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

I suspect @eviltom is correct and your firmware will be updated to 2.201 and not 2.43.
If you check your pethubconfig.json under the hub serial you will have the firmware version in there.

    "Devices": {
        "H0xx-0xxxxxx": {
            "Hub": {
...
                "Device": {
                    "Hardware": "3",
                    "Firmware": "2.43"
                },

If your Firmware above is 2.201 then you will need to flash on the older firmware to make it work.

This is an area I need to document further but if you check the pethublocal.log it should show you that your firmware is the older version and the 2.43 firmware has been built for you.

In the share/pethublocal share you will see there are two groups of firmware images:

H0xx-0xxxxxx-2.43-nn.bin

and

H0xx-0xxxxxx-1.177-nn.bin

The 2.43 one is the custom firmware built to your Hub, and 1.177 is what was downloaded from SurePet and then the XOR key found.

So…

If you boot the hub while holding down the reset button underneath then the hub will downgrade to 2.43 and be able to run locally.

Then if you decide you don’t want PetHubLocal anymore you can move the H0xx-0xxxxxx-2.43-nn.bin files somewhere else and leave just the H0xx-0xxxxxx-1.177-nn.bin files in place, repeat the process again and it will flash back on the original firmware back to 2.201

It’s REALLY important you don’t interrupt the firmware process as I don’t want you to brick your hub, and with everything you are taking this risk on yourself if things go wrong… which I have tried as hard as I can to avoid anything going wrong.

But I think that is what you will need to do.

Re batteries: I almost completely ignore the battery reporting.

I have three feeders (2 dumb, 1 smart) and a smart cat flap. One of the dumb feeders started flashing a battery warning at me so I bought some new ones ready but didn’t change them as I figured I’d get every last drop out of the old ones. That was in January and they’re still working, maybe a little slower to open, but still working.

One of the dumb feeders was ‘faulty/parts’ from eBay because it eats through batteries. I opened it up, added a AliExpress 5v to 6v buck converter and a cable with a USB plug on the end and the feeder is happy. It did also work on 5v usb direct but gave the battery warning constantly.
I’m planning on doing it with all the others as well. Not as clean a look with the cable but I can live with that as all the devices are tucked away.

Updated documentation to detail the Firmware upgrade process a bit more.

Nope. It was DNS + restart. Works fine now!

We actually had the battery scenario almost happen to us. IIRC, one of the doors gave up on the day we were leaving - without any battery alert. Not good!

1 Like

Oh, how can I manually change the state of a pet?

edit: Also I’m seeing this in the addon logs

1655147386: Saving in-memory database to data/mosquitto.db.
1655147386: Error saving in-memory database, unable to open data/mosquitto.db.new for writing.
1655147386: Error: No such file or directory.
1655149187: Saving in-memory database to data/mosquitto.db.
1655149187: Error saving in-memory database, unable to open data/mosquitto.db.new for writing.
1655149187: Error: No such file or directory.
1655150988: Saving in-memory database to data/mosquitto.db.

Changing the state of the pet ie if they are inside or outside? That is the sort of thing I am planning to add to the console on port 80. Home assistant didn’t have an easy way to change those values via the UI unless I changed the sensor type to a switch.
Unless you can think of an object type in HA which would make more sense.
And I noticed the db save issue. Will try and sort it today if time permits.

The ‘native’ SurePet integration has a service that’s called to set the pet’s state manually.

It looks they use binary_sensor, if that matters…

A service call would be fine, but is there a reason a cat’s in/out state can’t just be changed to a switch?

Not at all. Easy enough to do and I remember in my first code base I did have something similar. I’ll just need to handle the change between the two and have it as a config option in the json file.

1 Like

I’m guessing the native integration did it because it had to update SurePet as well. So yeah, a simple switch makes way more sense.

I started looking into turning the Pet State into a switch rather than sensor this and thought it was going to be a super simple update, And right before I pushed the change I realised I need to update the pethubconfig.json with the new state. This is going to need to wait until the weekend when I have some more time.

1 Like

Thanks for the update, but no need to rush (on my account anyway). It’s great that you’re able to do this at all. Thanks for all your work so far.

1 Like

I agree with all this. Thank you!

1 Like

Currently preparing for my Kawaiicon Talk in a few weeks so focused on making sure that all goes smoothly. Which was what kicked me off a few months ago to finish my v2 code.

Wow! Nice work dude!

Mostly finished off the device documentation, detailing all the different messages sent by different devices and how to understand the stream of hex.

Can I just say that their firmware naming scheme is highly annoying. 2.201 is newer than 2.43. pseudo-raaaaaage

Any more thoughts on this? :smiley:

Good luck with your talk on Friday! I’m sure you’ll ace it!

2 Likes

Thanks @Deez … Have thought about the @flyize and was working on bug fixes to my code for the talk on Friday more so than refactoring how the sensor / switch gets created.
Will get onto it in a week or so once everything calms down.

Patches / PR also welcome :slight_smile:

2 Likes