Based on your hub's engineering logs that only go back to 9/7, you've had at least 10-15 crashes every day. since. The 2.3.6 update came out on 9/20, so the problems you are having started long before 2.3.6. You are dealing with a problem that can be solved by eliminating devices that may cause the radio to crash, or simply your radio is bad and the hub needs to be replaced.
5 Likes
yet 1st time after after noticing the problem on 2.3.6 i stayed on 2.3.5 for days without issues and used 2.3.5 for the entire night last night with no issues and 2.3.6 never works past an hour.
Also keeping in mind the zwave crashes notice how i can control my light from dashboard instantly and produces a status change even 30 mins after all reports stopped from the bug. So why devices report status change when controlling them manually but they stop reporting status change on their own ??? If zwave radio is dead my logic tells me i should not be able to control any device and the hub would not receive any device status change no matter if they are manually or automatically triggered.
Given the number of daily crashes, the radio is able to recover on its own, but your experience must be terrible with huge delays and times when devices are simply unresponsive. They work between crashes, but if you try to use them when the radio has not recovered yet, they wouldn't work. Eventually, the radio will drop off and not be able to recover. I wouldn't wait for that day, if I were you. I would try to isolate the devices that could cause the radio to drop offline, or replace the hub to eliminate the possibility that the hub itself is the problem.
3 Likes
Here is an idea. Update your other hub to 2.3.6 and see if it runs into the same problems. As you said, your other hub has the same mix of devices. I checked its engineering log and the hub is free of any errors. I guarantee you that 2.3.6 will not have a negative impact.
3 Likes
my experience was perfectly fine until 2.3.6 update.
Anyway for the 1st time i'm getting somewhere.
As i said earlier I have noticed a motion sensor being almost everytime the last one to report just before everything stops working, i noticed it from yesterday and changed its driver with no luck but today i unplugged it and so far it's been 2 hours and the hub still working fine, it never worked for more than a hour until now.
So i'll leave it running for awhile now to make sure everything is good then i'll try to exclude/reinclude that sensor and see what happens.
It still doesn't explain why the problem appears only on 2.3.6 but i'm least i'm getting somewhere with the fix.
1 Like
Ok I just picked up on this thread and read through completely. Lots of awesome people on this forum.
But now it like hitting a “to be continued” on a tv show.
10 hours and no update. I assume that is a good sign.
3 Likes
yep so that motion sensor was the problem and caused the crash.
Excluding and reincluding it fixed the problem so there's no hardware problem with the sensor, not sure what caused it to go crazy in 2.3.6 but now the hub has been running for over 12 hours with no issues.
Thanks to everyone but mostly thanks to me for noticing the sensor.
Staff doesn't seem too involved in proactively fixing bugs, reported a simple to fix bug 1 month ago and remained unfixed Mode not syncing in mesh
Glad you were able to isolate the problematic device. It's odd that a sensor was creating havoc in your mesh. Is it powered by usb?
As for "fixing bugs," what you are requesting in the other thread is an enhancement. The Hub Mesh is working as expected. It would be nice to have the modes sync on startup. We noted the request, but is not a top priority to be implemented, at this time.
2 Likes
FWIW I had a MS6 go bad and it caused strange problems with my Zwave mesh. I had 2 in production and they have always been very chatty devices and have since removed them as I don’t trust them.
2 Likes
I've seen MS6 sensors causing latency and hub freezes, however, I've never seen a sensor taking the radio offline. That unusually happens when repeaters go bad.
1 Like
I documented my wierd issue here:
2 Likes
is not an enhacement , the 2ndary mesh hub should always be in sync with the main hub, that's why all devices have a fail safe that checks their status every few mins, mode is skipped and not checked regularly or on startup like other devices so it seems to me more like a bug and i'd be very thankful if is fixed.
they are chatty as they have many sensors but are the best I could find with permanent usb power, I',m not changing batteries to dozens of devices .
But you can use their parameters to disable many reports, I have most reporting only motion and temp every 15 mins so not chatty in this case.
So just curious did you also try changing to a regular power supply or is it still using the router USB port as you were before?
4 Likes
still using router usb port like it did for years, the router has only usb 3.1 ports
1 Like
That has not been my experience.
Take the last major platform release for example, version 2.3.5, which coincided with the release of the C8 hub.
There were 22 hotfix updates that were released over a period of four months. Every one of those updates included bug fixes and additional platform updates in response to issues reported by users.
The current hub firmware was released three weeks ago, with previously known bugs squashed in the initial release, and there have been about 10 hotfixes so far.
You can review every firmware release thread and see the same pattern.
If you’re really bored, you could also look for all the threads in which a staff member acknowledged a reproducible bug reported by a user, committed to fixing it in a platform update, and in many cases followed up in that same thread to confirm with the user that reported the issue it’s been fixed.
A bug is when software behaves unexpectedly from how the developer intended. If a user doesn’t like how the software behaves and would prefer it do something else, that’s a feature request.
7 Likes
So, hub mesh which whole propuse is making more hubs work like 1,syncs all devices between the hubs when are both online, syncs the modes when they are both online, but if a hub is offline then boots , syncing only devices without modes is a feature? That makes sense to you? Ok then excuse me then for asking for new features.
For some people, yes; Hubitat is an event-driven system. If one hub is off and misses the event, it does not make sense for all use cases to generate an event at some later time. (There is no disagreement about the fact that some use cases may also need different behavior.)
In not sure where your attitude comes from. The feature request was not rejected; on the contrary, it has already been noted as being "on the list."
Backtracking a bit...
You might want to re-think this position as well. You initially claimed this was a Hub Mesh problem and had to be begged to share more details that helped other people figure out you had a different problem. Finding the Z-Wave crash (as also confirmed by staff) and the likely culprit of a device based on logs (which you were already asked to look at but were hesitant to share any details about) was indeed a good find on your part. But I'd be more appreciative of people who helped me get there, personally. 
8 Likes
Thanks everyone for your inputs and support. This topic is, for the moment resolved. @ady.adrianu if you have any more problems with your Z-Wave devices, please let us know. Until then, this topic is being closed.
5 Likes
