Lock PetDoor through Home App

[Sommi486]

Trying to lock the PetDoor with HomeApp shows very often „can‘t be closed“ and then the door makes the typical closing sound and is closed.

Perhaps there is a chance to make a longer timeout that the door has more time to react.

Thank you for your work!

[wylanswets]

Hey @Sommi486! Thanks for your feedback!

Unfortunately what's happening there would be an error reply from the Petcare API of some kind... internally I only pass along the command and response that I get so I can't really add a "timeout" on my end.

How would you describe the frequency of it saying it couldn't do it but working anyway?

[Sommi486]

Thank you for contacting us!

I've found SurePet's servers to be very slow and sluggish. Maybe it's because of that. Because even in SurePet's in-house app, the locking process keeps hanging.

From 5 times I would say that the error occurs 3 times.

[wylanswets]

You're welcome!

YUCK! That's quite terrible.... is it possible that the signal to your device is weak?

The only other option I could try on my end if it's continuous is maybe add some sort of retry before giving up? Right now I send the request and upon first reply take that as the answer.... so I suppose I could keep retrying until I get 1) a good answer or 2) some timeout or number of retry attempts occur?

What do you think?

[dansimau]

This is happening for me consistently, so I looked into it.

The issue for me is that the API request to lock/unlock the cat flap often takes longer than 10 seconds, and HAP (Homekit Accessory Protocol) specifies a 10 second timeout. The accessory then shows as not responding, even though the lock/unlock has been successful.

Here is the solution I tested:

• Confirm the state change (set event) after ~8 seconds, if the API request is still pending
• When the API request completes, update the characteristic state with the result from the API (in case there has been an error)

This results in the following UX:

• In cases where the lock/unlock API call takes <8s, existing behaviour is maintained (user presses the button, sees the spinner and the lock state is updated when the API request completes).
• In cases where the timeout occurs and the API request will go on to succeed, the user will see the spinner for 8s and then see the lock state updated to their desired state.
• In cases where the timeout occurs and the API request will go on to fail, the user will see the spinner for 8s, then transition to their desired state. Then, when the API request finishes (hopefully a few seconds later), the state will transition back to the previous state. This is the indication to the user that the action failed.

The third point (failure case) above is not an ideal experience, but I found it is better than the accessory going into an unknown state ("no response"), because this causes Homekit to stop reflecting characteristic changes at all.

Also the third case above should be the rarer case, and is partially mitigated by the fact that Homekit sends notifications on lock state, so a user should be able to see if the lock state reverts back.

[dansimau]

Just coded the aforementioned solution:
dansimau@df6d5f8

Works for me, I no longer get the "no response" issue.