Lights turns on after "unavailable" - started recently

Configuration Z-Wave
1

At around 2:21am every morning for the last several mornings, I am being woke up by a light being turned on.

Screenshot 2020-11-05 073138
Screenshot 2020-11-05 073138466Ă—553 14.1 KB

Facts:

  • My server does maintenance around this time, and the history confirms the Z-Wave light switch goes Unavailable shortly before its state changes to On.
  • My other GE 14294 dimmer, my 2 GE 12722 switches, and my Inovelli Red Series dimmer all return to the Off state after going Unavailable.
  • Logbook shows no automation being triggered by this state change, so it is seems like the switch is defaulting to turning itself on.
  • Looking through OZWAdmin there doesn’t appear to be a Default On setting, nor is there any differences between the config between the Bedroom and the Laundry (GE 14294) dimmers.
  • Home Assistant 0.117.4, with ozdaemon docker image outside of my Home Assistant VM.

For now I am out of ideas on what else to look for. Do you have any suggestions?

2

OZW uses mqtt. 90% sure you have a retained message in the state topic for this device.

You wont notice this message until a disconnect from the MQTT service. All other times it will work perfectly fine.

Use MQTTExplorer or something to check these messages. Or, just send an empty retained message to that dimmer’s state topic from Home Assistant MQTT config section. That will clear the retained message.

2 Likes
3

If ozwdaemon misses a keepalive message with the MQTT broker it will disconnect and restart. That’s what makes the entities go unavailable, as HA changes their state until ozwdaemon is back online. I noticed this on my Raspberry Pi, ever night it would disconnect and narrowed it down to a backup process that was consuming too much CPU and network.

Do you have any group associations with the switch as a target that would cause it to be controlled?

I would look at the ozwdaemon logs at that time the switch is turned on and verify if it was an external process (like HA) that is turning on the switch.

1 Like
4

According to MQTTExplorer the message was not supposed to be retained. However, clearing the message seems to have resolved it! I have stopped and restarted the Mosquitto and ozdaemon (in different orders) servers 3 times, and the light has stayed off all three times! Thank you!

5

Thank you so much for your suggestion. I was able to resolve it.

6

What was the message? Was it a retained setvalue command?

7

By “message” I was referring to the stored data. MQTTExplorer showed a great big yellow RETAINED message on some of the other data that was stored, but not the value in question.

8

Nearly all, if not all MQTT topics published by ozwdaemon are retained, that is how it is designed. None of those messages control it though. I was asking which retained topic you were referring to that was causing the switch to turn on.

9

Here is the topic and a sample value.
OpenZWave/1/node/6/instance/1/commandclass/38/value/105480209

{
    "Label": "Level",
    "Value": 99,
    "Units": "",
    "ValueSet": true,
    "ValuePolled": false,
    "ChangeVerified": true,
    "Min": 0,
    "Max": 255,
    "Type": "Byte",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_SWITCH_MULTILEVEL",
    "Index": 0,
    "Node": 6,
    "Genre": "User",
    "Help": "The Current Level of the Device",
    "ValueIDKey": 105480209,
    "ReadOnly": false,
    "WriteOnly": false,
    "Event": "valueRefreshed",
    "TimeStamp": 1604620001
}
10

The values are all supposed to be retained. It doesn’t control the light, it shows the current value.

Glad your problem is fixed, just curious how that actually fixed it. Seems like something else was going on. :man_shrugging:

11

I cleared that value. I sure hope its fixed. My tests suggest it is fixed. But I won’t know for sure until my maintenance process shuts down the Mosquitto and ozwdaemon around 2:21am.