Sounds like it is plain old serial over RS485… This is the response I got from the installer…
No it’s just running straight UART with baud rate 9600. Modbus is a specific communication protocol but we didn’t make it use that as that would become all sorts of complicated to implement, so the communication protocol is like I outlined in my previous email. The serial communication settings should be 9600 baud rate (asynchronous communication), 8-bit, no parity, 1 stop bit, no flow control (you will only be reading the data output by the fan anyway). If you use a simple program like RealTerm and a RS485 to USB converter, you should be able to see the fan output coming into your computer so you can get an idea of what kind of data you are receiving.
Stuck with reading a serial stream then.
USB/RS485 hardware is cheap for a direct connection; RS485 cabling can go a loooong distance; openHAB serial binding is rather basic but a rule or two should be able to extract the data.
I have used rs485 with openhab before and yes a USB to rs-485 converter that works in Linux is all you need. You have to parse the serial data yourself.
I’m planing on making a binding to interface to my rs485 devices so if you pm me a copy of your devices packets I can look to include an easier way to parse it in my binding.
Hey, I’ve got some stuff coming into OpenHAB and can see this in the logs…
2019-06-23 14:30:30.412 [vent.ItemStateChangedEvent] - Serial01 changed from S
PTaHIVM to S
PTHIVM
I suspect there are some special characters in there or something…
This is some context I got from the person who supllied me the fan…
If you want to see what kind of data you are receiving yourself, I would suggest selecting the “display as: Hex + ASCII” option if I remember correctly, but I would just try a few different options and see what it does. You should be getting data in the form of a string of 13 characters like “S15P2T185H63V3M0” (speed = 15%, phase = ADJUST, temp = 18.5, hum = 63%, vent rate = HIGH, summer mode = 0) but getting it to show it like that might be tricky.
So it looks like I have all the Alpha characters to indicate the bits of data but the actual values are encoded in such a way as that I can’t read them. I’ll read some more and see if I can figure anything further out…
When I tell the serial binding to encode it in BASE64 I get this…
UwxQAlQQAEhIVgFNAQ==
Yuck what a pain and it does not have any kind of device ID number in case you own multiple fans so it will mean a new serial port for every device so you know which device is sending the data. I would convert to using pure HEX and then simply learn what the hex for S is by using this
Here are some tips, set the serial binding to use ‘ISO-8859-1’ charset otherwise the conversion to HEX will not be correct and will confuse you. I believe the binding now allows you to set the charset as an option, have not used it since it was changed (?) so the following post may need to be adapted slightly. Note the post was made in 2015 so if you work it out be sure to post what works to help others.
Yes that was nice of them and the static characters will actually help you identify when you have a good packet since there is no Id. My last post had some example for you to get it working with hex if the binding has not changed too much. You don’t need rules to receive the hex but you will for the parsing of the incoming data. This is why I am going to write a binding that allows more flexible and easier setup for this kind of thing. It will probably be a few months before I get the time to do it.
Great news that you now have it sorted. Can you post what info you needed to know in order to get it working and mark the post as the solution to help others that search the forum?
That the part of the stream represents temp = 15.0 I guess??
What a nasty encoding! But you can use it.
I guess the simplest way would be something like myTempItem.postUpdate( byte(nn).toString + "." + byte(nn+1).toString )
Well it’s just an example, you’d use the 6th and 7th bytes in the stream.
The object was to convert X and Y numeric values to a single decimal X.Y , which isn’t quite as easy at it looks.
The cheat way is to make a string out of it.
Yeah I’m pretty clueless when it comes to coding so don’t assume I know anything "-)
Below is the rule I have so far using the sample you provided to log the full DECIMAL. I’ve added an extra line to try to add some more logging and display the fan speed which is supposed to be the 2nd value.
rule "display serial packet"
when
Item Serial01 changed
then
var bytesarray = Serial01.state.toString.getBytes()
val StringBuilder decdisplay = new StringBuilder
bytesarray.forEach[b |
var int x = b.intValue.bitwiseAnd(255) // this converts -128 to 127 to 0 to 255
decdisplay.append(Integer::toString(x) + " ")
]
logInfo("Serial test", "decimal bytes " + decdisplay)
logInfo("Serial test", "Fan Speed " + bytesarray(2).toString)
end
FAIL
Rule ‘display serial packet’: The name ‘bytesarray’ cannot be resolved to an item or type
One possibility is to use new tranformation service available in 2.5 called Binary To JSON Transformation Service. This service can be used to transform binary data to json format. Then you can use e.g json path tranformation to extract different information to items.
The output of getBytes() is some kind of java array we don’t often use in rules.
I think maybe you get a member with bytesarray.get(7)
EDIT - this should do the un-signing part. It looks like you don’t expect byte values above 127 and so not risking misinterpreting as negative values, but it might be smart to avoid surprises. bytesarray.get(5).bitwiseAnd(255).
On the other hand … what happen with a negative temperature? Maybe you do need to take account of negatives. You need a sample of how they get encoded really.
When you get a byte that way, it might be a primitive integer and not have a .toString method. You may have to parse it into something more amenable.
Maybe a java programmer can suggest a neat method here.
