That is what I thought has to be done, but with the hass.io image I do not have to enter anything… everything is just starting up automatically for me… I do not know how the resin and docker containers start within the hass.io image. The only thing I see is the run.sh script which appears to be for enabling the ssh. I looked through the other directories for a start script of some sort but am unable to find one.
When I run dmesg | grep USB I can see that /dev/ttyUSB0 exists and it is the Insteon PLM because for some reason it actually worked a couple of times, with some Insteon devices showing up in Home Assistant. But most of the time it does not…
Did you pair the devices both directions? i.e. turn on pairing at the modem, then the item. Then reverse it - turn on pairing on the item, them the modem. If you skip the second step, the modem isn’t notified of state changes.
Any updates on a solution / anyone resolve their insteon plm setup?
I just upgraded from the insteon hub to plm and updated to HASSIO at the same time. I’m a total noob with docker, so please be patient. Like others I’m running the all-in-one HASSIO install on a raspberry pi which auto-starts the Docker and HA instances.
I was able to get the devices to appear in the HA control page (breadcrumbs for others following: install Insteon HouseLinc, update the devices.xml file to be able to register the plm, then use that to register/pair all your insteon devices with the plm) but as reported above, I can only see the device status from when I first restart HASSIO and cannot control anything from HA. I am able to control the devices using HouseLinc, so I don’t believe it’s a device pairing problem. I couldn’t find where to add the --device=/dev/ttyUSB0 command in any kind of startup file. I see /dev/tty listed in the dev folder when I log into the SSH console, but there’s no /dev/ttyUSB* listing. I tried the $ curl -d ‘{“devices”: [“ttyUSB0”]}’ http://172.17.0.2/homeassistant/options' instructions I found in a different post but it doesn’t seem to have made any difference.
If it helps, I have to following error in the HA logs, which I hope is related to the missing ttyUSB device:
2017-11-13 00:00:02 INFO (MainThread) [insteonplm.protocol] Requesting Next ALL-Link Record
2017-11-13 00:00:02 ERROR (MainThread) [homeassistant.components.light] Error while setting up platform insteon_plm
Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/homeassistant/helpers/entity_component.py”, line 170, in _async_setup_platform
SLOW_SETUP_MAX_WAIT, loop=self.hass.loop)
File “/usr/lib/python3.6/asyncio/tasks.py”, line 352, in wait_for
return fut.result()
File “/usr/lib/python3.6/asyncio/futures.py”, line 244, in result
raise self._exception
File “/usr/lib/python3.6/asyncio/tasks.py”, line 179, in _step
result = coro.send(None)
File “/usr/lib/python3.6/asyncio/coroutines.py”, line 210, in coro
res = func(*args, **kw)
File “/usr/lib/python3.6/site-packages/homeassistant/components/light/insteon_plm.py”, line 28, in async_setup_platform
for device in discovery_info:
TypeError: ‘NoneType’ object is not iterable
So I gave up and reverted to Hassbian (from Hass.io), but still encountered numerous issues with insteon_plm not working. After several frustrating hours of troubleshooting, I was able to narrow the issue to messages not being processed by the underlying insteonplm library (that the insteon_plm component is built on), which lead me to this thread: Insteon_plm queue does not empty after timeout - #5 by TD22057
I added the timeout options @Grant10k mentioned and everything started working! The code does need a few extra lines (including the time library, declaring the _wait_time variable setting the start time, etc) than what’s available in the post for it to work correctly. I occasionally get the lockup with orphaned commands, but with this change they automatically clear after a minute and I have full control again. I’m still working on getting a few more things working on my end (like why does every insteon module appear as a plug-in dimmer when I don’t have any!?) but I’m much happier and further along than where I was 2 weeks ago.
Not sure if you have the same access to the insteonplm library on Hass.io, but this is likely the fix you need. I wonder if this is due to the far off devices I have in my detached garage dropping packets (which I get notified about when doing insteon diagnostics).
For anyone experiencing the “TypeError: ‘NoneType’ object is not iterable” error I had, this was due to the light / switch insteon_plm.py code attempting to iterate through the “discovery_info” value while it was set to “None” adding the following code before that loop traps the error:
if discovery_info is None:
_LOGGER.info(“discovery_info is None”)
else:
Just so you are all aware, insteon_plm has been significantly updated in version 0.65.0 of HA. It fixes a lot of issues including much better auto discovery and the issue of hanging when the network is chatty. It also introduces FanLinc, SmokeBridge and I/O linc support. Working now on KeypadLinc and Thermostat.
I’m still having a lot of issues making this work reliably using the USB PLM. I have 5 leak detectors and one 2477 switch. I got everything linked up both ways and made progress when I forced the devices to be discovered by using the device_override command in my configuration, listing all the Insteon addresses, their categories and subcategories… When I reboot, sometimes devices show up, sometimes they don’t. It’s frustrating to say the least. Anyone have the same experience? I’m running version 0.65.4 right now.
All my Insteon items are working with this update! (At least the ones I previously added, have not tried six button switches yet). I have dimmers, light switches, door sensors, leak detector, motion sensors, outlet lincs. The difference is that some of my light switches that used to show up as lights are now showing up as switches, so they no longer work with my emulated Hue component. So I can’t ask Google to turn them on off anymore… I have not overrode any of the devices, because the switches are showing up as the correct devices even though that is not as a light… maybe there will be a component update to make light switches “lights” vice “switches.” Thanks for the update teharris1!!
I had trouble previously with the PLM not being detected by RPi USB port on Hassio, and I reset all my devices to clear out the device(s) memory and relinked from scratch. Things worked good after that… linking in both directions has given me both control and status updates from the device. I have 2477S and 2477D both being detected and working.
@Madelinot sorry this is causing you issues. Happy to see if we can figure it out. Here are a few questions:
In your HA config directory, you should see a file called insteon_plm_device_info.dat. Can you confirm it is there. This file stores the device cat and subcat so the component does not need to query each time it restarts. Hopefully you are not deleting it in between restarts each time.
Can you cut and paste your insteonplm configuration?
If you put the component in debug mode you should see at least 12 lines (two for each device) that look something like this: 2018-03-12 18:08:50 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x00, 'address': 14.62.7A, 'linkdata1': 0x01, 'linkdata2': 0x00, 'linkdata3': 0x00}. This is the ALDB dump. Please confirm the content of these messages is what you would expect.
The only way I can think that the situation you are describing could occur is if an insteon message comes in while the component is reading the PLM All-Link database. I am working on a fix for that. But that has only happened to me once in a few dozen restarts and I have about 30 devices. With only 6 devices it should not take more than 30 seconds to read the ALDB so the window for this error to occur is pretty small for you.
@tbandzul Thanks for the input. I did make a decision during the refactoring to classify dimmable devices (i.e. cat 0x01) as lights and non-dimmable (0x02) as switches. Of course this is arbitrary but make sense to me since only a light is reasonably dimmable but anything could be on a switch. The prior code allowed you to change the platform which technically would allow you to make a motion detector a light. Obviously not a good idea but also unlikely to happen. Anyway, if you really want to reclassify your switches as lights just override the cat and subcat. Just know that the result will be HA thinking that the switch is dimmable, which it is not. If you tried to set the value of the switch via the slider in the entity card you will receive a runtime error that on_level is not an available method. As long as you keep to the on/off switch in HA you would be fine.
That said, I did not think about the scenario you raise. How important is this to you? It also feels very limiting for emulated Hue to only work on lights. I could add an option to allow cat 0x02 devices to be seen as lights vs switches (you would be the second person to say that is what you want) but I don’t want to make it wide open like the prior code. Also note that devices like the I/O Linc would then be a light which would make no sense either. Welcome any ideas you may have.
@teharris1 I understand your design decision. I have about 20 lights using insteon “switches” and only 4 dimmer switches. I have a few lamps on outlet lincs and a couple lamps on those plugin appliance modules… so most of my usage is for lights. But I do have two switches running bathroom fans as well. I use the six button switches at the doors leaving the house in order to have an “All Off” button, but the main button is controlling the outside lights on each. So from Google Home I would just say “Turn out the lights” when I left the house, but I can push the All off button. So not the end of the world.
As for my priority, I like the fact that so far all my devices are showing up consistently, and my automation’s using the motion sensors and door sensors are working consistently as well… that is what is important to me. I have wall tablets as well using the hadaemon dashboard, and having the insteon devices always being online is nice as well, previously it was hit or miss if the connection was lost. So having a consistent connection to the PLM and thus the insteon devices is the most important item to me as then I know when I go to control a device from any controller it is going to work. When I would make changes that required a restart of HA, or even configurations, sometimes the insteon component would NOT come back, or sometimes it would just stop working and I would have to try restarting HA many times until it would start correctly… that was frustrating as most of my house is insteon. So I do appreciate you “fixing / refactoring” the code… I had started switching lights to z-wave because it was so frustrating.
So short answer, the voice control is a novelty, but the automation’s are what is important. I like the new Light group in HA, I have not tried it yet, but assume I cannot group the switches with it. If I could use the current group button, but hide all the individual switches in the group that would be good. Does the insteon protocol have an “all off” command like the old X-10 protocol had that you could somehow create an API call/ switch for that we could hook up in the HA front end? Then I could call “All off” from my tablets via hadaemon dashboard without having to create a big script.
The key one is insteonplm: debug.
What is your OS? Are you virtualized or physical? I have worked with a few people where it turned out the USB port was the issue. The answer was to rebuild the operating environment to get more consistent port communication.
FYI, I used the USB stick 2448A7. Is that what you are using?
@teharris1 I’m running the latest version of HASSio on a brand new Raspberry Pi. The PLM is also new.
But there is definitely something wrong. Yesterday and this morning, 3 out of 5 leak sensors decided they were wet. The front end of HASS is showing me they are wet, but of course, they are dry. I did not touch anything during this time, and did not reboot yet. I will add the logger and reboot now.
Without touching anything other than adding the logger in configuration.yaml, I rebooted. All devices are now seen as dry. My log is too big to be pasted here as a whole. This is part 1:
2018-03-17 08:34:53 INFO (MainThread) [homeassistant.components.insteon_plm] Looking for PLM on /dev/ttyUSB0
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.connection] Connecting to PLM on /dev/ttyUSB0
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 4038bb cat is 16
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 4038bb subcat is 8
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 2857be cat is 16
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 2857be subcat is 8
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 284f3d cat is 16
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 284f3d subcat is 8
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 2d60ac cat is 16
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 2d60ac subcat is 8
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 403ffc cat is 16
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 403ffc subcat is 8
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 237d6e cat is 2
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.aldb] New override for 237d6e subcat is 42
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.aldb] Added new callback <function async_setup.<locals>.async_plm_new_device at 0x73c63078>
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.plm] Connection established to PLM
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Found 0 saved devices
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Starting: _get_plm_info
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.plm] Requesting PLM Info
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Starting: send_msg
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Ending: send_msg
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Ending: _get_plm_info
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Starting: _load_all_link_database
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Starting: _get_first_all_link_record
2018-03-17 08:34:53 INFO (MainThread) [insteonplm.plm] Requesting ALL-Link Records
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Starting: send_msg
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Ending: send_msg
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Ending: _get_first_all_link_record
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Ending: _load_all_link_database
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Starting _get_from_send_queue
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Aquiring write lock
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] True
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x60, 'address': 00.00.00, 'category': None, 'subcategory': None, 'firmware': None, 'acknak': None}
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Starting _get_from_send_queue
2018-03-17 08:34:53 DEBUG (MainThread) [insteonplm.plm] Ending _get_from_send_queue
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Received 9 bytes from PLM: b'026049f8ee03159e06'
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'026049f8ee03159e06'
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Starting: _peel_messages_from_buffer
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Finishing: _peel_messages_from_buffer
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x60, 'address': 49.F8.EE, 'category': 0x03, 'subcategory': 0x15, 'firmware': 0x9e, 'acknak': 0x06}
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Calling method <function PLM._handle_get_plm_info at 0x73350780>
2018-03-17 08:34:54 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2018-03-17 08:34:55 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-03-17 08:34:55 DEBUG (MainThread) [insteonplm.plm] Starting _handle_get_plm_info
2018-03-17 08:34:55 DEBUG (MainThread) [insteonplm.plm] Ending _handle_get_plm_info
2018-03-17 08:34:55 DEBUG (MainThread) [insteonplm.plm] True
2018-03-17 08:34:55 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x69, 'acknak': None}
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Received 13 bytes from PLM: b'0269060257a2fb403ffc100844'
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'0269060257a2fb403ffc100844'
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Starting: _peel_messages_from_buffer
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Finishing: _peel_messages_from_buffer
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 2
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x69, 'acknak': 0x06}
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] No callback found for message {'code': 0x69, 'acknak': 0x06}
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0xfb, 'address': 40.3F.FC, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x44}
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Calling method <function PLM._handle_all_link_record_response at 0x733506a8>
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Starting _handle_all_link_record_response
2018-03-17 08:34:56 INFO (MainThread) [insteonplm.plm] Found all link record for device 403ffc
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Product data: address 403ffc cat: 10 subcat: 08 product_key: 44
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.devices.devicebase] Registering DeviceBase._receive_message callbacks for device 40.3F.FC
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.aldb] New INSTEON Device '403ffc': Water Leak Sensor (10:08)
2018-03-17 08:34:56 INFO (MainThread) [homeassistant.components.insteon_plm] New INSTEON PLM device: 403ffc (leakSensor) binary_sensor
2018-03-17 08:34:56 INFO (MainThread) [insteonplm.plm] Device with id 403ffc added to device list from ALDB data.
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Starting: _get_next_all_link_recor
2018-03-17 08:34:56 INFO (MainThread) [insteonplm.plm] Requesting Next All-Link Record
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Starting: send_msg
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Ending: send_msg
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Ending: _get_next_all_link_recor
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Ending _handle_all_link_record_response
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] True
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x6a, 'acknak': None}
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Starting _get_from_send_queue
2018-03-17 08:34:56 DEBUG (MainThread) [insteonplm.plm] Ending _get_from_send_queue
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Received 13 bytes from PLM: b'026a060257a2012d60ac100841'
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'026a060257a2012d60ac100841'
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Starting: _peel_messages_from_buffer
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Finishing: _peel_messages_from_buffer
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 2
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] No callback found for message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0x01, 'address': 2D.60.AC, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Calling method <function PLM._handle_all_link_record_response at 0x733506a8>
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Starting _handle_all_link_record_response
2018-03-17 08:34:57 INFO (MainThread) [insteonplm.plm] Found all link record for device 2d60ac
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Product data: address 2d60ac cat: 10 subcat: 08 product_key: 41
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.devices.devicebase] Registering DeviceBase._receive_message callbacks for device 2D.60.AC
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.aldb] New INSTEON Device '2d60ac': Water Leak Sensor (10:08)
2018-03-17 08:34:57 INFO (MainThread) [homeassistant.components.insteon_plm] New INSTEON PLM device: 2d60ac (leakSensor) binary_sensor
2018-03-17 08:34:57 INFO (MainThread) [insteonplm.plm] Device with id 2d60ac added to device list from ALDB data.
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Starting: _get_next_all_link_recor
2018-03-17 08:34:57 INFO (MainThread) [insteonplm.plm] Requesting Next All-Link Record
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Starting: send_msg
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Ending: send_msg
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Ending: _get_next_all_link_recor
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Ending _handle_all_link_record_response
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] True
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x6a, 'acknak': None}
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Starting _get_from_send_queue
2018-03-17 08:34:57 DEBUG (MainThread) [insteonplm.plm] Ending _get_from_send_queue
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Received 13 bytes from PLM: b'026a060257e2012857be100841'
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'026a060257e2012857be100841'
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Starting: _peel_messages_from_buffer
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Finishing: _peel_messages_from_buffer
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 2
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] No callback found for message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x01, 'address': 28.57.BE, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Calling method <function PLM._handle_all_link_record_response at 0x733506a8>
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Starting _handle_all_link_record_response
2018-03-17 08:34:58 INFO (MainThread) [insteonplm.plm] Found all link record for device 2857be
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Product data: address 2857be cat: 10 subcat: 08 product_key: 41
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.devices.devicebase] Registering DeviceBase._receive_message callbacks for device 28.57.BE
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.aldb] New INSTEON Device '2857be': Water Leak Sensor (10:08)
2018-03-17 08:34:58 INFO (MainThread) [homeassistant.components.insteon_plm] New INSTEON PLM device: 2857be (leakSensor) binary_sensor
2018-03-17 08:34:58 INFO (MainThread) [insteonplm.plm] Device with id 2857be added to device list from ALDB data.
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Starting: _get_next_all_link_recor
2018-03-17 08:34:58 INFO (MainThread) [insteonplm.plm] Requesting Next All-Link Record
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Starting: send_msg
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Ending: send_msg
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Ending: _get_next_all_link_recor
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Ending _handle_all_link_record_response
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] True
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x6a, 'acknak': None}
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Starting _get_from_send_queue
2018-03-17 08:34:58 DEBUG (MainThread) [insteonplm.plm] Ending _get_from_send_queue
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Received 13 bytes from PLM: b'026a060257a2fb2857be100841'
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'026a060257a2fb2857be100841'
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Starting: _peel_messages_from_buffer
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Finishing: _peel_messages_from_buffer
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 2
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] No callback found for message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xa2, 'group': 0xfb, 'address': 28.57.BE, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x41}
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Calling method <function PLM._handle_all_link_record_response at 0x733506a8>
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Starting _handle_all_link_record_response
2018-03-17 08:34:59 INFO (MainThread) [insteonplm.plm] Found all link record for device 2857be
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Starting: _get_next_all_link_recor
2018-03-17 08:34:59 INFO (MainThread) [insteonplm.plm] Requesting Next All-Link Record
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Starting: send_msg
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Ending: send_msg
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Ending: _get_next_all_link_recor
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Ending _handle_all_link_record_response
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] True
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x6a, 'acknak': None}
2018-03-17 08:34:59 DEBUG (MainThread) [homeassistant.components.binary_sensor.insteon_plm] Adding device 403ffc entity leakSensor to Binary Sensor platform
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Starting _get_from_send_queue
2018-03-17 08:34:59 DEBUG (MainThread) [insteonplm.plm] Ending _get_from_send_queue
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Received 13 bytes from PLM: b'026a060257e2014038bb100844'
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'026a060257e2014038bb100844'
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Starting: _peel_messages_from_buffer
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Finishing: _peel_messages_from_buffer
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 2
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] No callback found for message {'code': 0x6a, 'acknak': 0x06}
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Processing message {'code': 0x57, 'controlFlags': 0xe2, 'group': 0x01, 'address': 40.38.BB, 'linkdata1': 0x10, 'linkdata2': 0x08, 'linkdata3': 0x44}
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Calling method <function PLM._handle_all_link_record_response at 0x733506a8>
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-03-17 08:35:00 DEBUG (MainThread) [homeassistant.components.binary_sensor.insteon_plm] Adding device 2857be entity leakSensor to Binary Sensor platform
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Starting _handle_all_link_record_response
2018-03-17 08:35:00 INFO (MainThread) [insteonplm.plm] Found all link record for device 4038bb
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Product data: address 4038bb cat: 10 subcat: 08 product_key: 44
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.devices.devicebase] Registering DeviceBase._receive_message callbacks for device 40.38.BB
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.aldb] New INSTEON Device '4038bb': Water Leak Sensor (10:08)
2018-03-17 08:35:00 INFO (MainThread) [homeassistant.components.insteon_plm] New INSTEON PLM device: 4038bb (leakSensor) binary_sensor
2018-03-17 08:35:00 INFO (MainThread) [insteonplm.plm] Device with id 4038bb added to device list from ALDB data.
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Starting: _get_next_all_link_recor
2018-03-17 08:35:00 INFO (MainThread) [insteonplm.plm] Requesting Next All-Link Record
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Starting: send_msg
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Ending: send_msg
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Ending: _get_next_all_link_recor
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Ending _handle_all_link_record_response
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] True
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.plm] Writing message: {'code': 0x6a, 'acknak': None}
2018-03-17 08:35:00 DEBUG (MainThread) [insteonplm.states.stateBase] Registered callback for state: leakSensor
I won’t be able to look at this until tonight but let it run overnight and post the remaining log tomorrow if you can. Regarding the devices going to ‘off’, this is because they are battery operated and there is no way to query them. You have to wait for them to send an update. They send updates at least once per day which is why I need tomorrow’s log.
First all the positive stuff from the latest changes:
I’m certainly glad to see work on the Insteon PLM components. I wasn’t quite so glad at first when I read the release notes after almost all my Insteon components broke, but I’ve got almost everything working with device overrides in the new form. (I had had to override all my wireless device definitions, since they were showing up as whatever device was relaying them to the PLM at the time. So, e.g., a motion detector would show up as an outdoor on/off modules if the closest dual band device to it was an on/off module.)
Anyway, reliability seems better now. I don’t have to do 2 or three resets in a row every so often to get most devices to show up. (And the devices on circuits with way too much noise are a little more usable as well.)
Now the problem:
Here’s the thing I haven’t got sorted out yet – my wireless motion sensors just appear as red circles with dashes and labeled with the insteon address. The device history appears as “Unknown”. If I override with cat: 0x10 and subcat 0x16, the result is the same. (I got the cat and subcat from the motion sensor manual, so I assume that those are right . . .) The wireless leak detector seems to show up as expected.
Here’s what I put in the configutation file “insteon_plm” section for my wireless sensors:
(Hopefully I figured out the code block syntax for this form, if not, I’m sorry, it’s my “first day on the job”.)
# - address: 45FAA8 # Insteon motion sensor Back Door
# cat: 0x10
# subcat: 0x16
- address: 321D21 #Insteon leak detector
cat: 0x10
subcat: 0x08 # 915MHz RF frequency
# - address: 4168CB # Insteon motion sensor Front Door
# cat: 0x10
# subcat: 0x16
I’ve tried it with and without the motion sensor entries commented out.
Any ideas?
Thanks again for the continued work on Insteon PLM