-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
please add a "TeleRetain" option #1071
Comments
This is a bad idea. If telemetry messages are retained and you take a decision based on them, if the sonoff goes down you still get the tele message on subscription and take a wrong decision. Better save the messages and the received time to a database and use them for your future decisions. |
telemetry messages, just like sensor messages, have a timestamp already on them. actually, this is how I discovered #1072 |
I also do not understand why there is a retain required. I retain the message and the information in other Programms like ThingWorx or OpenHab. For example the APMac and RSSI. Anhyhow having an option for those people who need it, seems to be ok. It is always the issue to keep RAM requirements in mind. The ESP is limited and arend did a great job not to implement everything. |
the retain flag on published messages does not affect RAM requirements on the ESP as the information is not retained in the ESP but in the MQTT broker. having an option of course would use a few bytes of code on the ESP. having that hardcoded to 1 would not affect the ESPs resources in any way. I hacked that already to go along with the SensorRetain option to be able to develop stuff without having to wait for this to be implemented. i.e. my SensorRetain also means TeleRetain. my stuff works already, it autodiscovers every tasmota device connected to the mqtt and graphs RSSI and Vcc values nicely for all devices. it also graphs all sensor data from devices that have sensors on them. TeleRetain = 1 would also provide one with the ability to see when a device was last seen online and may give a reason why it went offline. e.g. low RSSI or failing PSU. all without any other software just for retaining the data. |
The additional RAM and code requirements came from implementing the option in the MQTT command and serial commands. Just hard coding is not the way this great software is working. Also you need some bytes for the description text in the language file. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I added a TELE_RETAIN switch to the user_config.h in my local git and drag that along ever since. as can be clearly seen, no additional RAM is wasted and there isn't even anything that needs translation.
|
Hi, please add a Pull Request with this to be discussed there, because this is an enhacement. Thanks |
If this fix is all you need I'll add it as designed here; a compile option only. |
5.12.0m * Add define MQTT_TELE_RETAIN compile option default set to 0 (#1071)
yes it's all I need, thank you very much! |
5.12.0m * Add define MQTT_TELE_RETAIN compile option default set to 0 (arendst#1071)
if set, it would set the retain flag on telemetry messages.
motivation:
I'm writing a series of munin and nagios/icinga plugins that would use that data.
those scripts are just executed once and expected to terminate immediately with a result printed to stdout.
so, no time to wait for a telemetry message to show up.
the only way to work around this would be to write some sort of always running programm that lurks on the mqtt, stores the information and hands it over to a monitoring script once it is queried.
with that information retained, the script would connect to the mqtt, reads the retained information, converts it, hands it over to the monitoring system and terminates.
telemetry info could be used to monitor wifi RSSI to get a more or less realtime monitoring of your wifi coverage. e.g. create a heat map.
I'd also monitor voltages to perhaps predict PSU failure on a sonoff module.
outline: ~40 tasmota devices, ~30 of them sonoff touch.
if you think what I'm trying to do is stupid and there is a better solution, please feel free to point that out.
meanwhile, I write that for the sensor output.
The text was updated successfully, but these errors were encountered: