New Sure Petcare Binding for Cat/Pet Flap

I’ve taken the most recent changes from your repo, addressed the remaining code review issues and migrated it to OH3. I couldn’t rebase onto the latest 2.5.x branch and therefore create a completely new PR off the OH3 main branch ([surepetcare] Sure Petcare Binding by renescherer · Pull Request #9713 · openhab/openhab-addons · GitHub).

If anyone wants to help testing, here is a built version for OH3: https://drive.google.com/file/d/1TihgIxLw4_HPxVGHOjY4NjmjbTVTtrEE/view?usp=sharing

3 Likes

Great,

Yeah i’ve seen some topics where is was mentioned that we cant kept the commit history… But the most important thing is, that we get all the functions and a working binding, which hopefully get merged soon :slight_smile:

I’ve downloaded the jar and will definetly test this the next couple days.

Thanks for your work Rene

Hello Rene!
I did fresh install of OH3 and manual install of the binding.
I believe that the error still persists…

2021-01-08 11:58:30.140 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:hubDevice:sure_flap_bridge:sure_flap_hub' changed from ONLINE to UNINITIALIZED

2021-01-08 11:58:30.183 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:hubDevice:sure_flap_bridge:sure_flap_hub' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)

2021-01-08 11:58:30.186 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:bridge:sure_flap_bridge' changed from ONLINE to UNINITIALIZED

2021-01-08 11:58:30.254 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:bridge:sure_flap_bridge' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)

==> /var/log/openhab/openhab.log <==

2021-01-08 11:58:31.071 [DEBUG] [e.internal.SurePetcareHandlerFactory] - createHandler - create handler for org.openhab.core.thing.internal.BridgeImpl@21f54cd8

2021-01-08 11:58:31.101 [DEBUG] [iscovery.SurePetcareDiscoveryService] - Starting Sure Petcare household discovery

2021-01-08 11:58:31.104 [DEBUG] [iscovery.SurePetcareDiscoveryService] - Scheduled topology-changed job every 12 hours

2021-01-08 11:58:31.158 [DEBUG] [nal.handler.SurePetcareBridgeHandler] - Initializing Sure Petcare bridge handler.

2021-01-08 11:58:31.164 [DEBUG] [nal.handler.SurePetcareBridgeHandler] - Login to SurePetcare API with username: 

2021-01-08 11:58:31.164 [DEBUG] [e.internal.SurePetcareHandlerFactory] - createHandler - create handler for org.openhab.core.thing.internal.ThingImpl@f9b8649b

2021-01-08 11:58:31.176 [DEBUG] [etcare.internal.SurePetcareAPIHelper] - current MAC address: b827ebd5cb6e, device id: 1809267645

2021-01-08 11:58:31.179 [DEBUG] [nal.handler.SurePetcareDeviceHandler] - Created device handler for type surepetcare:hubDevice

2021-01-08 11:58:31.382 [DEBUG] [etcare.internal.SurePetcareAPIHelper] - Login successful, token: 

2021-01-08 11:58:31.386 [DEBUG] [nal.handler.SurePetcareBridgeHandler] - Login successful, updating topology cache

==> /var/log/openhab/events.log <==


2021-01-08 11:58:31.120 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:bridge:sure_flap_bridge' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING

2021-01-08 11:58:31.166 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:bridge:sure_flap_bridge' changed from INITIALIZING to UNKNOWN

2021-01-08 11:58:31.202 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:hubDevice:sure_flap_bridge:sure_flap_hub' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING

2021-01-08 11:58:31.235 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:hubDevice:sure_flap_bridge:sure_flap_hub' changed from INITIALIZING to ONLINE

==> /var/log/openhab/openhab.log <==

2021-01-08 11:58:32.364 [DEBUG] [etcare.internal.SurePetcareAPIHelper] - API execution successful, response: 

2021-01-08 11:58:32.381 [WARN ] [etcare.internal.SurePetcareAPIHelper] - Exception caught during topology cache update: java.lang.NumberFormatException: Character N is neither a decimal digit number, decimal point, nor "e" notation exponential mark.

2021-01-08 11:58:32.383 [DEBUG] [nal.handler.SurePetcareBridgeHandler] - Cache update successful, setting bridge status to ONLINE

2021-01-08 11:58:32.387 [DEBUG] [nal.handler.SurePetcareBridgeHandler] - Updating 1 connected things

2021-01-08 11:58:32.389 [DEBUG] [nal.handler.SurePetcareBridgeHandler] - Bridge topology polling job every 36000 seconds

2021-01-08 11:58:32.392 [DEBUG] [nal.handler.SurePetcareBridgeHandler] - Pet status polling job every 300 seconds

==> /var/log/openhab/events.log <==

2021-01-08 11:58:32.387 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'surepetcare:bridge:sure_flap_bridge' changed from UNKNOWN to ONLINE

Hi

I had another look at the JSON output you posted earlier and I can see:

"name":"Kepek","gender":1,"weight":"NaN"

My guess is that the “NaN” can’t be deserialized correctly. Can you try giving Kepek a correct weight through the app and try again?

Thanks,
Rene

1 Like

Yes!! :smiley:That was it! :partying_face:
THANK YOU very much Rene!

I have seen this thread about the API binding and the brilliant work @scherer has done.
Is anyone interested in building a local surepet instance and reverse engineering the MQTT protocol used by the hub as it connects to AWS IOT MQTT endpoint?
My intention is to have an agent that listens to the mqtt topic and then publishes to another topic so I can integrate it into Home Assistant as a dynamic mqtt client, I assume there would be similar integration possibilities with OpenHAB??
Feel free to private message me if anyone is interested in this project.

@scherer thanks for creating this binding! I got my cat door today and just tried the draft 3.0 binding you shared here.
Some questions:

  • Do you intend to support actions, I’m especially interested to modify the lock status through OpenHAB based on sunset/sunrise.
  • The lock status shows as “Unlocked” even though Curfew is enabled. I think it should show “in only” during Curfew.
  • A “look through” event would be nice, i.e. to show when was the last time a cat peeked through a cat flap

Happy to assist with beta testing or other help, let me know.

How do you envision this? Mimic a 2nd hub that can peek into events from the original one? Or write a “man in the middle” proxy that spies on the traffic between the hub and the cloud? I read that currently the SSL certs are not validated by the hub so this could be done but might be hard to come up with an easy to setup configuration for this.
I’m interested too to make this a local only thing to not rely on the cloud.

I have created a docker compose that spins up a web server and mqtt mosquito server instance on TLS to simulate the hub and aws iot endpoints with self signed certs. The web server downloads the credentials from the hub . api . surehub . io and saves them locally as you need a set of valid credentials for the hub to then connect to the MQTT endpoint as then the mosquito server also listens on a TLS endpoint to simulate aws iot for the hub to connect to. Then you need to update your local DNS with static entries for the two domains the hub queries to point to your local instance IPs rather than the ones on the internet. Fairly easy to do with many routers to have a static DNS entry, but not on very low end ISP supplied ones.
So far I have the majority of messages for pets coming in and out decoded and last night decoded the feeder messages. It is currently pointing to home assistant putting messages on a mqtt topic for HA to pick up, but equally it could send messages to openhab.
Looking for some folks who may be able to assist further ideally with MIPS PIC32MX6xx disassembly to have a look through the firmware and able to sniff zigbee traffic as there might be the possibility to have the devices connect to a local zigbee gateway as it seems Miwi is fairly close to zigbee.

2 Likes

Hey folks,

I just wanted to let you know that our SurePetcare Binding has been merged to the official openhab addons.

It is available through the snapshot releases starting with build #2229

Thanks to all people who helped to get this merged… and mostly to Rene @scherer who took most of the coding work.

Have fun with this binding… and please let us know if you have any issues with the binding.

/Holger

3 Likes

Thank you Holger! I know from experience that the development of a binding takes a lot of time and dedication, very happy with the binding to be able to monitor our cats in OpenHAB!
One thing I like is the ability to see the battery voltage. We use rechargeble batteries and due to the lower voltage the official app starts complaining way too soon about low batteries. I learned that a voltage of 4.6V means the flap is no longer working so now can create a custom OpenHab notification when the voltage reaches 4.7V :slight_smile:

Hi @jwveldhuis . I finally managed to get the 2 approvals for the first version of the binding to be merged. Now I’m happy to extend it. Actions should be easy to add and I’ll have a look at the lock status and look through.

2 Likes

Hi @plambrechtsen . Do I understand you correctly. The app connects to the API, then downloads some MQTT connection information and credentials and then connects to the MQTT broker? I would be interested to have a look at your reverse-engineered messages to see if we can get a better user experience listening to MQTT messages, rather than polling the REST API.

1 Like

Hello Peter,

may I ask you to give a little bit more detailed description of the things you described here, because I use also some SureFlap API calls, but they are slowly. In my solution based on the description of GitHub - alextoft/sureflap: Basic PHP Examples for SureFlap API (IoT cat flap) the API calls take between 5 to 45 sec. And if I got it right than is your solution much faster. I do need a fast response of the SureFlap status change of a cat who comes or goes through a SureFlap catalpa and I understood you that you do have for this a solution.

THX

Klaus

I’ve made pretty good progress so far and am integrating it into home assistant via MQTT discovery topics so it should be very easy to plug into openhab.
It’s a docker compose that spins up a web server, local MQTT TLS endpoint, logging and pethub which does the translation into human readable topics than the binary string you get from the hub and if you redirect the dns domain the hub uses to make the connection to the cloud.
So if you weren’t sure this runs the whole cloud backend within your local network after you make a single change on your local dns to point the first call the hub makes to a local web server instead of the cloud service. And then the rest is local traffic and the cloud service and surepet app and api are no longer used.

2 Likes

Doesn’t seem to be much interest here but I figured out one of the last puzzles yesterday so if you wanted to fully MITM the traffic back to the cloud service and you don’t mind soldering a TTL console cable onto the hub PCB I have written a script to take the console output created during a firmware update and find the password for the certificate the hub uses to talk to the cloud service.

1 Like

@scherer Is there still a version for OH 2.5 available?
The links are all going to a 404 site :frowning:

Hi Simon,

In case you or anyone else is getting this updateThingCurfews error. I’m using version 3.1.0 of the binding. I had this exception, we have a feeder and cat-flap on the system. I’ll see if I can find the json for @scherer. To fix it I found on the cat flap if you create a Curfew and then disable it the error goes away. I’m just guessing the response changed from null to an array showing disabled curfews looking at the debug, as its reading the one I entered, but as false. Now the binding boot’s up successfully. If I can find the old json output in the log’s, I’ll post the delta’s around anything mentioning curfews.

Hopefully this helps anyone else with this same exception.

P.S Thank you @kaufsim for the binding :+1:

@scherer I found an old copy of the logs. After the Curfew setting is touched, it outputs like this for the object representing the cat flap:

“control”: {
“curfew”: [],
“locking”: 3,
“fast_polling”: false
},

Before the user has touched the setting it is excluded completely from the API response:

“control”: {
“locking”: 3,
“fast_polling”: false
},

This is what was causing the Curfew update issue I guess.

Ran into a recent issue when upgrading to OH4 with this binding not being able to login to cloud service. Not sure if anyone else is seeing issues. Think I have figured it out but need a maintainer’s help to correct it.

https://community.openhab.org/t/sure-petcare-binding-login-failure-due-to-rejected-http-user-agent/146992