RS485 Sending HEX bytes issue RPi

Hi all,

I’m new to OH and to this forum, thanks in advance for any help you can offer.

This issue has been bugging me for quite a long time now. I’ve read many of the good articles here, but none of them have fixed the issue for me.

I’m running OH 2.5.2 on a RPi 3. Whether relevant or not - I also have a zwave board attached.

Essentially, I change the switch item, the rule fires and I see the USB device TX light flash. I’ve connected my laptop and using realterm I see info arrive. However, the HEX string that arrives is not the sequence I’m expecting from the set below.
If I connect my laptop to the projector screen and send the HEX codes, it works fine, so I’m happy I’ve got the right pin-outs etc.
I’m guessing it’s something to do with encoding. I’ve tried loading the ISO-8859-1 coding in openhabian-config, i’ve tried setting BASE64, i’ve tried using a BASE64 encoded string, and all of the permutations I can think of…

I’ll kick myself if it’s something obvious, but at this stage I really don’t care if it is :slight_smile:

Any pointers or suggestions gratefully received!

I have followed this article:

My configuration looks like this:
/etc/udev/rules.d/99-usb-serial.rules
SUBSYSTEM==“tty”, ATTRS{idVendor}==“0403”, ATTRS{idProduct}==“6001”, SYMLINK+=“ttyUSB-rs485”, GROUP=“dialout”, MODE=“0666”

/etc/default/openhab2
EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB-rs485"

/items/projectorscreen.items
Switch ProjectorScreen “Projector Screen”
String ProjectorScreenRS485 “Projector Screen Control” { serial="/dev/ttyUSB-rs485@2400,CHARSET(ISO-8859-1),BASE64" }

/rules/projectorscreen.rules
rule “Screen_Down”
when
Item ProjectorScreen changed from OFF to ON
then
sendCommand(ProjectorScreenRS485,’\u00FF\u00EE\u00EE\u00EE\u00EE’)
logInfo(“ProjectorScreen”, “Projector Screen Down”)
end

rule “Screen_Up”
when
Item ProjectorScreen changed from ON to OFF
then
sendCommand(ProjectorScreenRS485,’\u00EE\u00EE\u00EE\u00EE\u00DD’)
logInfo(“ProjectorScreen”, “Projector Screen Up”)
end

afaik you can’t choose the device names free, instead you have to use ttyUSB0… ttyUSB9 or something similar.

Thanks Udo, I originally tried using ttyUSB0 but figured that the udev links are working okay as I do see some output from the USB device.
I’ll give this a go again to see if it makes any difference.
Cheers!

Unfortunately that didn’t solve the problem. Thanks for the idea though.

It might be helpful to know what that is

Good call - I should have included that on OP.

So, for my projector screen down rule:
sendCommand(ProjectorScreenRS485,’\u00FF\u00EE\u00EE\u00EE\u00EE’)
I receive: 00 84 84 84 04
The log says: ProjectorScreenRS485 changed from ÿîîîÝ to ÿîîîî

For my project screen up rule:
sendCommand(ProjectorScreenRS485,’\u00FF\u00EE\u00EE\u00EE\u00DD’)
I receive: 00 84 84 84 04
The log says: ProjectorScreenRS485 changed from ÿîîîî to ÿîîîÝ

Thanks for looking at this with me, much appreciated!

I’m gonna guess your RS485 wires are swapped A/B ?
I’m basing that on correct character count and bitwise inversion of FF to 00

Probably should have said - for testing the output etc I’ve been using an RS232 FTDI USB device. I only have 1 RS485, so use the RS232 for testing on my laptop. I figured if the chars are being sent correctly on RS232 it would work when I swap out for RS485 (with reboot). I haven’t done much with RS485 before btw.
PS - thanks for your help!

I’ve also only just noticed that the received bits are the same doing that test, even though the string in the rules is different. I just checked for typos etc and all looks fine.

When the bitstream is inverted, the UART picks out the wrong bits for a start bit, so you never get true character inversion, and will not get a consistent uh “translation”.
That’s to say, I’m not surprised :wink:

Because you seem to get the expected character count, I’d be fairly confident that the character mapping is good - you clearly are not getting the raw string characters or escape characters etc.
It’s going to be something stupid like polarity or parity. (serial binding lacks the means to choose that)

I’d get a cheapo USB-RS485 dongle for your laptop bag, they cost little.

Good idea - I’ll order another RS485 dongle.

With RS232 each side though, should I see the correct stream? I’ve basically just got the GND/TX picked off the FTDI RS232 jobby and have hooked that upto another USB RS232 on my laptop.
The RS232 dongle i’m using is: https://www.amazon.co.uk/gp/product/B07BBPX8B8/ref=ppx_yo_dt_b_asin_title_o08_s00?ie=UTF8&psc=1
And the RS485: https://uk.farnell.com/ftdi/usb-rs485-we-1800-bt/cable-usb-rs485-serial-converter/dp/1740357

I don’t know. From memory, “TTL” RS232 is inverted compared with “real” RS232 lines. TTL “low” = 0/space RS232 “low” = 1/mark (so that a disconnected line is a continuous mark/stopbit)

Edit - yes, so-called TTL RS232 is inverted compared to proper RS232
https://www.sparkfun.com/tutorials/215

A haaa! That’s good info, thanks very much. I’ll look into that.
You sound like you have great knowledge on the subject - does my items and rules look correct to you with respect to the charset and base64 etc?
Thanks so much, this has been driving me crazy :slight_smile:

That I am not sure of at all, but looks reasonable. If it was messed up I do not think you would get a packet of five characters, but something different.

I are a enjineer.
I have a lifetime of nowadays useless experience as a mainframe field service engineer, and that ropes in a lot of weird mechanical, electrical, electronic and programming knowledge. I can mend a Teletype or a hydraulic actuator, and could maybe produce some Fortran with a little refresher!

Our job required the flair, if you will, to diagnose systems too complex to fully understand from end to end. In a commercial environment, with objective to fix fast for customer and cheaply for employer, not fully analyse fault. Bit like a doctor, I suppose.

Lessons learnt -
Observe/measure everything you can - clues turn up.
Divide and conquer. (“It’s all broke. Well, does this part work?”)
RTFM, but selectively when you need it.
Trust your gut (your experience counts, even when you’ve forgotten why)
Run it past a colleague (their experience counts)

1 Like