Optimize MQTT Public display? about bresserweathersensorreceiver HOT 5 CLOSED

Sorry, I'm quite busy at the moment. I'll have a look at this as soon as my spare time permits.

from bresserweathersensorreceiver.

No problem.
Is mainly cosmetic.

from bresserweathersensorreceiver.

Hi,

o.k., let's discuss this step by step.

1. Order data/LSDWetterSensor (as in the example) or LSDWetterSensor/data (your proposal)
   The idea behind this was, that data contains the topics for one or more sensors and nothing else.
   If you prefer the second variant, you can just change the order of the format strings and the variables in the snprintf() function call
   from

      // Try to map sensor ID to name to make MQTT topic explanatory
      for (int n=0; n<NUM_SENSORS; n++) {
        if (sensor_map[n].id == weatherSensor.sensor[i].sensor_id) {
          snprintf(mqtt_topic, TOPIC_SIZE+31, "%s/%s", mqttPubData, sensor_map[n].name.substr(0, 30).c_str());
          break;
        }
        else {
          snprintf(mqtt_topic, TOPIC_SIZE+31, "%s/%8X", mqttPubData, weatherSensor.sensor[i].sensor_id);
        }
      }
   

   to

      // Try to map sensor ID to name to make MQTT topic explanatory
      for (int n=0; n<NUM_SENSORS; n++) {
        if (sensor_map[n].id == weatherSensor.sensor[i].sensor_id) {
          snprintf(mqtt_topic, TOPIC_SIZE+31, "%s/%s", sensor_map[n].name.substr(0, 30).c_str(), mqttPubData);
          break;
        }
        else {
          snprintf(mqtt_topic, TOPIC_SIZE+31, "%8X/%s", weatherSensor.sensor[i].sensor_id, mqttPubData);
        }
      }
   

   The string length remains the same, so there is no risk of buffer overflow.

2. extra as part of the sensor data
   My idea was that to use extra for any data not directly coming from a sensor, i.e. calculated data which might also be generated from signals received from different sensors. So it's basically a matter of taste and how you are using the topic.

3. radio as part of the sensor data
   Yes, there is a strong correlation between the RSSI and the specific sensor, because the RSSI is read directly after receiving a message and finally assigned to the sensor's data structure after successful decoding. I agree.

4. status as part of the sensor data
   status provides information about the MQTT client and is not related to a specific sensor.

In general, you could move the topics around as you like - you just have to make sure that you do not exceed the buffer sizes. I think it makes sense to change the data types from char [] to String.

After all, the examples are just... examples... not final software products.

But I will keep this in mind for the next release!

Best regards
Matthias

from bresserweathersensorreceiver.

Changed payload from char [] to String in v0.11.0 as proposed above.

from bresserweathersensorreceiver.

Implemented 1. and 3. in v0.12.0

from bresserweathersensorreceiver.