This page last changed on Apr 20, 2013 by smee204.

I am trying to add a new protocol and extend some existing ones but to test the changes I need a working designer. I have spent many many hours trying to get the beehive and designer built and deployed but seem to have got nowhere. Can anyone provide a prebuilt/setup installation in a virtual machine or folder that I can use as I only need to add/modify the protocol xml files?

Is there a guide on building/setting up the designer?


No guides at the moment – if you describe your changes and post the XML here, I can look at deploying it on a staging server. Maybe that would do?

Posted by juha at May 01, 2013 09:53

I wanted to fix the infrared protocol and also expand it. See this thread for the bug it is fixing.

I also wanted to expand it by adding the option to specify the LIRCD socket for users with multiple ir blasters.
The new protocol infrared.xml is:

<?xml version="1.0" encoding="UTF-8"?>
<openremote xmlns="" xmlns:xsi=""
	xsi:schemaLocation=" protocol.xsd">
	<protocol displayName="Infrared" tagName="ir">
		<attr name="remote" label="Name">
		<attr name="command" label="IR Command">
				<regex message="Command is necessary">\w+</regex>
		<attr name="device" label="LIRCD Socket (Optional)">
Posted by smee204 at May 01, 2013 20:03

Another item that I think should be improved is the UDP and TCP/IP sockets. Currently with TCP you always get a CR appended onto the end of the command. I think there should be a drop down list allowing you to specify if you want a CR "\r", LF "\n" or EOL "\r\n".

Please add the following to both the UDP and TCP/IP socket protocols.

<attr name = "ending" label = "Line Endings" options="NONE,LF,CR,CRLF" tooltipMessage="Select line ending">
Posted by smee204 at May 01, 2013 20:23

The final change (for now) is the addition of a ping protocol. It will return on or off for a switch depending on the results of a ping. This is useful to tell if a PC or other device is turned on.

I propose the following ping.xml file.

<openremote xmlns = "" 
            xmlns:xsi = ""
	    xsi:schemaLocation = " protocol.xsd">

  <protocol displayName = "PING" tagName = "ping">

    <attr name = "ipAddress" label = "IP Address">
          <regex message="Must be a valid IPv4 or IPv6 address or a fully qualified domain name">(?:(?:1\d{0,2}|[3-9]\d?|2(?:[0-5]{1,2}|\d)?|0)\.){3}(?:1\d{0,2}|[3-9]\d?|2(?:[0-5]{1,2}|\d)?|0)|(^(([a-zA-Z]|[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z]|[A-Za-z][A-Za-z0-9\-]*[A-Za-z0-9])$)|(^([0-9a-f]{1,4}:){1,1}(:[0-9a-f]{1,4}){1,6}$)|(^([0-9a-f]{1,4}:){1,2}(:[0-9a-f]{1,4}){1,5}$)|(^([0-9a-f]{1,4}:){1,3}(:[0-9a-f]{1,4}){1,4}$)|(^([0-9a-f]{1,4}:){1,4}(:[0-9a-f]{1,4}){1,3}$)|(^([0-9a-f]{1,4}:){1,5}(:[0-9a-f]{1,4}){1,2}$)|(^([0-9a-f]{1,4}:){1,6}(:[0-9a-f]{1,4}){1,1}$)|(^(([0-9a-f]{1,4}:){1,7}|:):$)|(^:(:[0-9a-f]{1,4}){1,7}$)|(^((([0-9a-f]{1,4}:){6})(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$)|(^(([0-9a-f]{1,4}:){5}[0-9a-f]{1,4}:(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$)|(^([0-9a-f]{1,4}:){5}:[0-9a-f]{1,4}:(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}$)|(^([0-9a-f]{1,4}:){1,1}(:[0-9a-f]{1,4}){1,4}:(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}$)|(^([0-9a-f]{1,4}:){1,2}(:[0-9a-f]{1,4}){1,3}:(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}$)|(^([0-9a-f]{1,4}:){1,3}(:[0-9a-f]{1,4}){1,2}:(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}$)|(^([0-9a-f]{1,4}:){1,4}(:[0-9a-f]{1,4}){1,1}:(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}$)|(^(([0-9a-f]{1,4}:){1,5}|:):(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}$)|(^:(:[0-9a-f]{1,4}){1,5}:(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}$)</regex>
Posted by smee204 at May 01, 2013 20:27

Thanks, will try to set these up today.

Posted by juha at May 03, 2013 08:16

The ping protocol is now deployed online at

Looking at the IP address validation, these regexp have been problematic in the past. If it's a copy/paste from our previous other protocols, would recommend removing it and replacing it with .*

Posted by juha at May 05, 2013 06:31

Working on the rest.

Posted by juha at May 05, 2013 19:40

Great looks like it works.

I copied the regexp from the other socket protocols so replacing it with a * would be best.

Posted by smee204 at May 05, 2013 20:52

How do features get into the next release? Do I need to submit them somehow?

The ping feature is implemented in the controller at the following branch.

Posted by smee204 at May 05, 2013 21:57

The line-endings attributes have been added to TCP and UDP protocols in

Posted by juha at May 07, 2013 13:58

Will create a task for the ping protocol to track it which will eventually make it into release branches.

Posted by juha at May 07, 2013 13:59

Hi Juha,
would it be a big deal to add those changes (TCP line-endings and ping) to the Preview Designer (Markab)? That would be great as for now I cannot simply go back to the regular designer once I have used the preview version.

Thanks and best regards

Posted by aschwith at May 07, 2013 18:59

They won't have impact on preview yet since these are deployed just so Simon can test his controller changes which haven't been committed or distributed yet.

Posted by juha at May 07, 2013 19:21

Except for ping which has been committed, so can look at adding that once I've created the proper tasks to track the integration of these new features.

Posted by juha at May 07, 2013 19:23

Have committed the change in your workspace.

Posted by juha at May 07, 2013 20:26

I have implemented these new line endings for TCP and UDP sockets at the following branch:

Posted by smee204 at May 07, 2013 21:57

Thanks Simon, will be looking at integrating to release branches and also make it available in preview for Alexander.

Posted by juha at May 13, 2013 09:31

Quick update on this, there's one issue (easy to fix) with the proposal which is the use of Java's switch statement with strings. Switch on strings was introduced in Java 7 so this would currently introduce a dependency to Java 7 which at the moment is a no go.

Just a heads up, this is not a difficult fix. Tracking issues regarding to TCP line endings at ORCJAVA-358.

Also had to port it to a new baseline for 2.1 because ORCJAVA-298 introduced a significant rewrite of the TCP part. This can be found in your workspace.

Posted by juha at May 28, 2013 11:10

Did not see anything on the UDP side, was this still planned?

Posted by juha at May 28, 2013 11:12

I had implemented this at the same time just forgot to push it to the svn!

Should be there now.

Posted by smee204 at May 28, 2013 19:33


Posted by juha at May 29, 2013 13:34
Document generated by Confluence on Jun 05, 2016 09:31