Templating device_id in a Platform Event trigger

I’m struggling with and puzzled by
a) Why I cannot template the value for a device_id in a trigger on platform event (as below); and
b) How to do it correctly or else the best work-around.

Context: I have Z-Wave Fibaro Switches and Dimmers that can provide a Scene_Id for certain wall switch actions, but (as far as I know) HA does not identify these. Hence I’ve created an automation to capture and interpret these ZW events for the relevant Fibaro devices. This works fine with explicit device_id tags, but of course for mainainability we’re encouraged to avoid using those in code where possible.
Going forwards, I will want this to work for multiple device_ids.

  trigger:
    - platform: event
      event_type: zwave_js_value_notification
      event_data:
        device_id: 9a4501b39ec7fcb28ef299af43c59cb6
#         device_id: "{{ device_id('light.landing_ceiling_light') }}" # Does not work
        command_class: 43
        property: sceneId
        endpoint: 0
      id: landing_light_wall_switch_off
  action:
    Etc...

The above fields are the relevant ones from those that the event message contains, as seen in Developer Tools/Events.
As per the commented line, I’ve tried replacing the long device Id with “{{ device_id(’<entity_id>’) }}”, but that does not work, though in Developer Tools/Template it returns the correct value (but " quoted - unless the " pair is removed, but that’s not allowed).
? Does the return value need casting? To what? (Tried |device_id and |device_id(), but neither work.)
? Or is templating not supported in this context?
? Is there a good way around this? e.g. entity_id or device_name instead of the device_id itself?
? Should I perhaps leave the device_id out of the trigger condition and filter on it in the Action block instead?

Thanks for any help with this…

Well that was an interesting rabbit hole.

Triggers that support templates will explicitly state so. e.g. for the event trigger:

Ok what are limited templates:

Well that didn’t tell me anything.

Looking at the device templating rules reveals this:


So device_id() should be supported in limited templates. And you have confirmed your template works in the template editor ( I did too with one of my devices).

So all I can conclude is that this is either a bug or the documentation is incorrect.

Can you listen to the event in Developer Tools → Events and post the full event_data here?

There may be another way to do this.

Hi Tom. Glad you enjoyed exploring this rabbit hole!
I thought I was (am) dealing with a Platform Event trigger, so that templating ought to be supported, and yes, as you copy in, “device_id()” appears to support it too. And yes, the definition of what “Limited Templates” are does seem vague! I’d checked it too.

My other thought was that the template returns a quoted string, whereas what works is an unquoted alphanumeric sequence. Does it need casting? But to what datatype and how? I tried using the ‘>’ multi-line template format (so no outer quotes), but without success.

Anyway, the Events tool returns the following (for a Fibaro Dimmer 2 and on Clicking the attached momentary wall switch S2 Off once). Fibaro provide an “interpretation table” to decipher what the action was from the combination of the device’s settings and the Z-Wave event values sent. Messy!

event_type: zwave_js_value_notification
data:
  domain: zwave_js
  node_id: 20
  home_id: 1234567890        # My edit - not its real value.
  endpoint: 0
  device_id: 9a4501b39ec7fcb28ef299af43c59cb6
  command_class: 43
  command_class_name: Scene Activation
  label: null
  property: sceneId
  property_name: sceneId
  property_key: null
  property_key_name: null
  value: 11
  value_raw: 11
origin: LOCAL
time_fired: "2023-09-28T08:32:08.625205+00:00"
context:
  id: 01HBDENCDHDR9HBZEE9DD0NGAZ
  parent_id: null
  user_id: null

I also wondered about removing the Device_Id from the trigger’s spec so that it catches all similar device’s events, and then in the Action block only processing on my wanted devices, ignoring other device’s events? Would that have any unwanted side effects?

[ In the wider context, I’m using this event trigger to capture the Fibaro “Scenes” (identifying if my wall switch clicked On or Off and with 1, 2 or 3 clicks) and then to raise my own events to pass to a complex lighting control automation. Am hoping I can parameterise it all so that 1 logic script can work for many rooms and variations. About 350 lines of code including comments and debugging blocks. My first serious automation and venture into serious YAML etc. Much learning happening!!! ]

It should not matter if it is quoted or not. You can test that by trying:

  trigger:
    - platform: event
      event_type: zwave_js_value_notification
      event_data:
        device_id: "9a4501b39ec7fcb28ef299af43c59cb6"
        command_class: 43
        property: sceneId
        endpoint: 0
      id: landing_light_wall_switch_off

Thanks. I should have thought to test that scenario.
So, it’s down to whether templating is meant to be allowed in this context or not. Bug or documentation error? Who decides that one?

Is my best solution then to try “removing the Device_Id from the trigger’s spec so that it catches all similar device’s events, and then in the Action block only processing on my wanted devices, ignoring other device’s events?”
Would that have any unwanted side effects?

Thanks for your help and research on this issue.

Yes, just use a more general trigger, then filter either within the Condition block or in a Choose or If/Then action if you plan on using those.

You might end up with a greater quantity of unhelpful traces because there will be more trigger firings that are unrelated to your target device. If you can do your filtering in the Condition block rather than the Action block you should since that will help keep the last_triggered attribute as accurate as possible.

Thanks Drew. Had n’t thought about the Traces. Good point. I’ll filter the Device Ids in the Conditions block, as you recommend. Already coding my changes up. Eventually it’ll be useful to capture for more devices anyway. The Trigger Variables bit comes in useful too, does n’t it.