That sounds like some kind of network issue for your previous HAOS image or something. Something beyond what I could fix with the integration.
I just released 0.3.0, which has the power pet door now appearing as a cover entity, and adds a button for doing the open/close cycle.
This will likely break any existing automations using the power pet door, but they should not be hard to correct.
Thanks to @sdholden28 for the suggestion - it was a great idea, and very logical.
The powerpetdoor.open, powerpetdoor.close and powerpetdoor.toggle actions have been removed, as theyāre now pointless (use cover.open, cover.close on the powerpetdoor cover, and button.press on the powerpetdoor button respectively).
NOTE: As far as I know, there is no āstopā command for the power pet door. So if you choose to open, or close, it will do it all the way. You canāt stop it half way open. Similarly, you canāt select an arbitrary position to open/close to.
Agreed. Given my experiment itās something outside your scope!
UPDATE - @corporategoth provides a much cleaner solution below
Great update. I updated seamlessly via hacs and removed my template sensor without issue. I did enjoy āopeningā and āclosingā status via the template sensor, and that seems to be missing from the cover entity. The code below uses the door_status attribute to change icon and icon colors. The dashboard result is a red āopenā icon when open, green āclosedā when closed, and a yellow āproblemā icon for anything in between. In theory this should let me know at a glance if the door has gotten stuck or has some other abnormal condition.
Icon template:
{%if is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_IDLE')%}
mdi:window-shutter
{%elif is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_CLOSED')%}
mdi:window-shutter
{%elif is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_HOLDING')%}
mdi:window-shutter-open
{%elif is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_KEEPUP')%}
mdi:window-shutter-open
{%else %}
mdi:window-shutter-alert
{%endif%}
Icon color template:
{%if is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_IDLE')%}
green
{%elif is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_CLOSED')%}
green
{%elif is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_HOLDING')%}
red
{%elif is_state_attr('cover.basement_dog_door', 'door_status', 'DOOR_KEEPUP')%}
red
{%else %}
yellow
{%endif%}
There is an attribute of current_position on the cover.
That is 0 for closed, and 100 for open. It will also report 33 and 66 (the door gives me 2 intermediary states both on the way open and on the way closed). Thatās as good as it will get.
Also - your template is wrong.
The door is closed if the status is DOOR_IDLE or DOOR_CLOSED (current_position 0)
The door is open if the status is DOOR_HOLDING or DOOR_KEEPUP (current_position 100)
The door is near the top if the status is DOOR_SLOWING or DOOR_CLOSING_TOP_OPEN (current_position 66)
The door is near the middle/bottom if the status is DOOR_RISING or DOOR_CLOSING_MID_OPEN (current_position 33)
You will get a lot of āalertā shutters
Do with that what you will
Thanks! I knew there was another status (DOOR_KEEPUP) I was missing but I could never see it! I was just watching the state changes. I guess I shouldāve dog into the code! Iāll add that one. Iām looking for the āalertā icon any time the door isnāt fully open or fully closed, which includes opening or closing, but typically thatās just the short time between open or closed.
I would recommend more something like:
{% if state_attr('cover.basement_dog_door', 'current_position') == 0 %}
mdi:window-shutter
{% elif state_attr('cover.basement_dog_door', 'current_position') == 100 %}
mdi:window-shutter-open
{% else %}
mdi:window-shutter-alert
{% endif %}
There is no reason for you to know or code for the door states.
Yes that is MUCH cleaner. I could feel I was going the long way around. Thank you!
Just made a minor improvement again. 0.3.1 has removed the āstopā button (so you canāt press it!), and added back āopeningā and āclosingā statuses.
I upgraded my Power Pet Door installation yesterday and now none of my automations work. Reading through this, is there supposed to be some sort of door status sensor I can use? If so, Iām not seeing anything in entities. If it is that cover type entity, it is continuously showing up as unavailable.
I am reverting my installation to a backup. I guess I will wait to upgrade until I see this issue has been resolved.
It should now show up as a cover entity. So you can user cover.open and cover.close services to open/close it (or the button.press for the cycle button).
Everything else should be the same.
Note - the entity is set to show itself as unavailable if the power is set to off. So make sure the power button is on
Iām fairly certain it was powered on as I was able to operate the door via Home Assistant and it would still respond to my dogsā collars.
I just created a beta version of 0.4.0 - which includes a LOT more settings, that are currently only available to be changed in the app.
I would love some testing of it before I release it.
This will be slightly breaking - mainly because I renamed the entities, so what was something like cover.power_pet_door is likely now going to be cover.power_pet_door_door.
But notifications settings can be set, you can adjust the hold delay, you can see stats on how many times the door has been opened, or retracted itself due to an obstruction. You can even control things like whether it should auto-retract on an obstruction.
I havenāt put the scheduling stuff in yet. I know how to do the scheduling from an API/protocol level. However, how to actually do that in Home Assistant is another story (HA doesnāt give me many good options for how to store it - or manipulate it). Same for the time zone, I can get it, but I donāt want to just make it a text field, as that will open things up to trouble if someone edits it. Iām still thinking on how to handle these.
Oh, and I finally put in the MR to get this into HACS natively, without needing to add a custom repository.
Iām happy to test. Thanks so much for the efforts. The best way to install the beta is manually I assume?
If, in the HACS Download screen, you enable the āShow beta versionsā option, you should then see 0.4.0-beta1 in the drop down to install. So no, you donāt need to do a manual install.
FYI - I am trying to implement the scheduling feature.
I can create schedule entities (that read the schedule from the pet door), and have the code to set new schedules too.
HOWEVER, the problem is that the Schedule component is backed by Storage, and so the schedule entities I have can tell you if, according to the schedule, itās scheduled to be on or off, but does NOT give you the ability to edit the schedule in the UI.
Iām trying to figure out if there is a way I can make this happen. But it seems the schedule component (which matches up with the front end control) is poorly designed, and gives you no ability to update the storage via. the entity, NOR the ability to access the storage to add/update it there so it could notify the entity.
Right now, the only access to the storage directly is via. a websockets API - and using the websockets API to edit core properties from WITHIN core seems kludgy. Iām trying to see if I can work around it somehow.
Itās frustrating that all the support to handle reading/setting schedules is done from the pet door integration standpoint, itās just presenting a UI to edit them in the home assistant frontend thatās proving annoying.
Should the āNotify Inside Onā, āNotify Outside Onā etc options be working? Am I correct in thinking those toggles would enable/disable the push notifications from the Power Pet Door app? I receive an error when trying to toggle those options, but I didnāt want to submit an issue if I donāt understand their function correctly.
Thanks for that. They were indeed broken. I fixed them now
I also released 0.4.0. I could not yet get stuff working with the schedule, because I need actual support for the schedule entity in Home Assistant (that allows other entities to plug in/use it easily).
Nice integration!
Is there an option to detect if the door is open from the outside or inside? If so, how can it be achieved?
This information is unavailable.
We only know the door opened, not which sensor caused it to be opened. The hardware does not provide that information.