\u00fe and \u00ff are being transformed to 3f

Setup, Configuration and Use Scripts & Rules
, ,
1

In OH2.4 \u00fe and \u00ff are being transformed to hex: 3f

I have a transform file racklink.map

login=\u00fe\u0010\u0000\u0002\u0001\u0075\u0073\u0065\u0072\u0007c\u006d\u0076\u0078\u006b\u0077\u0068\u0078\u0061\u004a\u00ff
OFF=\u00fe\u0009\u0000\u0020\u0001\u0002\u0000“0000”\u006a\u00ff

and item

String powerctl "RLNK-415R" { tcp=">[*:10.47.0.50:34000:'MAP(racklink.map)']"}

I captured what Openhab is sending with Wireshark. When I send login command to powerctl, OH is sending hex: 3f100002017573657207636d76786b776878614a3f, when it should start with fe and end with ff

When I send OFF command to powerctl OH sends hex: 3f0900200102003f303030303f6a3f, when it should start with fe and end with ff

Uh, okay. Is this a bug or am I missing something here?

2

0x3f is a question mark, which is the replacement character.

You’ll also see it for the garbage quotes:

3

I agree 0x3f is a question mark, but what I posted is a hex dump of the TCP payload, not ASCII.

I would expect to see the payload start with fe and end with ff

4

The point was that whatever is loading the map file is trying to convert the characters into some encoding. Whatever those two are, it’s treating all of the values referenced as unsupported characters and replacing them with the replacement character.

This post says the expected encoding is ISO-8859-1.

5

I got hit with that once a while back when sending hex via the serial binding. You can read the fix which is to use the iso charset that namraccr posted.

6

@namraccr, thanks for the info! I’ll have to try that next time.