React to automation errors

[craggy ruin]

Hey everyone, I have an automation that automatically locks my cat flap under certain conditions. This is, for complicated reasons, very important to avoid expensive vet visits.

Today I was very surprised when I found my cat outside while the flap was supposed to be securely locked. Checking the automation trace, I found an API connection error.

Question: Is there any reasonable way to react to errors in steps of an automation? This was the first time I noticed it, but it got me thinking: I have a few quite critical automations, and I really need to get notified if one of them runs into trouble of any sorts.

[tired laurel]

Don't think there is a way for the error itself. Of course there is as it will fire an event!\ But you could build in a check into the automation that the requested task is done. Be sure to have continue_on_error: true set for the step you expect to fail.

[gilded ingot]

For this particular case, you can add a simple door sensor to know if the cat flap has been opened after activating your automation and notify you in such case

[copper fern]

You can trigger on errors if that’s what you’d like to do.

#1358789861414408294 message

[craggy ruin]

I'll have to look into this more, but it looks promising.

[craggy ruin]

Wish it were that easy, but a door sensor can't tell me if the cat flap was locked when it should be, and by the time the door sensor goes off, it's already too late, because the cat is out of the bag, so to speak. Also, finagling a door sensor into that thing might play merry hell with the RFID tag readers.

Plus, the door already tells me not only when a cat passes through, but even the direction it went.

[tired laurel]

It it a Sure petcare? They are indeed not very reliable, also not via the official app. But here the flap is or 'unavailable' or will jump back to unlocked after locking fails. Both of which you can check.

[craggy ruin]

It is a sureflap, yes. My main beef with them is that their flaps don't always successfully pick up on a cat passing through and report it as "looking through". They also sometimes change their API, but we can't really complain about that, since HA integrations are using reverse engineered API calls "inofficially", can we now?

[tired laurel]

I don't have the "looking through" issue often, but like now the communication between flap and base station is gone. I'll have to reset the flap again.

Yeah, API is not official. But also via the official app it's flaky 😐 Still don't get why companies just don't go with an official API, would even save them resource but okay.

But as you have a sureflap, you do have a locked/unlocked status in HA. Are you saying you came across situations where you have the status 'locked' in HA while it's unlocked irl? The times I saw issues locking from HA I see the status go back to 'unlocked' after a few seconds.

[craggy ruin]

I can give you a hint there. Call the surepetcare hotline, they have some special compatibiltiy mode they can activate if connectivity is bad iirc. They claim it's got something to do with radio interference.

And yes, I have come across cases where the status was locked both in HA and the official App, but in reality it would just fail open. That's when I learned about that compatibility mode.

In this specific case however, it was different. There is an automation that was supposed to lock the flap, which simply ran into a connection issue. The real problem however was that I didn't realize that it hadn't happened.

[tired laurel]

Thanks, should give them a call then.

But for the normal cases you could implement a check after like 10-20 seconder after calling the lock action, to see if the status is really locked now.

[craggy ruin]

That's probably what I'm going to end up doing, but I agree that having some sort of built-in on_error jump would be a nice feature of automations.