C8 Hub Disconnects from network

🛎️ Get Help
1

Hello all,

I bought my C8 hub on Oct 2023, all worked ok when started using it, then right after the update that came with Matter, I did the update and connected the hub to WiFi, and then it started having random disconnects from the network, nothing responds and automations also stopped working.

While it was connected to WiFi, it was totally unresponsive (I didn't have access to the diagnostic tool either), I tried using soft reset and restoring database, but it kept going offline again with no way to connect to it.

So, I changed it to Ethernet and did another soft-reset to make sure the database was not corrupted, which extended the time available (I was hoping it wouldn't go offline again) but it still got disconnected although this time I was able to reset it using the diagnostic tool so that the database would not become corrupt (I still had no automations available)

Also please note that I have the IP reserved in my router and no other device can get it since DHCP is in a different range, hub is on the latest 2.3.7.145 firmware, not sure if this is useful: I have OPNSense for router and unify for switch and access points, also at all times I only used either WiFi or Ethernet, never both at the same time.

I believe I tried what was told to be done from other posts, but since I am not getting anywhere, I would like to request some help to see if I am missing something else to try.

Thanks

2

Hello, sadly I lost network connectivity to the hub again (after around 12-15 days), nothing changed during those days, no extra devices or changes in automations or anything, (I don't remember exactly the day I did the last step I mentioned in my original post).
Today's steps were:

  • Reboot-hub from Hubitat Diagnostic Tool (which luckily, I still had access to, also the led is green)
  • Created and downloaded a backup
  • Another soft reset (just in case db still needs that) by Rebooting on the main menu by selecting "Rebuild database on reboot" (which according to the help manual this works the same as soft reset and restoring the backed-up database)
  • Updated the hub to 2.3.7.146 firmware

I guess I can just hope these steps are the last ones to have the hub more stable.

3

You should consider scheduling a weekly reboot.

1 Like
4

Does this mean you also configured the same static IP address directly on the hub’s network settings page? And configured the hub’s gateway, subnet mask and DNS servers on the same page?

What’s the DHCP range of addresses and what address is your hub set to?

5

Hi, thanks for your reply, here are the details of it:

The LAN network range is: 10.7.4.1 - 10.7.5.254 (10.7.4.0/23)
The DHCP service assigns IPs from 10.7.5.11 to 10.7.5.254
And the Hub has a reserved address at 10.7.4.131

I have not set the IP as static in the hub since it would not allow me to, it complained that the IP set did not belong to the IP range selected (although all was set correctly) but since all was working ok with the reservation, I have not done any further tests to raise that properly here.

Thanks

6

Hi, would you say that your suggestion with a rule using http-post is still the best way to achieve this?
(I found your suggestion at: Auto Reboot - #3 by aaiyar)

Is this the common behavior of HE hubs? I would be relieved if it's not a hardware issue, but I am not sure how to confirm that nothing is wrong with mine.

Thanks for your help.

7

This is what seems strange to me, although I’m certainly not an expert.

The hub defaults to DHCP unless set to a static IP from the network settings page.

So how does it successfully obtain the IP address from the router if it’s outside the DHCP range?

I think this is likely to be the root of your issue, one way or another.

Networking is @rlithgow1’s thing. He might have more of an idea of what could be going on.

1 Like
8

That config for a static directly on the hub shouldn't be an issue. What's the gateway addr? (I assume 10.7.4.1)

9

There's nothing wrong with your hub. The hub platform runs within a Java virtual machine (JVM). JVMs (running on any hardware) are notorious for running out of memory over time, and require a periodic "restart". The frequency of that event is driven by the complexity of devices/automations.

A weekly reboot is not an unreasonably high frequency.

1 Like
10

Hi, that is how DHCP server works when reserving IP addresses (at least in OPNSense) you need to have a range for actual random IP for clients and another for the reserved ones so they do not overlap (you can say DHCP has access to full range and it is selective)

11

Hi, yes 10.7.4.1 is the router/gateway
Thanks

12

No, you didn't lose network connectivity to the hub. If you had, you wouldn't be able to reach the Diagnostic tool either.

Rather, what happened is that the hub platform JVM had crashed or stopped running for some other reason. While the JVM that the Diagnostic Tool runs in was unaffected.

This observation drove my initial suggestion that you should perform a weekly reboot of your hub.

2 Likes
13

The hub makes that "complaint" when dealing with subnets other than /24. @hideki_c is using /23 - perhaps they have more than 256 IP-connected devices and need a larger subnet for a flat network topology?

14

Ohh thanks a lot for explaining, I'll setup the weekly reboot in the rule machine.

1 Like
15

Yes I had many devices not like a huge number of them but kind of wanted to "keep things in order."

1 Like
16

Thank you all for your replies with the suggestions and giving me some peace of mind explaining why it was like that.
For now, I have setup a schedule using a rebooter found in HPM (I have selected to only restart the process to test how it works).

As for the /23 subnet, will there be an update supporting it so I can later set the IP as static?
Thanks

1 Like
17

This is a good point and I may have missed it, it’s true that network connectivity is unlikely to be the primary issue if the diagnostic interface remains accessible when the primary interface isn’t.

1 Like