Reloading ZHA pointlessly triggers automation

[3jam3]

I have a ZB smart switch with measurement function (Tongou TO-Q-SY1-JZT) successfully connected to the ZHA. I have set up automation to protect the circuit from exceeding the 20A load limit.

alias: "Protection: overcurrent"
description: ""
trigger:
  - type: current
    platform: device
    device_id: 9e119f85db9bf8a2982e01bcc20bff37
    entity_id: 897beedf270490d7160cdbf2fe04b2ca
    domain: sensor
    above: 20
condition: []
action:
  - type: turn_off
    device_id: 9e119f85db9bf8a2982e01bcc20bff37
    entity_id: 1080cb0e5e07cf3987727569f6f44929
    domain: switch
mode: single

When I reload the ZHA, this automation is triggered, and power is cut off. When I try to switch on with a physical button or in HA, immediately the automation is triggered again. It makes a pointless loop. In the logs you can see this:
Turned off triggered by automation Protection: overcurrent triggered by numeric state of Tongou switch and meter Current
The other automations (voltage, wattage) are not triggered during the ZHA reload. Overcurrent automation is not triggered when the HA reboots. Does anyone have an idea why this is happening and how to mitigate it?

[pcwii]

Could you try adding a small delay to the trigger so that it doesn’t trigger when first loaded?
You may also want to look at this.

Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [image] It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use entity, with state or numeric_state. Device_id problems The yaml will be longer and harder to follow, which may make maintenance difficult, especially a few months down the line when you h…

[NathanCu (Nathan Curtis)]

First you’ll do well to use numeric state instead of device triggers in the future because if you replace a device you have to edit your automation if you use entity_id and replace the device as long as the entity is is the same on your new device your automation keeps truckin’. That said.

Your device is probably going unavailable or unknown during the cycle and then getting the new state. (and interpreted as above number in your trigger) You can accommodate those in your automation using ‘not from x’ exclusions in the state trigger in the automation.

Run a trace of the automation. Post the trace and someone will help.

[3jam3]

Thanks, guys. Here’s the trace:

* Triggered by the numeric state of sensor.tongou_switch_and_meter_current at 28 March 2024 at 06:14:31
* Turn off <unknown entity>
* (switch.tongou_switch_and_meter_switch) turned off
* Finished at 28 March 2024 at 06:14:31 (runtime: 0.12 seconds)

[NathanCu (Nathan Curtis)]

Read this post I think you’ll figure it out

Automation UI needs an option to ignore unexpected triggers when state changes from or to "unavailable" or "unknown"

trigger: - platform: state entity_id: - binary_sensor.bathroom_light_switch from: ["off", "on"] to: ["off", "on"] This works fine, usually what I use. Or for sensors which aren’t binary: trigger: - platform: state entity_id: - sensor.some_sensor not_from: ["unavailable", "unknown"] not_to: ["unavailable", "unknown"] But still, checkboxes would be nicer.

[3jam3]

Encouraged by the indicated post, I have added conditions. It now looks like this:

alias: Test
description: ""
trigger:
  - type: current
    platform: device
    device_id: 9e119f85db9bf8a2982e01bcc20bff37
    entity_id: 897beedf270490d7160cdbf2fe04b2ca
    domain: sensor
    above: 20
condition:
  - condition: template
    value_template: "{{ trigger.from_state.state not in ['unknown', 'unavailable'] }}"
  - condition: template
    value_template: "{{ trigger.to_state.state not in ['unknown', 'unavailable'] }}"
  - condition: template
    value_template: "{{ trigger.from_state.state != trigger.to_state.state}}"
action:
  - type: turn_off
    device_id: 9e119f85db9bf8a2982e01bcc20bff37
    entity_id: 1080cb0e5e07cf3987727569f6f44929
    domain: switch
mode: single

Reloading ZHA still triggers the Current protection automation but no longer triggers the circuit breaker.

* Triggered by the numeric state of sensor.tongou_switch_and_meter_current at 28 March 2024 at 13:27:36
* Test Test if template renders a value equal to true
* Stopped because a condition failed at 28 March 2024 at 13:27:36 (runtime: 0.00 seconds)

I have just started my HA adventure. Please advise if my modification of the automation code is correct.

[NathanCu (Nathan Curtis)]

Promising. That means it’s ignoring the flip from unknown or unavailable to a number now.

Now you need to see if your automation works for what it’s designed to do.

You can use developer tools to temporarily override the device state to force it over your trigger value to see if it works. You should expect it to trigger but this time because it was not coming from unavailable or unknown and to something over your trigger value… Pop.

[123 (Taras)]

@3jam3

Please advise if my modification of the automation code is correct

You only need the first of the three Template Conditions you created.

The second and third Template Conditions can never be false so they’re unnecessary.

[3jam3]

@ NathanCu
I will see if it works as soon as my wife’s gone to groceries. Otherwise, it may be not understood and accepted

@123
Thanks for pointing it out. Now I see it.

[3jam3]

Unfortunately, the overcurrent automation I created is not working. I have tested several scenarios and despite exceeding the set limits (A), the power supply is not cut off. The log shows that the device immediately updates the status when the electric current increases. You can see this on the sensor readings screen.
However, if you set up automation based on energy transfer (W), it works as expected. I’ve done several trials with the trip thresholds set in Watts and it has been as expected each time. It is worth noting that this automation is not sensitive to ZHA reload. So I set the trip threshold to 5700W, which corresponds roughly to 25A [at 230V] taking into account the power factor, and left it that way.
I don’t understand why the automation based on energy transfer is not problematic and the one based on current is indeed. Perhaps it has to do with something being wrong with the ZHA quirk for the meter.
https://community.home-assistant.io/t/energy-sensor-shows-summation-delivered-multiplied-by-100/709373