[feat] Use trigger instead of sensor in home assistant discovery for scenes

[dr1rrb]

Is your feature request related to a problem? Please describe.
Currently Z-wave scenes are pushed as "sensor" in Home Assistant, using a hard coded delay to reset the state when triggered.

This means that

1. We are not able to trigger the scene twice without having to wait for a fix delay;
2. We have to listen on state changes of the sensor, and filter them instead on directly consume scene as events in HA;
3. We have a bunch of sensor in "unknown" state when we reboot HA (until we actually trigger the scene)

Describe the solution you'd like
We should instead use the "trigger" component (a.k.a. "device_automation").

Describe alternatives you've considered
This could be an option in setup to avoid breaking change.
We could also have both enable as a migration scenario.

Additional context
Add any other context or screenshots about the feature request here.

[robertsLando]

We are not able to trigger the scene twice without having to wait for a fix delay;

Why?

We have to listen on state changes of the sensor, and filter them instead on directly consume scene as events in HA

Aren't the automatically created?

We have a bunch of sensor in "unknown" state when we reboot HA (until we actually trigger the scene)

This is because you have not set retain flag I think

[dr1rrb]

We are not able to trigger the scene twice without having to wait for a fix delay;

Why?

This is more theoretical than a real concern on my side. Since the scenes are forwarded to HA by setting a sensor to on then off, I assume that when turned on there is a delay before setting it back to off during which, if the device trigger the scene again, the HA's sensor won't toggle on/off or will do it after that delay.

We have to listen on state changes of the sensor, and filter them instead on directly consume scene as events in HA

Aren't the automatically created?

Yes there is an event which is fired each time a device state changed, but my comment was more about the distinction I make below.

We have a bunch of sensor in "unknown" state when we reboot HA (until we actually trigger the scene)

This is because you have not set retain flag I think

Indeed, I forgot I let the retain flag unset in the settings page. I'm no longer a big fan of the retain, usually causes more issues than benefits (stale values that has to be manually cleaned-up). It might do the trick, even though I'm not sure for the scenes that I never trigger.

Just to clarify, I've created this issue as I was trying to re-arrange my UI using the "auto-entity" filtered by device. I realized that I had those sensors that shows up but was absolutely useless in the UI (and just filtered them out still using the "auto-entity" card).

It make me realized that the distinction between event (a.k.a. intent / trigger / command / or even scene in z-wave terminology) vs. state was weak when backed by a device in HA, as a device is state-full. Turning a sensor on and off is actually a patch IMHO, even if it's a common pattern that I've fight more than once in my professional life. So I looked in HA docs and found that the MQTT integration does offer a solution for that distinction which is well documented:

An MQTT device trigger is a better option than a binary sensor for buttons, remote controls etc.

I won't argue that it's the ultimate solution that must be implemented right now, it's more a suggestion as this feature in HA has been developed specifically for those cases. And actually I agree that currently a sensor is really easy to use in the automation GUI (even if I don't use it) which might not be the case of events (I'm planning to use the "automation_trigger" for my own projects, and see if I've to open an issue / contribute to HA to ease that use).

[robertsLando]

Ok thanks for the clarification @dr1rrb :) I will implement this, just one question, with scene you mean the central_scene? Are your scene sensor actually looking like this: https://github.com/OpenZWave/Zwave2Mqtt/blob/master/hass/configurations.js#L135?

[dr1rrb]

Ok thanks for the clarification @dr1rrb :) I will implement this, just one question, with scene you mean the central_scene? Are your scene sensor actually looking like this: https://github.com/OpenZWave/Zwave2Mqtt/blob/master/hass/configurations.js#L135?

Thanks @robertsLando 👍

And yep it looks like to be that:

At least the object_id ("scene_state") seems to match 😊

[robertsLando]

@dr1rrb What type should I use in the discovery payload? What value is published in the scene topic when it is activated?

https://www.home-assistant.io/integrations/device_trigger.mqtt/#type

Also could you try to manually edit a scene discovery configuration in order to work as a device trigger? I don't own devices to test this

[dr1rrb]

Hey @robertsLando , I finally took time to validate that.

So for the discovery I used

{
  "type": "trigger",
  "object_id": "scene_down",
  "discovery_payload": {
    "automation_type": "trigger",
    "type": "button_double_press",
    "subtype": "turn_off",
    "topic": "zwave2mqtt/inovelli_lzw31sn_001/91/1/1",
    "device": {
      "identifiers": [
        "zwave2mqtt_0xc35fa37d_node3"
      ],
      "manufacturer": "Inovelli",
      "model": "LZW31-SN Dimmer Red Series (0x0001)",
      "name": "inovelli_lzw31sn_001",
      "sw_version": "1.35"
    }
  },
  "discoveryTopic": "device_automation/inovelli_lzw31sn_001/scene_down/config",
  "values": [
    "91-1-1"
  ],
  "persistent": true,
  "ignoreDiscovery": false,
  "id": "sensor_scene_state"
}

Note: No name nor unique_id. Setting any extra property will fail the discovery.

Then in the HA's Automation UI it adds a well named trigger:

The text in the red rectangle is "Turn off" double pressed , which matches what I configured in the type and subtype attributes

About the payload to publish, actually whatever you want. It's seems that publishing a value on the topic is sufficient to trigger the automation. For instance, when I've tried to publish some dummy data, it has triggered my automation:

So it means that unlike other properties, we have to discover multiple HA entities for a single "ZWave class ID" (not sure if it's the right name, in means the "91-1-1" in my case). One for each possible value of a scene. Apparently we already have the info in the device config file:

<Value type="list" genre="user" instance="1" index="1" label="Scene 1" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="0">
	<Help></Help>
	<Item label="Inactive" value="0" />
	<Item label="Pressed 1 Time" value="1" />
	<Item label="Key Released" value="2" />
	<Item label="Key Held down" value="3" />
	<Item label="Pressed 2 Times" value="4" />
	<Item label="Pressed 3 Times" value="5" />
	<Item label="Pressed 4 Times" value="6" />
	<Item label="Pressed 5 Times" value="7" />
</Value>

I don't know if I can already add some entities for each value by manually editing in the settings.json ? But even then, I think that ZWave2MQTT only converts each "ZWave class ID" into a given MQTT topic, I won't be able to request it to publish in some extra topic.

[dr1rrb]

BTW I just realized that if for the subtype we could just use button_<index>, there is no easy conversion between central_scene items in the OZW device config and the type of the HA discovery. But the HA's doc states

If set to an unsupported value, will render as subtype type, e.g. First button spammed with type set to spammed and subtype set to button_1

So I tried to alter my discovery config to use the config's label as type and subtype:

 "discovery_payload": {
    "automation_type": "trigger",
    "type": "Pressed 2 Times",
    "subtype": "Scene 1",

then in HA automation UI:

That looks really great IMHO

[robertsLando]

@dr1rrb Are you able to submit a PR for this? :)

[dr1rrb]

@robertsLando I would love to, but I already have a lot of pending projects (the life story of all of us ;)). So it probably won't be before the end of this year. Meanwhile I can do real world tests if someone wants to do this.

[robertsLando]

@dr1rrb I keep it in my todos for now but I'm also working on z2m successor (https://github.com/zwave-js/zwavejs2mqtt) and it will take me some time :)