This page last changed on Apr 05, 2013 by renatoriolino.

Hi all,

I have a home automation built by myself and now I'm looking for a software to controls it. That's why I'm here.

I found that the easiest way to make my automation works with OR is using telnet, as I already have a working telnet host that I can use to get the status and turn on/off all lamps of my home.

I have some doubts about how the OR telnet works. I followed the telnet how to, but it's not working as I expected.

The STATUS command that is not working is configured as follow:

Command: null|STATUS COZINHA
Read Timeout: 1
Read Regex Filter: blank
Read Regex Group: blank
Default Read Response: blank
Polling Interval: 1s

Looking at the debug terminal of my telnet server, I am receiving correctly the string "STATUS COZINHA" every 1 sec as expected. This command respond the following bytes:

6F 6E 0 (aka "on").

But on my android the sensor is still "off".

My doubts are:

1- Which string does OR telnet expect from a sensor in the "off" and "on" state?
2- Does the string needs to be NULL terminated? Line-break terminated? return feed terminated?

Well, I think that's it for now.

Btw, running OR Controller 2.0.2 on Linux and Panel on Android (latest one available at Play Store).

Thanks

Renato

I've tryied to use regex without success.

My sensor on controller.xml:

<command id="57" protocol="telnet">
<property name="port" value="12345"/>
<property name="statusDefault" value="off"/>
<property name="command" value="null|STATUS COZINHA"/>
<property name="statusFilter" value="on|off"/>
<property name="pollingInterval" value="1s"/>
<property name="statusFilterGroup" value="0"/>
<property name="timeout" value="1"/>
<property name="ipAddress" value="localhost"/>
<property name="name" value="CMD_COZINHA_STATUS"/>
</command>

The output of the command STATUS COZINHA is always "on" or "off" (without quotes).

On dev.log I got:

2013-04-05 14:41:00,452 ERROR [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: Telnet Read Status: No 
Match using Regex: 'on|off' on response from command 'null|STATUS COZINHA'
2013-04-05 14:41:00,453 WARN [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: Event producer bound 
to sensor (ID = 58) returned a value that is not consistent with sensor's datatype : off  setting sensor 
value to 'N/A'

The sensor on controller.xml is:

<sensor id="58" name="SENSOR_COZINHA" type="switch">
<include type="command" ref="57"/>
<state name="on"/>
<state name="off"/>
</sensor>

Posted by renatoriolino at Apr 05, 2013 19:24

Setting a default read response, this is what I got (when the sensor is "on" and default response is "off"):

2013-04-05 15:29:18,277 INFO [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: received: on
2013-04-05 15:29:18,277 ERROR [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: Telnet Read Status: 
No Match using Regex: 'on|off' on response from command 'null|STATUS COZINHA'
2013-04-05 15:29:18,277 TRACE [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: Processed off, received off
Posted by renatoriolino at Apr 05, 2013 19:30

One more thing (and possible the cause of the problem), here what I found on xml-parser.log:

DEBUG 2013-04-05 15:51:26,929 (XML): A switch sensor (Name = 'SENSOR_COZINHA', ID = 58) has an incomplete <state> element mapping, the value attribute is missing in <state name = on/>.
DEBUG 2013-04-05 15:51:26,929 (XML): A switch sensor (Name = 'SENSOR_COZINHA', ID = 58) has an incomplete <state> element mapping, the value attribute is missing in <state name = off/>.

But my controller.xml has both state name = on and off:

<sensor id="58" name="SENSOR_COZINHA" type="switch">
<include type="command" ref="57"/>
<state name="on"/>
<state name="off"/>
</sensor>

Anyone?

Posted by renatoriolino at Apr 05, 2013 19:53

The last one is just a debug statement caused by an incorrect XML generated by the designer tool. The controller reads your sensor snippet just fine though, the message exists just to note the inconsistency (there should be a value attribute next to the name attributes).

Posted by juha at Apr 06, 2013 08:09

On dev.log I got:

2013-04-05 14:41:00,453 WARN [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: Event producer bound
to sensor (ID = 58) returned a value that is not consistent with sensor's datatype : off setting sensor
value to 'N/A'

This looks like it might be the root of the problem. I should add double quotes around the value that is being ignored but from the output that you posted (unless you changed it) it looks like there's an extra space after the 'off' – so might be 'off ' instead which would fail string matching.

Also should add automatic trimming on our side to remove white space.

It might be an issue with the last zero byte in your stream. Unlike C, Java doesn't expect strings to end with a zero byte, and it may be adding it to the string it is attempting to match.

Posted by juha at Apr 06, 2013 08:21

Juha, I've changed my telnet server to not send the end of string with a zero byte and I tryed to change the regext too, but didn't work.

My STATUS COMMAND new is:

<command id="57" protocol="telnet">
<property name="port" value="12345"/>
<property name="statusDefault" value="off"/>
<property name="command" value="null|STATUS COZINHA"/>
<property name="pollingInterval" value="3s"/>
<property name="statusFilter" value="^.(on|off).$"/>
<property name="statusFilterGroup" value="1"/>
<property name="timeout" value="3"/>
<property name="ipAddress" value="localhost"/>
<property name="name" value="CMD_COZINHA_STATUS"/>
</command>

My telnet server output log is:

selectserver: new connection from ::ffff:127.0.0.1 on socket 4
recv: STATUS COZINHA
reply: 6F 6E (2 bytes)
selectserver: socket 4 hung up

And dev.log is:

2013-04-06 09:49:56,231 INFO [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: 
send: STATUS COZINHA
2013-04-06 09:49:57,236 INFO [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: 
received: on
2013-04-06 09:49:57,238 ERROR [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: 
Telnet Read Status: No Match using Regex: '^.*(on|off).*$' on response from command 
'null|STATUS COZINHA'
2013-04-06 09:49:57,238 TRACE [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: 
Processed off, received off

Any ideas? I have no experience with java or regex. I tested '^.(on|off).$' on the regex test page and at least there it correctly extract the on OR off string to group(1).

Thanks

Posted by renatoriolino at Apr 06, 2013 13:55

So the warning is gone, yes or no?

Event producer bound
to sensor (ID = 58) returned a value that is not consistent with sensor's datatype : off setting sensor
value to 'N/A'

Because what you are describing now sounds like a different issue with regexp.

Posted by juha at Apr 06, 2013 14:12

If your implementation is simply returning two strings either 'on' or 'off' you should not need to define a regular expression, those two strings are valid as is.

Posted by juha at Apr 06, 2013 14:17

Yes, the warning is gone now after a stopped sending the zero at the end of string.

I removed the regexp and the read regexp group, but still not working. Here'se the dev.log now:

2013-04-06 10:47:27,108 INFO [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: send: STATUS COZINHA
2013-04-06 10:47:28,110 INFO [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: received: on
2013-04-06 10:47:28,110 TRACE [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: Processed off, received off

If I remove the "off" from the default read response, it doesn't change anything.

Thanks

Posted by renatoriolino at Apr 06, 2013 14:51

Juha, my telnet server is now sending only the strings 'on' or 'off' (without a NULL byte at the end), but OR still doesn't recognizes it.

2013-04-06 10:47:27,108 INFO Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA': send: STATUS COZINHA
2013-04-06 10:47:28,110 INFO Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA': received: on
2013-04-06 10:47:28,110 TRACE Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA': Processed off, received off

What do you sugest me to do?

Thanks

Posted by renatoriolino at Apr 07, 2013 13:55

2013-04-06 10:47:28,110 INFO Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA': received: on
2013-04-06 10:47:28,110 TRACE Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA': Processed off, received off

The last two lines are saying that the telnet implementation first receives an 'on' string but then for some reason decides to switch it to an 'off' value (I suppose the default value) because at the sensor level it is already processing an 'off' string.

It's hard to say where it goes wrong because there doesn't seem to be sufficient logging in the telnet implementation. I need to add more log statements or you can try to do it yourself – the implementation is here: TelnetCommand.java.

You can try a patch I created for trimming the values – OpenRemote-Controller-2.0.2_ORCJAVA-324 – but I don't think this will have an impact since it is a patch at the higher level in the controller mechanism and from the log it looks like the value has already been determined to be 'off' before it reaches its target. So more logging in the telnet implementation seems necessary.

I can try to get to this in couple of days, but unlikely that can do anything about it today unless you take a look at it yourself.

Posted by juha at Apr 07, 2013 14:11

Hmm, looking at the code, didn't have time to confirm this:

can you try ending your strings with line feed character ('\u000A'), and see if that does it?

something to try in the meantime.

Posted by juha at Apr 07, 2013 20:09

Hi,

Tryied but didn't work.

Log from my telnet server:

recv: STATUS COZINHA
reply: 6F 6E 0A (on
) (3 bytes)

dev.log:

2013-04-07 16:28:00,274 INFO [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: send: STATUS COZINHA
2013-04-07 16:28:01,275 INFO [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: received: on

2013-04-07 16:28:01,276 TRACE [Polling Sensor Thread ID = 58, Name ='SENSOR_COZINHA']: Processed off, received off

I'll try to download the source code and put some log there, but I only know C. But I guess java is not that different.

Thanks for helping me out.

[]'s

Renato

Posted by renatoriolino at Apr 07, 2013 20:33

Ok, I figured out where was the problem. On TelnetCommand.java, on the last line of the function readString() there was a code appending a newline to end of recvd string:

this.response += sb.toString() + "\n";

I just changed it to:

this.response += sb.toString();

because later on the read() function, it was correctly replacing the "on" string to "true" but leaving the newline at the end of string (true\n). Then the ParseBoolean method understood true\n as false.

I don't know it this change will break something for others, but here it solved the problem.

Now I only have some issues with timeout. One doubt:

How do OR knows that the response string finished? Because I can see on the logs that it keeps waiting 1 sec and than it process the string. I'll try to close the connection after sending the reply to see if it speeds up the process.

[]'s

Renato

Posted by renatoriolino at Apr 09, 2013 19:04

Hmm saw that, I found the implementation a bit strange there too. Not sure why it has been implemented that way.

Regarding responses, don't know either. Will need to build up proper tests to make sure these behaviors are documented and work consistently.

Posted by juha at Apr 10, 2013 07:30

The timeout property should let you define how long the response is waited for?

Posted by juha at Apr 10, 2013 07:45

Also can you try the OpenRemote-Controller-2.1.0_Alpha-SNAPSHOT-2013-04-09.zip. I think there were some reports with the timeout not working but I haven't confirmed. There's no fix for the '\n' issue as far as I can tell but it's hard to tell exactly what has changed between the releases.

Posted by juha at Apr 10, 2013 07:50

because later on the read() function, it was correctly replacing the "on" string to "true" but leaving the newline at the end of string (true\n). Then the ParseBoolean method understood true\n as false.

Hmm I guess we could trim the value before this, and thus avoid any impact to anyone else who might rely on the existing '\n' addition.

Posted by juha at Apr 10, 2013 13:20

Renato,

I'm building a regression test on the readString() issue and having trouble getting anything on the readString() implementation to be received at all.

Was the change to response sb.toString() the only one you made?

What was the exact configuration of the piped commands you set in the Designer ?

Thanks,

Posted by juha at Apr 11, 2013 05:37

The code branch for the snapshot is here : http://svn.code.sf.net/p/openremote/code/workspace/juha/Controller_2_1_0_FeatureMergeBranch/ in case you want to apply your '\n' fix again.

Posted by juha at Apr 11, 2013 05:38

Ok, my bad. It does insist on 'null|cmd' for the readString() to work correctly, instead of just '|cmd'.

Moving on.

Posted by juha at Apr 11, 2013 06:00

I've created a patch that should make it unnecessary to modify the source to remove the '\n' added in readString() method. Tests are passing ok with it but would appreciate if you were able to test it against your implementation.

OpenRemote-Controller-2.1.0_FM_ORCJAVA-326.zip

Posted by juha at Apr 11, 2013 10:35

Juha, it worked perfectly!

2013-04-11 06:41:37,755 INFO [Telnet Polling thread for sensor: SENSOR\_COZINHA]: send: STATUS COZINHA
2013-04-11 06:41:38,757 INFO [Telnet Polling thread for sensor: SENSOR\_COZINHA]: received: on
2013-04-11 06:41:38,757 TRACE [Telnet Polling thread for sensor: SENSOR\_COZINHA]: Processed 'on', received 'on'

There is still one issue: you see on the log above that between sending the command and receiving the reply there is a 1 sec interval. This 1 sec seems to be a timeout (timeout property is blank on designer). I don't know nothing about Java, but what does OR expect as "end of reply"? I tried sending a line-feed and even immediately close the socket after sending the reply but it seems that OR still waits 1 sec time-out to process the reply.

This it not a big issue, but it would improve a little the response time.

Other than that, everything is perfectly working!!

Thank you so much for your support.

Renato

Posted by renatoriolino at Apr 11, 2013 11:00
Document generated by Confluence on Jun 05, 2016 09:41