Detecting where an update originates
Posted: Thursday 22 September 2016 16:05
I'd like to be able to detect the source of an update to sensor values in Domoticz.
I have an external vent system that I'm controlling via a modbus interface using a dedicated RPi. Once a minute, it sends updates to Domoticz and updates virtual temperature sensors, switches etc based on various values (such as supply and exhaust temperature, RPM of the fans, etc) in the vent.
I also have a web server on the remote RPi which takes commands to be written to the vent systems.
This works fine, with one exception. I have one value (the temperature setpoint) that I want to be able to change from the Domoticz dashboard, and that is also updated from the vent (in case the vent is altered outside of Domoticz using the actual remote control that came with the vent). This I have solved by triggering a call to the RPi when the setpoint value changes to update the value in the vent. This also works well with one exception; I cannot detect if the devicechanged event is triggered from the Domoticz dashboard or from the remote RPi usign the JSON interface, so every time the value is updated from the vent, I also generate an update request back to the RPi. This in itself is not all that bad (though it does create an endless loop of writes to the vent), unless I actually do a change in the dashboard while the value is being updated. And it just so happens that the script on the remote pi is run by cron and domoticz is executing scheduled changes (such as lowering the temperature setpoint during the day when nobody is at home) at the same time. So scheduled changes have no effect, as that will cause the following flow:
Suppose we start with temperature setpoint X, and schedule a change to setpoint Y.
(1) Script starts on remote RPi, writing and reading values to/from the vent, reading value X.
(1) Domoticz calls remote RPi, scheduling a write to value Y.
(2) Script completes (modbus isn't quick, so this takes ~10 seconds), and sends updates to Domoticz using the value read from vent (X)
(3) Domoticz stores value X, and calls remote RPi, scheduling a write to value X.
(4) Script starts on remote RPi, writing first value Y, then value X, and we're back to where we started.
I'm planning on implementing a workaround for this specific fault in delaying the start of the script on the remote RPi, but what I'd really like is to have the script detect when the device update event is originated from the remote RPi, and thus be able to void relaying that value back to the RPi. That would solve the problem completely.
I have an external vent system that I'm controlling via a modbus interface using a dedicated RPi. Once a minute, it sends updates to Domoticz and updates virtual temperature sensors, switches etc based on various values (such as supply and exhaust temperature, RPM of the fans, etc) in the vent.
I also have a web server on the remote RPi which takes commands to be written to the vent systems.
This works fine, with one exception. I have one value (the temperature setpoint) that I want to be able to change from the Domoticz dashboard, and that is also updated from the vent (in case the vent is altered outside of Domoticz using the actual remote control that came with the vent). This I have solved by triggering a call to the RPi when the setpoint value changes to update the value in the vent. This also works well with one exception; I cannot detect if the devicechanged event is triggered from the Domoticz dashboard or from the remote RPi usign the JSON interface, so every time the value is updated from the vent, I also generate an update request back to the RPi. This in itself is not all that bad (though it does create an endless loop of writes to the vent), unless I actually do a change in the dashboard while the value is being updated. And it just so happens that the script on the remote pi is run by cron and domoticz is executing scheduled changes (such as lowering the temperature setpoint during the day when nobody is at home) at the same time. So scheduled changes have no effect, as that will cause the following flow:
Suppose we start with temperature setpoint X, and schedule a change to setpoint Y.
(1) Script starts on remote RPi, writing and reading values to/from the vent, reading value X.
(1) Domoticz calls remote RPi, scheduling a write to value Y.
(2) Script completes (modbus isn't quick, so this takes ~10 seconds), and sends updates to Domoticz using the value read from vent (X)
(3) Domoticz stores value X, and calls remote RPi, scheduling a write to value X.
(4) Script starts on remote RPi, writing first value Y, then value X, and we're back to where we started.
I'm planning on implementing a workaround for this specific fault in delaying the start of the script on the remote RPi, but what I'd really like is to have the script detect when the device update event is originated from the remote RPi, and thus be able to void relaying that value back to the RPi. That would solve the problem completely.
