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
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 
@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.