openHAB 2.0 binding
-
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
-
@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
-
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
-
@kolaf for which speed did you configure the serial gateway? The MySensors default or the openHAB default 9600 baud?
-
@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?
-
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.
-
@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).
-
-
@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.7Apart 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.logThis 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).
-
@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.
-
@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
-
@kolaf Ah, this makes sense. I will try that later.
-
@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...
-
@kolaf
In the examples the nodes retries requesting this information until they get it.
-
@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.
-
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.
-
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?
-
@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...
-
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.
-
@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.
-
There it is, the Child ID is included in the request message :-). Sorry for the confusion caused by my lack of observation skills.
-
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
-
-
@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?
-
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.
-
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.
-
@bpair Thanks for your feedback. I'm glad it works.
I'm currently adding some sensors and plan to test them against @barduino s mocksensor.
-
oh let me update the code then.
Did some fixes since my last commit
Cheers
UPDATE
Guys, folks here at MySensor were gracefull enough to upgrade the MockMySensors to lib 1.5 and I didn't realise that. So making a dumb mistake I've tried to update the development branch from my local copy.
I don't think the pull request went through which is good and I think you should be fine with the master version.Cheers
-
I am new to MySensors and for that matter home automation in general, but I have setup OpenHab 2.0 on Windows 7 with a serial gateway device. I built a humidity and temp sensor and after a bit of trial and error (30 mins) the sensors were detected within OpenHab. Sensors are updating every 30 seconds without any issues even though the gateway is in the loft and the sensor is in the downstairs living room. I am very impressed at how easy your auto detection has made the initial setup. I have initially bought Vera Edge but my serial gateway has the wrong chipset to work with it so thought I would give this a try. I am tempted to sell the Vera now after having quick success thanks to your help, just need to keep an eye on the OpenHab 2.0 development and hope it's ready to use sometime soon.
-
@Atomfire I'm glad it worked for you too!!
I've added a few additional sensors:
- S_DOOR
- S_MOTION
- S_SMOKE
- S_DIMMER
- S_COVER (V_STOP not implemented in OH2, can't use it yet)
- S_WIND
- S_RAIN
- S_UV
- S_WEIGHT
- S_DISTANCE
- S_LIGHT_LEVEL
Downloadlink is in the first post and I've modified the instructions.
Please delete the content of the userdata directory if you already tested with an older version of the binding. OH2 may get confused (throws exceptions) otherwise.
-
after installing openhab2 this way how do I keep it updated?
-
This is probably a better question for the openHAB2 google group but is there anyway to persist the data without having to create a items.xml? Or another way to put it, is there any way to persist data for a sensor that is detected and added?
-
For those interested in OpenHAB - they have a new forum here:
http://community.openhab.org/I think/hope it will be easier to use that the google groups.
-
@gregl the link doesn't work, here is the correct one:
https://community.openhab.org/
(only that annoying little s after http i think
)
-
Firstly great work on the binding... it makes openhab2 a bit more attractive.
Not entirely sure how to debug this further as I'm very new to openhab but after setting all my sensors up (even via discovery which is cool) after I restart the openhab2 service the MYS things never get initialized and stay in the UNINITIALIZED state.
Running on RP2 and start_debug.sh I see the incoming MYS messages but OH2 is not updating the thing, for example
2015-08-15 04:04:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:68 ] - 4;0;1;0;0;29.0
2015-08-15 04:05:08 [DEBUG] [b.m.p.ip.MySensorsIpConnection:68 ] - 1;0;1;0;0;30.0However if I go in to the thing via the paperui, edit/save it. The thing is then initialized and I can see in the console OH2 updating the thing when a message is received.
2015-08-15 04:08:53 [DEBUG] [b.m.p.ip.MySensorsIpConnection:68 ] - 1;0;1;0;0;30.0
2015-08-15 04:08:53 [INFO ] [runtime.busevents :27 ] - mysensors_temperature_08797005_Temperature_1_0_temp state updated to 30.0I deleted the userdata directory before updating to the latest version 3 days ago.
No idea if this is a OH2 issue or a binding issue though.
-
@Qu3Uk: Thank you for the report. I am able to reproduce this. I suppose it is an error in my binding because some parts are started correctly. I will look into it.
-
@TimO Good to know its not just me, may still be O2 it is alpha after all.
Now to figure out these rules..
-
Hi @TimO, any chance you add support to MySensors MQTT to your great work in progress ?
-
How do I add this button from the paper UI ? I can´t understand what to enter in the child id, node id fields.
/** * The MySensors Arduino library handles the wireless radio link and protocol * between your home built sensors/actuators and HA controller of choice. * The sensors forms a self healing radio network with optional repeaters. Each * repeater and gateway builds a routing tables in EEPROM which keeps track of the * network topology allowing messages to be routed to nodes. * * Created by Henrik Ekblad <henrik.ekblad@mysensors.org> * Copyright (C) 2013-2015 Sensnology AB * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors * * Documentation: http://www.mysensors.org * Support Forum: http://forum.mysensors.org * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * ******************************* * * DESCRIPTION * * Simple binary switch example * Connect button or door/window reed switch between * digitial I/O pin 3 (BUTTON_PIN below) and GND. * http://www.mysensors.org/build/binary */ #include <MySensor.h> #include <SPI.h> #include <Bounce2.h> #define CHILD_ID 3 #define BUTTON_PIN 3 // Arduino Digital I/O pin for button/reed switch MySensor gw; Bounce debouncer = Bounce(); int oldValue=-1; // Change to V_LIGHT if you use S_LIGHT in presentation below MyMessage msg(CHILD_ID,V_TRIPPED); void setup() { gw.begin(); // Setup the button pinMode(BUTTON_PIN,INPUT); // Activate internal pull-up digitalWrite(BUTTON_PIN,HIGH); // After setting up the button, setup debouncer debouncer.attach(BUTTON_PIN); debouncer.interval(5); // Register binary input sensor to gw (they will be created as child devices) // You can use S_DOOR, S_MOTION or S_LIGHT here depending on your usage. // If S_LIGHT is used, remember to update variable type you send in. See "msg" above. gw.present(CHILD_ID, S_DOOR); } // Check if digital input has changed and send in new value void loop() { debouncer.update(); // Get the update value int value = debouncer.read(); if (value != oldValue) { // Send in the new value gw.send(msg.set(value==HIGH ? 1 : 0)); oldValue = value; } }
-
@Cliff-Karlsson : Start the discovery process in the paper ui and after that restart your sensor. The sensor will represent itself while starting up and should appear in the paper ui.
-
@fets: I'm not very familiar with MQTT but that should already work with the 1.X binding, or not?
-
@TimO yes I think it works with manual bindins (several discussions mention it) but I meant using paper ui as you do here
-
Well if I add a door sensor and just enter some random node id/child Id it shows up as online. I never managed to add any sensor automatically even if I start the search process and resetting any sensors.
But the problem is that I can't get any reaction from the switch. I have tried connecting a button to pin 3 and also tried just connecting a cable from pin 3 to gnd. But no reaction whatever I do.
-
@Qu3Uk : Fixed the error. The sensors were initialized before the bridge was up.
@Cliff-Karlsson: The status of a thing in OH is not reliable and I'm yet not sure how to make it reliable because the connection between sensor and gateway is stateless, so a sensor maybe is online even if it only transmits one time per day.
In your case: what is the output of the "start_debug.sh"? Are there messages from the MySensors Gateway logged?
-
Nice work!
Did anyone try the binding with FakeMySensors?
http://forum.mysensors.org/topic/1648/test-your-home-made-controller-with-fakemysensors
-
after OH2 restart I got "UNINITIALIZED - HANDLER_INITIALIZING_ERROR" for all already existing sensors. If I add a new sensors it works until OH2 restart
-
on thing removing:
2015-08-21 19:40:36 [DEBUG] [.c.thing.internal.ThingManager:174 ] - Asking handler of thing 'mysensors:temperature:8da0bd23:Temperature_87_1' to handle its removal.
2015-08-21 19:40:36 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:8da0bd23:Temperature_87_1' updated: REMOVING
2015-08-21 19:40:36 [ERROR] [.c.thing.internal.ThingManager:178 ] - The ItemHandler caused an exception while handling the removal of its thingjava.lang.NullPointerException: null
at org.eclipse.smarthome.core.thing.internal.ThingManager$1.statusUpdated(ThingManager.java:176)
at org.eclipse.smarthome.core.thing.internal.ThingManager.thingRemoving(ThingManager.java:361)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyTrackers(ThingRegistryImpl.java:193)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.remove(ThingRegistryImpl.java:89)
at org.eclipse.smarthome.core.thing.setup.ThingSetupManager.removeThing(ThingSetupManager.java:442)
at org.eclipse.smarthome.io.rest.core.thing.setup.ThingSetupManagerResource.removeThing(ThingSetupManagerResource.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
-
@ZoTyA said:
after OH2 restart I got "UNINITIALIZED - HANDLER_INITIALIZING_ERROR" for all already existing sensors. If I add a new sensors it works until OH2 restart
This should be fixed but I don't think @Tim0 has released the fix yet? Might be wrong.
-
I'm pretty sure this time it is a bug in OH2, because my code works sometimes.
I've found a workaround and got 10/10 clean starts of OH2 and reinitializations of the configured things.Please let me know, if the error occures again!
Thanks for testing!!
-
How do I keep openhab2 updated after installing?
-
What do you want to keep updated? The OH2 runtime? The binding?
I update the link of the binding (jar-file) in the first post here whenever I add or fix something. You only have to switch this jar file in your installation. In the current alpha phase it is an good idea to delete the userdata folder, but with that you will lose all already discovered and added things. I have configured all things/items that should survive a deletion of the userdata in the thing.conf, items.conf etc.
For the future I plan to make a pull request so that the mysensors binding will be a fixed part of OH2, but I want to ensure its stability before I do so. Additionally there are some features I would like to add before making a pull request.
-
@Qu3Uk said:
@ZoTyA said:
after OH2 restart I got "UNINITIALIZED - HANDLER_INITIALIZING_ERROR" for all already existing sensors. If I add a new sensors it works until OH2 restart
This should be fixed but I don't think @Tim0 has released the fix yet? Might be wrong.
Confirmed - it is fixed.
Thanks
-
@TimO Slightly off topic but am I right in thinking even with discovered things you still have to manually create an item for the thing in the item.conf for stuff like rules to work?
-
@Qu3Uk I asked a similar question about persistence on the OH2 forum and the response was you could set up a group and configure persistence for it. Then as the new items are dynamically found they just need to be added to the group without adding them to the config files. Possibly the same thing would work for rules.
-
@Qu3Uk Looks like they are adding some support for this: https://community.openhab.org/t/rules-allowing-regexp-for-items-and-catching-individual-items-in-a-group/2165
-
@TimO I'm having difficulty with the mysensors binding and the zwave binding on OH2 startup. If both bindings are present, then mysensors gets loaded first (port=/dev/ttyS2) and then zwave tries to load (port=/dev/ttyUSB0) however it reports that it's serial port is not present. If I remove the mysensors binding jar file from addons and then start OH2, the zwave binding connects to its serial port correctly and works fine. I can then mv the mysensors binding back into addons and it will get loaded and bind correctly to it's serial port. I've tried to turn the logging up to debug and not got anything more from the bindings to tell me what's happening. any help is appreciated. thanks.
-
@BenCranston : Thanks for the bug report! You're right I'm able to reproduce this error. The zwave and mysensors binding both use the same library (gnu.io) to access serial ports.
-
@TimO I'm beginning to think this might be platform specific to the gnu.io library and manifest on ARM architectures. I moved my OH2 installation over to my Mac and "Viola!" both services started working without an issue. Are you on an ARM platform as well? Initially I was running the MySensors gateway off of a GPIO serial port on my Pi. As part of working this I moved the gateway to an FTDI USB connection, so both devices were /dev/ttyUSB[01]. That didn't change the behavior and they still failed to co-exist from boot. I'm going to take a look at the gnu.io RXTX stuff and see if I can find a lead there... I'm not a java programmer, so this should be fun.
-
@TimO It looks like someone else ran into the same issue trying to do z-wave and enocean, both being serial connections. The discussion over on the community at openhab.org is here: https://community.openhab.org/t/serial-ports-issue/2516
I wonder if that sheds any further lights on the issue. They did get a fix implemented in the EnOcean binding to play nice with the zwave binding.
-
@BenCranston : Thanks for looking further into the problem. I was able to reproduce the problem on a x86 architecture.
I've looked into the fix for insteon and I'm not sure if that helps, because I don't use the updateProperties() method that is fixed.I don't know zwave, so to be sure: I've changed:
port=/dev/pts/1in zwave.cfg. Is that correct?
(I've running a serial emulation on /dev/pts/1).
-
@TimO : Yes sir, that's the config step to tell the zwave binding where it's serial port is. The rest is done via files, or the habmin interface.
-
Hi @TimO
I have a ESP8266 as Ethernet GW and a Nano with a S_HUM, S_TEMP and a S_LIGHT_LEVEL.
I follow as described steps and the S_TEMP sensor is updated almost immediately, the S_HUM takes some minutes and the S_LIGHT_LEVEL is never updated.Can you take a look please?
Launching the openHAB runtime... Listening for transport dt_socket at address: 8001 2015-09-26 11:42:26 [DEBUG] [s.m.i.r.i.ItemRuntimeActivator:23 ] - Registered 'item' configuration parser 2015-09-26 11:42:26 [INFO ] [uartz.impl.StdSchedulerFactory:1184 ] - Using default implementation for ThreadExecutor 2015-09-26 11:42:26 [INFO ] [rtz.core.SchedulerSignalerImpl:61 ] - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl 2015-09-26 11:42:26 [INFO ] [rg.quartz.core.QuartzScheduler:240 ] - Quartz Scheduler v.2.2.1 created. 2015-09-26 11:42:26 [INFO ] [org.quartz.simpl.RAMJobStore :155 ] - RAMJobStore initialized. 2015-09-26 11:42:26 [INFO ] [rg.quartz.core.QuartzScheduler:305 ] - Scheduler meta-data: Quartz Scheduler (v2.2.1) 'openHAB-job-scheduler' with instanceId 'NON_CLUSTERED' Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally. NOT STARTED. Currently in standby mode. Number of jobs executed: 0 Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 2 threads. Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered. 2015-09-26 11:42:26 [INFO ] [uartz.impl.StdSchedulerFactory:1339 ] - Quartz scheduler 'openHAB-job-scheduler' initialized from specified file: './runtime/etc/quartz.properties' 2015-09-26 11:42:26 [INFO ] [uartz.impl.StdSchedulerFactory:1343 ] - Quartz scheduler version: 2.2.1 2015-09-26 11:42:26 [DEBUG] [.i.PersistenceRuntimeActivator:23 ] - Registered 'persistence' configuration parser 2015-09-26 11:42:26 [DEBUG] [s.m.r.r.i.RuleRuntimeActivator:35 ] - Registered 'rule' configuration parser 2015-09-26 11:42:26 [DEBUG] [m.s.r.i.ScriptRuntimeActivator:22 ] - Registered 'script' configuration parser 2015-09-26 11:42:26 [DEBUG] [.s.r.i.SitemapRuntimeActivator:23 ] - Registered 'sitemap' configuration parser 2015-09-26 11:42:26 [DEBUG] [.m.t.r.i.ThingRuntimeActivator:23 ] - Registered 'thing' configuration parser osgi> 2015-09-26 11:42:27 [WARN ] [.j.s.handler.RequestLogHandler:137 ] - !RequestLog 2015-09-26 11:42:27 [DEBUG] [.c.d.internal.ConfigDispatcher:222 ] - Processing config file 'services.cfg' 2015-09-26 11:42:27 [DEBUG] [.c.d.internal.ConfigDispatcher:222 ] - Processing config file 'runtime.cfg' 2015-09-26 11:42:28 [DEBUG] [.s.core.internal.CoreActivator:30 ] - Core bundle has been started. 2015-09-26 11:42:28 [DEBUG] [.e.s.c.a.i.AutoUpdateActivator:29 ] - AutoUpdate binding has been started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/binding/binding.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [o.e.s.c.s.i.SchedulerActivator:34 ] - Scheduler has been started. 2015-09-26 11:42:28 [INFO ] [rg.quartz.core.QuartzScheduler:575 ] - Scheduler openHAB-job-scheduler_$_NON_CLUSTERED started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:159 ] - Create an empty XmlDocumentProvider for the module 'org.openhab.binding.mysensors'. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/thing/channels.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [.c.t.i.TransformationActivator:34 ] - Transformation Service has been started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:159 ] - Create an empty XmlDocumentProvider for the module 'org.openhab.binding.mysensors'. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/thing/thing-types.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [.e.s.i.m.i.MultimediaActivator:32 ] - Multimedia I/O bundle has been started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/thing/bridges.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [io.rest.internal.RESTActivator:32 ] - REST API has been started. 2015-09-26 11:42:28 [DEBUG] [s.i.t.m.internal.MDNSActivator:27 ] - mDNS service has been started. 2015-09-26 11:42:28 [DEBUG] [.i.t.m.internal.MDNSClientImpl:37 ] - mDNS service has been started 2015-09-26 11:42:28 [DEBUG] [i.t.m.internal.MDNSServiceImpl:85 ] - Registering new service _openhab-server._tcp.local. at port 8080 2015-09-26 11:42:28 [DEBUG] [i.t.m.internal.MDNSServiceImpl:85 ] - Registering new service _openhab-server-ssl._tcp.local. at port 8443 2015-09-26 11:42:28 [DEBUG] [.i.r.sse.internal.SseActivator:46 ] - SSE API - SseFeature registered. 2015-09-26 11:42:28 [DEBUG] [.i.r.sse.internal.SseActivator:55 ] - SSE API has been started. 2015-09-26 11:42:28 [DEBUG] [.io.transport.mqtt.MqttService:118 ] - Starting MQTT Service... 2015-09-26 11:42:28 [DEBUG] [.s.s.mapdb.MapDbStorageService:50 ] - Opened MapDB file at 'D:\Downloads\openhab2\.\userdata\mapdb\storage.mapdb'. 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.items.ManagedItemProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.thing.ManagedThingProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [.core.common.ThreadPoolManager:141 ] - Created scheduled thread pool 'discovery' of size 3 2015-09-26 11:42:28 [DEBUG] [.c.thing.internal.ThingManager:549 ] - Thing handler factory 'MySensorsHandlerFactory' added 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.thing.link.ManagedItemChannelLinkProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.thing.link.ManagedItemThingLinkProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [ui.internal.chart.ChartServlet:122 ] - Starting up chart servlet at /chart 2015-09-26 11:42:28 [DEBUG] [u.i.chart.DefaultChartProvider:97 ] - Starting up default chart provider. 2015-09-26 11:42:28 [DEBUG] [o.e.s.u.c.i.servlet.CmdServlet:56 ] - Starting up CMD servlet at /classicui/CMD 2015-09-26 11:42:28 [DEBUG] [s.ui.icon.internal.IconServlet:76 ] - Starting up icon servlet at /icon 2015-09-26 11:42:28 [INFO ] [ui.internal.servlet.PaperUIApp:31 ] - Started Paper UI at /ui 2015-09-26 11:42:29 [DEBUG] [e.s.i.t.upnp.UpnpIOServiceImpl:152 ] - Starting UPnP IO service... 2015-09-26 11:42:29 [INFO ] [.u.d.internal.DashboardService:55 ] - Started dashboard at /start 2015-09-26 11:42:29 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.model.item.internal.GenericItemProvider' has been added. 2015-09-26 11:42:29 [INFO ] [rg.quartz.core.QuartzScheduler:2311 ] - JobFactory set to: org.eclipse.smarthome.model.rule.runtime.internal.engine.GuiceAwareJobFactory@1762bd77 2015-09-26 11:42:29 [DEBUG] [.m.r.r.i.engine.RuleEngineImpl:96 ] - Started rule engine 2015-09-26 11:42:29 [INFO ] [.s.u.c.i.servlet.WebAppServlet:85 ] - Started Classic UI at /classicui/app 2015-09-26 11:42:29 [DEBUG] [e.s.m.t.i.GenericThingProvider:696 ] - ThingHandlerFactory added org.openhab.binding.mysensors.internal.MySensorsHandlerFactory@25ceff93 2015-09-26 11:42:29 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.model.thing.internal.GenericThingProvider' has been added. 2015-09-26 11:42:29 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.model.thing.internal.GenericItemChannelLinkProvider' has been added. 2015-09-26 11:42:29 [DEBUG] [ui.internal.proxy.ProxyServlet:94 ] - Starting up proxy servlet at /proxy 2015-09-26 11:42:29 [INFO ] [.o.core.internal.CoreActivator:41 ] - openHAB runtime has been started (v2.0.0, build 201509240103). 2015-09-26 11:42:29 [DEBUG] [.o.core.internal.CoreActivator:47 ] - Startup took 6896 ms 2015-09-26 11:42:36 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:42:49 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element home_group_daef4dc3 to ManagedItemProvider. 2015-09-26 11:42:49 [DEBUG] [.core.common.ThreadPoolManager:171 ] - Created thread pool 'safeCall' with size 3-10 2015-09-26 11:42:49 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'home_group_daef4dc3' has been added. 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:bridge-eth:c27764bd' is tracked by ThingManager. 2015-09-26 11:43:31 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:bridge-eth:c27764bd' has been added. 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:bridge-eth:c27764bd' at 'org.openhab.binding.mysensors.intern erFactory@25ceff93'. 2015-09-26 11:43:31 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:bridge-eth:c27764bd' updated: INITIALIZING 2015-09-26 11:43:31 [DEBUG] [.core.common.ThreadPoolManager:141 ] - Created scheduled thread pool 'thingHandler' of size 3 2015-09-26 11:43:31 [DEBUG] [o.b.m.h.MySensorsBridgeHandler:58 ] - Initialization of the MySensors Bridge 2015-09-26 11:43:31 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 192.168.0.17 to field 'ipAddress' in configuration class org.openhab.binding.mysensors.conf eConfiguration 2015-09-26 11:43:31 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 5003 to field 'tcpPort' in configuration class org.openhab.binding.mysensors.config.MySenso tion 2015-09-26 11:43:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:40 ] - Connecting to bridge ... 2015-09-26 11:43:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:56 ] - Connection to ethernet gateway successful! 2015-09-26 11:43:31 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:bridge-eth:c27764bd' updated: ONLINE 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:bridge-eth:c27764bd' added. 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:bridge-eth:c27764bd'. 2015-09-26 11:43:31 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:bridge-eth:c27764bd to ManagedThingProvider. 2015-09-26 11:43:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 0;0;3;0;14;Gateway startup complete. 2015-09-26 11:43:32 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_bridge_eth_c27764bd to ManagedItemProvider. 2015-09-26 11:43:32 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_bridge_eth_c27764bd' has been added. 2015-09-26 11:43:32 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_bridge_eth_c27764bd' to thing 'mysensors:bridge-eth:c27764bd'. 2015-09-26 11:43:32 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_bridge_eth_c27764bd -> mysensors:bridge-eth:c27764bd to ManagedItemThingLinkProvider. 2015-09-26 11:43:32 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:44:02 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:44:14 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;38 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:humidity:7d1da077' is tracked by ThingManager. 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:humidity:7d1da077' at 'org.openhab.binding.mysensors.internal Factory@25ceff93'. 2015-09-26 11:44:16 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:humidity:7d1da077' has been added. 2015-09-26 11:44:16 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:humidity:7d1da077' updated: INITIALIZING 2015-09-26 11:44:16 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:humidity:7d1da077' updated: ONLINE 2015-09-26 11:44:16 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'nodeId' in configuration class org.openhab.binding.mysensors.config.MySensorsSe 2015-09-26 11:44:16 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 0 to field 'childId' in configuration class org.openhab.binding.mysensors.config.MySensorsS n 2015-09-26 11:44:16 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:humidity:7d1da077' updated: ONLINE 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:humidity:7d1da077' added. 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:humidity:7d1da077'. 2015-09-26 11:44:16 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:humidity:7d1da077 to ManagedThingProvider. 2015-09-26 11:44:16 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_humidity_7d1da077' has been added. 2015-09-26 11:44:16 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077 to ManagedItemProvider. 2015-09-26 11:44:16 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_humidity_7d1da077' to thing 'mysensors:humidity:7d1da077'. 2015-09-26 11:44:16 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077 -> mysensors:humidity:7d1da077 to ManagedItemThingLinkProvider. 2015-09-26 11:44:17 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077_hum to ManagedItemProvider. 2015-09-26 11:44:17 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_humidity_7d1da077_hum' has been added. 2015-09-26 11:44:17 [DEBUG] [.c.t.internal.ThingLinkManager:317 ] - Adding linked item 'mysensors_humidity_7d1da077_hum' to channel 'mysensors:humidity:7d1da077:hum'. 2015-09-26 11:44:17 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077_hum -> mysensors:humidity:7d1da077:hum to ManagedItemChannelLinkProv 2015-09-26 11:44:17 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:44:27 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:light-level:9e706943' is tracked by ThingManager. 2015-09-26 11:44:48 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:light-level:9e706943' has been added. 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:light-level:9e706943' at 'org.openhab.binding.mysensors.inter lerFactory@25ceff93'. 2015-09-26 11:44:48 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'nodeId' in configuration class org.openhab.binding.mysensors.config.MySensorsSe 2015-09-26 11:44:48 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 2 to field 'childId' in configuration class org.openhab.binding.mysensors.config.MySensorsS n 2015-09-26 11:44:48 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:light-level:9e706943' updated: INITIALIZING 2015-09-26 11:44:48 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:light-level:9e706943' updated: ONLINE 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:light-level:9e706943' added. 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:light-level:9e706943'. 2015-09-26 11:44:48 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:light-level:9e706943' updated: ONLINE 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:light-level:9e706943 to ManagedThingProvider. 2015-09-26 11:44:48 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_light_level_9e706943' has been added. 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943 to ManagedItemProvider. 2015-09-26 11:44:48 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_light_level_9e706943' to thing 'mysensors:light-level:9e706943'. 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943 -> mysensors:light-level:9e706943 to ManagedItemThingLinkProvider 2015-09-26 11:44:48 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_light_level_9e706943_light_level' has been added. 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943_light_level to ManagedItemProvider. 2015-09-26 11:44:48 [DEBUG] [.c.t.internal.ThingLinkManager:317 ] - Adding linked item 'mysensors_light_level_9e706943_light_level' to channel 'mysensors:light-level:9e706943:light-l 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943_light_level -> mysensors:light-level:9e706943:light-level to Mana kProvider. 2015-09-26 11:44:48 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:45:05 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:45:06 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:temperature:4a73d1fa' has been added. 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:temperature:4a73d1fa' is tracked by ThingManager. 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:temperature:4a73d1fa' at 'org.openhab.binding.mysensors.inter lerFactory@25ceff93'. 2015-09-26 11:45:06 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:4a73d1fa' updated: INITIALIZING 2015-09-26 11:45:06 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'nodeId' in configuration class org.openhab.binding.mysensors.config.MySensorsSe 2015-09-26 11:45:06 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'childId' in configuration class org.openhab.binding.mysensors.config.MySensorsS n 2015-09-26 11:45:06 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:4a73d1fa' updated: ONLINE 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:temperature:4a73d1fa' added. 2015-09-26 11:45:06 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:4a73d1fa' updated: ONLINE 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:temperature:4a73d1fa'. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:temperature:4a73d1fa to ManagedThingProvider. 2015-09-26 11:45:06 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_temperature_4a73d1fa' has been added. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa to ManagedItemProvider. 2015-09-26 11:45:06 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_temperature_4a73d1fa' to thing 'mysensors:temperature:4a73d1fa'. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa -> mysensors:temperature:4a73d1fa to ManagedItemThingLinkProvider 2015-09-26 11:45:06 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_temperature_4a73d1fa_temp' has been added. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa_temp to ManagedItemProvider. 2015-09-26 11:45:06 [DEBUG] [.c.t.internal.ThingLinkManager:317 ] - Adding linked item 'mysensors_temperature_4a73d1fa_temp' to channel 'mysensors:temperature:4a73d1fa:temp'. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa_temp -> mysensors:temperature:4a73d1fa:temp to ManagedItemChannel 2015-09-26 11:45:06 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:45:14 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:45:40 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:46:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 0;0;3;0;14;Gateway startup complete. 2015-09-26 11:46:09 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:46:21 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;38 2015-09-26 11:46:27 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:48:03 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:48:03 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:48:03 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:49:32 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:49:45 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.1 2015-09-26 11:49:45 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.1 2015-09-26 11:49:45 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:49:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:50:10 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:50:23 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;45 2015-09-26 11:50:23 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 45 2015-09-26 11:50:23 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:50:36 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:51:01 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:51:14 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:52:05 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:52:30 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:53:08 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 7 2015-09-26 11:53:21 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:53:21 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:53:21 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;33 2015-09-26 11:53:33 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 6 2015-09-26 11:53:46 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;33 2015-09-26 11:53:59 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:56:06 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 5 2015-09-26 11:56:19 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;23.8 2015-09-26 11:56:19 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 23.8 2015-09-26 11:56:19 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;69 2015-09-26 11:56:19 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 69 2015-09-26 11:56:19 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 3 2015-09-26 11:56:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.5 2015-09-26 11:56:31 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.5 2015-09-26 11:56:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;81 2015-09-26 11:56:31 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 81 2015-09-26 11:56:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;32 2015-09-26 11:56:44 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:56:44 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:56:44 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;77 2015-09-26 11:56:44 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 77 2015-09-26 11:56:44 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 8 2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.4 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.4 2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;65 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 65 2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:57:10 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;57 2015-09-26 11:57:10 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 57 2015-09-26 11:57:22 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;53 2015-09-26 11:57:22 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 53 2015-09-26 11:57:22 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:57:35 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;50 2015-09-26 11:57:35 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 50 2015-09-26 11:57:35 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;19 2015-09-26 11:57:48 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;49 2015-09-26 11:57:48 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 49 2015-09-26 11:57:48 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;30 2015-09-26 11:58:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.3 2015-09-26 11:58:00 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.3 2015-09-26 11:58:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;48 2015-09-26 11:58:00 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 48 2015-09-26 11:58:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;26 2015-09-26 11:58:13 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;47 2015-09-26 11:58:13 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 47 2015-09-26 11:58:26 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;29 2015-09-26 11:58:39 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;46 2015-09-26 11:58:39 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 46 2015-09-26 11:58:39 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;27 2015-09-26 11:58:51 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:59:09 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.3 2015-09-26 11:59:09 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:59:09 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.3 2015-09-26 11:59:17 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;32Thank you
-
@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
-
Hello @Daniel-Oliveira!
- S_Temp looks good:
2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.4 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.4- S_HUM looks good too:
2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;65 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 65I can't see a reason why it should not update correctly. Could be a bug in the OH2 runtime? Does this bug persist with a current runtime?
- S_LIGHT_LEVEL
1;2;1;0;2;36With subtype 2 (V_STATUS) the binding is expecting 1 == ON or 2 == OFF.
For light level the binding is expecting V_PERCENTAGE.So a message like this should work:
1;2;1;0;3;36
-
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?
-
@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.
-
@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 !!
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.
-
@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)
-
@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)
-
@kolaf: Interesting. I'm not able to reproduce the error. Did you clean the userdata directory? OH2 gets stuck, when the xml-Definition changes, because it uses some sort of cache.
Because it is somewhat annoying to start from the scratch after deleting userdata, I define fixed things (like the gateway) in the *.things file.
https://github.com/wishmoooop/openhab2/tree/master/addons/binding/org.openhab.binding.mysensors
-
Thanks, it seems that that was the problem.
-
Hi everyone. Just to let you know OpenHAB 2.0.0 first BETA release is available. Unfortunatelly Tim0's binding is throwing some errors while OpenHAB tryes to install it.
2016-01-13 13:46:25.314 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/home/pi/OpenHAB2/Downloads/OpenHAB-Beta/addons/org.openhab.binding.mysensors-2.0.0-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.mysensors [166] Unresolved requirement: Import-Package: gnu.io at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1245)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1217)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:509)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)[8:org.apache.felix.fileinstall:3.5.0]Let me know Tim0 if I can help you fix this.
Thanks, regards.
Gonzalo.
-
kewl, thank 4 digging this up. I'm just evaluating openHab2
-
Hi Timo,
Regarding the errors in OH2beta, see this post for a possible solution.
Some other questions:
Is it possible to access sensors with different "V_types" for example V_VAR1 to a temperature sensor? I would like to send out numbers to my sensor nodes from rules.I was not able to get the battery level to work.
my item looks like this:Number SHBat "Storehouse Node Battery Level [%f %%]" (nSH,gBAT) { channel="mysensors:temperature:gateway:SHtemp_in:battery" }What is wrong?
Thank you for a great work!
/Tomas
-
Hi Tomas!
Thanks for the hint, I will take a closer look!
@ofverstedt said:
I would like to send out numbers to my sensor nodes from rules.
This is currently not possible, but it will be. It is on my ToDo list.
The current solution with the serial binding in OH 1.X is complicated, but leaves a lot of freedom for the user and I would like to preserve as much freedom as possible.I've implemented some new features a while ago, like resending of messages if no ACK is received. But the Repo is out of date. I will fix that.
-
Hi Tim0.
Really nice work with this binding. Huge step forward into a official MySensors OpenHAB binding.It would be nice to have the repo updated so as to try the new features you have implemented.
Have you had time to check why we are gewtting that error at OpenHAB 2 Beta while trying to install the binding?
Let me know if there is any way in which I can help.
Thanks, regards!Gonzalo.
-
Hi @gonzalonal !
I'm working on it. Due to the changes in the OH git repository my environment is all messed up.
-
This kind of problem (as I've read online) in this release of OH seems to be not only related to this binding. One suggestion that I found is here: https://github.com/openhab/openhab-distro/issues/82 (last comment) or here: https://github.com/openhab/openhab-distro/issues/81
I've tested it without success but I don't know if I've done it right. I've also try to build myself a rfxcom binding (this one use gnu.io) and it has the same issue
hope this help
EDIT: this work for me, run on OSGI console: feature:install openhab-transport-serial and restart OH
-
@andreacioni said:
This kind of problem (as I've read online) in this release of OH seems to be not only related to this binding. One suggestion that I found is here: https://github.com/openhab/openhab-distro/issues/82 (last comment) or here: https://github.com/openhab/openhab-distro/issues/81
I've tested it without success but I don't know if I've done it right. I've also try to build myself a rfxcom binding (this one use gnu.io) and it has the same issue
hope this help
EDIT: this work for me, run on OSGI console: feature:install openhab-transport-serial and restart OH
Hi @andreacioni.
You saved the day. It worked for me.
Here the steps I did to make it work.1- Download latest snapshot from https://openhab.ci.cloudbees.com/job/openHAB-Distribution/ (Download offline version)
2- Unzip the file.
3- Run start_debug.sh
4- In console write "feature:install openhab-runtime-compat1x"
5- Ctrl-D to exit/shutdown OpenHAB
6- Once exited, copy MySensors binding to addons folder.
7- Start againg OpenHAB-
8- Thats it. It should workRemember to copy your serial thing to things folder.
Regards!
Gonzalo
-
@andreacioni: Absolultly amazing! Thanks!
I don't understand why this helps though because the changes in the code I have to do have nothing to do with OH1 (compability).
I hope to provide an adjusted version today or tomorrow along with a clean and working repository.
Thanks for your patience!
-
@TimO I'think the OH1 compatibility is not the problem. It seems that OH2 beta1 have not installed transport feature and so it has no definition for the gno.io pakage, so I'think there's nothing to do on your code
PS tell me when the new repo is OK that I download it and try to add the baudrate config
Thanks!!
-
So, I would like to show you my current status. I've tested it against my mini MySensors environment and it looks good so far. Feel free to test.
-
Download latest snapshot from cloudbees: https://openhab.ci.cloudbees.com/job/openHAB-Distribution/lastSuccessfulBuild/artifact/distributions/openhab-offline/target/openhab-offline-2.0.0-SNAPSHOT.zip
-
Unzip file (into a directory like oh2).
-
Download the current binding from Binding and place it in the addons directory under oh2.
-
Configure addons, things, items and sitemap. Example?! addons.cfg, demo.things , demo.items, demo.sitemap
-
Start "start_debug.sh", "start_debug.bat" ...
-
In the karaf console enter: "feature:install openhab-transport-serial".
-
MySensors Plugin "should" start.
8: "log:set debug" + "log:tail" to see debug output.
Github and documentation will follow, please refer to the "old" Readme and the examples.
-
-
@TimO Hi Tim, for debugging outupt of the binding I need to write:
log:set DEBUG org.openhab.binding.mysensors, without this I cannot see anything about binding logs
-
@andreacioni Hi andreacioni. Same issue with debug mode with me. Thanks for the tip!
@TimO: V_STOP for Rollershutter sensors, is a MySensors binding limitation, or it is not implemented in OH2 yet?
Another thing I've noticed is that every item added, despite being a regular switch or a rollershutter, is is being added as:
Battery Level
mysensors:cover:gateway:Cover_1_0:battery
MySensors Battery ChannelIs this the intended behavior for every node of my sensor, despite having or not a battery?
Regards.
Gonzalo.
-
@gonzalonal said:
V_STOP for Rollershutter sensors, is a MySensors binding limitation, or it is not implemented in OH2 yet?
It is a limitation of OH2 and I don't understand the limitation. It is very confusing, because with the "RollerShutter" widget in OH2 I get three buttons: UP, DOWN and STOP. UP and down calls the handler in which I generate the MySensors message. STOP don't call the handler and therefore I can't do anything. I need to dig deeper.
Battery Level
mysensors:cover:gateway:Cover_1_0:battery
MySensors Battery ChannelIs this the intended behavior for every node of my sensor, despite having or not a battery?
This is intended behavior. The battery status is send via an internal message and there is no presentation if a sensor has a battery or not.
I've therefore added the battery channel to every item. In Paper UI you are able to simply disable the channel by clicking the blue circle next to the battery channel or in the configuration file you have to specify the channel, if you want to use it. If the battery channel is not defined for a thing it won't receive the battery status.For the future: maybe there is a way to hide the channel as long as there was no battery status received and display it only when used. But currently I don't see an easy way to implement that.
Greetings!
Tim
-
@TimO
Great TimO. Thanks for clarifying this topic.
Regards.
Gonzalo
-
@gonzalonal : I found a solution for V_STOP! It will be available soon.
But more important: @andreacioni is doing some great work improving the stability and performance of the binding!!
I just wanted to let you know, that the binding is currently under heavy development.
