Interesting. I have HE Homebridge integration tied to lights turn on at Sunset and off at 11:30pm, which are not failing. I also have an motion sensor enabled by a -60 Sunset offset and restricted at 1am. This sensor and the light are not part of Homebridge, and also working well.
Just to be clear... what is failing is not on home bridge. I only have two devices paired to homebridge and I did this intentionally so that HE would barely interact with the homebridge app.
I am frankly stuck.
Understood. If you remove the HE Homebridge app, do you still experience automation failures after 36 hours?
No the last time I removed it, went about 30 days with no automation errors.
Strange. @tonesto7, could there be something different in his config.json file that would change how the app behaves?
Good point. Her is my confit.json (is redacted).
{
"bridge": {
"name": "Homebridge",
"username": "0E:09:51:55:C9:47",
"port": 51821,
"pin": "585-xx-087"
},
"platforms": [
{
"platform": "Netatmo",
"name": "Netatmo Platform",
"auth": {
"client_id": "59d374a3ec135e6c428be24d",
"client_secret": "XByRs2f0yv8YpDxAfCf5QooCvhPSd79",
"username": "xxxx.xx@xxx.edu",
"password": "xxxx"
}
},
{
"platform": "Nest",
"token": "c.4CsKEHITUxiT3coC1URf29GPUE70UNzHNOU1rjDdgsWBjrT6CVXjFlLjgDlhG6gP8ya0Djlv3VpREbiUmovZOtAyNYNHOW1s3GFlPzcDNOgNEG0hSNVphNowCV5RCOH6jgNX16DRc6deGfhr",
"clientId": "4e1592e9-d2d8-4ed8-bca0-20b3eb27fa46",
"clientSecret": "xxxx",
"code": "SJGN732K"
},
{
"platform": "Camera-ffmpeg",
"cameras": [
{
"name": "Jonathan",
"videoConfig": {
"source": "-re -i rtsp://xxxx:xxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxxx=Xxx",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Balcony",
"videoConfig": {
"source": "-re -i rtsp://xxx:xx@192.168.7.xxxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Entryway",
"videoConfig": {
"source": "-re -i rtsp://xxxx:xxx@192.168.7.189:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxxx",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Family Room",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxxxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Entryway - Inside",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Front Door",
"videoConfig": {
"source": "-re -i rtsp://xxxx:xx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Kitchen",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxx@192.xxx.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "North Pool",
"videoConfig": {
"source": "-rtsp_transport tcp -re -i rtsp://xxx:xxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Stairway",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "South Pool",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Driveway",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Chicken Coop",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxx@192.168.7.xxxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
},
{
"name": "Playground",
"videoConfig": {
"source": "-re -i rtsp://xxx:xxxx@192.168.7.xxx:554/videoMain",
"stillImageSource": "-i http://192.168.7.xxx:88/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Xxx&pwd=Xxx&",
"maxStreams": 2,
"maxWidth": 1280,
"maxHeight": 720,
"maxFPS": 10
}
}
]
},
{
"name": "Config",
"port": 8080,
"auth": "form",
"theme": "blue",
"platform": "config"
},
{
"platform": "Hubitat",
"name": "Hubitat",
"app_url": "http://192.168.7.xxx/apps/api/1316/",
"access_token": "80f1808f-xxxx-48c9-a233-0682f2aa20d9"
}
],
"accessories": []
jsonlint.com says it's valid json (after adding an ending } )
Obviously for diagnostic purposes, you could trim this down to:
{
"bridge": {
"name": "Homebridge",
"username": "0E:09:51:55:C9:47",
"port": 51821,
"pin": "585-xx-087"
},
"platforms": [
{
"platform": "Hubitat",
"name": "Hubitat",
"app_url": "http://192.168.7.xxx/apps/api/1316/",
"access_token": "80f1808f-xxxx-48c9-a233-0682f2aa20d9"
}
],
"accessories": []
}
Plan B would be the opposite: remove the hubitat "paragraph" from config.json, leave the APP running in Hubitat. The results would be: it's better 
, or it's worse 
But either gives some additional data.
Ok. I will try and report back.
Still running fine. Homebridge plug in app loaded with some devices. No homebridge plug-in started in the config.json.
Like I said, all automations running smoothly.
My good morning RM rule failed to change the mode at 7am this morning.
What do the logs show? Did the Rule run or not?
The idea behind plan b was to isolate sending to Homebridge, and having a bug that yields performance issues VS receiving from Homebridge. Sounds as if it’s working better (or at least longer) with data flowing to Homebridge (which never hears it). Implies that Homebridge is responding/sending something unexpected or at least not programmed for.
I appreciate the help.
At 7:00 a.m. the Good Morning Rule should run and the point is that it does not. The logs show nothing at 7:00 a.m. so I wish I could say there is a log of something running and NOT actually running, but in this case the automation simply did not run and is not reflected as running in the logs.
Home bridge is running (screenshot).
So here are my logs from 7:00 a.m. this morning.
Here is my good morning automation... _NB! I manually switched the house into Day Mode thus making the condition FALSE.
Update: removed the home bridge app and all has returned to normal.
1 Like
Thank you for providing your data. I have had a very similar experience, and ever since I stopped using the Homebridge App, my Hubitat hub has been very stable.
I just can't imagine what is going on inside this app? It just subscribes to events from devices and sends HTTP requests to the Homebridge Plug-in. Of course, it also receives messages from Homebridge as well. I wonder if it is possible to isolate the issue to one side or the other of the App.
That's what I was hoping for with my "Plan B would be the opposite: remove the hubitat "paragraph" from config.json, leave the APP running in Hubitat." above.
Initially I read @JDogg016 reply as App = running, and stability improved. With no JSON for Hubitat active on HomeBridge, It should be receiving messages from Hubitat and ignoring them. Without an active connection, I'm not even sure of that, but certainly HomeBridge would not be responding.
Now, with the App shut down, stability improved, the burden shifts back to the Hubitat App.
I see three possibles...
- Hubitat HomeBridge PlugIn is sending incorrectly formatted data. Which results in an exception response that is not handled correctly.
- Hubitat HomeBridge PlugIn is sending incorrectly formatted data. Which results in no response! And the App is "puking" as a result.
- Hubitat HomeBridge PlugIn is unable to build a message and the App is "puking" as a result.
(where "puking" means some deadly embrace, resource consumption, or filled queues that otherwise slows the system.)
My humble opinion anyway.
I should add that I have no other homebridge integrations except Tony’s and the configurable we GUI he recommended. I’m running my Ubuntu VM from my QNAP NAS.
Thank you all for jumping in.
I run homebridge on a synology disputation using docker and a GUI platform developed by oznu on Github.
With very limited exceptions (usually related to losing actual internet connectivity) homebridge runs flawlessly for my netatmo, nest and cameras.
Any assistance with @tonesto7 app would be great! I do agree, there is something in the app (not homebridge itself) causing HE to "puke". I did previously mention that the most obvious fails after installing the homebridge app are time based (ie. 7:00 a.m.) RMs that do not run. But speed is also noticeable in the fact that lights that should turn off after x minutes of motion (or contact sensor closing) do not run either.
If you remove the app and restart HE everything fires up. In fact, I get a new 24 hour lease on life if I simply restart HE and leave the homebridge app in place, furthering the theory that something in the app code causes abnormal resource consumption.
Really curious why this is an issue on your system. I've not had any issues. I have these additional parameters in my config.json file.
"polling_seconds": 1,
"update_method": "direct",
"direct_ip": "192.168.0.113",
"direct_port": 8005
Yes, yes, I know. A one second polling time is not good and likely to cause issues, but I need it for the kind of response time I require to sync virtual switches to the Insteonlocal plug-in. It has not caused issues for me ironically.
I would have to presume you run RM and have rules that are time based?
I don’t think it has anything to do with the homebridge plugin but rather the app as I had issues without starting the plugin.
