openHAB 2.0 binding

[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

[kolaf]

@TimO Great work, I will try to test it tonight.

It appears from the discussion that official support for getting the values in the binding seems unlikely.

I guess you could argue that as long as the thing and openhab are not rebooted at the same time, the count should be consistent from the thing. But perhaps he is right, maybe it is better to just keep the total count inside openhab and create a rule to calculate the total power consumed based on our knowledge of number of pulses per kwh, for instance?

On the other hand, was about something like a lock which needs to know its last state if it was not written to EEPROM, is this also beyond the scope of what the binding should be able to do?

[bpair]

I just wanted to say thanks for your work on this. OpenHAB2 has been slow to a release but I think a mySensors-openHAB2 combination could really be a solution that many people need. Ease of entry, big user base, handles many sensors and applications.

My kids go back to school in a couple weeks and I hope to help with testing. Thanks.

[bpair]

I followed your directions and installed on a Windows 7 machine with a serial gateway. Everything came up fine. I configured the serial gateway (added the port). Then I waited but my humidity sensor was not detected. I restarted my arduino with the humidity sensor and immediately two new devices appeared (Humidity plus temperature).

Really nice! Thanks.