fis issue with nogo areas nomop areas

[dkneisz]

When I added nogo areas to my map (I have a Roborock Qrevo Master) I got the following error:

2024-08-03T16:44:18.179+02:00  INFO 749731 --- [all: rrb_SzUs2l] d.k.r.remote.mqtt.RoborockMqtt           : Lambda: New message for topic 'rr/m/o/4EUZXHZXIzF8TWaCO6eXNn/5bd9676a/3nuRxpUimbqlq0IGJdJzGU' 0
2024-08-03T16:44:18.185+02:00 ERROR 749731 --- [all: rrb_SzUs2l] d.k.r.remote.mqtt.RoborockMqtt           : Error while handling message from topic rr/m/o/4EUZXHZXIzF8TWaCO6eXNn/5bd9676a/3nuRxpUimbqlq0IGJdJzGU

java.lang.IndexOutOfBoundsException: null
        at java.base/java.nio.Buffer.checkIndex(Buffer.java:749) ~[na:na]
        at java.base/java.nio.HeapByteBuffer.getShort(HeapByteBuffer.java:387) ~[na:na]
        at de.konqi.roborockbridge.remote.mqtt.map.dto.MapDataAreaVertices$Companion.fromRaw(MapDataArea.kt:21) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.map.dto.MapDataArea$Companion.fromMapDataSection(MapDataArea.kt:42) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.map.MapDataPayload$Companion.fromRawBytes(MapDataPayload.kt:54) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.map.Protocol301$Companion.decryptAndDecode(MapDataWrapper.kt:40) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.map.Protocol301$Companion.access$decryptAndDecode(MapDataWrapper.kt:24) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.map.Protocol301.<init>(MapDataWrapper.kt:22) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.map.Protocol301Binary.decryptAndDecode(MapDataWrapper.kt:50) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.MessageDecoder.readProtocol301Body(MessageDecoder.kt:167) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.MessageDecoder.decode(MessageDecoder.kt:90) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.RoborockMqtt.handleMessage(RoborockMqtt.kt:167) ~[!/:0.0.7-SNAPSHOT]
        at de.konqi.roborockbridge.remote.mqtt.RoborockMqtt.subscribe$lambda$3(RoborockMqtt.kt:159) ~[!/:0.0.7-SNAPSHOT]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.deliverMessage(CommsCallback.java:511) ~[org.eclipse.paho.client.mqttv3-1.2.5.jar!/:na]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.handleMessage(CommsCallback.java:417) ~[org.eclipse.paho.client.mqttv3-1.2.5.jar!/:na]
        at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:214) ~[org.eclipse.paho.client.mqttv3-1.2.5.jar!/:na]
        at java.base/java.lang.Thread.run(Thread.java:840) ~[na:na]

The issue here was, that MapDataAreaVertices expects 4 coordinates for each area, while it was called like this:

MapDataAreaVertices.fromRaw(data.body.slice(index * 8, 8).order(ByteOrder.LITTLE_ENDIAN))

Since here only 8 bytes are extracted and passed, only 2 coordinates are available. To fix this I sliced the data with 16 bytes to get the third and the fourth. As this was never used when publishing I added it there tool

[dkneisz]

I ran into issues with state updates. Turns out, the last commit 354a065 caused this. When setting "org.springframework.boot" back to "3.2.5" in build.gradles.kts everything is working again.

[konqi]

Any chance you can provide a payload to create a test?

[dkneisz]

Sure, I also added the tests now. The payloads look something like this (for both):
[[[323.72,249.24],[323.72,270.24],[383.88,270.24],[383.88,249.24]],[[315.64,238.8],[315.64,256.86],[352.22,256.86],[352.22,238.8]],[[360.2,239.46],[360.2,264.46],[385.2,264.46],[385.2,239.46]]]

One additional note, that is not directly related to this topic:
As I mentioned when using a higher version than "3.2.5" for "org.springframework.boot" I did not get any update for the states. I thought I got it fixed by removing the second parameter when calling publishDeviceStatus(message.deviceId) in "BridgeService.kt" (line 173). Then I did get updates when requesting state updates, but I did not get all properties, just a handfull. I was not able to find out why that's the case, maybe you have an idea (but maybe that should be another topic, because it has nothing to do with this).

[konqi]

Thanks.
Regarding the spring boot version I'll have to check the changelog. Since there is another pending update to spring boot this might also be a regression thing and go away with the next update. Of course it would be best if, I had a test that can reproduce the issue.