Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Hey there @benleb, @Danielhiversen, mind taking a look at this pull request as it has been labeled with an integration (surepetcare) you are listed as a code owner for? Thanks!

Tested on my own sureflap and this PR restores the integration to fully working again 👍

lgtm :) thanks for the quick fix!

If you & @Danielhiversen are happy, it comes down to one of you approving the last workflow I think :)
Hopefully the most recent changes worked for @daernsinstantfortress and @timsprawe. Thanks for all the help!

lgtm :) thanks for the quick fix!

If you & @Danielhiversen are happy, it comes down to one of you approving the last workflow I think :) Hopefully the most recent changes worked for @daernsinstantfortress and @timsprawe. Thanks for all the help!

I lack the required permissions, sorry :/ But I am sure @Danielhiversen will do it asap 👍

lgtm :) thanks for the quick fix!

If you & @Danielhiversen are happy, it comes down to one of you approving the last workflow I think :) Hopefully the most recent changes worked for @daernsinstantfortress and @timsprawe. Thanks for all the help!

Works like a charm! Thanks to all devs :)

lgtm :) thanks for the quick fix!

If you & @Danielhiversen are happy, it comes down to one of you approving the last workflow I think :) Hopefully the most recent changes worked for @daernsinstantfortress and @timsprawe. Thanks for all the help!

Works like a charm! Thanks to all devs :)

All good here too. Nice one and thanks for the rapid intervention here.

Does NOT look good to me, it worked before the update, now it's broken, i.e the status of the pets and the connectivity entity are not available anymore although the battery state and locking unlocking the flap still work

Does NOT look good to me, it worked before the update, now it's broken, i.e the status of the pets and the connectivity entity are not available anymore although the battery state and locking unlocking the flap still work

Please provide your logs.

@MadMonkey87 are you referring to the sureHA version? If so, as the others have said, your logs would be very useful.

If you're talking about the latest version of HA, this fix hasn't been incorporated yet so it will be broken in the HA integration.

@MadMonkey87 are you referring to the sureHA version? If so, as the others have said, your logs would be very useful.

If you're talking about the latest version of HA, this fix hasn't been incorporated yet so it will be broken in the HA integration.

Then it might be the later, I'am sorry🤐 Looking into the code here this indeed seems to be the case:

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in _async_setup_platform await asyncio.shield(awaitable) File "/usr/src/homeassistant/homeassistant/components/surepetcare/binary_sensor.py", line 44, in async_setup_entry entities.append(DeviceConnectivity(surepy_entity.id, coordinator)) ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/surepetcare/binary_sensor.py", line 130, in init super().init(surepetcare_id, coordinator) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/surepetcare/binary_sensor.py", line 62, in init super().init(surepetcare_id, coordinator) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/surepetcare/entity.py", line 45, in init self._update_attr(coordinator.data[surepetcare_id]) ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/surepetcare/binary_sensor.py", line 141, in _update_attr "hub_rssi": f"{state['signal']['hub_rssi']:.2f}", ~~~~~~~~~~~~~~~^^^^^^^^^^^^ KeyError: 'hub_rssi'

Yeah that's the original error that this PR fixes. We'll have to wait for this to trickle through unfortunately.

After all of the hard work, it's slightly frustrating that this didn't get included in today's 2025.4.4 update as it would have been a perfect opportunity for it.

@frenck Sorry to prod you directly, but this integration is down for all users right now, the fix is submitted and tested and ready to go - it just needs accepting and merging, but there's noone active here with access rights to do it. Is this something you could help with? At least then it can get into the 2025.5.0 release.

Tests are failing, can you take a look?

@joostlek so I'm not entirely certain what the tests are doing in all honesty. The test failing seems to be checking that unique ids are being generated (which they are) but failing on a check for the actual value of the state - I believe this is because the mock feeder is missing the 'online' status, which I believe is in error.

I am assuming this bugfix was needed because the API changed, so then the tests should be updated to reflect what the API does I guess

I think this was an old error to be honest, but in fixing the actual API change we also used a slightly different way to set the state (based off an actual 'online' status, not just the existence of data), which wasn't reflected in the original tests.

If it's ready for review, please use the button :)

Woops! Sorry 😅