Alright, that sucks. I’m thinking of building the Wemos or Pi version, I’d rather do that than getting their hub.
How’s your hardware/software engineering skills. You’re gonna need em!
@lurvig if you want to investigate all the work already done in that area I recommend you to read this thread from the beginning.
You can also look here: https://pethublocal.github.io/
As you can see it was possible in the past to update the firmware of the hub with a custom firmware that included local control, but surepet applied a patch in one of their firmware updates and it is not possible anymore.
So an update. I actually mentioned wanting a local API in my trustpilot review.
What is good to see, the company not only reached out to me, they also investigated my account on their servers to try and help. In my case, that actually helped, because my hub wasn’t work for a while now with the pethublocal project.
In the meantime, I have now checked your profile, and can see both your Hub and Pet Door are offline since over a year.
So that got me on the right path. I was super lucky, I found a backup of my old firmware from 2022 and even better, the config contained my client_certificate(credentials) which you can’t get anymore either from their cloud.
This did allow me to get my hub back and working with pethublocal.
In my email response on the ticket they created to me, I made sure to let them know I am using pethublocal (what a great project).
Something else they mentioned, not sure what it is worth, but maybe:
While we use an industry standard communication method, we do not use the same protocol of communication, mainly because our products are battery powered and therefore, we cannot work the same way and still maintain a reasonable battery life.
We are currently in the process of updating our products range and services, and we feel that in the future we may have an open API, but currently this is not something we can offer to you or support.
Please do keep an eye on our website and social media feeds for any further updates on open API and other product integration.
Ideally, they should just allow customers to use a firmware again that can be spoofed like 2.43, an opt-in approach, very much like Bambulab did for their X1C printer with custom open firmware.
@tinuva lucky you!!
When I first read your comment I thought surepet helped you in some way (like getting your old firmware), but soon I realised the only thing they did was giving you the same excuse they are giving to each one of us: “we use a different communication protocol because our devices are battery opperated” which is completely false, as the standard zigbee is specificially designed for battery opperated devices (they just changed it a bit to make it incompatible with the standard zigbee protocol, and they did that on purpose), and “in the future we may have an open API” which is a complete lie as well, as they have been saying the same BS for years now.
Regarding your last comment, I´m afraid I have to dissagree, they don´t need to allow customers to use a firmware that can be spoofed, what they should do is to include a local API into their firmware so all customer have the possibility of controling their devices locally, without having to spoof or modify the firmware at all. Companies must understand IT IS NOT OK to sell you a device that will stop working anytime they want, and as customers WE WILL NOT ACCEPT THAT
For everyone reading this comment, if you haven´t written a review yet, please write a 1-star review and mention the lack of a local API, we already got 14% of 1-star reviews in their trustpilot page and they are contacting us trying to get the reviews removed, so this is working:
Yeah I said “ideally”, not “must” or “have to”. Would cost them very little dev time, unlike building the local api.
Reading between the lines, the local api version, will be a new hub, as in new product. It will not come to the existing hubs. Probably because of memory constraints.
Nah don’t think so. A local API would not require a new product or loads of time. All it requires is willingness which Surepet don’t seem to have… yet.
2 Likes
@tinuva I totally agree with @fenty17, a local API will only cost them a bit of development effort and will run on the same hardware for sure. Exposing a local API is just opening a door to the current code that is already running in the device. They could even update their app to make use of that local API as that would make their app to respond much faster (currently the app is really slow, and the reason is clearly the time it takes to connect to their busy servers).
Regarding our preferences, ideally they should develop this local API and make it available to all their customers, as many other companies do. Your idea of allowing us to “hack” the firmware is not a bad idea, but it would be just a workaround (that of course many of us would happily use), but it wouldn´t be the ideal solution.
The first step is for surepet to show any willingness to do something about it (even talk with us to discuss options), but so far their answer has always been complete silence, hopefully the 1-star reviews will apply enough pressure to change that.
So, what the both of you don’t understand, is that hardware have limitations. What if these devices just don’t have enough space to add a local-api in to it. At best, the devices might be able to connect to an additional local mqtt endpoint. Having the api added, is an ask that might just be impossible if there is no space for the extra code. Or they have to remove something else to make it possible, and they might just not want to do that.
Expectations should meet reality.
@tinuva you are right, when we talk about “local API” we mean local access, which has multiple potential solutions and not only a local API (including the connection to a local MQTT as you mention), it is basically a way to control the devices locally, removing the cloud dependency. I believe the local API would be the best option as they could use it to make their app faster, but that is just going into the details of how they decide to implement it.
I am sure their developers know how to do it, it´s the management team that took the decision to make their devices dependent on their servers. In the unlikely scenario that they don´t know how to do it, Surepet just needs to be willing to talk and discuss options, the HA community would be more than happy to help them if they have any technical challenges.
All they would have to do would be to allow us to set our own MQTT server. Then they could leave the rest to the community. This would allow them to do the bare minimum, while saying they’re helping the open-source community.
1 Like
That seems very unlikely to me. I have ESP32s over the house that could hold many more lines of code and fulfil loads of features I don’t currently use. Having said that, I agree with the other comments that all we would need is the basic tools (e.g. MQTT) to allow enthusiasts/the HA community to get what we need.
FYI - I do not own a Surepet product! I would like to purchase one (6 month old kitten) but cannot believe that the only credible solution on the market involves relying on company servers that may fall over and lock my cat in or out!
In case it helps, I don’t believe the Surepet products actually rely on remote servers - only the remote control via phone and logging are reliant on them. The core functionality of only letting in your cat by checking its RFID has never failed for me, even when the servers are down. I’ve also never had the flap open or close or change mode by itself so that side of things seems reliable. That’s not to say it wouldn’t be possible in future though e.g. due to a bug or if Sure Petcare were hacked. So I’m not defending the lack of local control since that should be a given - it’s just that I still find the product useful without it and so you might too. I actually got mine just to stop other cats coming in - so it just sits in the back door in the same mode do that all the time, with or without servers, and would continue to do so if even Sure Petcare went bust. The logging can be handy, but it easily goes wrong if a cat follows you out of a door for instance. All remote functions also have a button on the device itself - just like the versions of these devices that don’t have a server link (i.e. that don’t have a hub).
1 Like
Regarding the local API, these devices already have one - it’s how the hub talks to them. The problem is that someone at Sure Petcare decided to keep it proprietary and encrypt the traffic. To be fair, there is a valid angle to this which is to keep hackers out and maybe make it harder for other companies to copy or build products that could take sales away from Sure Petcare. But that shouldn’t preclude local control - we only need a username and password to protect a router for instance, so it wouldn’t be hard or require any development effort to use that method to keep hackers out and let owners in.
I think we are mixing concepts here, let me try to clarify it.
As we all know, the catflap is connected to the hub using a modified zigbee protocol. In an ideal world Surepet would have used the standard zigbee protocol, and that would have solved all our issues, as we would have been able to connect the catflap to z2m using any zigbee coordinator, and would have removed the need to buy the surepet hub. Now this solution seems difficult if not impossible to implement for our devices, as it would require to update the firmware of both the catflap and the hub to change the communication protocol to the standard zigbee. Considering this, I think the probability of this happening is almost zero.
The solution we are proposing is a local API to access the hub (not the catflap) which doesn´t involve any modification in how the catflap communicates with the hub. This local API could also be used by their own app to make it faster, as the performance of the app is really bad due to the slow response of their servers.
@user_id_for_q you are right regarding the catflap, as it keeps working without an internet connection. The device that stops working and would become useless if Surepet went bust is the hub, and that is the main reason why most of us have chosen this model and have bought their hub.
While true, their outage created a dangerous situation for our cats. At the time we were selling our house, we had to get the cats outside during showings, so we would lock the flaps. The three day outage happened not long after we locked the flaps for a showing. So my cats were not able to safely get in at night for days, or outside to go to the bathroom.
While an edge case, that’s a HUGE safety issue and breach of trust.
Probably a terrible place to ask this, but can anyone recommend another RFID smart feeder like the SurePet one? I’m looking for one that ‘opens’ the bowl, not dump out food when they get near it.
No way I’m giving SurePet more money.
I think it would be useful to clarify whether you were actually living in your house at the time. It sounds like you were away or you could have just used the buttons on the cat flap itself when the servers were down? If you were living there it sounds like your cat flap stops working when the the servers are down, which would mean I should change my reply to fenty17 above since there must be flap variants out there that don’t work without the servers.
Yeah, I was relying on the cloud to be able to unlock them - and could not. That’s like a REALLY bad betrayal of trust and safety.
Really appreciate the input and views on this thread. I’m in such a hard place as I don’t want to support Surepet by buying one of their products, but I don’t see any alternatives other than punting for an Only Cat at double the price and unknown risk/ship time. I could buy Surepet anyway and hope something changes, or relent and succomb to their cloud. But at this point I’m seriously considering a dumb solution even though it doesn’t feel right!!
Sidenote - not sure if this has changed but reviews on their website are not from Trustpilot so maybe we need to bomb them on the other platform too?