openHAB 2.0 binding

[gregl]

Hi Timo,

I've just ( as of about 5mins ago) run up Openhab2 A2 on my Rpi2....and last night ran up a new iBoard ( unmodified thanks to @hugob ) with the MySensors Ethernet gateway sketch.

As mentioned i plan to migrate off Vera so building a parallel environment to get up and running with.

So i would love to help test/troubleshoot your MySensors binding....ethernet though?

[odieselredbeard]

I am very interested in this. I want to run openhab 2.0, but haven't been able to figure out the bindings for mqtt or mysensors. I'm available to test as well!

[ZoTyA]

Good work!

I will definialty need some testers and I will call for help, if I think my github repository is useable.

We want to help! What is you github repo url?

[kolaf]

Sign me up or testing as well, please :-)

[TimO]

Ok, so for those of you that would like to test a bleeding edge alpha version I've prepared a little test environment of OpenHAB 2.0.

Please keep in mind: OpenHAB 2.0 is Alpha and my binding is in best case pre-alpha, so don't expect it to work. ;-)

What should (maybe) work:

• Serial Gateway supported
• Ethernet Gateway supported
• Supported sensors: V_TEMPERATURE, V_HUMIDITY, V_VOLTAGE, V_LIGHT
• Request for an ID is answered (random free number is given)

What is not working yet:

• Automatic discovery of sensors that represent themself. I've made a basic implementation and in the debug mode there will be messages which say that a new device was discovered, but that is a lie. ;-) I've found the error in the implementation but it's not that easy to change, so I've postponed that.

How to test:

1. Download the package from: Download
2. Unzip the file
3. Change in the directory openhab2
4. Execute "start_debug.sh" (or "start_debug.bat" should work on windows too, but not tested yet)
5. Direct your browser to http://localhost:8080
6. Watch the video for further information.

I've made a demo of how to set up OpenHAB 2.0: Vimeo Link

How to give feedback:

1. If you've made a test and it is not working, reset everything and start from scratch and try to reproduce the error. Tell me, what you've done and give me the debug output.

2. If you want to test a type of sensor that is not implemented yet, post the messages the sensor sends or expects and I will implement it so you're able to test. Someone posted a sketch for mock-sensors, I will look in that too.

My ToDo List

• Get discovery of sensors working
• implement discovery of bridges / gateways
• implement additional sensors
• look into items-, rules-, config-files (the OpenHAB 1.X way to implement things)

[Jan Gatzke]

As it seems there is no option for configuring the speed of the serial port. I have flashed my gateway with 9600 baud in config.h. Could this be a problem? I have added a temp and a hum sensor both using static node ids but I see no sensor data coming in. During startup of openhab2 I am seeing the following errors:

2015-07-25 18:33:53 [INFO ] [ome.event.ThingStatusInfoEvent:43   ] - mysensors:humidity:93e7b934' updated: UNINITIALIZED (HANDLER_INITIALIZING_ERROR)
2015-07-25 18:33:53 [ERROR] [.c.thing.internal.ThingManager:489  ] - Exception occured while calling thing handler factory 'org.openhab.binding.mysensors.internal.MySensorsHandlerFactory@1e5c7cf': nulljava.lang.NullPointerException: null
        at org.openhab.binding.mysensors.handler.MySensorsHandler.initialize(MySensorsHandler.java:51)
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:116)
        at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:480)
        at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:1)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:744)

and

2015-07-25 18:33:53 [ERROR] [.c.thing.internal.ThingManager:489  ] - Exception occured while calling thing handler factory 'org.openhab.binding.mysensors.internal.MySensorsHandlerFactory@1e5c7cf': nulljava.lang.NullPointerException: null
        at org.openhab.binding.mysensors.handler.MySensorsHandler.initialize(MySensorsHandler.java:51)
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:116)
        at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:480)
        at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:1)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:744)

OpenHAB2 is running on a raspberry pi 2. I habe added this option to the start_debug.sh file: -Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0

[kolaf]

@TimO It would be great if you could implement support for the power type. My sensor reports the following two values:
3;1;1;0;17;2810, the current power consumption (Watt)
3;1;1;0;18;106.2550, the overall power usage since sensor boot (KWH)

It would also be good to be able to get the Gateway log messages such as this: 0;0;3;0;9;Gateway is alive.

This is basically the only thing missing for me apart from the temperature and humidity sensors for the moment. I could give you some examples for barometric pressure and the resulting forecast message based on this if you're interested. I also think I have a sensor lying around that reports distance (actually it's time remaining, but it's using the distance type).

Edit: The few sensors I have running at the moment should have reports available in the log file I included in the next post if you want something to look at :-)

Edit: Barometer forecast message: 6;3;1;0;5;stable

[kolaf]

My five mins of experience:

Setting up the serial Gateway thing work without problems, and I was also able to add a temperature sensor.

BUG: Changing the name of the new thing (temperature sensor) was not successful. It stubbornly remained "Temperature sensor".

Also, it does not seem to get any values even though they are reported in the log, but this might just be some kind of sluggishness?

The same is the case for the humidity values. Example reports listed in the log: 6;2;1;0;1;48.0 (humidity)

Edit: Humidity got updated, but I still get no update for the temperature.

Updated log: server.log

[Jan Gatzke]

@kolaf for which speed did you configure the serial gateway? The MySensors default or the openHAB default 9600 baud?

[kolaf]

@Jan-Gatzke I did not make any changes either to my Gateway or to the openhab configuration. I'm running at the default serial Gateway speed which I guess is 115200?

[Jan Gatzke]

Ok, that explains my problems with openHAB 2.0. Former versions had a fixed speed of 9600 baud. Due to this my serial gateway is compiled with 9600 baud, to.

@TimO can you easily add an option for changing the bit rate? If not I will upgrade my running installation of openHAB to 1.7. This way I could user 115200 baud productive and testing.

edit: just did the update. Will have a look at openhab2 tomorrow.

[TimO]

@kolaf , @Jan-Gatzke : Thanks for testing and your feedback!!

I've edited the first posting, which now contains the documentation on how to test and I've added a new alpha version (Download) for test.

The sensors you requested @kolaf are ready for a test. The discovery is working now too, feel free to give it a try.

@kolaf : I can't work with your server.log. Did you provide the right file? Did you start OpenHAB with "start_debug.sh"?

Your questions:

• baud rate of the serial gateway is currently fixed to 115.200. It is easy to add that option but I would like to keep it simple and because it is a little bit hardcoded in the MySensors lib I would like to omit this option. If it is easier for you to test with that option I will add it.

• Changing the name of a new thing: works for me but this could be a bug in the runtime it is nothing I've implemented in the binding.

• You should see everything the gateway receives in the debug output. Mine looks like this:

2015-07-27 18:52:40 [DEBUG] [.p.s.MySensorsSerialConnection:83   ] - 0;0;3;0;14;Gateway startup complete.
2015-07-27 18:52:40 [DEBUG] [.p.s.MySensorsSerialConnection:83   ] - 172;255;0;0;18;1.4.1
2015-07-27 18:52:40 [DEBUG] [.m.d.MySensorsDiscoveryService:70   ] - Representation Message received
2015-07-27 18:52:40 [DEBUG] [.m.d.MySensorsDiscoveryService:71   ] - Preparing new thing for inbox
2015-07-27 18:52:40 [DEBUG] [.p.s.MySensorsSerialConnection:83   ] - 172;255;3;0;6;0
2015-07-27 18:52:40 [DEBUG] [.p.s.MySensorsSerialConnection:83   ] - 172;255;3;0;11;Humidity + Temp + Relay
2015-07-27 18:52:40 [DEBUG] [.p.s.MySensorsSerialConnection:83   ] - 172;255;3;0;12;1.0
2015-07-27 18:52:40 [DEBUG] [.p.s.MySensorsSerialConnection:83   ] - 172;0;0;0;7;1.4.1

• I've added the S_POWER sensor and tested it with the values you have given @kolaf . Could you please check if it works in your environment too (look at the screenshots of the first posting in this thread)?

• Also I've added S_BARO. The value that is received by the gateway is shown as a simple string. It is ok for a start, but I would like to change that later (given set of values, change icon in dependency of the state).

[kolaf]

@TimO Thank you very much for your excellent work :-).

I have done some more testing, and I can report that discovery of sensors seems to work flawlessly (at least for the supported types ;-)). I like the change you made to the naming, it makes the default names much more easy to distinguish. As for renaming the elements, I will just have to play a bit around with that on my own, I guess.

The new types seem to work well, but there is a problem when updating the light switches. It apparently does not like a DecimalType when updating the item. The light switch command looks like this: 6;4;1;0;2;1
Also, the the updates appear twice in the log which is a bit weird.

I set up two of my sensors, including a sensor type you have not yet implemented, the distance sensor. Two of the sensor reports looks like this:
6;5;1;0;13;1.0
6;5;1;0;13;0.7

Apart from the small issues I'm very impressed with the implementation :-)

I apologise for sending you the wrong log, I was not aware of its location in 2.0. Hopefully I should now have attached the right one.
openhab.log

This is what the sensors currently look like in my simple setup:

Edit: I should mention that switching the sensor on and off from the widgets on the page seems to work correctly, even though it does not report if the sensor is switched using its local interface (hardware interface, a button soldered to the sensor).

[Jan Gatzke]

@TimO Just tested the new Version of the binding. I only have sensors with static IDs so I cannot test the discovery. I will build a test sensor as soon as I find the time. I have manually added several sensors and did not see any problems.
Voltage sensor (wasn't mentioned, yet, right?) seems to work fine, too.

[kolaf]

@Jan-Gatzke I think autodiscovery refers to automatically adding sensors to the system as they present themselves when they are booted. Assigning IDs is a completely different thing, I believe.

I simply removed all my existing things, restarted the server, and then rebooted the sensors when in "discovery" mode. This made everything appear magically :-)

[Jan Gatzke]

@kolaf Ah, this makes sense. I will try that later.

[kolaf]

@TimO Your binding and your plans moving forward. Some sensors rely on some kind of persistence to know the last state before a reboot. Examples include the power sensor that wants to know the total power usage overall (mine is currently lost after every reboot), a lock (you want to ensure that the looked does not change state after a reboot), and probably many other devices as well. Some of these can safely be stored to EEPROM as they do not change very often, but others such as the power usage changes at every measurements and it does not make sense to write to ROM.

One way this has been solved in sensor examples is to have the sensor request the latest value from the gateway, which in turn will pass the request along to any monitoring application. Do you have any plans/is it possible for the binding to support something like this?

In the examples I have seen the sensor and Gateway have used a generic VAR1 variable to communicate this data, but perhaps it is possible for the binding to implement a more generic solution? What if whenever you receive the hello from a sensors node indicating that it has booted, if there is a stored data for that node and child ID, transmit this data to the node using the same type of message as the node sends to the gateway. This has to have a limited number of retries in case the node does not expect such messages. It is then up to the node developer to decide whether he wants to pick up these last state messages from the gateway or not.

Does this make sense and is it useful? Or is that perhaps already some kind of support for this communication in the MySensors library (@hek)?

I'm just thinking out loud here...

[hek]

@kolaf
In the examples the nodes retries requesting this information until they get it.

E.g. https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/EnergyMeterPulseSensor/EnergyMeterPulseSensor.ino#L83-L86

[kolaf]

@hek Exactly, I saw that and had to remove it before implementing your version of the pulse counter :-).

So my point is still valid, I guess, the binding has to listen for variable requests and respond to them. The question is then how does it know which variable is requested? That is why I thought it would be easier if you just sent all the date eight had using the same message types as they reported from the sensor.

[hek]

Yep, but there might be other use cases where a node have been sleeping and wants to request an update from the controller (of something). Guess we cannot just assume that all nodes behaves the same here and just need all VARs sent out.