I’ve got an automation that wants to turn of shelly switches when their _overpower binary sensor triggers.
But I cant get the template loop for the switch.turn_off, to accept my list of devices.
When I initially created it, and accidentally sent it the list of (_overpower) entities the syntax works, but with a device list…it looks like this 
With an additional ‘-’ that messes up the list??
Whereas the earlier attempt, when I was sending an entities list:
Try the template in developer tools, because it seems the device id already contains a - before it so I think it already is a list. (see the double - in the log and the fact it says device_id[0] should be a string). You might want to try removing the [ ] around it.
But besides that: afaik when you create a device action in the automation editor, both a device and entity are supplied. Probably because devices can have multiple entities to act on. So I’m not sure this will work. Why would you want to do this with device ids anyway?
I’ve already run the same output via a notification, and there is no ‘-’ in the device id’s themselves, when you print them one by one. And the adding of them, into the list, is done the same way as when I used the entities.
I have to go via the device id, since the trigger is a group of entities of the electric_socket_whatever_overheat, which is something I cant use in a switch.turn_off as an entity, since I need the switch-entity for the associated device.
Sure, I could probably iterate over the specific device’s entities, but it should work just as fine with the device Id. And it does work, if I ust just [0] and pick the first.
You missed the point about the double - I think: it seems devide_id() is already returning a list. You are wrapping it in another list, creating a list of lists.
How could the device_id() of an entity, be a list? An entity cant - afaik - belong to TWO devices at the same time.
Additionally, as I said, I also sent the output of each {{device_id(X)}} to a notification, and that just shows the device id’s number, nothing else.
I am however adding the device_id’s TO a list, but I dont see any difference wether the last line in the automation is:
{{ overTempList.deviceIds }}
or
{{ overTempList.deviceIds|list }}
I agree entities belong to one device. It may be a bug, I just reacted to the fact that the error says that the first element of the device list is not a string, and that ithat element displays with a minus in front. The only non-string with a - I know of is a list. That is also why I suggested the developer tools. If you are not the cause of nested lists, it is the action. That would be a strong indication of a bug. Knowing that I never actually saw anyone use templates for the devices, it is not unlikely that a bug has been there for some time.
I’m still not convinced turn on will work on a device. If you hard code one device, will it work? Otherwise fixing the template thing is moot. Plus: I’d expect overheating devices to turn themselves off, and showing the overheat sensor as the reason why and for alarming. They’d be dangerous if they wouldn’t. This is not something you’d let an external system be responsible for.
Hello heQue42,
Device_id’s are not currently intended to be used with templates. Any function you might get to work will likely break in some update in the future. If you are using templates, use entity_id’s.
That’s the YAML representation for a list of lists.
Try flattening it:
{{ overTempList.deviceIds | flatten }}
Yes, that does work. But, it can target all the switches attached to the device, so it can be “dangerous” since some devices have switch entities for restart.
In your second example, the action wouldn’t do anything because the only entity it found that was “on” was a binary sensor which would be unaffected by the action. Likewise, you have over-complicated the template:
action: switch.turn_off
target:
entity_id: |
{% set sensor_list = trigger.to_state.attributes.entity_id %}
{{ sensor_list | select('match', 'switch.') | select('is_state', 'on') | list }}
I am well aware that the entity-version wont work. It was never intended to. And even though I am sure my loop-concept can be improved since I cant claim I am very secure in my use of jinja, but I cant either filter on switches etc.
The trigger for the automation is a group helper, that ONLY contains the binary sensors for overload or overheat of shelly devices.
There are no switch entities. So therefor I must find the device that the triggered overload/heat-sensor “belongs” to, and then turn that off.
{% set sensor_list = trigger.to_state.attributes.entity_id %}
{{ sensor_list | map('device_id') | map('device_entities') | flatten
| select('match', 'switch.') | select('is_state', 'on') | list }}
You will probably be fine since you are using Shelly devices, but it wouldn’t hurt to double check that there aren’t other switch entities attached to the devices that need to be filtered out.
Is this documented somewhere? I mean, I can easily, with the visual editor, create an action call:
action: switch.turn_off
metadata: {}
data: {}
target:
device_id:
- 1c1aade25e57a697196bd58e741075ac
- dc6ddae238085fe77f98fd1095db500f
So, why not parse with jinja, as for entity_ids?
Tried, but to no avail, and I guess @Sir_Goodenough might be right, the the code simply doesn’t accept jinja templates for device lists…even though the jinja is parsed, at least partially.
I gave up and extracted the entities, and turned_off the switch entitiy instead, just like someone suggested.
{%- set overTempList = namespace(deviceIds=[]) -%}
{%- set sensorList = trigger.to_state.attributes.entity_id -%}
{%- for node in sensorList -%}
{%- if is_state(node, "on") -%}
{% set overTempList.deviceIds = overTempList.deviceIds + [device_id(node)] -%}
{%- endif -%}
{%- endfor -%}
{%- set eList = namespace(entityIds=[]) -%}
{%- for devId in overTempList.deviceIds -%}
{%- set entityList = device_entities(devId) -%}
{%- for eId in entityList -%}
{%- if eId is search("switch") -%}
{% set eList.entityIds = eList.entityIds + [eId] -%}
{%- endif -%}
{%- endfor -%}
{%- endfor -%}
{{eList.entityIds}}
And yes, it can probably use a lot of clever filters instead…
I performed my own tests and confirmed that the device_id option fails to behave the same way as the entity_id option.
For device_id, regardless of how the template is constructed, the value it produces always becomes the first item of a list. So if the template produces a list, the final result is a list within a list.
The only way it works is if the template produces a single value because then it becomes the first (and only) item in the list.
This is a bug (with device_id); there’s no reason for it to always insert the template’s result into a list.