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.
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
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."
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?
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.
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.
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.
When you had removed lots of devices and it was stable, perhaps it would have been better to introduce your devices in a slower manner. That way you would have a better idea of what device caused the issue to reoccu rring urring ur.
What I am saying is that I originally believed it to be related to Homebridge. I installed homebridge adding all devices that I would use. That broke things. I reintroduced homebridge in a number of ways each time causing the issue (thus a very extensive thread of homebridge in this forum where others acknowledged the issue).
However, I have come to also realize that the issue is coming up whether I have homebridge installed or not, it just takes longer to manifest itself. I realized this because I had this problem and documented it to support about a month before I ever installed homebridge and several homebridge users don't report this being an issue.
I almost think of it as an old Microsoft Windows memory leak. If you have some program/task running in the background that is slowly eating away your memory you may never realize it is there... until you run some memory intense program in windows. Your first thought is to blame that memory intense program because every time you run it Microsoft Windows would crash. That example seems way too analogous to the current situation as I think Homebridge might be that memory intense program in HE.__
The reason I never noticed the issue, absent homebridge, was because the HE team constantly releases firmware updates (at least every 10-12 days which is a nice thing). When I update the firmware I reboot HE and whatever is causing the issue stops before it has the chance to truly manifest itself.
All the Homebridge (Hubitat) App is doing is sending HTTP requests to Homebridge Service on every subscribed device event with the specific change.
I can see this being an issue if you have 200+ highly active devices where is just constantly sending device events. Beyond that, I really struggle to see how it's the Homebridge (Hubitat) App causing the schedule execution issues.
