Closed antst closed 4 years ago
I don't observe the behavior you claim when I recreate the situation you describe. In my setup only the second value is reported via MQTT, as you expected. Of course, the original value will have been reported before overriding the control setpoint.
Your MQTT messages don't have a timestamp. Are you sure the first one happened due to the T90012500 message and didn't happen before the control setpoint override?
Closing due to lack of response from the originator. Assuming the observed behavior was due to misunderstanding by the user.
Today I finally updated to this version (before I was using 4.3. from site with my own patches to add more MQTT actions and reports).
This version has an issue that it reports in MQTT twice if you override something (like CH)
For example this from log (clearly, CS is overridden with 22) 12:46:43.723811 T90012500 Write-Data Control setpoint: 37.00 12:46:43.730684 R90011600 Write-Data Control setpoint: 22.00 12:46:43.846851 B50011600 Write-Ack Control setpoint: 22.00 12:46:43.853892 A50012500 Write-Ack Control setpoint: 37.00
results in two MQTT messages events/central_heating/otmonitor/controlsetpoint 37.00 events/central_heating/otmonitor/controlsetpoint 22.00
Same for events/central_heating/otmonitor/chenable 1 events/central_heating/otmonitor/chenable 0
While formally second value is what you would expect, anything which is subscribed to those topics will be triggered twice and can be confused.