I have 79 devices in my homebridge setup and no issues because of that amount.
Would you mind sharing the config.json portion related to HE?
Also, I am thinking maybe it has something to to with Netatmo. Netatmo integration is quite less than polished on HE (nobody's fault) and I am thinking consent web requests for netatmo combined with homebridge might be the culprit. Especially when Netatmo's developer servers go down.
My config.json isn't fancy at all. In fact it's a copy/paste of the example on the GitHub page with my hub's information substituted.
"username": "MAC ADDRESS HERE",
Homebridge supplies the config:
For many, that's enough, for you with other Homebridge integrations, you'd want just the part between the square brackets, and to insert that (as you have done) between your existing square brackets.
I’m fairly certain the issue isn’t fully with Homebridge or WebCoRE.
In my testing there seems to be something related to network connections (slow, packet loss, outages). It seems that the hubs are locking up under these certain conditions. It's basically halting the processing of other actions/automations.
No matter the cause no custom app or platform app should be able to bring down the hub or interfere with Z-Wave and ZigBee functionality.
Based on the comments from staff on here, this doesn't seem to be a hardware limitation but in my opinion a platform limitation, which I can only hope will be addressed sooner or later.
With all of that said I still understand from a support perspective how impractical it is to support custom apps.
I'm more than willing to work with engineering/support to optimize the code any of my apps to run more efficiently under Hubitat.
Which in the end I have to think that solving these issues would have a few benefits. One being lower support requests. Another is reducing user attrition and increasing their overall satisfaction.
Plus we could share our findings/solutions with other community developers to make there apps better as well.
All I really need from Hubitat is the actual cause in which the custom code is killing these hubs.
Bingo! Some of the frustration is that I can email support and they can tell my why my hub crashes. BTW - Support is awesome they helped me on a Friday night because Netatmo servers went down which caused a weird html issue to the HE hub which led to a hub crash.
Homekit is a very useful UI platform and a nice way to interact vocally with connected devices in the home and a version of the homebridge plugin that would NOT cause crashes (if that is the case) would be widely appreciated.
For some reason, I'm still having issues with the Armed Night mode. I tried reinstalling the homebridge app and checking to make sure the Hubitat code was updated. Not sure what else to try.
Yes there support is wonderful... but they can only do so much.
I think what bothers me the most is this:
Hubitat was born from the frustration of ST not listening to developers and always doing what they wanted.
So it's hard to watch the same thing occurring on this platform.
My apologies if this has been covered somewhere in this thread , I read through but couldn't find any references.
Has anyone installed homebridge on a synology nas ? I am specifically interested in the performance with hubitat when installing it via a docker image or directly as a synology package. I have a DSM712+. Not sure if it can handle this. Just checking before I dive in.
Also where can I find the latest version of the homebridge app for hubitat? Is it v2 or 1.5 ? I clicked on the link at the beginning of this thread to the github page and it had v1.5 ( I think). But i have seen references to a v2 ?
Yup I have it on my Synology 912+ and docker runs it without issue. I've never had docker go down and only take docker down if I do an update to the entire Synology platform.
Check out the container by oznu. It has a GUI self-install version of the Homebridge Docker container made especially for the Synology NAS. It takes about 5 minutes to install and even comes pre-built with a text editor to edit the config.json file.
It's not the plugin I promise. It's very efficient.
The issue is in how the app works under Hubitat...
The only thing I can think of is that it uses HubActions instead httpPost() requests which sucks because that's the only way to do local communication on ST,
I speculating here but maybe the issue lies in HubActions. Idk if they have a timeout and if every time an device event comes in it opens a new connection until the hub can't handle it (I don't know for sure)
That shouldn't say can't tell you
That's the one. Now install that directly from the Docker Application in Synology and you will be good to go.
There is a version 2 which was a large rewrite of the plugin.
I was planning to implement the new ST Rest API into it as well (Which would require a web UI to manage on ST), but it got put on the back shelf because of the popularity of my Echo Speaks implementation.
I will eventually get around to finishing v2.0 (the core plugin is done and I have been using it for 4+ with 0 issues)
I'm having some issues as well. If I arm for "Night" from the Home App it gets confused and seems to arm it for "Home" instead. If I arm from the Hubitat web interface it works just fine. For now I just keep using the arm "Home" for night.
It's because i never updated the npm package (which I just pushed out).
If you update the homebridge plugin to v1.5.6 you should be good
Thanks for updating it. I actually manually updated the code with the armedNight line and still had issues. I'll try updated the npm and give it another shot. Thanks again for all your great work on this...without this integration I wouldn't have moved to Hubitat.
Seems to be working great with the updated app. Thanks!
Okay still having an issue with arming for "Night" mode using the iOS Home app. It changes it to armed "Home" instead of "Night". If however I arm it using the Hubitat web interface button "Arm Night" it shows correctly armed as night in the iOS home app. So in summary I can't arm for Night using iOS at all as it just changes it to armed Home instead.