I've mentioned that (and sent screenshot) in a private message. I think that may be the issue as well.
I have two devices showing as Failed. I know I can ignore it, that it's a non-alarming status... to me.
The two devices I show with a FAILED status arethe two Aeon WallMotes I have. Both are battery devices, both almost never get used now that I have Pico's again. (The Wallmotes were an experiment in replacing Picos over on the ST side. They are great, amazing, and too big. )
I know from experience that if I just touch both those Wallmotes, they will wake, reconnect and turn on the device I have tied to the button. In other words, for those battery devices, FAILED is a transient state.
I would certainly be alarmed if I saw an A/C powered device as failed.
That's the "before"...
That's after I touched the Wallmote and it turned on the Light, as intended.
Devices with dead batteries also show as failed. Like my Aeon Multisensors 
I don't currently have any devices in the same state as you, @JDogg016
I certainly have had that.. just not in several weeks.
"Discover" means (to me) that the device exists out ON the USB Stick, but not in the internal Hubitat DB. Clicking Discover fixes that and puts that device (#9 in your case) back into the Hubitat DB. Therefore, "DEAD/Re-Initialize" is a matching status. The Hubitat DB has no idea what it is, so it calls it dead. Clicking Re-Initialize should kick the hub into figuring out the device is gone and offer the remove button. Clicking Discover should be reserved for "last resort."
I encountered one of those in my recent past. I had a device in the spares bin, knew I was never going to use it again and wanted to remove it from Hubitat. Same state as you're displaying BUT I know I wanted to eradicate it. Couldn't do it. @bobbyD and I tried "the dance" 4-5 times and it wouldn't go away. He got interrupted and didn't get back to me for a while and I really really wanted it gone, so I put the USB Stick into my OZWCP virtual machine and deleted it from there. Put the USB Stick back and it was problem solved, bobby was able to move onto a "real" problem 
That's all just my interpretation of how all this works... could easily be miles off...
Rather than speculate, I sure would like for the developers to publish some sort of "how-to" on what to do when you have issues with devices and what all the different states mean, both on the Device page and the device list on the z-wave settings page.
I'm also curious why device issues appear to cause all (or most, not sure) events to fail.
1 Like
Having said all that...I still LOVE my Hubitat hub! Every hub I've tinkered with has had issues, but the Hubitat is the only one that works exactly the way I want it to
"Almost Perfection" will be:
- Thermostat support in the Alexa skill
- Harmony integration
- More text messages than 10
- The ability to send email notifications
- Lock Manager app
- Thermostat (in one), color/temperature light, and Smoke/CO alarm (in one) tiles in the Dashboard
1 Like
Much optimization is probably possible that will speed the entire ZWave subsystem, and I am sure that Hubitat Team is aware. I was "lucky" in that when I got here, "Discover" didn't exist and my bumbling around highlighted a need and the Discover button was created. Now, months later, I bet that a more unified method has grown in their minds and (time permitting) a release will arrive that would "wipe out" the HowTo for today.
Again, my interpretation of the "shadows dancing on the wall."
1 Like
I do want to pass along thanks to all of you for thoughts and suggestions.
Iām looping @tonesto7 in as he created the homebridge app. Maybe he can work with support.
Someone from Hubitat please correct me if I'm wrong. I actually want to be wrong.
Of all of these rule issues I've seen since the release of Hubitat most of them have a single thing in common "time".
Based on the specs and details of what I can search for. The Hubitat box does NOT have an RTC and relies on NTP to sync the software clock. There is no configuration parameter either to change the NTP server or option to use a local time server.
The latest Hubitat release NOW can use your local browser to set time????
So the question stands can someone from Hubitat confirm Yes/No does your hardware have an RTC?
Can a lot of these rule issues be correlated back to a time issue?
Can we get a configuration parameter to use a local time server?
DHCP Option 42 (NTP) would be the 'normal' way of identifying a local NTP server.
Normal depends on the context of use.
I'm not going to get drawn into the debate of "normal" and the use dhcp. Yes I know this is a consumer hub and dhcp is normal in this context.
The use of DHCP to set the NTP server was not the question.
The question is around the NEED for it. Can it be validated that a NTP server configuration IS NEEDED and I don't care how it's configured.
I've been reading for a long time of these "weird" issues and they all have time in common and nobody has bothered to ask this simple question.
I put 'normal' in quotes to exactly imply what you point out...
Normal depends on the context of use... this is a consumer hub and dhcp is normal in this context.
You stated, not asked "There is no configuration parameter either to change the NTP server or option to use a local time server." and that's really the ONLY thing I was responding to. There is the option... via DHCP. That's it. Nuttin else to contribute. 
Well my statement still is true and valid as is your point of using DHCP to perform the configuration.
Random thought experiment: when I was on ST I understood webcore to function (sort of) independently of ST with respect to clocks and times.
Wouldn't the same logic hold true on HE?
Another way to say it. Does anyone in the community have issues with timed Pistons in Webcore? Bonus question: does anyone in the community have issues with timed Pistons in Webcore AND run homebridge?
Earlier today I added Homebridge back into my mix. Want to try that Presence suggestion. So that means I'm +1 on Homebridge, zero on WebCoRE, +17 on RM 'time of day dependent automation' (sunrise, sunset), +1 for local NTP (stratum 2).
Maybe that will help with the matrix of test result 'clues.'
Yes, the hardware has an RTC. From our testing it appears to be fairly stable and accurate, however it is not battery backed. There is an issue with NTP. This issue only arises when you run the hub without it being connected to the internet. We added the ability to set the hub time to browser time to provide a means of setting the clock without NTP. Other than potential clock drift causing the onboard clock to have the wrong time, there is no other reason that that absence of NTP would cause these sorts of issues with the hub. So while it may appear that these problems have 'time' in common, we don't believe that to be the cause.
There we go then. At the least it does have an RTC. The other issue of NTP having problems....
How bad are those NTP issues if a connection is lost for a short time? Is it doing weird things like resetting the clock to 1970 and then when connection restored setting it back to a proper time? If so that could cause some havok. Ehh probably not the issue but just wondering.
Good to hear there's an RTC, I thought there was, I hoped there was but I've just seen a lot of issues around time problems.
HE doesn't do any of this.
So I've removed homebridge (because I want HE to work properly) and updated to the latest FW. It will take about 10 days before the symptoms happen again, but they will.
I thought you determined there was an issue with one or more of your Z-Wave devices for which you suspected and several of us have suggested, that might be a cause. I seem to have missed your post where you determined that this was not the cause.
