@benleb I was not updating to latest version of HA because the integration was not included yet.
Today I bite the bullet and installed latest version of HA, did remove the unnecessary lines in configuration.yaml and also remove the old integration files. When upgrade of HA was finished everything seems to work, but I noticed nothing updates, if the cats go outside it shows still inside, waited 20 minutes nothing changed. Then checked the entities everything seems to work except the sensor.pet_flap_tuin_kattenluik I am not sure if this is part from old integration or the new one.
It would be great value to the community to have a solution that does not rely on the internet service of the company. All companies go belly-up or stop supporting services at some point in time, and then these expansive cat flaps will become a brick.
Like you, I have the cat flap connect with Hub; but honestly have not the skills to replicate what you have created. There are some smart cookies on this chat who could prob create a solution over time, but I understand that you all have day jobs as well and already have built part a solution independently.
Well done to all and hopefully over time we have the privilege to a solution that is no longer dependent on the cloud
Hi
I seem to be missing the flap status (unlocked etc) - does it take several different polls to the surepet API to grab all the sensor data? I am getting connectivity and battery sensors though
Thank you, I’ve tested the solution via HACS and I was able to manually change the flap locks to: unlocked, locked_in, locked_out, locked_all.
Unfortunately, the script still does not seem to update the status within HA entities, or HA itself does not register the change and does not update lovelace UI. Strange
May I ask if you plan to add additional bindings to the code in the future, similar to those documented on Sure Petcare - Bindings | openHAB ?
One feature I would love to see in future is to be able to manually set the status of the pets to “outside” or “inside”, as we sometimes open the window to let them out.
Thank you for sharing and well done.
I doubt I have the skills and patience to deploy your solution, but its good to know a solution exists. Unfortunately, I am not very familiar with coding so cannot help much, sorry.
I’ve put this dev branch in as a custom component.
It seems to be working. But I’m not getting any info on feeder status other than battery and connectivity. I thought the feeders were more integrated now.
Should weight and feeding info be available in home assistant with this dev component ?
@flyize Once you set the following, you should be presented with the various sensors, depending on your account:
#SurePetCare credentials set in configuration.yaml
surepetcare:
username: !secret my_email_address
password: !secret surepetcare_password
Replace/define the username/password credentials in your own Home Assistant secrets.yaml file, as per guide here
In my case I am presented with various entities for 1x hub, 1x cat connect flap, 2x pets. I can execute the “set_lock_state” service with all 4x values that are available as options (unlocked, locked_all, locked_in, locked_out). There are currently no other service calls defined in script, as far as I’m aware of.
If you do not have your flap_id value already, you may have to enter some dummy flap_id value first, and execute the service call. The error message should then indicate other (possible) correct values to try next. I am presented with 4x values, two of which are the IDs for my pets, and 1x each for the connect flap and the hub. Try each value out and one of them will work.
@benleb , I believe there is some clash/mix between the official surepetcare repo (which has some known issues) and the updated one that some of us loaded via HACS. The result seems to indicate to me that values/fields are not correctly updated and/or presented into lovelace.
In my case I get the updated (correct) data in lovelace after I manually change the hass:icons to something else. Once I select “Update”, the correct pet_status/lock_Status/battery_state is displayed. The manual update of the hass:icon seems to trigger a refresh of the values, which in turn presents the correct data.
Hope the above observation of mine makes some sense to you. I feel that once the updated code is within the official HA/HASSIO repo, it will all sort itself out.