Slowing to a Halt

[NexGen-3D-Printing]

Hi,

This plugin appears to have the same issue as the Home Assistant Insteon Local plugin.

As you add more devices, the slower it goes, and if you try to turn on and off more than 2 lights one after the other, it slows right down and can either take minutes to activate a light or not at all.

I have tried several platforms, win10, win7, Debian, Mint, same result on them all.

Its shame as this was exactly what I was looking for, I'm currently using the HCA-Tech Homebridge plugin and the ridiculously expensive HCA software in trial mode to control my Insteon HUB, and this software is fast, never fails at all.

Is there something in common with this plugin and the HASS one? I've tried everything, Homebridge receives the commands instantly, but the hub and lights just stop responding.

My Hub is the 2242 AU version, if you get a chance grab a trial copy of Home Control Assistant (HCATECH) and give it a shot, its freakishly fast in response time, even when its iphone -> VM Debian Homebridge -> VM Windows 7 -> Insteon Hub - > Light Bulb, it really is insteon.

Cheers

KFK

[logname]

Did you disable express server? "use_express": "no",

[NexGen-3D-Printing]

I will have to check my old backup config files, but I believe I set it to "false" as per the instructions.

[NexGen-3D-Printing]

{ "platform": "InsteonLocal", "name": "Insteon Local Platform", "user": "", "pass": "", "host": "192.168.0.165", "port": "25105", "model": "2242", "use_express": "false", "refresh": "300", "server_port": "3000", "devices": [ { "name": "Kitchen", "deviceID": "27.12.F8", "dimmable": "yes", "deviceType": "switch" } ] }

My config is as above, but I have around 20 devices, 1 seem to work okay still slow, but anymore and the issues start.

[logname]

Hmm, I see that Kevin wrote "true or false" in the readme, but I haven't see any parameter values previously for the plugin that used those values. It's always been "yes" or "no". I actually didn't even read that as true or false the first time, and I just entered "no" by force of habit. Maybe both are valid, but maybe not? Try "no" instead of "false" perhaps?

I have less than 20 Insteon devices in Homebridge and I'm using a 2245 hub, so those are likely the most important differentiators.

[logname]

Was just about to close my laptop and noticed two anomalies in your config.json example

1. There should not be any spaces or dividers in the "deviceID" - Should just be "deviceID": "2712F8",
2. You have "dimmable": "yes" and "deviceType": "switch" - dimmable is not valid for switches, so "dimmable" should be removed. If the device is dimmable, use

"dimmable": "yes", "deviceType": "lightbulb"

[kuestess]

@Kung-Foo-Kamel I have ~30 devices and my hub is still fairly responsive. A couple things to try... first as @logname noted, remove the periods from your device IDs. I believe the home-controller library will handle that, but it takes time/cycles. In your config, where you have "use_express": "false", , remove the quotes from around false so that it is treated as a boolean instead of a string. I don't think that the Express server adds alot of overhead, but can't hurt to disable if you're not using it.

One other thing that I've discovered is that the Hub firmware can make a huge difference. Insteon made some updates to firmware when I was testing early versions of the plugin and it managed to totally tank connections to the Hub (they fixed with a subsequent update). Make sure that you have the most recent firmware (although I see that you have a 2242 which I don't remember whether it is field upgradable or not). Outside of that, there may be a few things to tweak responsiveness that I can try.

[awaspaas]

I do also get the issue somewhat but mine only manifests once a week or so. The request pops right up immediately in the homebridge log but the device doesn't respond and homekit spins its pinwheel. Sometimes it eventually responds, sometimes not at all. Either way a reboot of homebridge clears it up. Is there some debug logging that can show where the holdup is during the unresponsive time?

[NexGen-3D-Printing]

Thanks for the responses, I’m away at the moment, so I will attempt to add Insteonlocal back into my config this weekend with the possible fixes stated above.

Also I believe there is no firmware updates for my hub, it’s stuck with firmware circa 2014 I believe.

But like I have said above, HCA will make my hub and Insteon system work like a race horse, would be nice to know how they have accomplished it, I would buy their software if it was cheaper, and if I cant get this plugin to function properly, I might have to. (Also this software is windows only, would prefer nix instead)

I will let you all know how things went after the weekend.

[kuestess]

So now that I read through all of your responses, I understand the issue a little differently. The loss of connection to the hub is something that I've noticed too and have been trying to fix. Unfortunately, I think it is partially (at least) firmware related. There was a firmware version at the end of 2017 that would chronically drop connections. Insteon updated it and it seemed to be pretty solid. Lately I've been noticing a lot of dropped connections from the hub. @awaspaas As you describe, a quick restart of homebridge seems to fix it. I haven't had any luck diagnosing the problem running homebridge in debug mode.

[NexGen-3D-Printing]

Have tried hcatech.com ?

If you have windows running give it a try has a 30 day trial. It has no connection issues, would love to know their secret source (pun intended)

In regards to Homebridge I find a reboot will fix it for about 30sec then it starts playing up, I can turn a light on then off, after that it gets slow then unresponsive.

Like I said it seems to be the exact same thing happening in HASS.

[NexGen-3D-Printing]

Hi guys, some feed back, I made all the corrections above, and increased my CPU from 1 to 3 and doubled the ram in the VM, also gave homebridge max priority, and its better, but after about 5 commands it slows right down, and if I persist, it just locks up and requires a restart.

On a side note, username and password are not needed, I forgot to put those into my config, and everything worked, when I discovered this, I put the details in, but it operates just the same.

Looks like I will have to pony up the $160 for HCA.

I wish I had never purchased any insteon gear, I can buy 6 RF 433 plugs for the price of one insteon, and they perform perfectly with the Broadlink setup, its been so hard to get support for the AU insteon gear.

Thanks for all the help anyways.

[kuestess]

@Kung-Foo-Kamel Maybe one more thing to try..... Your 2242 hub still has the PLM interface port which is why you can connect without a username/password. I think that you can still connect to that hub via http, which is the only interface that the newer hub (2245) has. In your config, change the model to "2245" and see if that helps. Just a thought!

[NexGen-3D-Printing]

G'day kuestess, just tried this and its an order of magnitude worse, it's really slow and fails after trying just one light, seems to get backed up straightaway, but in PLM mode its its fast to respond, but after a few goes it gets backed up, but actually will recover if you leave it, its almost usable unless you switch a group on or off, this is were it will fail completely.

Not sure what HCA uses, most likely PLM as it works as well as my insteon wireless switches do.

Can we switch insteon on and off like the old X10 stuff? I know my hub can control X10 gear.

Edit: I just discovered that the 2242 PLM also uses this port number: 9761 it works, but same result unfortunately.

Edit2: I used wireshark to capture the events from HCA, it appears to keep cycling its port numbers, everytime it sends a package to the hub, it comes from a different port number, all are going to 25105, but HCA changes up by one each time it sends a command, maybe this is how they circumvent the buffer issue? there could be an artificial limit that the hub imposes on a particular port number through the PLM interface, how does your plugin communicate, does it send from the same port number everytime?

Its starts at 63xxx and works its way up to 64xxx, I gather they have a window of port numbers they use, mostly will recycle once it hits the end, the hub always sends it response back to the originating port number, then HCA steps up to the next sequential port number for the next command.

This happens every single time a command or request is sent out to the hub.

[logname]

You can buy a 2245 hub for $80, that will solve the slowness issue.

[NexGen-3D-Printing]

The 2245 hub will most likely not function correctly in Australia, if it did, every man and his dog would be selling them here, we are still stuck with the non homekit/alexa/google hub, that would also cost me $120 plus some silly rate for transport.

There is an obvious work around for the buffer slowness issue, as stated in my edits above, HCA have figured this out by a rolling port system.

[kuestess]

Sometimes you can even get the 2245 for $29 around US holidays.

@Kung-Foo-Kamel Interesting that it was even worse with port 25105. Can you post some of your wireshark capture? Would be interesting to see if they are sending special commands to the hub other than on/off that speed up response. This was my next thought, but if you've already done it I can try to see what their secret sauce is beyond changing ports.

[logname]

most likely not function correctly in Australia

Ah, OK. That makes a major difference. No, a 2245 will not work for you. Carry on.

[NexGen-3D-Printing]

kuestess, using 2245 was worse than using 2242, both were using port 25105, and I tried 2242 with alternate port number, and results were identical to using port 25105.

Basically using the 2245 hub setting is a no go at all.

I have extracted some transmit and receive packets from Wireshark and zipped them up, if you need more let me know.

WireShark.zip

[kuestess]

Thanks @Kung-Foo-Kamel - looks like this capture only contains buffer requests. Can you capture some on/off cycles for one of your switches? Thanks!

[NexGen-3D-Printing]

Insteon.zip

Kuestess, give that a shot, I had to figure out how to use the filter in Wireshark, got it sussed now.

[kuestess]

@Kung-Foo-Kamel Thanks for the capture. As I looked through it, they don't appear to be using any special tricks, but rather the same calls that the home-controller package uses (which I use for this plugin). Interestingly enough, it looks like they only use the http interface as I don't see a connection on port 9761. The only difference I can spot is that they close their connection to the hub after every call, where I keep it open so that we can capture events and update status in real-time. Does the HCA interface update status if you manually hit a switch?

[NexGen-3D-Printing]

Hi, I just checked on that and no it doesn't, I think it polls for an update after x time, their interface if used properly is supposed to take over the job of the hub as you can do all the linking in their software, this way all requests, from switches go through their software, I have not done this, as its a ridiculous amount of work, and if my server has a failure, my lights still function properly as all my switches are the mini wireless ones and are linked directly to the responding bulbs. (we don't have access to the wired Insteon switches)

Can you add a line to the config.json that will allow us to toggle this keep alive feature on or off? all we need is for it to poll after x time to get an update if a state has changed which I think your plugin already does?

You may find if you drop the connection like they do but use 9761, yours might actually work better.

I think if you fix this issue, you will have most likely fixed the issue with HA and OpenHAB2 as they suffer from this very same affliction.

[kuestess]

@Kung-Foo-Kamel I was thinking the same thing - kill the connection and re-establish as needed for commands and periodically for polling. Unfortunately the plugin was written thinking that these little boxes could handle a constant connection, so its a bit of work to change to an on-demand connection or at least provide the option. Certainly feasible, but may take some effort. I'll be away for a bit but will take a stab at it when I return!

[kuestess]

As a temporary fix, I've uploaded a new version to npm that periodically resets the connection to the hub. I've been running it for a bit and I haven't had issues with non-responding devices (yet), but more time will tell! By default, the connection watcher will reset the connection every hour - you can change this by placing the keepAlive variable in your config (string, at the platform level) and specifying a reset time in seconds. You can disable this by setting keepAlive to 0. So far the only negative impact I've seen is response time when the connection is reset, but that should be fairly infrequent.

[NexGen-3D-Printing]

Thats awesome, I will give it a shot and see how it goes.

Update: The plugin is now broken for me, 2242 hub wont respond anymore, and eventually crashes homebridge, if I switch to 2245 then it works, but like before, with massive delay, I messed with the keepAlive and set to 1 second, then 5 then 60, it doesn't help, not with hub 2245, and I have tried everything with hub 2242, but it appears to be unresponsive.

[NexGen-3D-Printing]

I have found a fix for this issues, take all Insteon gear and sell it on fleabay, I am switching to standard RF433 gear as its 1/20th the price and works way better for my use case.

We don't have hardwired Insteon switches, only mini remotes, the RF433 gear have really nice flat panel touch sensitive RF switches that just wire straight into existing gear, they are more wife friendly.

[gozoinks]

Still following this thread. I’m using a 2242 with port 25105. The resets might be helping. I still have delays, but perhaps only just prior to a reset.

[kuestess]

@Kung-Foo-Kamel I just published 0.3.5 that attempts to replicate what HCA does. In effect, it creates a connection only when a request is in process/needed and closes when not. Downside is that the eventListener won't work, but periodic polling should update status. Let me know if it works for you.

[NexGen-3D-Printing]

@kuestess I will give this a shot and see how it performs, I have started to switch out some of the Insteon gear for basic 433mhz switches, and I'm not fussed if HB doesnt know the state, as I can just tell what state I want, so if a light is on, and HB thinks its off, and I want it, HB just resends the on, this only works if the device has seperate on and off signals.

Does this plugin resend even if it thinks the state is already what you are wanting? I had this issue with the Btoadlink plugin, if Siri thinks the light is on, she will ignore the on command, they fixed this with resend state command, so Siri now ignores the state of the light and just resends what you asked her to do.

This would negate the need for event tracking, periodic polling is fine, but I dont think fast event update is always necessary for everyone, only those that are using a state change to trigger some other automated event.

I'm still up in the air on whether to keep any Insteon gear, its been a little disappointing for its price, I suppose I would like it a lot more if I had all the product range you guys have in the US, here we get only a few items to choose from, even the camera is only 720p, its pretty sad to be honest, would have at least liked proper hardwired wall switches.

[kuestess]

@Kung-Foo-Kamel Thanks for giving it a shot. I dusted off my 2242 and it seemed to work, but I only have a couple devices linked to it. Understand your frustration with the Insteon gear - when it works it seems to work well, but sometimes reliability can be a problem. Can understand why you'd move away form it given the limited selection of devices.

Except for power on commands, I don't do anything to filter out commands. I think its dependent upon the specific app that you use - the Apple Home app likes to resend power on when you dim a light, making it go to full on and then to the commanded level. I filter out the power on command if Homebridge thinks its on so you don't get the full brightness first. As long as Homebridge has the correct state it shouldn't be an issue. I'll have to look at the Broadlink plugin to see what they did. Other apps are smarter about what commands they send and only send a new level if the device is already powered on, at least in my experience.

[NexGen-3D-Printing]

Just testing this now, and its better, but still not working properly, you can turn a couple of lights on, then the third time, there is a delay, then it starts to lag, but eventually follows what your asking, if you wait a bit, it will catch up.

My fear is I will have to rip all of this Insteon gear out, only wish they had released a Homekit compatible hub in AU.

When using standard 433 gear with Homebridge, its superfast.

Was there any special command I needed to add to my config?

        "platform": "InsteonLocal",
        "name": "Insteon Local Platform",
        "user": "Test",
        "pass": "123abc",
        "host": "192.168.0.165",
        "port": "25105",
        "model": "2242",
        "use_express": "false",
        "refresh": "300",
        "server_port": "3000",

[kuestess]

@Kung-Foo-Kamel Glad to hear its slightly improved. Nothing you need to add to your config - on demand connections should be the default for a 2242 hub. Right now I only check whether the Hub is in use every 10 sec. I might try shortening that duration (more frequent checks) to see if that helps with response time. I'll push out an update later today to test that out.

[kuestess]

@Kung-Foo-Kamel Just published a new version that decreases the 'idle' connection time before the plugin disconnects from the hub. Let me know whether that helps response time.

[NexGen-3D-Printing]

0.3.7-5 is complete broken for me, nothing is responding at all now, previous version was working, was a little slow, just had to wait a few seconds between switching things, but now its back to square 1, pretty much doesn't respond, and if it does, its like 5 minutes later.

[kuestess]

@Kung-Foo-Kamel I've published a new version to npm that will allow you to adjust the hub connection check interval by adding 'checkInterval' to your config at the platform level and setting to the number of seconds you want it to wait before disconnecting the Hub. It will default to 20 sec, which seems to work fairly well. I also ran homebridge looking at all debug messages while connected to my old 2242 - it kept getting stuck on the message 'parsing - insufficient data to continue' with a buffer equal to '15' which means that requests are coming in too fast to the hub. After that, it retries the status check and eventually is successful, but at the expense of very slow response. I made some changes to the home-controller code to insert a short delay before checking status and it seemed to drastically improve response on my 2242, and eliminated any messages about insufficient data. If you're up for making a small change to the home-controller library within the insteonlocal plugin on your machine, it would be interesting to see if that works for you. Navigate to [your node directory]/homebridge-platform-insteonlocal/node_modules/home-controller/lib/Insteon and open index.js. Find the line (around 92) that has

socket.on('data', function (data) { debug('Rcvd:', data); that.buffer = that.buffer + data; that.checkStatus(); });

and change to

socket.on('data', function (data) { debug('Rcvd:', data); that.buffer = that.buffer + data; setTimeout(function(){that.checkStatus()},500) });

Let me know if that helps. If so, I'll request a change to the home-controller library.

[scourchesne]

@kuestess I can confirm that the change in the index.js of the home-controller Insteon library helps a lot with my 2242 controller.

[scourchesne]

@kuestess Quick note on the 2242, currently, the device status polling doesn't seems to work.

[kuestess]

@scourchesne Thanks for testing the above fix - glad that it worked for you! Does the hub remain responsive to commands over time? For the polling issue, I just published a fix - I made a change in a prior version that would inadvertently limit polling to the first device (I only tested with one device :-) ). The update should fix that.

[scourchesne]

@kuestess 2242 Hub is super responsive with the following config. I can make light blinking disco-style and the hub keep up!

But, still no update of the status. Polling seems broken. Manual input or Insteon app input are not updated in the Homekit interface.

Config :

{

                  "platform": "InsteonLocal",
                  "name": "Insteon Local Platform",
                  "user": "test",
                  "pass": "xxxxxxxx",
                  "host": "192.168.2.6",
                  "port": "25105",
                  "model": "2242",
                  "refresh":"60",
                      "use_express": false,
                  "server_port": "3000",
                  "keepAlive": "0",
                  "devices": [
                                { 
                                    "name": "Dimmer Sous-sol",
                                    "deviceID" : "1DC4FE",
                                    "dimmable" : "yes",
                                    "deviceType" : "dimmer" },
                                { 
                                    "name": "Venmar",
                                    "deviceID" : "1CD8D7",
                                    "dimmable" : "no",
                                    "deviceType" : "switch" },
                                {
                                    "name": "Keypad Sous-sol",
                                    "deviceID": "1CE5BD",
                                    "dimmable": "yes",
                                    "deviceType": "dimmer" },
                                {
                                    "name": "Sous-Sol ALL-ON",
                                    "deviceID": "1CE5BD",
                                    "dimmable": "no",
                                    "groupID": "4",
                                    "keypadbtn": "A",
                                    "groupMembers": "1CE5BD,1DC4FE",
                                    "deviceType": "scene" }
                            ]
    }

[kuestess]

@scourchesne glad to hear it remains responsive - I'll open an issue for home-controller to get this change integrated into that library. With the current code for 2242 hubs, I'm trying to keep the connection to the hub at a minimum (essentially on-demand) meaning that the event llistener won't work (requires a persistent connection). As a result, you won't see status updated immediately in the Home app, but it should update at least within the refresh interval defined in the config. Does status update within 60 sec (per your config) of a manual event or using the Insteon app? Do you get any 'Polling status for.... ' in your log?

[scourchesne]

Negative, no polling status for in the homebridge log.

[kuestess]

Well crap. Let me dig out my 2242 do a little testing to see if I can figure it out.

[kuestess]

@scourchesne I tested (as best I could) the same configuration that you posted above with my 2242 and polling seemed to work ok for me. I only have 2 devices linked to that hub, but each seemed to update in the defined refresh interval. Since your setup seems to work with the connection watcher disabled, I updated the code to (re)enable the event listener in the case where the connection watcher is disabled. This should allow you to get pseudo real-time, event-driven status updates. Let me know if you have any problems with the update (0.3.9).

[scourchesne]

@kuestess Great ! I confirm that 0.3.9 give realtime (FAST!) update on my 2242. I will report about stability after more testing.

[scourchesne]

@kuestess Quick report : The event-driven status updates works for manual scenes activation on the keypad but doesn't catch manual ON/OFF event from the same physical dimmer/keypad.

The event listener catch 100% of the input from the Insteon app. Also, just opening the Insteon mobile app refresh everything on the homebridge side. (Probably catching the status fetching from the Insteon App on the network)

[kuestess]

@scourchesne Not sure I completely follow the issue that you describe. Sounds like it updates status properly for scenes and associated devices, but isn't catching status changes for manual on/off for the individual device. Is that the issue that you are having?

[scourchesne]

Exactly

[kuestess]

@scourchesne New version published on npm that should fix issues for manual on/off. Corrected logic for on events.

[scourchesne]

@kuestess I tried a 0.3.9.1 from NPM but it seems to crash my Homebridge docker. Maybe it's something wrong with how I use NPM... I will wait for the next github release.

[kuestess]

@scourchesne Can you post a log of the crash?