MiBoxer WL-433 Gateway DPs questions and some info

[Silverstar]

I have two MiBoxer PW01 underwater (pool) lights which are controlled by a proprietary 433 MHz LoRa protocol.

There is one remote available as well as a gateway, WL-433, which features a DMX input as well as app control through the MiBoxer app, which uses tuya under the hood. However, as MiBoxer states, this device cannot be used with the tuya cloud platform, so I did not try that, but used their provided app.

Fortunately, the app freely tells me the device id and local key and some DP data when logging its debug output 😁 (with LogFox on android)

The gateway and remote support different zones, so I put one lamp into zone 1 and the other in 2, and I can control them individually or all together. Also, they support different modes / effects.

Now I was able to add it with local tuya as well as tuya local to home-assistant and I can control the lamps, but only all at once, not the individual zones and not the scenes / modes.

While digging deeper I found the packet capture parser here, which I fed with the pcap I obtained with pcapdroid.
As I can't use the tuya cloud, I had to figure out how to create the devices.json myself, sadly I found no example here and the snapshot.json is not in the same format. Here is my example for others to find:
[ { "name": "wl433", "id": "bf...xyz", "ip": "192.168.x.yz", "key": "xyz", "version": "3.3" } ]

There I found that the app sends some strings to a DP 101, which I could already see in the debug log, but I can't make any sense of it.

I hope someone here can point me in the right direction how to decrypt these data to enable me (and others having that device) to make full use of it.

parser_output_stripped.txt

I removed the device id and stripped it of duplicate and empty lines and just took a part of the whole log. I was opening the app, switching the lamps off and on and selecting different modes in different or all zones.

Can you help me decipher that?
Thank you in advance!

[uzlonewolf]

I'm glad my PCAP parser is getting some use :)

Fortunately it does not appear to be encrypted or anything, it's just base64 encoded. Unfortunately without knowing *exactly* what you were changing I have no way of figuring out how it packs the data.

Whole thing:

QwAAgAAAAAAAgIDD = 4300008000000000008080c3
RAAAAAABAAEACwFS = 4400000000010001000b0152
QwAAgAAAAAAAgIDD = 4300008000000000008080c3
SQAACwIAAQAAAIDX = 4900000b02000100000080d7
SQAACwIBAAEAAAFZ = 4900000b0201000100000159
QwAAgAAAAAAAgIDD = 4300008000000000008080c3
RAAAAAABAAEACwFS = 4400000000010001000b0152
QQAACwYBAAAAAIDT = 4100000b06010000000080d3
QgAAAAQBAAEACwFU = 4200000004010001000b0154
QQAACwYGAAAAAIDY = 4100000b06060000000080d8
QgAAAAIBAAEACwFS = 4200000002010001000b0152
QgAAAAIBAAEACwFS = 4200000002010001000b0152
QQAACwUBAAAAAIDS = 4100000b05010000000080d2
QgAAAAMBAAEACwFT = 4200000003010001000b0153
QQAACwYGAAAAAIDY = 4100000b06060000000080d8
RAAAAAIBAAEACwFU = 4400000002010001000b0154
QQAACwUBAAAAAYDT = 4100000b05010000000180d3
QQAACwYGAAAAAYDZ = 4100000b06060000000180d9
QgAAAAIBAAEACwFS = 4200000002010001000b0152
QQAACwUCAAAAAoDV = 4100000b05020000000280d5
QgAAAAQBAAEACwFU = 4200000004010001000b0154
QQAACwYGAAAAAoDa = 4100000b06060000000280da
QgAAAAIBAAEACwFS = 4200000002010001000b0152
QQAACwUDAAAAAIDU = 4100000b05030000000080d4

Only commands to the device:

QwAAgAAAAAAAgIDD = 4300008000000000008080c3
QwAAgAAAAAAAgIDD = 4300008000000000008080c3
SQAACwIAAQAAAIDX = 4900000b02000100000080d7
QwAAgAAAAAAAgIDD = 4300008000000000008080c3
QQAACwYBAAAAAIDT = 4100000b06010000000080d3
QQAACwYGAAAAAIDY = 4100000b06060000000080d8
QQAACwUBAAAAAIDS = 4100000b05010000000080d2
QQAACwYGAAAAAIDY = 4100000b06060000000080d8
QQAACwUBAAAAAYDT = 4100000b05010000000180d3
QQAACwYGAAAAAYDZ = 4100000b06060000000180d9
QQAACwUCAAAAAoDV = 4100000b05020000000280d5
QQAACwYGAAAAAoDa = 4100000b06060000000280da
QQAACwUDAAAAAIDU = 4100000b05030000000080d4

Only responses from the device:

RAAAAAABAAEACwFS = 4400000000010001000b0152
SQAACwIBAAEAAAFZ = 4900000b0201000100000159
RAAAAAABAAEACwFS = 4400000000010001000b0152
QgAAAAQBAAEACwFU = 4200000004010001000b0154
QgAAAAIBAAEACwFS = 4200000002010001000b0152
QgAAAAIBAAEACwFS = 4200000002010001000b0152
QgAAAAMBAAEACwFT = 4200000003010001000b0153
RAAAAAIBAAEACwFU = 4400000002010001000b0154
QgAAAAIBAAEACwFS = 4200000002010001000b0152
QgAAAAQBAAEACwFU = 4200000004010001000b0154
QgAAAAIBAAEACwFS = 4200000002010001000b0152

The only thing I can say for sure is that last byte is an 8-bit sum of the message.

[Silverstar]

Awesome, thank you!

I guess I wouldn't come up with base64. Is that common for tuya devices?
A friend has a tesvor vacuum which we "just" want to command to clean specific (defined) rooms instead of just auto run (and no path, area or map stuff), but with this device I got some progress first. Thanks to your tool!

I wanted to do some systematic captures as soon as I could make some sense out of the data, but I wanted to capture something first in case I could "just read it".
Now I can do!

I'll report back. I might need some pointing again...
Thank you!

[uzlonewolf]

Yep, base64 is pretty common on Tuya devices for variable-length binary data. Data needs to be encoded into text somehow since commands are sent in JSON and JSON does not allow binary data, and base64 is one of the more efficient ways of doing that. A few devices use hex strings, however that doubles the amount of data which needs to be sent and processed. Lots of AA's are a pretty good clue it's base64 since that's what long sequences of 0x00's packs into.

Feel free to post more if you get stuck, I'm pretty good at picking things apart :)