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!
@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.
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.
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.
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.
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.
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.
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.
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.
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.
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 …
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: