Request: Retain flag on SENSOR data

[tam481]

Hi Theo,
Would it be possible to retain sensor messages?

thanks in advance

[davidelang]

what do you mean by retain sensor messages?

If you are meaning to save the temp/humidity/power data to flash so that it's not lost on a reboot, that's not really possible because flash is write limited, it will wear out, so writing to it every time we get a new piece of data would cause the devices to wear out much faster.

It's far better to have your home automation system grab the data and store it in some method. Even if you use a Pi and write to a SD card, you can at least replace the SD card when it wears out and not have to replace the entire computer (or in the case of the sonoffs, all the computers wired into things around your house as they wear out) :-)

[khcnz]

Was this in relation to setting the retain flag on the MQTT messages (same as the below concept?)
#define MQTT_BUTTON_RETAIN
#define MQTT_POWER_RETAIN
#define MQTT_SWITCH_RETAIN

[davidelang]

each of those things is expected to change relatively infrequently, when they are configured to retain, every time the item changes it writes to flash. sensor data is expected to change every time it's reported (5 min by defaults, but it works down to about 5-10 seconds

…

On Sun, 19 Mar 2017, khcnz wrote: Was this in relation to setting the retain flag on the MQTT messages (same as the below concept?) #define MQTT_BUTTON_RETAIN #define MQTT_POWER_RETAIN #define MQTT_SWITCH_RETAIN

[khcnz]

I haven't looked at the code but one of us is confused - i was talking about the retain flag sent on the MQTT messages which tells the broker to store this message. Nothing to do with flash

[davidelang]

Yes, one of us in confused, I'm pretty sure those retain flags are telling the firmware on the esp to save those to flash so that they are avaiable after restart. I don't see how it would make sense for the device to set a flag on messages to the mqtt broker about retention, it has no idea what is on the other end of the broker (how many different things may be there), let alone if it makes sense for those things to remember state or not. David Lang

[khcnz]

I have had a look at source - pretty sure I am correct and these relate to the retain flag on the MQTT message.

The point of the retain flag is that the message is cached by the broker so when you connect you will receive the most recent value that has been posted. This ensures that as long as your server is always reachable by sonoff then any client that would like to receive the most recent value can just ask the MQTT broker - thats an expected pattern good write up here about how it may be useful in an IOT world http://www.steves-internet-guide.com/mqtt-retained-messages-example/

I'd suggest its a valid use case and re-open the ticket for prioritization. the change would be pretty trivial.

[davidelang]

If this is just a flag to the mqtt broker telling it to cache the data and allow it to be queried (as opposed to the 'normal' role of the broker of just message passing), then is there a reason not to set the flag all the time? It's a different mode of accessing the broker, so it won't confuse existing clients. And it's not likely to be a significant load on the broker (or if it is, even with thousands of devices, the broker needs to be fixed :-) go ahead and re-open the issue.

[khcnz]

It wasn't my ticket and i don't have issue permission :)

[arendst]

Implemented SensorRetain on message tele/sonoff/SENSOR in next release.