UDP/TCP binding

[GoogleCodeExporter]

Same as the Generic Serial binding, but for the networked devices.

I see it is on the roadmap (I suggested it there too). I'm building an Arduino 
central heating controller that I would like to control over UDP and that 
feature misses me a lot.

Original issue reported on code.google.com by mishoboss on 11 May 2011 at 7:07

[GoogleCodeExporter]

Sorry, it's not a bug. Please, correct it as a Feature.

Original comment by mishoboss on 11 May 2011 at 7:08

[GoogleCodeExporter]

Original comment by kai.openhab on 11 May 2011 at 7:17

• Changed state: Accepted
• Added labels: Type-Feature
• Removed labels: Type-Bug

[GoogleCodeExporter]

Is there a chance this one is ready for version 1.0?

Original comment by mishoboss on 17 Feb 2012 at 6:11

[GoogleCodeExporter]

Thomas volunteered to look into it :-)
@Mihail: Do you have any hint on how to best test it? Any real hardware or some 
software tool for the other communication end?

Original comment by kai.openhab on 18 Feb 2012 at 9:06

• Added labels: Version-1.0.0

[GoogleCodeExporter]

Kai, just for tests Thomas could use NetCat for Linux/Unix. With the real 
existing hardware it is more complicated, because usually there is some 
application layer protocol above the TCP/IP or UDP/IP stack. In theory it 
should be able to communicate with any 6loWPAN device. In practice, you should 
know the application protocol of the device (there is no standardized 6loWPAN 
application protocol yet, despite there are several drafts and proposals) to do 
some real world stuff.

Personally I want to use TCP or UDP communication with my custom build Arduino 
based hardware. Currently it speaks to the openHAB via the REST API and openHAB 
speaks to it via the HTTP binding, but there are several issues whit that:

1. Atmega 328 MCU has too small memory to hold long URLs and do string 
manipulation.
2. You have to hard-code the item URIs in the firmware.

So, personally I see this TCP/UDP binding as an open road to the DIY hardware 
with custom ASCII based protocols. In some time of the future I see it as a 
transport layer for different protocols like 6loWPAN, xPL, and why not a whole 
protocol framework, built-in in openHAB, that let the users describe their own 
protocol schemes.

Original comment by mishoboss on 18 Feb 2012 at 10:29

[GoogleCodeExporter]

i´m also interested on it, how ist the status with tcp binding, i would like 
to use may be an special protocol on it. i´d like to know where to start ...

Original comment by openhab.lb on 6 Mar 2012 at 8:19

[GoogleCodeExporter]

Regarding "special protocol", the same as 
https://groups.google.com/d/msg/openhab/Sy-QC16hX8c/oTwmSQo6y8YJ might be the 
case for this binding.

Original comment by kai.openhab on 6 Mar 2012 at 8:26

[GoogleCodeExporter]

there are two things:

- the protocol
- the transport (transport framework)

as i can see, the some protocol (how the bytes are interpreted) could be used 
for tcp and/or serial binding ... at the moment i´m interested to get the 
bytes transported by an tcpip connection to openhab translated there and 
updated items

Original comment by openhab.lb on 7 Mar 2012 at 11:49

[GoogleCodeExporter]

I have some Advantech 6015 analog modules in my network that monitor PT1000 
probes, and send the temperature data via UDP packets every 30 seconds.  Each 
packet contains an array with 8 sets [current, max, min]. 

In Misterhouse, I process these with simple actions:

$advantech_LBK = new Socket_Item(undef, undef, "server_advantech_LBK");
$T_supply = new Generic_Item;
$T_cool = new Generic_Item;
$T_return = new Generic_Item;
$T_duct = new Generic_Item;

if (my $packet = said $advantech_LBK) {

    my ($id, @curtemp, @maxtemp, @mintemp);
    ($id, @curtemp[0..8], @maxtemp[0..8], @mintemp[0..8]) =
       unpack("a4x18n9n9n9", $packet);

# Ni1000 sensor measured as PT1000 -40 - 160 C; 17% too high.
    set $T_supply sprintf("%2.1f", (@curtemp[0]/326.68-40)/1.17) unless @curtemp[0]==65535;
# PT1000 -40 - 160 C
    set $T_cool sprintf("%2.1f", @curtemp[1]/326.68-40) unless @curtemp[1]==65535;
    set $T_return sprintf("%2.1f", @curtemp[2]/326.68-40) unless @curtemp[2]==65535;
    set $T_duct sprintf("%2.1f", @curtemp[3]/326.68-40) unless @curtemp[3]==65535;
}

Would it be possible to support a similarly simple parsing of the packet, e.g. 
in a rule, with packet attributes like srp ip, src host and src port that we 
can use in a when cause?

Original comment by vanhobo...@gmail.com on 9 Apr 2012 at 5:23

[GoogleCodeExporter]

Will be easy actual binding implementation on top of the new abtract class that 
I have built. TCP only as this point in time, but adaption to UDP not that 
difficult

Original comment by karel.go...@gmail.com on 25 May 2012 at 1:31

[GoogleCodeExporter]

done!

Original comment by karel.go...@gmail.com on 2 Sep 2012 at 6:54

[GoogleCodeExporter]

Wait, we still didn't review the code... It is only done as soon as it is in 
the main branch, not in a feature branch :-)

Original comment by kai.openhab on 2 Sep 2012 at 6:58

[GoogleCodeExporter]

Original comment by kai.openhab on 2 Sep 2012 at 6:58

• Added labels: Version-1.1.0
• Removed labels: Version-1.0.0

[GoogleCodeExporter]

This binding has meanwhile been moved to the default branch.

Original comment by kai.openhab on 15 Nov 2012 at 11:51

• Changed state: Implemented