[Solution Provided] Nuki Lock state undefined since version 8.35

[MihaiKrieger]

PROBLEM DESCRIPTION

With the update to the new 8.35 FW, the Nuki Lock state is undefined.
Repairing the lock did not solve the problem.
Power cycling the ESP32 Board did not solve the problem.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• [x ] Read the Contributing Guide and Policy and the Code of Conduct
• [ x] Searched the problem in issues
• [ x] Searched the problem in discussions
• [ x] Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., ESP32-S3): ESP32 D1 mini
• Nuki Hub binary firmware version number used: 8.35
  • Pre-compiled
  • Self-compiled
• Provide the output of http://nukihubIP/info:

System Information
Nuki Hub version: 8.35
Nuki Hub build: 9596492875.1136.1 (release)
run: true
confVersion: 835
deviceId: 4178833015
deviceIdOp: 2209271902
nukiId: ***
nukidOp: 
mqttbroker: 192.168.1.2
mqttport: 1883
mqttuser: ***
mqttpass: ***
mqttlog: false
checkupdates: true
websrvena: false
lockena: true
lockpin: 1
mqttpath: nuki
openerena: false
openerpin: 
openercont: false
mqttoppath: 
maxkpad: 
opmaxkpad: 
maxtc: 
opmaxtc: 
enabtlprst: false
mqttca: 
mqttcrt: 
mqttkey: 
hassdiscovery: homeassistant
hassConfigUrl: 
buffsize: 
dhcpena: true
ipaddr: 
ipsub: 
ipgtw: 
dnssrv: 
nwhw: 1
nwwififb: false
rssipb: 60
hostname: NukiHub
nwbestrssi: false
nettmout: -1
restdisc: true
rstbcn: 120
lockStInterval: 1800
tcPerEntry: false
kpPerEntry: false
configInterval: 3600
batInterval: 1800
kpInterval: 1800
kpCntrlEnabled: true
kpInfoEnabled: false
kpPubCode: false
tcCntrlEnabled: false
tcInfoEnabled: false
cnfInfoEnabled: true
regAsApp: false
regOpnAsApp: false
nrRetry: 0
rtryDelay: 100
crdusr: ***
crdpass: ***
disnonjson: false
pubAuth: false
pubdbg: false
prdtimeout: 60
offHybrid: false
hybridTimer: 600
hybridAct: false
hybridRtry: false
hasmac: false
macb0: 
macb1: 
macb2: 
latest: 8.35
tsksznetw: 
tsksznuki: 
authmaxentry: 
kpmaxentry: 
tcmaxentry: 
MQTT connected: Yes
Lock firmware version: 
Lock hardware version: 
Lock paired: Yes
Lock valid PIN set: Yes
Lock has door sensor: No
Lock has keypad: No
Lock ACL (Lock): Allowed
Lock ACL (Unlock): Allowed
Lock ACL (Unlatch): Allowed
Lock ACL (Lock N Go): Allowed
Lock ACL (Lock N Go Unlatch): Allowed
Lock ACL (Full Lock): Allowed
Lock ACL (Fob Action 1): Allowed
Lock ACL (Fob Action 2): Allowed
Lock ACL (Fob Action 3): Allowed
Lock config ACL (Name): Disallowed
Lock config ACL (Latitude): Disallowed
Lock config ACL (Longitude): Disallowed
Lock config ACL (Auto Unlatch): Disallowed
Lock config ACL (Pairing enabled): Allowed
Lock config ACL (Button enabled): Allowed
Lock config ACL (LED flash enabled): Allowed
Lock config ACL (LED brightness): Disallowed
Lock config ACL (Timezone offset): Disallowed
Lock config ACL (DST mode): Disallowed
Lock config ACL (Fob Action 1): Disallowed
Lock config ACL (Fob Action 2): Disallowed
Lock config ACL (Fob Action 3): Disallowed
Lock config ACL (Single Lock): Allowed
Lock config ACL (Advertising Mode): Disallowed
Lock config ACL (Timezone ID): Disallowed
Lock config ACL (Unlocked Position Offset Degrees): Disallowed
Lock config ACL (Locked Position Offset Degrees): Disallowed
Lock config ACL (Single Locked Position Offset Degrees): Disallowed
Lock config ACL (Unlocked To Locked Transition Offset Degrees): Disallowed
Lock config ACL (Lock n Go timeout): Disallowed
Lock config ACL (Single button press action): Disallowed
Lock config ACL (Double button press action): Disallowed
Lock config ACL (Detached cylinder): Disallowed
Lock config ACL (Battery type): Disallowed
Lock config ACL (Automatic battery type detection): Disallowed
Lock config ACL (Unlatch duration): Disallowed
Lock config ACL (Auto lock timeout): Disallowed
Lock config ACL (Auto unlock disabled): Allowed
Lock config ACL (Nightmode enabled): Disallowed
Lock config ACL (Nightmode start time): Disallowed
Lock config ACL (Nightmode end time): Disallowed
Lock config ACL (Nightmode auto lock enabled): Disallowed
Lock config ACL (Nightmode auto unlock disabled): Disallowed
Lock config ACL (Nightmode immediate lock on start): Disallowed
Lock config ACL (Auto lock enabled): Allowed
Lock config ACL (Immediate auto lock enabled): Disallowed
Lock config ACL (Auto update enabled): Disallowed
Network device: Built-in Wi-Fi
BSSID of AP: C2:09:D0:1E:F7:A1
Uptime: 3 minutes
Heap: 76664
Stack watermarks: nw: 7092, nuki: 5420, pd: 7092
Restart reason FW: RestartOnDisconnectWatchdog
Restart reason ESP: ESP_RST_SW: Software reset via esp_restart.

TO REPRODUCE

Steps to reproduce the behavior: Update to the new firmware via the OTA interface from the board.

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen. Nuki lock state should be locked, unlocked, locking, or unlocking, based on the situation. However, it remains in undefined state.

SCREENSHOTS

ADDITIONAL CONTEXT

I have rolled back to the 8.34 version, and it started working again.
Post downgrade screenshot:

(Please, remember to close the issue when the problem has been addressed)

[technyon]

That's very strange, and sure didn't happen during testing. Could you get MQTT or serial logs with fw 8.35. For serial logs you can use hterm and connect 115200 baud.

[iranl]

Is the state only undefined in the webconfigurator or also in MQTT?

Serial logs would be helpfull

[MihaiKrieger]

I'm sorry I did not have the time to install 8.35 again and gather the logs for you. Making the door unavailable during a busy evening would put me in a bad light at home.
I don't have any MQTT logs because none were generating. I would have to collect the serial ones.
@iranl - Other observations:

1. In MQTT, the lock was showing as available, and locked. I think it was because that was the state of the door before updating the firmware.
2. MQTT was appearing as "connected" in the device's page in HA. MQTT Connected - on
3. The undefined state was only in the web configurator, nowhere else. In the native app, the correct state of the lock was displayed, and in HA, the door had the locked state.
4. When I called the unlock service in HA, the door would indeed unlock! However, the updated state would not display. The MQTT state was still locked and the web configurator state would still be undefined.
5. No other subsequent actions would take effect. I called the lock service from HA, but the lock wouldn't react at all.
6. During this time, the MQTT log was not being populated with any new entries
7. No other actions would take effect from HA. E.g: toggling LED enabled. on 8.34 version, this works correctly. My lock has a PIN defined in the web configurator.

I hope this helps further. I'm doing my best to get around to reinstall 8.35, reproduce the issue and collect the logs.

[iranl]

Your observations point to an issue with BLE communications.

Considering your other issue (#403) where you didn't recieve BLE beacons (which is not very common in my experience) i'm not yet convinced this is 8.35 related and not hardware/situation dependant.

The fact that you are able to unlock the door also point in the direction that some BLE communication is possible, even if it is only sending and not recieving.
How far away is your device from the lock? Can you try to reduce this distance?

[MihaiKrieger]

Strange, to only have the issue on the new FW. The distance between lock and esp board is around 1.5 -2 meters, with a BT strength of -64 dBm.
It is stable again with 8.34 FW, and with respect to my other issue, it is no longer an issue, now that I have corrected the settings and the board restarts itself correctly.

Below an evolution of the BT strength for a couple of hours.
The flatline is when I had the problem earlier today, again, solved nicely with a reboot. :)

[iranl]

Can't reproduce this on 8.35 with:

• ESP32 D1 Mini (Hybrid mode)
• Second ESP32 D1 Mini (App mode)
• ESP32 S3 (Hybrid mode)
• Second ESP32 S3 (App mode)
• ESP32 C3 (App mode)

Using Lock 4.0 and Lock 4.0 Pro

Very interested in serial logs (might need logs from the debug binary) when you get the chance

[pipip]

I have the same issue with Nuki Smart Lock 3.0 Pro and M5Stack Atom.
--> Nuki Lock state: undefined

Downgrade to 8.34 makes the hub and lock work again immediatelly.

[iranl]

@pipip Please provide a serial log while running 8.35

[gerardovf]

While I try to get a serial log, I would like to point out that, after deleting the 'homeassistant' topic in the broker the nuki hub never sends it complete again (just homeassistant/status -> online)
The "lock/query/lockstateCommandResult" topic sends "undefined" payload.

[iranl]

Homeassistant discovery is only updated when a valid config from the Nuki device is received.
Info page from @MihaiKrieger suggests that a valid config is never received (There is no firmware/hardware version of the Nuki device).
So that would match with your observation.

It is possible that a serial log when on a release binary will not give much information.
A serial log while running a debug firmware (from https://github.com/technyon/nuki_hub/actions/runs/9598815492) will provide more information.

[iranl]

I may have found the issue in the info page supplied by @MihaiKrieger.

nrRetry is set to 0.

There was a change in 8.35 with how this value is used.
Setting this to 0 will mean that most commands are never sent.

This setting is basically not named correctly as of this time as it is not interpreted as number of retries but as maximum number of total tries of a command.

I'll make a PR to fix this.

Please check the value or nrRetry on your info page and if this is 0 set it to at least 1 on the "Nuki configuration" page with the setting "Number of retries if command failed" (default is 3)

[MihaiKrieger]

I have just re-checked this value in 8.34 FW (working), and nrRetry still has the value 0.
So to make sure I understood correctly:
This value should be 3 on v8.35, correct?

On 8.34 it is still 0, but it doesn't matter, because it only becomes a problem in 8.35, so 0 should fine in 8.34.
I'll try installing release version 8.35 again and come with a later edit after I have changed this value to 3.
Please let me know whether do I still need to collect any logs using the debug version of the firmware, and I can do it tomorrow.

LE: Just updated to new fw, added value 3 to Number of retries if command failed and it works now exactly as expected.

Nuki Hub version: 8.35 Nuki Hub build: 9596492875.1136.1 (release) run: true confVersion: 835 deviceId: 4178833015 deviceIdOp: 2209271902 nukiId: *** nukidOp: mqttbroker: 192.168.1.2 mqttport: 1883 mqttuser: *** mqttpass: *** mqttlog: false checkupdates: true websrvena: false lockena: true lockpin: 1 mqttpath: nuki openerena: false openerpin: openercont: false mqttoppath: maxkpad: opmaxkpad: maxtc: opmaxtc: enabtlprst: false mqttca: mqttcrt: mqttkey: hassdiscovery: homeassistant hassConfigUrl: buffsize: dhcpena: true ipaddr: ipsub: ipgtw: dnssrv: nwhw: 1 nwwififb: false rssipb: 60 hostname: NukiHub nwbestrssi: false nettmout: -1 restdisc: true rstbcn: 120 lockStInterval: 1800 tcPerEntry: false kpPerEntry: false configInterval: 3600 batInterval: 1800 kpInterval: 1800 kpCntrlEnabled: true kpInfoEnabled: false kpPubCode: false tcCntrlEnabled: false tcInfoEnabled: false cnfInfoEnabled: true regAsApp: false regOpnAsApp: false nrRetry: 3 rtryDelay: 100 crdusr: *** crdpass: *** disnonjson: false pubAuth: false pubdbg: false prdtimeout: 60 offHybrid: false hybridTimer: 600 hybridAct: false hybridRtry: false hasmac: false macb0: macb1: macb2: latest: 8.35 tsksznetw: tsksznuki: authmaxentry: kpmaxentry: tcmaxentry: MQTT connected: Yes Lock firmware version: 4.2.8 Lock hardware version: 7.0 Lock paired: Yes Lock valid PIN set: Yes Lock has door sensor: No Lock has keypad: No Lock ACL (Lock): Allowed Lock ACL (Unlock): Allowed Lock ACL (Unlatch): Allowed Lock ACL (Lock N Go): Allowed Lock ACL (Lock N Go Unlatch): Allowed Lock ACL (Full Lock): Allowed Lock ACL (Fob Action 1): Allowed Lock ACL (Fob Action 2): Allowed Lock ACL (Fob Action 3): Allowed Lock config ACL (Name): Disallowed Lock config ACL (Latitude): Disallowed Lock config ACL (Longitude): Disallowed Lock config ACL (Auto Unlatch): Disallowed Lock config ACL (Pairing enabled): Allowed Lock config ACL (Button enabled): Allowed Lock config ACL (LED flash enabled): Allowed Lock config ACL (LED brightness): Disallowed Lock config ACL (Timezone offset): Disallowed Lock config ACL (DST mode): Disallowed Lock config ACL (Fob Action 1): Disallowed Lock config ACL (Fob Action 2): Disallowed Lock config ACL (Fob Action 3): Disallowed Lock config ACL (Single Lock): Allowed Lock config ACL (Advertising Mode): Disallowed Lock config ACL (Timezone ID): Disallowed Lock config ACL (Unlocked Position Offset Degrees): Disallowed Lock config ACL (Locked Position Offset Degrees): Disallowed Lock config ACL (Single Locked Position Offset Degrees): Disallowed Lock config ACL (Unlocked To Locked Transition Offset Degrees): Disallowed Lock config ACL (Lock n Go timeout): Disallowed Lock config ACL (Single button press action): Disallowed Lock config ACL (Double button press action): Disallowed Lock config ACL (Detached cylinder): Disallowed Lock config ACL (Battery type): Disallowed Lock config ACL (Automatic battery type detection): Disallowed Lock config ACL (Unlatch duration): Disallowed Lock config ACL (Auto lock timeout): Disallowed Lock config ACL (Auto unlock disabled): Allowed Lock config ACL (Nightmode enabled): Disallowed Lock config ACL (Nightmode start time): Disallowed Lock config ACL (Nightmode end time): Disallowed Lock config ACL (Nightmode auto lock enabled): Disallowed Lock config ACL (Nightmode auto unlock disabled): Disallowed Lock config ACL (Nightmode immediate lock on start): Disallowed Lock config ACL (Auto lock enabled): Allowed Lock config ACL (Immediate auto lock enabled): Disallowed Lock config ACL (Auto update enabled): Disallowed Network device: Built-in Wi-Fi BSSID of AP: C2:09:D0:1E:F7:A1 Uptime: 2 minutes Heap: 77892 Stack watermarks: nw: 7096, nuki: 4912, pd: 7096 Restart reason FW: RestartOnDisconnectWatchdog Restart reason ESP: ESP_RST_SW: Software reset via esp_restart.

[iranl]

Yes that value should not be zero on 8.35. Set it to atleast 1, but default and advised value is 3

Do note that this is considered a bug, introduced by changes by me in 8.35.

It should be perfectly fine to have this at 0 and will be again in 8.36

If this works no serial logs would have to be collected.

Should this work for @MihaiKrieger and not for others please open your own issue and post correct info as per the issue template

[MihaiKrieger]

I can confirm this works. Posted a new info page above, but somehow the formatting ended up weird.
it is perfectly working as expected with the value "3".

LE: When 8.36 rolls out, should I set it back to 0, or should I leave it at 3? What is the best practice there?

[iranl]

It is up to you. If you don't want commands to be retried you can set it to 0.

Best practice is the default ( = 3)

[gerardovf]

Yes that value should not be zero on 8.35. Set it to atleast 1, but default and advised value is 3

Do note that this is considered a bug, introduced by changes by me in 8.35.

It should be perfectly fine to have this at 0 and will be again in 8.36

If this works no serial logs would have to be collected.

Should this work for @MihaiKrieger and not for others please open your own issue and post correct info as per the issue template

That was the solution! Setting nrRetry to 3 solved the problem. THANKS a lot!!!

[FrankSchoene]

Setting retries does the trick for me. As a note in the release notes it would have saved me 3 hours :-)