Create a Roadmap

[lp55]

Hi,

@benleb has invited me to collaborate on the surepy & sureha repos. So I thought that one of the first things that should be done is a roadmap. Here are the itens I though about:

• Add Tests (this would make it easier to verify when APIs change/break the current code
• Fix standing bugs
• Improve code documentation
• Improve README
• Merge the Felaqua code I did in my repos (added drinking consumption habits for the pets and sensors for sureha)

Any other ideas?
And who else is willing to help?
I only have a Felaqua, so there's a limit in what I can help regarding some bugs/features with my current access.

[Zhephyr54]

Hi,
On the HA integration, It could be nice to support custom locations when having more than 1 flap. Not sure how hard it would be to implement but it could work like this:

• On initial setup of the integration, if detecting more than 1 flap, add the possibility to configure a mapping for each flap in/out with the Location enums (Inside, Outside) + HA areas (or simple string if its too complicated), so you could map it this way for example :
  • Hallway flap In: Inside
  • Hallway flap Out: garage
  • Garage flap In: garage
  • Garage flap out: Outside
• Change the cat binary sensor to a select

What do you think?

[FirstRulez]

Hi, On the HA integration, It could be nice to support custom locations when having more than 1 flap. Not sure how hard it would be to implement but it could work like this:

• On initial setup of the integration, if detecting more than 1 flap, add the possibility to configure a mapping for each flap in/out with the Location enums (Inside, Outside) + HA areas (or simple string if its too complicated), so you could map it this way for example :

  • Hallway flap In: Inside
  • Hallway flap Out: garage
  • Garage flap In: garage
  • Garage flap out: Outside

• Change the cat binary sensor to a select

What do you think?

This is something I'd really appreciate - we have a setup like this with two flaps which Sure have no interest in supporting from the feedback I've had.

[lp55]

That's an interesting suggestion. Would any of you be willing to help with data or code for that? I don't have flaps, so I can't test that with my user data.

[Zhephyr54]

Sure, I would be glad to help.
I got the logic implemented in node red for now:
When any of the binary sensors state for my cats change, I am getting the pets info from the /api/pet?with=position
endpoint:

// Ids changed
{
    "data": [
        {
            "id": 1,
            "name": "Cat 1",
            "gender": 1,
            ..., // omitted
            "status": {
                "activity": {
                    "id": 42,
                    "pet_id": 1,
                    "tag_id": 11,
                    "device_id": 116,
                    "where": 1,
                    "since": "2025-02-25T06:02:53+00:00"
                },
                "feeding": {
                    ... // omitted
                }
            },
            "position": {
                "id": 42,
                "pet_id": 1,
                "tag_id": 11,
                "device_id": 116,
                "where": 1,
                "since": "2025-02-25T06:02:53+00:00"
            }
        },
        ... // other pet, omitted
    ],
    "meta": {
        "page": 1,
        "page_size": 1000,
        "count": 2,
        "total_pages": 1
    }
}

Then, knowing which device id is corresponding to which flap, I am just mapping the position (activity seems to also contains the same info but I guess it might contain other info depending on the last activity of the cat (feeding, drinking...)) device_id + where (inside/outside) to the matching location string and set the pet input_select.

[Zhephyr54]

Just to let you know, I implemented this feature in the core integration, but have not yet submitted a PR as I would need a change in the HA core architecture to correctly handle the new config flow step form translations.
Here is the proposal if anyone wants to help by upvoting it.

Here is what it looks like (I have 2 flaps):

• Conflig flow:
  
  
  

• New select entity per cat:
  

[benleb]

@lp55 if you need anything, feel free to contact me (dont know how to contact you 😅).

@Zhephyr54 nice work! :D

About the "tests" and "docs" in the roadmap, I think that can do an AI for us 👍 Will try it at the weekend :D And guess I will also be able to be more active again in future probably :) (If its urgent or so, please try to contact me directly, not via github :D)

[Daneish]

Hi Ip55, thanks for jumping in to work on the repos! I have two Feeder bowls. I’m not a developer, but would be happy to help with testing, or interacting with the API to provide information on the Feeders.

[FredrikM97]

A contribution file would be nice

[Zhephyr54]

@benleb I just submitted a PR to add the pet location select entity feature to the HA core integration 😄

[FredrikM97]

After looking a bit at the repository I feel that a lot of functionality is bundled together and a bit hard coded. It kind of works but difficult to test and update. I started working on a new implementation that hopefully can use the v2 api (noticed that the api is still lacking)
Feel free to take inspiration if you want for this project. https://github.com/FredrikM97/py-surepetcare

[lp55]

After looking a bit at the repository I feel that a lot of functionality is bundled together and a bit hard coded. It kind of works but difficult to test and update. I started working on a new implementation that hopefully can use the v2 api (noticed that the api is still lacking) Feel free to take inspiration if you want for this project. https://github.com/FredrikM97/surepy

HI, I felt the same when I took a closer look at the code. There's also a lot of unused code. I also think sureha has some similar issues. That's why I asked if people were using surepy outside sureha/home assistant here. My idea was to sort redo it. Here's what I though would be a good structure:

REST API calls
|->remove unused calls
|->api tests that validate that the expected response is still returned (so if SurePet changes something in the API, it's quickly caught)
|->mock tests
|->converts json to proper python data structure (using enums instead of numbers, etc, but keeping it very close to the JSON)

HA part
|-> structures pooling, stores data to reduce data requests
|-> converts api calls data structure to ha data structure
|-> implement tests

I haven't taken a detailed look at @FredrikM97 code, but it seems like you had a similar idea.
Life happened in this meanwhile and I haven't had time to work on this code yet. But hopefully in the next week I'll have more time to do so.
One thing I remember from the original surepy/sureha is that appears to have some weird edge cases / api / ha issues that it had to workaround it. It seems to be more on the pet flap code. That's a point of attention.

[lp55]

After looking a bit at the repository I feel that a lot of functionality is bundled together and a bit hard coded. It kind of works but difficult to test and update. I started working on a new implementation that hopefully can use the v2 api (noticed that the api is still lacking) Feel free to take inspiration if you want for this project. https://github.com/FredrikM97/surepy

@FredrikM97 I suggest that you rename you repo to something like surepy2 or sureapi or whatever so it's not confused as a simple fork. Your code can't be used by sureha directly, correct?

[FredrikM97]

->remove unused calls |->api tests that validate that the expected response is still returned (so if SurePet changes something in the API, it's quickly caught) |->mock tests |->converts json to proper python data structure (using enums instead of numbers, etc, but keeping it very close to the JSON)

HA part |-> structures pooling, stores data to reduce data requests |-> converts api calls data structure to ha data structure |-> implement tests

This is a good idea. It might be worth creating a surepyv2 or similar module within this library. I started refactoring parts of the original surepy code, but the lack of tests and the tight coupling between devices (especially the flap), client, and authentication made it very challenging to make changes without breaking existing functionality.

Additionally, I’m concerned that the client currently stores the username and password in plain text, which is not ideal from a security perspective.

After looking a bit at the repository I feel that a lot of functionality is bundled together and a bit hard coded. It kind of works but difficult to test and update. I started working on a new implementation that hopefully can use the v2 api (noticed that the api is still lacking) Feel free to take inspiration if you want for this project. https://github.com/FredrikM97/surepy

@FredrikM97 I suggest that you rename you repo to something like surepy2 or sureapi or whatever so it's not confused as a simple fork. Your code can't be used by sureha directly, correct?

That’s correct. My repository will break the current sureha implementation, and I’m still missing support for several devices and POST requests. However, the existing sureha implementation is already broken for Feeder Connect and I feel it have a complex structure for adding new devices. I hope to eventually create a new sureha integration that is built around actual devices, rather than mapping sensors as devices (which is how the feeder is currently handled).

I hope I can create a guide in the near future to guide users to create pull requests/mock data so I can implement support for more device.