openHAB 2.0 binding
-
-
There is a new build of the jar available!
Changes:
- Added delay before checking the SerialGW (@andreacioni )
- Requests are answered by the binding (The binding returns "0" if no value was set before)
Hello @TimO .
Just tested the last build of the binding. Works great.
I see you manage to answer the nodes requests without having to trigger a rule to respond.I though that wasn't possible due to the limitation of the API. Did they manage to solve this from the OH side?
Does the binding itself keeps track of the items values, or does it querys OH (or its persistence service) for getting the right value?
Thanks!
Gonzalo -
Hello @TimO .
Just tested the last build of the binding. Works great.
I see you manage to answer the nodes requests without having to trigger a rule to respond.I though that wasn't possible due to the limitation of the API. Did they manage to solve this from the OH side?
Does the binding itself keeps track of the items values, or does it querys OH (or its persistence service) for getting the right value?
Thanks!
GonzaloHi @gonzalonal !
I'm glad it works, thanks for testing!
Sadly the limitation of the API is still there, but for the implementation of the requestAck feature I needed to implement a memory and now reused this memory to answer requests.There is a really big BUT coming with this implementation: we currently can't use persistence out of the box. For this a rule is needed. After startup of OH we need to use "sendCommand(ITEMNAME, VALUE)", where VALUE Is the value stored in persistance. With that the memory of the binding is filled initially.
Hopefully I will find an easier way in the future . -
Hi @gonzalonal !
I'm glad it works, thanks for testing!
Sadly the limitation of the API is still there, but for the implementation of the requestAck feature I needed to implement a memory and now reused this memory to answer requests.There is a really big BUT coming with this implementation: we currently can't use persistence out of the box. For this a rule is needed. After startup of OH we need to use "sendCommand(ITEMNAME, VALUE)", where VALUE Is the value stored in persistance. With that the memory of the binding is filled initially.
Hopefully I will find an easier way in the future .I get what you mean @TimO .
Unfortunatelly, using the rule method you suggest would create a lot of traffic (depending on how many sensors you have) at boot up time. Maybe there are some sensors that wouldn't behave the intended way if receiving the "last value" repeteadly.
An example. Lets supose I have an automatic gate, that everytime it receives a command, wether its a "1" or "0" it toggles its moving direction. Like the most common automatic gates remotes.
Gate is closed.
Press button > Gate opens
Press button > (if gate moving) Gate stops
Press button > (if gate open) Gate closesNow, suppose last command send to the gate made it close. Suddenly, OH restarts itself because of power failure or whatever. It runs the rule to load the memory of the binding, while at the same time it sends to the sensors the last status taken from the persistance service. This would make the gate to open without your notice.
This may create dangerous escenarios.
I hope you can understand what I mean.Maybe it would be a better idea to handle requests with rules in the way I suggested in the github issue, that is the same way as the OH-1 mysensors serial binding works.
Let me know if I can help in any way.
Regards.Gonzalo.
-
@gonzalonal Good point! :worried:
If a request (or a message in general) is received there is no "commandReceived" in OH, so you can't trigger a rule based on a message received. So doing it with a rule is not possible.
A workaround would be to use "postUpdate()" to update the value after restart. This isn't implemented yet, but is no big deal. This would be a workaround for the workaround, because we still need the rule. :confused:
In the OH1 binding the request is answered with the state of the item, as I would like to to do too.
Line 277: https://github.com/bloft/openhab/blob/master/bundles/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/MySensorsBinding.java -
@gonzalonal Good point! :worried:
If a request (or a message in general) is received there is no "commandReceived" in OH, so you can't trigger a rule based on a message received. So doing it with a rule is not possible.
A workaround would be to use "postUpdate()" to update the value after restart. This isn't implemented yet, but is no big deal. This would be a workaround for the workaround, because we still need the rule. :confused:
In the OH1 binding the request is answered with the state of the item, as I would like to to do too.
Line 277: https://github.com/bloft/openhab/blob/master/bundles/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/MySensorsBinding.javaHi @TimO . Good we got in the same page.
I think this topic needs some more thinking.
I was reading OH wiki and found this about receivedCommand.
Implicit Variables inside the Execution Block Besides the implicitly available variables for items and commands/states (see the script documentation), rules can have additional pre-defined variables, depending on their triggers: * Every rule that has at least one command event trigger, will have the variable receivedCommand available, which can be used inside the execution block. * Every rule that has at least one status change event trigger, will have the variable previousState available, which can be used inside the execution block.https://github.com/openhab/openhab/wiki/Rules
Maybe this is not available anymore, or at least on OH2.
For now, I think it would be a better approach to use postUpdate at systemStart to populate the binding memory. With this, we'll avoid sending commands to the nodes.
Regards!
-
@gonzalonal Good point! :worried:
If a request (or a message in general) is received there is no "commandReceived" in OH, so you can't trigger a rule based on a message received. So doing it with a rule is not possible.
A workaround would be to use "postUpdate()" to update the value after restart. This isn't implemented yet, but is no big deal. This would be a workaround for the workaround, because we still need the rule. :confused:
In the OH1 binding the request is answered with the state of the item, as I would like to to do too.
Line 277: https://github.com/bloft/openhab/blob/master/bundles/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/MySensorsBinding.javaHi again @TimO .
Just an idea.
What do you think about solving this problematic in this way:
We create a group whose members are all those items that later will populate the binding's memory. I have a group named mysqlpersisted where I put all the items whose data will be stored in my SQL DB. So I could use that group. For this example, let's call it "MemoryGroup"
Then, we can create the following rule:
rule "Populate MySensors binding memory" when System started then (maybe add a delay to allow persistance services to load) MemoryGroup?.members.forEach[i | postUpdate(i.name, i.previousState(true)) ]Using this method, memory would get populated everytime OH boots up, with data belonging to the persistance service that we use. And we use postUpdate, so no command is sent to the nodes.
With this I think we solve both problems as data in the binding will be concurrent with the persistance service data.
Let me know what you think about this.
Regards!
-
Hi @gonzalonal !
I was thinking in the same direction and I have played a litte bit with different rules. I had no success in finding a rule that worked. Additionally I don't like the workaround. ;-)
A good solution would be, to trigger a rule, if a request is received, but there too I had no success till now.
I'm still struggling with it ...
-
I'm currently trying to migrate my production environment from OH1 to OH2. I'm now using two serial gateways.
@kolaf : The problem you described occured to me too. In my case I use two serial gateways. I've added a little method that ensures that a connection to more than two serial ports via nrjavaserial is possible. It works within the OH2 binding. Could you test if it works with the RFXCOM binding you are using? A new jar is available on github. OH2 is currently using an old version of nrserialjava that has a bug. I don't know how to switch the version yet.
@tomkxy : I will integrate MQTT in my OH2 Installation soon and will come back to your request after that.
-
-
I'm currently trying to migrate my production environment from OH1 to OH2. I'm now using two serial gateways.
@kolaf : The problem you described occured to me too. In my case I use two serial gateways. I've added a little method that ensures that a connection to more than two serial ports via nrjavaserial is possible. It works within the OH2 binding. Could you test if it works with the RFXCOM binding you are using? A new jar is available on github. OH2 is currently using an old version of nrserialjava that has a bug. I don't know how to switch the version yet.
@tomkxy : I will integrate MQTT in my OH2 Installation soon and will come back to your request after that.
-
The weird thing is that it seems to work with an older version of OH2 (and an old version of your binding), but not with the more recent beta releases.
-
@kolaf : My guess is, the implementation in the could be the problem. Please do a litte test: remove the mysensors.jar file from the addons folder. Start OH2. RFXCOM should start fine now. Copy the mysensors.jar in the addons folder. OH2 will try to load the binding. What is the result?
I suppose this way both binding work fine together?!
-
@kolaf : My guess is, the implementation in the could be the problem. Please do a litte test: remove the mysensors.jar file from the addons folder. Start OH2. RFXCOM should start fine now. Copy the mysensors.jar in the addons folder. OH2 will try to load the binding. What is the result?
I suppose this way both binding work fine together?!
@TimO I tried this before, and removing the MySensors binding made the rfxcom binding work. However, this was not the case this time. I will try a bit later to also remove the zwave binding.
20:56:34.098 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from UNINITIALIZED to INITIALIZING 20:56:34.115 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0' 20:56:34.115 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from INITIALIZING to ONLINE RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0 20:56:34.361 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized 20:56:34.384 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller 20:56:34.385 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false. 20:56:34.419 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from ONLINE to INITIALIZING 20:56:34.444 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD2BB4D801400' has been updated. 20:56:34.578 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD21C16201400' has been updated. 20:56:34.756 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD2BB4FE01400' has been updated. 20:56:34.852 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app 20:56:34.866 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'hue:bridge:0017881c7280' has been updated. 20:56:34.869 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app 20:56:34.998 [INFO ] [.openhab.core.internal.CoreActivator] - openHAB runtime has been started (v2.0.0, build 201602200203). 20:56:35.015 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'demo.sitemap' 20:56:35.444 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mysensors.things' 20:56:35.491 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'mysensors:bridge-ser:gateway' has been added. 20:56:35.500 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from UNINITIALIZED to INITIALIZING RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyACM0: File exists. It is mine �a�� testRead() Lock file failed RXTX Warning: Removing stale lock file. /var/lock/LCK..mysensorsUSB 20:56:37.420 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message. 20:56:37.426 [ERROR] [WaveSerialHandler$ZWaveReceiveThread] - Protocol error (CAN), resending 20:56:37.427 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message. 20:56:37.429 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message. 20:56:38.773 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from INITIALIZING to ONLINE 20:56:38.774 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'rfxcom.things' 20:56:38.780 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'rfxcom:bridge:rfxtrx' has been added. 20:56:38.790 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from UNINITIALIZED to INITIALIZING 20:56:38.792 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from INITIALIZING to OFFLINE RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine �`�� testRead() Lock file failed 20:56:38.805 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: null -
@TimO I tried this before, and removing the MySensors binding made the rfxcom binding work. However, this was not the case this time. I will try a bit later to also remove the zwave binding.
20:56:34.098 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from UNINITIALIZED to INITIALIZING 20:56:34.115 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0' 20:56:34.115 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from INITIALIZING to ONLINE RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0 20:56:34.361 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized 20:56:34.384 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller 20:56:34.385 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false. 20:56:34.419 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:43b9314d' changed from ONLINE to INITIALIZING 20:56:34.444 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD2BB4D801400' has been updated. 20:56:34.578 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD21C16201400' has been updated. 20:56:34.756 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'sonos:zoneplayer:RINCON_5CAAFD2BB4FE01400' has been updated. 20:56:34.852 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app 20:56:34.866 [INFO ] [smarthome.event.InboxUpdatedEvent ] - Discovery Result with UID 'hue:bridge:0017881c7280' has been updated. 20:56:34.869 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app 20:56:34.998 [INFO ] [.openhab.core.internal.CoreActivator] - openHAB runtime has been started (v2.0.0, build 201602200203). 20:56:35.015 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'demo.sitemap' 20:56:35.444 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mysensors.things' 20:56:35.491 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'mysensors:bridge-ser:gateway' has been added. 20:56:35.500 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from UNINITIALIZED to INITIALIZING RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyACM0: File exists. It is mine �a�� testRead() Lock file failed RXTX Warning: Removing stale lock file. /var/lock/LCK..mysensorsUSB 20:56:37.420 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message. 20:56:37.426 [ERROR] [WaveSerialHandler$ZWaveReceiveThread] - Protocol error (CAN), resending 20:56:37.427 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message. 20:56:37.429 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 37: Not initialized yet, ignoring message. 20:56:38.773 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from INITIALIZING to ONLINE 20:56:38.774 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'rfxcom.things' 20:56:38.780 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'rfxcom:bridge:rfxtrx' has been added. 20:56:38.790 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from UNINITIALIZED to INITIALIZING 20:56:38.792 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from INITIALIZING to OFFLINE RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine �`�� testRead() Lock file failed 20:56:38.805 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: nullIt appears that I get these errors even if I remove all the offending bindings. I think I need to start with a completely clean installation and see how it goes. I will let you know.
-
Success, I think.
I started a brand-new installation of the latest OH2 snapshot, and sequentially added the rfxcom, z-wave, and mysensors bindings. After fiddling a bit with getting serial ports recognised by OH2 and getting the permissions correct, it seems to work. I still get some weird error messages, but apparently the library is able to work through its issues :-). An example of what I mean is included.
08:30:03.894 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'mysensors:bridge-ser:334037be' has been added. 08:30:03.910 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:334037be' changed from UNINITIALIZED to INITIALIZING RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..rfxtrxUSB: File exists. It is mine @�2� testRead() Lock file failed RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyACM0: File exists. It is mine @�2� testRead() Lock file failed 08:30:04.043 [INFO ] [smarthome.event.ItemAddedEvent ] - Item 'mysensors_bridge_ser_334037be' has been added. 08:30:04.219 [INFO ] [rthome.event.ItemThingLinkAddedEvent] - Link 'mysensors_bridge_ser_334037be-mysensors:bridge-ser:334037be' has been added. 08:30:07.060 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:334037be' changed from INITIALIZING to ONLINE -
Returns out that I am still seeing the problem sometimes. If I change the configuration so that the bindings are reloaded (especially the zwav binding) it fails to reconnect to the serial port. I found someone who had posted an updated serial binding which supposedly solved some related problem (I think), but I'm not sure. It does not appear to have had any effect on the problem.
The modified version is available from one of the last posts here: https://github.com/openhab/openhab2-addons/issues/671
-
I managed to get things working pretty well under Linux, but I have now switched to a Windows-based installation to see how that is.
Currently I have all three bindings working at the same time using three different serial ports. This is finally allowed me to pay attention to what the mysensors binding is doing.
The seems to be some kind of delay through the system for messages coming from the device. This is quite evident from the log included below. Device number three is a power sensor which transmits about once a minute. For some reason things are bunched together. I guess some of these could be Retransmissions, though. The sensor is located 4 m away from the gateway. Number 10 is a temperature sensor in the basement.
For some reason I have had severe problems getting the sensor to talk to the Gateway today. It shouldn't be related to the binding, I know, but I'm loosing my mind trying to keep track of all the different factors here.
2016-04-10 16:56:19.535 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3 2016-04-10 16:56:20.512 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3 2016-04-10 16:56:21.747 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3 2016-04-10 16:56:21.805 [INFO ] [marthome.event.ItemStateChangedEvent] - FirstFloorHallMotionSensor changed from ON to OFF 2016-04-10 16:56:21.805 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_command changed from ON to OFF 2016-04-10 16:56:21.806 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_dimmingLevel changed from 100 to 0 2016-04-10 16:56:21.807 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_contact changed from OPEN to CLOSED 2016-04-10 16:56:24.922 [INFO ] [marthome.event.ItemStateChangedEvent] - FirstFloorHallMotionSensor changed from OFF to ON 2016-04-10 16:56:24.923 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_command changed from OFF to ON 2016-04-10 16:56:24.924 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_dimmingLevel changed from 0 to 100 2016-04-10 16:56:24.926 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_contact changed from CLOSED to OPEN 2016-04-10 16:56:55.048 [INFO ] [marthome.event.ItemStateChangedEvent] - CurrentDate changed from 2016-04-10T16:55:55.046+0200 to 2016-04-10T16:56:55.045+0200 2016-04-10 16:56:55.049 [INFO ] [ome.event.GroupItemStateChangedEvent] - ntp_ntp_local changed from 2016-04-10T16:55:55.046+0200 to 2016-04-10T16:56:55.045+0200 through ntp_ntp_local_dateTime 2016-04-10 16:56:55.049 [INFO ] [marthome.event.ItemStateChangedEvent] - ntp_ntp_local_dateTime changed from 2016-04-10T16:55:55.046+0200 to 2016-04-10T16:56:55.045+0200 2016-04-10 16:57:08.332 [INFO ] [marthome.event.ItemStateChangedEvent] - FirstFloorHallMotionSensor changed from ON to OFF 2016-04-10 16:57:08.333 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_command changed from ON to OFF 2016-04-10 16:57:08.334 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_dimmingLevel changed from 100 to 0 2016-04-10 16:57:08.334 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15669958_10_contact changed from OPEN to CLOSED 2016-04-10 16:57:13.444 [INFO ] [marthome.event.ItemStateChangedEvent] - MainHallMotionSensor changed from OFF to ON 2016-04-10 16:57:13.445 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15663466_10_command changed from OFF to ON 2016-04-10 16:57:13.450 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15663466_10_dimmingLevel changed from 0 to 100 2016-04-10 16:57:13.451 [INFO ] [marthome.event.ItemStateChangedEvent] - rfxcom_lighting2_A1WJD2HB_15663466_10_contact changed from CLOSED to OPEN 2016-04-10 16:57:23.053 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 10;1;1;0;0;6.3 2016-04-10 16:57:24.511 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;17;9223 2016-04-10 16:57:24.513 [INFO ] [marthome.event.ItemStateChangedEvent] - CurrentTotalPower changed from 6559 to 9223 2016-04-10 16:57:24.519 [INFO ] [marthome.event.ItemStateChangedEvent] - AverageTotalPower changed from 6559 to 9223 2016-04-10 16:57:24.798 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;17;9223 2016-04-10 16:57:25.616 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;24;4597 2016-04-10 16:57:27.075 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;24;4597 2016-04-10 16:57:29.766 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;24;4597 2016-04-10 16:57:31.128 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 3;1;1;0;18;4.6050 -
@kolaf : I'm glad the bindings are now working together.
The delay in the transmission is a bit strange. I've no idea where that could come from.
I've ported my production environment to OH2 and this didn't occure to me yet. I've upgraded a lot of my sensors to 2.0-beta and therefore took a closer look at the debug output of the OH2 binding to check if the devices present themself correctly and send the messages. I'll will keep an eye on it!Currently I'm running OH2 with:
- Astro1
- Weather1
- MySensors2
- MySQL Persistence
- Sonos2
In the MySensors network I have a couple of Sensebender Micros, a shutter control with 12 SSR and two nodes to control LED lights plus selfmade DHT22 nodes connected to two gateways (one serial, one ethernet (iboard)).
I'm glad it runs stable for days now, although it is obvious in some places that this is a beta release of OH2. There are icons missing and there are bugs in the basicui and the documentation could be much better.