C8 continues to lockup every 3 days or so. Can only be resolved by removing power, then reconnecting.
Running build 145 (updating to 146 right now - but release notes don’t indicate any changes other than zigbee graph).
C7 never locks up on the same network. I have mesh turned on, but had already moved all of my devices to the C8, so the C7 is “just sitting there”.
Really starting to become a problem since all the rules die when the hub locks up.
Thanks. I can certainly go through this process, however, this did not originally occur. It began to occur with certain builds (which others noted in separate threads).
When others were also experiencing this, I had a daily lockup….usually around 14:30…which does not coincide with any specific timed tasks, or boundary conditions for mode changes.
After one of the builds, but these are rather frequent currently so I didn’t track too closely, there was a step function improvement from daily lockups to only 1 every 3 days or so. Others mentioned that the lockups stopped for them,
But, 1 in 3 days is still a mess. The C7 never did this in the past, and the C8 was added via the migration (backup/restore) process.
Again, didn’t occur originally, but followed certain builds.
Since the C7 is not an issue I would assume JF is not the cause.
Is the C8 connected via Ethernet or Wifi?
There was a known issue with Wifi optimization performed by some routers where they scan and change the wifi channel. It will cause the hub to get disconnected if its on the Wifi and not reconnect. Not sure if that has been fixed yet in the recently firmware.
I appreciate the ideas and support. Hubitat warranty support has already setup a replacement and it is on the way (thanks Hubitat!).
A few additional notes:
C8 is connected by Ethernet, and I also added WiFi connectivity, right after initial setup.
For both connections I have the IP address reserved in my Eero mesh network (Eero Pro 6E).
After replacing the C7 with the C8, I set the C8 to use the same IP address that had been reserved for the C7, and moved the C7 to a different IP address.
I did this to avoid making additional changes for makerAPI (HomeBridge), and potentially webCore
I had seen the post regarding jumbo packets in another thread and had already verified that jumbo packets were not enabled on the network.
I had also gone through the various event and device logs and didn’t find anything that seemed to correspond with the lockups (error-wise).
Even though I didn’t see errors, I also just looked at potential events near the lockup. I did this by using “last seen” info from the Eero logs.
I found that there was neither anything out of the ordinary, nor increased activity at the time that the device became responsive. In fact, in general, it was pretty quiescent at the time.
One additional anomaly which may be unrelated, but is odd:
When powering back up after a lockup, my hub variables are not initialized.
I only have 2 hub variables setup, and they are both booleans
When I go to the settings page and look at them, they both show as false (which is how the default should be per settings during creation).
However, automations based on these (which are state variables used as pre-requisites) did not run (although they should have - these are only set to true while the automations are running, to prevent reentrant behavior).
After debugging this I found that these seemed to be in an indeterminate state, although the setting page showed them as false.
By manually toggling them (setting them to true, then false again) automation behavior returned to normal.
I was tempted to add an automation to force these to false with a mode change (since the automations are also limited to running in specific time-based modes). I was thinking to set them false on the first mode transition when these become active.
However, I did not do this because I wanted to revalidate the behavior as I installed updated builds.
Other steps taken, which have so far shown no difference in behavior:
- Removed some apps (currently unused) - webCore, HomeBridge (makerAPI)
- Removed a number of defunct user device codes (mostly zigbee-device related)
At this point I only have 3 user apps running (CoCoHue, Hubitat Package Manager, Kasa Integration).
User device code now only includes Zooz devices (various), CoCoHue, Kasa Plug Switch, and Modern Forms Fan and Light.
It now has fewer installed drivers and apps than the C7 had before migrating. It is pretty vanilla, and there are only 55 devices.
I am using the HomeKit integration beta (which I’ve not had any issues with). The use of HomeKit allowed me to remove makerAPI for HomeBridge (HomeKit was setup on the C7 prior to my migration.
Likely this is unnecessary info, but I would really like to understand the root cause, and others with far more knowledge or experience with Hubitat might have some additional insight.
We have had reports of Eero routers causing C8 hubs to stop working. The lack of obvious hardware issues on your C8 may be indicative of this very problem. If the new hub resolves the issue, then we know it was on the hub side. If the replacement ends up acting the same way, then the problem is on the router side. I hope the replacement resolves the problem, as replacing your mesh network devices might be a very costly effort.
While I can’t say one way or another yet whether the issue is related to the Hubitat hub being on the Eero mesh, I can say that my C7 was always on the Eero network, never did, and continues to never lockup.
If the problem continues with the replacement C8, this does not become a question of replacing the mesh. It become the challenge of determining the root cause of why the C8 (and only C8) has the issue, and then fixing that.
It isn’t that the problem is on the router side, it is that the combination of the two have issues. But when you aren’t having issues with any other device on the network, it isn’t something that you plan to fix by replacing the network.
I’m not saying that there can’t be anything wrong with the Eero and some very esoteric behavior comes out with that, but it may require working with them to understand this.
Unfortunately, I don’t have any sort of sniffer setup to pull detailed data off the net, but I am willing to provide data to help troubleshoot the root cause.
I was having sporadic issues with a thermostat (WiFi, not hub-based) on the Eero network, which I was able to pin down to having multiple access points that were signal-wise practically equidistant to the thermostat (insert reference to pomade procurement from “Oh Brother Where art Thou” film here). Eero has an option to not switch connection between different access points, but that can be problematic for my Apple watch for unlocking my PC). I resolved that by removing (“retiring”) the older (Pro 5) access point that apparently was resulting in frequent handoffs between two different access points.
However, the C8 is connected by Ethernet, and isn’t subject to this behavior.
I have also wondered about this, but it “felt” like a less-than-complete setup of the Hubitat, so I went ahead and added it anyway.
My assumption has been that the wired connection took precedence, but I was not aware that the WiFi connection will not act as a failover.
Currently, the wired and wireless connections are both pointed to the same Eero network (and are both on the same subnet).
By physical location, the WiFi access point should not be switching between more than device. I have not noticed the Hubitat WiFi connection being attached to any other than the device it is closest to.
If there is a possibility of the hub being confused by having both connections enabled, I can disable WiFi. I don’t recall why, but a possibly flawed recollection makes me think that I was being reminded about the lack of having WiFi setup.
I have thought that in the future I might potentially point the WiFi to a different network (e.g. secondary ISP), but I didn’t see too much value in this, since it would not be connected to the same network as the rest of my eco-system, and much of the value would be reduced. Therefore, I can understand how WiFi as a failover may not be as useful as it might seem on the surface.
I've always thought of the WiFi feature (via dongle for the C-7, built in for the C-8) as being a way to physically place the hub in a central location that wires didn't reach. It just happens that in my home, there is wired in one room and that room happens to be rather central, physically.
I tried the WiFi features (bought a couple of the dongles) and agree that it works, but I have no need for it and disabled it eventually.
I have received the replacement device (sans anything other than the device itself).
I was planning to repeat the steps of migrating, but in this case, I already have the C8, and want to migrate to the new one.
Since I technically have already completed migration, there is no longer an option available to do this. Unfortunately, the backup of the C7 is quite old at this point.
What is the best way to migrate from the current C8 to the replacement, without the migration option? I do not have the cloud service setup at this time.
