New Insteon version for beta testing - (Do not use since this is now in 0.111 and higher)

Share your Projects! Custom Integrations
61

Thank you so much … I have HA running in docker, however, missing hassio or supervisor. Guess I’m still missing something…

Update:
Started over and ran the following:

New install

sudo -i
apt-get update
apt-get install -y software-properties-common apparmor-utils apt-transport-https avahi-daemon ca-certificates curl dbus jq network-manager socat
systemctl disable ModemManager
systemctl stop ModemManager
curl -fsSL get.docker.com | sh

curl -sL “https://raw.githubusercontent.com/home-assistant/supervised-installer/master/installer.sh” | bash -s – -m raspberrypi4
docker run homeassistant/raspberrypi4-homeassistant
systemctl restart hassio-supervisor.service

Everything working now … will start on the insteon2 later today.

62

cannot get pyinsteon loaded …
looking at docker my installation is homeassistant/rasberrypi4-homeassistant
modified Dockerfile to reflect this difference …
Docker build -t myinst2 .
Docker run myinst2
this is from the log ……
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/loader.py”, line 391, in _load_file
module = importlib.import_module(path)
File “/usr/local/lib/python3.7/importlib/init.py”, line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File “”, line 1006, in _gcd_import
File “”, line 983, in _find_and_load
File “”, line 967, in _find_and_load_unlocked
File “”, line 677, in _load_unlocked
File “”, line 728, in exec_module
File “”, line 219, in _call_with_frames_removed
File “/config/custom_components/insteon2/init.py”, line 5, in
from pyinsteon import async_close, async_connect, devices
ModuleNotFoundError: No module named ‘pyinsteon’
2020-04-17 14:34:30 ERROR (MainThread) [homeassistant.components.hassio] Component error: insteon2 - Integration ‘insteon2’ not found.

??? … I’m lost … all the custom insteon2 files are populated and I didn’t see anything where the container naming would make a diff

UPDATE:
Ran this:

docker exec -it --user=root homeassistant pip3 install --upgrade https://github.com/teharris1/pyinsteon/archive/release1.zip

didn’t notice the first time I tried this the h was missing in the https: from the example.
Found all my devices … will let you know how it works after my scripts run tonight.

Thanks taharris1 for all you hard work …

63

Working great … google home routines turning on lights update immediately in HA.
The only problem I’m seeing is light scenes executed by insteon are not reflected in HA.
Minor as I can delete this and will reenter as google home routines.
Thanks again …

64

The scenes being reflected in HA are likely and issue with the All-Link databases not being loaded. You can load them by going to “Developer Tools” -> “Services” and selecting “insteon2.load_all_link_database” and use the entity “all”. This will load the ALDB for all entities. This will take about 15 - 30 minutes to complete. After that you should see scenes respond. If you have battery operated devices their ALDB will load after they are triggered next (i.e. wake up) such as opening a door or motion in a motion sensor.

65

quick question for you – how do you manage your databases on your devices (add/remove new or bad links)?

I’ve used the HA services with the insteon2 component to get the modem into link mode… but i have to access each physical device to get them into linking mode.

By chance do you run insteon_terminal in parallel with the HA service? I’ve never tried that… but that would be super powerful

66

Everything working great except for HA not seeing devices turned on/off by MINI Remote 2342-2
Any suggestions?

67

@gm_az – I found it took 2-3 _load_all_link_databases to get a fully copy so HA would keep track of the “cascading state changes”.

I also have 2 or 3 devices that i don’t have proper Controller > Responder and Responder > Controller links done with the modem that I need to circle back and update. You may check that your devices the mini-controller is controlling are setup as controllers to the modem as well.

68

@teharris1 – i know we had a side conversation in a github issue about load_all_link_database persistent notifications to the user… given this need to run it, and likely re-run it (because of insteon network inefficiencies, not the component)… what would your thoughts on scheduling this to run every night during off hours?

I suppose i could do that with an automation – it might be nice if the component could also kick it off for novice users / newcomers so they don’t have to think about it. Curious if you have any concerns about doing that…

69

I did set up the ALDB loading to happen whenever the system restarts IF the devices’ ALDB is not marked “LOADED”. It happens in the background and is not really invasive but it may slow down commands to and from devices; for example, on/off commands. This is only because you add more noise to the network and Insteon is a serial communication protocol, meaning only one message can be on the wire at any one time.

As for running the load_all_link_database service in the background every night, I would say that is probably overkill but not a problem if you felt you needed to do that. The ALDB only changes when you change links between devices so I would say once you have it loaded you should just need to reload after a change.

One of the enhancements I have not put into the current library is the ability to see the ALDB version and if it is different than the stored version it will reload the ALDB. The downside of this is very power failure resets the version back to 0 and so it will look like the version is different. This will cause all devices to reload after the power outage.

70

Yeh – I get that running nightly would be overkill in the long run. I was just trying to figure out how to simplify new onboards. Perhaps just on every service restart would eventually get you there.

Since having run load_all_link_database at least 3 times … plus i recently added a new device part of a “3-way” switch configuration (and subsequently ran load_all_link_database again), the cascading state changes have worked nearly perfectly. Super impressed, well done. I know insteon_mqtt tried to do the same, but i could not get it to be reliable. Possibly/likely because of the database sync issue above… which is why i’m proposing making initial sync’s or even unnecessary long term sync’s a part of the component.

71

Makes sense. Let me think about the idea.

72

Hi All, I have made what I think are the final changes to the solution. I improved start-up and tweaked a bunch of small items like device_overrides and X10 devices. I think it is ready to go but if you all don’t mind reloading the solution and running it for a couple of days each that would be appreciated.

One breaking change for the thermostat is that hvac action (no underscore) is back to hvac_action (with underscore). On further review that is a standard climate platform item so I used that rather than my custom hvac action.

73

upgraded – will report back if there’s anything notable that might block a merge

74

I’ve had Insteon in my home for some time, but have recently started w/HA on an RPI4 - So far so good except for the Insteon integration. Just came across your project, and I have to say I’m excited at the prospect of a well-functioning integration.

I had been using the standard built-in Insteon capability of HA, and was able to get your latest Insteon2 up and running, though I’m seeing some odd behavior and I’m not sure where to start the troubleshooting. I updated using your latest code from 12hrs ago.

I’ve set up the Insteon2 integration and detailed logging in my configuration.yaml (username/password removed below):

# Hub 2245 configuration variables
insteon2:
  host: 192.168.1.251
  ip_port: 25105
  username: ...
  password: ...
logger:
  default: info
  logs:
    pyinsteon.topics: debug
    pyinsteon.messages: debug
    custom_components.insteon2: debug

I’m seeing some inconsistent behavior and I’d like to figure out why. Using the Insteon app, or Insteon/Alexa integration, I get consistent results, but with the old Insteon integration I had issues with it working consistently, and with Insteon2 there seems to be more/different issues.

I have some devices on the far end of the house that seem to have trouble with updates. They work pretty well through the Insteon App, but not so well through HA Insteon nor Insteon2.

Trying to turn the device via HA Insteon2 through the UI I get:

2020-04-28 11:18:44 DEBUG (MainThread) [pyinsteon.topics] Topic: send.on.direct data: {'address': 22cd89, 'on_level': 255, 'group': 1}
2020-04-28 11:18:44 DEBUG (MainThread) [pyinsteon.topics] Topic: send_message.on.direct data: {'msg': msg_id: 0x62, address: 22cd89, flags: 0x00, cmd1: 0x11, cmd2: 0xff, 'priority': 5}
2020-04-28 11:18:44 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x62, address: 22cd89, flags: 0x00, cmd1: 0x11, cmd2: 0xff
2020-04-28 11:18:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 22cd89, flags: 0x00, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2020-04-28 11:18:45 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.22cd89.1.on.direct data: {'cmd1': 17, 'cmd2': 255, 'user_data': None}
2020-04-28 11:18:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0xa6, cmd1: 0x11, cmd2: 0xff
2020-04-28 11:18:45 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.on.direct_nak data: {'cmd1': 17, 'cmd2': 255, 'target': 50ba89, 'user_data': None, 'hops_left': 1}

Turning the device on via the Insteon App, it works, and I see the following in the logs, but the UI doesn’t sync up to show the current state:

2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 22cd89, flags: 0x05, cmd1: 0x13, cmd2: 0x00, ack: 0x06
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.22cd89.1.off.direct data: {'cmd1': 19, 'cmd2': 0, 'user_data': None}
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0xa6, cmd1: 0x13, cmd2: 0x00
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.off.direct_nak data: {'cmd1': 19, 'cmd2': 0, 'target': 50ba89, 'user_data': None, 'hops_left': 1}
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 22cd89, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.22cd89.status_request.direct data: {'cmd1': 25, 'cmd2': 2, 'user_data': None}
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0x26, cmd1: 0x19, cmd2: 0x00
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.status_request.direct_ack data: {'cmd1': 25, 'cmd2': 0, 'target': 50ba89, 'user_data': None, 'hops_left': 1}
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0x22, cmd1: 0x19, cmd2: 0x00
2020-04-28 11:10:45 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.status_request.direct_ack data: {'cmd1': 25, 'cmd2': 0, 'target': 50ba89, 'user_data': None, 'hops_left': 0}
2020-04-28 11:10:47 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0x22, cmd1: 0x19, cmd2: 0x00
2020-04-28 11:10:47 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.status_request.direct_ack data: {'cmd1': 25, 'cmd2': 0, 'target': 50ba89, 'user_data': None, 'hops_left': 0}

Where do I go from here? How else can I troubleshoot? Is this an Insteon2 problem or some other underlying problem (or both)?

75

Based on the log above you turned the device off from the app not on. Is that correct? Can I assume this is a KPL device? The reason I say that is because after the off command is sent by the app I see a direct NAK. This means that the device rejected the off command. This is common with KPL devices due to a database size issue.

76

You’re absolutely right - on both accounts. It is a KPL, but it works near 100% consistently from the App, or Alexa/Insteon integration, but rarely from the HA/Insteon2.

Here’s the “on” from the app:

2020-04-28 13:28:27 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 22cd89, flags: 0x05, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2020-04-28 13:28:27 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.22cd89.1.on.direct data: {'cmd1': 17, 'cmd2': 255, 'user_data': None}
2020-04-28 13:28:27 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0xa1, cmd1: 0x11, cmd2: 0xff
2020-04-28 13:28:27 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.on.direct_nak data: {'cmd1': 17, 'cmd2': 255, 'target': 50ba89, 'user_data': None, 'hops_left': 0}
2020-04-28 13:28:28 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 22cd89, flags: 0x05, cmd1: 0x19, cmd2: 0x02, ack: 0x06
2020-04-28 13:28:28 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.22cd89.status_request.direct data: {'cmd1': 25, 'cmd2': 2, 'user_data': None}
2020-04-28 13:28:28 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0x26, cmd1: 0x19, cmd2: 0xff
2020-04-28 13:28:28 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.status_request.direct_ack data: {'cmd1': 25, 'cmd2': 255, 'target': 50ba89, 'user_data': None, 'hops_left': 1}

Any ideas or ways around getting consistent behavior for KPLs?

77

Let me make sure I have this right.

  1. In the very first example when you turned the KPL on via HA I see that the KPL responded with a Direct NAK. The odd behavior of a KPL is it will respond with a Direct NAK but still respond correctly to the command. Does the KPL turn on/off correctly but HA is not updated or does the KPL not respond at all? I know how to fix this if the KPL does respond by using the same approach as the Hub app is using which is to send a status update request on Direct NAK to see if it responded correctly or not. This makes sense to do to work around this behavior which many KPLs demonstrate.

  2. For the second and third examples above, I see that both the on and off commands from the app are also responded to by the KPL with a Direct NAK followed by a status request. I would expect HA to track the status request and set the state in HA per the status response. Does this happen?

78

Thanks again for the help!

  1. … Does the KPL turn on/off correctly but HA is not updated or does the KPL not respond at all? …

It responds inconsistently, sometimes not at all, sometimes the KPL will turn on, but the UI still shows off, sometimes the KPL will not turn on at all (UI still shows off), and sometimes it works as expected, the KPL and UI show ON.

  1. … I would expect HA to track the status request and set the state in HA per the status response. Does this happen?

No - It seems that when the switch is working consistently, the updates work everywhere, but when it is not working, while I still see the debug logs coming through in HA/pyinsteon, it is not flowing through to the UI.

Example experience when not working:
KPL is OFF & UI shows OFF > Click switch in UI to ON > UI flips to ON for a few seconds, then back to OFF, KPL remains OFF, logs show as above. NOTE: As I sit here testing this, it is inconsistent, sometimes it’s working, other times it’s not.

Example log from not working:

2020-04-28 17:06:44 DEBUG (MainThread) [pyinsteon.topics] Topic: send.on.direct data: {'address': 22cd89, 'on_level': 255, 'group': 1}
2020-04-28 17:06:44 DEBUG (MainThread) [pyinsteon.topics] Topic: send_message.on.direct data: {'msg': msg_id: 0x62, address: 22cd89, flags: 0x00, cmd1: 0x11, cmd2: 0xff, 'priority': 5}
2020-04-28 17:06:44 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x62, address: 22cd89, flags: 0x00, cmd1: 0x11, cmd2: 0xff
2020-04-28 17:06:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 22cd89, flags: 0x00, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2020-04-28 17:06:45 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.22cd89.1.on.direct data: {'cmd1': 17, 'cmd2': 255, 'user_data': None}
2020-04-28 17:06:45 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 22cd89, target: 50ba89, flags: 0xa1, cmd1: 0x11, cmd2: 0xff
2020-04-28 17:06:45 DEBUG (MainThread) [pyinsteon.topics] Topic: 22cd89.on.direct_nak data: {'cmd1': 17, 'cmd2': 255, 'target': 50ba89, 'user_data': None, 'hops_left': 0}

I’ve not yet found a consistent experience and troubleshooting is challenging given the inconsistency, though I’m happy to run through any additional scenarios or get more logs. What is (mostly) consistent is it seems to work better through the App or Alexa integration.

79

@gregp I have created two issues on the Insteon2 site:


We will track the issue there until they are resolved. Thanks for the help. I have asked a few questions there. Can you check them out?

1 Like
80

Will do, thanks!