[bug] Scenes retriggers after zwavejs2mqtt restart

[haavardNO]

Before submitting a bug please read: https://zwave-js.github.io/zwavejs2mqtt/#/troubleshooting/bug_report

Version 1.0.1

Build/Run method

• [X] Docker
• [ ] PKG
• [ ] Manually built (git clone - npm install - npm run build )

Describe the bug

As discussed with @robertsLando I am creating a separate issue. When restarting the application Home Assistant will re-trigger a scene, and in my case open my garage. Looks as the "0" state is set back after restart, and this is what is used as trigger. I think the zwave2mqtt version used "inactive" as the default state, and changed it to 0 only when triggered, then back to inactive. Maybe this could solve the issue?

To Reproduce

I have this issue with a fibaro keyfob that is used as a scene controller. I have the following automation in HA

alias: Garage open keyfob
description: Open garage from keyfob
trigger:
  - platform: state
    entity_id: sensor.garage_keyfob_scene_state_004_scene
    to: '0'
condition: []
action:
  - service: script.garage_open_if_closed
    data: {}
mode: single

[robertsLando]

@haavardNO Fix ready

[haavardNO]

Tried with the latest version now. 1.0.5, and there is still something strange going on.

Below is a screen capture from home assistant before I restart zwavejs2mqtt:

Then I delete everything in mqtt explorer that contains keyfob, and get the following in HA:

Then when I restart the docker image states are again inserted as below:

Any suggestions what is happening here?

[haavardNO]

Also, just as a reference I use the settings below:

[robertsLando]

Any suggestions what is happening here?

Did you delete all retained messages from mqtt broker right?

@billiaz Could you help in this?

[varet80]

Let me check if my Scenes retain of course I can!

[varet80]

@robertsLando I do see these getting retained on my broker too. But without value!

[varet80]

@haavardNO state 0 means inactive right? should this be empty? I see MQTT refreshes value and cleans it after 1 second but the payload is there without value.

Looking into my Button from Aeotec I have this

{
  "type": "sensor",
  "object_id": "scene_state_scene_001",
  "discovery_payload": {
    "state_topic": "zwave2mqtt/MasterBedroom/VassilisSwitch/91/0/scene/001",
    "value_template": "{{ value_json.value}}",
    "json_attributes_topic": "zwave2mqtt/MasterBedroom/VassilisSwitch/91/0/scene/001",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xcddb486e_node60"
      ],
      "manufacturer": "Aeotec Ltd.",
      "model": "NanoMote Quad (Aeotec NanoMote Quad)",
      "name": "MasterBedroom-VassilisSwitch",
      "sw_version": "1.2"
    },
    "name": "MasterBedroom-VassilisSwitch Scene 001",
    "unique_id": "zwavejs2mqtt_0xcddb486e_60-91-0-scene-001"
  },
  "discoveryTopic": "sensor/MasterBedroom-VassilisSwitch/scene_state_scene_001/config",
  "values": [
    "91-0-scene-001"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "sensor_scene_state_scene_001"
}

most probably this: "value_template": "{{ value_json.value}}", returns the 0

can you share with us your node export and also the specific MQTT payload under the device?

[haavardNO]

state 0 means button press. So the system triggers on state 0. When I press the button the 0 state disappears after a short while.

id: 71-91-0-scene-004
nodeId: 71
commandClass: 91
commandClassName: Central Scene
endpoint: 0
property: scene
propertyName: scene
propertyKey: '004'
propertyKeyName: '004'
type: number
readable: true
writeable: false
label: Scene 004
stateless: false
min: 0
max: 255
list: true
states:
  - text: KeyPressed
    value: 0
  - text: KeyReleased
    value: 1
  - text: KeyHeldDown
    value: 2
  - text: KeyPressed2x
    value: 3
  - text: KeyPressed3x
    value: 4
value: 0
lastUpdate: 1612465964173
friendly_name: garage-keyfob_scene_state_004_scene

Sorry but I was a bit trigger happy there. I am a bit new to this, so can you please explain in a little more detail what details you need?

[haavardNO]

I have the same behavior on both the aeotec quadmote and the fibaro keyfob.

[aretakisv]

It can be hass behaves differently in this case! I suggest to move to a new issue and investigate the template we send to hass! this way we might be able to fix the HASS only part.

[haavardNO]

@robertsLando please advise on how to proceed. Should I create yet another case?

[varet80]

@haavardNO this retriggers on HASS side right? I suggest to create a new issue for the HASS side in that case. As the driver works as shuold (MQTT) topic, we probably need to workout the HASS discovery side. Is that the case?

[haavardNO]

@billiaz Yes, it triggers on HASS side. But the values has to come from something. Even after I delete the toppics it retriggers. If a new issue on the HASS side is needed, can someone with the required knowledge create that one?

[varet80]

Please open an issue here, not on hass, for the hass discovery. To get a try fix it. As this issue covers the driver/mqtt part. Include both device exports, for me to create a pr and test container

[haavardNO]

Just to verify that I havent messed up. Is the the reqomended settings for the broker on HASS?

[varet80]

@haavardNO HASS caches the last value, when we send a state without value keeps the old. this means we need some how to reset it. By opening a bug on our issues but fo rHASS discovery! I could start working on this specific bit, which is Different from what this topic solved.!

[haavardNO]

@billiaz thanks for the explanation. see https://github.com/zwave-js/zwavejs2mqtt/issues/486

Please note that the original zwave2mqtt handled this a bit differently. There the state was set to inactive unless it was activated, then back to inactive again.

[varet80]

@billiaz thanks for the explanation. see #486

Please note that the original zwave2mqtt handled this a bit differently. There the state was set to inactive unless it was activated, then back to inactive again.

The zwave2mqtt was using ozw, where zwavejs2mqtt is using node-zwave-js. There are some core fundamental differences, how each driver exposes states/differences.

OZW was controlling 99.9% of how you talk to device, what you get... sometimes outside the spec. the case we are talking is the same. OZW was "performing" extra actions outside spec. In the other hand zwave-js is keeping bit 99,999% if not 100% the specs.

This leads to differences. Comparing between devices like zipabox, fibaro.. they also do the same! follow specs.

Now home assistant has a bit different approach. This means we need to link home assistant's thinking to the app's thinking.

[haavardNO]

@billiaz has there been any development on this issue? I find it curious that no one else is struggling with this. At the moment all my z-wave scene controllers are retriggering after restart.

[haavardNO]

I have moved to the new WS Server option. So I am no longer using these devices in the same way. Investigating more pressing issues with my z-wave network at the moment, so I think we can push this issue further ahead.

[robertsLando]

Ok @haavardNO, let me know!

[Wladi05]

@billiaz has there been any development on this issue? I find it curious that no one else is struggling with this. At the moment all my z-wave scene controllers are retriggering after restart.

Hi, I have exactly the same issue. Did you solve it?