Best practice for event triggers after startup or reconnection

[jstuyts]

When my plug-in is shut down or when the connection is lost, I change the value of all its devices to a special value indicating that the actual current value is not known. After the connection with the device is reestablished, I update the values to the actual values.

What is the best practice for event triggers for the first value update after a successful reconnection?

• Always trigger events. This may result in events undoing manual changes.
• Never trigger events. This may require manual changes to get the system in the desired state.
• Save the last value when disconnecting, and only trigger if the current value is different. This may result in a combination of undoing manual changes and requiring manual changes.

Here is a simplified example. An event has been created that turns relay 2 on whenever relay 1 is turned on:

1. Turn on relay 1.
2. HomeSeer runs the event, and relay 2 is turned on.
3. The user manually turns off relay 2.
4. The connection is lost.
5. Both relay values are changed to idle.
6. The connection is reestablished.
7. The plug-in updates the relay values: 1 = on, 2 = off.
8. Should relay 2 be turned on by the event at this point?

[bsobel]

Can your plugin determine the relay state or is it a 1 way control? If bi-directional I think your model is off. I’d suggest not changing the relay state to unknown but rather a different device that represents the communication state.

I do almost the same thing you do with Tuya devices. The root device gets set to the connection state (e.g. tcp MQTT or plugin stopped). That parent device has a say a switch device which represents an outlet. I get the actual switch state and only if the state doesn’t match the Hs device state do I make that change.

In general stopping and immediately restarting a plugin shouldn’t cause a bunch of events to trigger if the actual device states haven’t changed (at least that’s my opinion)

[jstuyts]

The relay state can be queried and changed. I do the same as you do when the connection is established: Continuously poll the device and only update the value if it has changed. I already noticed event storms if I always updated the value.

Switching to a different device when the connection state changes has quite a bit of impact, so I won't be doing that unless I have no other option.

In general stopping and immediately restarting a plugin shouldn’t cause a bunch of events to trigger if the actual device states haven’t changed (at least that’s my opinion)

I'll do it like this (unless somebody else has good arguments for not doing it this way). I will try if storing the last known value in the plug-in extra data does the trick. Something like this:

if value is unknown
    if polled value does not equal last known value
        update value with trigger
        store the polled value as the last known value
    else
        update the value without trigger
else if value does not equal polled value
    update value with trigger
    store the polled value as the last known value

Thanks for your help.

[bsobel]

Anytime, and yes storing the prior state in the PED should work fine. Im curious, mind if I ask what kind of device your controlling?

[jstuyts]

I am working on a plug-in with which you can control relay boards connected to the network:

• Robot Electronics ETH008: Support for this one is almost done. I still need to do some polishing, make some minor changes, and test extensively.
• Robot Electronics ds2824: This will be the next one to be supported. I plan on supporting both the relays and (all modes of) the I/O ports.

And that are the 2 boards that I own. Support for other boards should be relatively easy to add.

[bsobel]

I am working on a plug-in with which you can control relay boards connected to the network:

• Robot Electronics ETH008: Support for this one is almost done. I still need to do some polishing, make some minor changes, and test extensively.
• Robot Electronics ds2824: This will be the next one to be supported. I plan on supporting both the relays and (all modes of) the I/O ports.

And that are the 2 boards that I own. Support for other boards should be relatively easy to add.

Cool, thanks!

[alexbk66]

AKWebIO 4.0.5.13 Added RobotElectronics (Devantech) ETH008

https://forums.homeseer.com/forum/hs...d-input-boards