Intent is supposed to be very simple:
If watts are > 75W, set “on”
If watts are unknown/unavailable, use last state
If watts are <75W for 5 minutes, set “off”
It seems like there are a lot of short moments the base sensor is unavailable. Could it be that that interferes with the delay off?
I read somewhere that there’s been a change recently that new values are recorded even if there is no change (by adding a last reported attribute). That too may factor into the sensor not thinking it has been off for long enough.
If removing the delay off helps, it may be a bug that delay off does not work well with the above mentioned change (assuming that every reported value constitutes a change).
But then again, many hickups in the base sensor also seems something in need of fixing.
Unfortunately that is something I can’t fix since its coming in thru an integration and seems like HA just randomly fails trying to query the iotawatt for no reason that I can tell. It completely goes away if I restart both the IoTaWatt and HA server (not reload HA service but reboot the host Hass-OS) at the same time but always comes back after a while. I’ve given up on it. No other machine on my LAN has issues polling the IoTaWatt in tests, its like HA just randomly decides it can’t resolve or didn’t get the expected reply.
I guess I could make another intermediate sensor that just keeps the value to avoid the gaps but I thought the IF logic should handle it.
None of my sensors that lack a “delay_off” are having an issue like this so I bet there’s something odd going on there. I’ll have to see what I can do to work around that. Maybe I’ll have to have an intermediate “state now” sensor and then a “delay_off” separately or something so that it can’t interfere.
This is the first I’ve heard of the “last_reported” attribute, I’ll have to hunt for information on that.
It does seem like removing the delay makes it perform as expected…I’ll look into where to submit a bug. In the meantime (when this load of wash finishes) I think I worked around it splitting up the sensors…so the 2nd one keeps the correct “now” state with power use and then the 1st one handles the “delay” so a gap between cycles won’t prematurely mark it as finished running.
Good thing that it works, but if I was right that is was the last reported change, then I would have thought that this would also not have worked. So it must be something more subtle. Anyway, I’m glad this helps.