Probably a stupid question:
I have the impression that the payload in the webhook is different :
I get :
“MjEuNjLCsEMxMDI0LjA2aFBh”
This is clearly not HEX.
Probably a stupid question:
I have the impression that the payload in the webhook is different :
I get :
“MjEuNjLCsEMxMDI0LjA2aFBh”
This is clearly not HEX.
It’s base64.
echo -en "MjEuNjLCsEMxMDI0LjA2aFBh" | base64 -d | hexdump -C
00000000 32 31 2e 36 32 c2 b0 43 31 30 32 34 2e 30 36 68 |21.62..C1024.06h|
00000010 50 61 |Pa|
This indicates that you are using an innapropriately inefficient payload encoding.
Do not send numeric values as ascii characters, send them as numeric values using only as many bytes (or ideally bits) per field as strictly necessary for the range.
Do not send units as ASCII abbreviations, units should be managed entirely out of band by knowing the payload format of a given node
Thanks
I’m fully aware that the encoding is not for production.
The encoding/decoding is not on the critical path and is something rather straightforward.
These things tend to not get fixed and are substantially easier to do it right first time. As such we are really allergic to text based payloads. See this for a mini-how-to:
Hi
This is a test setup.
My plan is to send not that often, send quite some measurements and use about 4bits for pressure and 4 bits for temperature for relative changes. same, up to 7 up, up to 7 down and an escape code (with than another 4 bits or 8 bits).
Plans rarely withstand contact with reality.
We can’t do much about it, but as a matter of protocol / policy, we don’t support bad practise on the community network so you’ll have to make your own way.