This page last changed on Jan 02, 2013 by domog.

I try connect with modbus plc with tcp\ip command:
i send this command: 0x000000000006010600100001 but don't work.
I try this command ( 000000000006010600100001 ) with modbus master tester and it work.
Can sameone help me?


I did not try it before but I am interest in this topic too.

Can you give me more information ?

Posted by miumiu2013 at Jan 23, 2013 15:12

Which version of the controller did you use?
I think the hex support is only in the 2.1-DeveloperSnpashot:

Posted by mredeker at Jan 24, 2013 08:03

Can I understand that the 2.0.2 version currently under Controller download does not support Hex HTTP commands?
If so what is the difference between the two versions?

Posted by niraviry at Jun 03, 2013 05:42

You can download the latest development snapshot here:

The change notes are here: CHANGES.txt

Controller 2.1.0 (2013-XX-XX Twin Galaxies)

New Features:

  - WebConsole upgraded to version 2.1.1, fixes issues with stuck
    loading screen (Richard Turner, ORCJAVA-345)
  - Added DSC-IT 100 Security System integration - IP to serial (Greg Rapp)
  - Lagarto server (panStamps) integration (Daniel Berenguer)
  - Support 'custom' sensor types with virtual commands (ORCJAVA-217)
  - KNX: added distinct levels for 'DIM' and 'SCALE' commands that allow
    set values to be configured for buttons, e.g. 'DIM 50' to dim directly
    to 50% (Eric Bariaux, ORCJAVA-71).
  - HTTP protocol: methods GET, POST, PUT and DELETE are now supported.
    For HTTP/JSON return documents, a JSON Path expression is supported.
    For outgoing HTTP request, a user agent header is included which
    contains 'OpenRemoteController' as agent value which HTTP applications
    can use to identify requests originating from the controller.
    Internally, the implementation has been converted to use URIs instead 
    of URLs which resolves an issue with lack of encoding of HTTP parameters 
    which contain which contain white spaces or other special characters 
    (Marcus Redeker)
  - One Wire: Added possibility to specify temperature values in
    either Celsius (default), Kelvin, Fahrenheit or Rankine scales, data
    property added for sending values to switches (Marcus Redeker)
  - Shell Command Execution: polling interval and regular expression
    filtering on return values supported, including regexp groups to 
    read in multiple sensor values at once. Support for using shell
    commands with sliders added (Marcus Redeker, Ivan Martinez)
  - Telnet: polling interval property added (Marcus Redeker), dedicated
    telnet log directory and telnet debug logs added (Juha Lindfors, ORCJAVA-328)
  - Date/Time : values updated once per minute instead of once per second
    (Marcus Redeker)
  - UDP : send hex values by prefixing command data with '0x' string.
    Receiving of UDP packets added (Marcus Redeker)
  - TCP : send hex values by prefixing command data with '0x' string
    (Marcus Redeker)
  - Samsung SmartTV : support control of multiple Samsung devices in single
    installation (Ivan Martinez)
  - Touch panel gestures can now be bound to macros in addition to individual
    commands (Eric Bariaux, ORCJAVA-231)
  - Color selection widget is now supported by the controller (Eric Bariaux,
  - Direct Tomcat container logging to /logs/container/tomcat-server.log 
    (Tomcat server logging) and /logs/container/appcontext.log (Controller
    web application logging) files, and output directed to standard output
    and error streams to /logs/container/stderrout.log -- catalina.out is
    no longer created (Juha Lindfors, ORCJAVA-273)
  - Adjusted 'start' and 'run' targets of to configure default
    standard output console logging differently -- 'run' target will still
    output logs to console where as 'start' target will redirect all logging
    to files (Juha Lindfors, ORCJAVA-273)

Bug Fixes:

  - Performance fix to sensor state cache queries (Marcus Redeker)
  - Runtime performance optimization to avoid unnecessary XML 
    parsing/XPath use (ORCJAVA-190)
  - Fix for JSON REST request return values (Richard Turner, ORCJAVA-254)
  - Rework logout requests and added CORS headers (Richard Turner, ORCJAVA-255)
  - Internal API : concurrency and call control on Deployer start 
    controller calls (Juha Lindfors, ORCJAVA-179)  
  - Range and Level sensors trim the incoming values from protocol implementation
    before attempting to convert values to numbers (Eric Bariaux, ORCJAVA-261)  
  - Fix issues with installing Controller to a file system location that contained
    white spaces in path names - commonly 'Program Files' on Windows environments
    (Juha Lindfors ORCJAVA-280, ORCJAVA-263, ORCJAVA-286, Eric Bariaux ORCJAVA-311)
  - Fix a false warning in ISY-99 protocol implementation 
    (Juha Lindfors, ORCJAVA-308)
  - State sensor is more tolerant to device input trimming non-printable 
    characters -- CF, RF, zero bytes, etc.  (Juha Lindfors, ORCJAVA-324) 
  - Use locale independent string case conversions in the controller, KNX and telnet
    protocols (Juha Lindfors, ORCJAVA-332, ORCJAVA-334, ORCJAVA-335)
  - Fix a bug in telnet switch sensor handling where untrimmed return value was
    never correctly parsed to 'on' state (Juha Lindfors, ORCJAVA-326)


  - Enforce UTF-8 encoding on Java source files with javac to prevent build issues
    on systems with differing default character encoding configurations
    (Juha Lindfors, ORCJAVA-329)

Posted by juha at Jun 03, 2013 11:58

I think HEX is not supported with HTTP only TCP.

Posted by mredeker at Jun 03, 2013 13:04

What about documentaion of some sort?

Posted by niraviry at Jun 03, 2013 20:29

Hi again.

I have been investigating the ModBus issue. I have used the Advantech tools for the ADAM-6050 along with Wireshark to understand the actual TCP activity. The results under OR are (to my opinion):
1. The HTTP is useless since:

  • One needs to send the ModBus Head which is non ASCII and have a running transaction number (new binding number each new command for TX and RX)
  • At least currently with Advantech, the HTTP is stated as supported but there is no documentation of the way to perform HTTP get.
  • It is not clear wether the HTTP is an internal support or using a translating library.
    2. The TCP is useless since you can only send hex data but the ModBus needs handshake.

I guess a Java ModBus is the only solution and since my Java skills are low I will have to wait or dig deeper.
If someone has a different idea / opinion I would like get it.

Posted by niraviry at Jun 24, 2013 16:09

Nir Aviry

Were you ever able to get your Advantech working with Openremote? I just picked up an Adam-6052 and am trying to experiment with it.

If you have any more findings can you pass them on


Posted by drewscm at Jan 04, 2014 04:51

Back to Modbus after a long time.
I am no expert in HTTP but I am on the way to understand the method after running some activity with Wireshark.
The new ADAM devices can be loaded with HTTP version instead of JAVA. That means available protocol for OR.
I got the structure of the POST and GET which implemet plain text method in commands:

The GET is for both while the POST is for the Digitaloutput.

Along with that is a plain text workload:


The ADAM-6050 is an Ethernet ModBus/TCP based device with 6 Relay and 12 Digital inputs.
The ACK seems to be a XML structure which is constant if all is OK:

<?xml version=\"1.0\" ?>
<ADAM-6050 status="OK">

This is a fairly good starting point.

Posted by niraviry at Apr 10, 2015 17:57

Thats great....I am in the middle of programming my system, I will have to pull my ADAM I/O out and do some testing

Keep posting any results you get


Posted by drewscm at Apr 14, 2015 17:18

I did some XPath using a web tester. The responce is XML but from some reason the query of the XPath tester does not function as I have expected. I will use it after the XP shell be understood.
In general the HTTP has two type of GET fron DI and DO and one POST for DO setting.
The responce XML starts with <ADAM-6050 status="OK"> and ends with </ADAM-6050> which XPathtester does not cope with that.
Even if I remove the status stuff still I have not managed to set a working query. Once it will work it can be used in the HTTP command and sensors.
As you may know if the device implements Modbus using hTTP server it will work about the same way for othe manufacturers devices.
Please update me with your findings.
fYI, ADAM devices with version CE has the option for HTTP server application. The older ones (BE) can not be used for that.

Posted by niraviry at Apr 14, 2015 20:13

Good news (Update - not there yet but close).

As I have posted, when loading the ADAM CE series units with HTTP firmware the ADAM units responce to XML through HTTP POST and GET.

The GET functionality using XPATH should look like this (Read status request and responce):

The corresponding Controller.XML code looks like this:

<command id="3122" protocol="http">
      <property name="username" value="root" />
      <property name="pollingInterval" value="500m" />
      <property name="method" value="GET" />
      <property name="contentType" value="text/xml" />
      <property name="password" value="00000000" />
      <property name="url" value="" />
      <property name="xpath" value="//DO[1]/VALUE[1]='1'" />
      <property name="name" value="ADAM 1 DO0 STATUS REQ" />

The result is binary (true / false) as tested using a web tester called XPATH Tester.

The Relay Control contains 7 commands: 6 for setting each of the 6 Relays and one for Ressting them all. The reason is that my control
is a pulse so I can use a Macro to set and reset each relay which is connectoed to my aircondition units accross my house.

The Designer (July 2013 snapshot) looksline this:

But the corresponding XML code looks like this:

<command id="3124" protocol="http">
      <property name="workload" value="DO0=0&amp;DO1=1&amp;DO2=0&amp;DO3=0&amp;DO4=0&amp;DO5=0" />
      <property name="username" value="root" />
      <property name="pollingInterval" value="500m" />
      <property name="method" value="POST" />
      <property name="contentType" value="text/plain;charset=UTF-8" />
      <property name="password" value="00000000" />
      <property name="url" value="" />
      <property name="xpath" value="/ADAM-6050" />
      <property name="name" value="ADAM_Living_Aircon_set" />

As you can see &amp instead of & (the workload string is: DO0=0&DO1=0&DO2=0&DO3=0&DO4=0&DO5=0). I am not shure it is correct as this is a plain text.

I used only one sensor to test the setup which checks the Relay status. WhatI get is the following error:

ERROR [Polling thread for sensor: Test]: ClientProtocolException when executing HTTP method
org.apache.http.client.HttpResponseException: Forbidden
	at org.apache.http.impl.client.BasicResponseHandler.handleResponse(
	at org.apache.http.impl.client.BasicResponseHandler.handleResponse(
	at org.apache.http.impl.client.AbstractHttpClient.execute(
	at org.apache.http.impl.client.AbstractHttpClient.execute(
	at org.apache.http.impl.client.AbstractHttpClient.execute(
	at org.openremote.controller.protocol.http.HttpGetCommand.requestURL(
INFO 2015-06-27 18:29:40,991 : Registered sensor : Switch Sensor (Name = 'Study Desk Light Panel Status', ID = '100057353')
[Fatal Error] :1:1: Premature end of file.
ERROR [Polling thread for sensor: Test]: Could not perform xpath evaluation
org.xml.sax.SAXParseException: Premature end of file.
	at javax.xml.parsers.DocumentBuilder.parse(

This error appears both in HTTP GET for DI which seems to be OK from the Controller.XML code and the GET DO which looks suspicious.

I have also noticed that the Wireshark URI appears like this:

" HTTP/1.1" (" are not part of the URI). The request version does not appear in any place in the HTTP command.

Also the referer looks like this:


The \r\n - (CR) (LF) appears in many of the fields in the messages I see in the Wireshark and I am also not sure I need to add them in the Designer or not.

There are posts about (CR) & (LF) regarding the TCP and UDP but not HTTP.

BTW, removing the user and password does not change any of the above.

This is why I am not sure the URL in the designer is OK.

Can anyone help.


Posted by niraviry at Jun 21, 2015 17:40

As I had no time to try and investigate why the HTTP version does not work, I left it aside till few days back. I found a command line application running on most platforms -modpoll. Using this utility I was able to sense and control my Modbus devices.
So I have created bash (linux) sh files to do all tasks I need. The result is equal, not equal my value and communication error.
It works great.
Now I am in the middle of putting it all in the Designer. I expect no problem.
Will update once I will have time to do that.
Using Modbus one can use very chip voltage and power meters and many inexpensive devices as the modpoll is very generic.

Posted by niraviry at Aug 29, 2015 07:32

After integrating most of my devices it looks like it is working great.
The modpoll is working smoothly.
End of my air condition project.
Now I am heading towards Modbus power meters. These are about 50 to $90 in Aliexpress.

Posted by niraviry at Sep 01, 2015 20:14

Hi Nir, did you indeed get modbus to work? It would be great if we can create some documentation on that...

Posted by pierre kil at Sep 02, 2015 08:43

Well i need to do some more tweaking since the sensors return values do not function properly under OR but I am optimistic.
The idea is to use the free modpoll for whatever OS you need. Mine is Ubuntu.
Play with a terminal to get the proper command syntax you need.
Then, generate a script to be used as shell command protocol on the OR.
Keep in mind that if you add a vlue at the end, it is a write coil if relevant and if not it is a read status of a coil or discrete.
The coil commands are working well. I have created 3: On, Off and Toggle.
I pass IP and coil number to the script and exit the shell with or without an error.
As for sensors, i do the same but on status registers. I send an IP, discrete number and expected result.
If the result fails, it is the oposite value.
I will send out the bash files (scripts). The rest is trivial as it is exactly as in the tutorial.
I use 500mSec for Sensors polling.

Posted by niraviry at Sep 02, 2015 15:29

Sounds like a plan Keep us posted. I'll happily create some basic doc.

Posted by pierre kil at Sep 02, 2015 15:51

I might be needing some help to resolve to sensor issue.
The control is working perfectly.
Here is my bash file which returns 0 if the sense request is equal to the value I expecting and 1 if not. It also retuns 2 if there is a communication issue but I did not set this one out yet. I need to add some rules.


# $1 is ADAM IP, $2 is Channel number 1-12 are input, 17 to 22 are Relay output.
# $3 is expected vlaue 0 or 1
# Respnce will return 1 if discrete matches $3, 0 if not matches $3 and 2 if communication error  occured.

modbus_io="$(modpoll -m tcp $1 -r $2 -c 1 -t 0 -1 | tail -1)"
modbus="$(echo $modbus_io | cut -c $((${#modbus_io})))"

if [ $modbus -gt 1 ]
	echo communication error
	exit 2

if [ $modbus -eq $3 ]
	echo responce match
	exit 1
	echo responce missmatch
	exit 0 

The sensor looks like this:

I also enabled the shell command logging as instructed in the forum but it is not in the log directory so I can't debug.

I assume ) and 1 are translated in to on and off of a switch which I have used.

At this point I get no responce from the sensor on the screen. The bash file works OK.

I am not sure if I should move to custom sensor instead of a switch to solve the problem.

Posted by niraviry at Sep 02, 2015 18:02

Finally I got the Modbus and for a matter of fact any other command line based protocol or utility working perfectly.
The thing is that the OR How to page of Shell Execution protocol is missing some basic info which one must figure out by trail and error.
I will try and put it all in one post which will enable everyone to add any command line utility as shell execution protocol to OR. I am using Linux so I use Bash files to filter out response and get what is needed by OR.

Posted by niraviry at Sep 14, 2015 20:22

This is an add on information to ModBus and Shell execution Protocol.

This post extends the information about the implementation of the two subjects.

There are few rules to follow to make things running:
1. Shell commands return values to OR using echo command which is part of Linux shall commands like bash and part of Windows Batch files. These will be refereed to as script files.
To use a Switch one must use both"echo on" and "echo off" commands within the script files.
Exit 0 or Exit 1 will not do the job.
2. If some other form of entity is to be used, a custom sensor may be used to convert the response (something like 1 is on, 0 is off etc.).
3. The Regex in a switch case shall be (on|off). Keep in mind that the order in this field is insignificant. The logic behind (of the shell command file is what's important).
4. Verify the the integrated interval of commands/program (like modpoll in the case of a ModBus) within the script file shall be short enough no to cause overlapping commands.
That means the OR polling interval shall be longer than the command cycle, which in many cases can be altered (see -l time in modpoll).
5. I am not sure about the sensor name field as my final stage from which all was working, had to changes at one time and one of them was the sensor name.
6. Changing the code of the script file shall require a PC re-boot or at least program re-run. Otherwise changes will not take effect.
7. The script files can be anywhere in the file system as long as:

  • They are executable
  • Permission is at least as the one of the OR folder.
  • All files are fully defined in the path in each OR command.
    8. Some devices like Air condition units needs pulse as a trigger and its state (like off/on or error) are defined using dry contact or so, there should be a script that run coil enable and then disable (off to on, delay and on to off) to toggle the function.
    9. Th outcome is that one needs a different sensor to get the state of the unit. The script is to read the proper bit in the Modbus (or any other protocol), and within the script may set to output result to be directly used by OR. That means on q off etc.
    10. I attach the script files. The OR commands and sensors are about the same as in my previous post in this subject.

Note: I managed to enable the shall logging only under the last version of the Linux OR (2.1.1 from Feb 2015).


# The is script file
# Set Relay 0 to 5 to On (short state).
# $1 is ADAM IP address, $2 is Channel number 1-12 are input so do not use, 17 to 22 are Relay output.

modpoll -m tcp $1 -r $2 -c 1 -t 0 -1 1 > /dev/null

# echo "Relay" $2 "On" $1 "was set to On"

See the > /dev/null. It is designed to prevent the OR sensor from seeing undesiered text that shall be interpreted wrongly.


# The is script file
# Set Relay 0 to 5 to On (short state).
# $1 is ADAM IP address, $2 is Channel number 1-12 are input so do not use, 17 to 22 are Relay output.

modpoll -m tcp $1 -r $2 -c 1 -t 0 -1 0 > /dev/null

# echo "Relay" $2 "On" $1 "was set to Off"

Ofcoarse one can combine two or more commands to do the correct task.

The sensor script looks like this:

#! /bin/sh

# This is file
# $1 is ADAM IP, $2 is Channel number 1-12 are input, 17 to 22 are Relay output.
# $3 is expected vlaue 0 or 1
# Respnce will return 1 if discrete matches $3, 0 if not matches $3 and 2 if communication error  occured.
# ech off
modbus_io="$(modpoll -l 250 -m tcp $1 -r $2 -c 1 -t 0 -1 | tail -1)"
modbus="$(echo $modbus_io | cut -c $((${#modbus_io})))"

# if [ $modbus -gt 1 ]
# then
#	echo communication error
#	exit 2
# fi

if [ $modbus -eq $3 ]
	echo on
	echo off

# echo "Status bit" $2 "on" $1 "was tested!"

Regex above is to use different values per each sensor to lower the load over the net. I have set it to about 1.1 seconds with 20mSec difference between the set of sensors.
The regex actually is (on|off).

ADAM devices have 12 bit of Digital Input (1 to 12) and 6 Digital Outputs (17 to 22). This will help you understand the commands for the TCP ModBus device.

Last thing, as you can see, one can arrange the proper parameters according to the device / protocol being used.

I hope I did not miss anything.

My next project is implementing a Modbus Energy meter including events logging (out of range voltage etc.).
RS-485 based Modbus devices are low price (look at Aliexpress).

Posted by niraviry at Sep 15, 2015 12:17

does the de-tour using the shell command work well?
Do you think we can come up with a more sophisticated solution, maybe speaking HTTP or TCP?
The HTTP "Forbidden" issue came up just the other day talking to another device.
There might be an issue with our HTTP protocol not sending the authentication information correctly which I want to investigate when I find some time

Posted by mredeker at Sep 24, 2015 21:07

Interesting to see that Nir had the same problem with http authentication as I encountered. So would be nice if he could give the http thing one more try with Pro version 1.2 (If he has that)

A side remark on Modbus. Industry is still soaked in that protocol. Not rocket science, but very reliable in hersh envrionments. Because of Nir's search I could make someone very happy with a link to modpoll (which is open source and easy to compile on different platforms I understood)

Posted by pz1 at Sep 24, 2015 22:32

Well I even did not compile it. I have simply downloded the Linux version run file, lookup for some examples and after a hour I had bash files working simply under Linux.
Then I have packed the bash file to return on or off (I still need to add error condition handling as well as I had not time for that yet).
Once this was over, I have used shell command protocol under OR.
Here I came accress the interval time issue and once I have understood it, I have just set a time in mSec (no m next to the number) and it all works well.
There are so many devices working under Modbus so it is very usefull. For instance KNX input devices are very expensive while Modbus is very cheep.
I have also mentioned evnergy meters/analyzers which under Modbus RTU have lots of inexpensive products.
Finally, any protocol the has a command line utility off the shelf (bash or batch) can be implemented very easily in thus way.
As for the HTTP, I have only the free edition so I got stuck with it. Keep in mind that not all devices support HTTP protocol.
I do this work on my own house for the fun so I had no season to move to the pro edition.

Posted by niraviry at Sep 25, 2015 00:34

Well I even did not compile it.

But my friend was happy he could compile for his platform! And it makes your Modbus solution more generic.

Keep in mind that not all devices support HTTP protocol

I'am well aware of that. I do understand that you choose not to use the pro version. Would have been a nice test opportunity if you had it.

Posted by pz1 at Sep 25, 2015 08:44

Hi, nice progress If you like to try out the suggestion of Pieter, we are happy to give you a free pro license. Just e-mail me at

Posted by pierre kil at Sep 25, 2015 09:44

Regarding HTTP and authentication you can follow the discussion here:
Seems that your HTTP device is also directly returning the 403 instead asking for the authentication information with a 401 first.

Posted by mredeker at Oct 05, 2015 11:04

Yes, I continued in that thread

Posted by pz1 at Oct 05, 2015 11:13


Sorry for the delay with testing the ModBus with HTTP. I have repeated the ADAM test with HTTP. I t shows about the same results on the Pro 1.3 version.

I have tested my ADAM device in two configuration as was posted in the above in this post (with and without user and password).
Both do not work.

With no user and password I get the following errors:

ERROR [Polling Sensor Thread ID = 250156, Name ='AirCon Test Sensor']: ClientProtocolException when executing HTTP method
org.apache.http.client.HttpResponseException: Object Not Found
    at org.apache.http.impl.client.BasicResponseHandler.handleResponse(
    at org.apache.http.impl.client.BasicResponseHandler.handleResponse(
    at org.apache.http.impl.client.AbstractHttpClient.execute(
    at org.apache.http.impl.client.AbstractHttpClient.execute(
    at org.apache.http.impl.client.AbstractHttpClient.execute(
    at org.openremote.controller.protocol.http.HttpGetCommand.requestURL(Unknown Source)
    at Source)
    at org.openremote.controller.model.sensor.Sensor$ Source)
    at org.openremote.controller.model.sensor.Sensor$ Source)
[Fatal Error] :1:1: Premature end of file.
ERROR [Polling Sensor Thread ID = 250156, Name ='AirCon Test Sensor']: Could not perform xpath evaluation
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Premature end of file.
    at javax.xml.parsers.DocumentBuilder.parse(
    at Source)
    at org.openremote.controller.model.sensor.Sensor$ Source)
    at org.openremote.controller.model.sensor.Sensor$ Source)

The project is tiny and the object exists.

If I put the login user and password (which do not appear in the Wireshark recording) I get about the same but one or two times I got an error
as the first error:
"login rejected"
It is very fast so it is hard to catch. I tried to find it in the debug log but it was not there.

As for the errors:

1. It looks to me that the 1st thing that bugs this one is the "//" at the Xpath Expression.
Using the follwoingXPAth tester, the XPath is OK:

I have no idea what is wrong unless OR canot cope with such a condition.

The xml responce looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ADAM-6050 status="OK">

2 As for the "object not found" error, I have no idea what is the problem.

If someone wants me to send him the Wireshark file I will be happy to do so.

I hope there is a solution.



Posted by niraviry at Nov 06, 2015 16:21

I gave up since both Marcus and the ZWay guys say the other side is wrong. I honestly don't know who is right. Marcus has answered all my questions, but the Zway people have choosen not to respond to my final question.....

Posted by pz1 at Nov 06, 2015 18:14

can you verify that the device is handling the basic authentication problem that Pieter had correctly.

1) Our library first needs a 401 Unauthorized response before sending the authentication information.

2) I cannot find the "Object not found" being part of our HTTP library. This sees to be a error from your side.

Can you verify these 2 issues with wireshark?

Posted by mredeker at Nov 17, 2015 22:37

I had hoped that the latest ZWay release (2.1.2-rc17) had changed a bit on their side (release notes say nothing about it). I see no change. Maybe tomorrow I find the time to run the TCPDUMP once more.

Posted by pz1 at Nov 18, 2015 16:58

Still problematic in v2.1.2-rc17.

    DS212> tcpdump -A -v -s 10240 'tcp port 8083 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 10240 bytes
    15:38:44.400120 IP (tos 0x0, ttl 64, id 53660, offset 0, flags [DF], proto TCP (6), length 217)
        DS212.56798 > Flags [P.], cksum 0x8459 (incorrect -> 0x73aa), seq 785799336:785799501, ack 3299199293, win 183, options [nop,nop,TS val 191007037 ecr 51423], length 165
    .b.=....GET /OpenRemote/SwitchBinaryStatus/9/0 HTTP/1.1
    User-Agent: OpenRemoteController
    Content-Type: application/json
    Host: raspberrypi:8083
    Connection: Keep-Alive

    15:38:44.425443 IP (tos 0x0, ttl 64, id 483, offset 0, flags [DF], proto TCP (6), length 269) > DS212.56798: Flags [P.], cksum 0x75ba (correct), seq 1:218, ack 165, win 470, options [nop,nop,TS val 51425 ecr 191007037], length 217
    .....b.=HTTP/1.1 401 Unauthorized
    Connection: close
    Access-Control-Allow-Origin: *
    Access-Control-Allow-Credentials: true
    Content-Type: text/plain
    Content-Length: 13
    Transfer-Encoding: chunked

    Not logged in

Looks to me like ZWay properly returns 401, but I do not see OR sending the request with usr/pwd then. The pattern above just repeats every 2seconds as defined by me in the http command.

Posted by pz1 at Nov 19, 2015 14:59

I will try this weekend.

Posted by niraviry at Nov 19, 2015 17:53

It has become pretty clear to Marcus and me that the problem I reported is on the ZWay side. So as far as I am concerned this issue is closed.
I no longer this thread

Posted by pz1 at Dec 08, 2015 09:45

Hi all.
I am using 7 module from AHATOS. the modules are connected to my COM port on my PC via RS232 to RS485 converter and I am using modpoll.exe to communicate with the module ( under windows OS).
in openremote I create ON ,OFF commands ( that runs powershell script that invoke modpoll.exe to set value) , STATUS command ( that runs powershell script invokes modpoll.exe to read value),
Sensor that runs every 500ms the status command and a switch that combines ON,OFF and sensor elements.
one switch is working fine. I can set and read from AHATOS module. the problem is when I create 56 switches like the above switch.
commands are dropped and the and the system is busy.
I noticed that for each switch there is a thread opened that runs powershell.exe. when openremote controller is running and I read from the AHATOS module manualy, I get some times an indication the the port is already open
so the current command is lost.
in addition shell debug file indicates also that readings are also lost (I don't get a valid value "on" or "off" ).

my questions :

1. does 56 switches that runs powershell script are too much?
2. what is the best way to aggregate all the individual reads to a one thread containing 56 serial reading? if there is a thread contention, this can solve it...
3. I am not using the PRO controller. is it related?

please advise

Posted by nitzank at Jan 31, 2016 14:50

Hi Nitzan.

I use 2 ADAM devices with 6 DO and 12 DI each. I use some of them. In order to spread the activity I keep a kind of order of polling que by setting differnt polling time. This way I have one at the time polling. The modpoll has timing parameter.
Keep it low to free the modpoll shortly after each polling.

Posted by niraviry at Jan 31, 2016 19:12

Nir , thanks.
I will try it.
Is it possible that there is a conflict between sensor command ( read ) and on/off commands ( write ) on the serial port?
Can you give me please an example of the modpoll command with the timing parameter?

Posted by nitzank at Jan 31, 2016 19:29
Document generated by Confluence on Jun 05, 2016 10:44