Disconnecting it while included in hubitat can mess it up as it's a repeater. If you need to disconnect it, exclude it first.
Understood. I presume if I don't see it on the zwave details page as a part of any other device route, it is safe to assume that it's not repeating anything?
It's still a repeater and because it's in the table at some point it will be tried to routed though and hang your mesh. When you are done with it just exclude it.
And so it happened again - I guess it's true what they say - consistency is a sign of mastery.
I am trying to put in place some nightly shutdown / powerup measures so that if it is f'd at least on my terms... But it's definitely annoying.
I know there's a rebooter app, But is there a shutdown command that can be issued?
umm nevermind... search makes wonders sometimes
I've had the same problem and was able to recover with a shutdown, power disconnect, and restart.
I hope Hubitat has a permanent solution soon.
There is no generic solution for this because the cause seems to vary by installation. Just to confirm - do you have anything sending jumbo Ethernet frames on the same LAN segment as the Hubitat?
Aaiyar, thanks for your question. After looking up “Ethernet Frame” on Wikipedia, I think I have some idea of what you are asking.
First, my WiFi installation is a home installation and is not divided into segments as far as I know.
I’m using a TP-Link ER605 as the router with three access points. The Hubitat C-8 hub is connected via Ethernet (not WiFi) to the Internet. Wouldn’t that eliminate a problem with Ethernet frames?
No. Ethernet is what would be affected, wifi connected devices would not be. If your router has jumbo frames turned on they should be turned off.
Edit: Looking at the manual for this, it is not possible to turn off jumbo frames on this switch.
I still can't believe jumbo frames aren't protected against in the HE firmware. Its the only wired device on any of my networks that has this issue.
The fix would likely require an OS level fix (as opposed to a change in the platform). Which is very possible. My guess is that Hubitat is reluctant to have end users flash the underlying OS for fear of bricking their hubs.
I assumed every update applied contains a mix of OS and platform updates combined. The Linux based embedded product I work on does.
The C8 was a good opportunity to fix things like this too.
My zwave issues started last night. I have 6 zwave locks and they have all stopped updating their status. They do not respond to any remote commands either. Other zwave devices seem to be working OK. I have rebooted and restored from a previous back up but no help. Running 126.96.36.199 and updated to that about 5 days ago. C-8 Hub.
Shut down the hub, unplug power to the hub for 5 mins and power back up.
Agreed. Perhaps the testing environment didn’t have jumbo frames.
Based on your reply about the TP-Link router, I assume that I cannot fix this without changing the router. Is that correct?
I have had to shut down and restart my Hubitat 3 times in three days. This is really bad.
This isn't rare for me. It's happening every day almost.
What about temporarily turning off cloud backups? Will that stop it? Or are jumbo Frames still a problem? Is this caused by a combo of both those things or is it either of those things?
You could get just a small 100mb hub to throw in there, that should stop the passing of jumbo frames,. just plug that in and then plug your hubitat into that and it should be good.
Jumbo frames are network based whereas the cloud backup causing issues is on the hub itself. Jumbo frames are being based to the interface of the hub causing the lockup