IOLinc relay state not reported

[djfjeff]

I use the IOLinc with a water valve, so I use it in Latching mode with no use for the sensor.

Triggering the scene 20 on and off effectively open and close the relay, so my valve work.

However, the MQTT state topic always report OFF because it tracks the sensor state. Without having the relay state available on MQTT, I cannot add the IOLinc to HASS as it always stay in the OFF position (because it track the unused sensor state in my case).

[TD22057]

The IOLinc is a mess. It reports sensor states in some cases and relay states in other cases on the same group so there is no way to tell them apart. See the comment here: #12 (comment) for a break down of what happens when. I'll think about if there is a way to "fix" this but I'm not sure there is. I also can't find a developers guide for the IOLinc so I don't know if there is anyway to query the relay state from the device.

[djfjeff]

There is surely a way of getting the relay status because the Insteon app does it and report it. You can choose in the app to report either the relay status or the sensor status.

However, I agree with you that without a developer guide, this is something hard to figure out.

[krkeegan]

It is a bit messy, but I think it can be worked out. Here are my notes from a few years ago when working on Misterhouse:

The IOLinc is a strange device in that commands sent to it control one aspect
of the device, but commands received from it are from another aspect of the
device.

As a result of the IOLinc's oddities, when the IOLinc is set as a controller
of another device, that other device will be controlled by the sensor state.
However, when the IOLinc is set as a responder in a link, the relay of the
IOLinc will change with the commands sent by the controller.

One more oddity is that using the "set" button on the side of the device to
change the state of the relay, will cause MH to perceive this as a change in
the state of the sensor, thus placing the sensor and relay objects out of sync.

In short, Misterhouse determines whether to update the relay or the sensor depending on who is the initiator of the state change.

To request the status of either the relay or the sensor use the standard length message:

CMD1 -- CMD2 --
0x19    0x00    Response is relay state
0x19    0x01    Response is sensor state

[TD22057]

Thanks. I've been thinking about this today and I think this will work. I think there should be a new MQTT topic for the IOLinc which is the relay state. The IOLinc class is going to have to read the relay mode (latching, momentary, etc) and the delay time and store those. When it sees a command being sent to the device, it can send out a relay state message. Then some kind of timer will have to be fired to change the state message back if the device is in momentary mode. The addition of a general timer based message is going to a new change the network handling code which will require some though on how to achieve.

[TD22057]

I've submitted 1593430 which implements a timer based message system so the relay state can be updated in momentary mode.

[TD22057]

I've been working on this in my spare time. I added a relay topic/payload to the config file and updated the device to report relay vs sensor states. I've only had time to test latching mode but the state reporting for the relay and sensor are working for that mode. I'm still working on handling momentary cases and there are some weird (as usual for iolinc) issues when trying to refresh the relay state which I'm still working on.

The only real issue I see so far is that if you push the button on the iolinc, it sends the exact same message that the sensor change sends. So either that scenario should be ignored because pressing the button directly isn't likely or the system will need to ignore sensor messages and send a refresh command whenever it gets any status update from the device (which will delay reporting the sensor change some). I'm going to experiment and see how the refresh works out.

[TD22057]

OK - I officially hate the IOLinc now. Mine randomly stops responding to commands. The command will work once and then be completely ignored the next few times I send it. It also randomly doesn't send sensor update messages. I'll try and finish the coding but you may have to test it for me since my IOLinc seems to be dying a slow death...

[krkeegan]

@djfjeff I feel your pain. I just started setting things up in HASS and use an IOLinc in what sounds like a similar fashion. I have it set in latching mode and don't even use the sensor. So I only need to know the state of the relay.

I figured this out in Misterhouse and at least had it working there. My only concern is getting things to work in all of the possible configurations that someone may use an IOLinc for.

[krkeegan]

I am not sure where to add this information, so I will put it here, where I may find it when I need it.

We currently use a scene defined on the modem to change the IOLinc. This takes up one of the 254 scenes on the modem (not a big deal). But it also causes us to have to track what otherwise looks like a scene which can be problematic.

It turns out, we can send AllLink_Cleanup messages from the modem without sending the main scene command. This would enable us to link the IOLinc (many of them if we want, or other similar devices) to group 0x01 on the modem (which is often done as part of join anyways) and then when we want the IOLinc to do its thing, just send the Cleanup message using group 0x01 but directed solely to the IOLinc and not a broadcast. The IOLinc just thinks it missed the broadcast, and we make our lives a bit easier.

[krkeegan]

@TD22057 I am getting very different values and messages for setting and reading flags on the IOLinc. Can you confirm that the current code works for you? Specifically does changing the mode through latching->a->b->c work for you?

I have a device manufactured in 2015 that reports as i2. Dev=0x07 Sub=0x00 Firmware=0x41.

[krkeegan]

@TD22057 nevermind. I see my issue now, I was relying on insteon documentation. I should have learned by now that it is often wrong.

[krkeegan]

Alright, I have a lot more things working now. I am tracking the state of the relay and sensor independently.

In short:

• Don't ever use the Set button on the device to control the device. It just confuses us.
• Broadcasts from the device are always the state of the sensor.
• Commands or Broadcasts sent to the device always represent the relay state.

For the latching mode, everything works as expected, job done.

The momentary modes are a bit more of a thing for two reasons:

1. While we can see the relay turn on, we never get any notice that it turns off.

I think we can solve this either by reading the momentary time value on the device and using a timers.

Or, we don't solve it and we make users handle this in whatever platform they are using. One could configure this in Home Assistant to set the relay state to off X seconds after an on state is received.

2. Momentary C doesn't give any details of if the command was successful. The relay will only react if the command matches the state of the sensor. If the sensor is in the wrong state, we don't get any message that the relay didn't react.

The only way I can think to solve this is to track things in software We run the risk of getting out of sync, but I don't see any other option.

The other issue is @TD22057 comment that a keypadlinc button may get itself in the wrong state if the sensor is in the wrong state. I am inclined not to do anything about this. This seems very specific to a user's installation and if they want to solve this, they can do so with automations.

So, what do we think of the following?:

• Add a timer to track the momentary states and update the relay state accordingly.
• Add code to prevent the state change of a relay if Momentary-C is used and the sensor is in the wrong state.

[krkeegan]

#197 has been merged into dev and will be pushed to master next week. I think this will solve your issues.