Detecting where an update originates

[genie]

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.

[four2six]

why don't you use virtual switches in Domoticz for all your events on both systems and take it from there?

[genie]

why don't you use virtual switches in Domoticz for all your events on both systems and take it from there?

Can you please expand on that? I don't quite follow. This is a setpoint device, so I don't see how a switch would help?

// J

[four2six]

After reading it again, I'm not sure I really understood your problem.

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 understand this and your description of your 'circle flow' as a problem of not knowing when the script is still running or if it already has run. Adding something like a switch "script is running or has already run" and using that in the subsequent steps could help. you could turn that switch off after a certain time or when you're sure the last step is done.

but as i said, i'm not sure anymore i really understood your problem. if not, feel free to tell me so