Did you ever try reading the firmware using a pickit? I’m seriously thinking about ordering a pickit4 to try this, unless surepet did set the read-protect bit on the pic?
If I can read it using a pickit I can try to modify the firmware and upload a modified version. I should be able to find the CA inside the 233.364 firmware, change it and try to get it to connect to my PetHubLocal installation.
Just a FYI on using an ESP32 or similar an the MRF24J40MA which is the 802.15.4 aka Zigbee radio controller.
The main trick is to have your 2.4G WiFi on Channel 11, as I am fairly certain that the surepet stack all works on 802.15.4 channel 15 (if memory serves). ZigBee and Wi-Fi Coexistence | MetaGeek
I am sure that is why Surepet made the Hub wired only rather than offering it wireless. As that way you only have one radio transmitter which is the MRF24J40MA on 802.15.4 channel 15 rather than having 2.4G WiFi interfere with the 802.15.4 or build the device to only work on 5Ghz WiFi.
But… If we document it and say “please don’t do this as it will cause interference” and the geeks who will build the whole stack will know how to configure 2.4G WiFi properly right?? … Right? 
So… a bit more of an update on this. The new firmware doesn’t appear to be easily worked around. I suspect it has been rolled out to most hubs now but if you don’t want it I recommend you block port 80 to hub.api.surehub.io
You could also be unlucky that they push down the MQTT message to force a firmware update. Which I can help with if needed.
Another interesting find is the latest distros with the latest OpenSSL has the older cipher used in the hub disabled. So now I will need to build a docker image using Debian oldstable which still seems to work.
The passive aggressive messages in the hub console are such a 
move. So… I’m not particularly impressed with Surepet.
I am not sure what you mean with “passive aggressive boot loader”, but I think we already came to the conclusion Surepet doesn´t want to lose control of their devices so unfortunately they will do everything in their power to stop us from being able to replace the firmware of the hubs.
Regarding your findings about OpenSSL, just thinking about a potencial future where we find a way to downgrade the firmware, shouldn´t we all block the port 80 you mention now to avoid Surepet upgrading the hub firmware even before we find the solution for the current firmware? I understand the device/hub will still work with the port 80 blocked because it uses other ports for the normal tasks and only uses port 80 for firmware upgrades, right?
Yes, but I suspect everyone has now had the updated firmware applied if their hub has been connected to the internet. My development hub has only had one attempt to firmware update from surepet as I have no doubt they are reading this thread (hello, I have emailed you folks a few times about wanting to speak about some other issues I have found, but you have never responded 
) where I received via MQTT 1000 11 0 1 0 which was a message I hadn’t seen before.
A type 11 message reboots the hub and forces it into bootloader mode to do a firmware update.
Yes but what I mean is that we cannot go back in time and avoid the hub to update to the latest firmware as that already happened for most of us, but if we block port 80 now (btw, shouldn´t we block 443 as well?) at least we will avoid any new firmware to be applied, right? I am just thinking that even if we find a way to downgrade the current firmware, Surepet could launch a new firmware and apply it to our hubs before we have time to do the downgrade so we would be in the same situation again. So the question is, should all of us block port 80 (and 443?) now so the hub cannot upgrade its firmware to any potential new version they release?
Hello,do you have news on the subject?
is it possible with the serial cable to downgrade the firmware?
Hello,
I own a SureFlap Microchip Cat Flap Connect without hub currently. Is there some way I can help the development of this project? I would love an open source hub for the cat flap. If I now buy the official hub I will probably end up with the new incompatible firmware, right?
I can help with python programming, docker and also developing or testing hardware if you need any help currently @peterl .
There was code I started on @Malaber that I started here: https://github.com/plambrechtsen/pethublocal/tree/main/WemosPetHub but it is using a MRF24J and an ESP32. I never finished the code and don’t have time for working on it.
Others seem interested but no one has yet picked it up.
Feature request: please finish your work on the ESP32 replacement hub! · Issue #15 · plambrechtsen/pethublocal · GitHub
Did it continue to run well on 6.3V? I was also thinking about using an external power supply, but I have been worried about interference. I see all the antennas for DIY kits come with a warning to not use switching power supplies or other power sources than batteries due to interference and reading range being affected.
Perhaps the power supply can be conditioned to be better? Capacitor to kill noise? I do not know the issue well enough.
It still works fine for me, kitty gets in and out every day 
I can confirm that sure catflap is a bit sensitive for the right voltage. I added a diode between the catflap and battery compartment and added a 5v power supply with a small step-up converter to adjes the voltage to 6v. This way, the normal batteries act as power backup in case of power outage. Because the diode cuts apprx 0,5 volt off, the power will be just enough to work with batteries (5,5v) but my home assistant will see a low power (that normally never should occur, so I can send an alert). Below 5,5v it seems to work but the RFID does’nt get reliable results
Folks, just a head up regarding the external power supply: Both, the cat flap and even the feeders are working with 6V Pb and 4s LiFePo Batteries. The highest Voltage i´ve tried was 7V from the LiFePo´s. So, the devices were not “grilled” and are working fine. There was no Interference or noticable “QRM”. If there´s time left, i´ll start a new thread with this feature and will post a few photos with the feeding points on the PCB, a starting help for all sureflap/feeder owners, that want to try this. greez
Another huge SurePet outage. This is horribly frustrating. My cats were locked outside by this.
Same here, I’ve asked them for a local api once more…
Same here, I replaced the battery twice before giving up, I don´t understand what SurePet gets by forcing us to use their servers instead of providing a local API, is it so important for them to know when my pet enters or leave the house? if so, just keep both options! I would happily let my catflap send data to SurePet servers as long as I can control it locally
I consider completely unacceptable that our pets can get locked every time the server of a company totally out of our control has some issues, and considering we have already tried to contact SurePet in multiple occasions and they have never replied I am propossing a new method of action, which is all of us providing negative feedback in every platform we have access to (google reviews, trustpilot, etc.) letting them know we are really unhappy with the fact that they don´t provide a local API to control our devices. I think if we all write negatives reviews explaining the reason we will get their attention, and hopefully some day get a local API to control the devices we have already paid for.
can I ask where in the world are you ?
myself I’m in New Zealand and have had no server issues, I’m assuming there use different server locals for different parts of the world
Thanks for writing a review I posted one also.
One year ago Sure Petcare replied:
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.
The Netherlands