I do not know how to use Docker or Resin, and am wondering if anyone has setup an Insteon PLM with Hass.io? The USB ports do not seem to be exposed to the Home Assistant installation… is their a guide on how to achieve this?
thanks,
I am not sure where to add these flags though, ie; where is the docker setup to add the “extra parameters”? I am not able to determine what is the docker container. When looking at the Putty via ssh setup, can I see the docker container?
When you run the command to start the docker, you add this flag, assuming your USB device is at /dev/ttyUSB0
–device=/dev/ttyUSB0
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…
Running the hassio host hardware command I can see the USB port at /dev/ttyUSB0
The database of lights and switches appears to have downloaded from the PLM, and I was able to assign friendly names to the devices.
When I restart Home Assistant the current status of the devices is correctly displayed each time.
I just cannot control the lights and see statuses from the devices in real time, and ideas??
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
Any help is greatly appreciated.
Just wanted to comment that I have the same issue on my hass.io pi3 (although no error messages in the log)
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.
1 Like
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.
@teharris1 … Thanks for trying to help. Here are my answers:
- Yes, the file insteon_plm_device_info.dat is there. I have 5 leak detectors and one 2477 switch. The file seems to contains the proper information:
[ { "address":"403ffc", "cat":16, "subcat":8, "product_key":0 }, { "address":"2d60ac", "cat":16, "subcat":8, "product_key":0 }, { "address":"2857be", "cat":16, "subcat":8, "product_key":0 }, { "address":"4038bb", "cat":16, "subcat":8, "product_key":0 }, { "address":"284f3d", "cat":16, "subcat":8, "product_key":0 }, { "address":"237d6e", "cat":2, "subcat":42, "product_key":0 } ]
- Insteon PLM configuration from configuration.yaml:
insteon_plm: port: /dev/ttyUSB0 device_override: - address: 4038bb cat: 0x10 subcat: 0x08 - address: 2857be cat: 0x10 subcat: 0x08 - address: 284f3d cat: 0x10 subcat: 0x08 - address: 2d60ac cat: 0x10 subcat: 0x08 - address: 403ffc cat: 0x10 subcat: 0x08 - address: 237d6e cat: 0x02 subcat: 0x2a
- How do I enable the debug mode? Where do I find this output?
Thanks!
OK, so the info you provided pretty much narrows it down to 2 things:
- A program issue from startup to completion of the All-Link database or
- the USB port / USB modem is not operating correctly
To setup debugging add the following code to your configuration.yaml file:
logger:
default: warn
logs:
insteonplm: debug
homeassistant.components.insteon_plm: debug
homeassistant.components.light.insteon_plm: debug
homeassistant.components.switch.insteon_plm: debug
homeassistant.components.binary_sensor.insteon_plm: debug
homeassistant.components.sensor.insteon_plm: debug
homeassistant.components.fan.insteon_plm: debug```
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