That can happen especially if there is other things going on with the hub, and repeated full mesh repairs will only cause more problems by spamming out tons of discovery packets.
For now I would maybe not worry too much about Zwave but when you get the hub stable, you can make note of which nodes fail and then do those one by one to see if they will repair that way. If it still fails then possibly the hub cannot reach that node.
You can try the advanced discovery on here: http://findmyhub.hubitat.com/
Most likely though is that something within the LAN is upsetting the interface on the Hub and knocking it totally offline where only a power down can bring it back. It has been proven to be especially sensitive to multicast JF packets. Not sure if there are other things it does not like.
That's why I suggested to totally isolate it, which if done correctly would rule out any possible LAN issues.
I am using the Maker API to create a Hubitat <-> MQTT bridge, and it worked all night long until the first attempt to turn off a device (fan). There were MQTT messages right up until the crash.
Yeah, unless a software update on the NAS changed something and now it is sending out multicast JF for some reason? Or even a software update from Ubiquiti, I have seen other posts where people said a Ubiquiti update started causing issues due to some change they made. Could be any new piece of equipment you added or anything that was updated . Assuming it is a networking issue. Not saying there is anything wrong with your network, but just something that is not playing nice with the HE Ethernet interface possibly.
Another thought, since you said it usually goes down pretty quickly. If you want to rule out Zwave you could just disable the Zwave radio for a short time? I cannot recall though where anything Zwave related would cause such a swift and severe problem.
@jtp10181 I get it. I really like the Hubitat. It's been one of my favorite bits of home automation gear. It really is the hub of what I have been working on for years. It's really frustrating when it should "just work."
I got the idea that the z wave network might be a problem while searching for solutions to this problem. One solution involved removing ghost devices and "cleanup" (whatever that means).
I think you can see screenshots of my custom setup by searching this site for RoboDomo. That thread is likely years old and the UI and features have obviously improved since then.
Couple of other ideas. If you have the C5 still you could fully reset that, radios and soft reset. Bring it up and put it in the same situation as the C8, different IP obviously. See if that will run of it is also goes down.
Another option would be to open a warranty case, and maybe they can see something in the engineering logs that will point in the right direction. Warranty ā Hubitat Support
There have been a few cases of bad hardware as well, and a new hub fixed it, but since your C5 was doing the same thing, that seems to point to some other issue being the culprit.
@gopher.ny is this a known issue / work around?
User has a DHCP subnet mask of 255.255.0.0 and hub was going offline.
He set the hub for a static IP instead (I assume with same settings) and now it seems to work fine.
I know there were some issues with alternate subnet masks being worked on but I had not fully tracked with all of that discussion.
Yes, I am still using 255.255.0.0, but set in the UI as static IP, not being obtained via DHCP.
Again, this has been working for years with the 255.255.0.0 netmask and DHCPā¦. If there was a change to the network stack in any of the recent updates, it might explain it.
The hub has been up and working fast!
I considered the possibility of two devices on the LAN with the same IP. But I donāt see it in any of my configuration files.
I think it was in 2.3.6, they added some more aggressive reconnect logic. Possibly was some tweaks in 2.3.5 for the C8 as well. This was to help with people who has hubs dropping offline and never coming back. It was especially prevalent using the Wifi on the C8 with mesh networks.
So I am guessing something with that reconnect logic was blowing up and booting your hub offline due to the non-standard netmask in DHCP. I tagged a dev up above, not sure if he will see this or not Like I said I know this issue with the DHCP mask came up not too long ago, not sure if there ever was a full fix for it, I had not tracked that topic very much.
Itās a standard netmaskā¦. Not to argue or anything.
I donāt know why people use a class C for private networks, unless every IP is dynamicā¦
In hindsight, it makes sense that the hub was going offline, but was still āworkingā. I mean the CPUs was executing the programs normally, just without networking.
Non-standard by Hubitat standards apparently.
But yes, I know it is perfectly legit. I actually got a degree in networking once upon a time.
Most home networking equipment is going to use /24, and most people are not going to change it.
I use /24, I have around 50 devices and maybe 10-15 have reserved IPs, I let DHCP take .100 - .254 so I have plenty of room to work with. Most people who I have worked on their routers only have like 20 devices connected at any time max.
I have a feeling it was something like it didn't like the DHCP to change its subnet mask from the most common domestic /24.
However if you used a static IP it would work, BUT the issue was it would still show you it was using /24 which was just a UI issue. So think there was a number of issues with it, not sure what of those have been fixed I would assume the latter one at least.
I started out that way, but I wanted to keep my computers and VMs as contiguous IPs. I would allocate .10 through .19 for those, and .20 through .29 for home theater gear, etc. But I used all the .10 through .19 after a while. It made more sense to reserve 192.168.1.* for computers, 192.168.2.* for home theater gear, 192.168.3.* for ā¦. And so on. 192.168.100.* for dynamic IP.
I also have gig Internet and Spectrum as part of my HOA dues. I route the .100 net through the slower spectrum connection and use that for guests and for streaming devices to stream live TV using the Spectrum TV app (has to be on a Spectrum IP).
So much more flexibility this way.
My home automation backends can access things like the pool controller or the Denon AVR in my home theater by host nameā¦
Itās a bit of work initially, but later on, I just have to match a MAC to a new dedicated IP when I add something new to my network.
As an aside, I have a presence detection daemon (Docker container) that simply tries an HTTP request to our phones (static IP). If connection refused, the person/phone is on the WiFi thus present. If no route to host, or any other error l the phone/person is not present. Itās been a 99.9% working solution for me. It fails when the phone is powered off (almost never), has WiFi off (a mistake to be off), or in process of updating the OS.
Better than geofencing, IMO. Whatās really nice is that we pull into the driveway and the phone connects quickly to the WiFi. I could use it to automatically open the garage door- but I worry about security if the door might somehow open when weāre out.
. Assuming it is a networking issue. Not saying there is anything wrong with your network, but just something that is not playing nice with the HE Ethernet interface possibly.
Like I said I know this issue with the DHCP mask came up not too long ago, not sure if there ever was a full fix for it, I had not tracked that topic very much.
