openhab / openhab1-addons

Add-ons for openHAB 1.x
Eclipse Public License 2.0
3.43k stars 1.69k forks source link

UDP/TCP binding #530

Closed openhab-bot closed 10 years ago

openhab-bot commented 10 years ago

From mishoboss on May 11, 2011 21:07:35

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: http://code.google.com/p/openhab/issues/detail?id=33

openhab-bot commented 10 years ago

From mishoboss on May 11, 2011 12:08:29

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

openhab-bot commented 10 years ago

From kai.openhab on May 11, 2011 12:17:11

Status: Accepted
Labels: -Type-Bug Type-Feature

openhab-bot commented 10 years ago

From mishoboss on February 17, 2012 10:11:05

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

openhab-bot commented 10 years ago

From kai.openhab on February 18, 2012 01:06:29

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?

Owner: teichsta
Labels: Version-1.0.0

openhab-bot commented 10 years ago

From mishoboss on February 18, 2012 02:29:46

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.

openhab-bot commented 10 years ago

From openhab.lb on March 06, 2012 12:19:44

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 ...

openhab-bot commented 10 years ago

From kai.openhab on March 06, 2012 12:26:21

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

openhab-bot commented 10 years ago

From openhab.lb on March 07, 2012 03:49:47

there are two things:

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

openhab-bot commented 10 years ago

From vanhobo...@gmail.com on April 09, 2012 10:23:34

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?

openhab-bot commented 10 years ago

From karel.go...@gmail.com on May 25, 2012 06:31:36

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

openhab-bot commented 10 years ago

From karel.go...@gmail.com on September 02, 2012 11:54:02

done!

openhab-bot commented 10 years ago

From kai.openhab on September 02, 2012 11:58:28

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 :-)

openhab-bot commented 10 years ago

From kai.openhab on September 02, 2012 11:58:39

Labels: -Version-1.0.0 Version-1.1.0

openhab-bot commented 10 years ago

From kai.openhab on November 15, 2012 15:51:36

This binding has meanwhile been moved to the default branch.

Status: Implemented