Homebridge Plug-in

Disable the Homebridge app tonight/Tomorrow before 2:06 am and let me know if you see the same thing Iā€™m seeing please.

I canā€™t be the only one.

Me? @bobbyD mentioned the same thing. I'm not at home, but I'll try it when I return. It will be a good test.

For science!

And so simple right? I totally forgot about the disable check box until I needed it. Really a brilliant way to troubleshoot quickly.

Is there a way to programmatically enable and disable apps?

Only through the UI that Iā€™m aware, but maybe it exists. Iā€™m not a developer. Maybe one of these guys :point_up:t2:can help.

So if HomeBridge is slowing HE because of async not being enabled, Im wondering if the same is true for WebCoRE? I haven't used WebCoRE on HE but its just a thought.

webCoRE (latest versions) uses async http for most operations. I have done a lot of work to reduce state, thread, synchronous calls, mass wakeups, etc.

I see hangs on hubs with no home bridge or webcore. My belief (no clear way to prove) is that there are longevity issues in HE, causing it to leak / hang. It may be related to http (sync and async) calls (especially off the local lan), but it also may be memory/threads, garbage collection, database.

I expect more longevity tests need to be run, and with the more complicated applications for the HE folks to find the pattern for the leaks. As users there is not enough data to even monitor for this...

I hope they find this, as this type of instability is what plagues ST. Java is so much fun...

1 Like

I have observed just shortly before a hang that things dramatically slow down.

for example event responses that were 100ms, become 10,000ms. Not too long after that things are mostly locked up and a reboot is required.

I have asked questions about how they do the db cleanup, as this is something that gets done after a reboot, so it makes you wonder what happens if a db cleanup happens while the hub is in production....

It's not "because of async not being enabled". I'm not running the version with async enabled and I'm not having any issues. If it was because async isn't enabled all of us running the old non-async code would be having issues and we're not.

But you may also not be running many other http request/socket applications which could be the issue the rest of us are running into as well. As @nh.schottfam stated it could be a core issue that isn't being seen by your current setup.

Or so you assume...

I do see an improvement with Async, during the day, but when the HE database backs up, things get really slow with Homebridge enabled. If itā€™s disabled, thereā€™s only a 1-2 second delay for 2:06am to 2:16am while the database backup occurs on my system. I repeated this test last night with the same results.

I run and node.js app for Insteon, so I suspected this. But if I shut that down it still happens when the homebridge app is enabled. I canā€™t begin to tell you whatā€™s changed, or frankly when it changed because Iā€™ve been experiencing the slowness for quite some time. Itā€™s only recently that testing has shown, and Iā€™ve come to accept itā€™s the homebridge app.

Iā€™ve been a long time supporter of the Homebridge app and have promoted its use for people with iOS devices to do presence detection and all sorts of automation and control. However, when itā€™s enabled my hub slows, when itā€™s disabled my hub does not slow down. Nothing else I disable has any improvement to that slow down, except disabling the homebridge app. Whatā€™s doing it is beyond my ability to fix, so keeping it disabled is my only option until a total solution is found. I need my hub to be fast.

Is it worth keeping HB enabled, but paring down the devices that are used by it, to see if its a particular device or class of devices that are making it slow. I only use HB for presence so its very lightly loaded and I have never seen any slowness.

1 Like

Tried already. Two virtual switches only. Noted further up in the thread.

How do I try the async version of the app code?

So what was the result of your test?

Thanks for that post..missed it on my scan. I rebooted HB after updating to the new async code. Will let you know how it goes. For what its worth, the longer the Hubitat uptime, the slower HB has been getting. My Hubitat uptime has basically been the length of every platform update intervals, fyi.

Anecdotally, when the hub does its database update and the homebridge app is enabled, thatā€™s when things go downhill. When the homebridge app is not enabled and the database does itā€™s nightly deed, itā€™s not a problem and I donā€™t notice any slowdowns at all. I tested that over a two-day period. So longer testing is needed, but on the surface all I have to do is enable homebridge and it goes downhill and continues to go downhill after the first database maintenance following a reboot, until I again reboot the hub and leave Homebridge disabled.

How about if its enabled and no devices are selected? The only reason I ask is because it looks like it still subscribes the location mode and security system events (you should see the subscriptions and even the schedule's it has in the app config page).

Those subscriptions shouldn't do anything anyways that would cause the issues but who knows.

Now if that doesn't help I would probably look at next maybe the updates coming from the node server into the hub? Throw a little logging in there and see if a lot of chatter is coming in maybe even at the time you have a slowdown.

Since you have a repeatable process it helps quite a bit with troubleshooting to narrow it down. These are what I would probably start with to troubleshoot the issue. You've already done a lot to help.

1 Like