Interesting. Not sure how the native app is doing that. So, there is no physical sensor for inside and outside? Does the sensor between the doors, preventing closing, play any role along with the remote tag on the collar?
There are definitely microphones on both sides, with the gain knobs on the door to adjust the sensitivity of each one. (There is no way to set/read these knobs in the native app.)
Are you sure that you are seeing the sensors being triggered in the app? That information was never exposed in the reverse-engineered API that I sawā¦
Itās not about sensitivity; itās about which sensor triggered to open the door.
You can setup notifications in the app for inside vs outside. I havenāt set them up so I donāt know if they work well, and this still doesnāt mean itās exposed in the API, but it does appear that the app has some mechanism for determining which side of the door the open command was triggered from. This would be super useful to know if dog was in or out, if itās available in any form.
1 Like
I enabled the notifications in the power pet door app and did some tests. The notifications do work as expected and appear to be reliable. Iām an android user, but I assume similar IOS functionality. I have two dogs, and they both have collars to open the door, so in my case, this inside/outside information still wouldnāt be enough on its own to know who was inside/outside and when, but it would useful for anyone with a single dog I would imagine. Still doesnāt mean thereās an event stream thatās available for external use, but the information is present in some way. If I only had one dog, I would probably set something up in tasker to intercept the notification and call a webhook to set inside/outside status of dog, maybe in conjunction with a motion sensor to cover the case of opening from inside but not going out the door.
After traffic inspection, it appears that the door reaches out to an external server (iot.hightechpet.com) to send push notifications with inside/outside information to the app. It does not appear that this information is sent locally within the network in any way. So without access to the underlying code for the door, I donāt see any way to extract this data in a usable manner. I supposed you could spoof the external server via local DNS and redirect this traffic to a destination of your choosing, but youād have to be able to process it from there. Iām sure thatās possible in some form, but would be a fair bit of work for maybe not much return, and certainly not something the average user would want to take on.
Can I ask a dumb question? Does anyone else need to manually āreloadā this integration to get it to do anything after a HA update or reboot? Just wondering if it is something with my HA setup causing some sort of race condition during boot, or if others are seeing the same problemā¦
I had that issue once or twice a few HA versions back, but I havenāt had to do anything like that since probably 2023.9. I install every .2 update and there are numerous reboots during a month for other reasons, so Iād see it if it were still happening to me.
1 Like
As a heads-up, someone reported this issue overnight in GitHub:
After Update Home Assistant Core to 2024.2.4 and Operating System to 12.0 the ha-powerpetdoor plugin is not working anymore!
Everyone might want to hold off on the latest updates for nowā¦
There is an open issue fore this Unable to connect to power pet door / Validation of translation placeholders for localized (de) string component.homeassistant.issues.config_entry_reauth.title failed Ā· Issue #13 Ā· corporategoth/ha-powerpetdoor Ā· GitHub
From what I can tell, this is a bug introduced by Home Assistant itself.
Apparently they changed a translation token ( component.homeassistant.issues.config_entry_reauth.title - Add title to reauthenticate integration issue by timmo001 Ā· Pull Request #111275 Ā· home-assistant/core Ā· GitHub) to include a substitution called {name} - without letting anyone know this was going to be required, providing a default, or in any way telling anyone WHERE to declare said ānameā token.
Iād consider this a bug on the part of HA itself. But Iām looking for how to fix it by providing the missing name token. But so far I canāt find any examples.
1 Like
I think I have a fit on the git latest. If someone could test it with 2024.2.4 or OS 12.0, it would be appreciated (I cannot easily update my HA to test this).
1 Like
Iām running HA on bare metal and Iāve just updated core to 2024.2.5 and HAOS to 12.0. I have not made any changes at all to the Power Pet integration and it seems to be working just fine on v0.4.5.
1 Like
I have now installed the modified en.json file from the github issue and restarted HA. I had no issues before this, and I cannot find any issues now. Everything seems to be working as expected.
It seems the HA issue was fixed in 2024.2.5 here: home-assistant/core#111648
So perhaps the en.json is not needed any longer, but in any case, it doesnāt seem to cause any issues on its own.
2 Likes
@corporategoth I wonder if thereās something funny going on with the position indicator for the cover entity? I notice in my logs that it reports āunknownā state before switching to āclosedāā¦ possibly with different behavior based on how it was told to open (was it due to my dog with their sensor or due to me manually controlling via HA):
Over in Hubitat Iām reading this device via the Home Assistant Device Bridge and I donāt expect you to support that system, but I think it provides some diagnostically interesting data - it basically never reports a position of zero:
I donāt understand the internals of HA, let alone the ācoverā entity, but is there somewhere I can look to ensure that itās properly reporting a position of 0 when it really is fully closed?
Hereās a tip just in case anyone else is interested. Iāve been having real trouble from this Power Pet Door lately. Thereās something going on between the collar sensors in the door and the collars (I have 2 dogs). Iāve had the door for a little over a year and maybe two weeks ago, I started hearing the dogs pawing the doors and it wouldnāt open for them. I replaced collar batteries and that made no difference. Iāve played with sensitivity etc, but no dice. Nothing has changed, so Iām assuming the sensors in the door are failing? Sometimes it works as expected, others, it just wonāt open, no matter what you do. I wouldnāt think both dog collars would fail at the same time, but I suppose its possible. Anyway, I already had a camera that was covering the door from the inside and I already have Frigate setup. I had a cheap camera laying around that I put up on the outside of the door. I configured the cameras in Frigate and turned on ādogā detection. After a few rounds of adjustments, HA cycles the door via automation whenever a dog is detected in proximity to the door. Its been working wonderfully for a few days now and Iāve taken the collars off. No more collar battery changes! And now I can schedule the door opening within HA by setting conditions on the automation. I donāt know if I wouldāve gone this route if I didnāt have cameras laying around, but now that its up and running, I honestly think its a better solution long term.
1 Like
āDownstreamā (in Apple Home) my device essentially always reports 33% open. My hunch is that Homekit is detecting the OPENING event and then during the CLOSING the cover goes from 100% open to 66% open to 33% open to UNKNOWN and Apple chooses to display the last known-and-good value, instead of the current (āunknownā). I donāt use my door through a HA dashboard and dont have a card setup for it or anything, so I dont know how it looks there offhand (I could poke if we care).
I have it on my main mobile dashboard so I see it all the time. Opens and closes fully without issue. I just opened the device page in HA and cycled it a few times and I see the same thing there. I wouldnāt use homekit if they paid me, so Iām no help there. 
I have noticed that if the Power Pet Door loses network connection, this integration must be reloaded to re-establish communication/control. This doesnāt happen to me often, but when it does, its usually hours or even a day or two before I realize that my HA commands are having no effect. This typically occurs due to a unifi access point rebooting after an update or other maintenance. Iād like to write an automation to reload the integration after a short time if communication is lost. I suppose I could setup a ping presence and trigger it that way? Is there any other sensor or data I could use from the integration to trigger this? Could this be written into the integration somehow? Any other ideas to accomplish this?
I sorta ignored this since it seems nobody cares, but Iām back to trying to solve it because Iām getting a bunch of crashing and rebooting over in Homebridge and when I look at my docker logs I see two different systems spewing errors, seemingly due to this same issue. So Iām replying here to your comment āWhat problem is this actually causing?ā ā¦ wellā¦ itās causing the Homebridge connection to crash and reboot, I believe.
edit: again, just for the record, I recognize thatās a Homebridge issue but Iām pretty sure itās the fault of the Home Assistant entity, hence why Iām posting here.