openHAB 2.0 binding

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

[kolaf]

Fair point, and the ultimate solution should definitely support this.

Still, I think my suggestion could be useful and much easier to implement on the binding side (and sensor side) since it requires no user configuration in openhab (apart from possibly a checkbox to enable/disable the functionality). The only user interaction required is to actually consume the messages in the node and do something useful with them, if desired. So maybe it is a useful start?

In the pulse sensor example, what should be providing the data when it is requested by the node?

[hek]

@kolaf
Maybe I misinterpreted your earlier post... Do you mean that the controller-plugin should send out the last known value/state of all previously received variables to the node (even if it hasn't received a REQ message) when it detects a newly started node?

If it already keeps this information I guess it would be simpler to just reply on the REQ message only? Like intended... :)

[kolaf]

Yes, but how does it know what to send as a response to a generic request. Everything? A single specific variable? In that case, which variable?

Sorry for bringing this thread off track. Maybe I should take this off-line with @hek or try to read some documentation to understand this better, at least until we see whether @TimO wants to do anything like this at all.

[TimO]

@kolaf thanks again for testing!

The light switch can't get updated by the sensor, I've forgotten to implement that. Thanks for the hint! :-)

The request from sensors is definatly a thing I want to implement. As far as I can see, I should be able to determine which value is requested, because of the combination of nodeId, childId and Subtype.

I stumpled already about the isMetric() request in the humidity sketch, I want to add that too.

A problem currently is, that for persistance in OpenHAB2 the addon from OpenHAB1 is used and that is not yet fully compatible. I need to check, wether it is usable for development yet. A second problem: I need to dig deeper to find out, how to read the value of a thing.

[kolaf]

There it is, the Child ID is included in the request message :-). Sorry for the confusion caused by my lack of observation skills.

[TimO]

Small update:

• I've fixed the problem with the representation of the light status (@kolaf ).

• I've experimented a little with the configuration files. Additionally to the thing discovery or manual creation via the Paper UI you're able to declare the gateway and corresponding things/items in configuration files. It is very similar to the declaration done in OpenHAB 1.X, without the need to handle the messages in the rules files. I've documented that in the Readme.md you find while following the Link to the Github repository in the first post of this thread.

• I've started a discussion in the google group for OpenHAB2. OpenHAB2 is not able to read out the value of a thing within the binding. This would be very useful, for example for the pulse sensors (power/water) that are able to request the last pulse count. (Corresponding thread in the google group: https://groups.google.com/forum/#!topic/openhab2/QbmaSwC59l0)

The current snapshot of the mysensors binding is available for download here:
Download