The query interval configuration should be set to something like an hour (or more) as well. Strangely, on my updated device it is set to 3600 seconds (which was the previous hardcoded default).
Is there anyway to be able to get the data from the door sensor?
If it is paired with the lock, it should automatically be included, yes.
I have it paired with the lock
But it doesn’t shows up, I only get this:
I even tried getting it through yaml:
But still nothing
The payloads are wrong, it should look like something like this (already in the new mqtt domain):
mqtt:
binary_sensor:
- name: mqtt_lock_door_test
state_topic: "nuki/lock/doorSensorState"
value_template: "{{ value }}"
payload_on: "doorOpened"
payload_off: "doorClosed"
device_class: "door"
qos: 1
unique_id: mqtt_lock_door_test_unique
After 24 hours of using two Nuki Hubs I have two issues:
- KeePad (2.0) not showing up. What is needed on the configuration side for this? Only found the tick box for the Nuki Opener.
kpInterval: 1800
kpEnabled: false
- Every now and then (okay, 2 times per Nuki Hub) the device goes offline (looses WiFi connection) - and NEVER comes back, not even after two or more hours. Only discovered as trying to control the locks is doing nothing anymore. What are the recommended network settings for this? For now I only gave the tick box a try:
Thanks for sharing. Will monitor that topic, hopefully it will be possible shortly.
What about recommended network settings to get a constant WiFi connection?
(#2 from NUKI Hub firmware for the ESP32 - #224 by e-raser)?
According to mundschenk-at and to my own experience, it is not necessary to create manually the binary_sensor before. But may be something changed in the latest versions because me too, after to reset my esp and re-flashed it, I have no more this sensor automatically created.
Thank you very much, it works now 
Only thing is that my cloud-based tuya contact sensor is waaaaaay faster than this 
Even with the native Nuki app, the state door take several seconds to be refreshed. I think Nuki hub cannot do anything about that. May be it is faster with the smartlock v3 ?
I switched from the official bridge to this hardware because the nuki_ng was not really working well with the underpowered bridge. So far everything seems to be working fine. I have a few questions, howerver:
- Is it correct that the hub does register with the Smartlock as bridge, but not rwith Nuki Web like the original bridge? Yes, one less cloud service to rely on, but it was sometimes handy to be able to use the wab app or the Android app from afar.
- Are there any implementatione examples (blueprints, automations, scripts) for keypad administration via the Nuki Hub?
- I don’t get any readings for wifi and Bluetooth signal strength?!
- I have the Smartlock Pro. This has an internal wifi, which gets disabled as soon as a bridge is connected. Not that it is absolutely necessary, but would it be possible to run the internal wifi in parallel to the bridge (would probably solve 1.)?
- What does the “trigger” attribute mean?
Hi - it’s been 10 days since I installed v8.0 and set the query intervals to 7200. Battery drain has reduced from 6% per day to 2.7% per day. A good improvment, but still a bit high in my opinion.
v8.0 has been rock solid after periods of uptime of 3-4 days and a few HA updates along the way. Just installed v8.7 today to see if there are any improvements. I have set all the new config interval to 7200 as well.
P.S: The system information page in v8.7 is quite handy. Any chance of placing an uptime and/or time of last disconnect data in there (just saw a “RestartOnDisconnectWatchdog” for Restart Reason FW message in there).
I went from 2.5% per day to 0% in 7 days since I completely reset my esp32 (re-installed the bootloader) then re-flashed via the usb cable and left the default fw settings. It may be due to something else (e.g. less restart => less battery drain) but you could try it.
+1 definitely helpful
Disconnect time isn’t possible, since the ESP doesn’t know the date. I’ve added uptime which will be included in the next release. There’s already an mqtt node that holds the uptime (maintenance/uptime). If you log it you put it in a chart and track restarts.
1 Like
Any kick-start information for MQTT newbies to achieve this?
Just add this to your configuration yaml:
mqtt:
sensor:
- name: "nuki_esp32_upti"
state_topic: "nuki/maintenance/uptime"
value_template: "{{ value }}"
unit_of_measurement: minutes
unique_id: nuki_esp32_upti_unique_id
If you already have the mqtt: sensor: part (i think you would), just start with the -name line and add it under your last mqtt sensor. Reload mqtt and now you have a sensor with the uptime, if the sensor drops to below 10 you have had a restart.
1 Like
Thanks. Too easy. Looking at MQTT Sensor - Home Assistant I added some minor stuff (e. g. make it show up in the diagnostics section of the respective Nuki Hub device).
I used:
mqtt:
sensor:
- name: "lock_door_a_uptime_nukihub"
state_topic: "nuki_door_a/maintenance/uptime"
value_template: "{{ value }}"
unit_of_measurement: minutes
unique_id: generated-by-vs-code
state_class: total
icon: mdi:clock
device:
identifiers: nuki_XXXXXXXX
entity_category: diagnostic
