Hi everybody!
I’m trying to receive the status of a light from another machine (Raspberry Pi).
The Pi sends to the OpenHab machine the string “ON” or “OFF” but when I create this binding:
Switch Light_Test "Light Test" <light> { udp="<[ON:192.168.20.12:5006:'REGEX((ON))']" }
I don’t see the port 5006 listed as listening if I do a netstat -na.
What am i doing wrong?
Thanks,
Andrea
I have learned to always start at the beginning and most basic steps.
Have you installed the org.openhab.binding.tcp-1.7.1.jar file to your addon’s folder?
Have you looked at the logs to see if there are any errors reported when openHAB starts or when you send the data to the given socket? At a minimum you should see something saying that the TCP binding has been loaded and started in the logs. If not the addon is not being loaded.
That’s exactly what I do.
The TCP binding is installed and working, I use it regularly to send command to another machine but I was never able to receive information.
There is no error, as soon as I enable it on the log I see this:
We will accept data coming from the remote end /192.168.20.12:5006
where 192.168.20.12 is the machine who is sending the UDP commands from port xxxxx to port 5006 on the OpenHab machine.
When the UDP message is sent I don’t see any trace on the log
The next things I would check are:
Can you set up your own script or program to listen on that port, or set up wireshark to verify that the UDP packet is indeed being received by the OH machine?
Your binding looks correct to me, though you might try 'REGEX((.*))' just to see if what you are expecting to receive is a little off (e.g. a trailing space or something like that) from what is actually being sent. If the Switch goes to ON you know OH actually received the packet but the contents is not “ON”.
You also might try switching to TCP if you can change it to that on the other end to see if that makes a difference.
I have no experience with with the TCP binding myself but these are the steps I would follow to debug the problem. But my basic approach is to start at the beginning (make sure the binding is even installed and working) and then follow the message from its origin to each stop along the way to verify it is getting to where OH can read it, and then start experimenting with the OH binding config to see what makes a difference.
I’ve setup my script on the OH machine and it receive the UDP messages without any problem. In fact when I run my script if I do a netstat -na I see that the port 5006 is listening, while when I run OH that port is not listening, so it can’t receive any message.
I’ve tried switching to TCP but it’s the same story, OH says:
We will accept data coming from the remote end /192.168.20.12:5006
butthere is no socket listening on the port 5006.
I’ve even tried to change the port but nothing… 
The last thing I can think of to check is that the openhab user isn’t being prevented from listening on that port by iptables or seLinux.It seem unlikely but I’m all out of ideas.
I just went created a new crater in my desk with my forehead trying to get udp bindings to work with a remote serial to tcp/udp bridge. There’s a few things you need to configure. I’ll ignore all the transformation side of things.
The Item binding is about the remote device that you’re controlling and not your local openHAB server. So your binding (below) is saying that you are expecting an incoming message FROM 192.168.20.12:5006. That is, the source port is 5006, not the destination port. You said the machine is sending from port xxxxx TO port 5006. So change your binding to look like this (wildcard the port):
Switch Light_Test "Light Test" <light> { udp="<[ON:192.168.20.12:*:'REGEX((ON))']" }
Next, to make openHAB listen on port 5006, add this into openhab.cfg
udp:port=5006
openHAB will also automatically listen on any port it opens to send commands to remote udp ports if you have an outbound binding configured as well.
I’m using two String item types since the RS485 bridge I’m using sends and receives state and command messages (to/from Philips Dynalite). Basically, the remote unit listens on port udp/1000 for incoming messages, and will send back messages TO udp/1001. So my items look like this:
String IO_Dynet_Send "[%s]" { udp=">[192.168.10.250:1000:'REGEX((.*))']" }
String IO_Dynet_Receive "[%s]" { udp="<[192.168.10.250:*:'REGEX((.*))']" }
Then in openhab.cfg I have (amongst other things):
udp:updatewithresponse=true
udp:charset=ASCII
udp:port=11001
And what this then shows when I look at open ports is (openHAB is on 192.168.10.200 and the bridge is .250):
[~/]# ss -napu | grep java
ESTAB 0 0 ::ffff:192.168.10.200:57694 ::ffff:192.168.10.250:1000 users:(("java",pid=5345,fd=229))
UNCONN 0 0 :::11001 :::* users:(("java",pid=5345,fd=227))
Any message coming from 192.168.10.250 for an incoming port of 11001 or 57694 will be captured. Next time openHAB restarts that 57xxx port will almost certainly be something else, and it’ll listen on that instead. The udp:updatewithresponse setting in openhab.cfg determines if the replies on that outgoing binding are taken in or ignored.
Those that are more observant and reading along, will have spotted that I mentioned incoming data will be arriving on port 1001, yet my configuration is for 11001. Neither of those are typos. The problem with 1001 is that it’s less than 1024, making it a privileged port and since openHAB doesn’t run as “root” on my server, it cannot listen on port 1001. So instead since it’s running on Linux and iptables really makes this sort of thing easy, I have an iptables rule in the PREROUTING chain of the nat table to redirect incoming udp/1001 traffic to udp/11001. Done like this:
iptables -A PREROUTING -p udp --dport 1001 -j REDIRECT --to-ports 11001
That last one took me a while to solve, because it didn’t even occur to me that it was a privileged port issue, and just like you I couldn’t make openHAB listen on the right port, no matter what I tried.
Alex.
Hi There,
Don’t know if this is any help but I had to specify ports only to listen to as OpenHAB wouldn’t recieve when I specified IP:Port.
E.G. Contact Ensuite_Motion “Ensuite Motion” (Ensuite, Motion) {udp="<[:8282:'REGEX(.(CLOSED|OPEN).*)’]"}
Occasionaly I could get it working but it would eventually fail. All of my inputs from around the house come in via this method now and it works great.
Alex, your answer cleared the cloud I had in my mind and I’ve even realized that it was everything already in the OpenHab wiki, if only I had read it…
My problem was in the missing info in the openhab.cfg file:
udp:updatewithresponse=true udp:charset=ASCII udp:port=5006
Thanks,
Andrea
Hello,
I can send a command through the TCP Bindings and I can get the expected data correctly (verified with Wireshark:
).Here is my setup:
-> my .cfg:
tcp:port=22222
tcp:postamble=\n
tcp:updatewithresponse=true
tcp:charset=ASCII
-> my .items:
String JavaMeteo "Jav Met [%s]" (gRDC) {tcp=">[172.16.128.112:22222:'REGEX((.*))']"}
String JavaMeteo_receive "Jav Met recev [%s]" (gRDC) {tcp="<[172.16.128.112:*:'REGEX((.*))']"}
-> my .rules:
rule "TEST Davis"
when
Item TESTDavis received command
then if (receivedCommand==ON){
JavaMeteo.sendCommand("LOOP 1")
Thread::sleep(1000)
logInfo("TestJS","JS : " + transform("JS", "MeteoVantage.js", JavaMeteo.state.toString))
}else{
JavaMeteo.sendCommand("LAMPS 0")
Thread::sleep(1000)
logInfo("TestJS","JS : " + transform("JS", "MeteoVantage.js", JavaMeteo.state.toString))
}
end
-> MeteoVantage.js
// Wrap everything in a function
(function(i) {
return (i)+2;
})(input)
// input variable contains data passed by openhab
-> my result:
Launching the openHAB runtime...
osgi> 2016-06-02 11:39:57.574 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.2).
2016-06-02 11:39:58.207 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
2016-06-02 11:39:58.445 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Disco very initialization completed.
2016-06-02 11:39:59.767 [INFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest
2016-06-02 11:40:08.030 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'Maison.sitemap'
2016-06-02 11:40:08.133 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'myopenhab.persist'
2016-06-02 11:40:08.177 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'Maison.script'
2016-06-02 11:40:08.232 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'Maison.items'
2016-06-02 11:40:08.724 [INFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /classicui/openhab.app
2016-06-02 11:40:12.826 [INFO ] [t.AbstractSocketChannelBinding] - The maximum buffer will be set to the default value of 1024
2016-06-02 11:40:12.826 [INFO ] [t.AbstractSocketChannelBinding] - The interval to retry connection setups will be set to the default value of 5
2016-06-02 11:40:12.827 [INFO ] [t.AbstractSocketChannelBinding] - The cron job to reset connections will be set to the default value of 0 0 0 * * ?
2016-06-02 11:40:12.828 [INFO ] [t.AbstractSocketChannelBinding] - The setting to queue write operation until a channel gets connected will be set to the default value of true
2016-06-02 11:40:12.829 [INFO ] [t.AbstractSocketChannelBinding] - The setting to share channels within an Item will be set to the default value of true
2016-06-02 11:40:12.829 [INFO ] [t.AbstractSocketChannelBinding] - The setting to share channels between the items with the same direction will be set to the default value of true
2016-06-02 11:40:12.830 [INFO ] [t.AbstractSocketChannelBinding] - The setting to share channels between directions will be set to the default value of true
2016-06-02 11:40:12.831 [INFO ] [t.AbstractSocketChannelBinding] - The setting to use address masks for incoming connections will be set to the default value of true
2016-06-02 11:40:12.832 [INFO ] [t.AbstractSocketChannelBinding] - The refresh interval of the worker thread will be set to the default value of 250
2016-06-02 11:40:12.833 [INFO ] [t.AbstractSocketChannelBinding] - Listening for incoming connections on /0:0:0:0:0:0:0:0:22222
2016-06-02 11:40:12.836 [INFO ] [.service.AbstractActiveService] - TCP Refresh Service has been started
2016-06-02 11:40:12.836 [INFO ] [t.protocol.internal.TCPBinding] - The maximum time out for blocking write operations will be set to the default vaulue of 3000
2016-06-02 11:40:12.837 [INFO ] [t.protocol.internal.TCPBinding] - The blocking nature of read/write operations will be set to the default vaulue of false
2016-06-02 11:40:12.839 [INFO ] [t.protocol.internal.TCPBinding] - The preamble for all write operations will be set to the default vaulue of ""
2016-06-02 11:40:12.840 [INFO ] [t.AbstractSocketChannelBinding] - Connecting the channel Channel [item=JavaMeteo, command=0, direction=OUT, remote=/172.16.128.112:22222, buffer=, isBlocking=false, isReconnecting=false, channel=, host=172.16.128.112, port=22222]
2016-06-02 11:40:12.841 [WARN ] [t.AbstractSocketChannelBinding] - When using address masks we will not verify if we are already listening to similar incoming connections
2016-06-02 11:40:12.842 [INFO ] [t.AbstractSocketChannelBinding] - We will accept data coming from the remote end 172.16.128.112:*
2016-06-02 11:40:12.860 [INFO ] [.p.rrd4j.internal.RRD4jService] - Removing invalid defintion component = null heartbeat = 0 min/max = 0.0/0.0 step = 0 0 archives(s) = [] 0 items(s) = []
2016-06-02 11:40:13.093 [INFO ] [t.AbstractSocketChannelBinding] - The channel for /172.16.128.112:22222 is now connected
2016-06-02 11:40:18.300 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'Maison.rules'
2016-06-02 11:40:27.269 [INFO ] [.myopenhab.internal.MyOHClient] - Connected to my.openHAB service (UUID = 6fe97abb-****-****-****-64b868d097b9, local base URL= http://localhost:8080)
2016-06-02 11:40:42.713 [INFO ] [runtime.busevents ] - TESTDavis received command ON
2016-06-02 11:40:42.988 [INFO ] [runtime.busevents ] - JavaMeteo received command LOOP 1
2016-06-02 11:40:42.995 [INFO ] [runtime.busevents ] - JavaMeteo state updated to LOOP 1
2016-06-02 11:40:43.611 [INFO ] [runtime.busevents ] - JavaMeteo state updated to LOO
2016-06-02 11:40:44.776 [INFO ] [rg.openhab.model.script.TestJS] - JS : LOO2
2016-06-02 11:40:52.998 [INFO ] [runtime.busevents ] - TESTDavis received command OFF
2016-06-02 11:40:53.016 [INFO ] [runtime.busevents ] - JavaMeteo received command LAMPS 0
2016-06-02 11:40:53.017 [INFO ] [runtime.busevents ] - JavaMeteo state updated to LAMPS 0
2016-06-02 11:40:53.862 [INFO ] [runtime.busevents ] - JavaMeteo state updated to OK
2016-06-02 11:40:54.070 [INFO ] [rg.openhab.model.script.TestJS] - JS : OK2
However, the return string is displayed instead of the string sent. Furthermore, no element is displayed in the return chain. Why?
Also, how can I extract and then parse the hexadecimal string that comes from my weather station please? Indeed, I wish to extract each element as indicated in the document on page 22: http://www.davisnet.com/support/weather/download/VantageSerialProtocolDocs_v261.pdf
Thank you in advance for your help.
Flavien