Insteon I/O Linc to Control a Garage Door

Configuration
1

I have…

  • HA running in a docker instance on a home server
  • an Insteon Hub controlling a variety of their devices
  • two garage doors controlled via Insteon I/O Linc devices, which appear in HA as two devices, a switch and a binary_sensor
  • no clue what I’m doing.

I have two problems:

  1. The sensor states are not always accurate.

The doors are sometimes opened via their own openers. The Insteon app picks this up and correctly shows the state of both doors no matter how they were opened. But HA seems to not always accurately show the states. For instance, right now (after several restarts of HA) the two binary sensors are correct, but yesterday when both doors were closed the sensor for one was correct and the other was flipped so it showed as open all day and closed when I opened it.

Is there a way for me to query the Hub and then reset the state of the binary_sensor so if it gets flipped it can correct itself?

and

  1. What’s the best way to display garage doors in UI?

I’m thinking a glance card with an icon that changes to display open / closed state that responds to a on_tap that will send the switch.turn_on to the switch. The switch only responds to a turn_on, so I also need a ? that immediately turns it back off. I’ve seen this discussed in other threads, but am unclear if it is a script, an automation, or something else. And I’m unclear how this script / automation gets called from the UI card.

2

What version of HA are you using?

3

Version 0.103.5

4

Try upgrading to 0.105. There was an update this week that fixed certain connectivity issues with the hub.

5

I’m up to 0.105.2. I’m still having the same troubles. It’s consistent in behavior. But, I have two devices and only of them is getting its state flipped.

Two doors. Two I/O Lincs. One cycles states as I expect it should. The other one seems to miss the first time the sensor flips state and then ends up backwards. The Insteon app shows the state accurately regardless of how the door is triggered, whether by the opener itself, the Insteon app, or from HA.

I verify with the Insteon app what the current state is. I then use the Developer Tools -> States to correct to match reality. I trigger the switch.turn_on for the relay. I hear the door moving. I see state change in the Insteon app. State in HA is unphased. So, now door is open, Insteon app says door is open, but HA says it is closed. Wait a moment for everything to settle down. Trigger the switch.turn_on again. I hear the door moving. The Insteon app and HA both flip the state at the same time. Door is now closed, Insteon says it is closed, but HA says the door is open.

Here is the log from the above two actions. https://pastebin.com/bGEvz9pP

I don’t know how to read these messages. Are the codes, flags, commands, etc documented anywhere publicly reachable? Which line is the sensor changing the state?

6

Generate a printout of the modem database. You can do that via Developer tools-> Services -> Insteon.print_im_all_link_database. Look for your IO Linc devices. You will probably see a difference between the one that works and the one that does not. Let me know the results.

7

For my 2nd half of my original post, I think I got the UI part sorted.
Here’s what I have at this point, in case anyone else wants to see the example.

The card in the UI makes use of the custom button card. It ends up looking like this:

image
image694×378 13.9 KB

The icon displays state of the door based on the sensor on the door, so the icon and text toggles between green and ‘closed’ when sensor says the door is closed and red and ‘open’ when door is open. The icon responds to a tap that triggers a script to open or close the door.

Here’s the code for the card:

  - type: 'custom:button-card'
    tap_action:
      action: call-service
      service: script.left_garage_toggle_switch
      service-data:
        entity: script.left_garage_toggle_switch
    entity: binary_sensor.i_o_linc_44_12_34_group_2
    show_state: false
    size: 30%
    state:
      - color: 'rgb(255, 5, 5)'
        icon: 'mdi:garage-open'
        name: Left Garage<br>Open
        value: 'on'
      - color: 'rgb(5, 255, 5)'
        icon: 'mdi:garage'
        name: Left Garage<br>Closed
        value: 'off'

The relay that triggers the garage door opener only responds to a switch.turn_on. That switch would then be on so the next toggle of the switch fires switch.turn_off which the garage door doesn’t respond to.

So, instead of interacting with the switch directly, I fire this script which sends the turn_on to get the door moving and then immediately sends the turn_off to reset the switch so it is ready for next action.

The script looks like this:

left_garage_toggle_switch:
  alias: Toggle Left Garage Switch
  sequence:
    - service: switch.turn_on
      data:
        entity_id: switch.i_o_linc_44_12_34_relay
    - delay: 
        milliseconds: 25
    - service: switch.turn_off
      data:
        entity_id: switch.i_o_linc_44_12_34_relay

I saw several ways to handle combining the switch and sensor into a single card and turning the relay’s switch into a momentary button that are based on automations, templates, and other things. This setup seemed to be less code and thus has less moving parts to maintain.

8

Is this it?
The only difference I’m seeing is in the ‘Group’ column.

 ALDB load status is LOADED
 RecID In Use Mode HWM Group Address  Data 1 Data 2 Data 3
 ----- ------ ---- --- ----- -------- ------ ------ ------
  0005    Y     C   N      2 44.10.E9     1     0    65
  0004    Y     R   N      1 44.10.E9     0     0     0
  0003    Y     C   N      0 44.10.E9     1     0    65
  0002    Y     C   N      1 44.12.34     1     0    65
  0001    Y     R   N      1 44.12.34     0     0     0
  0000    Y     C   N      0 44.12.34     1     0    65
9

I think I might have accidentally got it! You got me looking for differences between the two devices. What I ended up finding was in the Insteon app:

IMG_2861
IMG_2861747×1286 68.8 KB

On one device, the “sensor sends” was set to ‘Off’ and on the misbehaving one it was set to ‘On’. I got them both set to ‘Off’ and now it seems (so far) to be responding correctly.

10

Good to hear you figured it out.

11

Thank you! Couldn’t have done it without ya!

12

I have the same issue, with some help and reading, I ended up creating my own manual binary sensor and reversing the output so I can display it properly.

How do I make the above change directly in home assistant WITHOUT using the Insteon app? I would like the native insteon sensor to display properly and get rid of my custom one if possible

Hassio - current version

Thanx!!

d

13

any one have any luck with this?

I have the same issue, with some help and reading, I ended up creating my own manual binary sensor and reversing the output so I can display it properly.

How do I make the above change directly in home assistant WITHOUT using the Insteon app? I would like the native insteon sensor to display properly and get rid of my custom one if possible

Hassio - current version

Thanx!!

d

14

At some point after I started this thread (I don’t remember when exactly), the logic on these sensors flipped. In the code I posted above I turn the icon red to indicate the door is open when the sensor is “on”. After an update a while back, I saw the logic flip and I had to update the state code on the icons and referenced scripts so red == door is open == “off”.

You’re not crazy. My code above is backwards.

Where I am now, the Insteon app says the sensor sends ‘on when closed’. That was what they defaulted to whenever I reset the hardware device, so I opted to stop fighting them. Then I set the binary sensor in HA to treat ‘off’ as door is open.

15

How do I correct the same issue you have with mine. Reads opposite. open is closed and closed is open. I dont know allot yet about HA but trying to learn. Do I need to edit code somewhere to flip the verbage? Here is a link of my issues with IOlinc which seems exact with yours and hopfing to fix this or a work around. Insteon Cover for I/O Link - #25 by mtiede

16

There are two sides to this…

In the Insteon app to control the config for each device, you can set the behavior for the sensor at the door. ‘on when closed’ vs ‘off when close’, see screenshot above. This is significantly hampered by Insteon going offline.

And then in HA, you can control the behavior of the sensor entity a couple different ways.

1_ A ‘template’ lets you alter the behavior at the entity level, the result being when you use the entity in the card it will have the states as specified by the template. This is very extensible and allows you to do a bunch of cool tricks, such as have the actual state reported by the sensor be ‘open’ vs ‘closed’ instead of ‘on’ v ‘off’. It’s really handy, but probably overkill for this application.

2_ The other way is to roll with whatever state the entity gets and change the card logic to accommodate it. There’s an example of that above in the code above where I change the button-card based on the state: tag, specifically the value: tag under the state: tag. Watch the entity in the Developer Tools’ State tab and pay attention to what it changes to when the door is open vs closed, then set the card to ‘open’ vs ‘closed’ based on whatever was reported. If you copied the card code above and door state is reported backwards, just swap the ‘on’ and ‘off’ in the value: lines.

17

I’ll take a look and see if I can figure out how and what to do to change the state per your yaml.

18

Wish I could go into insteon app to switch the open close thing but cant.I think i understand what you mean about the cards and flipping them and will try that. I wonder how this would work if i want to create a goodnight scene and check the sensor to see if closed and if not, then tell the iolinc to close the garage?

19

thank you !

20

I was using the I/O module to send me a push message on my phone when the doorbell rang. Now that I’ve moved to HA it’s not clear to me as how to detect when the signal is triggered and if HA can send a push message. Would be great to send it to Alexa instead of the phone which was the hopes I had from the beginning.