I am having this issue exactly and as others have posted in the community. It's been an issue pretty much from the get-go. I'll give as much information as I can:
I am having this trouble with 3 out of 4 hubs (I can't recall the 4th ever having this problem).
Model of Hub(s)
C-8
Platform/firmware on hub
Currently 2.3.6.146 though the issue has been present on multiple versions.
How is it connected to the LAN?
Mix of CAT6 cable and WiFi. The WiFi are connected to Cisco Meraki MR46E APs. No rhyme or reason as to which ones have issues (WiFi and cabled both have experienced this problem)
How is Hub being powered? Supplied power block or other (explain)
Supplied power block
Brief explanation of network topology.
Microsoft Active Directory environment, running DHCP server on the domain controllers. Network is a /30. Hubs are given a DHCP reservation on these servers.
Brief explanation of firewall / DNS / DHCP services.
Firewall is a Cisco Meraki MX250. DNS and DHCP are running on the aforementioned domain controllers.
How many devices total (approx) and mix between Zwave, Zigbee, LAN/Wi-fi
Mix of hubs. I'll give stats on the 3 that I can recall as having this issue. Hub 1: 4 Z-Wave Locks, 5 Zigbee Plugs, and some network devices (Wyzehub and Geofency integrations). Google Home integration. Hub 2: 3 Z-Wave, 0 Zigbee, and some network devices (Lutron integration and Samsung TV). Google Home integration. Hub 3: 2 Z-Wave, 0 Zigbee, Samsung TV network integration. Google Home integration. Hub 4 (Without the issue): 5 Z-Wave, 0 Zigbee, Samsung TV (network), and Google Home integration.
What user / custom integrations are you using for LAN/IP/Cloud based connections?
Google Home on all. Samsung TV on 2 of the 3, Lutron integration on 1 of the 3, Wyze and Geofency integration on 1 of the 3.
Screenshots of Past Logs from the incident, and also of any errors being generated recently.
Everything just stops logging when the device hangs. There will be a gap in the logs until I power cycle the device.
When I first saw the issue, I thought it may be network related (since the hub light was green, it was just inaccessible). I installed an app then that reboots the hub nightly to see if that would help and I've never disabled it (though clearly I could now). My only point in bringing this up is that app doesn't respond either, so it doesn't seem network related to me.
I've also not tried the backup and immediate restore so I will try that now on the 3 hubs where I've seen the problem.
The diagnostic tool is unreachable and the hubs do not respond to a ping.
That's about as much information as I can think of right this minute. I wanted to post this as I'm having the exact issue as UndercoverMarble in the linked thread and his backup and immediate restore didn't help. I don't suppose that means it won't help in mine, but since the issue only rears it's head every 2-3 weeks or so, I didn't want to wait to get this typed up in case someone else knows more about the issue and other steps could be taken in the meantime.
Thanks for giving the full details up front, it helps to paint a full picture of what might be going on!
I would disable the automatic rebooter app since it is not effective in solving the issue.
Obviously try the backup/restore, just in case that helps. Make sure you have downloaded a good backup in case something goes wrong with the restore (is rare).
The /30 network could possibly be an issue, for some reason the hub is not liking anything but /24 with DHCP. Would it be possible to configure it as a static IP on the hub instead to test? Just make sure you set the DNS properly.
Also, it was not in my Pinned post, since it is sort of advanced, but also make sure nothing in your network would be sending out Jumbo Frames packets that could possibly reach the hubs (possibly multicast). This would only be an issues for ethernet connected. Most common culprits are NAS devices or media/data servers.
Let me reiterate @jtp10181's suggestion to ensure that there is nothing on the same network segment as the hub that sends jumbo ethernet frames. A simple safe guard against this is to put the hub on an old unmanaged fast ethernet switch (i.e. something restricted to 100 Mbps).
I can do that for the ethernet-connected hub, but not for the two that are on Wi-Fi. I will say, now that I think about it a little more, the ones on Wi-Fi do seem to hang up more often than the one on ethernet. I didn't put it in the post above but 1 of the 3 problematic hubs is ethernet-connected and 2 are Wi-Fi. The 2 Wi-Fi-connected hubs seem to have the issue more than the 1 ethernet-connected one and the other (without the issue) is also ethernet-connected. I wish I could easily get a cable to the other 2 but I can't.
Regarding jumbo frames, I do know that we have a SAN that uses them. However, that SAN has its own network with them enabled (completely separate from the regular network). So we have 5 servers that connect to an independent switch that the SAN is also connected to and those ports are configured to use jumbo ethernet frames. But again, that network is totally isolated from the regular network and is for communication between the servers and the SAN only.
Is there an easy way to scan for jumbo frames? I assume Wireshark could do it but I'm a novice at best with that tool.
While Booby runs his play, one thing good to know would be the actual network topology especially relating to the Wifi equipment. Mesh system? Brand / Models of equipment? There have been some issues with Wi-Fi channel optimization that some routers/APs do, and when they change the channel the hub gets booted offline and cannot reconnect for some reason, but this may be better/solved in 2.3.6 firmware.
Those are good points. What actually caught my attention is that 2 hard-wired hubs behave differently. My first step is to narrow down the differences between the 2 Ethernet connected devices, then tackle the wireless hubs.
