search

technyon / nuki_hub

Use an ESP32 as a Hub between a NUKI Lock and your smarthome.
MIT License
518 stars 40 forks source link

delay, missing states, button press info #361

Closed ManniTom closed 4 months ago

ManniTom commented 5 months ago

I connected the nuki hub to my home assistant, and the basic functionality is working. now i have a couple of questions:

1) Time from a HA command (e.g. unlock the door) until unlocking starts: about 1.0 sec. That's fast enough.

Time from a lock action until MQTT sees the new Status: 3.5 sec. That's too long for my usecase. i want to unarm my alarm system as soon as the lock gets unlocked. And when i open the door the alarm system must have been unarmed, else it will fire an alarm...

is there any chance to get quicker status updates from the lock in HA?

2) For the lock/hastate topic, your documentation says, possible values are: locking, locked, unlocking, unlocked, jammed. i subscribed to lock/hastate, to get early status updates, especially unlocking and locking, but i never see those states. States are updated only after lock has finished it's action, so i only see the states locked and unlocked. i really like to see unlocking und locking, because then the system could react a few seconds earlier. how can i get early states unlocking and lockin?

3) i have to know when a user presses the nuki button, and i must know if he pressed once or twice, or, as an alternative, what action (e.g. lock 'n' go) got triggered. i need that to arm my alarm system, but only if the lock was locked by lock'n' go. how do i do that?

My configuration: Nuki Hub firmware V8.34 on a M5Stack ATOM Lite ESP32 & PoE Base W5500, no WiFi, only Ethernet. Nuki SL4P with FW 4.3.4 (beta)

technyon commented 5 months ago

The ESP has to communicate with the lock to update the status, this takes times, sometimes a few seconds. There's little that can be done to change that. That's also the reason why you don't see states like locking and unlocking, they are done before they can be communicated to the ESP.

There's nothing in the bluetooth API that communicates if the user has pressed the button or not, you only see the result of that press when the configured action has finished. You can then read the "lock/trigger" node, if it reports "button", you know the last action has been triggered by someone pressing the button.

If you need faster updates, you have the option to buy a Pro lock with built-in Wifi. Since the Wifi is built-in, it will skip the step of communicating via bluetooth, and allows to much faster publish state updates.

technyon commented 5 months ago

Thinking about this, there's one thing that could help you. What happens very early is that the ESP receives a beacon that the state has changed. At this point the ESP doesn't know the new state and has to query it from the lock, resulting in the delays you mentioned. It would be possible to publish a message when such a beacon has been received. You would only know that the state has changed at this point, not what the new state is. But if the state is locked, you'd know that the new state is some other than locked, so it should suffice to disarm your alarm system.

iranl commented 5 months ago

@technyon: Was thinking of the exact same solution. I'm also working on better lock n go detection (the oldest outstanding issue on GH right now). I can probably incorporate this there.

@ManniTom: Since you apparently have control of your alarm through your smart home can't you just delay the alarm detection/firing with a couple of seconds to allow for the Nuki status to update?

technyon commented 5 months ago

@ManniTom Could you give us feedback if that would be useful for you?

ManniTom commented 5 months ago

@ManniTom: Since you apparently have control of your alarm through your smart home can't you just delay the alarm detection/firing with a couple of seconds to allow for the Nuki status to update?

No i cannot. the alarm system has it's own small doorlock pin, which is used to prevent that the door is openend while the alarm system is still armed. This is not a burglar secure lock, but only to remind the user, that the alarm system is still armed when he tries to open the door, but forgot to unarm. the alam system has to be unarmed quick, so that the alarm systems doorlock pin get recessed before the nukis unlatch operation ends. i dont want to lengthen the unlatch time to more than 5 seconds for other reasons.

my other problem is that nuki hub will not inform me about presses of the nuki button used to starti a lockNgo process. i need this info to check if the door was closed after lock'n'go, only then should the alarm system be armed. this is to avoid false alarms, when someone played around with the button, activates lock'nGo but never leaves the house.

a message on a beacon receipt would surely be useful

technyon commented 5 months ago

@iranl I just checked the code, this should already be available under "/lock/statusUpdated", isn't it?

iranl commented 5 months ago

Yes, added as part of #365.

Will start working on more options to speed up Nuki Hub soon. I have a feeling the auth log is bogging down my setup more and more too (not sure if this is Nuki Lock 4.0 only or all version). Need to debug this.

iranl commented 5 months ago

@ManniTom: I'm currently wrapping up a PR that will allow Nuki Hub to work in conjunction with the official MQTT implementation over WiFi/Thread. This should allow your SL4(P) to give you very vast updates and intermediate states in HA. Nuki Hub will manage the integration of the official implementation and Nuki Hub functionality that will allow fast updates with all the added functions of Nuki Hub. This should give you the functionality from your first 2 questions.

The Nuki Hub auth log implementation should allow for the functionality of question 3.

ManniTom commented 5 months ago

Sounds very good! Right now i test the Nuki MQTT over WiFi interface of the SL4P, but it's not stable, and so it's unusable. Nuki seems to have great difficulties to get it stable, i don't expect that to be working within the next months. Nuki Hub as an working and fast alternative would be highly appreciated, but i'm not sure how you will connect Nuki Hub to the SL4P by other means than Bluetooth. As far as i know SL4P offers MQTT only over WiFi. You don't want to use that, it's not stable, and there is already an HA integration for that. The other Interface of the SL4P is Matter over Thread, and i don't think that there is MQTT available. Correct me if i'm wrong.... I don't undersstand what you mean with "nuki hub will manage the integration of the official implementation". Could you please explain? Maybe a bit longer explanation would help me understand... :)

iranl commented 5 months ago

Both SL4P and SL4 support MQTT over Thread. I have this running on my SL4 right now, will probably switch my SL4P over when I'm done with the hybrid functionality. Thread MQTT is free on both the SL4 and the SL4P, they only charge for their remote access over Thread on the SL4. No stability issues as of yet (weeks testing).

You can't run the official MQTT while you have a (Nuki Hub/official) bridge connected.

The idea of combining Nuki Hub and the official MQTT implementation is:

Hopefully will bring the best of both worlds in speed, functionality, battery life and reliability.

ManniTom commented 5 months ago

Both SL4P and SL4 support MQTT over Thread. I have this running on my SL4 right now, will probably switch mu SL4P over when I'm done with the hybrid functionality. Thread MQTT is free on both the SL4 and the SL4P, they only charge for their remote access over Thread on the SL4.. No stability issues as of yet (weeks testing). -> Great!

You can't run the official MQTT while you have a (Nuki Hub/official) bridge connected. -> What exactly do you mean by official MQTT?

The idea of combining Nuki Hub and the official MQTT implementation is: • Setup Matter over Thread on your SL4(P)with a border router that supports NAT64 (Apple device or Home Assistant) • Pair Nuki Hub as an app with your SL4(P) -> Does this mean you will emulate the Nuki Smartphone App? Will the smartphone App still be usable?

• Set intervals to check for changes over BLE to really high numbers • Let Nuki Hub monitor the official MQTT topics for state change • In case of state changes publish as much information as possible from the official MQTT topics to Nuki Hub topics (faster) • Request the rest of the usual Nuki Hub information over BLE • When you tell Nuki Hub to execute an action (lock/unlock) optionally sent this lockaction over MQTT to the official MQTT lockaction topic instead of over BLE (faster) • All Nuki hub functions that are not supported in official MQTT remain available (e.g. config, keypad, auth log, time control, acl etc.) over BLE • Fallback to BLE when official MQTT is not connected • Your smarthome appliance (e.g. Home Assistant) remains connected to only Nuki Hub -> by the means of the e.g. mosqitto MQTT broker and the MQTT HA integration?

Hopefully will bring the best of both worlds in speed, functionality, battery life and reliability. —

Thankfully i already testet matter over Thread, and i still have the necessary hardware. i uninstalled it though, because of the extremely limited functionality the matter integration of nuki offered. looking forward to test it again, though, with nuki hub, once you release a matter/thread MQTT version!

:)

mundschenk-at commented 5 months ago

@ManniTom Nuki has added support for their own MQTT API with a recent FW update for the SL3P via WiFi (and apparently this API is also supported via Thread on the SL4* models, but I don't know anything about that).

iranl commented 5 months ago

As @mundschenk-at said Nuki has added MQTT to all their devices that have their own network access. This means the SL3P (Wifi), SL4 (Thread) and SL4P (Wifi or Thread). This allows you to get the state of the device and send lock actions without a bridge or any cloud based Nuki services. You just connect the Nuki lock directly to a MQTT broker.

I agree that Matter over Thread is pretty bare bones/useless. But in my plan Matter is only used to connect the Nuki over Thread to a border router that gives the Nuki device network access. MQTT on the Nuki device can then be enabled, but only if no bridge is connected. The Nuki MQTT implementation is also pretty bare bones, but it is alot faster than BLE in notifying Nuki Hub of state changes. Nuki Hub will subscribe to the messages sent by the official MQTT and directly republish some of these messages to the Nuki Hub topics and use these messages to detect when to do updates over BLE.

mundschenk-at commented 5 months ago

That plan sounds fantastic (and could be a reason to upgrade to finally try out WiFi).

ManniTom commented 5 months ago

Great plan! i could add my thread hardware again, it's a sonoff radio module with a Silicon Labs EFR32MG21 Radio, together with home assistant AddOns it builds the border router, which i had been running already. So i could test everything and give feedback. Are you sure that nuki, on the SL4P, has enabled MQTT over Thread? i've heard something that it's only enabled over WiFi...

iranl commented 5 months ago

I'm using the same Thread chip (Sonoff-E) with HASS.io running as a VM (couldn't get NAT64 working on HA/Matter/OTBR in docker, going the HASS route with addons is currently highly recommend)

See the Nuki article on MQTT over Wifi and Thread: https://support.nuki.io/hc/en-us/articles/14052016143249-Activate-MQTT-via-the-Nuki-app

I'm almost done with a version that can be tested, have it running stable on my SL4 since yesterday, but it still needs some final adjustments. You can prepare for this release by setting up Thread on your SL4P and testing if you can get the official MQTT implementation running. Note that you do need to remove the Nuki Hub bridge connection to the SL4P to connect to MQTT over Thread.