-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
delay, missing states, button press info #361
Comments
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. |
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. |
@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? |
@ManniTom Could you give us feedback if that would be useful for you? |
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. my other problem is that nuki hub will not inform me about presses of the nuki button used to starti a lockNgo process. a message on a beacon receipt would surely be useful |
@iranl I just checked the code, this should already be available under "/lock/statusUpdated", isn't it? |
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. |
@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. |
Sounds very good! |
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. |
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). 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: • Set intervals to check for changes over BLE to really high numbers 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. :) |
@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). |
As @mundschenk-at said Nuki has added MQTT to all their devices that have their own network access. 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. |
That plan sounds fantastic (and could be a reason to upgrade to finally try out WiFi). |
Great plan! |
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: 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. |
I connected the nuki hub to my home assistant, and the basic functionality is working.
now i have a couple of questions:
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?
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?
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)
The text was updated successfully, but these errors were encountered: