Hi, new here and fairly new to hab (but WOW its fantastic).
Setup is Ubuntu 14.04 LTS, OH 1.8 and current version of Serial binding (from repos)
Had to build the commands into a rule as there isnt a serial binding and I’m not a java etc coder (mainly embedded so having a UI is scary )
I’ve got a 2006/7 vintage Denon AV amp which has the RS232 interface, I’m using the serial binding to send the commands with great sucess, but I’d like to get feedback from the amp used in the hab system (to initialise/monitor things). Trouble is if you send an MV? (query on what the volume level is), you get a response almost instantly (seen on cutecom). This doesnt seem to be read into the system, or I’m doing something very wrong with it. I tried a simple text item in the sitemap using the serial item in the items file, but that only ever shows what went out, not whats come back.
One work around I thought of was wiring the RX line to another DB9 plug to drop that into the system via another serial port (gotta love an ebay cheapy 4 port serial card), and then read that with another item, but this seems overkill. A further massive overkill idea would be to create a Serial to MQTT bridge in python, but thats something I dont want to do unless I have to.
I guess in short I want to know if the event of sending a command is sort of blocking the system from reading or updating its read of the incoming serial buffer? and if so, is there a way around it other than the two crazy ones I’ve mentioned.
What are your Item binding configs? Have you adjusted the BAUD for that serial connection? It might be operating at a rate faster than the binding’s default 9600.
What is your Item config? Maybe it would make sense to have two Items, one that writes and the other that reads. It might be possible that the return comes too fast and OH is still trying to finish up its internal process for sending the command and is missing the incoming message.
I doubt you need to resort to hardware changes or an MQTT bridge. This should be workable with the existing serial binding.
I don’t understand this comment. You said you are using the Serial binding then say you aren’t? Maybe if you post your Items and Rules it will be more clear.
My bad.
I have a serial binding. What I should have typed was there isnt a Denon Serial binding (the proper Denon binding is IP based) so I built rules for sending the commands.
My Items entry:
String ampCtl “[%s]” (DenonAmplifier) { serial="/dev/ttyS5@9600" }
My rules Entry for one task: (note this is TX only. I did have it trying to read the ampCtl and update a test item but that was having none of it aside from showing the outgoing command)
rule “AVR Mute”
when
Item AVMute received command
then
if(receivedCommand==ON){
sendCommand(ampCtl, “MUON\r”)
}
if(receivedCommand==OFF){
sendCommand(ampCtl, “MUOFF\r”)
}
end
When I tested the commands in cutecom (the only acceptable terminal I could find for Ubuntu), the Amp sends a reply just about instantly after you send it a command (either a query or a control).
I’ve a sneaky feeling that OH will be sorting itself out with processes etc before the RX can be read.
My humble opinion is that making a second item that uses the same port wont help much either, but I’m willing to be proved wrong…
I think you might be wrong. I’d try it at least. I suspect the problem has more to do with OH sorting itself out then it has to do with a limitation of the binding.
If it doesn’t work I’d experiment with the baud. 9600 might just be too slow and the signal is missed.
ummmm the baud rate for the amp is 9600, thats how this kinda thing works…
I’ll add a second item and see what comes from that, but its staying at 9600 since thats the datasheet daud for the connection (its not something one can mess with )
That is what it is then. I’ve helped people in the past who was having problems because they were using the wrong baud which is why I brought it up. They never checked what the manufacturer says it should be. Clearly you have.
From looking at the code briefly a separate set of classes get instantiated for each Item you bind to which I believe means that they are running in separate threads. So even if the code that is processing the outgoing commands is still wrapped up in finishing when the response comes it it should not keep the other Item from reading the value. Unless it isn’t working quite like it appears at a first scan in which case all bets are off.
But I have to believe that this is not the first time someone has encountered an immediate response to a command and yours is the first posting I’ve seen seeing this error.
late night geeking
I made the log debug, and it IS showing that the feedback from the amp is coming in…
I’m now having idiot troubles showing the feedback in the sitemap.
Here is the Item
String AVStatus "[%s]"
Switch ampStat
Ive tried AVStatus.postUpdate(tester1) and all sorts… like I say, this kind of coding isnt my bag, I’m more a simple assembler and not OO C kinda chap lol
It is better to use Thread::sleep(msec) than a busy wait while loop to delay.
To get the state of an Item you need to call the .state method and, sometimes you need to cast the result (particularly when dealing with numbers). Since you are dealing with Strings a call to toString is all that is needed though.
var tester1 = ampCtl.state.toString
The postUpdate should work fine but I prefer to call the method on the Item wherever possible. It tends to work better with dealing with different types of inputs.
AVStatus.postUpdate(tester1)
So your entire code would collapse to:
Thread::sleep(10) // or however long you need it to sleep
AVStatus.postUpdate(ampCtl.state.toString)
Rich, you fine gent
That solved my issue a treat, seems it needs a sleep of atleast 200 to catch the amp reply. Now I can build on that and make a sensible looking control for it.
Many Thanks again
)