This page last changed on Oct 08, 2010 by juha.


I'm trying to get my Onkyo Amp set-up using TCP<->Serial converter (Software) so i could test out the Status commands.

The commands are simple enough.



However the AMP reponse has a /EOF control character



Net result is i can't match to the reponse (!1PWRON[square]) as the UI designer only expects displayable characters.

I'm no programmer but I found a regex filter for control characters that if added to the TCPSocketCommand reply() would be enough to remove this issue for me, I have no idea what it would do to ayone else. I'm affraid I don't know how to use SVN to suggest changes nor do have a IDE for Java I still new to this so any suggestions on what tools to use read etc welcome (OSX 10.8.5) Did some C# and FORTRAN many moons ago. Would love to be able to contribute more.

Maybe there are other TCP<-> serial users with similar control character issues ?

Should this be a seperate protocol or just a change to the TCPsocket one ?

My best guess at the code would be something like..import java.util.regex.*;

| | @Override |
| | public String read(EnumSensorType sensoryType, Map<String, String> stateMap) { 
| | String rawResult = requestSocket();
| |String rawResult2 = null;
| |
| |Pattern p = Pattern.compile("\\p{Cntrl}");
| |Matcher m = p.matcher(rawResult);
| |String rawResult2 = m.replaceAll(""); 
| |
| | if ("".equals(rawResult2)) { 
| | return UNKNOWN_STATUS; 
| | } 
| | for (String state : stateMap.keySet()) { 
| | if (rawResult2.equals(stateMap.get(state))) { 
| | return state; 
| | } 
| | } 
| | return rawResult2;

Any takers to point me in the right direction.



First, you've got impressively far.

Second, your idea is exactly right. Thanks for posting it, it's a quick solution for many generic (HTTP, TPC) protocol status update needs.

Don't worry about SVN too much, you can figure it out later. Simple diff will do, I will apply it on your behalf.

This will solve other issues too, including Pierce's Yamaha HTTP API.

If you want to keep trying to get a Java implementation to compile (command line tools are fine, if you have a good text editor, IDE you can worry about later, they take time to learn).

If not, let me know too. The idea is simple enough (and good), I can add it, you already showed enough detail.

If you want to build it as a generic solution, the regex expression should be an additional parameter in the *Builder implementation so it can be parsed from controller.xml and changed per implementation. If you hard code it will obviously be specific to your device and should be a separate protocol.

Bottom line, let me know if you're still itching to work on finishing it (and claim further fame and glory) or if you prefer to hand it over...

Posted by juha at Oct 08, 2010 17:13

Cool, glad I can help.

"Simple Diff wil do" ... if only I knew what  Diff was and how to create on...

OK for now I'll just stick to notepad, I downloaded eclipse some time back with the intention of learning, but it's far to complex for me to understand and the IDE curve is a bit steep. ho hum.

Generic solution.. jess didn't even think of that, as for claiming the glory, I happly hand over to someone who knows what they're doing on the basis that it'll actually it done !

Over to you Juha.


Posted by flipit at Oct 08, 2010 17:40


OK after having no time to learn this before, I finally sat down at the weekend and figured this out. Added the regex to remove control characters from the response words on tcp/ip sockets.

Certainly allows me to specify Name/Value pairs and display Names like On / Off instead of the ASCII Value command words !1PWR01 / !PWR00. Switch works well.

Next to get this working on a Slider using Name/Value pairs to convince the Slider is a Level/Range

Where do I post the patch file?


Posted by flipit at Dec 06, 2010 13:04


Feel free to post patch here, unless it is too long in which case email directly to me : juha at openremote org

Also, let me know by email if you already agreed on the OpenRemote Contributor Agreement (legal click through on the website we require from all contributors to include code into the codebase). If not, I will send you the details over email.

Thanks for taking the time and effort – sorry for taking so long to get back on this (it was still on my list, just was getting pushed down).

Posted by juha at Dec 07, 2010 08:53


this sounds great. The socket implementation was still missing support for control characters.

Posted by mredeker at Dec 07, 2010 09:17


Email on it's way.

One thing I have noticed now though is there doesn't seem to be a way to differentiate sensors that are polling different actions on the same TCP/IP socket.

Example: Custom Name/Value Power On Sensor linked to a label and a Custom Name/Value Volume Sensor linked to another label.  Both lables display responses from both sensors since they are polling the same socket, but looking for different Name/Value pairs. The default seems to be if a Name/Value match isn't found just to return the Control Word.. need to work on that i think.

A way for a sensor to ignore a control word not listed in the Name/Value pair..

Maybe a another patch to follow.. who knows.


Posted by flipit at Dec 07, 2010 14:02

Hmm I see.

I need to start building unit tests for this so we can at least document the behavior somehow. And also to ensure we don't regress moving forwards.

Not sure if the default behavior is ideal. Would be excited to receive another patch Marcus may also have ideas how the implementation should work – he's using the TCP/IP quite a lot I think.

Posted by juha at Dec 08, 2010 08:03

OK. I lied about the switch. It doesn't work, but I think I know why.

The Sensor is defined as a Custom type. It has Name/Value Pairs:

on : !1ZPW01

off : !1ZPW00

I was expecting the REST reponse for the sensor to show the Name so that it acts in the same way as a Boolean type, however the REST status shows the Value:

<openremote xsi:schemaLocation="">
<status id="263">!1ZPW00</status>

Can anybody (Juha) point me to the code that sets the REST stauts this so I can patch this to Name, can't seem to locate it !



Posted by flipit at Dec 08, 2010 09:28

Think what we'll probably want to do is add two properties in the TCP/IP protocol configuration (XML) on the designer:

  • Switch regexp
  • Level/Range regexp

And use those in the TCP protocol implementation based on the sensor type that has been configured (EnumSensorType).

That way both regular switch and slider functionality should work, you won't need 'custom' sensor for a regular two-state switch, and we can isolate the changes within the protocol implementation.

The two properties can be parsed in the * implementation and passed onto the commands.

Does that make sense to you?

I will apply your control character strip patch, let me know if you want to dig into this deeper.

Posted by juha at Dec 08, 2010 13:33

Your patch to strip control characters from the return values has been applied to Subversion and will be included in the next developer release (alpha 12) of the controller.

Thanks for your contribution!

Posted by admin at Dec 09, 2010 10:22


I know this is an old thread but this is a subject of interest for me right now. I am interfacing with pulseaudio and MPD as part of a multiroom audio project, both have telnet interfaces that I can successfully send commands to so the next step is reading status data back to update the panel UI (things such as volume, current song).

Both pulseaudio and MPD have 'messy' telnet command responses in that lots of text is returned and there is a need to 'filter' out the required data. I definitely think that the way forward is to use the generic telnet protocol rather than custom protocols with hard coded response filtering. The discussion above regarding the use of regexp seems like a great way of filtering response data but looking through the source code I can't see any reference to regexp in any of the protocols.

I might be missing something but it seems that the read method of the TelnetCommand class hasn't yet been implemented at all. I'd appreciate it if you could bring me up to speed on this and then if I can I am more than willing to help out in implementing a solution.

This is a great bit of work so far and the potential is huge! Ideally I'd like to make this the cornerstone of my home automation control, I see dynamic panel controls and controller scheduling as musts (MisterHouse would be a thing of the past then!) and the M-V-C principal of your architecture is fantastic (I see some similarities with Microsoft's WPF form technology and I'm sure some of the principles could help with the dynamic controls).

I'm getting a bit carried away now and would happily settle for getting the status reading working for the time being!

Many thanks and good work.

Posted by kurrazyman at Jan 17, 2011 22:27
Document generated by Confluence on Jun 05, 2016 09:31