Add option to send unchanged values to help metrics db's

[ggggh]

Could you add a config option to switch on and off the current behaviour of not re-sending a sensor value if it has not changed since the last message? For example, currently if the ph value has not changed from the last reading we do not get ph/state resent mqtt message, but we do get ph/attr. In certain scenarios it may help to get the update even if value has not changed (for example, plotting them in grafana)

[LordMike]

Sure. I'll leave this open to keep track of it.

[ggggh]

What is the environment setting to activate this option? Tried: ReportUnchangedValues: "true" but unsuccessful. (Had to use the string, as docker-compose won't take a boolean)

[LordMike]

It's BlueRiiot__ReportUnchangedValues. And a string is completely fine.

I'll update the readme.

[ggggh]

Thanks! It's working now! It sends all values back now on every update_interval - But I was rather thinking of it a different way though - only sending back repeated data if there has been a valid sensor reading confirming the old value is still the current value.

Example, a scenario where sensor actually reads hourly: Real Sensor values: Values at 1pm: PH 7.0, ORP 700 Values at 2pm: PH 7.0, ORP 701 Values at 3pm: PH 7.1, ORP 701

With setting at "false", polling every 10 minutes we get this: 1:10pm: PH 7.0, ORP 700 2:10pm: ORP 700 (PH not returned as it has not changed) 3:10pm: PH 7.1 (ORP not returned as it has not changed)

With setting at "true" we get this: 1:10pm: PH 7.0, ORP 700 1:20pm: PH 7.0, ORP 700 1:30pm: PH 7.0, ORP 700 1:40pm: PH 7.0, ORP 700 1:50pm: PH 7.0, ORP 700 2:00pm: PH 7.0, ORP 700 2:10pm: PH 7.0, ORP 701 2:20pm: PH 7.0, ORP 701 2:30pm: PH 7.0, ORP 701 2:40pm: PH 7.0, ORP 701 2:50pm: PH 7.0, ORP 701 3:00pm: PH 7.0, ORP 701 3:10pm: PH 7.1, ORP 701

My expectation was: 1:10pm: PH 7.0, ORP 700 2:10pm: PH 7.0, ORP 701 3:10pm: PH 7.1, ORP 701

So, we only get a dump of values when there is an actual sensor reading, but when we do, we send all value data, not just the one which has changed.

The point is, with the current "True" setting implementation we are getting values for which a reading has not been truly confirmed - we don't know at 1:30 that the ORP is still 700, because it hasn't been read by the sensor since 1:00. But we do know at 2:10pm that the PH was still 7.0, as there was a sensor reading - we just aren't sending it when on the "False" setting because it had not changed.

Makes sense? Maybe can implement it as a third option, as the others may be useful in different scenarios?

[LordMike]

I see.. It makes sense. Another thing I was considering was finally getting around to doing polling when the sensor makes readings. The API tells me when it's expected to do a new measurement, so I could ditch the static polling interval and go for a more dynamic route.

12 is on this other topic.

[LordMike]

Besides, you probably should poll more rarely :)

[ggggh]

Probably! But sensor readings are never less than 1 hour apart, and that is too long to be able to use the data for real-time pool control; if I only poll every 30 mins it means potentially adding 29mins to the latest age of the data. That's sometimes over 2 hours with no data. I'm refining my understanding of the data's behaviour in my pool, so hopefully can live with older data soon, when I can predict trends better.

Very interesting that the API tells you the next reading time...! I'd be interested to see if a bluetooth reading reschedules the subsequent sigfox reading.

[LordMike]

My goal would be to at least wait until the reading should be ready, and then poll often until it is ready.. then repeat.

That should make the data as live as possible.

[ggggh]

That would be excellent, as long as can also cover an ad-hoc bluetooth reading, but I guess we'd be missing that one as we would only have scheduled a poll for the planned sigfox one

[ggggh]

I'm also going to try to look into the decimals on the graph API - I could live with somewhat longer polls as long as I have more precise data

[LordMike]

Perhaps a command you can send to BR2M to invoke a poll ?

[ggggh]

That would work - an ad-hoc poll request via an mqtt message

[LordMike]

@ggggh I've had some time to rework the application. It should now report unchanged values, whenever a new measurement arrives.

In version 0.5.0