Hi Peterl,
I could do that - but I’m away from my home location until June 10th. I will contact you, when I’m back.
Thanks a lot.
Rgds
Gerald
I will check with a friend of mine who lives around the corner who has standard setup but hasn’t run the hacked version over the weekend. Will let everyone know how I get on.
… And seems to be running the new firmware.
1 Like
Hi, as I have the v2 Hub, I’m probably interested in the Wemos way. I have the MRF24J40MA and an ESP32 devkit, but I struggle to make the firmware at least semi-working. It does not capture any messages. I know it’s probably abandoned project, but I would really appreciate at least some info on how this is supposed to work or what to expect etc. Thank you.
Ok, got it semi-working. Now it receives some messages (the problem was two pins on my ESP32 dev board were marked as 23, only one is good). But how do I find out how to lock and unlock the door? I’m trying to capture some messages from the hub, but there are too many when locking an unlocking 
Did anyone possibly did figure this out already?
1 Like
Thanks @peterl, we have big hope in this project 
As a paralell question, reading some comments on this thread it seems the connection between the hub and the flap is zigbee, has anyone been able to sniff this zigbee traffic to see if it can be reproduced? I have done some work sniffing the traffic of my zigbee network (zigbee2mqtt) and I am happy to help in case this option has not been fully explored.
Being able to integrate the flap in our zigbee networks so the hub is not required anymore would be a dream.
EDIT: I have found this thread that partially answers my question: The 2.4GHz protocol is likely Zigbee related · Issue #8 · alextoft/sureflap · GitHub. It seems people were trying the zigbee route, but it was parked as the cloud solution looked simpler at the time, maybe that option could be reconsider now in case the new hub firmware cannot be downgraded.
Hi @heisenberg and @drejk
Just a bit of a status update on where I stand with a few things, broken down based on the hub type:
– Hub V1
This is the hub that I have and was made prior to about 18 months ago when SureFlap went for FCC approval of the V2. It’s based on a full Microchip stack (CPU + Zigbee radio + Ethernet) documented here which shows what it looks like on the inside.
There have been a number of different firmware builds that I have managed to use.
-
2.43this was builtJan 17 2020the version I figured out that it wasn’t checking for a signed certificate that can be downgrade flashed onto the hub if a newer version has been applied -
2.201this was builtApr 21 2021and they introduced certificate checking so the trick of generating your own certificate and using PHL no longer worked. I have figured out how to byte-patch my own CA certificate into the firmware after figuring out how to add the CRC to the file. That is available here but my concern is I didn’t want to brick peoples hubs either with downgrading firmware or them applying the byte patched firmware so I didn’t add too much documentation on how to do it but those interested might find it. I was still able to download this version as the bootloader version1.117hadn’t changed so doing the download from SureFlap’s site was easy. -
233.364this is the latest version and I don’t (yet) have a copy of this firmware. I suspect they have changed the bootloader but I can’t be sure. Need to get my hands on a hub and see what it does connected to my isolated network. Again I am worried about either downgrading to2.43or2.201as it could leave folks with a $100 brick that I created. But am going to see if I can borrow a hub from a friend who is running the latest version and see what I can do.
– Hub V2
As documented on the FCC site: https://fccid.io/XO9-IHB002
The V2 hub is completely different to the V1. It does have two massive TX/RX pads that could be soldered onto and see what comes up on the console log. And I would assume they are still validating the server certificate to make sure it is correct.
I did manage to download what I think is a V2 firmware a while ago, it’s completely different and doesn’t use the same XOR CRC that the V1 firmware uses so I don’t think the byte patching on the deXORed firmware is going to work. I don’t have one of these and don’t really want to invest in getting one as I assume SureFlap have done things very differently this time around.
– Wemos ESP32 Hub
This was an effort I was working on after I bricked my first hub. I left all the code I wrote, plus the gerber files under my old repo. The code is able to pair with the devices and receive messages, but it wasn’t robust enough as it repeatedly crashed and I didn’t have the time or C / Arduino skills to finish the code as I managed to completely hack the V1 hub so it wasn’t necessary.
There is another repo that Mike built using a Raspberry Pi and a BeeClick that I helped him with the pairing functions and that is purely a read-only function to gather data from the Feeder.
Things that have to be add with the WemosHUB to make it functional in my view:
- Making it robust so it doesn’t periodically crash
- Adding MQTT support to in my view send the exact same messages as the V1 hub sends so that PHL doesn’t need many changes, or you will need to build your own message interpreter based on the documented message types from paired devices.
- Add support for sending messages to the devices. This will require figuring out how the 1 character CRC check digit is calculated at the end of the message. As the Zigbee messages are XORed (which I have figured out) and then a single check digit is added to the message (which I have not). But I do have a Ghidra decompiled version of the firmware so anyone who is capable in reverse engineering could most probably easily figure it out based on the firmware and I have a few pointers on which function to look at.
To me someone who was a competent C / Arduino developer and had done some reverse engineering should be able to knock that out, but that someone isn’t me.
– Pet Hub Local Python Code
This has a few bugs I know and I have parked it for some time. Going to see if I can pick this up and fix the underlying issues, plus enable support for completely offline enrollment without needing to phone home as I think I have everything. The main issue is if if SureFlap have changed their bootloader sufficiently so that flashing older firmware or byte patching the current firmware with a different certificate can’t be done anymore.
3 Likes
Me friend will be lending me his hub today and I will see what has changed. Could be an easy fix or could be terminal. And then depending on how much interest there is working on the WemosHub code or the BeeClick on a Pi would be the only option.
There are various Zigbee devices out there but it is important to understand the radio traffic isn’t Zigbee its a completely custom protocol ontop of 802.15.4 so we would need to build a custom gateway rather than leveraging a Zigbee one.
I had thought building one with a CC2531 would be an option but someone would need to build a custom firmware first before even building the upper layer protocol handler. That was why the MRF24 was great as it handled a lot of the radio handshake and keep alives on chip so then I could focus on the custom sureflap stuff ontop of 802.15.4
1 Like
233.364this is the latest version and I don’t (yet) have a copy of this firmware. I suspect they have changed the bootloader but I can’t be sure. Need to get my hands on a hub and see what it does connected to my isolated network. Again I am worried about either downgrading to2.43or2.201as it could leave folks with a $100 brick that I created. But am going to see if I can borrow a hub from a friend who is running the latest version and see what I can do.
what needs to be done to dump the firmware? (sorry, I am also not up2date :D) I should also be able to solder some wires to some pads if ´something like that is needed 
( Hub H001-0057586, Firmware: 233.364)
Looks like they locked the firmware update process to HTTPS only so my downgrading trick will no longer work.
So the only option will be to build a complete hub replacement.
Well that sucks. 
My suggestion for those who already haven’t had the firmware update. Which I suspect most people will have is to block port 80 outbound from the hub on your firewall if you can. That way the firmware won’t update.
But… This does make me want to look into reviving the WemosHub a lot more… as it’s such a dick move from SureFlap.
What is the easiest way to determine firmware version?
It’s in the json /api/me/start response that surepy downloads.
I’m 99.9% sure they have rolled out firmware updates to the vast majority of hubs.
And because it includes the new passive aggressive boot loader there isn’t the option to downgrade firmware anymore.
Perhaps I will try with a pickit3 which is the hardware required to flash the cpu. But I don’t have one right now.
@peterl if the latest firmware doesn´t allow downgrading the firmware OTA anymore, what about flashing the hub using a usb to serial converter (similar to how ESPHome/Tasmota is flashed), asumming the RX/TX/5V/GND pins are available in the hub that would only require a copy of the old firmware, has this option been explored/considered?
It requires flashing hardware from Microchip called a pickit 3. I borrowed one from a friend but he has moved to another city so if I wanted to go down that path then I would just buy one off AliExpres.
I still think the best use of time would be building a complete replacement to the hub using the ESP32 and the MRF board I already started. That way the nonsense dog chasing the cat the whole time with firmware patching or needing specific flashing techniques goes away. And anyone buying new hardware could just DIY build their own hub for 1/5th the price of the hub and have it work over wifi.
Just need time to work on the code. Or someone else interested in that project.
4 Likes
Wouldn’t it be an option to modify the feeder instead of trying to decode whatever it’s sending to the hub?
That way we can completely customize how the feeder works and will open much more possibilities…
Just thinking out aloud:
- Replace the existing PCB with an arduino MKR Wifi (?) and an rfid shield? and whatever that’s needed to control the motor.
- Maybe even replace the batteries with 16850 li-ion batteries that are rechargable so we don’t have to buy new batteries that often…
The arduino can be put in low-power mode most of the time, so it should last quite some time. And it will be able to send it’s data directly over wifi without the need of a hub.
Doing it this way we will be able to implement every feature we can think of (for example: custom open/close delay time, prevent a cat on a diet to eat too much to quickly, or a timer to allow/disallow the cat to feed at night for example…) directly in the firmware of the feeder.
This might sound like a big task but I honestly think it’s not much more work compared to building a custom hub from scratch… After all, it will just be an arduino reading the sensors and controlling the motor. Shouldn’t be that hard at all…
Can you do this?
I think I can. I haven’t opened the feeder yet to check which load cell, rfid coil etc… are used.
But given the fact that it’s a pretty simple device I think I can do that, yes.
I’m even thinking about doing this but the problem is that I don’t have much spare time to work on an additional project. I was hoping anyone else has more time to work on that and I can just try to help wherever possible/needed.
1 Like