Insteon_PLM on Hass.io, Anyone have it working?

Installation Home Assistant OS
61

@tbandzul Questions about the logs you uploaded:

  • There are 24 devices listed here. Is that all of the devices you expected?
  • When you say leak sensor is not working can you describe what the issue is? I can see that the leak sensor 2D.F9.22 is sending a ‘wet’ message. Are you saying it is not showing as ‘wet’?
  • When you say open/close sensor is not working can you describe what the issue is? I see this one is also sending an ‘open’ message and a ‘closed’ message. Do they register in HA? (This one I assume is you are looking for a binary_sensor but are getting a sensor, correct?)

The insteon_plm_device__info.dat file is saved after each load so it would appear to be ‘new’ but is not. So that does not concern me.

62

@tbandzul So I see the issue with the leak sensor. The underlying library is not processing the message correctly because it is looking for a different message flag. Easy change. I already made it in the base library and just need to push it to HA. Not sure of the release timing yet. I already made the open/close a binary sensor so you should see that in the next update.

63

@teharris1 I looked at my configuration file, and I think that 24 devices is all that I linked after I reset my PLM. So I think it is correct now. 24 devices keep coming back on restart of hassio, whereas before it was between 1 and 16. (This is why I thought that the file was not being retained, as why would it not still contain 24 devices even though only one was reported?) Whatever the issue was, it seems to have corrected itself. I will add more devices to see if they show up.

The Leak sensor is registering, but NEVER showing wet on HA (plm). I was putting it in water and the hub I have was showing wet and sending me a notification.

The open/close sensor now register as sensor.13e310 and stays in the “unknown” state. In version 0.65.0 it registered as binary_sensor.13e310 and sent out “on” and “off.” That is what I set in the HA automations anyway, which triggered the automations I created.

So if you fixed both the sensor problems I am good!

64

@teharris1 I have a general question on insteon that you may be able to answer. I have a three way switch setup. If I turn the light on from the switch connected to the light directly, the switch sends(?) a report saying it is on. If I turn the switch on as a responder to another insteon device (controller), it goes on, but it does not seem to report it is on (I don’t see a message going out of device)… thus HA does not know it is on. I have four sets of these three way switch configurations, and none of the “responders” report when turned on from another controller switch. Does this mean that the status in Home Assistant is just a reflection of the command for the device? Do the devices actually have a status report? Or does the Insteon component just use the “optimistic” mode?

Would the same apply for a Motion sensor linked to a light switch? The motion sensor turns on a light, but there is no report from the light?

thanks, Terry

65

@tbandzul I have just pushed a change that should address the leak sensor and the open/close sensor as well as increase the reliability of the devices loading.

Very confusing that all of the devices are now loading because I didn’t change anything that would have effected it and it doesn’t look like hassio has had a release in over a week.

66

@tbandzul The ‘feature’ you are requesting is something I am working on but it is tough for a bunch of reasons. Here is the link to an enhancement request for exactly what you are looking for:


The way Insteon works is way more complex than generally understood but it also has a great deal of flexibility and some really cool features if you know how to use them. So here goes:
When you link two devices, the controller (e.g. 1A.2B.3C) defines a ‘link group’ which usually corresponds to a button number. Single button devices use group 0x01 but the mini-remote, for example, has buttons 0x01 - 0x08. The responder (e.g. 4D.5E.6F) registers an link in it’s all-link database to respond to device 1A.2B.3C group 0x01. Now the two are linked but only for that group. When you trigger device 1A.2B.3C button 0x01 it sends a broadcast message to the network. When 4D.5E.6F sees a broadcast message from 1A.2B.3C for group 0x01 it turns on or off or, even to a specific level, depending on how the link is defined. All devices in the network see that same message but only devices with the link for that controller and that group respond to the command.

The PLM only sees the broadcast message. It does not see what devices are linked to that controller and group. What is required for HA to know about these changes is for it to know the All-Link database of every device. This is easier said than done. I am working on this and hope to have it in a few months (yes, it is months of work).

There is a work around. If you set up two scenes in HA you can mimic the feature you are looking for. Scene 1 has both devices ‘on’ and Scene two has both devices ‘off’. Then you set up two automations that are triggered when either switch is turned on it triggers Scene 1 and when either switch is turned off it triggers Scene 2.

For some more information, when a responder joins the ‘link group’ it memorizes the state it is in when the link occurs. For example, if your mini-remote is the controller and you set a dimmer to 50% then link the dimmer to the mini-remote button A, pressing button A will change the dimmer to 50% brightness because that was the brightness at the time the link occurred. This allows you to set scenes via Insteon technology. You can do some pretty cool stuff with that like set your thermostat to 72 deg with a KeyPad button, or set a movie scene in your basement with a double tap of a single switch to dim 4 lights at the same time.

67

Thanks for the information! I was trying to find information on my devices, or even the latest insteon ICD. I found an old one, but hard to interpret. From what I read though, I thought that some insteon devices could send a status report. (Not sure if the ones I have can or not) If they can send status, when do they send it? Or does the status have to be requested / polled from the device?

68

Status reporting is both a push and a pull with Insteon. Battery operated devices are generally push only. So your door and leak sensors will not respond to a status request because in between sending messages they go to sleep to conserve battery. Wired switches will respond to a status request. When HA starts I query devices that are wired but not devices that are battery operated. That is why you can get the on/off status of a wall switch but not your door sensor on startup.

69

So that was just bad code on my part and will be fixed in the next release. The code itself does no harm since it only logs a message. What this means though is that you have a device linked to your PLM that I don’t have programmed. For example, this would happen with a thermostat. Can you send me the line before this error that says something like:
2018-04-04 21:32:08 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x50, 'address': 46.2F.24, 'target': 01.41.45, 'flags': 0x8f, 'cmd1': 0x01, 'cmd2': 0x80}
Look for the previous line with cmd1: 0x01. The important field is the three digits following target.

This could explain some devices not showing up in HA.

70

Here is what I have in my logs:

    Line 37: 2018-04-06 06:52:51 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x60, 'address': 49.F8.EE, 'category': 0x03, 'subcategory': 0x15, 'firmware': 0x9e, 'acknak': 0x06}
	Line 50: 2018-04-06 06:52:52 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x69, 'acknak': 0x06}
	Line 52: 2018-04-06 06:52:52 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0xfb, 'address': 40.3F.FC, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x44}
	Line 74: 2018-04-06 06:52:53 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 76: 2018-04-06 06:52:53 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0x01, 'address': 2D.60.AC, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
	Line 98: 2018-04-06 06:52:54 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 100: 2018-04-06 06:52:54 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x01, 'address': 28.57.BE, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
	Line 122: 2018-04-06 06:52:55 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 124: 2018-04-06 06:52:55 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0xfb, 'address': 28.57.BE, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
	Line 142: 2018-04-06 06:52:56 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 144: 2018-04-06 06:52:56 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x01, 'address': 40.38.BB, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x44}
	Line 171: 2018-04-06 06:52:57 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 173: 2018-04-06 06:52:57 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0xfb, 'address': 40.38.BB, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x44}
	Line 191: 2018-04-06 06:52:58 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 193: 2018-04-06 06:52:58 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x01, 'address': 28.4F.3D, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
	Line 215: 2018-04-06 06:52:59 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 217: 2018-04-06 06:52:59 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0xfb, 'address': 28.4F.3D, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
	Line 236: 2018-04-06 06:53:00 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 238: 2018-04-06 06:53:00 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x01, 'address': 23.7D.6E, 'linkdata1': 0x09, 'linkdata2': 0x0b, 'linkdata3': 0x3a}
	Line 260: 2018-04-06 06:53:02 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 262: 2018-04-06 06:53:02 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0xfb, 'address': 23.7D.6E, 'linkdata1': 0x09, 'linkdata2': 0x0b, 'linkdata3': 0x3a}
	Line 279: 2018-04-06 06:53:03 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 281: 2018-04-06 06:53:03 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0x01, 'address': 23.7D.6E, 'linkdata1': 0x09, 'linkdata2': 0x0b, 'linkdata3': 0x3a}
	Line 298: 2018-04-06 06:53:04 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 300: 2018-04-06 06:53:04 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0x01, 'address': 40.3F.FC, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x44}
	Line 317: 2018-04-06 06:53:05 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
	Line 319: 2018-04-06 06:53:05 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x00, 'address': 23.7D.6E, 'linkdata1': 0x01, 'linkdata2': 0x00, 'linkdata3': 0x00}
	Line 336: 2018-04-06 06:53:06 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x15}
    Line 366: 2018-04-06 06:53:06 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x62, 'address': 23.7D.6E, 'flags': 0x00, 'cmd1': 0x19, 'cmd2': 0x00, 'acknak': 0xNone}
	Line 373: 2018-04-06 06:53:07 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x62, 'address': 23.7D.6E, 'flags': 0x00, 'cmd1': 0x19, 'cmd2': 0x00, 'acknak': 0x06}
	Line 374: 2018-04-06 06:53:07 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x50, 'address': 23.7D.6E, 'target': 49.F8.EE, 'flags': 0x20, 'cmd1': 0x13, 'cmd2': 0x00}

The only other line with cmd1 in it is line 366 above. Only one line contains the word “target” (line 374 above). That’s it.

71

I also have this, which seems good:

2018-04-06 06:53:17 DEBUG (MainThread) [homeassistant.components.switch.insteon_plm] Adding device 237d6e entity lightOnOff to Switch platform

and that switch is there in the front end. But since v 0.66.0, none of my leak sensors have showed up in HASS, even after 30+ reboots. Thanks again for your help.

72

Yes, that is the key line that says HA found the device and added it. Do you see anything that looks like this:
2018-04-06 14:14:20 INFO (MainThread) [insteonplm.plm] Device with id 14627a added to device list from ALDB data
The device is added to insteonplm then to HA. The line you highlighted above shows adding to HA. The line I am highlighting here is the device added to insteonplm.

73

Yes, I see this:

	Line 60: 2018-04-06 06:52:52 INFO (MainThread) [insteonplm.plm] Device with id 403ffc added to device list from ALDB data.
	Line 84: 2018-04-06 06:52:53 INFO (MainThread) [insteonplm.plm] Device with id 2d60ac added to device list from ALDB data.
	Line 108: 2018-04-06 06:52:54 INFO (MainThread) [insteonplm.plm] Device with id 2857be added to device list from ALDB data.
	Line 155: 2018-04-06 06:52:56 INFO (MainThread) [insteonplm.plm] Device with id 4038bb added to device list from ALDB data.
	Line 201: 2018-04-06 06:52:58 INFO (MainThread) [insteonplm.plm] Device with id 284f3d added to device list from ALDB data.
	Line 245: 2018-04-06 06:53:00 INFO (MainThread) [insteonplm.plm] Device with id 237d6e added to device list from ALDB data.

They are all there… Only 237d6e shows up in HASS, once in a while, not always.

74

OK, so then it is clear the underlying Insteon library is working. Now the question is why hassio is not registering the device when they show up. The fact that the switch shows up even some of the time indicates it is likely not my code that is causing the issue. It is deeper inside Home Assistant. I will post an issue with hassio to see what could be happening here.

75

I have created a ticket with hassio here:

76

Thanks. Note that the issue has always been there, at least since I installed my PLM about two months ago (not sure which version it was then). As far as I can tell, with version 0.66+, the leak sensors NEVER show up in the front-end.

77

Ah, OK. I will have to change the ticket then to reflect that. Do you know when this was installed? The current code base has been in place since early March. If you performed your install in Feb or Jan it was the old code base.

78

I think it was early March, so likely the new code base… I don’t know what the behavior was before that. Thanks again,

79

I updated HASS to v 0.67.0 and everything seems back to normal. Much more reliable, all my leak sensors now show up.

The update included this:


which seems to have solved the “not-showing-up” issues. I will see if they stay dry now…

Thanks!

80

Should the Insteon Leak sensor (2852-222) be working in home assistant v. 0.69.1? AFAICT, it’s properly linked to the PLM, it’s sitting an a very wet floor right now, and on the home assistant web overview, it shows it’s “DRY”. I don’t see anything weird in the log file . . . what should I be checking?