Pet Door curfew no longer reporting lock status

[rjclocks]

I have a Pet Door and the curfew status has stopped reporting locked/unlocked correctly. It was working until fairly recently thorough my integration but now always reports as unlocked, even though the Pet Door is physically locked by the curfew.

When I print the rawdata() from the device object (shown below) I can see that it is correctly reporting the curfew lock/unlock times. But despite running this after the curfew time (22:01) when the device should report as 'locked', it still is not doing so.

If I query the device.state, I get a response of <LockState.CURFEW: 4> rather than the locked/unlocked enumerations for the curfew values (which should be negative)

Logging into the surepetcare.io web page with the same user shows the device as locked with curfew.

Does anyone know what might be occuring?

{'control': {'curfew': {'enabled': True,
                        'lock_time': '21:49',
                        'unlock_time': '06:00'},
             'fast_polling': True},
 'created_at': '2019-01-09T20:21:37+00:00',
 'index': 1,
 'move': {'duration': 3174,
          'entry_device_id': 223590,
          'exit_device_id': 223590,
          'from': '2023-11-28T16:37:03+00:00',
          'to': '2023-11-28T17:29:57+00:00'},
 'name': 'Kitchen',
 'pairing_at': '2019-01-09T20:21:37+00:00',
 'parent': {'created_at': '2018-04-06T12:53:59+00:00',
            'updated_at': '2023-11-28T22:01:23+00:00',
            'version': 'ODA5MTA='},
 'parent_device_id': 81384,
 'product_id': 3,
 'status': {'battery': 6.3374999999999995,
            'learn_mode': False,
            'locking': {'curfew': {'delay_time': 0,
                                   'lock_time': '21:49',
                                   'locked': False,
                                   'permission': 2,
                                   'unlock_time': '06:00'},
                        'mode': 4},
            'online': True,
            'signal': {'device_rssi': -47.8, 'hub_rssi': -50},
            'version': {'lcd': {'firmware': 1, 'hardware': 1},
                        'rf': {'firmware': 0.16, 'hardware': 4}}},
 'updated_at': '2023-11-28T22:01:20+00:00',
 'version': 'Mzk1MTQ='}

[rjclocks]

Looking at the data used by the surepetcare.io page (developer tools /network in web browser), the device information appears to be consistent with the data from SurePy.

It appears that they may no longer using status values to report the lock status under curfew. They may be using time comparisons to determine what is happening, which is a bit annoying.

I will have a mess around with a few more locking modes tomorrow and update here with my findings.

            "control": {
                "curfew": {
                    "enabled": true,
                    "lock_time": "21:49",
                    "unlock_time": "06:00"
                },
                "fast_polling": true
            },
            "status": {
                "battery": 6.337,
                "learn_mode": false,
                "locking": {
                    "mode": 4,
                    "curfew": {
                        "delay_time": 0,
                        "permission": 2,
                        "unlock_time": "06:00",
                        "lock_time": "21:49"
                    }
                },
                "signal": {
                    "device_rssi": -47,
                    "hub_rssi": -50
                },
                "version": {
                    "lcd": {
                        "hardware": "1.0",
                        "firmware": "1.0"
                    },
                    "rf": {
                        "hardware": "4.0",
                        "firmware": "0.16"
                    },
                    "device": {
                        "hardware": "1.2",
                        "firmware": "1.0"
                    }
                },
                "online": true
            },

[rjclocks]

The pet door is definitely reporting it's state correctly using the status.locking.mode values (based on the expected device enumerations) but the curfew logic seems to have changed so that it is always reporting as mode=4 regardless of the state of the exit lock.

[rjclocks]

I fixed this in my own downstream code. WIll close it here.