wrong value displayed

[Hobbit-0815]

the value "LockActionEvent" of a NUKI 3.0 Pro lock is not displayed correctly. I have tried both with the internal broker and with a mosquitto. If I retrieve the data via MQTTX on a Windows PC I get the correct values.

Value in iObroker objects: ����
Value in MQTTX 3,0,442236930,1,2

Versions:

• Adapter version: 4.1.1
• JS-Controller version: 5.0.12
• Node version: 8.17.1
• Operating system: Linux

[Apollon77]

It seems this is interpreted as binary data ,... please provide a debug log

[Hobbit-0815]

Its with the mosquitto broker

MQTT_Debug.log

also other users are affected:
https://forum.iobroker.net/post/984398
https://forum.iobroker.net/post/984543

[Percy2Live]

@Apollon77
This bug is still present and it seems to be a specific issue with the interpretation of the array data. Is there any news about a possible fix? If further information is required I can provide additional logs and perform some testing

[Apollon77]

There is a setting in the adapter confog to "Trace output for every message:" ... please enable this and post log again, I need to see whats really coming in as data

[git828]

Like this?
mqtt.0 | 2024-02-27 17:38:22.658 | debug | stateChange mqtt.0.nuki.XXXXXXXX.lockActionEvent: {"val":"\u0002\u0000̀\u0000\u0000","ack":true,"ts":1709051902654,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1709051902654}

third 'Backslash' looks weird. Must be binary.

[Percy2Live]

@Apollon77
It seems this is an issue of the nuki transmitting a symbol which isn't the expected ' / ' and hence the interpretation of the data fails. Unfortunately there is no quick fix in sight from nuki itself and this affects a lot of users. Is there any chance to implement a workaround like a special pattern interpretation or an internal replacement of this character (which probably won't ever be used by any other topic as well)

EDIT: My assumption seems to be wrong as @git828 explains below.

[Apollon77]

But how the adapter should find out if thats the case? How to detected that?

[git828]

In mosquitto i can see following data:
Received PUBLISH from Nuki_xxxxxxxxx (d0, q2, r0, m59102, 'nuki/xxxxxxxxxx/lockActionEvent', ... (14 bytes))
In MQTT Explorer i can see correct conversion:

on ioBroker (Client connect to mosquitto) i see some Escape Sequences: ( kind of wrong encoding? )

[dwm66]

Duplicate of #403.
As mentioned there, also the MQTT Adapter shows the right string for lockActionEvent in the debug log, but somewhere it goes astray.

[danny030]

Hi, in the Nuki Developer forum it's being stated that this is likely a problem of the ioBroker adapter: https://developer.nuki.io/t/mqtt-api-specification-v1-4/19223/109

In the post they're talking about the Nuki firmware 4.1.8 but also with 4.2.8 today the issue persist and I wasn't able to find Nuki team to acknowledge an issue on their end :-)

This is how the debug log looks when receiving the data from Nuki (MQTT explorer subscribed as well, but result has the same issue here in opposite to mosquitto):

2024-04-25 18:55:29.888 - debug: mqtt.0 (517659) Server received "nuki/XXXXXXXX/lockActionEvent" (string): "\u0003\u0000䁠 \u0002"

2024-04-25 18:55:29.892 - debug: mqtt.0 (517659) stateChange mqtt.0.nuki.XXXXXXXX.lockActionEvent: {"val":"\u0003\u0000䁠 \u0002","ack":true,"ts":1714064129890,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1714055914114}

2024-04-25 18:55:29.892 - debug: mqtt.0 (517659) Client [mqtt-explorer-75839788] send to this client "nuki/XXXXXXXX/lockActionEvent": �䁠 �

It would be really great if you @Apollon77 could have another look into this. Please let me know if I can provide any additional information to help.

Thanks!

[danny030]

One more addition. Just came across a similar (same?) issue with MQTT of INSTAR cameras. On the screenshot left side the ioBroker MQTT adapter as client subscribed to Mosquitto and on the right hand side, MQTT Explorer connected to the same Mosquitto. See the values of polyx and polyy.

[Percy2Live]

@Apollon77 any chance to have a look at this? Is there anything else we can do to contribute to the solution?

[Apollon77]

No, not yet, sorry

[Percy2Live]

I don't want to be annoying, but this bug is present since a while without a fix in sight. As this is not a niche adapter but the only mqtt implementation, I'm quite sure a lot of people are interested in a fix.
I believe beside myself we have plenty of people in this thread alone who would be happy to assist with logs and testing, unfortunately we cannot solve this issue without the help of the adapter's developers.
Is there anything we can do to assist or speed up the implementation of a fix?

[danny030]

Maybe it's just the comma like mentioned here. The issue looks similar to ours.