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?
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?
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!!! ]
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?
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.
