I moved my Insteon USB PLM over to HA, on a Raspberry Pi running HASSIO. Lovelace will control the lights fine, but often when I turn a light on, it’ll turn right back to off in the interface, but the light itself has turned on.
It takes multiple tries for the switch to sync on the web interface. Has anyone else seen this behavior?
I’m seeing the log file get flooded with this:
2018-09-02 14:19:42 DEBUG (MainThread) [insteonplm.plm] No ACK or NAK message received.
2018-09-02 14:19:42 DEBUG (MainThread) [insteonplm.plm] TX: {‘code’: 0x60, ‘address’: 00.00.00, ‘category’: 0xNone, ‘subcategory’: 0xNone, ‘firmware’: 0xNone, ‘acknak’: 0xNone}
2018-09-02 14:19:42 DEBUG (MainThread) [insteonplm.plm] Waiting for ACK or NAK message
The PLM was migrated from a Indigo instance.
It looks like the PLM is linked as a controller of the device but is not configured as a responder to the device. You can set this up using the following steps in HA
Developer Tools -> Services
insteon.add_all_link.Service Data box enter the following : {"mode": "responder", "group": 1}.Set button on the device.CALL SERVICE buttonI ended up resetting the controller and adding the open/close sensors using Indigo, but just syncing the remainders. I think there were old devices in the controller causing issues.
Now, doing 3 way syncs is a pain in the ass.
Sorry, I am not familiar with Indigo so I am not sure what this line means. Happy to help. Here is what I can tell you, some PLM software designs only link as a controller (one way linking) then they use status updates (aka polling) to maintain state. The insteon component is designed for two way linking so that polling is not needed. It is much faster and is a less chatty network when done this way. But it requires links to be set up correctly. I will soon be releasing code that will automatically set up the correct links but that is a little bit out on the roadmap.
Re-reading your original two messages, it likely is not a linking problem but you may very well be right that resetting the PLM would fix the issue. I would love to see your full log after a clean start if possible.
Seems to be working now. I switched logging to a MariaDB on my QNap.
IndigoDomo is Mac based Insteon automation software. I like its control logic, but its ability to make control screens is terrible so I’m switching over to HAS.
Here’s a snapshot of the logs:
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.devices] Releasing lock after processing direct ACK
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.devices] Calling <bound method OnOffKeypadLed._status_message_received of <insteonplm.states.onOff.OnOffKeypadLed object at 0x720365f0>>
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] OnOffKeypadLed status message received with value 0xc0
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Status message: {'code': 0x50, 'address': 44.C8.00, 'target': 3C.4D.9B, 'flags': 0x22, 'cmd1': 0x02, 'cmd2': 0xc0}
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 1 was off now is off
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] No callbacks found for button 1
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 2 was off now is off
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] No callbacks found for button 2
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 3 was off now is off
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Calling button update callback <bound method OnOffKeypad.led_changed of <insteonplm.states.onOff.OnOffKeypad object at 0x7258bbd0>>
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 3 LED changed from 0 to 0
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 4 was off now is off
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Calling button update callback <bound method OnOffKeypad.led_changed of <insteonplm.states.onOff.OnOffKeypad object at 0x72036f10>>
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 4 LED changed from 0 to 0
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 5 was off now is off
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Calling button update callback <bound method OnOffKeypad.led_changed of <insteonplm.states.onOff.OnOffKeypad object at 0x72036c90>>
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 5 LED changed from 0 to 0
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 6 was off now is off
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Calling button update callback <bound method OnOffKeypad.led_changed of <insteonplm.states.onOff.OnOffKeypad object at 0x720a3f70>>
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 6 LED changed from 0 to 0
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 7 was on now is on
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Calling button update callback <bound method OnOffKeypad.led_changed of <insteonplm.states.onOff.OnOffKeypad object at 0x7277af50>>
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 7 LED changed from 1 to 1
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] Button 8 was on now is on
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.states] No callbacks found for button 8
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.devices] Called <bound method OnOffKeypadLed._status_message_received of <insteonplm.states.onOff.OnOffKeypadLed object at 0x720365f0>>
2018-09-02 17:44:23 DEBUG (MainThread) [insteonplm.devices] Ending Device._wait_for_direct_ACK
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] Starting: data_received
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] Received 11 bytes from PLM: b'025044c8003c4d9b2702c0'
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] Finishing: data_received
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] Total buffer: b'025044c8003c4d9b2702c0'
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] Buffer too short to have a message
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] Messages in queue: 1
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] RX: {'code': 0x50, 'address': 44.C8.00, 'target': 3C.4D.9B, 'flags': 0x27, 'cmd1': 0x02, 'cmd2': 0xc0}
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.devices] Starting Device.receive_message
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.devices] Got Direct ACK message
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.devices] But Direct ACK not expected
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.devices] Ending Device.receive_message
2018-09-02 17:44:25 DEBUG (MainThread) [insteonplm.plm] Last item in self._recv_queue reached.Was the problem you were referring to always with a KeyPadLinc? I have found a few problems with that device when there are a lot of links. This could explain why resetting the All-Link database fixed the issue.
I am having no luck wuth the new Insteon integration and the latest HA .78 just tried today. I have a Hub and here is the errors I am getting:
[insteonplm] Reconnect to Hub (TimeoutError)
I have tired loading the command “insteon.add_all_link” and loading a insteon.add_all_link with a working Insteon switch light.316993 entity.
[homeassistant.components.insteon] Device All-Link database not loaded
2018-09-11 17:00:55 WARNING (SyncWorker_12) [homeassistant.components.insteon] Use service insteon.load_aldb first
Here is my config.yaml entry:
insteon:
host: 192.168.1.111
ip_port: 25105
username: xxxx
password: xxxx
I have a hub listed below:
INSTEON HUB2 Details
Hub2-V04-20140904
PLM Version:A3
Firmware:1017 Build Jul 18 2018 11:21:08
Insteon ID
The issue you are seeing with [insteonplm] Reconnect to Hub (TimeoutError) has nothing to do with linking. It is a communication issue between the hub and HA. It would indicate it connected at some point and then disconnected. When you see the [insteonplm] Reconnect to Hub (TimeoutError) error, do you see this multiple times or does it reconnect at some point? Do you have to restart your hub to reconnect?