TCP - UDP

[Karel Goderis]

All,

I have spent the last few days rewriting the TCP and UDP bindings and things are advancing well. Both bindings now are truly TCP/UDP clients and servers, thus allowing incoming connections from remote ends, with "allowed" hosts defined in the Item definitions. Also, there is a mechanism built in (that can be configured) to share network connections between Commands in an Item (ex: Switch DemoSwitch "Switch" <heating> { tcp=">[ON:127.0.0.1:3336:'on_cmd'], >[OFF:127.0.01:3336:'off_cmd']"} would run over 1 single TCP connection), whereas by default a connection would set up for each individual Command. Also, it is possible to share connections between Items (ex: Switch DemoSwitch "Switch" <heating> { tcp=">[ON:127.0.0.1:3336:'on_cmd'], >[OFF:127.0.01:3336:'off_cmd']"}
Switch DemoSwitch2 "Switch2" <heating> { tcp=">[ON:127.0.0.1:3336:'on_cmd'], >[OFF:127.0.0.1:3336:'off_cmd']"}) -> 1 TCP connection) as well as between Directions (e.g. if an outbound connection to a given host:port is established, and the binding would be listening for an incoming connection coming from the same host:port, then that "listening" item will equally piggy-backing on the outbound connection). Furthermore, in the event of network failures, data send to remote devices can (configurable) be queued and sent later on when the network connection is restored. One will be able to define pre-amble and post-ambles to be attached bits of data that are sent over. For unstable remote devices, for which from time to time a connection needs to be reset it is now possible to define a cron job to do these resets. Maximum buffer sizes can be chosen and so forth.

All that being said, for those will live installations (e.g. Arduino boards etc), do you have any other particular requirements that should be covered in the "base" binding? Things that are specific to your setup or where the type of device can influence the behaviour of the TCP/UDP binding?

Thanks
K

[Jan Krause]

Great news, Karel.

when will you show some code? I really want to try it out. I have a development setup with the current "default" branch of openhab.

What about supporting binary data? 

I thought about something like this:

{ udp=">ON:192.168.0.123:3336:0x01,0x10,0xAF" } 

to specify data bytes as hex codes.

Jan

[Pauli Anttila]

Should escape sequence work out of the box

{ udp=">ON:192.168.0.123:3336:\u0001\u0010\u00AF" } 

Br,
Pali

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openhab.
> For more options, visit https://groups.google.com/groups/opt_out.
>

[IgorZ]

Karel, it sounds great!

as for me, I'm interesting in fixes for issue #362 and issue #360.

Субота, 31 серпня 2013 р. 12:46:48 UTC+3 користувач Pali написав:

[Karel Goderis]

In the binding I do process the pre-amble and post-amble so that one can use \r\n or alike for easier reading, but in the binding itself I de-escape the \ so that it becomes \r\n (as in 2 special characters instead of a 4 characters. e.g. \\\\r\\\\n after it is read by the configReader. 

With the example below additional 'de-escaping' will be necessary cause the core reader will provide "\\u001\\u..... " to the parseBindingConfig

K

[Karel Goderis]

All,

I have updated the TCP binding in my clone with transformation services, and I confirm that escaped binary data is working.

Regards

Karel

[tertiu...@gmail.com]

Hi Karel

Can you pls post a compiled project for this binding. I'm new to the development side of openhab and tried relentlessly to compile your clone to extract this updated binding, but no luck yet. thanks!

regards,

Tertius

[Karel Goderis]

Tertius

here is the jar file 

Karel

[tertiu...@gmail.com]

Thanks Karel

I gave it a go but got stuck with the following:

Openhab running on 10.0.0.7 and Arduino publishing UDP packet to Openhab on port 8888

OPENHAB Item:

String Arduino_TCP_rcv "ArduinoUDP [%s]" (Sensor_Arduino) {udp="<[10.0.0.51:8888]"}

Error:

18:19:29.264 ERROR o.o.m.i.b.AbstractGenericBindingProvider[:130] - Binding org.

openhab.binding.tcp.protocol.internal.UDPBinding threw an exception:

java.lang.NullPointerException: null

        at org.openhab.binding.tcp.protocol.internal.ProtocolGenericBindingProvi

der.getAllCommands(ProtocolGenericBindingProvider.java:439)

18:19:29.289 ERROR o.o.m.i.i.GenericItemProvider[:321] - Binding configuration o

f type 'udp' of item æArduino_TCP_rcvæ could not be parsed correctly.

org.openhab.model.item.binding.BindingConfigParseException: udp binding configur

ation must consist of four [config=java.util.regex.Matcher[pattern=(<|>)\[(.*):(

.*):'?(.*?)'?\] region=0,17 lastmatch=]] or five parts [config=java.util.regex.M

atcher[pattern=(<|>)\[(.*?):(.*?):(.*?):'?(.*?)'?\] region=0,17 lastmatch=]]

        at org.openhab.binding.tcp.protocol.internal.ProtocolGenericBindingProvi

der.parseBindingConfig(ProtocolGenericBindingProvider.java:148)

What is the syntax for sending and receiving UDP packets into a String or Switch?

I've tried using a * as well to indicate bidirectional comms.

regards,

Tertius

On Saturday, August 31, 2013 8:03:03 AM UTC+2, karel....@me.com wrote:

[Karel Goderis]

Tertius,

What I maybe forgot to tell more clearly is that the Wiki documentation of the binding is not up to date anymore. There are some syntax changes in the item definitions to take into account

 - direction is either > or <. The * is obsolete

 - there is now an additional "field" required in the definition to cope with the transformation rules

 - the default behaviour of the UDP binding is that if the transformation on recceived data failes, the the data received "as such" is used

so, 

could you try this:

String Arduino_TCP_rcv "ArduinoUDP [%s]" (Sensor_Arduino) {udp="<[10.0.0.51:8888:'']"}

(It contains '' at the end)

Karel

[tertiu...@gmail.com]

Thanks

So I tried it and I'm getting close. However there's something new. I initially thought that < would read data presented on the openhab system with the port I define, i.e 8888 in the case of {udp=">[10.0.0.51:8888:'']"} . I then discovered that port 25002 has been hardcoded for ipv4 connections. So, I changed my Arduino setup to publish to port 25002 on Openhab. The response from openhab is (21Closed- is the data I'm after):

20:23:38.917 WARN  o.o.b.t.AbstractDatagramChannelBinding[:1511] - Received data

 21Closed-

                                                                  from an undefi

ned remote end /10.0.0.51:8888. We will not process it

20:23:38.920 WARN  o.o.b.t.AbstractDatagramChannelBinding[:1542] - No channel is

 active or defined for the data we received from null. It will be discarded.

I've attached a screenshot of wireshark's capture. Do you know what I'm doing wrong here? Thanks for the help!

[Karel Goderis]

Hi Tertius

{udp="<[10.0.0.51:8888:'']"} reads as "Accept any UDP packet on my defined listener port (default 25002) coming from the remote with source address 10.0.0.51 and with source port 8888"

The default UDP port to listen on can be changed in openhab.cfg

in case of {udp=">[10.0.0.51:8888:'']"} OH will send out data to the remote end with destination IP  = 10.0.0.51 and destination port 8888. 

Now, if you only define an Item with ">" in your items.cfg then you should be aware of one thing: for some reason, in Java NIO, a DatagramChannel is not "readable", even if "connected" until data is sent from the initiating host to the remote end. In other words, if you just declare the item, the datagramchannel to the Arduino will be opened and connected, but if then the arduino sends data to OH first, for  some reason the underlying Java NIO does not consider the UDP "connection" to be readable. It only does so after the first byte sent from OH to the arduino. I don't know of this intended to be so, or either a bug in Java NIO, or just the intended behaviour of "nc", which I use to debug/test the binding.

All that being said, cfr the error message here below, do you only have a ">" definition in your items.cfg? then this behaviour would be normal if you send an UDP packet to the listener port, as for the binding, there is no Item bound to the listener port (e.g, no "<"), and thus, when data is received the binding fails to find a valid item that can receive data from ..51:8888. However, if you do only have a ">" defined, and if you first send data to the Arduino, then anything coming back will be correctly received

K

[Chris Jackson]

Hi Karel,

This seems a little confusing... I suspect I'm about to try and do something similar to Tertius. I have a number of mbed controllers to which I can connect to an IP port, and the controller will then send data in the format "<addr:111,type:222>\r\n".

So, I need the binding to connect to the mbed, and then receive incoming data.  Additionally, I need to be able to send commands in a similar way "<addr:111,cmd:OFF>\r\n".

I thought the following binding string would do the trick -:

tcp="<[192.168.2.21:1024:'REGEX(.*?<addr:17,battery:(.*?)>.*)'] >[OFF:192.168.2.21:1024:<addr:111,cmd,OFF>]"

I want it to connect to 192.168.2.21 port 1024, then receive the data (extracting the appropriate bit with the regex), and send the outgoing string if I hit the button (I'd add another ON command as well).

Is that correct - I suspect from your previous answer that this isn't how the binding works?

Thanks.

Chris

[Karel Goderis]

Hi Chris

the item definition you provide here below, is that for a String Item or an Switch Item? This is a bit ambiguous 

The binding does work indeed slightly different. You item definition will do the following:

tcp="<[192.168.2.21:1024:'REGEX(.*?<addr:17,battery:(.*?)>.*)'] >[OFF:192.168.2.21:1024:<addr:111,cmd,OFF>]"

 - When the binding is started, an outbound TCP connection is made to port 1024 of the embedded remote device with address 2.21.

 - (assume your item is a Switch) When you toggle the Switch to OFF in the OH user interface, the command <addr:111.....> will be sent to the remote device. 

 - When you toggle the Switch to ON in the OH user interface, nothing will happen

 - When the remote device replies with data, it will be used to match the <addr:111....>, and if it does match, then the Switch will be toggled to OFF (in other words, > = outbound - but bi-directional - connections)

 - When the remote device makes a connection to the listening port of the OH binding (default 25001), and when the source port equals 1024, then the OH binding will accept the connection. 

 - (assume your item  is a String) When data is received from this remote end, after it made the connection, dat will be REGEX'd and the resulting string will be used to update your String Item

Assume now that you have the following in your openhab.cfg:

tcp:directionssharedconnections=true

then the behaviour is slightly different: now the binding will "share"/"multiplex" inbound and outbound data over the same TCP connection for all items (in this case only 1), and sub-definitions within a single item (in this case 2), that make/receive connections to the same remote end. In other words, in this case the binding will:

 - make a connection to .2.21 when it starts

 - make use of that same TCP connection already established, for the <[192.168.2.21:1024:'REGEX(.*?<addr:17,battery:(.*?)>.*)'] of your item definition. So, then data is received from the remote device, it will

* be REGEX'd with <addr:17, ...> and the resulting string will be use to update or set the Item

* be matched with <addr,111....>, and if it matches, the Item will be updated with the OFF state

 - the OH will not accept any inbound connection from that remote end anymore as the Item is already "served" by the previously established tcp connection.

In short, < is to indicate that the OH can accept an incoming connection from defined remote end on its listener port, and then it will be able to receive and send data

> is to indicate that OH is rather a TCP client that will make an outbound connection to the defined remote end, on which it will be able to send and receive data

I sense that I have to write a very long and thorough wiki page for this binding ;-)

Karel

[Chris Jackson]

Hi Karel,

This definition is for a switch - as said, I do have an ON command as well, but I omitted it from the email to avoid cluttering it up (but I added confusion - sorry).

It looks like the binding will do what I want with the tcp:directionssharedconnections=true setting. I just want a single connection - OH needs to connect to 2.21:1024. The remote sends data when it changes (this actually comes in from wireless sensors), and OH can send commands when you press the switch button.

I think a long wiki (with a bunch of examples) is a must. The binding is quite flexible, but with flexibility comes confusion :)

Anyway, I'll give the above a try later in the week as I'm just about to head abroad for a few days for work :(

One other suggestion if I can - this probably isn't an issue for me (yet), but as I have a number of devices that I'll probably use the tcp binding for (with different ways of working), it might be nice to adjust some of the settings (in openhab,cfg) on a per link basis?

Thomas suggested I do this in the OWServer binding, so, in the openhab.cfg file, the interfaces are defined, along with the settings for this interface. Then, in the items file, instead of using the IP address, you use the interface reference. This has 2 advantages - 1) you can specify different settings for each interface, and 2) if you change an IP address, it just changes once in the openhab.cfg file, and not for dozens of files.

eg....

in openhab.cfg -:

tcp:device1.address=192.168.2.21

tcp:device1.port=1024

tcp:device1.timeout=20000

tcp:device1.blocking=false

tcp:device2.address=192.168.2.53

tcp:device2.port=1024

tcp:device2.timeout=40000

tcp:device2.blocking=true

in items -:

tcp="<[device1:'REGEX(.*?<addr:17,battery:(.*?)>.*)']  >[OFF:device1:<addr:111,cmd,OFF>]""

etc

For the way I'm using the binding, this would really be helpful, but I understand that others may be using it very differently (eg using port numbers to differentiate different items) in which case the above may not help (and may be more of a pain?). Anyway, just a thought... Thanks for producing the binding - it's a "difficult" one as I guess the "problem" with a generic TCP binding is everyone uses it slightly differently so it's probably difficult to keep everyone happy :)

Cheers

Chris

[Karel Goderis]

On 17 Sep 2013, at 11:32, Chris Jackson <ch...@cd-jackson.com> wrote:

One other suggestion if I can - this probably isn't an issue for me (yet), but as I have a number of devices that I'll probably use the tcp binding for (with different ways of working), it might be nice to adjust some of the settings (in openhab,cfg) on a per link basis?

Thomas suggested I do this in the OWServer binding, so, in the openhab.cfg file, the interfaces are defined, along with the settings for this interface. Then, in the items file, instead of using the IP address, you use the interface reference. This has 2 advantages - 1) you can specify different settings for each interface, and 2) if you change an IP address, it just changes once in the openhab.cfg file, and not for dozens of files.

eg....

in openhab.cfg -:

tcp:device1.address=192.168.2.21

tcp:device1.port=1024

tcp:device1.timeout=20000

tcp:device1.blocking=false

tcp:device2.address=192.168.2.53

tcp:device2.port=1024

tcp:device2.timeout=40000

tcp:device2.blocking=true

in items -:

tcp="<[device1:'REGEX(.*?<addr:17,battery:(.*?)>.*)']  >[OFF:device1:<addr:111,cmd,OFF>]""

etc

For the way I'm using the binding, this would really be helpful, but I understand that others may be using it very differently (eg using port numbers to differentiate different items) in which case the above may not help (and may be more of a pain?). Anyway, just a thought... Thanks for producing the binding - it's a "difficult" one as I guess the "problem" with a generic TCP binding is everyone uses it slightly differently so it's probably difficult to keep everyone happy :)

Well, Indeed some configuration parameters could be applied to individual links, but if you don't mind I will attempt to do this on a long rainy afternoon somewhere in the future ;-) I first need to complete my building project and make sure the basics are running fine. 

[Unless someone else feels the urge to have a go at this]

K

[Chris Jackson]

Well, Indeed some configuration parameters could be applied to individual links, but if you don't mind I will attempt to do this on a long rainy afternoon somewhere in the future ;-) I first need to complete my building project and make sure the basics are running fine. 

[Unless someone else feels the urge to have a go at this]

Absolutely. For me, it's no problem. It's probably worth thinking about before hte next major release - just to avoid too many changes to the configuration formats....

Thanks for all your work :)

Cheers

Chris

[dave.sh...@gmail.com]

Hi Karel, great to see you're working on this... much appreciated!

I replaced my tcp addon with the jar file you provided here and got the following messages at startup and then a CPU loop:

08:08:02.670 INFO  o.o.u.w.i.s.WebAppServlet[:99] - Started Classic UI at /openhab.app
08:08:06.950 INFO  o.o.b.t.AbstractSocketChannelBinding[:716] - Listening for incoming connections on /0:0:0:0:0:0:0:0:25001
08:08:06.967 ERROR org.quartz.core.JobRunShell[:222] - Job AbstractDatagramChannelBinding.1ecb918-Select-1379660886960 threw an unhandled Exception:
java.lang.NullPointerException: null
        at org.openhab.binding.tcp.AbstractDatagramChannelBinding$SelectorJob.execute(AbstractDatagramChannelBinding.java:1387)
08:08:06.970 ERROR org.quartz.core.ErrorLogger[:2361] - Job (AbstractDatagramChannelBinding.1ecb918-Select-1379660886960 threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception.
        at org.quartz.core.JobRunShell.run(JobRunShell.java:224)
Caused by: java.lang.NullPointerException: null
        at org.openhab.binding.tcp.AbstractDatagramChannelBinding$SelectorJob.execute(AbstractDatagramChannelBinding.java:1387)
08:08:06.972 INFO  o.o.b.t.AbstractDatagramChannelBinding[:738] - Listening for incoming connections on /0:0:0:0:0:0:0:0:25002

I haven't got any tcp/udp items in my items file. Is there some default customisation of my conf file that I need to perform first? If I remove the addon and restart I don't get the messages (or the CPU loop). I'm running the latest 1.3 openhab.

Cheers

Dave

[Karel Goderis]

Dave

I can not bring back the line numbers with own source code because it got slightly modified since I posted the jar. Can you retry what you did with the jar file attached?

Just a question : are you in a situation whereby nothing is defined in .items but a remote end is already sending data to the listener port on the OH host?

Karel

[Karel Goderis]

Dave

could you open an issue for this on the issue list? Lets take the discussion off-line; I was not able to reproduce your problem doing the following on a "fresh" OH installation

 - empty demo.items

 - start OH

 - launch nc -v -D -u 127.0.0.1 25002  in a terminal (Mac OS X)

To me it behaved as it should (discarding all data received)

Karel

<org.openhab.binding.tcp_1.3.0.201309201244.jar>

[dave.sh...@gmail.com]

Thanks Karel

The new jar file doesn't give any errors, just the two "Listening on port 25001 and 25002" as expected.

I missed the message you said earlier about setting up a server on those ports so it can now act as a client and a server. Sorry about that, it all makes sense now! You use "nc" to act as a server, I'm on Windows so that won't work for me, so I will write a Perl script and try it out over the weekend.

My Openhab is still in a CPU loop though. Can this be caused by the code highlighted by Jan in this thread (I've copied an extract here...)

"in the ReadJob class you call 

    muxChannel.readSelector.selectNow() in a loop, until some data is received.

selectNow is a non blocking call and returns immediately, even when no data is available.

it.hasNext() returns false, and the loop starts again. That is a busy loop and gives you a high cpu usage.

I have tried it on windows and linux and i guess, selectNow() should act on Max OS X the same way (like the docs say).

Jan"

Thanks

Dave

[Karel Goderis]

WIll look into the loop, normally it should run only once and then finish the Job

k

[Chris Jackson]

Hi Karel,

I've tried running the binding, but no luck. There's nothing printed in the log, and when I look in the console, it shows the status is "starting", or <<Lazy>>. Is there anything else that is needed to get it to run?

I've tried it on my original 1.3 snapshot, but when that didn't work I changed to the 1.4 build (rebuilt snapshot from the GIT source).

Any thoughts appreciated.

Cheers

Chris

[marcel.v...@gmail.com]

Hi Karel,

Would this version also fix the issues issue #362 and issue #360.

I'm still stuck with errors whenever I use the TCP bindings. For testing I just use netcat to receive my updates ( I can see other programs connect to the port)

I try to control a switch with (sending a "a" or a "f0" text

{ tcp=">[ON:192.168.3.45:3001:a] >[OFF:192.168.3.45:3001:f0]" }

09:48:02.172 WARN  o.o.b.t.AbstractSocketChannelBinding[:1495] - The channel java.nio.channels.SocketChannel[closed] has encountered an unknown IO Exception: Co

nnection refused: no further information

09:48:07.174 INFO  o.o.b.t.AbstractSocketChannelBinding[:1347] - Attempting to reconnect the channel for /192.168.3.45:3001

Op vrijdag 20 september 2013 12:47:24 UTC+2 schreef karel....@me.com:

[Kevin Rasmussen]

I have not yet worked witht he TCP - UDP binding, but arent you missing a comma?:

 

{ tcp=">[ON:192.168.3.45:3001:a], >[OFF:192.168.3.45:3001:f0]" }

[Karel Goderis]

Marcel

Your remote host .3.45 is refusing the connection, as I understand. Is it listening on port 3001? At first sight this is not a problem of the binding.....

K

[jasonhe...@gmail.com]

Hi,

I have been using the old TCP binding from 1.2  in client mode but suffered with high CPU utilisation - something like 50% on i5 desktop. When I try this on my raspberry PI its at 100% CPU utilisation and so sluggish thats its useless on the rpi. Then I updated to Openhab 1.3 and this most recent TCP binding in this thread hoping to resolve this high CPU issue but with no luck. In this thread [https://groups.google.com/forum/#!searchin/openhab/tcp/openhab/hbIPcaW5gwE/Ps_px4_htNEJ] there is talk of a high CPU loop with selectNow and hasNext() methods. 

Is there any chance that this will be resolved in this updated TCP binding please?

Thanks

Jason

[Karel Goderis]

Yes - I will have a look at it

Admittedly in my Mac mini I have not this high cup load hence the reason I did not notice this issue during development. Can you open an issue for this ?

K

Sent from my iPhone

--

[Igor Zelenyi]

Hi Karel,

I would like to test your new TCP binding. Where can I download latest version?

Thank you,
Igor

[Karel Goderis]

The latest is on the official repo on github

K

Sent from my iPhone

--

[jasonhe...@gmail.com]

Hi Karel, 

Opened an issue for the high CPU utilisation here:

https://code.google.com/p/openhab/issues/detail?id=478&can=1&q=CPU%20utilisation

Hoping to get this resolved as I wanna get OH running on my Rpi. 

Thanks

Jason

[jasonhe...@gmail.com]

Hi Karel,

thanks, I see the high CPU usage on the TCP binding has been resolved in the Issues. Thanks for that. Any chance you can post a compiled jar file for it here. I have not setup the openhab development environment yet.

Thanks

Jason  

[Karel Goderis]

Well, in fact, there is now a parameter you can add to the openhab.cfg to control the time-out that is used to Select NIO Keys. I could not use a plain blocking select() as that would break the OH setup in the sense that the Quartz Job that does the heavy lifting is started before the parsing of the binding configurations, and thus, would block forever. The default value is 1000ms, but you can adjust that. 

Now that Kai has merged the changes into the main repo, you might have a look at https://openhab.ci.cloudbees.com/job/openHAB/ to get the latest zip with add-ons?

Karel

[marcel.v...@gmail.com]

Hi Karel,

I believe it was something else. (I was just listening with netcat -l -p 3001 and received other suff I send).
Anyway I updated to the 1.4 snapshot build of today and now the connection to the Philips living color lamp is happily working.

Great, Thanks

Op vrijdag 27 september 2013 15:13:03 UTC+2 schreef karel....@me.com:

[JNeureuther]

Hi Karel,

i've just scanned my computer with Sophos Endpoint Security and i got this: Virus/Spyware "Mal/JavaKC-B" found in "C:\Users\Julian\karelgoderis-tcpdebug\bundles\persistence\org.openhab.persistence.exec\target\classes\org\openhab\persistence\exec\internal\ExecService.class".

I don't want to say that this came from you, but maybe you can check this as Viruses/Spyware aren't too funny.

Regards,

Julian

[Karel Goderis]

Julian

that's funny

 - I have never used the exec binding

 - I clean/compile stuff

 - It affects Windows PC only; I operate in an 100% Apple environment

I will check as well

K

[Karel Goderis]

Julian

I just compiled the main repo from a clean base, and indeed, on my system Sophos also finds a threat in the same file. That's quite funny, it means we are producing really good code here ;-)

/me thinks is rather a coincidence, and nothing to worry about. 

Karel

On 06 Oct 2013, at 12:57, JNeureuther <julianne...@gmail.com> wrote:

[jasonhe...@gmail.com]

Hi,

I am trying a simple TCP client from OH 1.4.0 to a remote TCP Server listening on port 2100. 

Openhab.cfg has all commented out under the TCP section.

My item is: 

Switch temp "temp" {tcp=">[ON:172.22.78.12:2100:'OnData']"} 

My error is:

13:07:51.531 INFO  o.o.u.w.i.s.WebAppServlet[:99]- Started Classic UI at /openhab.app

13:07:55.328 ERROR org.quartz.core.JobRunShell[:222]- Job AbstractDatagramChannelBinding.2dec4d-Select-1381316875328 threw an unhandled Exception: 

java.lang.NullPointerException: null

at org.openhab.binding.tcp.AbstractDatagramChannelBinding$SelectorJob.execute(AbstractDatagramChannelBinding.java:1408)

at org.quartz.core.JobRunShell.run(JobRunShell.java:213)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)

13:07:55.343 ERROR org.quartz.core.ErrorLogger[:2361]- Job (AbstractDatagramChannelBinding.2dec4d-Select-1381316875328 threw an exception.

org.quartz.SchedulerException: Job threw an unhandled exception.

at org.quartz.core.JobRunShell.run(JobRunShell.java:224)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)

Caused by: java.lang.NullPointerException: null

at org.openhab.binding.tcp.AbstractDatagramChannelBinding$SelectorJob.execute(AbstractDatagramChannelBinding.java:1408)

at org.quartz.core.JobRunShell.run(JobRunShell.java:213)

... 1 common frames omitted

13:11:56.968 INFO  o.o.i.r.i.RESTApplication[:174]- Stopped REST API

13:12:00.968 INFO  o.o.u.w.i.s.WebAppServlet[:110]- Stopped Classic UI

13:12:00.968 ERROR org.quartz.core.JobRunShell[:222]- Job AbstractSocketChannelBinding.1064e39-Select-1381317120968 threw an unhandled Exception: 

java.lang.NullPointerException: null

at org.openhab.binding.tcp.AbstractSocketChannelBinding$SelectorJob.execute(AbstractSocketChannelBinding.java:1382)

at org.quartz.core.JobRunShell.run(JobRunShell.java:213)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)

13:12:00.968 ERROR o.o.b.t.AbstractSocketChannelBinding[:754]- An exception occurred while creating the Listener Channel on port number 25001 (Address already in use: bind)

13:12:00.968 ERROR org.quartz.core.ErrorLogger[:2361]- Job (AbstractSocketChannelBinding.1064e39-Select-1381317120968 threw an exception.

org.quartz.SchedulerException: Job threw an unhandled exception.

at org.quartz.core.JobRunShell.run(JobRunShell.java:224)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)

Caused by: java.lang.NullPointerException: null

at org.openhab.binding.tcp.AbstractSocketChannelBinding$SelectorJob.execute(AbstractSocketChannelBinding.java:1382)

at org.quartz.core.JobRunShell.run(JobRunShell.java:213)

... 1 common frames omitted

13:12:00.984 ERROR org.quartz.core.JobRunShell[:222]- Job AbstractDatagramChannelBinding.9b1e83-Select-1381317120968 threw an unhandled Exception: 

java.lang.NullPointerException: null

at org.openhab.binding.tcp.AbstractDatagramChannelBinding$SelectorJob.execute(AbstractDatagramChannelBinding.java:1408)

at org.quartz.core.JobRunShell.run(JobRunShell.java:213)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)

13:12:00.984 ERROR org.quartz.core.ErrorLogger[:2361]- Job (AbstractDatagramChannelBinding.9b1e83-Select-1381317120968 threw an exception.

org.quartz.SchedulerException: Job threw an unhandled exception.

at org.quartz.core.JobRunShell.run(JobRunShell.java:224)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)

Caused by: java.lang.NullPointerException: null

at org.openhab.binding.tcp.AbstractDatagramChannelBinding$SelectorJob.execute(AbstractDatagramChannelBinding.java:1408)

at org.quartz.core.JobRunShell.run(JobRunShell.java:213)

... 1 common frames omitted

13:12:00.984 ERROR o.o.b.t.AbstractDatagramChannelBinding[:775]- An exception occurred while creating the Listener Channel on port number 25002 (Address already in use: bind)

13:13:36.578 INFO  o.o.c.internal.CoreActivator[:92]- openHAB runtime has been started (v1.4.0).

[Karel Goderis]

Jason

From the log here below it seems that the tcp:port and udp:port items are defined in the .cfg file. 

Are you using the latest build of the TCP binding, because the line numbers where the exceptions occur do not match anything that could generate an exception in the source code?

Karel

[jasonhe...@gmail.com]

That the #504 build from cloudbees as earlier in this thread.
I was hoping not setup a dev environment but it seems like things are going that way.
Will build latest from github and report back.

[Karel Goderis]

I think cloudbees might be trailing the merge but I will check later tonight in detail

Sent from my iPhone

[Karel Goderis]

Hi Jason

I tried to replicate your problem. First of all I ow you an apology because I write my initial mail with a wrong branch checked out in Eclipse. Nevertheless, I can not replicate the problem, everything seem to function. I am also sure you are not on the latest version of the TCP binding as the exceptions are raised by the "Select" Quartz Job, which I  removed alltogether.

What I did was configure the TCP and UDP bindings to listen to ports 25001 and 25002, and then initiate a connection to it. that worked

I also copied your temp Item definition, but changed the Ip address to 127.0.0.1 and had "nc" run listening on port 2100. That worked equally

What I noticed from the logs is that you ran OH several times after each other: it is fact that when you bind a port/socket in java, and you abandon it, that there is a kind of timer that is tracked to release the port to other process on the OS. If you run OH too fast after each other, you get the kind of error message ("Address already in use")

K

[jasonhe...@gmail.com]

Hi Karel,

Have the latest from github checked out into dev environment but have some fundamental issues now: "the method getHostString() from the type InetSocketAddress is not visible" which is only in the tcp binding project. While I accept this challenge to dig a bit deeper, is it possible for you to send me the latest tcp binding jar file to test with. 

I tackle this challenge another day.

Yip, I have been restarting OH quite often during testing.  

[Karel Goderis]

I think you need to run it with JRE 1.7

Away from my PC now, will send jar later

K

Sent from my iPhone

--

[jasonhe...@gmail.com]

How extensive is the TCP 1.4.0 binding Regex functionality? I have been trying some standard Regex search patterns but OH seem to no like it much.
Heres my item:
String str  "str [%s]" {tcp=">[192.168.0.201:2100:'REGEX(([0-9]*$))']"}

which is supposed to match the last numbers but OH complains:

23:20:50.991 WARN  o.o.b.t.p.internal.TCPBinding[:173]- Can not parse input :,10,1,@A,1,1,4392                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               to match command ON on item st 
23:20:51.005 WARN  o.o.b.t.p.internal.TCPBinding[:173]- Can not parse input :,10,1,@A,1,1,4392                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               to match command OFF on item st 
23:20:51.022 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.IllegalArgumentException: given transformation function 'REGEX(([0-9' does not follow the expected pattern '<function>(<pattern>)'
    at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:239)
    at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
    at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
    at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
    at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
    at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
    at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)


Also if i rectify the Regex to something simple that OH is happy with like Regex(.*), then OH still gives errors until restarted.

Thanks
Jason

[Karel Goderis]

Very good question, but I do not have an answer for you, as I piggy-back on the Transformation services written by Thomas initially. So if there is a limitation, this limitation is the same as for other classes using the transformation services (e.g. that also copy/pasted the code that makes the call to the TransformationService. 

Thomas, any view on this, why this particular REGEX string is not working?

Jason, I also do not understand why the error on REGEX(.*) only goes away after a restart. the REGEX part of an item definition is not "used" to set-up TCP connections, so if only that part of the definition changes, the underlying socket should stay intact when reloading an .items file... weird.

Karel

[dave.sh...@gmail.com]

I've been following the development of this binding for a while and the latest changes seem the best and most stable so far. We really appreciate all the hardwork that's gone into it.

But am I being really stupid or missing something? I can't get the UDP bind to work at all.

So I have a simple switch that when switched on should send a command to a UDP port on a remote computer:

Switch Midroomsw1 "Midroom switch 1" { udp=">[ON:192.168.0.6:9760:'123,!R2D1F1'], >[OFF:192.168.0.6:9760:'987,!R2D1F0']"}

but all I get is an error:

08:20:35.605 ERROR o.o.b.t.AbstractDatagramChannelBinding[:963] - there is no channel that services [itemName=Midroomsw1, command=ON]

I've tried all variations but no success. This is running on the latest version 1.4.0 built from GITHUB on Saturday.

Dave

[Karel Goderis]

Dave

can you post or send more complete logs so that I can check in detail what happens? If not yet done, pls enable DEBUG level logging for the tcp binding  in the logback.xml files

The error sounds as if the binding did not open a channel for your remote host. Even when UDP, the underlying Java NIO has a connection oriented approach, so an UDP channel first has to be "connected"

it could be very well due a stupidity of me you know, I tend to develop/edit the TCP and UDP binding in parallel to keep them sychronized, could be that I missed something.

Kind Regards,

K

[Karel Goderis]

Dave

I had to explain this better - you have to add at least one "udp=" in the openhab.cfg and that is for example

udp:refreshinterval=250

If not, the binding will not be properly configured and will not start up

regards

Karel

On 14 Oct 2013, at 09:26, dave.sh...@gmail.com wrote:

[Daniel Dobos]

Hi Karel,

I have the same problem with TCP:

Switch Camera_test "Cam" (Camera) { tcp=">[ON:192.168.1.38:8888:'on']" }

results in:

07:36:42.067 ERROR o.o.b.t.AbstractSocketChannelBinding[:964] - there is no channel that services [itemName=Camera_test, command=ON]

also the receiving side is strange: 

String  Camera_MSG1 "Camera [%s]" (Camera) { tcp="<[192.168.1.38:1025:'']" }

opens the port 25001 (after uncommenting line in cfg, not before as far as I remember), messages are accepted but don't show up in the eventbus ...

DEBUG doesn't give any additional hints.

Cheers,

Daniel

[Karel Goderis]

Daniel

I will check this later tonight. Does your log contains anything particular related to the Transformation services (e.g. exceptions etc)? incoming string should be passed on after going through the transformation service "as is"; unlike other Item Types they are not matched with the string defined between ' ' in order to trigger the defined Command. I usually had REGEX(.*) between the ' ' in my tests, I might have missed something here.

the port number must indeed be defined in the .cfg as some other bindings in the making, that derive from the same abstract class, do not need a listening port, so I made this optional.

K

[dave.sh...@gmail.com]

Adding the udp:refreshinterval to the config file kick started the activation of the module and the two switch statements I posted earlier worked wonderfully.

Daniel, add a tcp:refreshinterval=250 to your config file and restart. Should work.

I have another issue, but I'll post that later!

[Karel Goderis]

I will update the wiki shortly, I hope so. That will clarify a lot of things

Glad you can test in real-world setting, as my setup is still  - despite all binding development - very virtual (moving in 2 weeks time and still a lot of KNX stuff to be set up). Let me know what you have found and will look at it.

Regards

K

[dave.sh...@gmail.com]

Karel

spent most of the weekend playing with the latest version of the binding. Everything I tried has worked successfully. No errors to report!

Any errors I got were with my coding (mixing up tcp with udp , getting driections/commands wrong). I think once the wiki is updated everyone should be able to use this with no issues.

Excellent work.

Thanks

Dave

[Karel Goderis]

The wiki was updated in the meantime

Kai, noticed you populated the Wiki pages on GitHub. Do we continue to edit the code.google.com ones, or we switch as of now?

K

[Kai Kreuzer]

Hi Karel,

Kai, noticed you populated the Wiki pages on GitHub. Do we continue to edit the code.google.com ones, or we switch as of now?

You seem to watch all my moves ;-)

Yes, indeed, I tried to port our wiki to GitHub last night, but I was only half successful - the automatic conversion left many pages in quite an ugly state. Instead of fixing this all manually right now, I decided to leave the official wiki at Google Code for the moment. The documentation will anyhow require a complete overhaul when we split off the core to Eclipse SmartHome. So my suggestion is to move the wiki only when this split is done (still due this year).

My next effort would be moving the issues - for referencing issues in commits & pull requests, it would be much nicer to have them at GitHub. I'll investigate this…

Regards,

Kai

[maarte...@gmail.com]

Where can I download the latest version of this binding?

Op zaterdag 31 augustus 2013 08:03:03 UTC+2 schreef karel....@me.com:

[daniel.go...@gmail.com]

Karel once wrote me in an email:

"the latest changes are now in the official repo on github.com. Alternatively you can download snapshot builds at https://openhab.ci.cloudbees.com/job/openHAB/"

[maarte...@gmail.com]

I've installed the latest snapshot. But I can't get it working.

Item:

Switch test {tcp="<[ON:192.168.1.8:*:'on_cmd',OFF:192.168.1.8:*:'off_cmd']"}

openhab.cfg

############################ TCP/UDP Binding ##################################

#

tcp:refreshinterval=250

tcp:port=23

tcp:retryinterval=5

#tcp:buffersize=1024

tcp:timeout=3000

tcp:itemsharedconnections=true

tcp:addressmask=true

log:

13:29:07.940 INFO  o.o.b.t.AbstractSocketChannelBinding[:1360] - Received connection request from /192.168.1.8:36937

13:29:07.941 INFO  o.o.b.t.AbstractSocketChannelBinding[:1369] - 192.168.1.8:* is an allowed masked remote end. The channel will now be configured

13:29:08.195 ERROR o.o.c.s.AbstractActiveService[:195] - Error while executing background thread TCP Refresh Service

java.lang.NullPointerException: null

at java.util.regex.Matcher.getTextLength(Matcher.java:1234)

Op vrijdag 25 oktober 2013 13:02:58 UTC+2 schreef daniel.go...@gmail.com:

[Karel Goderis]

Maarten

you are still using the item binding configuration "old style" which does not take into account the Tranformation rules; the Wiki was updated in the meantime to reflect the changes in syntax

Kind Regards

Karel

[maarte...@gmail.com]

How do I setup a transformation rule? I Can't find specific information in the wiki.

Op vrijdag 25 oktober 2013 14:20:34 UTC+2 schreef karel....@me.com:

[Abhishek Bathla]

Hi all,

Can you tell me if openhab works for ipv6?

Thanks

abhishek bathla 

[jorg]

Hey Karel

We are trying out your new TCP Binding together with the nightly build. I'm trying to send data to openhab through a outgoing connection and transformations via a mapping file.

I'm having the problem that the incoming string in TCPBinding.parseBuffer(String, Command, Direction, ByteBuffer) the String theUpdate contains as many spaces as the package size. Mean I had a short command String and over 1000 spaces behind it. With that transformation for the mapping did not find a match in the mapping file. I would suggest to add a trim to the String theUpdate. (See attached patch)

[dario....@souliss.net]

Hi,

I'm following openHAB from long time but never joined really the discussion about, this binding looks interesting and I've seen that is intended also for integration with Arduino based devices. Me and a small community are running an open-source project that designed a framework that interconnect Arduino based hardware for home automation and we would like to integrate it with openHAB.

Basically is all a matter of UDP using an event based (pub/sub) protocol that we have defined, then a node acts as gateway to transfer data to others including nodes that runs over wireless point-to-point and RS-485. Is not only a matter of networking, is included whatever needed for home automation, including logics and an Android application with direct access to the nodes.

For the integration with openHAB there are two ways, I can include a gateway to interface with this TCP/UDP binding (is it working in polling, right?) or build a binding that move our pub/sub protocol (so, no longer polling) on openHAB.

Just for evaluation, does someone has a library or an example code that use this binding on a microcontroller? It will be quite simpler for me to understand the feasibility from the code directly.

Right now I'm looking for people that would help in the development of this binding, if someone in this discussion is interested in helping on that topic, it would be great.

Just for reference, the project were I'm involved in is there
www.souliss.net
http://code.google.com/p/souliss/

Thanks.

Regards,
Dario.

[Karel Goderis]

Hi Dario

>
>
>
> For the integration with openHAB there are two ways, I can include a gateway to interface with this TCP/UDP binding (is it working in polling, right?) or build a binding that move our pub/sub protocol (so, no longer polling) on openHAB.

the binding is not really polling in a classical sense. It is based on the Java NIO library, and uses selectionKeys to check the TCP or UDP channels that are ready to be read or written to.

Karel

[Karel Goderis]

Thank you. good suggestion, I will incorporate that

K

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.

<tcp-binding-trim.patch>

[Di Maio, Dario]

Hi,

between the openHAB binding and the target device, how communication works? I mean, does the binding call periodically for new data or wait on a listening socket for new data?

Thanks,
Dario.

Karel

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/qJo_48FDMGA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Karel Goderis]

Well, depends what layer of the OSI stack you are considering.

At the network layer the tcp binding/OH can act as a TCP/UDP client as well as server, hence the definition of the listening port in the .cfg. That means that once a connection is setup, either outbound (OH connecting to your hub), or inbound (the hub connecting to OH), basically any type of communication is enabled. That is, it is up to the "application layer" to implement a meaningful protocol. In your case that means that you either build some smart Scripts or Rules in OH that push data to the other end, or you either have some logic in the remote end that deals with protocol specific things. When your remote end would send something to OH, OH will take the data, parse it and trigger the defined Command for the relevant Item. The other way around, if you post a Command, or Update an Item, the binding will send, in function of what you have defined in the binding configuration, some data to the other side. So, in short, it does not poll for data at all. If you need something more complex that can not be dealt with in Scripts or Rules, then you will have to write a new Binding in java, but that is rather straight forward  as you can extend an Abstract class that does the heavy lifting. The current TCPBinding is "merely" an example of how a TCP-based binding could look like; it is just an generalized implementation with some configuration possibilities like pre-pending strings etc. For example, I will be pushing a binding for IRTrans devices, based on this Abstract class, shortly.

Regards

K

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Di Maio, Dario]

That's what I was looking for, thanks for the clarification.

Regards,
Dario.

[Di Maio, Dario]

That's what I was looking for, thanks for the clarification.

Regards,
Dario.

From mobile.

[chux...@gmail.com]

Karel,

I am using the latest snapshot 1.4.0 build #522 with both Runtime and Tcpbinding. I always get error trying to receive string data from remove tcp server and assign value to String Item in OH. I have spent some day to look for info in forum but no luck, so please help me.

I have OH running on my computer and successfully send string to Arduino via TCP binding. The following are contents in my config files :

default.config :

Switch ceiling "Ceiling"  {tcp=">[ON:192.168.0.4:4440:MAP(ceiling.map)],>[OFF:192.168.0.4:4440:MAP(ceiling.map)]"}

String str [Task : %s] {tcp="<[192.168.0.4:4440:'REGEX(.*)']"}

default.sitemap

sitemap default label="Menu"

{

Frame label="Response message" {

Text item=str

}

Frame label="Switch" {

Text label="Ground floor" icon="groundfloor"{

Switch item=ceiling

}

}

}

ceiling.map

ON=on_G0

OFF=off_G0

default.rules

...

rule "Receive state change"

when 

Item str received update 

then

println("Receiving string!")

end

I can send the string "on_G0/off_G0" to remove end (Arduino) successfully by switching ON/OFF. As soon as Arduino received the string, it responsed some data in string. I have seen that string received successfully in cmd of OH, but always with error :

WARN o.o.c.t.i.s.MapTransformationService - Could not find a mapping for 'some string data' in the file 'ceiling.map'

WARN o.o.b.t.p.internal.TCPBinding - Can not parse input 'some string data' to match command ON on item ceiling

WARN o.o.c.t.i.s.MapTransformationService - Could not find a mapping for 'some string data' in the file 'ceiling.map'

WARN o.o.b.t.p.internal.TCPBinding - Can not parse input 'some string data' to match command OFF on item ceiling

The string did not bind to String Item

What should I do to solve this error and successfully bind the received string to String Item?

Many thanks

Hy

[Karel Goderis]

Hello Hy

I have some questions for you:

1. Does the Arduino set up the connection to OH, or is it OH connecting to the Arduino?

2. If the latter, did you enable the setting tcp:directionssharedconnections=true in the default openhab .cfg? doing so will make the binding "share" TCP connections not only between commands in a single Item (your "ceiling" ON and OFF), but also between Items, even if they are defined to be in a different direction. Indeed, as I read your config, OH will connect to the Arduino for the Ceiling Item (because you used ">" denoting an outbound connection), but for the "str" Item, the binding expects and incoming connection from the Arduino (since you used "<" for inbound connections), unless you set the setting as mentioned here above.

As with respect to the Errors you marked in red, inbound and outbound data received go through the same Transformation rule, e.g. MAP in your case. Unless the data returned by the Arduino is of any importance, you can basically ignore the errors. If you need to do somehting with that data, then you have to define it in the same MAP. But as you figured out, you can also capture that information in another Item like a string

Kind Regards

Karel

[Trung Trần]

Hi Karel,

Thank you for your answer, I dont know that the TCP Binding is now both acting as client and server, I remember that it is just client somewhere in wiki. Now, I can receive string data from remote end in OH, successfully using the data to update OH interface accordingly to physical switch.

Have a nice weekend!

[jason hector]

Hi Karel, 

I think I found a bug in the new Tcp binding:

When I edit my items file the errors below are created. I then have to restart OH. Then the errors are gone until I edit items again.

Im running build 505 from Cloudbees.

My item look like:

String rawEmon "rawEmon [%s]" { tcp=">[192.168.0.10:2001:'REGEX((.*))']" }

And my openhab.cfg tcp settings are:

################################# TCP - UDP Binding ######################################

### all parameters can be applied to both the TCP and UDP binding unless specified otherwise

# Port to listen for incoming connections

tcp:port=2500

# Cron-like string to reconnect remote ends, e.g for unstable connection or remote ends

#tcp:reconnectron='0 0 0 * * ?'

# Interval between reconnection attempts when recovering from a communication error, in seconds

#tcp:retryinterval=3

# Queue data whilst recovering from a connection problem (TCP only)

#tcp:queue=true

# Maximum buffer size whilst reading incoming data

#tcp:buffersize=1024

# Share connections within the Item binding configurations

tcp:itemsharedconnections=true

# Share connections between Item binding configurations

tcp:bindingsharedconnections=true

# Share connections between inbound and outbound connections

tcp:directionssharedconnections=true

# Allow masks in ip:port addressing, e.g. 192.168.0.1:* etc

tcp:addressmask=true

# Pre-amble that will be put in front of data being sent

#tcp:preamble=''

# Post-amble that will be appended to data being sent

#tcp:postamble='\r\n'

# Perform all write/read (send/receive) operations in a blocking mode, e.g. the binding will wait for a reply from the remote

# end after data has been sent

#tcp:blocking=false

# timeout, in milliseconds, to wait for a reply when initiating a blocking write/read operation

#tcp:timeout=3000

# Update the status of Items using the response received from the remote end (if the remote end sends replies to commands)

#tcp:updatewithresponse=true

Her is the error:

21:18:35.748 INFO  o.o.m.c.i.ModelRepositoryImpl[:117]- Refreshing model 'jason.items'
21:18:35.753 DEBUG o.o.m.r.i.engine.RuleEngine[:305]- Executing rule 'emonRawRx'
21:18:35.768 DEBUG o.o.m.i.i.GenericItemProvider[:154]- Read items from model 'jason.items'
21:18:35.786 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_Vrms' -> '236.909999999999996589394868351519107818603515625'
21:18:35.795 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct1_realPower' -> '821.3899999999999863575794734060764312744140625'
21:18:35.797 DEBUG o.o.m.r.i.engine.RuleEngine[:305]- Executing rule 'Summary Housect1realPower'
21:18:35.807 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct2_realPower' -> '190.6200000000000045474735088646411895751953125'
21:18:35.826 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct3_realPower' -> '688.6000000000000227373675443232059478759765625'
21:18:35.835 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct4_realPower' -> '-37.9500000000000028421709430404007434844970703125'
21:18:35.838 DEBUG o.o.m.r.i.engine.RuleEngine[:305]- Executing rule 'Summary HouseVrms'
21:18:35.848 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct5_realPower' -> '-26.089999999999999857891452847979962825775146484375'
21:18:35.863 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct1_kwh' -> '810.0948694444447255591512657701969146728515625'
21:18:35.873 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct2_kwh' -> '178.507567850637627770993276499211788177490234375'
21:18:35.883 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct3_kwh' -> '616.298940277777774099376983940601348876953125'
21:18:35.891 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct4_kwh' -> '-15.7267099811676107634639265597797930240631103515625'
21:18:35.899 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'House_ct5_kwh' -> '-7.51965204678362653112344560213387012481689453125'
21:18:35.907 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'DailyRamp_ct1_kwh' -> '24093.86881563713905052281916141510009765625'
21:18:35.915 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'Daily_ct1_kwh' -> '16957.13824366825792822055518627166748046875'
21:18:35.922 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'MonthlyRamp_ct1_kwh' -> '227662.43402579266694374382495880126953125'
21:18:35.930 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'Monthly_ct1_kwh' -> '9523.5237080988590605556964874267578125'
21:18:35.938 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:00 PM' for item 'Monthly_kwh_units' -> '-218550.37577784221502952277660369873046875'
21:18:35.946 DEBUG o.o.c.p.i.PersistenceManager[:397]- Restored item state from 'Nov 14, 2013 9:18:01 PM' for item 'geyserOnOff' -> '0'
21:18:35.996 DEBUG o.o.b.t.AbstractSocketChannelBinding[:1303]- Setting up the outbound assigned channel Channel [item=rawEmon, command=3, direction=OUT, remote=/192.168.0.10:2001, buffer=, isBlocking=false, isReconnecting=false, channel=/192.168.0.10:59087::/192.168.0.10:2001, host=192.168.0.10, port=2001] 
21:18:36.006 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct5_realPower' with state '-26.089999999999999857891452847979962825775146484375' in rrd4j database
21:18:36.010 DEBUG o.o.b.t.AbstractSocketChannelBinding[:1303]- Setting up the outbound assigned channel Channel [item=rawMote, command=2, direction=OUT, remote=/192.168.0.120:2110, buffer=, isBlocking=false, isReconnecting=false, channel=/192.168.0.10:59088::/192.168.0.120:2110, host=192.168.0.120, port=2110] 
21:18:36.031 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct5_realPower' with persistence service 'rrd4j' took 28ms
21:18:36.039 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct2_realPower' with state '190.6200000000000045474735088646411895751953125' in rrd4j database
21:18:36.045 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:236)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)
21:18:36.091 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct2_realPower' with persistence service 'rrd4j' took 53ms
21:18:36.113 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct4_realPower' with state '-37.9500000000000028421709430404007434844970703125' in rrd4j database
21:18:36.155 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct4_realPower' with persistence service 'rrd4j' took 43ms
21:18:36.163 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct3_realPower' with state '688.6000000000000227373675443232059478759765625' in rrd4j database
21:18:36.210 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct3_realPower' with persistence service 'rrd4j' took 48ms
21:18:36.217 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_Vrms' with state '238.49' in rrd4j database
21:18:36.247 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_Vrms' with persistence service 'rrd4j' took 31ms
21:18:36.255 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct1_realPower' with state '882.88' in rrd4j database
21:18:36.311 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct1_realPower' with persistence service 'rrd4j' took 57ms
21:18:36.357 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:236)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)
21:18:36.668 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:236)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)
21:18:37.731 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:236)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)
21:18:38.003 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct5_realPower' with state '-26.089999999999999857891452847979962825775146484375' in rrd4j database
21:18:38.041 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:236)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)
21:18:38.094 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct5_realPower' with persistence service 'rrd4j' took 92ms
21:18:38.107 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct2_realPower' with state '190.6200000000000045474735088646411895751953125' in rrd4j database
21:18:38.191 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct2_realPower' with persistence service 'rrd4j' took 85ms
21:18:38.198 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct4_realPower' with state '-37.9500000000000028421709430404007434844970703125' in rrd4j database
21:18:38.238 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct4_realPower' with persistence service 'rrd4j' took 41ms
21:18:38.245 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct3_realPower' with state '688.6000000000000227373675443232059478759765625' in rrd4j database
21:18:38.266 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct3_realPower' with persistence service 'rrd4j' took 22ms
21:18:38.273 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_Vrms' with state '238.49' in rrd4j database
21:18:38.325 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_Vrms' with persistence service 'rrd4j' took 53ms
21:18:38.333 DEBUG o.o.p.r.internal.RRD4jService[:141]- Stored 'House_ct1_realPower' with state '882.88' in rrd4j database
21:18:38.352 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:236)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)
21:18:38.378 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'House_ct1_realPower' with persistence service 'rrd4j' took 46ms
21:18:38.663 ERROR o.o.c.s.AbstractActiveService[:195]- Error while executing background thread TCP Refresh Service
java.lang.NullPointerException: null
at java.util.regex.Matcher.getTextLength(Unknown Source)
at java.util.regex.Matcher.reset(Unknown Source)
at java.util.regex.Matcher.<init>(Unknown Source)
at java.util.regex.Pattern.matcher(Unknown Source)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.splitTransformationConfig(TCPBinding.java:236)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.transformResponse(TCPBinding.java:254)
at org.openhab.binding.tcp.protocol.internal.TCPBinding.parseBuffer(TCPBinding.java:162)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.parseChanneledBuffer(AbstractSocketChannelBinding.java:1019)
at org.openhab.binding.tcp.AbstractSocketChannelBinding.execute(AbstractSocketChannelBinding.java:1700)
at org.openhab.core.binding.AbstractActiveBinding$BindingActiveService.execute(AbstractActiveBinding.java:176)
at org.openhab.core.service.AbstractActiveService$RefreshThread.run(AbstractActiveService.java:193)

[Karel Goderis]

The line numbers do not really correspond with the latest version of the main repository, so I  can not really pinpoint where the problem lies

but try REGEX(.*) instead of REGEX((.*)) 

Karel

[dr.cleme...@gmail.com]

Karel, All, 

I am afraid I need some clarification: 

Here is what I am trying to do (in the "grand scheme of things"): Trying to avoid writing an Enocean/TCP binding. 

In my setup I have to Ethernet/Enocean Gateways (Thermokon STC) that encapsulate the Enocean Protocol into TCP (strangely mapping every byte they receive from 

their binary version into two characters), so that a telegram (in both directions) has a form of "A55A0B07009B640E000565E80071" with the first four characters being a sync sequence and the last

a checksum. Also, in the last few bytes the actual enocean device is encoded. 

Now, what I could have tried is to extend the existing enocean binding, to make it communicate through TCP, but the binding is somewhat incomplete (so far it is unidirectional). 

I have an installation at home that has a number of switches in each room as well as thermostats (with and without controls and with and without humidity sensors). Also, 

and this is where the serial enocean binding doesn´t help, I have enocean actors for light switching and heating control distributed in a number of places in the house. 

Ideally, the TCP binding with all of its nice functionality and configurability would form a basis to put another binding on top. As fas as I understand the TCP bindings state is, that it binds

a destination(or source) to an individual item. While this works for many cases, it does not deal with an encapsulated protocol well. 

So I decided to fiddle around with a number of rules and some pseudo-functions that I wrote as lambda-expressions to see how far I would get with understanding the protocol using the rule system, basically using the idea of triggering a rule on a single item, when data comes in and dispatch it to the actual items from there (this kind of works already, but needs to be cleaned up). 

For sending data to my gateways I need to encode the destination and the commands in a string add preamble and checksum and send it out to the gateway. 

Here is where I am stuck. I have created my telegrams (in a rule, one type for on, on type for off) and now want to send it out to the gateway. 

It might be just a simple thing that I am missing. I would like to send the generated string "as is" to the destination, but get errors of the type: 

14:07:38.304 WARN  o.o.c.i.e.EventPublisherImpl[:80] - given new state is NULL, couldn't post update for 'EnoceanOutgoing'

I have tried a few versions of the item definition, using Strings and Switches. 

Here is what I currently have: 

Switch EnoceanOutgoing "Outgoing Gateway" {tcp=">[ON:127.0.0.1:5000:'REGEX((.*))'],>[OFF:127.0.0.1:5000:'REGEX((.*))']"}   // receiver nc on localhost started with 

"nc -l -i 10 127.0.0.1 5000"

var String teleg = ""

postUpdate(DemoTCP5,"Constructing telegram")

teleg = constructTelegram.apply("000102030405060708090A")

postUpdate(DemoTCP5,"Trying to send "+ teleg) // to debug that telegram is constructed successfully

EnoceanOutgoing.sendCommand(teleg) // causes Error

sendCommand(EnoceanOutgoing,ON)// is received by nc 

Here is the output (there are a few debug posts in some Items from the telegram building, pls. ignore

14:33:03.083 INFO  o.o.m.c.i.ModelRepositoryImpl[:97] - Refreshing model 'demo.rules'

14:35:12.097 INFO  runtime.busevents[:22] - Enocean_0005393A received command ON

14:35:12.098 DEBUG o.o.m.r.i.engine.RuleEngine[:285] - Executing rule 'enoOutgoingSwitch' 

14:35:12.272 INFO  runtime.busevents[:22] - Enocean_00228A61 received command ON

14:35:12.283 INFO  runtime.busevents[:26] - DemoTCP5 state updated to Constructing telegram

14:35:12.913 INFO  runtime.busevents[:26] - DemoTCP7 state updated to after checksum 000102030405060708090A37

14:35:12.928 INFO  runtime.busevents[:26] - DemoTCP5 state updated to Trying to send A55A000102030405060708090A37

14:35:12.933 WARN  o.o.c.i.e.EventPublisherImpl[:58] - given command is NULL, couldn't send command to 'EnoceanOutgoing'

14:35:12.940 DEBUG o.o.c.t.i.s.RegExTransformationService[:42] - about to transform 'ON' by the function '(.*)'

14:35:12.940 DEBUG o.o.b.t.p.internal.TCPBinding[:243] - transformed response is 'ON'

14:35:12.941 INFO  runtime.busevents[:22] - EnoceanOutgoing received command ON

14:35:12.941 INFO  runtime.busevents[:26] - EnoceanOutgoing state updated to ON

14:35:12.964 WARN  o.o.c.i.e.EventPublisherImpl[:80] - given new state is NULL, couldn't post update for 'EnoceanOutgoing'

14:35:13.081 DEBUG o.o.b.t.AbstractSocketChannelBinding[:1717] - Picked WriteBufferElement [Channel=Channel [item=EnoceanOutgoing, command=ON, direction=OUT, remote=/127.0.0.1:5000, buffer=, isBlocking=false, isReconnecting=false, channel=/127.0.0.1:63402::/127.0.0.1:5000, host=127.0.0.1, port=5000], buffer=ON, isblocking=false] from the queue

14:35:13.081 DEBUG o.o.b.t.AbstractSocketChannelBinding[:1727] - Sending ON  for the outbound channel /127.0.0.1:63402->/127.0.0.1:5000

I tried with various forms in the REGEX ((.*)) and (.*), was also successful in sending aribtrary strings directly encoded in the item definition but now am a bit stuck on how to send a rule generated message to/through an item using the TCP binding. (I would assume that is also something that folks who want to send parametrized messages to other types of receivers). 

Any pointers in the right direction (or a nice interface to the TCP binding, on which I could plug an adapter for the enocean binding). 

Thanks 

Clemens

 

[Kevin Rasmussen]

Cant you just use the native TCP binding and then just update a string item with a custom value?

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/qJo_48FDMGA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[dr.cleme...@gmail.com]

Thanks, that goes is in the right direction. I was somehow stuck on the notion that I wanted to use a switch item, I get my data out now...

The other part of my question remains - I remember having read somewhere that the designers did not think the rule engine as the place to put

"heavy" programming. At some point I need to deal with message duplication from my Enocean bridges (+ the Enocean USB Gateway) for messages that are captured by more

than one device, and doing this with the somewhat limited features (and debugging capabilities) of the rule engine does not seem to be too inviting. 

Also, the configuration of the items using my TCP protocol converter is probably somewhat against the concept. 

C. 

[Kevin Rasmussen]

How about using the script engine which is designed specificaly for more advanved stuff that cant fit into the rules eng. How you use it though is beyond me hence I have not had any reason to use it yet.

[DEVESH PARMAR]

Hello sir,
             I want to make a communication between openhab and my UDP_Client running on IPv6. i want to make a log file of the data sent by the client to openHAB. Currently i am trying to do the things according to the documentation. But i am not able to connect openHAB with my UDP_Client IPv4.

Item Definition - String Message "str [%s]" {tcp="<[127.0.0.1:8888]"}
Runtime log-      AbstractChannelEventSubscriberBinding[:251] - Setting up a connection to /127.0.0.1:8888
                        org.openhab.binding.tcp.AbstractSocketChannelEventSubscriberBinding$MuxChannel@66e9a555 has encountered an unknown IO Exception:
                         Connection refused.

Thank You sir

[Karel Goderis]

Devesh,

If you want to have incoming connections on openHAB then you have to configure the port it has to listen to in the openhab.cfg . See the relevant section of that file and uncomment the port def line and if necessary change "tcp" to "udp". Secondly, you have to alter the definition of the Item to include the IP address of your UDP client, unless, which I presume, it is running on the same host as the openhab server. That being said, I have not tested the UDP/TCP binding with IPv6, so I have no clue what you might expect when you try that....

Kind Regards

Karel

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[andreas....@gmail.com]

I'm new to openHAB and I'm currently thinking about connecting my PHC House Automation System (from PEHA, Germany) to openHAB.

Therefore I'm thinking about writing a Socket Server which is communicationg with the PHC Controller. Within openHAB I want to use the generic TCP/UDP binding for sending ASCII commands to this Socket Server.

Currently I'm validationg the concept with some simple examples, but I have some problems with understanding the binding.

1) I have the following test items defined:

Switch        Sw1  "Schalter1" (Test) {tcp=">[ON:127.0.0.1:8888:'Schalter1 ON'],>[OFF:127.0.01:8888:'Schalter1 OFF']"}
Rollershutter Rol1 "Rolladen1" (Test) {tcp=">[UP:127.0.0.1:8888:'Roll1 UP'],>[DOWN:127.0.01:8888:'Roll1 DOWN'],>[STOP:127.0.01:8888:'Roll1 STOP']"}
Dimmer        Dim1 "Dimmer1"   (Test) {tcp=">[0:127.0.0.1:8888:'Dimmer1 %d']"} 

The switch and rollershuter are working as expected and sending the correct commands to my test socket Server.

But I don't get the dimmer to work as I need it. Currently my socket server will receive only an integer with the dim percentage.

To distinguish the commands for different dimmers, I need a prefix with the Name of the dimmer.

So what I need is a command for my socket Server like "Dimmer1 50%", "Dimmer1 50". But what I get is only "50".

What is the correct syntax/transformation/mapping for the dimmer?

2) If I switch the switch, my socket Server is replying "OK" or "ERROR".

Does openHAB expect and answer? What is the format of the expected answer?

3) The Status for example of a switch is not only controlled by openHAB. If somebody uses the normal switch for a light, how is it possible to send a status update for e.g a switch?

The Idee is, that my socket Server will send status updates back to openHAB via the same socket.

What is the Syntax for example for the switch, rollershutter or dimmer from above to update the status? Which message format is expected?

You have done a great Job with this generic binding, but I think therw should be a handful more examples to understand how it works...

Andreas

[DEVESH PARMAR]

Hello Karel 

                Sir thanks a lot for the help. Now i am able to connect openHAB with a remote host which acts like server. Now i am having tcp_client which want to communicate with openHAB through remote host. If i am sending some data from tcp_client then how to store it on openHAB , what sort of rule i should write to make a log file of the data coming from tcp_client.

Thank You Sir ....

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/qJo_48FDMGA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Kai Kreuzer]

Hi Andreas,

To me it sounds as if it could make sense to implement a dedicated binding for PHC instead of trying to squeeze all functionality in the generic TCP binding.

So if you are willing to do some Java coding, this would be perfect - good thing about putting efforts in a binding is that this is then easily reusable by others, while your current approach would only be specific to your own installation.

Regards,

Kai

[dave.sh...@gmail.com]

Kai,

is there a guide on how to copy an existing binding and compile it? I've downloaded the full package before and compiled it, but dont know how to compile just a single new binding!

cheers

Dave

[andreas....@gmail.com]

Hi Kai,

yes a special binding for PHC would be the best. But at the moment I think it is not very easy to implement a new binding. The TCP binding could do more than 50%
I need, so it was not only a good way to start playing with openHAB. It has also nearyl every function I need.

For the Problem with the dimmer only sending a value without identification, I can solve it by using differen ports for each dimmer (currently I only haave 4 dimmers in my house). Also it is maybe possible to use a seperate MAP file for each dimmer. One MAP file could map a simple "45" to "Dimmer1 45" and the other MAP file to "Dimmer2 45".

For the problem with changing the status of a Switch by an external event it is maybe possible to do it with a rule.

I'm very new to openHAB so I don't know if all my ideas are working...


Currently I'm trying the new 1.40 snapshots becahue 1.3.1doesn't seem to Support MAP files for TCP binding.
But none of the items below - all woking with 1.3.1 - are sending a command to the socket Server:

Switch        Sw1  "Schalter1" (Test) {tcp=">[ON:127.0.0.1:8888:'Schalter1 ON'],>[OFF:127.0.01:8888:'Schalter1 OFF']"}
Rollershutter Rol1 "Rolladen1" (Test) {tcp=">[UP:127.0.0.1:8888:'Roll1 UP'],>[DOWN:127.0.01:8888:'Roll1 DOWN'],>[STOP:127.0.01:8888:'Roll1 STOP']"}
Dimmer        Dim1 "Dimmer1"   (Test) {tcp=">[0:127.0.0.1:8888:'Dimmer1 %d']"} 

What could be wrong with my setup? Again: my configuration is working with 1.3.1
Is there a good documantation or a good example on how to implement a new binding? Which actual binding is aa good example for a new binding?


Thanks for your answer

Andreas

[Karel Goderis]

 

Hi Andreas

On 21 Dec 2013, at 20:54, andreas....@gmail.com wrote:

Currently I'm trying the new 1.40 snapshots becahue 1.3.1doesn't seem to Support MAP files for TCP binding.

But none of the items below - all woking with 1.3.1 - are sending a command to the socket Server:

Switch        Sw1  "Schalter1" (Test) {tcp=">[ON:127.0.0.1:8888:'Schalter1 ON'],>[OFF:127.0.01:8888:'Schalter1 OFF']"}
Rollershutter Rol1 "Rolladen1" (Test) {tcp=">[UP:127.0.0.1:8888:'Roll1 UP'],>[DOWN:127.0.01:8888:'Roll1 DOWN'],>[STOP:127.0.01:8888:'Roll1 STOP']"}
Dimmer        Dim1 "Dimmer1"   (Test) {tcp=">[0:127.0.0.1:8888:'Dimmer1 %d']"} 

What could be wrong with my setup? Again: my configuration is working with 1.3.1

I completely rewrote the TCP binding after 1.3, and indeed in the 1.4 snapshots Transformation services (MAP....) were introduced. In order to help you out it would be helpful if you could post some debug logs so that I can check what is happening. (pls also post the relevant part of openhab.cfg). 

Regards

K

[Kai Kreuzer]

Hi Andreas,

Is there a good documantation or a good example on how to implement a new binding? Which actual binding is aa good example for a new binding?

Well, this is as good as it gets: https://github.com/openhab/openhab/wiki/How-To-Implement-A-Binding

Regards,

Kai

[Kai Kreuzer]

Hi Dave,

> but dont know how to compile just a single new binding!

See the very last section „Building and Packaging“ at https://github.com/openhab/openhab/wiki/How-To-Implement-A-Binding

Hope this helps!
Kai

[Andreas Furrer]

Hello Kai,

thanks for your answer. I finally got some part the 1.4.0 binding to work.

These are my test items:

Switch          Sw1      "Schalter1"                            (Test)  {tcp=">[ON:127.0.0.1:8888:'MAP(my.device.map)'],>[OFF:127.0.0.1:8888:'MAP(my.device.map)']"}
Switch          Sw2      "Schalter2"                            (Test)  {tcp=">[ON:127.0.0.1:8888:'REGEX((.*))'],>[OFF:127.0.0.1:8888:'REGEX((.*))']"}
Switch          Sw3      "Schalter3 [MAP(my.device.map):%s]"    (Test)  {tcp=">[ON:127.0.0.1:8888:'MAP(my.device.map)'],>[OFF:127.0.0.1:8888:'MAP(my.device.map)']"}
Switch          Sw4      "Schalter4 [%s]"                       (Test)  {tcp=">[ON:127.0.0.1:8888:'MAP(my.device.map)'],>[OFF:127.0.0.1:8888:'MAP(my.device.map)']"}
Rollershutter   Rol1      "Rolladen1"                           (Test)  {tcp=">[UP:127.0.0.1:8888:'MAP(my.device.map)'],>[DOWN:127.0.0.1:8888:'MAP(my.device.map)'],>[STOP:127.0.01:8888:'MAP(my.device.map)']"}
String          Str1      "Str1 [%s]"                           (Test)  {tcp=">[:127.0.0.1:8888:'REGEX((.*))']"}

Dimmer          Dim1     "Dimmer1"                              (Test)  {tcp=">[:127.0.0.1:8888:'REGEX((.*))']"} 

All is working except the Dimmer.

For the Dimmer I will get the following error:

14:50:23.096 DEBUG o.o.i.r.i.r.ItemResource[:196] - Received HTTP POST request at 'items/Dim1' with value '40'.

14:50:23.096 INFO runtime.busevents[:22] - Dim1 received command 40

14:50:23.440 DEBUG o.o.i.r.i.b.GeneralBroadcaster[:41] - broadcaster 'org.openhab.io.rest.internal.broadcaster.GeneralBroadcaster$1@a6508ca' is empty

What is the correct item definition for a dimmer?

I had to change some lines of your code to get the mapping of the answer to work (currently my socket Server ist just echoing the input).

In  internalReceiveChanneledCommand of TCPBinding.java you are extracting the answer of a command by

logger.info("Received {} from the remote end {}",new String(result.array()),sChannel.toString());

String transformedResponse = transformResponse(provider.getProtocolCommand(itemName, command),new String(result.array()));

The Problem is, that the string for the result array will have a lot of null characters at the end (the string always has a size of 1024) which will make it impossible to map the answer.

I changed the code to

String sResult = new String(result.array()).split("\0")[0];

logger.info("Received {} from the remote end {}",sResult,sChannel.toString());

String transformedResponse = transformResponse(provider.getProtocolCommand(itemName, command),sResult);

The same Problem in parseBuffer. My changed code is:

String theUpdate = new String(byteBuffer.array()).split("\0")[0];

Maybe split is not the best way to cut the string at the first null character... But I have really no experience with Java programming and this is a way it worked.

Another Option would be to use the trim() function:

String theUpdate = new String(byteBuffer.array()).trim();

which would also trim all white spaces, but I don't know if this is wanted.

For now I could do a setup for all my switches with a seperate MAP-file for each switch to have unique commands ( I need to identify the switch at my socket Server), but for about 100 Switches this would be very anoying.

Is there a Transformation function which could just add some text (e.g. the name of the item) in front or behind the command?

For example, when switching Switch SW1 to on, I need to send "SW1ON", "SW1_ON", "SW1 ON" or something similar to my socket server.

Also: if a string is not found in a MAP-file, why is an empty string returned by the Transformation and not the input string? I think this would be better...

Thanks again for your help and your work.

[dave.sh...@gmail.com]

I have exactly the same issue (but mine is UDP not TCP). The transformation rule doesn't seem to kick in for Dimmer values. I changed it to tcp as below:

{tcp=">[0:192.168.0.6:9760:'MAP(r6d1.map)']"}

but the binding just comes back with "Sending 0" rather than the transformed value. Not sure about the number/placement on brackets here.

I would also like to append the transformed value (any of the passed Dimmer percentage values from the transform) onto some fixed text such as:

{udp=">[192.168.0.6:9760:'SOMETEXT'+'MAP(r6d1.map)']"}

I could use the transform as ageneric rule for any of the switches I have!

[Andreas Furrer]

I think the best would be if we could do some simple string operations within the transformation section.

I tried to use JavaScript but within the Javascript there is no item information available. Also no ingi about the function etc. But it should be not a lot of work to add it to the transformation function.

Another possibility would be to add something like a String transformation with simple string operations  (Add, Insert, Delete, Left, Right, Mid, Pos, Len, Replace, Upper, Lower...) which could be used recursively. But for that we should also habe some placeholders for e.g. function, item name etc.

If we would have one oft that ( the adding oft item and function information to JavaScript should be easy and is more flexible) the TCP binding (and also other bindings) could be used in a very flexible and universal way.

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/qJo_48FDMGA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[dave.sh...@gmail.com]

Found my error... I need the latest version of the files. So will recompile when I get home.

Looking at the code, what I think would be really useful is if the preAmble and postAmble could be set for an individual item. Combined with MAP and REGEX this would satisfy 99% of my requirements!

[Andreas Furrer]

Can you please post your item Definition of the dimmer?

I still have the Problem.

Am Montag, 6. Januar 2014 12:04:46 UTC+1 schrieb dave.sh...@gmail.com:

[dave.shaw.kford]

I used the following items:

Dimmer        R6D1     "Dimmer1 [%d]"  <slider>  (Test)  {udp=">[0:192.168.0.6:9760:'MAP(r6d1.map)']"}
Dimmer        R6D2     "Dimmer1 [%d]"  <slider>  (Test)  {udp=">[0:192.168.0.6:9760:'MAP(r6d2.map)']"}
Dimmer        R6D3     "Dimmer1 [%d]"  <slider>  (Test)  {udp=">[0:192.168.0.6:9760:'MAP(r6d3.map)']"}

and a sample of the r6d1.map file (one per dimmer only the dimmer name being different in each file, which is why if I could set the 'preamble' per item then I would only need one transform file to convert the percentage to a value between 0 and 32):

OFF=111,!R6D1F0
ON=111,!R6D1F1
0=111,!R6D1F0
1=111,!R6D1FdP1
2=111,!R6D1FdP1
3=111,!R6D1FdP1
4=111,!R6D1FdP1
5=111,!R6D1FdP2
6=111,!R6D1FdP2
7=111,!R6D1FdP2
8=111,!R6D1FdP3
9=111,!R6D1FdP3
10=111,!R6D1FdP3
11=111,!R6D1FdP4
12=111,!R6D1FdP4
13=111,!R6D1FdP4
14=111,!R6D1FdP5
15=111,!R6D1FdP5
16=111,!R6D1FdP5
17=111,!R6D1FdP6
18=111,!R6D1FdP6
19=111,!R6D1FdP6
20=111,!R6D1FdP7
21=111,!R6D1FdP7
22=111,!R6D1FdP7
23=111,!R6D1FdP8
24=111,!R6D1FdP8
25=111,!R6D1FdP8
26=111,!R6D1FdP8
27=111,!R6D1FdP9
28=111,!R6D1FdP9
29=111,!R6D1FdP9
30=111,!R6D1FdP10
31=111,!R6D1FdP10
32=111,!R6D1FdP10
33=111,!R6D1FdP11
34=111,!R6D1FdP11
35=111,!R6D1FdP11
36=111,!R6D1FdP12
37=111,!R6D1FdP12
38=111,!R6D1FdP12
39=111,!R6D1FdP13
40=111,!R6D1FdP13
41=111,!R6D1FdP13
42=111,!R6D1FdP14
43=111,!R6D1FdP14
44=111,!R6D1FdP14
45=111,!R6D1FdP15
46=111,!R6D1FdP15
47=111,!R6D1FdP15
48=111,!R6D1FdP16
49=111,!R6D1FdP16
50=111,!R6D1FdP16
51=111,!R6D1FdP16
52=111,!R6D1FdP17
53=111,!R6D1FdP17
54=111,!R6D1FdP17
55=111,!R6D1FdP18
56=111,!R6D1FdP18
57=111,!R6D1FdP18
58=111,!R6D1FdP19
59=111,!R6D1FdP19
60=111,!R6D1FdP19
61=111,!R6D1FdP20
62=111,!R6D1FdP20
63=111,!R6D1FdP20
64=111,!R6D1FdP21
65=111,!R6D1FdP21
66=111,!R6D1FdP21
67=111,!R6D1FdP22
68=111,!R6D1FdP22
69=111,!R6D1FdP22
70=111,!R6D1FdP23
71=111,!R6D1FdP23
72=111,!R6D1FdP23
73=111,!R6D1FdP24
74=111,!R6D1FdP24
75=111,!R6D1FdP24
76=111,!R6D1FdP24
77=111,!R6D1FdP25
78=111,!R6D1FdP25
79=111,!R6D1FdP25
80=111,!R6D1FdP26
81=111,!R6D1FdP26
82=111,!R6D1FdP26
83=111,!R6D1FdP27
84=111,!R6D1FdP27
85=111,!R6D1FdP27
86=111,!R6D1FdP28
87=111,!R6D1FdP28
88=111,!R6D1FdP28
89=111,!R6D1FdP29
90=111,!R6D1FdP29
91=111,!R6D1FdP29
92=111,!R6D1FdP30
93=111,!R6D1FdP30
94=111,!R6D1FdP30
95=111,!R6D1FdP31
96=111,!R6D1FdP31
97=111,!R6D1FdP32
98=111,!R6D1FdP32
99=111,!R6D1FdP32
100=111,!R6D1FdP32 

Sent from Samsung tablet

-------- Original message --------
From Andreas Furrer <andreas....@gmail.com>
Date: 06/01/2014 19:29 (GMT+00:00)
To ope...@googlegroups.com
Cc dave.sh...@gmail.com
Subject Re: [openhab] TCP - UDP

[Andreas Furrer]

Thanks for the info. Now my dimmer is also working.

But it is very boring to create a map file for each switch or dimmer... It could be so easy if we just could add some item information to the function going out and coming in...

[Andreas Furrer]

My socket server is able to send the actual status for example of a switch command.

So if I switch the switch to on it could be possible that the switching device is currently not available (e.g. network error) and I will get the answer "OFF" if it was off.

Currently the answer is mapped against the same transformation as the sending command.

I think it would be a good idea to add an optional second transformation entry for mapping of the answer. e.g.

Switch Sw1 "SW1" (Test)  {tcp=">[ON:127.0.0.1:8888:'MAP(Sw1_Out.map)':'MAP(Sw1_In.map)'],>[OFF:127.0.0.1:8888:'MAP(Sw1_Out.map)':'MAP(Sw1_In.map)']"}

Am Samstag, 31. August 2013 08:03:03 UTC+2 schrieb karel....@me.com:

All,

I have spent the last few days rewriting the TCP and UDP bindings and things are advancing well. Both bindings now are truly TCP/UDP clients and servers, thus allowing incoming connections from remote ends, with "allowed" hosts defined in the Item definitions. Also, there is a mechanism built in (that can be configured) to share network connections between Commands in an Item (ex: Switch  DemoSwitch  "Switch"  <heating>  { tcp=">[ON:127.0.0.1:3336:'on_cmd'], >[OFF:127.0.01:3336:'off_cmd']"} would run over 1 single TCP connection), whereas by default a connection would set up for each individual Command. Also, it is possible to share connections between Items (ex: Switch  DemoSwitch  "Switch"  <heating>  { tcp=">[ON:127.0.0.1:3336:'on_cmd'], >[OFF:127.0.01:3336:'off_cmd']"}
Switch  DemoSwitch2  "Switch2"  <heating>  { tcp=">[ON:127.0.0.1:3336:'on_cmd'], >[OFF:127.0.0.1:3336:'off_cmd']"}) -> 1 TCP connection) as well as between Directions (e.g. if an outbound connection to a given host:port is established, and the binding would be listening for an incoming connection coming from the same host:port, then that "listening" item will equally piggy-backing on the outbound connection). Furthermore, in the event of network failures, data send to remote devices can (configurable) be queued and sent later on when the network connection is restored. One will be able to define pre-amble and post-ambles to be attached bits of data that are sent over. For unstable remote devices, for which from time to time a connection needs to be reset it is now possible to define a cron job to do these resets. Maximum buffer sizes can be chosen and so forth.

All that being said, for those will live installations (e.g. Arduino boards etc), do you have any other particular requirements that should be covered in the "base" binding? Things that are specific to your setup or where the type of device can influence the behaviour of the TCP/UDP binding?

Thanks
K

[Karel Goderis]

If the contents of the 2 .map files is different, e.g. what you send to the the server and what you get back has a different syntax, you could combine them in 1 .map no?

With respect to matching the physical state to the logical state in OH, since the TCP binding has no specific knowledge of what is sitting on top of it, it has to decide to either treat the response it get, or not. You can customise this behaviour with the tcp:updatewithresponse flag in the .cfg. if TRUE, then the TCP binding will parse (and transform) the response and use that to update the binding. If false, then the TCP binding will do nothing itself, but will update the Item with the command it received initially. eg.. it will then assume that the command at the server was successfull, and thus, it can "match" the logical state in OH with the physical state of the remote end. 

If you know that after each command the server *will* return something in reply, you can set tcp:blocking to true in the .cfg. That way, when OH sends a command, the TCP binding will wait for a reply

Karel

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Andreas Furrer]

I already have set "tcp:updatewithresponse=true" and "tcp:blocking=true".

And yes, currently I have combined the commands and answers in one mapping file. It is working for my case where I can change the socket server for the needs of the TCP mapping. But it is not a general solution.

Andreas