State 5 / bridge API

Discussion
,
1

Hi

I have seen today the second time that state 5 in the /list response when querying the bridge
I am currently not at home, so I can’t check the status, but I assume the door is closed and latched - so normally the state should be 3. This was at least the case last time when I had seen the state 5 and checked the door.
Any reason why it shows 5?
I haven’t seen that in the months before, so could it be related to a recent FW update?

[{“deviceType”: 0, “nukiId”:xxxxx, “name”: “np5ht”, “firmwareVersion”: “2.5.1”, “lastKnownState”: {“mode”: 2, “state”: 5, “stateName”: “unlatched”, “batteryCritical”: false, “timestamp”: “2019-06-12T14:10:30+00:00”}}]

2

Thanks for the feedback!
I assume the timestamp looks correct to you? (Timestamp should be from the last state-update pushed to the bridge.)
This could either be some strange bug with a wrong state shown or there has been an unlatch at that time and the next state-change (back to unlocked/locked would be expected) has not been pushed correctly.

If you ever notice this again it would be nice if you could immediatly try out a /lockState command to see if the Smart Lock shows the same state or if the values differs from the one cached at the bridge.

I will also try to reproduce it here with my setup.

3

http://192.168.178.44:8080/lockState?nukiId=xxxxxxx&token=yyyyyy returns:
HTTP 404 Not Found

List returns (door locked):
[{“deviceType”: 0, “nukiId”: xxxxxxx, “name”: “np5ht”, “firmwareVersion”: “2.5.1”, “lastKnownState”: {“mode”: 2, “state”: 3, “stateName”: “unlocked”, “batteryCritical”: false, “timestamp”: “2019-06-13T17:30:06+00:00”}}]
Timestamp is not correct either, even assuming that is seems to be 2 hours behind CEDT currently.
Callback isn’t issued either to my homematic, so state in homematic is wrong.

The app on my iphone (latest beta) shows no connection between Server-Bridge-Nuki. Connection between iphone and Server is green.

Once I used the app and issue /list, then the result is correct
[{“deviceType”: 0, “nukiId”: xxxxxxx, “name”: “np5ht”, “firmwareVersion”: “2.5.1”, “lastKnownState”: {“mode”: 2, “state”: 1, “stateName”: “locked”, “batteryCritical”: false, “timestamp”: “2019-06-13T20:13:43+00:00”}}]
(timestamp is 2 hours after CEDT, but it shows the time when I used the app, not the time when I closed the lock)
/lockState still doesn’t work.
Callback to homematic is issued, so state in homematic is correct.
The app on my iphone (latest beta) shows still no connection between Server-Bridge-Nuki.

/info displays
{“bridgeType”: 1, “ids”: {“hardwareId”: xxxxxxx, “serverId”: xxxxxxxx}, “versions”: {“firmwareVersion”: “1.12.6”, “wifiFirmwareVersion”: “1.2.0”}, “uptime”: 1080480, “currentTime”: “2019-06-13T20:21:56+00:00”, “serverConnected”: true, “scanResults”: [{“deviceType”: 0, “nukiId”: xxxxxxxx, “name”: “xxxxxxxx”, “rssi”: -56, “paired”: true}]}

Currently I have 2.52 SL waiting, but no time to install tonight. Should that solve the problem?

4

This would be the error for a wrong nukiId (would be 503 if the Smart Lock is not reachable). Be sure to use the correct dec-format (as shown over the /list command

Timestamps are in UTC.
They are set by the bridge at the moment when it receives the state from the Smart Lock. So if you have a later timestamp it seems it could not connect earlier; but it still should show the current state at that time.

There is still a bug with this screen which will be fixed in the next Beta.

There is a small BLE disconnect bug which may fix some things for you.

We also got a new Bridge FW Beta upcoming with some fixes.

But we couldn’t reproduce your state 5 case yet, as our test devices only wrote log entries after complete cycles (even if we stopped it midway), so state 5 should not show up in normal situations anyway.

5

Hi

I 'll check again tonight if my nukiID is wrong - could be since I stored the call some time ago and exchanged the SL afterwards.

But two things are strange, as I described already:
The values returned with after /list command are wrong (not showing actual status) until I use the app. Then the /list command sends the correct value.

The callback is also not sending data - callback is only issued that after I connected with the app to the SL. I haven’t seen that before.

Not sure if the issue is in the SL or the bridge.