I’m using a Insteon I/O Link for my garage door. I’m trying to create a Cover for this. However the documentation regarding the Insteon Cover says it supports the Open/Close Micro Module. Would this work with a I/O Link and how would I go about doing so?
I’m using Hassio on a raspberry Pi 3 B+
The I/O link works in HA as two entities, the switch and the sensor. The switch is used to trigger the device and the sensor tells you if the sensor is open or closed. Unfortunately it does show as a cover. That is something I have been thinking about since it is often used for garage doors.
Yeah, having it as a cover would be great. The switch part works no problem. However I find the sensor doesn’t respond very well on change. 95% of the time the binary_sensor will not update when it changes. It is the only Insteon sensor I have. So I have nothing else to compare with.
Any thoughts as to why it might be?
Sorry about the long delay here. I have been transitioning jobs.
The first question is if the unit is sending messages and HA is not catching them correctly or if the unit is not sending messages due to the magnet not tripping the sensor. The way to check this is to enter debug mode and track the messages. Put this in your configuration.yaml file.
logger:
default: warn
logs:
insteonplm: debug
Once you edit configuration.yaml you need to restart the system. Then send me any lines that look like this:
2018-10-31 15:34:01 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 45.31.94, 'target': 00.00.01, 'flags': 0xcb, 'cmd1': 0x11, 'cmd2': 0x00}
2018-10-31 15:34:02 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 45.31.94, 'target': 19.1A.60, 'flags': 0x41, 'cmd1': 0x11, 'cmd2': 0x01}
2018-10-31 15:34:02 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 45.31.94, 'target': 11.02.01, 'flags': 0xcb, 'cmd1': 0x06, 'cmd2': 0x00}
2018-10-31 15:34:57 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 45.31.94, 'target': 00.00.01, 'flags': 0xcb, 'cmd1': 0x13, 'cmd2': 0x00}
2018-10-31 15:34:57 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 45.31.94, 'target': 19.1A.60, 'flags': 0x41, 'cmd1': 0x13, 'cmd2': 0x01}
2018-10-31 15:34:57 DEBUG (MainThread) [insteonplm.devices] {'code': 0x50, 'address': 45.31.94, 'target': 19.1A.60, 'flags': 0x41, 'cmd1': 0x13, 'cmd2': 0x01}
2018-10-31 15:34:57 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 45.31.94, 'target': 13.02.01, 'flags': 0xc7, 'cmd1': 0x06, 'cmd2': 0x00}
Where address is the I/O Link device. The cmd1 field is the important one. cmd: 0x11means the door is open andcmd1: 0x13means the door is closed. You can ignorecmd1: 0x06` but send them to me anyway.
Also, are you using a PLM or a Hub?
Finally, I am aware of one bug in the system where the initial state is flipped so when the door is open it shows as closed and vise versa. I will get that fixed soon.
No problem. We all have busy lives. Thanks for getting back.
I’m using a Hub. I did add the debug logger to configuration.yaml file and restarted the system. I have the following in my configuration.yaml file.
insteon:
host: 192.168.0.14
hub_version: 1
logger:
default: warn
logs:
insteonplm: debug
I have the following in my groups.yaml file
garage:
name: Garage
entities:
- light.garage_light_1
- binary_sensor.22d4ff_2
The filter attributes of the Insteon sensor are as follows:
INSTEON Address: 22.D4.FF
INSTEON Group: 2
friendly_name: Garage Status
device_class: opening
Here is my Log after opening and closing garage door
2018-11-03 16:39:11 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2018-11-03 16:39:11 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 22.D4.FF, 'target': 00.00.01, 'flags': 0xcb, 'cmd1': 0x13, 'cmd2': 0x00}
2018-11-03 16:39:11 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] Received 11 bytes from PLM: b'025022d3fb130201cb0601'
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'025022d3fb130201cb0601'
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 22.D4.FF, 'target': 13.02.01, 'flags': 0xcb, 'cmd1': 0x06, 'cmd2': 0x01}
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.devices] Ending Device.receive_message
2018-11-03 16:39:17 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.Here is again
2018-11-03 16:57:44 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 22.D4.FF, 'target': 00.00.01, 'flags': 0xcb, 'cmd1': 0x11, 'cmd2': 0x00}
2018-11-03 16:57:50 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 22.D4.FF, 'target': 11.02.01, 'flags': 0xcb, 'cmd1': 0x06, 'cmd2': 0x01}
2018-11-03 17:01:42 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 22.D4.FF, 'target': 00.00.01, 'flags': 0xcb, 'cmd1': 0x13, 'cmd2': 0x00}
2018-11-03 17:01:48 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 22.D4.FF, 'target': 13.02.01, 'flags': 0xcb, 'cmd1': 0x06, 'cmd2': 0x01}So after looking further. The sensor status never changed. however it does show in the history timeline that it opened and closed. It just doesn’t update live
Ok, that should be sufficient for me to debug. Should have a response tonight or tomorrow. What is your platform (i.e. Hass.io, docket, virenv,…)?
Just re-read your post. This may not be an insteon issue. It may be a front-end issue. If the history says it opened and closed but the GUI does not change that my be a different issue. I will check the Insteon sensor code but can you tell me if you refresh the browser, does the status update?
I’m using Hass.io. I looked into the history timeline again and it isn’t accurate either. Meaning the times are off and it doesn’t show every instance of open/closing. Even refreshing the browser doesn’t update it on the front-end.
I also left the garage door open and rebooted Hass.io It also didn’t retrieve the correct status of the sensor. This was what the log shown on boot.
2018-11-04 12:46:55 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x0c, 'address': 22.D4.FF, 'linkdata1': 0x07, 'linkdata2': 0x00, 'linkdata3': 0x41}
2018-11-04 12:47:40 DEBUG (MainThread) [insteonplm.plm] Queueing msg: {'code': 0x62, 'address': 22.D4.FF, 'flags': 0x00, 'cmd1': 0x19, 'cmd2': 0x00, 'acknak': 0xNone}
I can confirm that there is a bug in the startup where the initial status shows a binary flip (i.e. door open shows sensor as closed and door close shows sensor as open).
I also see the problem with the sensor. The sensor and the switch both operate under group 1. I am not quite sure how to fix this yet but at least I know what the issue is. It works occasionally if the All-Link cleanup messages are sent because those messages are working correctly. But otherwise it does not. Hmmm…
I have fixed this issue and submitted a pull request (https://github.com/home-assistant/home-assistant/pull/18250)
Since this is a bug fix it should get in pretty quickly.
Great I will keep an eye out and give it a go
I’m currently experiencing the issue with the sensor not updating. I’m running v0.99.3 of Home Assistant. The IOLinc device address is 24.73.F7. Here are my logs:
2019-10-07 00:02:37 DEBUG (MainThread) [insteonplm.devices] Ending Device._send_msg
2019-10-07 00:02:37 DEBUG (MainThread) [insteonplm.devices] Starting 2F.73.F7 Device._process_send_queue
2019-10-07 00:02:37 DEBUG (MainThread) [insteonplm.devices] Lock is locked from yield from
2019-10-07 00:02:37 DEBUG (MainThread) [insteonplm.plm] Queueing msg: {'code': 0x62, 'address': 2F.73.F7, 'flags': 0x00, 'cmd1': 0x11, 'cmd2': 0xff, 'acknak': 0xNone}
2019-10-07 00:02:37 DEBUG (MainThread) [insteonplm.devices] Ending 2F.73.F7 Device._process_send_queue
2019-10-07 00:02:37 DEBUG (MainThread) [insteonplm.plm] TX: {'code': 0x62, 'address': 2F.73.F7, 'flags': 0x00, 'cmd1': 0x11, 'cmd2': 0xff, 'acknak': 0xNone}
2019-10-07 00:02:37 DEBUG (MainThread) [insteonplm.plm] Waiting for ACK or NAK message
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Received 20 bytes from PLM: b'02622f73f70011ff0602502f73f7aaaaaa2211ff'
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02622f73f70011ff0602502f73f7aaaaaa2211ff'
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02502f73f7aaaaaa2211ff'
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 2
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x62, 'address': 2F.73.F7, 'flags': 0x00, 'cmd1': 0x11, 'cmd2': 0xff, 'acknak': 0x06}
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Got Message ACK
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Look for direct ACK
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Ending Device.receive_message
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 2F.73.F7, 'target': AA.AA.AA, 'flags': 0x22, 'cmd1': 0x11, 'cmd2': 0xff}
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Got Direct ACK message
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Ending Device.receive_message
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.plm] ACK or NAK received
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Starting Device._wait_for_direct_ACK
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Direct ACK: {'code': 0x50, 'address': 2F.73.F7, 'target': AA.AA.AA, 'flags': 0x21, 'cmd1': 0x11, 'cmd2': 0xff}
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Releasing lock after processing direct ACK
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Device 2F.73.F7 msg_lock unlocked
2019-10-07 00:02:38 DEBUG (MainThread) [insteonplm.devices] Ending Device._wait_for_direct_ACK
2019-10-07 00:02:38 ERROR (MainThread) [hole] Can not load data from *hole: pi.hole
2019-10-07 00:02:38 ERROR (MainThread) [homeassistant.components.pi_hole] Unable to fetch data from Pi-hole
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Received 11 bytes from PLM: b'02502f73f7000001c71100'
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02502f73f7000001c71100'
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 2F.73.F7, 'target': 00.00.01, 'flags': 0xc7, 'cmd1': 0x11, 'cmd2': 0x00}
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Scheduling msg callback: <bound method IoLincSensor._close_message_received of <insteonplm.states.sensor.IoLincSensor object at 0x7fa21befd0>>
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Ending Device.receive_message
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Starting Device._send_msg
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Ending Device._send_msg
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Starting 2F.73.F7 Device._process_send_queue
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Lock is locked from yield from
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Queueing msg: {'code': 0x62, 'address': 2F.73.F7, 'flags': 0x00, 'cmd1': 0x13, 'cmd2': 0x00, 'acknak': 0xNone}
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.devices] Ending 2F.73.F7 Device._process_send_queue
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] TX: {'code': 0x62, 'address': 2F.73.F7, 'flags': 0x00, 'cmd1': 0x13, 'cmd2': 0x00, 'acknak': 0xNone}
2019-10-07 00:02:39 DEBUG (MainThread) [insteonplm.plm] Waiting for ACK or NAK message
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] Received 12 bytes from PLM: b'1502502f73f7aaaaaa471301'
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'1502502f73f7aaaaaa471301'
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.messages] Buffer content: b'1502502f73f7aaaaaa471301'
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.messages] Trimming leading buffer garbage
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 2F.73.F7, 'target': AA.AA.AA, 'flags': 0x47, 'cmd1': 0x13, 'cmd2': 0x01}
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.devices] Scheduling msg callback: <bound method IoLincSensor._open_message_received of <insteonplm.states.sensor.IoLincSensor object at 0x7fa21befd0>>
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.devices] Ending Device.receive_message
2019-10-07 00:02:40 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Received 44 bytes from PLM: b'02502f73f7130101c3060002502f73f7000001c3110002502f73f7aaaaaa41110102502f73f7110101c70600'
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02502f73f7130101c3060002502f73f7000001c3110002502f73f7aaaaaa41110102502f73f7110101c70600'
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02502f73f7000001c3110002502f73f7aaaaaa41110102502f73f7110101c70600'
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02502f73f7aaaaaa41110102502f73f7110101c70600'
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'02502f73f7110101c70600'
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2019-10-07 00:02:42 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 4
I’m going to add to this discussion…
I just setup my iolinc on my garage and the sensor is showing up as a switch in HA.
When the sensor is closed, the “sensor switch” in HA turns off but the actual relay switch in the front end also turns off. Nothing happens with the physical device but they are mirrored in the front end when the sensor changes.
I am in the process of switching to using Home Assistant thanks to Insteon going belly up. I have 37 devices all set up and they all seem to work so far, except the “sensor” part of the I/O Linc. I rigged up my own garage door opener using the I/O Linc and it worked fine with the hub.
But HA is not changing sensor status. It only ever says closed. Should this be fixed in my Synology HA integration? (Refreshing the page doesn’t change the status)
… time passes …
Here is what is in the configuration.yaml (as far as I can figure out):
{
"address": "41f1d7",
"cat": 7,
"subcat": 0,
"firmware": 0,
"engine_version": 2,
"aldb_status": 1,
"aldb": {
"4095": {
"memory": 4095,
"in_use": true,
"controller": true,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 1,
"target": "2ad4ad",
"data1": 3,
"data2": 0,
"data3": 0
},
"4087": {
"memory": 4087,
"in_use": true,
"controller": false,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 7,
"target": "2ad4ad",
"data1": 0,
"data2": 0,
"data3": 0
},
"4079": {
"memory": 4079,
"in_use": true,
"controller": false,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 6,
"target": "3f4873",
"data1": 0,
"data2": 0,
"data3": 0
},
"4063": {
"memory": 4063,
"in_use": true,
"controller": true,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 1,
"target": "49e167",
"data1": 3,
"data2": 0,
"data3": 0
},
"4055": {
"memory": 4055,
"in_use": true,
"controller": false,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 0,
"target": "49e167",
"data1": 0,
"data2": 0,
"data3": 0
},
"4047": {
"memory": 4047,
"in_use": true,
"controller": false,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 24,
"target": "49e167",
"data1": 0,
"data2": 0,
"data3": 0
},
"4039": {
"memory": 4039,
"in_use": true,
"controller": false,
"high_water_mark": false,
"bit5": true,
"bit4": false,
"group": 1,
"target": "49e167",
"data1": 0,
"data2": 0,
"data3": 0
},
"4031": {
"memory": 4031,
"in_use": false,
"controller": false,
"high_water_mark": true,
"bit5": false,
"bit4": false,
"group": 0,
"target": "000000",
"data1": 0,
"data2": 0,
"data3": 0
}
},
"operating_flags": {
"program_lock_on": false,
"blink_on_tx_on": true,
"relay_on_sense_on": false,
"momentary_on": true,
"momentary_on_off_trigger": false,
"x10_off": false,
"sense_sends_off": false,
"momentary_follow_sense": true
},
"properties": {
"prescaler": 1,
"delay": 20,
"x10_house": 32,
"x10_unit": 0
}
I’m wondering about these parts:
"operating_flags": {
"program_lock_on": false,
"blink_on_tx_on": true,
"relay_on_sense_on": false, <====?
"momentary_on": true,
"momentary_on_off_trigger": false, <===?
"x10_off": false,
"sense_sends_off": false, <====?
"momentary_follow_sense": true
Your config looks fine. Looks like you have a typical setup for a momentary delay of the relay at 2 second delay. The ALDB looks OK except I don’t see a group 0 entry. This should not cause the issue identified here but have you tried to add the default links?
What are “default links”?
… time passes …
After another forum member talked about using his I/O Linc, I took a closer look at my setup. I did my own “garage opener” by hooking up a magnet on the door and hooking the I/O Linc to a remote a disassembled so the I/O Linc could signal a press.
I was going to check the wire for continuity at the I/O Linc, but I noticed that the magnet wasn’t EXACTLY lined up with the alarm sensor I used. As soon as I lined it up, the HA status changed when the door opened and closed.
Only problem is that it is still saying Open when Closed and vice versa. I’m guessing that the version if HA I’m using in a Docker on my Synology box is the one before that was fixed. I wonder what else is old on what I have.
Still, I’d like to know what you meant by default links.
These are links between the modem and the device that aid in the proper use of the device. The Hub app never worried about these because the Hub App always queried the device every time it wanted to know the status rather than relying on the notifications from the device to keep the status updated. In Home Assistant the device is only queried once at startup and then after that it keeps the status by listening for messages from the device. At any rate, you an add default links for the device with the following steps:
Developer Tools from the side menu.Services tab at the top of the page.Service selection box select Insteon: Add default links.entity box enter the name of any Insteon entity such as switch.i_o_linc_1a_2b_3c_relay
Call Service button.The service will run in the background. This will update the ALDB to have a set of “standard” links between the modem and the device. If any of your device statuses are not reflected correctly in HA., this is usually the first thing to try.
Great to hear 
I’ll give it a try. Thanks.