MQTT topic content for nuki/lock/log is cut-off #270
Comments
|
It's not exactly an overflow. There's a buffer allocated of 4096 bytes. The JSON serializer checks against this maximum size, and in your case has hit the limit. There's a flag in the serializer to check for that, in that case the last log entry should be removed ... or the easy fix maybe is to increase the buffer size. I'd need to to some math what the maximum size could be, considering you're using the maximum length for the keypad entry names. |
|
Thank you 🙏
Is there anything I can change on my side to make it work out-of-the-box? I only have one keypad permission right now and it's just called "Zutrittscode". |
|
You'll find other things than keypad entries in the log. Any time you a lock action is executed, it appears in the log. Did you assign any long names (Android/IOS App, Fobs)? Also could you copy/paste the payload into a text editor and see if it really is longer than 4095 characterrs (4096 minus one for the termination character). |
|
Nope, my setup is pretty new. Just this one access code, no fobs, no other users etc. |
|
OK Counting the characters would help nevertheless :) |
|
I did a factory reset of the Nuki lock which led to the But another thing I just noticed is that the indices are assigned multiple times, don't know whether that's by design or not: The unredacted version of the payload is in total 2198 characters long. |
|
I'd say something strange is going on there. You don't just have duplicated indices, but duplicated log entries. Also, there should be no more than five log entries. NUKI Hub requests the last five log entries from the log, how those duplicates appear in your log I can only guess. It would also explain why you had the cut off json before. Which MQTT broker are you using? |
|
I use the Mosquitto addon for Home Assistant. I also encountered that some lock-related topics are not updating for hours while eg. presence is updated every few seconds, also after changing eg. the lock state interval to 300 seconds etc. Do you need some config insights? |
|
Let's check first what's going on on ESP side. Can you get serial logs? This firmware prints the log entry count when publishing, it should be no more than 5. Speed for serial logs is 115200. |
|
Somehow I wasn't able to flash that binary to my esp32 yet. I will try again tonight. More insights:
Maybe its a general problem with the Nuki 4 locks? |
|
Very strange. Getting those serial logs would be helpful. If it's a Nuki 4 issue, it's a bug in the Nuki 4 firmware. |
|
Here comes the serial logs: |
|
I'm having the same issue with my Nuki4 Pro lock. NUKI Hub info: MQTT value of /nuki/lock/log (4.106 characters long): Error seen in home-assistant logs: Entities on home assistant are unknown: I'm not sure if it's related to this problem (Sorry if it's not, maybe I can create a new issue for this), but I'm also seeing multiple lock autodiscovery topics with weird names created in /homeassistant/lock And this are some examples of multiple warnings that I can see in my home-assistant logs: If I delete the autodiscovery topics on the MQTT broker, the warnings on home-assistant go away for a few hours, but then reappear after some time. I only have one NUKI Lock and one NUKI Hub. |
|
This is your problem:
Only 5 entries are requested from the lock, so there should be a maximum of 5 entries. I suspect a bug in the firmware, especially if it 's only reported for 4.0 locks. Let me get in touch with the devs of the library that controls the lock. Problem is though we could ask in the NUKI developer forum, but lately there seems to be noone answering there. |
|
So the JSON is already delivered cut-off from that other library? Is that your fork here: https://github.com/technyon/nuki_ble ? |
|
Yes that's my fork, altough there should be no difference to the main project at this time, except maybe for a few missing commits. That library doesn't provide JSON, but enables communication to the lock. If 5 log entries are requested, it should return 5 objects with log information. In your case it returns 22, which are then serialized to JSON. Since the library worked fine until now, I suspect firmware bug in the 4.0 locks. |
|
But since the JSON itself is prematurely terminated and therefore no valid JSON, it could also be a memory / buffer problem in your JSON serialization, can't it? Am I thinking to primitive or might it be just possible to discard any entries you receive from that lib after the fifth one and then just serialize those 5 ones? |
|
Well, on a microcontroller resources are limited. You can't just happily create strings like on a x86 architecture, since memory is limited. For serialization a static buffer is allocated, and the number of log entries was chosen accordingly so they fit into this buffer. NUKI Hub relies on a the library to only send it 5 entries, which in turn relies on the lock to send only 5 entries. The lock has a bug, sends more entries, the serializer stops when it reaches the buffer limit and your string is truncated. Long story short, one should check external input, and yes maybe adding a check to only serialize the first five entries is a idea. Check the binary below. |
|
Yes, I must admit that I don't have much experience with embedded and microcontroller coding. But whatever you did now, worked. At least the JSON in that But: It also doesn't show the most recent logs. I think the logs are being red in reverse order. Currently the JSON contains the indices 2-6 which represents the oldest entries 2-6 shown in the app. So the first one is skipped, then the 5 next entries are shown. But since there the log recorded like ~25 more log entries. |
|
Ultimately NUKI has to fix this. The order to send this is also specified when sending the request to the lock, and the lock should return entries in the correct order. P.S.: Included in release 8.30 |
|
Fixed in #368 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
thanks for building this super nice piece of code. The integration works like a charm.
I just encountered a problem with the log supplied within the MQTT topic
nuki/lock/log:The JSON is somewhere just cut-off with some strange byte characters which makes it impossible to parse.
Also, the
Keypad StatusandLast action authorizationare unknown in HA.Is this kind of an overlow?
The text was updated successfully, but these errors were encountered: