Efforts to build an ESP32 hub

[chrish987]

My plan is to try and build an ESP32 based 'hub' that just sniffs the MiWi traffic - let this run as passive and leave the normal hub and app working as is. That way can drive reliable and customized notifications from the ESP32 messages.

As always efforts raise more questions than answers.

I have an existing hub and a couple of cat flaps, a feeder, and felauqa. The hub is running the old firmware. I worked out the xor key - and was surprised when it was the same as the one in your docs (although i made it slightly longer to cater for the 2 message cat flap messages).

So I am reasonably along with some ESP32 code to sniff and decode the packets. still very much a work in progress but got a good bit of it working. The hub i am (was) using is connected to a pethublocal instance. I am mostly testing with the flap and a collar tag. I see messages from the flap to the hub (message 13), but nothing coming back (I am only looking at the 01 data frames not the 02,08,0A etc). I assumed this is that as the app on the phone is not connected (as hooked up to your pethublocal) so there are no control/config messages to send from hub to flap.

With the above in mind i bought another hub today (I had an old broken flap that I could hook up to it). so now i see lots of back and forth when i generate traffic either using the tag or the app. However on decode I am getting gibberish. I don't know what version of firmware the new hub is running - but assume the latest locked down version.

So first question - do you think the xor key is firmware version specific? seems odd that is was the same as the one you posted before but now it is different. I have a database of all the message logged through all my testing - so given that i know the tag id i could potentially craft what the decoded message should look like - although the timestamp fields etc could be a bit tricky.

Another slightly unrelated question. I have been using the pethublocal for a couple months now but wrote my own notification code in node-red looking at the raw hub messages. For my notification messages I used the frame timestamp from the raw message (not the hub one - the one in the message) - and this has drifted slightly over time. I also changed the batteries in the flap yesterday and now I get an 'undefined' in me notification for the date - which presumably means the message decodes to a junk date. Do you think there are messages from the cloud to sync the time (which your python code is not doing)?

Last question - for now - is this interesting to you to try and build a passive sniffer type device - I am happy to post the code I have so far if it is of interest to anyone here.

Although the whole concept is dead in the water if sureflap can change the xor key with a firmware update.

[plambrechtsen]

Hi, awesome work. One thing I would be interested in is if you unpair the flap or whatever from the "new" hub, and then pair it to the old non-upgraded hub does that work back with pethublocal? As I don't have a hub with the newest firmware and don't want to upgrade my current hub due to being locked out.

So, I don't think the XOR key is firmware specific prior to the new build, but that being said I can pair up a device to the 2.201 on a test hub I have and trace out the traffic. The 3rd byte in the frame should be one of three values being 2d or 3c if it's a 126/132 message and 2a if it's a 127 command frame. It seems like the XOR Key seems to be rolling as per what I have seen from another person who emailed me some traces, but I haven't seen enough traces but I have seen that the 3rd byte seems to roll every 5-10 minutes to something new so that doesn't bode well.

But what is really worth checking out is if you can pair a new door / feeder that was paired to an upgraded hub back to an old firmware hub then we have a work-around.

The time is set by the hub depending on the device type. https://github.com/PetHubLocal/pethublocal/blob/main/pethublocal/generate.py#L135 (Pet Door) https://github.com/PetHubLocal/pethublocal/blob/main/pethublocal/generate.py#L150-L152 and https://github.com/PetHubLocal/pethublocal/blob/main/pethublocal/generate.py#L304 (All other devices) https://github.com/PetHubLocal/pethublocal/blob/main/pethublocal/generate.py#L446-L449

So when pet hub local starts it should send a frame to the device to set the current time.

[chrish987]

Unpairing the flap from the cloud connected hub and repairing to the pethub local one works ok. I can decrypt the data using the original XOR key.

There are a LOT of MiWi message back and forth for the pairing operation. I am guessing it will be next to impossible to rebuild all the hub functionality into another platform. Thoughts? - you obviously have spent a lot more time deciphering all this than me.

Given we know Sureflap CAN change the XOR key I guess they could if we leave the hub connected to the cloud.

In theory we can work out the new XOR key given we know what (most of) a decoded frame should look like. The bits that are not constants like the timestamp maybe we don't really need for a notification engine anyway.

Keen to get you thoughts on the 'sniffer' idea and if it is valuable and might work. I am thinking it could be pretty fragile if sureflap decide to regularly change the XOR key (which I guess they could push from the cloud as often as they like.

My thoughts for the sniffer was to learn devices and tags from the MiWi packets, save them in the ESP32 and give a simple web interface to manage config - device names, pet names, bowl configs, etc. Then send notifications using this data.

[plambrechtsen]

You know I already have started some build of the ESP32 code here: https://github.com/plambrechtsen/pethublocal/tree/main/WemosPetHub

Then I used the CC2531 Zigbee sniffer kit off Ali: https://www.aliexpress.com/item/1005001973568180.html

And the code to take the output and create a wireshark PCAP and then using tshark to convert it to a CSV. https://github.com/plambrechtsen/pethublocal/tree/main/zigsniff

So capturing and comparing the radio frames is pretty easy. Glad to know that you can pair the devices back to an old firmware hub.

[mickae1]

any news? I'm interested in the project

[JenCrawford]

I'm also interested in this projects - any updates?

[nickjvturner]

I was too late to the party, I started looking into adopting pethublocal, but, my hub is running 'firmware': '233.364' Is there any hope to building our own hub to interact with the pet door?