I think a replacement hub would be better since it would hopefully only need to be done once for all SurePet devices e.g. flaps and feeders. Otherwise each device type would likely need its own specific mod. Having said that, there’s no guarantee that the separate devices use the same protocol to talk to the hub so that might need decoding on a specific basis, but at least it would be a software adaptation instead of a hardware one.
BTW I tried to modify my flap to run off a 6v power supply instead of batteries but it introduced some interference somehow and stopped the RFID reader working (if anyone knows of a way to get this working please let me know). Just mentioning it in case it’s worth testing early on whether the RFID reader will tolerate a nearby Wi-Fi device. I guess it should do since if Zigbee is currently being used then Wi-Fi is the same frequency.
The RFID should be reading on 125 and/or 134khz in order to read a pets ID. So WiFi shouldn’t be interfering with the reader.
The reason I’m thinking about modifying the feeder instead of building a new hub is because in my experience I’m missing meals from my feeders (I have 4 of them!).
Sometimes I can see the cat eating quite a bit but the surefeed app isn’t sending a notification after the cat finished her meal. In the app, in the household list, there is no mention of the cat feeding at that specific time. So it’s failing to send the update.
When the cat goes back for a meal several hours later that meal usually gets recognized but the amount she ate isn’t correct. In the end of the day, if I sum up all feeding moments the total amount of food the cat ate doesn’t match the amount of food I put in…
Maybe the hub and/or cloud is just bad and it’s working much better with PetHubLocal? I can’t tell because my hub is running the latest firmware and it’s not possible to downgrade in order to test PetHubLocal
I just opened the feeder to see what’s in side. Just out of curiosity. I’m not (yet) really planning on modifying it because I don’t have the time at the moment.
The loop where the cat sticks his head in, when going to food bowls, is a big rfid coil. There are IR transmitters and receivers inside the loop too, these are there to detect presence of a cat and activate the RFid reader only when there’s something inside the loop.
I assume the reason for the IR transmitters/receivers is for lower power consumption because the device is battery powered. The rfid reader won’t be running long on batteries if it was on 24/7.
There are 2 load cells for weighing the amount of food.
And a simple dc motor to open/close the lid.
It’s a quite simple device and making it work using an arduino mkr wifi should be reasonably easy. The device would then be connecting to wifi on it’s own, no hub needed. Fully open source so we can do whatever we want.
But I do get what you’re saying. A custom hub is probably more interesting because it doesn’t require modding every single different device. I’m just unsure how reliably the feeders are on their own because of the issue I’m having (see previous post).
Thinking about the reliability of the feeder. It might be the case that the feeding moments I’m missing in the surefeed app are the ones when cat B enters the feeder of cat A when she finishes eating. At that moment the feeder closes quickly and I think those feeding moments are always missing in the app.
It’s probably a bug in the app/cloud and I guess the feeder itself will send all events correctly. So a custom hub will probably fix that too.
Oh damn. I wish I had an older hub that I can use for PetHubLocal…
I run my hub and the cat flap powered by ethernet (PoE). This is 5V which is just what the hub uses. I used a split cable to feed the same 5V to the flap and it did seem to work – but the RFID reading was unreliable.
After adding an adjustable voltage regulator and increasing the voltage a bit (the battery indicator now reads 6.3V), everything works well.
So just a guess but maybe your power supply is not quite 6V?
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?
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 .
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.
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
move. So… I’m not particularly impressed with Surepet.
) where I received via MQTT 