The best way to connect to OpenHAB

[Yveaux]

@kolaf touché

[kolaf]

@Yveaux makes sense. Can your gateway speak the serial protocol?

[Yveaux]

@kolaf said:

@Yveaux makes sense. Can your gateway speak the serial protocol?

It currently connects using sockets, but the protocol is identical, so it shouldn't be hard to use a serial connection.

[tboha]

For testing basic functions there exists another (rather crude) way - the serial binding offerd by OpenHAB. Adding :

   String Arduino   "Arduino [%s]"    {serial="COM6"}

to an "items" file will do the trick. Accordingly a "rules" file should be expanded by something like :

   rule SplitMessage
   when 
Item Arduino changed
  then
 <do some relevant processing>

Using MySensors 1.4b (proMini, Uno, Mega.Leonardo) and OpenHab 1.5 (Windows 7 Notebook) produced very reliable results with SerialGateway connected via USB.

You have to compile the sketches with Baudrate set to 9600 because OpenHAB deals only with this Baudrate (mentioned somewhere in the OpenHAB Documentation).

So in Mysensors.h replace :

#define BAUD_RATE 115200
with
#define BAUD_RATE 9600

Because OpenHAB is not prepared to distribute NODE_IDs, you should hardcode this NODE-IDs. This decreases flexibility, but it is acceptable to some degree.

This approach works well for reading sensordata as for writing to actuators. Currently I am using eigth Nodes (including Repeater) with serveral children (e.g. multiple DS18B20, multiple Door contacts, Motionsensor, DHT22 etc). Until now I haven´t enconterd serious problems.

[kolaf]

@tboha Thanks, that was very helpful. Do you have some more details for the mystical "do some processing"?

@Yveaux how do you use the mqtt binding to talk to the sensors? I have looked into it, and must admit I have no idea on how to achieve this. It's apparent that you need some kind of transformation, but my understanding ends there. Specifically, I would like to implement a toggle switch, a switch that toggles a light every time it is activated instead of having a specific on and off state.

[Yveaux]

@hek or @marceltrapman can you please split this topic starting at the openhab/mqtt examples into something like "OpenHAB & MQTT examples" please?
Thanks!

[marceltrapman]

@Yveaux said:

@marceltrapman can you please split this topic starting at the openhab/mqtt examples into something like "OpenHAB & MQTT examples" please?
Starting from which post do you suggest the split?

[Yveaux]

@marceltrapman said:

@Yveaux said:

@marceltrapman can you please split this topic starting at the openhab/mqtt examples into something like "OpenHAB & MQTT examples" please?
Starting from which post do you suggest the split?

Can you also join to an existing topic? In that case I'll create one -- that will make a clearer topic than just start in the middle of a discussion.

[kolaf]

For the record there is also this initiative where a smart guy has created a Python Web application to interface between the serial connection and openhab. He has even built in the functionality for handling node IDs.

https://github.com/wbcode/ham

It seems like there are three quite usable options for interfacing with openhab:

1. The MQTT gateway
2. Using the serial binding in openhab
3. Using the python openhab gateway.

The serial binding seems the best option for quick prototyping with its low implementation cost (no additional software) and high flexibility. One of the two other options seems to be a better long-term choice since they will be easier to manage on the configuration size as the network grows, I think. I like the concept behind the python gateway, but using the httpbinding to communicate with it seems a bit cumbersome. Ideally I would like to see this incorporated as an openhab binding, but I do not think it is possible to do the node ID assignment this way since the binding should be stateless.

This leaves the MQTT solution which leverages technology that seems to grow in popularity. An additional benefit is that the author of the software is still around the forums as opposed to the case with the python gateway. The downside is that the item configurations seems a bit complex (at least to me), it is much easier to understand the serial binding or HTTP binding usage.

It is a tough choice.

[Yveaux]

@hek made me a forum moderator, so now I did the split myself ;-)
Moved the topics regarding specific MQTT & Openhab usage to http://forum.mysensors.org/topic/302/openhab-mqtt-tips-hints
There we can post some OpenHAB code and stuff, and this thread continues to discuss different ways to connect to OpenHAB.
Still have to clean up the new thread a little, though...

[A Former User]

Hi!

Im a slow starter , but I been following the develompent here and over at http://www.byggahus.se/forum/villalarm-hemautomation/ for some time now but just recently I bought some z-wave things to play with and it's working quite ok now in OpenHab (windows 7).

I have a question about using OpenHab as controller for mysensors that I want to double check before I dive in :)

1. Can I use Arduino Nano + Radio module as a gateway to OpenHab attached as usb ?

2. Will it power over usb ?

3. If so does that limit me to use the serial bindning or is MQTT still an option ?

[tboha]

Hi!
I used an Arduino Nano (clone) as serial gateway to OpenHab, it worked without problems. Meanwhile I changed to an UNO-clone because the Nano fit better into its new task.

Power over USB was not an issue, it worked flawless.

The last question is a little bit ambiguous -
Scenario A - switching between serial binding or MQTT (over serial/USB) does not require much work (depending on your installation). You even don't have to change a plug. I did this several times and it is a little bit annoying -but it works.

Scenario B:
Serial binding and MQTT binding of the same gateway in parallel - I haven't tried this, but you will probably run into trouble.

Serial binding of the gateway and MQTT binding of a part of the messages of the MySensors network through a specialized node is not that difficult. It requires some strategy on programming the individual nodes (e.g. send this messages also to node xy which delivers these messages to a MQTT broker). The connection between this node and MQTT is serial/USB
It doesn't make much sense to use serial binding and MQTT binding from the same source to the same target, but it makes sense (at least for me) when the target is different. (e.g. switching and feedback via OpenHab, collecting sensor information via specialized programs).

If you see MQTT-binding as synonym for an Ethernet connection - I tried MQTT over Ethernet a long time ago and it didn't perform to my needs. There are new programs but i haven't tested until now. Switching between serial and Ethernet connection will probably cause the same amount of work mentioned above.

[A Former User]

@tboha
Thanks for clearing that out.

I am not planning to run them in parallel but I do want a setup that allows me to switch controller(software) in the future and thats why I thought that MQTT was to prefer as it would allow me to easily switch but if I understand you correctly it is easy to change between MQTT and serial binding ?

[tboha]

@JimmyH : Yes, it is easy to swap bindings as well as controller. Easy - but it requires some labour. This labour is not complex, it just has to be done. In my specific setup it takes approximately 1-2 minutes per device.

If you are using the serial binding in OpenHab it is tempting to perform some processing within the nested case statements (like I did). Retrospectively this was a really bad idea.

I think it is a better idea to limit the use of these statements to dispatch the incoming data to the chosen Items - and nothing more.

I had a hard time to get used to the functions of OpenHab ".rules" but at last it was worth the effort. Transfer every processing step into separate rules - it will make things easy.

In an ideal scenario to switch between serial and MQTT (either serial or over Ethernet) you pull your USB-plug, activate your broker and you are done.

Due to laziness and little other reasons I'm stuck with an inhomogeneous system resulting in the work mentioned in the beginning - it is tedious but i leads to the desired results.