Implementation strategy for a new binding

[karel....@me.com]

Hi all,

Maybe my question is utterly stupid, but anyways. How would you
implement a binding for a burglar alarm system knowing that:
- the system is controlled via a serial interface
- a proprietary protocol to send command and receive information from
the system exists
- there is a desire to "reuse" some outputs of the system as
different kind of items in openhab. Example, the potential-free window
contacts firing alarm states when a thief opens a window, can be re-
used as an Item to control room thermostats when the alarm system is
not armed (e.g when windows opens, shut off thermostat or lower
heating in room) (other example: re-use the alarm system PIR detectors
to measure room presence)

1. Define a bunch of Items and bind it to a serial port with the
SerialBinding, and then have all the encoding/decoding of the burglar
system protocol in a ruleset?
2. Make a new binding style VDR and MPD bindings, with a mapping of
Typed commands to commands understood by the burglar system
3. Extend the SerialBinding class to encapsulate the burglar system
protocol
4. ....

What do you think?

K

[Kai Kreuzer]

Hi Karel,

I would definitely go for option 2.
The existing serial binding is very basic and only meant to do simple tasks such as sending Strings (without a particular meaning) or being a cheap way to connect a hardware button (what I use at demos by simply shortcutting two pins on the serial port).

Any use case that sends data in a structured way (i.e. a certain protocol) via the serial interface, should be covered in a dedicated binding. This binding can then be specific to what the protocol/hardware supports. So you could bind your window contacts to ContactItems and your PIRs to SwitchItems.

Regards,
Kai

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.
> To post to this group, send email to ope...@googlegroups.com.
> To unsubscribe from this group, send email to openhab+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/openhab?hl=en.
>

[Thomas Eichstädt-Engelen]

Hi,

> I would definitely go for option 2.

+1

What i expect are many bindings that have the Transport Protocol in common. For example the "Simple Serial Binding", DMX512, RS485, your alarm system, many heating systems, etc. There will also be a TCP/UDP binding which which does only differ in the way the information the received String is interpreted (see issue #33 http://code.google.com/p/openhab/issues/detail?id=33 which will do the same except using another Transport Protocol.

So we should keep this common base in mind when designing the new binding. I don't know how to which grade we could achieve reusability, but at least we should keep that in mind. Also i vaguely remember a discussion taking place on the mailing list (but i didn't find the thread yet, @Kai: do you remember the discussion) where a solution based on regular expressions has been discussed.

Ragrds,

Thomas E.-E.

[Kai Kreuzer]

> @Kai: do you remember the discussion) where a solution based on regular expressions has been discussed.

No, sorry, I don't remember...

[Mihail Panayotov]

Thomas, are you talking about this discussion? I would really like to think about this option, as this would open the road people to define relatively easy new or existing protocols.

Karel, which burglar alarm system you plan to integrate? I would like to do exactly what you talk about to my home. I stopped to PARADOX alarm system and had published the protocol here:  http://code.google.com/p/openhab/issues/detail?id=36

[Karel Goderis]

The system I would like to integrate is an Aritech one (used to be GE before). It has an RS232 optional subboard (ATS1801) which allows one to configure the system and in revers, receive all ongoing notifications. 

Now, I researched a bit more, and since that I have some other serial devices to integrate (in my case, an HDMI extender as well as an IR tranceiver) to control all of my media equipment, I am considering going one step further and buy additional hardware to make my serial devices TCP/IP "able". I found some Serial-to-TCP/IP convertors that are not too expensive (approx $100/piece). This would allow for a simpler and more wide implementation at the OpenHAB side: you only have to setup a TCP connection to a given IP:Port and send/receive raw data to talk to the serial device. In my case it removes (1) the serial cable lenght problem between the serial device and my Mac Mini server and (2) the USB/serial conversion which is shitty on a Mac and thus (3) only have Cat6 cabling to be done throughout my house. 

For me it seems an easy way to bring universal control of media appliances (TV's, PVR,...) to openHAB by just leveraging the ubiquitous IR interface these devices have. This way switchting on/off devices, channels, etc can for example be integrated into scenes. or even more complicated scenarios: when someone is ringing the doorbell, the video stream of the door videophone is brought to the Apple TV device (switched on via IR), and the all TV's are automatically switched on (only when someone is in the given room based on the PIR inputs of the alarm system), and then with the HDMI extender the image is switched to these screens. (i admit, it is a bit a crazy scenario)

Makes you wonder why some folks are still considering serial for their products in the first place :-)

K

On 07 Mar 2012, at 09:33, Mihail Panayotov wrote:

Thomas, are you talking about this discussion? I would really like to think about this option, as this would open the road people to define relatively easy new or existing protocols.

Karel, which burglar alarm system you plan to integrate? I would like to do exactly what you talk about to my home. I stopped to PARADOX alarm system and had published the protocol here:  http://code.google.com/p/openhab/issues/detail?id=36

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

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/uEUwcTcxIkAJ.

[Kai Kreuzer]

For me it seems an easy way to bring universal control of media appliances (TV's, PVR,...) to openHAB by just leveraging the ubiquitous IR interface these devices have.

Right, IR support is also something I have on my long wish list (so many ideas and so little time…).

Would you think that this could be achieved through the "generic" TCP or serial binding? Probably depends on the hardware that is used for sending IR commands. What do you have in mind there? If you want to control many devices in different rooms, a system like http://www.irtrans.com/en/homeautomation/ might be worth a thought - you wouldn't need so many serial-2-tcp converters, but you would be of course back with a non-CAT wiring…

Regards,

Kai

[Karel Goderis]

Yep - I also looked at http://www.irtrans.com/en/technicalinfo/lancontrol.php but also http://www.globalcache.com/products/itach/models2/ which I  find more difficult to program. on serial-to-tcp/Ip I looked at http://gridconnect.com/rs232-rj45.html. In fact, there quite a few vendors that do the same stuff. 

Personally, I would do this through a generic TCP binding as it - but that is specific to my situation - is more convenient in the Mac Mini setting (only a few USB ports). From a programming point of view, with the VDR binding already existing, doing a generic one based on TCP would be doable, and means that integrating new devices afterwards would be more convienient, e.g. adapt the command definition/mapping, change a bit the serial protocol (they are al very similar in the sense : send sequence of hex codes, get answer back.) and you are done. IR codes are quite similar as they are - at their simplest, but more complex situations exists (different IR frequencies etc) - a binary sequence to be 'played'.  From what I learned today all the serial to tcp devices are very similar: define IP:port, define protocol (TCP or UDP), define serial bitrate, parity,... via integrated webserver, and you are set to go. 

I saw a product today (irtrans, not sure) that has an internal webserver, and there the IR commands can be sent through http as well (that would be very easy, as std http binding can be used in .cfg)

In scenarios whereby you would need many serial connections, one might even consider using a good old terminal server ;-) 

Yesterday I was at Batibouw (the largest consumer building/construction exhibition in Belgium) and in the domotics part of the trade fair, one could see that the 'successful' domotics companies are making the difference through their sheer of compatibility with many systems. For example, few have Russound, Nuovo, Bose or B&O integration capabilities; or integration with various alarm system vendors. And if you look in detail, you notice that all these "exotic" interfaces are no more than serial interfaces + protocol implementation. This is all commercial stuff, but it somewhere shows that through a generic tcp/ip(-to-serial) binding suddenly a whole range of additional devices can be supported without a lot of hassle. For example, ever considered what you could do if you can control irobot.com devices through openhab? let alone all the kudos you would get from your wife? ;-)

K

[Kai Kreuzer]

Yes, I see the point that many different devices can be accessed through sending "simple" strings through TCP/IP in some way.

But it still leaves the question open, how this is best implemented in openHAB. Reusing a single binding means that you have to put the information on what exactly to send and how to react to it somewhere. I see three possibilities: 

1. Add it somehow to the binding configuration string

2. Add it to some external configuration file

3. Write rules that do all the logic

None of these options seems very user friendly to me - agreed, from the developer point of view it is less work as no new binding has to be implemented. But from a user point of view, you have to deal with a lot of technical stuff that you might not be interested in.

So I would still prefer to have the logic being done inside a binding.

If writing new bindings in Java for every such TCP/IP-enabled device/protocol is too much effort, maybe we can introduce some plug-in mechanism in the generic TCP/IP binding? This could then even make use of the openHAB script language, so that there would not even be the need to compile and package anything. 

Regards,

Kai

[Karel Goderis]

Inheritance / extension of a base tcp/ip java class?

Sent from my iPhone

[Kai Kreuzer]

Inheritance / extension of a base tcp/ip java class?

You would still need to do all the bundle scaffolding around it and build it. We could think of having a template or even generation mechanism for such new bindings, but it still means work.

[Mihail Panayotov]

I'm really happy you discuss this topic. I'm more than sure openHAB should have some kind of protocol template mechanism that will let users (well, ok, advanced users) to define protocols without writing new bindings. Maybe a XML or DSL schema? Karel is right that all "command & control" protocols have very similar pattern - header, possibly device address, command function, data, CRC check. If openHAB provides such mechanism, it would be easily expanded to work with EnOcean, ZigBee, Z-Wave, X10, Insteon, C-Bus, many burglar systems, many different IR protocols, and yes - iRobot ;) Just define the protocol's schema.

[konfro...@elektroschaefer.info]

Really,
I have no clue about the technology used in openhab (osgi, jetty ...) but when I created my custom serial/rs485 binding (it's working btw!)
I had to run some "code generation" steps.
Couldn't it be possible to generate such serial/tcp bindings within the designer?

As a seperate step/module. I mean having some syntax to describe the protocol and let the designer
generate the binding.

 Regards
Daniel

[Kai Kreuzer]

> Couldn't it be possible to generate such serial/tcp bindings within the designer?
>
> As a seperate step/module. I mean having some syntax to describe the protocol and let the designer
> generate the binding.

That was about my idea about implementing ONE binding, which provides a plugin mechanism for the protocol, while using the same transport for all.
Such a plugin mechanism could use the openHAB script language, i.e. I could imagine having a new file type in the designer that allows writing the logic. Each file would correspond to one protocol and there would be no need to generate, implement & build any new bindings.

Regards,
Kai

[konfro...@elektroschaefer.info]

Sounds very, very, very nice to me :)