Open calle2010 opened 1 week ago
Hi! You're encountering an issue where --format binary
isn't being properly handled when writing to .netp
file. Here's a temporary solution using MQTTX CLI's pipeline capabilities:
./mqttx-cli-macos-x64 sub -h 192.168.xxx.xxx -t home/ew10/state --output-mode clean | jq -r '.packet.payload.data | join(",")' | xxd -r -p > ew10.netp
This command:
The root cause is likely that the system doesn't recognize .netp
as a binary format extension.
Interesting. I’d never expected the file extension to make a difference. Specifying format binary should eliminate all guessing done by the tool.
I don’t even know if netp is a well known extension. I just picked it because it was used in the device I wanted to monitor.
Yes, perhaps we will reverse the --format binary
logic, so only when utf-8 is specified will it be displayed as text file data. Everything else should be treated as binary.
What did I do
I try to read binary data from a channel and save it with "--file-write".
./mqttx-cli-macos-x64 sub -h 192.168.xxx.xxx --format binary --output-mode clean --file-write ew10.netp -t home/ew10/state >ew10.json
What happened
The output in "ew10.netp" contains extraneous bytes and doesn't match the clean output in "ew10.json", which has the correct data:
Expected
It is expected that the binary output has the bytes that can be found in the clean output.
Environment
More detail
It seems to me that there is a conversion going on and somehow the binary data is interpreted as UTF-8, which fails. Any non-UTF-8-compliant byte sequences would be replaced with
ef bf bd
. This sequence can be found multiple times in the output.Other "ASCII compatible" byte sequences like "00 00 00 04" or "01 01 07" can be found in the output.