Error in rest service when serial port sends STX ACK EOT bytes

I’ve connected a serial port device to OpenHAB (using the serial port binding) which sends STX ACK and EOT bytes. This generates the following error in the rest service e.g. when calling or even when calling

error on line 1 at column 130: PCDATA invalid Char value 2

What would be the proper way to solve this problem?
I think the rest service should encode this in XML as CDATA value.

The REST services don’t use XML, just text.

This is not correct. This is what happens when I respond without double checking. I do all my REST stuff using http GETs on the https://server:port/CMD address which does not return encoded (XML or JSON) values. But I still think my suggestion about implementing a proxy to encode the troublesome byte values to ASCII may still be valid.

You may need to write a proxy that receives data from REST and a rule that triggers to convert the text to bytes and send it to your serial Item.

Well it seems like there’s some code here somewhere that’s treating either the incoming data or the regex as xml and rejecting it as invalid. But without a stack trace, I don’t know where to begin looking…

The output from the rest URIs is certainly xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><item><type>GroupItem</type><name>gGF</name><state>Undefined</state><link></link>

So since the serial binding is sending characters that are illegal in XML 1.0, this should be where the error is coming from. The question is, should the server be using XML 1.1 instead so that these characters are allowed?

Sadly I cannot provide a call stack because the error is not logged. I already tried starting openhab in debug mode, but still no stack trace. If you can tell me which logger I have to configure to the the callstack I will post it here.

In the meantime I’m experimenting with the serial binding. My idea is to work with Base64 so the data will always be saved as text and I just have to decode it in my rule.

I’ve now modified the serial binding to use base64 internally and now the error is gone. I’ve already uploaded a pull request for my change:

Just to be clear, the REST services (in OH1) respond with either XML or JSON - depending on how they are called. Of course, both XML and JSON are text, so this is partly correct :smile: