MQTT support in OpenNetHome

[krambriw]

A simple example to get started

1) First thing, you need to be sure you are running aa version of ONH that supports MQTT (use latest nightly build)

2) Add a port for the MQTT Client connection. In the example below, I have a message broker installed on the same machine as ONH so I use that one. Otherwise you could use an external broker like [url]tcp://test.mosquitto.org[/url] on port 1883. See my config in the picture

3) Next you go to "Create/Edit" and wait for the first MQTT event to appear. From there you can create your first item. As you can see in the picture from my configuration you see the event in the first line


4) I did create the event using EventGhost (you obviously have to figure out how to do this with HomeBridge ). I then used the event to create a MqttRemapbutton as seen here


This remap is toggling a lamp named Dummy on/off. So now I can control lamps and other devices in ONH from EventGhost using MQTT

Kind regards, Walter

[stefangsbb]

Thanks for a really good explanation Walter!

[stefangsbb]

I have now implemented a first version of the MqttValueLogger. You can attach the logger to any attribute of any Item, and it will log changes of that attribute as an MQTT-Event. A typical example would be to log the temperature-attribute of a thermometer, but you can also for example log the State-attribute of a lamp, and the changes to the lamp state would be logged as MQTT-Events. It samples the attribute value with a configurable interval down to 5 seconds.

I also implemented sending and automatic re-connection in the MqttClient, so it will automatically reconnect if connection is lost and if you change the connection parameters. I have not released it in the nightly build yet, I was hoping Jocke or Patrik could give it a small test run before I release it.

[Jocke.g]

I dont have a java-development-environment set up, so I cant test it. Patrik have the dev-environment.

But I did have a look at the code, and it looks good. I like the reconnect and that stuff! Build a nightly, and I will test it in a few days. Nightly is not meant to be 100% stable anyway? By the way, have you started thinking about version 2.1?

[stefangsbb]

Well, I really try to keep the Nightly as stable as possible, since most people use it for their systems... I did some tests with the updates and it seems to work fine, so I have released it in the nightly now.

When it comes to the 2.1, I guess I have just been lazy... It is more fun to add new features than to do all the boring administration of a release. I was hoping to get the Z-Wave stuff working first, but it seems the task is too big, so maybe I have to release without that support.

[krambriw]

It kind of works. I do receive events from ONH (I selected state for lamp device)

The MQTT events looks like this:

Code: Select all

{ "topic": "MyHome/Outgoing", "payload": "Off", "qos": 0, "retain": false, "_msgid": "8ebc5bdd.7143a8" }

What I think would be valuable is to have a unique identifier in the payload as well. So for instance, a simple nexa code switch should have a payload including HouseCode.DeviceCode.State, like "A.2.Off". Otherwise you will have to use a unique topic in the broker for each device and that will be more work in terms of configuration

I think it is ok that you have a function that logs at defined intervals, it is useful for system synchronization matters. But I think you should also, in addition, log right away when the state changes (and reset the counter for next logging)

Best regards, Walter

[Jocke.g]

I have tried it out too, on thermometers. Seems to work. But I agree what Walter says about logging right away. Would be useful too, and easier to see if things work.

But I dont think I agree on more data in the payload. Keep it as small and simple as possible. Then the program dont have to parse json/xml to get the wanted data. The topic should be whats unique. Only the software communicating with the tellstick need to know what house-device code it has. Other softwares subscribing to data wont need this.
There should be a MqttLamp for this scenario, subscribing/publishing on a topic, just like the MqttThermometer.

And also, there should be authentication in MqttClient. Here is how to do it:
http://www.hivemq.com/blog/mqtt-client- ... -paho-java

Regarding versions. I would really like more zwave-support. And I know Patrik have bought a bounce of devices too. We did look at implementing more devices, but it did not seem easy, we did not really understand..
So if you have plans working on this, we can wait on the 2.1 version a bit more. Otherways, I think our android app would get a boost if it worked in a real version.

[krambriw]

The LogInterval seems to be hard coded, fixed to 60 seconds??

[krambriw]

But I dont think I agree on more data in the payload

For sure, you could leave it out but there will be effort needed in the client logic anyway. I can subscribe to MyHome/# but I have to evaluate the topic AND the payload in the message. If everything is in the payload, it will be more straight forward, one-to-one. But most annoying, to create unique events for each device, I will have to define a unique topic for each in ONH.

[stefangsbb]

Ok, so I did a few improvements on the MqttValueLogger:

1) You can now specify a ValuePrefix, which is a string that is added in front of the value that is sent in the MQTT-Message.

2) You can now select to "ReactOnEvent". This one is a bit tricky. There is no way to really send an update as soon as a value changes in an Item. That would require a ton of code in each Item just to make this information available and that would violate one of the core values of the whole system which is simplicity. However, when most values that are interesting changes, this is done as a reaction to an event or results in the sending of an event. The ValueLogger can not know however which events are connected to the value it logs. So when this option is selected, the MqttEventLogger will check for a change in the value as soon as ANY event is sent in the system. This can result in quite a bit of load if there are lots of events fired or if the reading of the value attribute is heavy. If the monitored attribute is a thermometer value or a lamp state, the reading is very light weight so for this kind of attribute (and really for most kind of attributes) the load should not be too high.

3) Fixed the timer so you can change it without having to restart the Item