Automations: Device automation based on device instead of device_id?

Configuration
1

Hello everyone,
I am trying to create an automation for my Shelly devices that notifies me if any of the Shellies have an overpowering or overheating problem.

The most elegent method would be to use the built in type:problem

alias: New Automation
description: ''
mode: single
trigger:
  - type: problem
    platform: device
    device_id: de5d500475bd278835fa262242edbfc2
    entity_id: binary_sensor.ambient_light_r_dr_overpowering
    domain: binary_sensor
condition: []
action:
  - service: notify.mobile_app_sm
    data:
      message: shelly
      title: shelly

However, I absolutely do not want to use device_id because that is lost if I want to restore my config. I tried using device instead of device_id but that is not allowed.

Is there a different, elegant way of doing this?
I would like to use a long if statement because then I could implement all entities in one go, but I am not sure which type would allow this.

{% if not binary_sensor.ambient_light_dr_overheating == "OK" or binary_sensor.ambient_light_dr_overpowering == "OK" or binary_sensor.ambient_light_l_dr_overpowering == "OK" or binary_sensor.ambient_light_lr_overpowering == "OK" or binary_sensor.ambient_light_r_dr_overpowering == "OK" or binary_sensor.boiler_1_overheating == "OK" or binary_sensor.boiler_1_overpowering == "OK" or binary_sensor.boiler_2_overheating == "OK" or binary_sensor.boiler_2_overpowering == "OK" or binary_sensor.boiler_3_overheating == "OK" or binary_sensor.boiler_3_overpowering == "OK" or binary_sensor.lightswitch_dr_overheating == "OK" or binary_sensor.lightswitch_lr_overheating == "OK" or binary_sensor.main_light_dr_overpowering == "OK" or binary_sensor.main_light_lr_overpowering %}
2

Device triggers are an abomination. Use state triggers.

trigger:
  platform: state
  entity_id: binary_sensor.ambient_light_r_dr_overpowering
  from: 'off'
  to: 'on'
3

Thank you @tom_l

But can I use the state trigger with a batch of entities rather than creating a long list of triggers?
And I agree, device triggers are ugly. Not sure though why there are not entity triggers? That would seem to be the easiest approach.

P.S.: If I leave to: empty, will it trigger on any state change, not matter what the new state is?

4

Yes you can list entities,

trigger:
  platform: state
  entity_id: 
    - binary_sensor.ambient_light_r_dr_overpowering
    - binary_sensor.something_else
    - binary_sensor.another_one
  from: 'off'
  to: 'on'

Any of them changing from off to on will trigger the automation.

1 Like
5

Instead of a long if statement, you rather put all entities inside a group and trigger when the group changes to ‘on’.
The group will only be ‘on’, if at least one of the entities is in the state ‘on’, otherwise it will be off.

The state of the entity for a binary sensor is either on or off, the states you see in the frontend are translated based on the device type and your language settings. Foe autonations you need to use the “real” state, which can be found under Developer Tools → States

trigger:
  platform: state
  entity_id: group.binary_sensor_group
  to: 'on'
action:
action:
  - service: notify.mobile_app_sm
    data:
      message: >
        There's a problem with the following shellies: 
        {{ expand('group.windows_doors_outside')|selectattr('state','eq','on')|map(attribute='name')|list|join(',') }}
      title: shelly problem
1 Like
6

I considered creating a group as a last resort.

I was wondering if it is possible to use regular expressions like for the configuration of Recorder or Logger or InfluxDB?
There you can batch exclude entities using regular expressions.

But I tried

  trigger:
    platform: state
    entity_id: 
      - binary_sensor.*_overpowering
      - binary_sensor.*_overheating
    from: 'OK'
  condition: []
  action:
  - service: notify.mobile_app_sm
    data:
      message: Shelly Overpowering or Overheating
      title: Shelly Overpowering or Overheating
  mode: single

and it failed.

7

One way to answer your own question is to review the documentation for the State Trigger. if you see no mention or example of it then the odds are very high that it’s not possible.

… and no you can’t specify an entity like that.

FWIW, a group isn’t ideal for this application. The automation’s State Trigger will trigger when the group’s state changes from off to on which means all of the group’s members were off and now one of them is on.

The second group member that changes to on won’t influence the group’s state because it’s already on. That means it won’t trigger the automation again.

8

As Taras stated, that’s not possible. And as I stated, you need to use the state from Developer Tools → States. A binary sensor is never “OK”, that’s only the state shown in the frontend.

9

Yes, sorry, I did not check the state before. And you are of course right, it has to be ‘off’ to ‘on’.

It is not really a big issue listing the sensors. I just use python to output them for me and then copy & paste them. But it would have been much nicer if I did not have to check everytime I added a device.

Is there a backdoor somewhere that you can think of?
Some integration that allows regular expressions which I can then piggy back off to get that list into the automation?

10

Where does this “type” appear? Is it an attribute of the Shelly’s binary_sensor?

11

Seems to be that HA recognizes it due to the device class “problem”.
image

Then in Automations:

image
image696×456 10.7 KB

Results in

alias: New Automation
description: ''
mode: single
trigger:
  - type: problem
    platform: device
    device_id: 18f0704b6db07f665b48b618c6d5e0e4
    entity_id: binary_sensor.main_light_dr_overpowering
    domain: binary_sensor
condition: []
action:
  - device_id: ''
    domain: ''
    entity_id: ''
12

Thank you; I understand now. That’s a Device Trigger’s way of indicating the binary_sensor’s device_class.

13

Hello again,

I have run into a follow-up issue.

I was creating an automation to notify me if a battery is running low. The current state is “GOOD” (as per Developer Tools). And I am pretty sure the alternative state is “LOW”.
image
And even though it was all setup, I did not get any notifications with

payload: value_json.battery == "LOW"

But if I run the automation manually, it sends the notifications. So the problem is not the notify part.

And if I try to force it to run by setting it to the known current state (“GOOD”) it does nothing.

- id: '1634910544401'
  alias: eQ-3 Battery LOW (Living Room)
  description: ''
  trigger:
  - platform: mqtt
    topic: stat/EQ3/001A2208B97D
    payload: value_json.battery == "GOOD"
  condition: []
  action:
  - service: notify.mobile_app_sm_g975f
    data:
      message: eQ-3 Battery LOW (Living Room)
      title: eQ-3 Battery LOW (Living Room)
  - service: notify.discord
    data:
      message: eQ-3 Battery LOW (Living Room)
      target: [!secret discord_target]
  - service: telegram_bot.send_message
    data:
      message: eQ-3 Battery LOW (Living Room)     
  mode: parallel
  max: 10

Is my payload syntax wrong?

payload: value_json.battery != "GOOD"
payload: value_json.battery == "LOW"

Should be identical.
I thought maybe it needs to be

{{ payload: value_json.battery == "GOOD" }}

but that is definitely wrong and even the system knows it :smiley:

Thank you for your help
Alex

14

Nevermind, fixed it by changing from MQTT to state. Would like to know why it did not work before, but at least it is working now.

15

Look at the docs for MQTT triggers

trigger:
  platform: mqtt
  topic: stat/EQ3/001A2208B97D
  payload: "GOOD"
  value_template: "{{ value_json.battery }}"