openHAB 2.0 binding
-
Hi @TimO . Great work so far. I'd like to join in and extend your module with a lot more S_ and V_ types. Your Github repo code was updated 3 months ago. Do you want to push your commits so I can fork it?
Also another question: Do I need something special or is the default OpenHAB 2 IDE as described on the OpenHAB2 page enough to start?
-
Hi @SiLeX !
I would really appreciate your help!
My Repo is up to date, there are no open code changes. I've merged my Repo with the master/upstream, so OH2 too is up to date.The instructions here should work just fine, although I didn't set up my environment this way:
https://github.com/wishmoooop/openhab2/blob/master/docs/sources/development/ide.mdThere is only one step needed to activate the MySensors binding, it is an addition to the step 8 in the instructions:
- Click on "Run"
- Click on "Run Configurations ..."
- Select "OpenHAB_Runtime" on the left
- Switch to "Plug-Ins" on the right
- Search for "org.openhab.binding.mysensors" and mark it
(At this step I disable yahooweather and astro so they stop to annoy me with newly discovered locations) ;-)
If "strange" errors occure while testing code changes, delete the content of the "userdata" directory in "distribution/openhabhome".
-
@TimO said:
Search for "org.openhab.binding.mysensors" and mark it
Unfortunately I cannot find this in the list. I already added your fork as upstream master and pulled it. Anything else to change in there?

edit: solved by throwing away the openhab2 dev repo and cloning @TimO 's repo richt after installing the OpenHAB IDE. Alternatively you can create a new workspace and import/clone @TimO 's repo from there.
Run a product stays empty, interesting files are in addons/binding/org.openhab.binding.mysensors/ESH-INF/thing/
-
@powermta : What is your problem? :)
-
@BenCranston I finally found some time to further investigate this issue. Your guess according to the serial port issue was right. I've managed to "fix" the zwave binding using the code found while following the thread you mentioned.
I've created a modified version of the zwave binding:
org.openhab.binding.zwave-1.8.0-SNAPSHOT.jar
org.openhab.binding.mysensors-2.0.0-SNAPSHOT.jar
(I've not changed the mysensors binding, just added it for reference)Could you please test it? The binding is throwing messages and trying to contact the zwave gateway/stick:
2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = GetVersion (0x15), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 1 2015-10-13 08:32:44 [DEBUG] [WaveController$ZWaveSendThread:1228 ] - Took message from queue for sending. Queue length = 0 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ] - Assembled message buffer = 01 03 00 15 E9 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = MemoryGetId (0x20), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 1 2015-10-13 08:32:44 [DEBUG] [WaveController$ZWaveSendThread:1285 ] - NODE 255: Sending REQUEST Message = 01 03 00 15 E9 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = SerialApiGetCapabilities (0x07), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 2 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = SerialApiSetTimeouts (0x06), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 3 2015-10-13 08:32:44 [DEBUG] [i.p.s.GetSucNodeIdMessageClass:30 ] - Get SUC NodeID 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = GetSucNodeId (0x56), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 4 2015-10-13 08:32:46 [DEBUG] [z.internal.ZWaveNetworkMonitor:315 ] - Network Monitor: Queue length is 4 - deferring network monitor functions. 2015-10-13 08:32:49 [ERROR] [WaveController$ZWaveSendThread:1326 ] - NODE 255: Timeout while sending message. Requeueing - 2 attempts left! 2015-10-13 08:32:49 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 5 2015-10-13 08:32:49 [DEBUG] [WaveController$ZWaveSendThread:1228 ] - Took message from queue for sending. Queue length = 4 2015-10-13 08:32:49 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ] - Assembled message buffer = 01 03 00 15 E9 2015-10-13 08:32:49 [DEBUG] [WaveController$ZWaveSendThread:1285 ] - NODE 255: Sending REQUEST Message = 01 03 00 15 E9@TimO Sorry it took so long to test this. I've been flat on my back due to illness. Regardless, I tested it a bunch this morning and the changes to the zwave binding totally broke zwave functionality. The USB stick initializes but then the port gets "lost" and any attempts to interact with it fail. The change does allow for the MySensors binding to run. I removed the MySensors binding and just left your modified zwave binding in the addons folder to try to isolate the issue. It would appear that the modified zwave binding is broken. I'm going to pull the latest build from cloudbees and try your latest build of the MySensors binding and see what happens.
-
For what it's worth, I'm using openhab 2 with a version from yesterday together with the latest my sensor binding I found here. Serial gateway and serial aeon stick zwave controller (latest binding from the build server). Absolutely no issues for me.
-
For what it's worth, I'm using openhab 2 with a version from yesterday together with the latest my sensor binding I found here. Serial gateway and serial aeon stick zwave controller (latest binding from the build server). Absolutely no issues for me.
@kolaf I concur. I just refreshed everything to latest snapshots and holy smokes it all works. :) I'm watching my zwave rules and MySensors controls all working together. At this point, I'm not sure what was broken with my install, but both bindings are now playing with each other very well without issue.
-
I can report continued success with the MySensors binding playing nice with the Z-Wave binding. :) Today I'm working out some more rules and have a situation, where when a switch state is changed we send out command to another MySensor to change two childIDs on the same nodeID and another childID on a different nodeID. Two of the messages get out to gateway with the third not going out. Here's the debug:
2015-11-11 09:49:00 [DEBUG] [.b.m.p.s.MySensorsSerialWriter:40 ] - Sending to MySensors: 10;1;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.b.m.p.s.MySensorsSerialWriter:40 ] - Sending to MySensors: 9;2;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.b.m.p.s.MySensorsSerialWriter:40 ] - Sending to MySensors: 9;4;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-10-10 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;read: 10-10-0 s=1,c=1,t=2,pt=2,l=2,sg=0:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-10-10 s=1,c=1,t=2,pt=2,l=2,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 10;1;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-9-9 s=2,c=1,t=2,pt=0,l=1,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;read: 9-9-0 s=2,c=1,t=2,pt=2,l=2,sg=0:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-9-9 s=2,c=1,t=2,pt=2,l=2,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 9;2;1;0;2;1It appears that all three messages are queued, but only the first two are actually sent. I switched the order around in the rule to send the messages in a different order and only the first two make it out to the nodes. Do I need to delay some after each command? Anyone else able to reproduce this? Thanks.
the driving rule looks like this:
rule "g01_Stair" when Item home_group_5a59cc99 changed then if (mysensors_light_508ef404_Light_10_1_status.state == ON) { // sendCommand(mysensors_light_508ef404_Light_9_2_status, ON) sendCommand(mysensors_light_508ef404_Light_9_4_status, ON) } else if (mysensors_light_508ef404_Light_10_1_status.state == OFF) { // sendCommand(mysensors_light_508ef404_Light_9_2_status, OFF) sendCommand(mysensors_light_508ef404_Light_9_4_status, OFF) } end -
Hello Timo,
Great Work !!:smiley:Could You suggest a good Tutorial for understanding how to develope Bindings for HopenHab2?
Anyway I will study your code tooRegards
Mirko Ugolini
-
I've been testing this on my side and I have to say that is excellent.
Very well integrated with the 'Things' discovery model for OH2, etc.
The only thing that is really stopping me to move forward is OH itself. I have several (and somehow disapointing) experiences that makes me feel that is still very beta. Not sure if anyone have any update on when the RTM is expected???
Great work @TimO ! ! !
-
@mirko-ugolini The documentation on how to develop bindings for OH2 is rather thin. :(
Starting point is here: https://github.com/openhab/openhab2/blob/master/docs/sources/development/ide.mdFrom that point I've looked into the existing bindings and into the eclipse smarthome documentation, that does not work all the time, but the concepts match.
If you would like to contribute to the MySensors binding I will gladly help you to find the entrance. :)
@BenCranston I will have a look at it. Thanks for testing! The queue currently is rather basic (but should work). Maybe the data is written too fast to the serial output. I have a similar problem with OH 1.X and my rules, where I need to define a delay between commands.
Something I plan to do, is adding the ACK functionality to the binding, so if no ACK is received the command is repeated for 5 times or so.
-
@Dave-Dan said:
The only thing that is really stopping me to move forward is OH itself. I have several (and somehow disapointing) experiences that makes me feel that is still very beta. Not sure if anyone have any update on when the RTM is expected???
Yeah, I see your point. As far as I know there currently is no real roadmap for OH2, which is rather annoying. On the other side there is a really healthy discussion running on how to maintain the code. There are so many developers with bindings, bugfixes and pull requests that want to contribute, that the OH organisation has to change its structure.
At the moment the number of open pull requests for OH and OH2 is huge, so I hesitate to give the MySensors binding a shot.
-
@mirko-ugolini The documentation on how to develop bindings for OH2 is rather thin. :(
Starting point is here: https://github.com/openhab/openhab2/blob/master/docs/sources/development/ide.mdFrom that point I've looked into the existing bindings and into the eclipse smarthome documentation, that does not work all the time, but the concepts match.
If you would like to contribute to the MySensors binding I will gladly help you to find the entrance. :)
@BenCranston I will have a look at it. Thanks for testing! The queue currently is rather basic (but should work). Maybe the data is written too fast to the serial output. I have a similar problem with OH 1.X and my rules, where I need to define a delay between commands.
Something I plan to do, is adding the ACK functionality to the binding, so if no ACK is received the command is repeated for 5 times or so.
@TimO said:
Something I plan to do, is adding the ACK functionality to the binding, so if no ACK is received the command is repeated for 5 times or so.
+1 for the ack functionality. In my opinion this is a Transport-Layer functionality and should be built into the gateway (Arduino or whatever) itself. But the main developer doesn't like the idea because he is fearful that the serial buffer (or even an arduino queue system) will be unable queue enough messages while resends happen.
On the other hand: we have plenty of RAM on our openhab hosts, so your idea seems like it will solve the problem completely, because we could even react on continous fails with putting the device offline (or whatever the openhab2 terms are for this) :grin:
-
@BenCranston : I'm pretty sure now, OH2 is sending the data too fast, because if I use terminal emulation instead of hardware all three commands are transmitted.
Just curious: are you using an ethernet or serial gateway?
-
I've added an option to influence the delay between messages send to gateway.
Possible values are 1 to 1000 milliseconds.
-
@TimO Would it be too much trouble for you to implement support for S_MULTIMETER? It seems that this is required for me to get the voltage reading from my battery driven sensors. Alternatively, is there anything you can do with the battery percentage that is sent using sendBatteryPercent? I don't know if OH2 has any notion of the sensors battery level?
I notice you have support for the type S_VOLTAGE, but I cannot find that this is present in the master branch of MySensors?
-
Also, from where can we download the latest versions of your binding?
-
And finally, GREAT WORK :-)
-
@kolaf Thank you! :)
I update the download in the first post here, whenever I upload a new version.
Newest update 1 minute ago: Implementation of S_MULTIMETER!
Please let me know if this works for you.
I'm planning to add a battery channel for every sensor. So if a sensor is added via UI, you are able to select/deselect a channel you don't need it. In *.items you are free to define the channel too.
-
Thanks, that was quick. However, something is not right:
2015-11-23 17:47:17 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:multimeter, mysensors:power, mysensors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, mysensors:light-level]' on 'MySensorsDiscoveryService'... 2015-11-23 17:47:17 [ERROR] [i.DiscoveryServiceRegistryImpl:339 ] - Cannot trigger scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:multimeter, mysensors:power, mysensors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, mysensors:light-level]' on 'MySensorsDiscoveryService'!java.lang.NullPointerException: null at org.openhab.binding.mysensors.service.DiscoveryThread.stop(DiscoveryThread.java:23) at org.openhab.binding.mysensors.discovery.MySensorsDiscoveryService.stopScan(MySensorsDiscoveryService.java:63) at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:173) at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:336) at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:321) at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:172) at org.eclipse.smarthome.io.rest.core.discovery.DiscoveryResource.scan(DiscoveryResource.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606)