Insteon: Add Dim, Bright, Fast(On/Off) Support to Relay Devices

[krkeegan]

So while a relay device cannot itself be dimmed, at least some are able to send dimming related messages to other devices. It would be nice if Insteon could handle these.

The issue is how to handle them. Which itself has two issues, 1) the state of the device itself and 2) correctly setting the state of linked devices.

Linked Devices This should be easy, if a controller relay device issues a dim related command, MH should represent the state of the devices linked to this controller accurately. If this isn't working properly right now, this is just a matter of correctly passing on the state to the set_linked_states routine.

The Device Itself We can say that a device has two parameters that we are interested in. The LOAD which defines the state of the light attached to the device and the SWITCH which defined the commands received from toggling the physical switch on the device. Historically, MisterHouse has merged the SWITCH and the LOAD parameter into a single variable, the State variable. Up until now, this made sense because SWITCH and LOAD were believed to always be the same. This new revelation proves that this assumption was wrong.

Of the two parameters, the state variable inside MisterHouse is most associated with the state of the LOAD.

Solutions I can see, and my comments:

1. Tie the state of the device to the SWITCH parameter. [I strongly dislike this idea, as it would allow the state of relay devices to appear dimmed, which is incorrect]
2. Change the State of the device for a single loop. This would cause the State of a Relay to appear dimmed for a few milliseconds. It would be enough for the change to be seen by the state_now variable, and the change would appear as an entry in the state log, but the change would be likely too fast to be seen by the user. [I could accept this design, i am not thrilled that the state even briefly represents the state of the LOAD incorrectly.]
3. Add a specific routine for checking the state of the SWITCH. [Easy to implement, but no very user friendly]
4. Add the ability to create a virtual SWITCH tracking device. Basically, this would be a Generic_Item whose state simply matches that of the SWITCH, it would somehow be added as a linked device so that it received the state changes. [Not very user friendly]

[gac410]

Kevin,

I'm wondering whether there really is a "fast" type state, or if the state really is simply "on" or "off", or 100%, as currently implemented. Instead of treating the "fast" event as a device state,
it is a modifier describing how a device got to it's current state. Or maybe the command vs. state needs to be separated, and the device objects implement how a device state changes based upon the command on the wire.

MisterHouse would implement "command" methods to differentiate between the command on the wire and the state of the device. When a switch device is double-clicked, it provides

• state_now ON
• command_now ON_FAST

So the state is persistent, the device remembers its state, but the command is transient. While there is a "state" method, I don't think that there is a matching "command" method, reflecting the purely transient nature of the command.

I think the same thing might apply to the dim/bright behavior. When holding the button on the switchLincRelay, the state of the device still toggles from OFF to ON, but the command on the wire is a dim or bright to some level. So the state_now is ON or OFF, but the command_now reflects that level command was transmitted.

But the converse is not the same behavior. If I hold the dim/bright on a switchLinc dimmer, the linked switchLincRelay does NOT change state. It only responds to on, on_fast, off, and off_fast. dim and bright are ignored. so state_now for the Relay device would never occur, and state remains as it was, even though command_now for a linked device was a dim or bright command.

It might also make sense to implement a command_log which parallels the state_log.

George

On 07/17/2014 02:25 PM, Kevin Robert Keegan wrote:

So while a relay device cannot itself be dimmed, at least some are able to send dimming related messages to other devices. It would be nice if Insteon could handle these.

The issue is how to handle them. Which itself has two issues, 1) the state of the device itself and 2) correctly setting the state of linked devices.

Linked Devices This should be easy, if a controller relay device issues a dim related command, MH should represent the state of the devices linked to this controller accurately. If this isn't working properly right now, this is just a matter of correctly passing on the state to the set_linked_states routine.

The Device Itself We can say that a device has two parameters that we are interested in. The LOAD which defines the state of the light attached to the device and the SWITCH which defined the commands received from toggling the physical switch on the device. Historically, MisterHouse has merged the SWITCH and the LOAD parameter into a single variable, the State variable. Up until now, this made sense because SWITCH and LOAD were believed to always be the same. This new revelation proves that this assumption was wrong.

Of the two parameters, the state variable inside MisterHouse is most associated with the state of the LOAD.

Solutions I can see, and my comments:

1. Tie the state of the device to the SWITCH parameter. [I strongly dislike this idea, as it would allow the state of relay devices to appear dimmed, which is incorrect]
2. Change the State of the device for a single loop. This would cause the State of a Relay to appear dimmed for a few milliseconds. It would be enough for the change to be seen by the state_now variable, and the change would appear as an entry in the state log, but the change would be likely too fast to be seen by the user. [I could accept this design, i am not thrilled that the state even briefly represents the state of the LOAD incorrectly.]
3. Add a specific routine for checking the state of the SWITCH. [Easy to implement, but no very user friendly]
4. Add the ability to create a virtual SWITCH tracking device. Basically, this would be a Generic_Item whose state simply matches that of the SWITCH, it would somehow be added as a linked device so that it received the state changes. [Not very user friendly]

— Reply to this email directly or view it on GitHub https://github.com/hollie/misterhouse/issues/438.

[krkeegan]

@gac410, your testing matches what I am seeing.

Your proposal is seems closest to my third idea above. Although, your suggestion of a command_now routine might be more than we can easily do. The state, state_now, and state_changed routines are intertwined deeply within MH and require a number of supporting routines. What I am suggesting is really a single "command" this would always report the most recent command state of the device even if that state was sent a while ago, this would be equivalent to the "state" method.