Thank you! Just to be clear, are the Xiaomi devices themselves causing those issues or are their drivers causing issues? Because after first three or four unpairing events I couldn't be bothered to re-pair any of them and now they just don't work...
And how are those thermometers/devices incompatible? They worked fine with C-7, on the C-8 I noticed somewhat better RSSI strength while they worked... Thanks!
I think in most cases it has been found to be related to the implementation of the Zigbee protocal on those devices. Something about how it was impleted doesn't always play nice with HE and sometimes they kind of work under certain conditions like specific repeaters being used. I think some users adjusted the zigbee radio power to try to force their similar devices through repeaters with mixed success.
When it comes to Xiaomi, the devices are the problem.
Some people are able to work around their inherently problematic behavior, but it requires some combination of deliberate effort and luck.
This is what I have read as well, here and elsewhere. Xiaomi rolls their own w/the Zigbee protocol and it works w/their hub (which they would love you to buy) but they aren't interested in being widely compatible with Zigbee hubs that implement the Zigbee standard protocols. Sometimes they can work on HE, sometimes not. If you search for Xiaomi on this forum you'll find a number of discussions of the preculiarities of these devices and successes and failures...
However, I would not expect that trying to use them would lock up your hub. Especially with only 12 Zigbee devices total...even if the Xiaomi devices were being unusually noisey doesn't seem like enough to take the hub down, and don't remember any comments about that happening in the past w/the devices.
Not just Xiaomi but aqara as well.
T
True...I'm an example of the strangeness of these non-standard devices. At one point I got some Aqara contacts and buttons, but they failed so repeatedly on my hub (C7) that I gave away the Aqara devices. However, in the last year or so I have found success w/Aqara somehow on both my C7 and C8, but I still have no idea why Aqara stuff started working for me.
If I was going to start over w/one of the Chinese/Ali Express brands I'd lean towards Tuya, as @kkossev has made some very nice drivers for many of their devices, and provides info to help users navigate through the many different versions of Tuya devices that are offered from different vendors. Tuya is really more of a label under which many vendors create/sell their own versions of "Tuya" devices that can vary widely in terms of HW and FW used. W/Kkossev's guidance and drivers, some Tuya devices can now be solid players on Hubitat.
Moes has been pretty good, as as been neo coolcam
@DrRomca
I was having a similar problem with one of my old C3 hubs with it constantly locking up.
I thought it was possibly a faulty hub.
But after a lot of troubleshooting it turned out to be a faulty rule in the old rule machine legacy. The rule appeared fine but after I deleted it and rebuilt it in the new rule machine I have not had a problem for many months.
Unfortunately it was not easy to troubleshoot. It could be a faulty rule, device, or an app (I would put the risk in that order).
It takes a lot of time to troubleshoot.
I started by disabling rules (you do not need to delete them for the test). You may have more than one bad rule try disabling all the rules and leave it running for a week or until it locks up.
If it still locks up then the issue is liking due to a device. repeat this process with the devices then with apps.
If it didn't lock up after a week on the first test the issue is in the rules.
Start by disabling half of the rules ( I both paused and disabled them just to be safe).
I then left the hub running for a week or until it locked up. If it locks up it is one of the active rules then try disabling the rest of them and re-enabling (and resuming) the previously disabled ones and do the same test. Once you determine the group start by breaking them down into smaller and smaller groups and repeating the test.
proccess of elimination but if there is more than one it will make this much harder.
Sorry but I need to add my 2 cents (+$160) into this thread.
My C8 has been locking up about every 3 days. Solid lockup, no network response, but will recover after a power reset. Not fun.
I'm sure someone will sort this out at some point in time, but...
This device should have a heartbeat or monitor in the system to 'restart' when it becomes unresponsive. Considering how this device is used in controlling devices in a HOME or OFFICE, it should be able to recover and restart automatically. Most microcontrollers have the ability to perform a soft or hardware reset when processes become non-responsive. There are always going to be problems in new hardware/software and it takes time to chase them down.
Most likely, there are problems that cannot be fixed in C8 and it is not economical for the company to replace any of the hardware. Its better to have a device reset and recover than die and sit there while nothing else works.
The Hubitat devices have a great community and an architecture that opens it up for development and hacking. This along begs for the device to be more robust in recovery.
It's not about jumbo frames and POE power plugs, it's really about how the device handles the problems when they show up. The C8 should be more robust than this.
It is very robust, but even pc's blue screen due to bad software or drivers. You need to find what is causing the issue. Having a heartbeat monitor rebooting stuff isn't necessarily good as it can cause corruption. I've had a c8 since beta and I've NEVER, NOT ONCE had it lock up. Had one zigbee radio restart issue that was caused by a bad sensor and one that was caused by a lan integration. I have close to 200 devices between z-wave, zigbee, virtual, and clear connect. The majority of people don't have issues, only a small percentage. Hubitat cannot cover all mixes of devices and software. If you are having a problem with your hubitat crashing every 3 days, you need to find out what's crashing it and why.
Thanks for your feedback. You are making (some) assumptions without actually knowing if they are valid or not 
We do not want to systematically 'restart' or 'reset' a hub when it becomes unresponsive, because that would mean to apply a 'band-aid' to potentially larger issue. The number of hubs going unresponsive is very small, and we want to investigate each incident to determine the actual root cause. As I am sure you know, determining why the hub became unresponsive, is the first step towards implementing a permanent solution.
A systematic reset is exactly what you. You can log any issues (detected by a process monitor) and then reset. Its not a 'band-aid' its a system process that ensures that the device stays operational.
I believe that you are looking at this like it's a PC issue. It's not. It's a microcontroller. The comments about "Not a lot of people have this problem, so it's not worth doing" is extremely short sighted. Maybe at some point in the future, there is a bug in an update or driver that causes a larger problem. This is about making the box reliable even while you look for issues and problems.
It's not that difficult. It's more difficult to deal with frustrated users and user boards that question the hardware. I am one of those users who upgraded to the C8. I never had a hung system until I got this model. Is it the hardware? Is it the drivers? Is it the Apps, libs, settings, network, bad sensors, bad switches, bad .... there is a lot of bad. I don't believe it's the C8 (fingers crossed) but it would be nice if I could depend on it keeping the automations running while I sort out the nature of the real problem.
Stop thinking like a PC and more like a microcontroller, which is what it really is...
It’s not a microcontroller with an embedded OS.
The closest comparison would be to an SBC running Linux loaded from an eMMC. The hub platform is layered on top of that in a Java Virtual Machine. I think that @rlithgow1’s description of the hub as a PC is an apt description of the hub’s hardware/software implementation.
Well, not quite. It is a Linux based OS (PC) running on a single board computer/motherboard. It has a full file system, applications installed, drivers, java vm, database, etc, loading from external storage. AKA - a PC.
Far from how most embedded systems work (I know a bit about this as I make and support embedded systems for a living). There are very few (maybe none?) consumer hubs/controllers that are actually traditional embedded systems/microcontrollers. End devices are usually much more like embedded systems/microcontrollers, but the hubs are not.
Think of it like one of the many amlogic S905 based boards floating around out there (used for Android TV, et al), and you are in the ballpark. A low power Linux PC. Not saying that is what is in the Hubitat hub (as it isn't exactly), but that is the closest non-proprietary example I can give that someone can google a picture of.
I am not sure who you are quoting, but I don't think anyone said that finding a solution to the limited number of incidents is not worth doing. What has been said is that a systematic reset or restart is not a permanent solution. Instead finding the root cause and solving the problem is worth much more, because it is the only long term solution.
I think I’ve been having similar issues and support stopped responding to my thread. I’ll start following this one I guess…
No, your issue is not the same:
My C8 hub also locked up repeatedly when connected via WiFi. I followed all the suggestions from the ambassadors and support. The only thing that worked was to use a wired connection and not use WiFi. It has been several months with no update from Hubitat on potential fixes to allow me to use WiFi. I don't have any Sylvania bulbs or "problematic" devices.
I see that A19 dimmable Sylvania bulbs are listed on compatible devices, which is what I have. I never these issues with the SmartThings Wifi unit I had, is there a reason that the C-8 is susceptible to this?
It is not just the c8. The issue is that they are zigbee ZLL 1.2 bulbs. They do not play well with ZHA devices (sensors and what not) as they make very bad repeaters and messengers. The exception to this are Sengled bulbs as they do not repeat and zigbee 3.0 bulbs are fine as well. The recommended solution is to either use a Hue bridge or another hubitat to isolate them on their own mesh.
Download the Hubitat app
