My Keymatic is unfortunately defective and must be replaced. Unfortunately, I am not thrilled with the quality of the opener! Therefore, I am looking for an alternative. It should be possible to open the lock via Openhab. I have enocean, zigbee, wifi and Homematic in use.
My current lock I do NOT want to change. Currently I am leaning towards Nuki, what do you say? Does the Nuki have zigbee or not?
PS: can someone tell something abaout the performance? If i use the Nuki 2.0 with the Qlan-Bridge. How long does it take for the lock to open when I send the command in Openhab? I have a external Fingerprintsensor who should open the door with nuki, but if this take a lot of time its useless
I have also a self built fingerprint sensor, Nuki and the Nuki bridge.
Nuki has an API that you can send commands to via the Nuki binding. It works very reliably - I haven’t experienced any quirks so far.
After Issuing the command it takes around a second and the lock will start opening. I have not waited longer than a second as far as I can remember, most of the time the dellay is shorter.
Also, I’m impressed with how good the adhesive mounting plate sticks to the door. We had some pretty cold winter days (-15°C outside) and I was prepared for it to fail, but it didn’t.
If you get it, get the eneloop pro batteries, they last very long (up to a year they say…).
Hi! How are you triggering it? Via rule?
It is never that slow for me. I have a display on my fingerprint reader so I see when the command is sent, and the Nuki reacts almost immediately.
Maybe you share a bit more of your setup and we can investigate!
ok so first of all, check the event log when exactly your states change and commands fire:
the fingerprint state
then, are you on OH2 or OH3?
And do you possibly have a jython setup up and running?
My experience is that DSL rules fire with a big delay when the rules in the file are not used very often. This got better with OH3, but still sometimes my rules fire delayed. That is not the case for jython, where I have my door unlock rules. The response there is immediate.
One more difference is that I use the Nuki Bridge, but let’s first find out where your delay is from. Maybe you can post your event log with the specific state changes?
i use a dahua VTO fingerprint. On the raspberry i have a PHP-Script that receive the fingerprintcommand from Dahua API and set the Haustuer_Open on true via HTTP-Restcall. With my old Homematic Item i havent any delay.
I use OH3, what kind of rule is faster than the classic DSL rules? I will test it
before you fiddle around with the rules, how long does the lock take to react when you issue the command to open manually from openhab? E. g. send the number seven to the item via the api explorer (in developer tools).
That way we can rule out the Nuki side for delay.
If there’s already a delay, then we’ll need to look into the Android Bridge.
OK, I’ll test tomorrow how long exactly it takes for me. But that would mean the Android Bridge is to blame, as I have the Nuki Hardware bridge.
Edit: I just tested it. The reaction of the lock is instant when I flick the switch in openhab. Not even a quarter of a second. Maybe the android bridge is just slow? Have you tried contacting nuki over this? The android bridge won’t be supported anymore some time soon though…
I only have the Android bridge.
The first opening takes much longer than an opening afterwards. As if a bt connection has to be established first or something. I just stood in front of the door again for 6 seconds. Directly afterwards it took “only” 2 seconds.
The Softwarebridge is outdated since last month.
They have stopped developing it because it is probably so rarely used. But the function should still be guaranteed.
The tablet hangs right next to the door and is always plugged in. It is a Fire hd 10 with fully kiosk browser. When I move it the display comes on and shows me my habpanel. So the tablet is always on. I don’t know if it will turn off bluetooth at some point.