According to the documentation it is not (more ?) true:
In fact, when I replaced binary_sensor
by sensor
, I let device_class: door
in place and I have the right representation:
According to the documentation it is not (more ?) true:
In fact, when I replaced binary_sensor
by sensor
, I let device_class: door
in place and I have the right representation:
You have specific device classes for each type of sensor, the code editor gave me error on Door when using sensor. Thatâs why I switched to binary_sensor.
Hereâs the official documentation regarding sensor vs binary_sensor device class property:
Ok, I tried the lock switch, as suggested initially by @Friedrieck and you both convinced me. Iâll switch to this one and will update the card to v3.1.
Thanks.
I updated the post, v3.1 published.
@mahikeulbody: if you can double-check it works Iâd appreciate it.
Very nice !
Sometimes, Nuki Door Status is no more updated (it stays "closed, even opening the door). I need do some lock/unlock to update it. But let double check again.
That sensor is updated by the callback of the bridge, it either works or not. If itâs not working it means the bridge is not calling the url/webhook.
Restart HA and do some testsâŠcheck HA logs for unkown webhook etc.
It seems that occurs when I unlock Nuki manually and then I open the door : Nuki Door Status stays âclosedâ but lock status is updated (with a little delay). I need to lock/unlock via HA to update again door status. It is not a callback problem as in the others cases, door status and lock status are updated immediately.
Hi there,
here itâs the same for some minutes after I manually unlocked the door. The icon switched between mdi:door to mdi:door-closed, but the status said âClosedâ.
A couple of minutes later it works as intended, icon switches between mdi:door-open and mdi:door-closed and analogous to this, the status.
I have exactly the same behavior.
So may be, it is not needed to do some lock/unlock with HA, just wait a few minutes ?
Ok.
But right now just after writing the above, I am not able to reproduce it again.
I locked it with a different script I have, unlocked it manually and when openend it worked as it should.
I tried with the Nuki app (Android) and it showed a problem with the door sensor (default). I re-calibrated it and now it is ok. I find strange to have this problem at the exact time to test v3.1
PS. May be an electronic noise coming from the bridge perturbing the door sensor in condition of tests (many lock/unlock opening/closing) ? Let check it during a few hours/days.
The Door Status âclosedâ is the default not initialized state when you restart HA. Unfortunately that sensor is not âunavailableâ when it starts like the lock. It is available but not initialized, and it says closed. When the Door Status is not initialized (and Closed) the Lock Status is grayed out. That lets you distinguish things.
As soon as you do some actions manually on the lock or on the door, the Bridge calls the url with the webhook, the Door Status sensor gets initialized with the correct real status, and the Lock that is grayed out becomes available and initialized with the real status of the lock.
This is how it works. Reading your experience, I canât really understand what you are seeing, thatâs why I wanted to fully explain how it worked.
Can you please do some stricter/reproducible tests?
Restart HA: you should see the Lock sensor as unavailable (grayed out) and the Door sensor as available and status=Closed.
Go at the door and open it so the bridge calls the webhook url and you should then see both sensors available and initialized, and the Door Status should be Open.
Then do another test, if the one above worked:
Restart HA: you should see the Lock sensor as unavailable (grayed out) and the Door sensor as available and status=Closed.
Go to the door and Lock/Unlock the Nuki so the bridge calls the webhook url and you should then see both sensors available and initialized, and the Lock Status should reflect the action you did on the Nuki.
Please let me know the result.
The thing I changed in v3.1 is Iâm using the Template Lock instead of Template Switch. But I didnât notice a different behaviour when I tested here.
Thanks for the help.
I can assure you I didnât put any strange things in the code.
Itâs just a coincidence, I hope.
That run exactly as you described. As I said, I am aware of the HA restart âproblemâ so I do this operation (opening the door or unlock/lock) after each restart.
I can assure you I didnât put any strange things in the code.
I was sure of that but I found strange two people have the same symptom at this exact moment. But when I saw that Nuki app showed the message âcapteur de porte bloquĂ©â (in english, that would be something as âdoor sensor blockedâ) I understood the problem was probably on the Nuki side. And indeed, all is running very nice after re-calibrating the door sensor.
So may be it is a coincidence, may be this HA config reveals a bug into Nuki bridge or Nuki lock. I will continue to âstressâ the lock in order to see if I can reproduce the problem.
So now that you recalibrated the doorsensor, you donât have the odd behaviour anymore, right? everythingâs working as expected?
But @Joerg didnât say he had the calibration error in the app. I donât beleive in coincidences either, so I want to be sure.
I told to fast, I just reproduce the problem ! With again the door sensor in default in Nuki app. I will try to re-calibrate it and use the Nuki door only with Nuki app to see what appen.
So the app told you that the doorsensor is not calibrated, AGAIN?
I donât know what could possibly cause thatâŠweâre not doing anything different respect to when we used the Template Switch. Instead of dong Turn On/Turn Off weâre doing Lock/Unlock.
Let me know your findingsâŠbut Iâd like to know also what @Joerg experience is, he didnât mention the uncalibrated sensor problem.
Also, I donât have this issue, and Iâm not able to reproduce it here.
Iâll wait for your feedbacksâŠ
The first steps were okay. But after I manually unlocking the lock I got the same behavior:
After writing the above I went back to the door and after opening/closing it, the status came back to normal, but battery and last actvity were unavailable. Coming back to my desk and start writing this paragraph everything refreshed and now all is good
I checked the Nuki Log - it says Door sensor disturbed
when this happens.
17:27h and 18:19h â see time of my screendumps