openHAB 2.0 binding
-
Merging sensor to one
Hi
I have been thinking and i think it would be nice if there is a way to merge sensor data to one in the mysensors binding.Background
I am trying to build a pool control based on mysensors and i have a lot of options that i wan it to handle. For example:- on/off of my pool pumps (S_LIGHT)
- on/off of lights around the pool (S_LIGHT)
- thermostat function for heaters (S_HVAC)
- measuring pressure on pump (S_BARO)
- measuring consumed power on pump (S_POWER)
All this are using the same sensor ID and getting own child IDs. When they now are brought in to openhab they appear as single sensors
Is there a possibility to get an automatic merge for thes combined sensors?
And what do you think about the idea.
Or is there already a solution that exist that I am not aware aboutexample from paper UI
with openhab poolcontrol view
@Denke
If I understand correctly, you are suggesting to combine different sensor types in one thing.
IMHO this would jeopardize the concept of the binding. The binding provides one thing per message type (see https://www.mysensors.org/download/serial_api_15). the thing has one channel per supported sub type.
I also do not see the advantage of combining different sensor/message types in one thing as you need one item per channel anyhow.
=> this would not reduce the number of items needed.Grouping the items in the site map - as you already did - is the best way here.
Does anybody see this differently?
-
@Denke
If I understand correctly, you are suggesting to combine different sensor types in one thing.
IMHO this would jeopardize the concept of the binding. The binding provides one thing per message type (see https://www.mysensors.org/download/serial_api_15). the thing has one channel per supported sub type.
I also do not see the advantage of combining different sensor/message types in one thing as you need one item per channel anyhow.
=> this would not reduce the number of items needed.Grouping the items in the site map - as you already did - is the best way here.
Does anybody see this differently?
@meju25 I saw this from a management perspective.
I have one device, my pool controller, that has multiple sensors and also channels per sensor just as HVAC that has a sum of channels. In my case i implemented a number of sensors in different types of channels "S_HVAC, S_LIGHT,...." what i see that it gets messy when you try to see if the channels are active or the pool control is active it has multiple sensors.So maybe a suggestion is to maybe implement this in the mysensors instead of in the openhab binding.
In that case i would like to add something that allows me to tell what channels are in a "sensor" by combining differnt channels and sensor types.I don't know if i got my message through.
But all this is mainly for management of my devices so that this gets less messy
-
-
Hi
Is there anybody that have had a problem with the S_BARO and the V_PRESSURE channel?I try to send a value on this channel as 1.2 I can see that the serial gateway receives it
23:10:51.808 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;9;read: 163-163-0 s=10,c=1,t=4,pt=7,l=5,sg=0:1.2
I set up the channel as i have done for alot of other channels through the paper ui. where i link the channel to an item.
The item file looks like this
String Pool_Pressure "Pressure [%s]" <pressure> (gPool)the sitemap file looks like this
Text item=Pool_Pressureresult is this
The field never gets updated.
any suggestions? -
Hi
Is there anybody that have had a problem with the S_BARO and the V_PRESSURE channel?I try to send a value on this channel as 1.2 I can see that the serial gateway receives it
23:10:51.808 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;9;read: 163-163-0 s=10,c=1,t=4,pt=7,l=5,sg=0:1.2
I set up the channel as i have done for alot of other channels through the paper ui. where i link the channel to an item.
The item file looks like this
String Pool_Pressure "Pressure [%s]" <pressure> (gPool)the sitemap file looks like this
Text item=Pool_Pressureresult is this
The field never gets updated.
any suggestions? -
@Denke : You're right, the pressure channel was missing in the thing definition. This is fixed in the current version!
@dakky : Which gateway type keeps disconnecting and why? I've a serial and ethernet gateway running side by side in OH2 and both didn't get disconnected so far. The hardest part is to recognize if the connection gets down.
-
@Denke : You're right, the pressure channel was missing in the thing definition. This is fixed in the current version!
@dakky : Which gateway type keeps disconnecting and why? I've a serial and ethernet gateway running side by side in OH2 and both didn't get disconnected so far. The hardest part is to recognize if the connection gets down.
Hi @TimO . Are you having both gateways connected to same the OH simultaneously?
Any troubles with that? I imagine you should have different radio channels for each gateway, right? like two separate sensors networks. -
Hi @TimO . Are you having both gateways connected to same the OH simultaneously?
Any troubles with that? I imagine you should have different radio channels for each gateway, right? like two separate sensors networks.Hi @gonzalonal !
Only the ethernet gateway has an attached radio.
Here is my current (MySensors) setup:
Bridge mysensors:bridge-eth:MySGW [ ipAddress="192.168.2.99", tcpPort=5003, sendDelay=100, skipStartupCheck=true ] { humidity bathHum01 [ nodeId="101", childId="0" ] temperature bathTemp01 [ nodeId="101", childId="1" ] humidity bathBat01 [ nodeId="101", childId="255" ] humidity bedHum01 [ nodeId="103", childId="2" ] temperature bedTemp01 [ nodeId="103", childId="1" ] humidity bedBat01 [ nodeId="103", childId="255" ] humidity workHum01 [ nodeId="104", childId="2" ] temperature workTemp01 [ nodeId="104", childId="1" ] humidity workBat01 [ nodeId="104", childId="255" ] humidity kitchenHum01 [ nodeId="105", childId="2" ] temperature kitchenTemp01 [ nodeId="105", childId="1" ] humidity kitchenBat01 [ nodeId="105", childId="255" ] humidity childHum01 [ nodeId="107", childId="3" ] temperature childTemp01 [ nodeId="107", childId="4" ] light childLight01 [ nodeId="107", childId="0" ] light childLight02 [ nodeId="107", childId="1" ] light childLight03 [ nodeId="107", childId="2" ] humidity guestHum01 [ nodeId="106", childId="0" ] temperature guestTemp01 [ nodeId="106", childId="1" ] light guestPresence01 [ nodeId="106", childId="3" ] light livingLight01 [ nodeId="106", childId="4" ] light livingLight02 [ nodeId="106", childId="5" ] light livingLight03 [ nodeId="106", childId="6" ] light livingLight04 [ nodeId="106", childId="7" ] light corridorLight03 [ nodeId="106", childId="8" ] light livingLight06 [ nodeId="106", childId="9" ] humidity livingHum01 [ nodeId="108", childId="2" ] temperature livingTemp01 [ nodeId="108", childId="1" ] humidity livingBat01 [ nodeId="108", childId="255" ] humidity gardenHum01 [ nodeId="110", childId="2" ] temperature gardenTemp01 [ nodeId="110", childId="1" ] humidity gardenBat01 [ nodeId="110", childId="255" ] motion gardenMotion01 [ nodeId="110", childId="3" ] } Bridge mysensors:bridge-ser:MySGWKeller [ serialPort="/dev/ttyUSB0", sendDelay=100, skipStartupCheck=true ] { cover kitchenShutter02 [ nodeId="0", childId="0" ] cover kitchenShutter03 [ nodeId="0", childId="1" ] cover livingShutter01 [ nodeId="0", childId="2" ] cover livingShutter02 [ nodeId="0", childId="3" ] cover kitchenShutter01 [ nodeId="0", childId="4" ] light corridorLight01 [ nodeId="0", childId="5" ] light corridorLight02 [ nodeId="0", childId="6" ] power corridorLight01watt [ nodeId="0", childId="7" ] } -
@Denke : You're right, the pressure channel was missing in the thing definition. This is fixed in the current version!
@dakky : Which gateway type keeps disconnecting and why? I've a serial and ethernet gateway running side by side in OH2 and both didn't get disconnected so far. The hardest part is to recognize if the connection gets down.
I'm using a ethernet gateway.
the problem is: if the sensors gateway gets restarted/disconnected/updated/whatever the binding does not reconnect. The only way to fix that, is to restart openhab in order to force the binding to connect again.
Detecting an disconnect is really that hard? in the worst case, what about simply reconnecting timebased? not as cute as only reconnect when nessecary but a dirty quickfix. -
Hi @gonzalonal !
Only the ethernet gateway has an attached radio.
Here is my current (MySensors) setup:
Bridge mysensors:bridge-eth:MySGW [ ipAddress="192.168.2.99", tcpPort=5003, sendDelay=100, skipStartupCheck=true ] { humidity bathHum01 [ nodeId="101", childId="0" ] temperature bathTemp01 [ nodeId="101", childId="1" ] humidity bathBat01 [ nodeId="101", childId="255" ] humidity bedHum01 [ nodeId="103", childId="2" ] temperature bedTemp01 [ nodeId="103", childId="1" ] humidity bedBat01 [ nodeId="103", childId="255" ] humidity workHum01 [ nodeId="104", childId="2" ] temperature workTemp01 [ nodeId="104", childId="1" ] humidity workBat01 [ nodeId="104", childId="255" ] humidity kitchenHum01 [ nodeId="105", childId="2" ] temperature kitchenTemp01 [ nodeId="105", childId="1" ] humidity kitchenBat01 [ nodeId="105", childId="255" ] humidity childHum01 [ nodeId="107", childId="3" ] temperature childTemp01 [ nodeId="107", childId="4" ] light childLight01 [ nodeId="107", childId="0" ] light childLight02 [ nodeId="107", childId="1" ] light childLight03 [ nodeId="107", childId="2" ] humidity guestHum01 [ nodeId="106", childId="0" ] temperature guestTemp01 [ nodeId="106", childId="1" ] light guestPresence01 [ nodeId="106", childId="3" ] light livingLight01 [ nodeId="106", childId="4" ] light livingLight02 [ nodeId="106", childId="5" ] light livingLight03 [ nodeId="106", childId="6" ] light livingLight04 [ nodeId="106", childId="7" ] light corridorLight03 [ nodeId="106", childId="8" ] light livingLight06 [ nodeId="106", childId="9" ] humidity livingHum01 [ nodeId="108", childId="2" ] temperature livingTemp01 [ nodeId="108", childId="1" ] humidity livingBat01 [ nodeId="108", childId="255" ] humidity gardenHum01 [ nodeId="110", childId="2" ] temperature gardenTemp01 [ nodeId="110", childId="1" ] humidity gardenBat01 [ nodeId="110", childId="255" ] motion gardenMotion01 [ nodeId="110", childId="3" ] } Bridge mysensors:bridge-ser:MySGWKeller [ serialPort="/dev/ttyUSB0", sendDelay=100, skipStartupCheck=true ] { cover kitchenShutter02 [ nodeId="0", childId="0" ] cover kitchenShutter03 [ nodeId="0", childId="1" ] cover livingShutter01 [ nodeId="0", childId="2" ] cover livingShutter02 [ nodeId="0", childId="3" ] cover kitchenShutter01 [ nodeId="0", childId="4" ] light corridorLight01 [ nodeId="0", childId="5" ] light corridorLight02 [ nodeId="0", childId="6" ] power corridorLight01watt [ nodeId="0", childId="7" ] }Thanks @TimO. Now I get it.
What do you think about having two gateways, one with NRF radio and the other one with RFM69 radio?Will the binding support both gateways simultaneusly with no issues?
Another question..Will you support HearbeatRequest for the development branch?
Thanks, regards.
-
Hello againg.
I have updated my OH2 to latest nightbuild from cloudbees, and also updated to lastest realease of OH2 MyS Binding.
Now, I am facing an issue, that everytime that OH2 starts, it sends out all the items status to its respective node. This is causing, for example, to open my gates, or lowering my rollershutters, even disabling/enabling my alarm system. So I have shutdown OH2 for time being.
Have anyone faced this behavior before?
This is some of the log:
15:41:40.241 [WARN ] [ome.core.thing.internal.ThingManager] - Initializing handler for thing 'mysensors:bridge-ser:gateway' takes more than 5000ms. 15:41:40.272 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.295 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.322 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.335 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.348 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.362 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.375 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.388 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.402 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.545 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Home.items' 15:41:40.671 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.685 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.697 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.710 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.724 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.738 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.755 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.768 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.783 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.806 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;255;3;0;14;Gateway startup complete. 15:41:40.811 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.856 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.871 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.885 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.898 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.914 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.928 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.941 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:41.029 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;3;1;0;0; 15:41:41.110 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:41.288 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;253;1;0;2; 15:41:41.546 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;6;1;0;2; 15:41:41.799 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;252;1;0;24;REFRESH 15:41:42.052 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;254;1;0;2; 15:41:42.307 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;254;1;0;2; 15:41:42.562 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;3;1;0;2; 15:41:42.817 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;253;1;0;2; 15:41:43.073 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;252;1;0;24;REFRESHI would really appreciate your help.
-
Hello againg.
I have updated my OH2 to latest nightbuild from cloudbees, and also updated to lastest realease of OH2 MyS Binding.
Now, I am facing an issue, that everytime that OH2 starts, it sends out all the items status to its respective node. This is causing, for example, to open my gates, or lowering my rollershutters, even disabling/enabling my alarm system. So I have shutdown OH2 for time being.
Have anyone faced this behavior before?
This is some of the log:
15:41:40.241 [WARN ] [ome.core.thing.internal.ThingManager] - Initializing handler for thing 'mysensors:bridge-ser:gateway' takes more than 5000ms. 15:41:40.272 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.295 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.322 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.335 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.348 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.362 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.375 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.388 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.402 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.545 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Home.items' 15:41:40.671 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.685 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.697 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.710 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.724 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.738 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.755 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.768 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.783 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.806 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;255;3;0;14;Gateway startup complete. 15:41:40.811 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.856 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.871 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.885 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.898 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.914 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.928 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:40.941 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:41.029 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;3;1;0;0; 15:41:41.110 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called 15:41:41.288 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;253;1;0;2; 15:41:41.546 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;6;1;0;2; 15:41:41.799 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;252;1;0;24;REFRESH 15:41:42.052 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;254;1;0;2; 15:41:42.307 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;254;1;0;2; 15:41:42.562 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;3;1;0;2; 15:41:42.817 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;253;1;0;2; 15:41:43.073 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;252;1;0;24;REFRESHI would really appreciate your help.
@gonzalonal I have no idea why this should happen. The binding isn't that smart to do something like that. I've done a complete fresh installation on 21.06. with the nightly build from cloudbees and don't see this issue.
@dakky Do you see disconnection messages in the log? The binding already tries to detect a disconnect and tries to reestablish the connection when an ethernet gateway is used. Currently the time within a reconnect would be successful is very small due to sleep limitations of threads in OH2 bindings.
-
@gonzalonal I have no idea why this should happen. The binding isn't that smart to do something like that. I've done a complete fresh installation on 21.06. with the nightly build from cloudbees and don't see this issue.
@dakky Do you see disconnection messages in the log? The binding already tries to detect a disconnect and tries to reestablish the connection when an ethernet gateway is used. Currently the time within a reconnect would be successful is very small due to sleep limitations of threads in OH2 bindings.
Thanks @TimO . I will try to make a progressive installation and try to figure out what is causing this behavior.
I'll let you know if I find out.
Have you read my previous message?
Regards@gonzalonal said:
Thanks @TimO. Now I get it.
What do you think about having two gateways, one with NRF radio and the other one with RFM69 radio?Will the binding support both gateways simultaneusly with no issues?
Another question..Will you support HearbeatRequest for the development branch?
Thanks, regards.
-
Thanks @TimO . I will try to make a progressive installation and try to figure out what is causing this behavior.
I'll let you know if I find out.
Have you read my previous message?
Regards@gonzalonal said:
Thanks @TimO. Now I get it.
What do you think about having two gateways, one with NRF radio and the other one with RFM69 radio?Will the binding support both gateways simultaneusly with no issues?
Another question..Will you support HearbeatRequest for the development branch?
Thanks, regards.
@gonzalonal : I just downloaded the recent version of the binding again and I don't see this behaviour.
I hope both gateways will work together! This is was the idea. I've not tested it in combination with RFM69 but I don't see a reason why this should not work! :-)
-
@gonzalonal : I just downloaded the recent version of the binding again and I don't see this behaviour.
I hope both gateways will work together! This is was the idea. I've not tested it in combination with RFM69 but I don't see a reason why this should not work! :-)
@TimO I have solved my probles using OH2 Beta3 and the last release of the MyS binding.
It seems that the problem is only reproduced with the last release of OH2 from Cloudbees. At least withe the release 372.
Have you tryed it?
-
After a full computer crash (overheated CPU, CPU fan stopped working) I'm trying to set everything up on a new computer. Using the latest openhab2 beta 3 I'm having issues with using this binding. Specifically, whenever I add my standard thing configuration I get a buffer overflow in openhab which results in a core dump.
I have downloaded latest binding from the link at github, but that did not affect it. In addition to this binding I am using the zwave binding and rfxcom binding. All three connect to devices through serial ports, although I I'm not sure if they do it in the same way.
You may recall that I have had trouble using these three bindings together earlier, but for some reason things worked out and it has worked quite reliably since then.
I'm not sure which information from the system crash is useful, but if there is anything I can send you to help you figure out what happens, let me know. Also, I realise that this problem might not be related directly with mysensors, but maybe with the serial library used (I saw a reference to NVJavaSeria in the stack trace after the crash.
-
Hello again.
As a temporary fix I found a simple TCP/serial Gateway Python snippet that handles the connection to the serial mysensors device and provides a TCP interface to openhab. Switching the binding of aggression from serial to socket and having it connected to this software gateway removes the core dump issue. This confirms my suspicions that the issues are with the serial port library.
It works okay as a workaround until someone figure something out :-)
If anyone else is having issues with the serial connection, this is the by then snippet I found and used:
https://github.com/pyserial/pyserial/blob/master/examples/tcp_serial_redirect.py
-
From what i can see this binding is not part of the official bindings for openHAB. Are there any plans to try to get this as a official binding for openhab?
/Fredrik
-
From what i can see this binding is not part of the official bindings for openHAB. Are there any plans to try to get this as a official binding for openhab?
/Fredrik
@Fredrik-Jönsson : Yes, this is on my to do list with high priority. I've done some preparations but need to contact the OH2 developers before creating a PR.