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

Wes · April 11, 2020, 7:47pm

Hi, I think what you ask was in my first post in this thread.

My Hub and Alexa are working well and the Hub is linked to, and works properly with, all my devices. Because a factory reset of my SmokeBridge had some positive change, I am wondering if a factory reset of the Hub, and setting it up again, might be worth trying.

Wes

teharris1 · April 11, 2020, 8:28pm

Ok, so HA is working with the PLM and the Hub is on the side. In that case, when you did a factory reset of the PLM did you relink all the devices you expect to be in HA? If not, that is the first thing to do. HA will only see devices after they are linked.

HA seeing hub commands and keeping HA updated only works if the Hub is the modem used with HA.

Wes · April 11, 2020, 9:16pm

After I factory reset the PLM I reconnected it to HA and everything that worked before still worked. So either my factory reset failed or relinking happened using the device info already captured in HA (eg aa.bb.cc). The latter would be good if not already in your code so a failed PLM could be replaced with a new one without any hassle.

I manually linked the 2 leak detectors to the PLM (they were not before) and now they show up in the log but I cannot see where they are as entities for use in HA (forgive me for being a bit slow).

Although all devices are on the one Insteon net, there is not a lot of usage overlap between those controlled by HA and those I control with Alexa or the Insteon Android App. It would be nice to see all device status in HA but I have been living without for quite a while. Do you think I should run all through the Hub and retire the PLM or stay with my current setup?

joe2 · April 11, 2020, 9:29pm

From the UI – although I also have some automations that are firing at other times and they are resulting in the same behavior.

Below are logs for me pressing A, B, C, D one at a time. In all 4 cases, the MAIN button on device is turned on instead and the HA keypad switch toggles off after a second.



KEYPAD_A:

2020-04-11 16:24:00 DEBUG (MainThread) [pyinsteon.topics] Topic: send.on.direct data: {'address': 330328, 'on_level': 255, 'group': 1}
2020-04-11 16:24:00 DEBUG (MainThread) [pyinsteon.topics] Topic: send_message.on.direct data: {'msg': msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, 'priority': 5}
2020-04-11 16:24:00 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:00 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2020-04-11 16:24:00 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.330328.1.on.direct data: {'cmd1': 17, 'cmd2': 255, 'user_data': None}
2020-04-11 16:24:01 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 330328, target: 31185b, flags: 0x21, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:01 DEBUG (MainThread) [pyinsteon.topics] Topic: 330328.on.direct_ack data: {'cmd1': 17, 'cmd2': 255, 'target': 31185b, 'user_data': None}
2020-04-11 16:24:01 DEBUG (MainThread) [pyinsteon.topics] Topic: handler.330328.1.on.direct data: {'on_level': 255}





KEYPAD_B:

2020-04-11 16:24:14 DEBUG (MainThread) [pyinsteon.topics] Topic: send.on.direct data: {'address': 330328, 'on_level': 255, 'group': 1}
2020-04-11 16:24:14 DEBUG (MainThread) [pyinsteon.topics] Topic: send_message.on.direct data: {'msg': msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, 'priority': 5}
2020-04-11 16:24:14 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:14 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2020-04-11 16:24:14 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.330328.1.on.direct data: {'cmd1': 17, 'cmd2': 255, 'user_data': None}
2020-04-11 16:24:15 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 330328, target: 31185b, flags: 0x26, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:15 DEBUG (MainThread) [pyinsteon.topics] Topic: 330328.on.direct_ack data: {'cmd1': 17, 'cmd2': 255, 'target': 31185b, 'user_data': None}
2020-04-11 16:24:15 DEBUG (MainThread) [pyinsteon.topics] Topic: handler.330328.1.on.direct data: {'on_level': 255}



KEYPAD_C:

2020-04-11 16:24:25 DEBUG (MainThread) [pyinsteon.topics] Topic: send.on.direct data: {'address': 330328, 'on_level': 255, 'group': 1}
2020-04-11 16:24:25 DEBUG (MainThread) [pyinsteon.topics] Topic: send_message.on.direct data: {'msg': msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, 'priority': 5}
2020-04-11 16:24:25 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:25 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2020-04-11 16:24:25 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.330328.1.on.direct data: {'cmd1': 17, 'cmd2': 255, 'user_data': None}
2020-04-11 16:24:26 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 330328, target: 31185b, flags: 0x21, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:26 DEBUG (MainThread) [pyinsteon.topics] Topic: 330328.on.direct_ack data: {'cmd1': 17, 'cmd2': 255, 'target': 31185b, 'user_data': None}
2020-04-11 16:24:26 DEBUG (MainThread) [pyinsteon.topics] Topic: handler.330328.1.on.direct data: {'on_level': 255}



KEYPAD_D:

2020-04-11 16:24:38 DEBUG (MainThread) [pyinsteon.topics] Topic: send.on.direct data: {'address': 330328, 'on_level': 255, 'group': 1}
2020-04-11 16:24:38 DEBUG (MainThread) [pyinsteon.topics] Topic: send_message.on.direct data: {'msg': msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, 'priority': 5}
2020-04-11 16:24:38 DEBUG (MainThread) [pyinsteon.messages] TX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:38 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x62, address: 330328, flags: 0x00, cmd1: 0x11, cmd2: 0xff, ack: 0x06
2020-04-11 16:24:38 DEBUG (MainThread) [pyinsteon.topics] Topic: ack.330328.1.on.direct data: {'cmd1': 17, 'cmd2': 255, 'user_data': None}
2020-04-11 16:24:39 DEBUG (MainThread) [pyinsteon.messages] RX: msg_id: 0x50, address: 330328, target: 31185b, flags: 0x26, cmd1: 0x11, cmd2: 0xff
2020-04-11 16:24:39 DEBUG (MainThread) [pyinsteon.topics] Topic: 330328.on.direct_ack data: {'cmd1': 17, 'cmd2': 255, 'target': 31185b, 'user_data': None}
2020-04-11 16:24:39 DEBUG (MainThread) [pyinsteon.topics] Topic: handler.330328.1.on.direct data: {'on_level': 255}

teharris1 · April 12, 2020, 12:25am

Ok, I posted an update that fixes that issue. You technically only need to update the switch.py file, everything else is the same.

teharris1 · April 12, 2020, 12:39am

The Insteon device file (either insteon_plm_device_info.dat or insteon_devices.json) beling loaded from the PLM prior to being reset would “fake” the module into thinking that the devices were paired but you may get a lot of weird behavior. Best would be to delete both of those files and restart HA. This will tell you what is actually linked and what is not.

The leak detectors should show up as sensors. If they are properly linked you should see them but if not, then I may have some work to do. If you press the set button once ever 30 seconds for two minutes and it still does not show up then it likely is not going to.

IMO, the PLM is a better device if you have a good number of devices (i.e. more than 25). If you have less than 10 devices the Hub is fine. The Hub is very chatty so it pushes a lot of noise on the wire. The PLM is cleaner. At the same time, if you like this backup option of HA and the Hub app then I would go with the Hub and retire the PLM. Two modems will never see each other’s traffic. So the only way for HA with a PLM and the Insteon App with the Hub to keep in sync is to pole every device for changes on a regular basis. This would add more traffic to the network and therefore cause more delays with devices responding to requests.

doucga · April 12, 2020, 2:56am

My thermostat is set to Fahrenheit. I’ve noticed that my thermostat in HA is now reporting mixed Celsius and Fahrenheit. When the device was originally scanned both the set temperature and the room temperature were reported in Celsius. The set temperature hasn’t been changed since the device was originally scanned but the room temperature has obviously changed and is now reporting in Fahrenheit.

Not sure if this is useful info but thought I’d pass it along.

Garry

teharris1 · April 12, 2020, 11:38am

Thanks Garry. Yes, it is helpful.are Are you using a Hub or a PLM?

joe2 · April 12, 2020, 12:29pm

didn’t seem to work – getting a new error though. I posted the log in an issue over in github as your thread here is getting forked a bunch.

Overall – this is working really well for me, thank you for the new component updates.

Wes · April 12, 2020, 7:07pm

Changed so insteon2 is now connecting via my HUB, I will leave the PLM for backup, connected and linked but not configured in HA. The only error I get now is SmokeBridge related. The error log is repeated below:

2020-04-12 13:59:27 INFO (MainThread) [custom_components.insteon2] Identifying Insteon devices
2020-04-12 14:42:55 ERROR (MainThread) [pyinsteon.utils] An issue occured distributing the following message
2020-04-12 14:42:55 ERROR (MainThread) [pyinsteon.utils] MSG: 025301003ee271100a43
2020-04-12 14:42:55 ERROR (MainThread) [pyinsteon.utils] Topic: all_linking_completed data: {'mode': 0x01, 'group': 0, 'target': 3ee271, 'cat': 0x10, 'subcat': 10, 'firmware': 67}
2020-04-12 14:42:55 ERROR (MainThread) [pyinsteon.utils] Error: 1
2020-04-12 14:42:55 ERROR (MainThread) [pyinsteon.utils]     Subscriber: AllLinkCompletedHandler.handle_response

I think getting the SmokeBridge device working in insteon2 should be a very low priority unless the fault could affect other more widely used devices. As far as I know the SmokeBridge only works with a small class of “First Alert” smoke and CO2 detectors.

I am pleased with insteon2 and plan to keep using it as a custom_component until it appears in mainstream HA. Please let me know if I can help in any way.

Wes

doucga · April 13, 2020, 12:35am

I’m using a PLM.

teharris1 · April 13, 2020, 1:38am

@joe2, Good idea to post the issues to the repo. For all others, here it is:

Posting a fix to the KeyPadLinc button issues. Need to reinstall pyinsteon for those to work.

teharris1 · April 13, 2020, 2:51am

@doucga I posted a change to have the thermostat check F / C on start up so it should know right away what the mode is. Thanks.

teharris1 · April 16, 2020, 2:02am

If you have not refreshed the insteon2 files or the pyinsteon module recently, it may be a good idea to do that. I have made a number of updates in the past few days. There are still a couple of open items which can be tracked on the github repository: https://github.com/teharris1/insteon2/issues

gm_az · April 16, 2020, 1:51pm

Thanks for all your hard work. I just started with HA last week on a PI3 … running good except for Insteon. I was going to test your insteon2 (I have 11 devices), but have searched for days and cannot figure out how to load the pyisteon (running on HassOS). Unless you have a suggestion, I’m going to start over with a PI4 and run HA in docker.

teharris1 · April 16, 2020, 7:27pm

I don’t know much about HassOS. I run in Docker myself so I can help with that.

gm_az · April 16, 2020, 11:12pm

Thanks, I spent all day looking at how to install. I have raspban buster lite installed, ssh, and docker. installed python 3 per instructions. A little confused on docker but it is running. Not sure it I have to create the containers or they are created with new installs like hassio. Have seen many conflicting examples. Tried to install Home Assistant for Pi4 and get Error missing jd … Continuing to search for Docker installations of HA. If you can point in the right direction it would be a great help. May just have to wait for the actual release.

teharris1 · April 17, 2020, 12:14am

Let me assume you can run docker at the command line and get a valid response, here is what I would do:

docker pull homeassistant/home-assistant

docker run -d \
           --name homeassistant \
           -v /path_to_config_dir:/config \
           -v /etc/localtime:/etc/localtime:ro \
           --net=host \
           --restart unless-stopped \
           --device=/dev/ttyUSB0
          homeassistant/home-assistant

You need to replace path_to_config_dir with wherever you want your configuration to be kept (i.e /home/user_name/config) and /dev/ttyUSB0 to wherever your PLM is connected. If you are using a Hub you don’t need the --device parameter obviously.

joe2 · April 17, 2020, 1:25am

dropping a comment in your thread here about my overall testing – going very well. Super responsive. i added a couple new devices just to test that process out too, auto discovery worked great (on restart).

I’ve just starting watching and being more critical of cascading state change – and your implementation seems to be far better then any I’ve used before! thank you. I’ll continue to monitor this closely and let you know if any issues come up.

For broader awareness – no magic exists to overcome the insteon 3-way switch sync issue… I commented on this a bit further in github issues, but the workarounds work fine if you avoid using the technology in a way it’s not designed for

teharris1 · April 17, 2020, 1:37am

@joe2 Thank you. I appreciate the help with debugging. Glad to hear it is going well. For what it is worth, I have been working on this new version off and on for over a year. Nice to see it being brought into the light of day.