I don’t think this is an openhab problem; but wanted to get some zwave expertise.
I had a power outage briefly Sat; lights flickered; as usual, all my zwave bulbs turned on when the power came back on; EVER SINCE THEN, the zwave bulb in my lamp next to my bed turns on every morning at 2:20ish am; there are no rules doing this; nobody is turning it on with the dimmer switch; i only have one rule and that is if i say to alexa turn on the bedroom light; it sends a command to the dimmer to set it to 100. Debug log is way too big to post here; even just 2:20 to 2:25 AM is too large to paste. Thoughts? Also, a network heal starts at 2 AM. Thanks
Restart OH as maybe it has some weird happening and it could set the time for the light turning on to a different time rather than in the middle of the night.
Remove the Thing entry and add it back in
Change the time on the OH system to see if its based on the hardware clock
I have the same problem with a my zwave bulbs (LB60z1) and it is related to the network heal. For me it only happens occasionally, but it is annoying. The heal does not start exactly at 2AM. Luckily mine were not in the bedroom. What I did is 1) disable the network heal (If nothing has changed, it is unnecessary) 2) If I do heal I moved it to 5am, so when I get up I can turn them off. 3) Created a cron rule to turn them off at 6am (usually a 5am heal is done by then), in case I sleep in.
for a bedroom light, I’d suggest moving the network heal (if you feel you need to do one) to the early evening.
Look in your events.log for Thing updates at this time. This kind of symptom has been seen when the binding has been updated at some time with new device spec in the database. When a heal is performed it discovers the device no longer quite matches a pre-existing Thing definition and reinitializes it.
Thing renitializing has knock on effects in turn.
My understanding from the Dev is you need to delete & re-add the Thing too get new settings. That would not happen daily. The database would only be newer after loading a new binding version.
Sorry should have included some things I’ve already tried:
OH Restart; that has happened already; still persists
Re-Adding it - I previously exlcluded it, and readded it and mapped the dimmer item back to the new things - still persists
Yes, and when a Thing updates it reinitializes, which has knock on effects. At the simplest, linked Items will be updated, which may invoke rules, etc.
@milty456 Just see if there are ‘Thing updated’ in your events.log, if not this is a goose chase.
Hmmm - I don’t think that’s right. The binding will not update the thing definition unless the thing is removed and added again.
No - not normally. The protocol part of the binding and the “openHAB” part are separate. Updating the “thing” will not cause the protocol stack to reinitialise.
That is true, however if the update is “instantaneous” - by which I mean the binding wasn’t stopped for 5 minutes, then any update should not cause a state change.
Yep - if rules are trigged by an update rather than a state change, then this could happen, but that is no different to things like regular polls which normally occur at some interval around every hour.
I would suggest to get a debug log - events logs are not particularly useful for diagnosing these sort of issues as you want to be able to see what is really happening in the binding.
I have noticed at start up the binding is treating node 1 as a slave which i assume is most likely your controller . Interestingly the node update is a mess also
2021-02-25 02:10:25.453 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 1: Node Status event - Node is DEAD
2021-02-25 02:10:25.453 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 1: Node is DEAD.
2021-02-25 02:10:25.453 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 1: Node Status event - Node is DEAD
2021-02-25 02:10:25.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 1: TID 3002: Transaction completed
2021-02-25 02:10:25.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 1: notifyTransactionResponse TID:3002 CANCELLED ```
But I do not think that this is your issue but that log is nasty.
What node id is the issue?
