I have, for lack of a better description, a ghost in the machine...
Like most of us currently using HE, I came from ST, where I had been using it from shortly after the Hub V2 release. As such, my light switches are antiquated when compared with some of the newer switches available. But they were all purchased en masse at the time, which me acquiring some newer z-wave+ models on a very limited basis.
So yes, I have to admit my switches are predominantly GE 18770 & 18756. And they all share an inherent problem, that being they do not adequately provide feedback to the hub on their status; by now a well known issue.
To this end, as mentioned by both Mike (@mike.maxwell) & Bruce (@bravenel) [in various other topics] ST worked around the issue by implementing a refresh cycle of sorts every x seconds, and I believe it was Bruce that advised to do something similar in RM. To this end I refresh all these switches currently on a 12s cycle.
The Ghost in the Machine is that these switches, with absolutely no discernible pattern or frequency, will turn ON... Never off if a switch happens to be on already The worst cases are the ones that occur at 3AM... It is worth pointing out that there is the odd GE switch this has NOT happened with at all, and some GE switches where it also appears to occur more frequently than with others.
Note that this never, ever, happened in ST, ONLY since I moved them to HE & started using RM to refresh them.
Any idea as what can be causing this? More importantly how to track & stop the cause. The logs, at least for me, have not proven a help (well mostly because I am fast asleep at 3AM!! ) Perhaps a better way of tracking the the cause?
Maybe 12 seconds is too much for switches of that vintage? I know it will impact you, but have you tried 30+ seconds just to see if it makes a difference?
Maybe -- open a live log tab, set Refreshing Rules to be 30+, go to bed. In the morning, check the logs, reset Refreshing Rules to 12 -- something like that for debugging?
I also have a good collection of those museum worthy GEs and I refresh at 37 seconds.
For actions that driven by switch state, waiting as per your recommendation, for +30s will be "like forever" until the switch state is refreshed & something else occurs. Unless I am misunderstanding the inner workings, in situations where my RM rules are waiting for a particular state, does this not make them unusable effectively?
Other issue that yeah, I can try to do so & go to bed; still no guarantee it'll happen. Like I said, no rhyme or reason...
ST V2 hub polls every Z-Wave device on a 10 second interval.
This could also be due to the switches failing (how else can you explain a refresh() causing it to turn on?). These vintage of GE were not very good.
The only reason you need the refresh quickly is to catch physical events for automations. For just having the state updated, it's unlikely that 30 seconds will matter. And, this is only in those situations where the switch is manually operated.
Yes, I haven't really noticed a strain with a 12s refresh cycle.
I have resorted to other means to trap physical vs programmatic events, most of the RM rules rely on a companion virtual switch for programmatic execution / trapping.
Could they be failing? Maybe, sooner or later all things fail. But would one not expect a device in the process of failing to make it a more consistent event? The absolute randomness of the events, IMO, doesn't support this... or perhaps it does. I simply don't know. As time and when funds allow I will start replacing the more "error prone / erratic" switches. As it currently stands, there is only about 2-3 events per week. It is the 3AM ones, as mentioned that drives everybody up the wall. And makes switch monitoring with HSM very problematic...
Edit: As mentioned, it never happened once in ST. I've only been on HE for maybe 4 months...
If this is something caused by Hubitat Elevation, you should be able to find an event in the logs that doesn't belong. And you would expect that other users would be reporting something similar on a fairly regular basis. I'm not saying that it is not caused by Hubitat, but would like to see some evidence of causation.
The one suggestion I'd have would be to examine quite closely every automation that touches these ghosting switches.
I did have a particular that would turn in randomly. This was one that had a refresh rule tied to it. I worked with Bobby in support and we never figured out the issue. I ended up replacing it with a Plus model.
But one thing I suggest is putting a timeframe around your refresh rule. You need to consider if you really need to refresh the switches in the middle of the night when the likelihood of turning them on physically is low. I use mode to restrict my refresh rules and don’t when in night mode. This should help with the random light in issue.
Others use Motion to trigger Rules that refresh in an area. Kitchen motion? then refresh the devices in and around the kitchen. Garage door opens? Refresh "downstairs", etc.
I did change the refresh mechanism yesterday after the discussion with Bruce.
In a manner of speaking I did implement what both of you suggested...
Tied the refresh of GE only switches (non-plus models) to motion events, which in effect also restricts the time of day things gets refreshed indirectly by extension.
I suspect it will be better this way using motion events.
I also wonder how many people on HE really have the older generation GE's. I suspect most either have a different brand or the newer ones. That may be why there has not been many people reporting this issue.
I have a bunch of older GE Z-Wave switches, but I don't use Physical Switch events in any of my automations that include these switches. Most of my automations are triggered by sunrise/sunset, door contact sensors and motion detectors. The automations turn the light on and off regardless of the existing state of these early z-wave switches. While not an ideal situation for everyone, it works for me. This may be part of the reason why some folks aren't too bothered by it.
Exactly the same for me. Zero switches (state of) are in any of my Rules. So technically I don't care what the Hub thinks the status is. However, one of my Dashboard pages shows them all and visually it's an issue. I run the Refresh routines so that the fewest number of them show wrong on the rare occasions I look at a dashboard.
I had one of my Z-Wave lights turn on by ghost yesterday. No evidence in the logs of it happening. It's clear that the hub did not command it, nor did the device report it. The fact that the device did not report it suggests a device glitch, not a mesh network glitch.
I've got a bunch of little factoids, but in summary, I was seeing ghosts when I had quite a few secondary controllers. Now, I have none (active) and I see no ghosts.
My home, til relatively recently, had multiple secondary controllers. While in my head I think I have everything off, in truth, there's a ZStick powered up and a Minimote. Neither SHOULD be able to cause ghosting, especially the Minimote.
The ZStick is a secondary and it's powered BUT there's no software active to drive it. (It's plugged in ready for me to launch a Virtual Machine and run either Zensys Tools or OZWCP.)
6 months before I got Hubitat I had a pretty regular ghost visit for one of my lights. Randomly, once a day, it would turn on. I would see it, think, I need to find my phone and turn that off... and then forget. Hours later, it would still be on. In other words, the ghosts turned things on, not off.
Over time, I've shut down all the secondaries I had back then: Wink, SmartThings, OpenRemote, Staples Connect. Same light, same Zwave device, Never has a ghosting problem in 3 months I've been on Hubitat only. All those previous controllers are shut now. The ZStick that was on OpenRemote is now the one that is powered up.
So I've been happy to blame the previous set of devices for ghosting, since I haven't actually noticed a ghost recently.
