Migrating plugs from Wifi to Zigbee (z2m) automation becomes erratic

[sand kelp]

Hi all,
I have a couple of simple automations that send an email when my washer, dryer or dishwasher is done.
Each appliance is plugged into a power-metering smart plug and the automation is simply put "when power drops below x Watts for y minutes, send email".

Going local by replacing my Wifi equipment with Zigbee, the power sensor occasionally becomes unavailable and this causes the automation to fire, when it becomes available again and is below the threshold. This never used to happen with Wifi and it's obviously due to the behaviour/settings of the Mosquitto MQTT.

I've changed the trigger from a simple numeric one to a template trigger
{{ is_number(states('sensor.zb_plug_washer_power')) and (states('sensor.zb_plug_washer_power') | float < 30) }}
(for 10 min) and it seems to do the trick.

Is this the way or is there something better? I understand that template automations are not exactly light weight.

[paper forum]

you could maybe template a condition to check
trigger.from_state and trigger.to_state
and filter out switching to and from unknown/unavailable states as needed

[cold bridge]

If your zigbee stuff is dropping out, you probably need to improve your Zigbee mesh. Smart plugs behind or under large steele appliances may need another zigbee routing device closer to that they keep their signal route.
Some suggestions for zigbee success:
https://community.home-assistant.io/t/the-home-assistant-cookbook-index/707144#p-2856943-zigbee-20

[sand kelp]

Hmm, the smart plugs in question each have the nearest router device no farther than 2m away, with only wood or masonary as barriers. And there are router devices all over the house at every shuttered window, so I don't think I'll be able to improve on the mesh.

[sand kelp]

I've been thinking, and neither the logic of my template nor adding a condition will yield the desired result.

So now I've created an input_number.washer_power_latest and an automation that updates it every 30s, but only if the source sensor is available and yields a numeric value. Otherwise it remains unchanged. With this as an intermediary I can revert to the simple automation I had in the beginning.

[cold bridge]

It's not necessarrily location or density. Read some of the stuff. What channel Zigbee is on, are you using an extension cable, etc...

[rugged stag]

Availability is not baked in to Zigbee. Z2M implements this by looking at the time between the last response and now. The threshold is set in Z2M. Or increase the threshold or just disable availability all together.

Other option or good idea in general, as this would mess up at the start of HA as well with every sensor as they are all unavailable/unknown when HA starts. I set an input_boolean when the power goes over a threshold to indicate the machine started. And only when the power drops below the threshold and this helper is set I threat it as a machine finished event.

[sand kelp]

@rugged stag yeah, that sounds like an Idea as well. With the different programs the machines run, I'm not treating passing the lower threshold as a finished event, but only if it stays below that threshold for a certain time. With my latestpower helper I'm getting good results now.

[sand kelp]

@cold bridge Thanks for pointing me to the Cookbook. It was actually new to me.
Having multiple wifis myself and living in close proximity of multiple neighbor-wifis that could change channels at any moment, I don't really see the point in changing the Zigbee channel. I didn't realize how dense my mesh has become since I migrated all of the smartplugs from wifi to Zigbee and that the smartplugs are, themselves, additional routers. Duh...

[rugged stag]

Yeah, I also use a time threshold. And I started doing it this way as when you restart HA all devices are unknown/available for a while as well. And when the go from unavailable to 0W that will also otherwise been seen as "machine finished". And a boolean is nice and simple and had the added benefit I can show it on my dashboard as machine is running. Also no need for some polling option which I think is rarely a smart solution 🙂

[sand kelp]

@rugged stag Visualizing the devices as running is a nice perk indeed. So do you just have two automations that look for the power passing the thresholds, one to set the bool on the upper threshold and one with lag and dependency on the bool being set to reset it and perform the finished action?