UPD binding - item to react on incoming UDP package

Hi,

I’m a bit stuck on getting my alarm system (Texecom) to interact with OpenHAB using the UDP binding.

What I want to realize:
I expect a specific UDP package from the Texecom system. Depending on the content of that package, my item should get a specific value.
The UDP package contains some other bits and bytes which I can ignore. But if it contains at least the values below, my item should be populated.
UDP package -> Item value
"Z0360 -> 0
"Z0361 -> 1
"Z0362 -> 2
Please not alse the " is part of the incoming UDP package.
The UDP packages are send from IP 192.168.3.10:10000 to IP 192.168.3.2:25001. The latter is where OpenHAB resides.

What I have done so far:

  • Install the TCP/UDP binding. I have set the configuration parameters to:
port=25001
refreshinterval=250
  • Install the REGEX and the MAP transformation;

I have created the following item file:

String Tex_UDP_Incoming1								"Incoming UDP String1"						<settings>		(gSet)						{ udp="<[192.168.3.10:25001:'REGEX((.*))']" }			
String Tex_UDP_Incoming2								"Incoming UDP String2"						<settings>		(gSet)						{ udp="<[192.168.3.10:10000:'REGEX((.*))']" }			
Number Tex_GV_Bureau_Zijkant_Kip_Z036					"Z036 - Bureau zijkant kipstand"			<window> 		(gGV_Bureau, gAlarm)

As you can see, I have created some generic “UDP Incoming” items (I tried various settings). My assumption would be it would be populated with whatever UDP package would be received. This is not the case.

Alternatively, I could use the MAP transformation. But in the examples in the documentation I only found the MAP transformation for outgoing UDP messages. So I guess that is not the way to go?

Thanks a lot for your help!

Dries

Which version of openHAB did you install?

Openhab 2.1 (snapshot)

Did you install the compatibility layer?
You can prove this through the karaf console:

user@openhab2:~$ ssh openhab@localhost -p8101
Password authentication
Password: //password is not shown. it is habopen

                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.1.0-SNAPSHOT
                               Build #906

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.

openhab> feature:list | grep compat1
openhab-runtime-compat1x                    | 2.1.0.SNAPSHOT   |          | Started     | distro-2.1.0-SNAPSHOT   | Compatibility layer for openHAB 1 add-ons

If this is not started, you will have to install it:

openhab> feature:install openhab-runtime-compat1x

Hi Udo,
Thanks for helping me out.
It seems I have the compatibility layer installed.

This is what I get:

openhab> feature:list | grep compat1
openhab-runtime-compat1x                    | 2.1.0.SNAPSHOT   |          | Started     | distro-2.1.0-SNAPSHOT   | Compatibility layer for openHAB 1 add-ons
openhab>

Also, when I restart my OpenHAB, I see the following entries in openhab.log:

2017-05-11 08:56:58.615 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The maximum buffer will be set to the default value of 1024
2017-05-11 08:56:58.615 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The interval to retry connection setups will be set to the default value of 5
2017-05-11 08:56:58.616 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The cron job to reset connections will be set to the default value of 0 0 0 * * ?
2017-05-11 08:56:58.616 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The setting to queue write operation until a channel gets connected will be set to the default value of true
2017-05-11 08:56:58.616 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The setting to share channels within an Item will be set to the default value of true
2017-05-11 08:56:58.617 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The setting to share channels between the items with the same direction will be set to the default value of true
2017-05-11 08:56:58.617 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The setting to share channels between directions will be set to the default value of true
2017-05-11 08:56:58.617 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - The setting to use address masks for incoming connections will be set to the default value of true
2017-05-11 08:56:58.618 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - Listening for incoming connections on /0:0:0:0:0:0:0:0:25001
2017-05-11 08:56:58.619 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The maximum time out for blocking write operations will be set to the default value of 3000
2017-05-11 08:56:58.619 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The blocking nature of read/write operations will be set to the default value of false
2017-05-11 08:56:58.619 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The preamble for all write operations will be set to the default value of ""
2017-05-11 08:56:58.619 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The postamble for all write operations will be set to the default value of ""
2017-05-11 08:56:58.620 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - Updating states with returned values will be set to the default value of true
2017-05-11 08:56:58.620 [INFO ] [ing.tcp.protocol.internal.TCPBinding] - The characterset will be set to the default value of ASCII
2017-05-11 08:56:58.621 [INFO ] [b.core.service.AbstractActiveService] - TCP Refresh Service has been started

So the mystery continues…

Not sure if it’s relevant, but OpenHAB is running on a Synology server (installed using a Synology package - 2.1.0.004-SNAPSHOT-DSM6).

hmmm… As I don’t use udp myself, I’m not that familiar with this stuff…
One thing…

2017-05-11 08:56:58.618 [INFO ] [ing.tcp.AbstractSocketChannelBinding] - Listening for incoming connections on /0:0:0:0:0:0:0:0:25001

Is that IPv6? I don’t know why the binding should listen to IPv6… Is there a command netstat at Synology Server? You could verify if openHAB is listening at IPv4, too.

Yes. Synology is essentially a Linux system.

Using SSH I have logged on to my Synology to run the “netstat -au” command (showing only UDP connections).
I’ve received the output below.

As you can see, Synology is not listening on port 25001 (not on IPV6 or IPV4). Anything I forgot to configure?

admin@DiskStation:~$ netstat -au
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:58372           0.0.0.0:*
udp        0      0 localhost:37899         0.0.0.0:*
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*
udp        0      0 192.168.3.2:47173       0.0.0.0:*
udp        0      0 192.168.3.2:ntp         0.0.0.0:*
udp        0      0 localhost:ntp           0.0.0.0:*
udp        0      0 0.0.0.0:ntp             0.0.0.0:*
udp        0      0 192.168.3.25:netbios-ns 0.0.0.0:*
udp        0      0 192.168.3.2:netbios-ns  0.0.0.0:*
udp        0      0 0.0.0.0:netbios-ns      0.0.0.0:*
udp        0      0 192.168.3.2:netbios-dgm 0.0.0.0:*
udp        0      0 192.168.3.2:netbios-dgm 0.0.0.0:*
udp        0      0 0.0.0.0:netbios-dgm     0.0.0.0:*
udp        0      0 localhost:snmp          0.0.0.0:*
udp        0      0 0.0.0.0:5353            0.0.0.0:*
udp        0      0 0.0.0.0:14682           0.0.0.0:*
udp        0      0 0.0.0.0:51555           0.0.0.0:*
udp        0      0 0.0.0.0:52665           0.0.0.0:*
udp        0      0 192.168.3.2:39390       0.0.0.0:*
udp        0      0 localhost:36318         0.0.0.0:*
udp        0      0 0.0.0.0:58867           0.0.0.0:*
udp        0      0 0.0.0.0:19996           0.0.0.0:*
udp        0      0 0.0.0.0:19997           0.0.0.0:*
udp        0      0 0.0.0.0:19998           0.0.0.0:*
udp        0      0 localhost:45653         0.0.0.0:*
udp        0      0 192.168.3.2:55900       0.0.0.0:*
udp        0      0 192.168.3.2:55901       0.0.0.0:*
udp        0      0 192.168.3.2:55902       0.0.0.0:*
udp        0      0 0.0.0.0:10897           0.0.0.0:*
udp        0      0 0.0.0.0:32410           0.0.0.0:*
udp        0      0 0.0.0.0:32412           0.0.0.0:*
udp        0      0 0.0.0.0:32413           0.0.0.0:*
udp        0      0 0.0.0.0:32414           0.0.0.0:*
udp        0      0 0.0.0.0:46761           0.0.0.0:*
udp        0      0 localhost:52935         0.0.0.0:*
udp        0      0 0.0.0.0:35570           0.0.0.0:*
udp        0      0 0.0.0.0:9997            0.0.0.0:*
udp        0      0 0.0.0.0:9998            0.0.0.0:*
udp        0      0 0.0.0.0:9999            0.0.0.0:*
udp        0      0 192.168.3.2:56103       0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1901            0.0.0.0:*
udp        0      0 localhost:34684         0.0.0.0:*
udp        0      0 0.0.0.0:52165           0.0.0.0:*
udp6       0      0 localhost:ntp           [::]:*
udp6       0      0 [::]:ntp                [::]:*
udp6       0      0 [::]:5353               [::]:*
udp6       0      0 [::]:5353               [::]:*
udp6       0      0 [::]:34386              [::]:*
udp6       0      0 [::]:3671               [::]:*
udp6       0      0 192.168.3.2:52990       [::]:*
udp6       0      0 192.168.3.2:57089       [::]:*
udp6       0      0 [::]:1900               [::]:*
udp6       0      0 [::]:1900               [::]:*

Ignore my previous post. Wrong netstat parameter.

Using “tnl” I could display the listening ports.

I’ve filtered out all non-relevant records.

admin@DiskStation:~$ netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp6       0      0 :::25001                :::*                    LISTEN

As you suspected, I only see a tcp6 entry. Where can I specify that it should listen on IPV4?

In fact I would expect that openHAB is listening at least IPv4 (because you defined IPv4 in your item) or both IPv4 and IPv6… mysterious…
Did you define any configurations in /$CONF/services/udp.cfg?

“udp.cfg” => right…
The binding generates a file called “tcp.cfg”. I assumed that file would contain the config for both UDP and TCP settings. Somewhere I’ve read that as long as the parameters are not preceeded with “udp:” or “tcp:” they would work for both protocols.

I guess I was wrong. As soon as I copied tcp.cfg to udp.cfg, some things kicked in action! :slight_smile:

The openhab.log is now being filled with the following entries:

2017-05-11 22:35:12.163 [WARN ] [g.tcp.AbstractDatagramChannelBinding] - No channel is active or defined for the data we received from /192.168.3.10:10000. It will be discarded.
2017-05-11 22:35:14.166 [WARN ] [g.tcp.AbstractDatagramChannelBinding] - Received data "Scrambled_data 22:34.23 Don 11 
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               from an undefined remote end /192.168.3.10:10000. We will not process it

The received data makes sense. It is the data that is being transmitted to OpenHAB via UDP. :slight_smile:

What I don’t get, is why my items are not populated with these values (I guess because “No channel is active or defined”).
These are my items:

String Tex_UDP_Incoming1								"Incoming UDP String1 [%s]"						<settings>		(gSet)						{ udp="<[192.168.3.10:25001:'REGEX((.*))']" }			
String Tex_UDP_Incoming2								"Incoming UDP String2 [%s]"						<settings>		(gSet)						{ udp="<[192.168.3.10:10000:'REGEX((.*))']" }			

My sitemap:

		Text item=Tex_UDP_Incoming1
		Text item=Tex_UDP_Incoming2

So what did I do wrong (again)?

Thanks already a lot, @Udo_Hartmann!

Dries

Hmm.
As the tcp/udp binding is an openHAB1 binding, the configuration was like tcp:parameter=whatever and udp:parameter=whatever in a file named openhab.cfg.
When changing to openHAB2, this file was split into many files, one for each binding. Now it isn’t necessary to name the binding, as it is named by the file itself.
tcp/udp binding is very special, as this binding is two bindings in one binding… but every parameter exists for both parts of the binding, so you have to set both of them if using both of them.
In fact, you would not need any configuration for receiving udp packets (except the item definition itself), but there is a bug in the binding, so you have to set at least one parameter to make things work, see http://docs.openhab.org/addons/bindings/tcp1/readme.html

I have no idea why the item still isn’t bound to udp, maybe you will have to restart openHAB.

Strange, when I restart OpenHAB, I see the following in openhab.log:

2017-05-11 22:29:30.821 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - The maximum buffer will be set to the default value of 1024
2017-05-11 22:29:30.821 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - The interval to retry connection setups will be set to the default value of 5
2017-05-11 22:29:30.821 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - The cron job to reset connections will be set to the default value of 0 0 0 * * ?
2017-05-11 22:29:30.822 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - The setting to share channels within an Item will be set to the default value of true
2017-05-11 22:29:30.822 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - The setting to share channels between the items with the same direction will be set to the default vaulue of true
2017-05-11 22:29:30.822 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - The setting to share channels between directions will be set to the default vaulue of true
2017-05-11 22:29:30.823 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - The setting to use address masks for incoming connections will be set to the default value of true
2017-05-11 22:29:30.860 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - Listening for incoming data on /0:0:0:0:0:0:0:0:25001
2017-05-11 22:29:30.861 [INFO ] [b.core.service.AbstractActiveService] - UDP Refresh Service has been started
2017-05-11 22:29:30.861 [INFO ] [ing.tcp.protocol.internal.UDPBinding] - The maximum timeout for blocking write operations will be set to the default value of 3000
2017-05-11 22:29:30.862 [INFO ] [ing.tcp.protocol.internal.UDPBinding] - The blocking nature of read/write operations will be set to the default value of false
2017-05-11 22:29:30.862 [INFO ] [ing.tcp.protocol.internal.UDPBinding] - The preamble for all write operations will be set to the default value of 
2017-05-11 22:29:30.863 [INFO ] [ing.tcp.protocol.internal.UDPBinding] - The postamble for all write operations will be set to the default value of 
2017-05-11 22:29:30.863 [INFO ] [ing.tcp.protocol.internal.UDPBinding] - Updating states with returned values will be set to the default value of true
2017-05-11 22:29:30.863 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - We will accept data coming from the remote end /192.168.3.10:25001
2017-05-11 22:29:30.863 [INFO ] [ing.tcp.protocol.internal.UDPBinding] - The character set will be set to the default value of ASCII
2017-05-11 22:29:30.864 [INFO ] [g.tcp.AbstractDatagramChannelBinding] - We will accept data coming from the remote end /192.168.3.10:10000
2017-05-11 22:29:31.117 [WARN ] [g.tcp.AbstractDatagramChannelBinding] - Received data "Scrambled data:28.40 Don 11 from an undefined remote end /192.168.3.10:10000. We will not process it"
2017-05-11 22:29:31.117 [WARN ] [g.tcp.AbstractDatagramChannelBinding] - No channel is active or defined for the data we received from /192.168.3.10:10000. It will be discarded.
2017-05-11 22:29:33.120 [WARN ] [g.tcp.AbstractDatagramChannelBinding] - Received data "Scrambled data 22:28.42 Don 11 

Some messages are coming from “ing.tcp.protocol.internal.UDPBinding” and some from “g.tcp.AbstractDatagramChannelBinding”.

I think there is a contradiction between “We will accept data coming from the remote end /192.168.3.10:10000” and “No channel is active or defined for the data we received from /192.168.3.10:10000”.

Problem solved!

I adjusted the udp.cfg to:

# Port to listen for incoming connections
port=25001
# Allow masks in ip:port addressing, e.g. 192.168.0.1:* etc
addressmask=true
# Used character set
charset=ASCII

It’s the “addressmask” that needed to be changed.

I also changed my item to:

String Tex_UDP_Incoming1								"Incoming UDP String1 [%s]"						<settings>		(gSet)						{ udp="<[192.168.3.10:*:'REGEX((.*))']" }			

My item is now populated with the ASCII information from the UDP package.

Thanks Udo for helping me out on this!

You’re welcome!

Hi Dries, I’m really interested in getting Openhab integration to a Texecom panel. I’m fairly new to Openhab and have a COM IP installed and online. Having trawled the net it looks like you are further progressed on this then anybody. I’m quite prepared to try to do the work and share for the community but can you share some information about how to start this project and any hints on how to get up and running. I’m running Openhab 2.2 on a Pi with Openhabian, I have the binding installed. Any help would be much appreciated.

Hi Mark,

I’ve been able to integrate my Texecom alarm to OpenHAB. It is running pretty stable for approx. 6 months. I’m not sure how much of my rules you van re-use, but I’m curious. Give me a few days to collect/structure some information (just dumping all my rules here would not be very helpful, I’m afraid). It would be nice if my rules find their way to another OH installation.

Hi,
Thanks for your reply that’s more than I was hoping for and would be fantastic. What to do to configure the interface etc is the part I am clueless on - once I understand how you made it work and have a rule or 2 working then I’m ok to write more rules.

I’m not sure I can offer you anything as useful in return - I have some unique automations but not generally that useful - eg an automated hay steamer! I am just working on an advanced solar energy monitor to max out use of our “free” excess solar power - I’m waiting for a Zappi car charger to be installed to nail that one. I’ve done some stock stuff like heating, weather, lights and so forth but probably not as well as others.

Thanks again and Regards

Mark

Hi Mark,
I’ve created a separate topic:

I don’t expect anything in return. People on this forum have given me more than enough without me being able to give something in return. Just let me know if it works!

Hello,

I might be asking a stupid question but forgive me in advance.

Does any one knos what happened to UDP binding on Openhab3?