nuki_hub
nuki_hub copied to clipboard
technyon
Intermediate state in HA
Hi, Is there a way to read an intermediate state in HA? For example, I set the query interval to 1s, when I put the lock into Lock n Go I see the state in the Nuki Hub FW changes to unlockedNgo - is this reflected in HA somehow? If yes, how can I build an automation off of this? Which entity do I monitor?
This could work, but has some drawbacks:
- You'll drain the battery very fast. Unless you've connected your lock to a permanent power source, I'd advice against it.
- You block a lot of air time, which could interfere with communication from other devices with the lock.
- It could still miss an intermediate state from time to time. I wouldn't automate anything that depends on this to work all the time.
In MQTT, you'd subscribe to the "lock/state" node.
With lock'n'go specifically, there is still the extant issue that locked > lock'n'go > locked does not send the unlocked state via BLE.
@technyon why do you think there would be such a big power waste? I guess the Lock and ESP are in a connection already so I would assume there is not so much data exchanged between them when the topic updates. I would guess that the locking/unlocking operations eat up much more battery than BLE traffic each second. Perhaps I’m missing something tho 🙃
Anyway, I’m using auto discovery, can I continue doing so and register to the state via the MQTT integration or give up the automatic discovery completely?
Normally the lock would be sleeping most of the time, which is obviously not possible when you query it every second. While each query will only use a small fraction of the power used for a lock operation, you will have > 85.000 of those per day.
If the lock and esp are connected then the lock should be sleeping between the BLE connection events anyway. If I query it every second then at one of those connection events it will also send some data. Doesn’t sound like a huge waste but again maybe I’m missing something.
For every query the ESP has to reconnect to the lock, which in itself takes a moment. During this time the lock has isn't sleeping and has to use power for CPU, bluetooth communication and so on. There's a reason why usually the lock notifies the ESP that the state has changed.
- Why not just stay connected?
- If the lock state changes, will that reflect in the topic immediately?
- Because the lock would need to maintain an active connection, which drains the battery
- The lock signals that the lock state has changed. NUKI Hub then queries the lock state, which can take a moment. It depends on what your defintion of immediately is, but for most use cases it's fast enough. What's problematic is the "unlatched" state, because it's often too short to be notified via MQTT.
- In this case the lock is the advertiser so it needs to send adv packets on all 3 primary adv channels with non-empty payload. When the lock and esp are connected, the payload when idle is an empty packet which is only 10 bytes long and is transmitted only on a single channel.
TLDR, Power profile in Connected state can be better than in adv state.
Only caveat is if the Nuki guys force the locks main cpu (if such exists) to stay awake when the BLE chip is connected which would be very bad practice.
- If my query interval is 100 seconds and state changes , the new state will only reflect after 100 seconds?
I have no insight of how exactly the NUKI firmware works. They have implemented things in a certain way, and the library that NUKI Hub uses works according to their API documentation.
If you set the query interval to that number, it doesn't take 100 seconds to change. When a state change occured, the lock actively signals that the state has changed using BLE beacons. Once the ESP picks up such a beacon it queries the lock for the new state.
Ah I see, I thought the Hub has some proprietary implementation.
I tried setting the query interval back to what it was but for some reason it didn’t update that way, I’ll try again and report back :)
That part about the beacon is actually not in official documentation. Took us a while to figure out.
So I played around a bit with the status entity and what I found is that if I set query interval to default then the status won’t always correctly reflect in the entity I created, especially not for the unlockedNga status. Locked and unlocked does reflect fairly reliably.
Setting the query interval to 2 seconds solves the issue (probably because it forces the esp to go into a connection with the lock and perform a GATT read).
Anyway, IMO, using the adv payload to indicate whether to connect and read the state is not best practice in my opinion.
Staying connected to the lock is probably the way to go. I would guess that the official hub maintains a connection with the lock at all times for both reliability and power consumption.
Hi,
as far as I understand it the Bridge does it the same way. I'd refer you to this thread:
https://developer.nuki.io/t/bluetooth-specification-questions/1109/3
Quoting the important parts:
Normally, the rssi value within the iBeacon data is -60 (0xC4). If the status of the smart lock changes in any way, that would trigger a new entry in the activity log, the rssi value within the iBeacon changes to -59 (0xC5) and that triggers the bridge. Once the bridge has connected to the smart lock and fetched the new status, the rssi value changes back to -60.
The last sentence suggests that the bridge opens a new connection to fetch the new status, just as NUKI Hub does.
Oh, thanks for that :) I guess it’s done to service multiple devices..
In that case the esp should show ulockedNga status even when query interval is long but for some reason it doesn’t … I guess the scan params of the esp are as Nuki suggests ? 40ms window 40ms interval 3s duration..
Closing as this issue has been stale for 9 months.
Intermediate states can since this issue has been raised now be shown in HA, but usually don't unless setting query interval to a very low amount, which is unfeasible for battery usage. This is a limitation of the BLE communication and can't really be solved. On Nuki Locks with MQTT (3.0 pro, 4.0, 4.0 pro) a combination of WiFi/Thread and BLE can probably be used in the near future to alliviate this problem.
