I set the static IP address on the router. It’s based on the device MAC address so it still assigns it no matter where the device is located on the network.
1 Like
@bravenel thank you for jumping in with your perspective on this. I'm glad to know that you are aware and the team is working on a solution...
I can say is that there are several of us here in the community who have strong technical backgrounds. Speaking for myself, and I am sure a few others as well, we are ready and willing to pitch in whenever needed.
I completely agree. I would offer the interim suggestion to create an official scheduled reboot feature. I have no problem with a nightly reboot.. I may have 5 hubs but we're not exactly talking a high availablility VXRails cluster. The 5 minutes a reboot takes would be far less painful than waking up/coming home to a dead hub.
7 Likes
I used the C4 hub (from last year to this summer) which would occasionally require a power cycle (stop responding). The location I was using this hub at has been under renovation since and will probably finish later this month. Should I continue to use the same C4 Hub, it is probably a few software versions behind as it has been sitting unplugged for a few month. Or should I replace it with a C5? Or preform a soft/factory reset?
I acquired a C5 Hub in October for another location (400+ miles). It has been stable since - been very happy with it.
I simply decided some months back to reboot my hub each night as per the example above. It is extremely easy to achieve. No addition functionality is required in my opinion. I have a small start-up RM/rule that reruns some initialisation of Chromecast/wifi devices etc to ensure they are reconnected. It works fine. While it will be great to get a proper solution for the obvious and ongoing resource leak issue, I always smile at the anxst in the forums about hub slow downs etc. The temporary fix is simple. And given the open nature of the platform, even if the underlying issue here is fixed, some dodgy app or driver can cause it again anyway. So unless you are an absolute purist running a vanilla hub, what's the big deal? Just reboot regularly.
1 Like
I posted above that I'm willing to help, I have 2 C4 in my house but they work fine, no daily reboots or whatsoever, but I have friends with C5 that those been slow sometimes. I suggest just stay with your C4, there is no reason to replace it.
2 Likes
Thank you! This worked perfectly!
Sorry, I misunderstood. I thought you meant that you replaced your router with the TP-link switch and thus no longer having a router for DHCP. I am using reserved IP addresses on my router to assign a specific IP to my HE based on MAC address as well.
1 Like
Agree. The only hub I have automated a reboot is my C5. My 2 C4s are rock solid. This said my C5 is my “coordinator” hub that has many custom apps and all LAN type integrations such as thermostats and AVRs. Only exception is HubConnect which is running in all 3 of course. Radios are off on my C5 too.
For the first time since owning HE I have held off on upgrades given what I have been reading about the latest versions. Running 2.1.5.124. This is the beauty of HE having the ability to choose when to upgrade.
@bravenel My development hub is a C3 and I am happy to load beta firmware on it and restore my coordinator backup to it to help validate any fixes. Please let me know how I can help.
it’s the auto-negotiating that isn’t working properly between Hubitat and some switches and routers. I’m not having any problems with the TP-Link TL-SG105E. It’s $24 on Amazon and I have 2 Hubitats, 1 SmartThings hub, 1 Hue Bridge, and Homebridge connected to it.
It's definitely some, but not all C5 hubs. Or it is much slower on come C5 hubs than others.
My C5 only gets reboot on firmware updates, and never any other time. Runs fine 24/7.
Both of my C4 hubs, on the other hand need reboot every few weeks or they get slower, and slower. But they have more apps and devices installed than my C5 hub, too, so could be an app/driver thing and not a platform problem. 
1 Like
6 days ago I moved all of my end devices along with 4 Samsung plugs, 2 Sylvania plugs, and 2 GE in-wall dimmers to a new HE hub. So far I haven't seen any slow downs on either hub. All of the lights are on my original C-5 hub, along with 6 Peanuts and 2 Sylvania plugs. I kind of wonder if it is a zigbee or rule maintenance/cleanup issue. I noticed quite a few devices, that were removed from all rules, still appearing to be associated with rules as I was deleting them from the original hub.
EDIT: I also had an issue with ML yesterday where I couldn't edit or create a new ML instance. Even after 'deleting' ML from the hub and rebooting, the logs were showing ML errors. I finally restored from an earlier backup and found a scene null value and fixed it. Then ML was okay again.
Forgive me for my ignorance. I want to follow your rule for rebooting hubitat. I used my own IP address but after the colon, is 8080 a constant or is it different for everyone's system
8080 is the port number, and is a constant.
<your hub's ip address>:8080
the : colon indicates that next is the port number.
2 Likes
Thank you soooo much! I wasn't sure if I should use just :80 or :8080. May I ask if you think rebooting the Hubitat hub 3 times a week is overkill? For some reason if I don't reboot my hub every 2 weeks, my Iris Ver 2 keypad doesn't respond to arming. Once I reboot everything is fine. No other device has this issue and my reason for creating the reboot rule. Thank you again!
I would like to make a few more suggestions to the idea of periodic reboot:
- to turn off the zwave radio for a short period of time to allow it to refresh. I'm not sure how long a "short period of time" is, but just rebooting will NOT refresh the zwave radio (This can be accomplished under RM control by disabling the Zwave radio on the zwave status page).
- Again, not for everyone, and not on a frequent basis, many users have reported on the benefit of doing a periodic zwave repair and/or a zigbee mesh healing. It depends on your situation, and your configuration, etc.
Nonetheless, a number of users have reported that their system seems to run better when these steps are taken.
I've been auto-rebooting my 3 hubs twice per day.
The following screenshot shows how I use a momentary switch to turn off the zwave radio for a period of 5 minutes. As stated above, your mileage may vary:
Thanks to all! Very helpful advice. I guess I'll leave my reboot rule on Mon Wed Fri and check out turning off Zwave radio periodically. GREAT COMMUNITY, I'd be lost without you all!
Tony
1 Like
Please keep in mind that ALL advise regarding reboots is to provide workarounds for the symptoms described here. In no way should the Hub need any periodic reboot. In fact, it shouldn't need any attention for years at a time, ideally longer.
People reading this thread 'next year' should understand that there's a temporary need for a workaround. The symptoms have bubbled to the top in the past month, but then so has the number of hubs in the world. The underlying issue(s) will get resolved, I believe, and this workaround should be discarded after.
9 Likes
In my opinion partially what you state is to be the case. One of my 3 hubs appears to be slowing down for the reasons many have listed here.
However another one, my now "zwave only" hub gets rebooted mainly twice per day because after about 8-10 hours of my zwave locks never missing a poll from the reliable locks refresh, after about 8-10 hours they drop off and don't ever self recover unless I manually go to them and either unplug/replug the battery, manually unlock/lock/some sort of manual interaction. (and yes I have ample beaming repeaters and all zwave plus devices)
But if I don't do any of the above and just reboot the hub, they all start working again like nothing ever happened. I don't foresee this issue being a resource related issue as I have no apps on this hub except hubconnect, mode manager, reliable locks (to poll the locks every 30 minutes), lock code manager, one simple lighting rule (that rarely ever gets ran), and two rule machine rules that reset energy plugs once per month. In my opinion this is a hardware related issue, but I could be wrong and of course it's my opinion only.
A lock is a tough one to debug.
I was going to suggest using OZWCP + USB Stick to toggle the lock once it gets 'stuck' but it would be a lot of work to get the ZWave Security Key copied onto OZWCP/ZenTools.
If there is another device: IF OZWCP was able to control the 'stuck' device then it's the hub. IF OZWCP is unable to control the 'stuck' device also, then it would be a faulty Device, not the Hub.
