Local Deployment for SureFlap / SurePetCare Connect using only local MQTT Broker

Thank you @D0doooh and @flyize! I just tried this, and while I have the DNS server running now on my Pi, I had to learn the hard way that my ISPs router has a hardcoded DNS server built-in. I am afraid I either need to keep things as they are (and simply keep the flap “unblocked” all of the time, something I can live with a bit of sadness), or I invest into a router myself. Need to think about it.

Still, THANK YOU for your fast and competent replies!

1 Like

@tombaloo You will need to disable DHCP off the ISP router and have the PiHole supply DHCP and DNS for your whole home network and have the Pi supply the default route of the ISP router. As most ISP routers won’t allow you to set an alternative DNS Server on your internal network via DHCP which is what you need.
Otherwise a Mikroik hAP mini Router would work fine as they are small and cheap if you are up for configuring it, which is pretty easy in my view.

2 Likes

And if you have modem/router combo, your only option will be to turn off DHCP and turn it on for PiHole. BTW, if you do this, I would suggest getting an actual Pi to also run DNS/DHCP. That way, if your HA server goes down, you’ll still have something handling DNS/DHCP.

If you do this, make sure the DHCP servers hand out different IP blocks.

Hi, I am a little lost. What is the best current way to apply this?

Currently, the “ears” are red and nothing is connected in the app…

So what is the best way to proceed?

I have installed the HA Addon, this shows me the flap and the hub, but both as offline, because I did not know which firmware has the hub so I have installed the Docker container on my Mac, and there looked up this should be in my opinion 2.43.

but nothing happens in the HA addon, neither the “ears” turn green. Neither do I see it as online in the web GUI.

thanks for the great project and the possibility to avoid this stupid cloud.

Might want to follow this issue:

A solid red light means it is trying to download firmware because you held the button underneath the hub when powering it on. I really hope you don’t have a new version of the Hub iHB v2 as that is a completely new hub that is on the FCC site and completely different hardware from the current hub. I was working on updating the documentation on it yesterday and included links to the FCC site:

It’s really unlikely but who knows…

Have you checked the pethubconfig.json file exists @D0doooh and has your Hub and all your devices, or check the start-xxx.json for your hub as that has your hub version in there.

Then make sure your DNS is setup to point hub.api.surehub.io to the host running PetHubLocal.

Lastly try doing a curl -k http://hub.api.surehub.io/api/firmware and see if you are seeing anything in the PetHubLocal logs.

Interesting.
Just had a quick look at the NRF24 series of chips as used in the V1 hubs and they’re not recommended for new designs and show signs of being EOL in the not too distant future. I imagine they’re not going to be high priority for a silicon fab to make either at the moment.
Probably the chip shortage has triggered a redesign

Looks like they’ve lowered the BOM size a fair bit as well, and managed to get rid of the through hole LEDs in favour of SMD parts.

TX/RX still available and labeled though, so hopefully that shows the motivation for the redesign isn’t security. :man_shrugging:

There’s a few places locally that sell the Sure stuff so I’ll have to keep an eye out for a version 2. That’s if it’s possible to tell from the outer box.

1 Like

I think I still have an old hub, I have it already over 3+ years

Maybe this is my Problem:

INFO:pethublocal:HTTP: Firmware hub request serial_number=H006-XXXXXXX&page=0&bootloader_version=1.177
ERROR:aiohttp.server:Error handling request
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 435, in _handle_request
    resp = await request_handler(request)
  File "/usr/lib/python3.10/site-packages/aiohttp/web_app.py", line 504, in _handle
    resp = await handler(request)
  File "/usr/lib/python3.10/site-packages/pethublocal/frontend.py", line 143, in firmware
    customfirmware = f'{serial_number}-{FIRMWAREVERSION}-{page.zfill(2)}.bin'
NameError: name 'FIRMWAREVERSION' is not defined
INFO:aiohttp.access:XX.XX.XX.XX "POST /api/firmware HTTP/1.1" 500 245 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"

I have now tried this again with the Home Assistant addon.

I have set DNS to the HA instance, but the curl command returns a 404 error, also visible in the addon log.

Thank you, will give that a try. Just finished my “dead man switch”, so I can now focus on this :slight_smile:

Found the issue @D0doooh FIRMWAREVERSION wasn’t being imported from consts in frontend
Pushed a change and that should fix it.

1 Like

yep, that worked now @peterl the firmware was downloaded from the hub and the permanent red glow is gone:

libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"
INFO:pethublocal:HTTP: Firmware hub request serial_number=H006-XXXXXX&page=75&bootloader_version=1.177
INFO:pethublocal:HTTP: Firmware image file H006-XXXXXX-1.177-75.bin
INFO:aiohttp.access:XX.XX.XX.XX "POST /api/firmware HTTP/1.1" 200 726 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"
INFO:pethublocal:HTTP: Firmware hub request serial_number=H006-XXXXXX&page=76&bootloader_version=1.177
INFO:pethublocal:HTTP: Firmware image file H006-XXXXXX-1.177-76.bin
INFO:aiohttp.access:XX.XX.XX.XX "POST /api/firmware HTTP/1.1" 200 224 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"
INFO:aiohttp.access:XX.XX.XX.YY "GET / HTTP/1.1" 302 188 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0"
INFO:aiohttp.access:XX.XX.XX.YY "GET /pethubconfig HTTP/1.1" 200 6260 "http://XX.XX.XX.ZZ/index.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox

Now the ears are flashing red though, and in the web gui everything is also still seen as offline.
according to the documentation, that would be everything, or have I missed something?

Can you do a curl -k https://hub.api.surehub.io/api/credentials and do you get anything in the logs? As I think you have something else listening on port 443 that is stopping this working.

Log Output:

INFO:aiohttp.access:XX.XX.XX.XX "GET /api/credentials HTTP/1.1" 405 204 "-" "curl/7.79.1"

And in the console I get: 405: Method Not Allowed%

in my opinion nothing else runs on my HA with port 443.

But the hub isn’t sending a request… It must be a networking issue causing this.

But an update on this, a friend of mine has just helped with the decompiled firmware how to calculate the CRC on the firmware. So I am now trying doing a byte patch on the firmware, so if this works all you should need to do is create a 19 character DNS entry as a exact replacement of hub.api.surehub.io and you won’t need that as a poisoned DNS entry.

hub.api.surehub.io
petshublocal.local
pethubslocal.local
pethublocal.hacked

:thinking:

2 Likes

Holy crap.

Awesome work you have done here.

I am looking for a smart cat flap to integrate with Home Assistant since I want to do highly dynamic things like keep the cat inside until kids are asleep. Also, I hate the cloud for automations.

After reading/skimming the entire thread I still have several questions.

  1. As I am still looking: are there any alternatives to the Sureflap Connect at all? I would prefer to support a company that is local-friendly by design, not by accident.
  2. Are there any current efforts to talk directly to the devices? That method seems more future-proof since a new hub bootloader could kill Pet Hub Local for upcoming hardware revisions.
  3. The “Hub Certificate” documentation mentions “If you have a H010 revision hub or have already upgraded the firmware then you need to get a soldering iron out to get the password.” – I understand that this is no longer true, all revisions can be downgraded without soldering now?

What I really want is a non-obfuscated Zigbee cat flap that could just be used with deCONZ but it seems like I will get the Connect with a hub and use this great project.

That is completely normal nowadays. It is not a decimal point but a dot separating two integers. Often version numbers even have three integers which makes it more clear.

I still think the same as @flyize mentioned above … might be the issue with the HA app as I’ve noticed the same behavior which I could only solve by running PHL with a manual install on an other VM.

With the HA app my ears did the same … always flashing red. The GitHub issue was already mentioned by @flyize

We just need to figure out why PHL or something in the HomeAssistant closes the TCP connection as soon as the Hub sends the TLSv1.2 “Client Hello”. It’s not in the PHL code itself, as the manually installed version just works great. Maybe something in the Docker environment the PHL is running in HomeAssistant …

Not that I’m aware of. I did not find such a thing, not 2020 when I was equipping the cat door and not nowadays.

I’d like the same … or a WiFi cat flap. But I guess no company is interested as you don’t have the customer base for that.

How much of our kind of IT guys, who can connect a flap to HomeAssistant, work with MQTT brokers, spinning up VM’s etc. are on this planet compared to all the cat owners who wants to control their flap(s) from whereever. All the remaining masses need a cloud for that.

And yes: It’ll be just great to have the choice between local control and the cloud.This was missed by Sure Petcare.

In case they would publish an API they would not loose any money. People will buy their flap with a hub, and they will save cloud resources as well.

But … bad thinking … what if they sell some data (cats behavior) to someone … you can do nice cat profiles if you have flaps, feeder, poseidon … :thinking:

1 Like

So patching the firmware works for me™. It’s been a hectic week work wise so I haven’t touched anything until tonight.
This will patch the firmware that is sitting in pethublocal/firmware and you will see there are two new files created, then the Firmware-2.43 needs to be XORed with your hub key, and then it works.
** THE DNS NAME CAN ONLY BE 18 BYTES LIKE THE CURRENT LENTH ** so don’t go changing the length of the DNS records otherwise things WILL break. 18 characters is the length.

Just made some further changes to this and have created my own CA Cert, and byte patched the 2.201 firmware with the certificate and the new hostname pethubslocal.local XORed it to my hub, generated a new server certificate for the hostname:

2022-08-06 22:10:03,939 : [ INFO] : Hub Request serial_number=H0xx-0xxxxxx&mac_address=0000xxxxxxxxxxxx&product_id=1&firmware_version=2.201
2022-08-06 22:10:03,939 : [ INFO] : Hub Credentials Response v02:xxxxxx:H0xx-0xxxxxx:::1:pethub/hub/H0xx-0xxxxxx:pethubslocal.local:MIIK....
2022-08-06 22:10:03,941 : [ INFO] : 192.168.0.125 "POST /api/credentials HTTP/1.1" 200 3712 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"
2022-08-06 22:10:25,751 : [ INFO] : HUB: Inbound Message Topic: "pethub/hub/H0xx-0xxxxxx/messages" Message: "62ee3e12 0000 Hub online at 6 10 10 26"

So that’s kinda cool.