openHAB 2.0 binding

[gonzalonal]

Hello againg.

I have updated my OH2 to latest nightbuild from cloudbees, and also updated to lastest realease of OH2 MyS Binding.

Now, I am facing an issue, that everytime that OH2 starts, it sends out all the items status to its respective node. This is causing, for example, to open my gates, or lowering my rollershutters, even disabling/enabling my alarm system. So I have shutdown OH2 for time being.

Have anyone faced this behavior before?

This is some of the log:

15:41:40.241 [WARN ] [ome.core.thing.internal.ThingManager] - Initializing handler for thing 'mysensors:bridge-ser:gateway' takes more than 5000ms.
15:41:40.272 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.295 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.322 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.335 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.348 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.362 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.375 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.388 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.402 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.545 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Home.items'
15:41:40.671 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.685 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.697 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.710 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.724 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.738 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.755 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.768 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.783 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.806 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;255;3;0;14;Gateway startup complete.
15:41:40.811 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.856 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.871 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.885 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.898 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.914 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.928 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:40.941 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:41.029 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;3;1;0;0;
15:41:41.110 [DEBUG] [g.mysensors.handler.MySensorsHandler] - handleCommand called
15:41:41.288 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;253;1;0;2;
15:41:41.546 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;6;1;0;2;
15:41:41.799 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;252;1;0;24;REFRESH
15:41:42.052 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;254;1;0;2;
15:41:42.307 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;254;1;0;2;
15:41:42.562 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 3;3;1;0;2;
15:41:42.817 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 1;253;1;0;2;
15:41:43.073 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 2;252;1;0;24;REFRESH

I would really appreciate your help.

[TimO]

@gonzalonal I have no idea why this should happen. The binding isn't that smart to do something like that. I've done a complete fresh installation on 21.06. with the nightly build from cloudbees and don't see this issue.

@dakky Do you see disconnection messages in the log? The binding already tries to detect a disconnect and tries to reestablish the connection when an ethernet gateway is used. Currently the time within a reconnect would be successful is very small due to sleep limitations of threads in OH2 bindings.

[gonzalonal]

Thanks @TimO . I will try to make a progressive installation and try to figure out what is causing this behavior.

I'll let you know if I find out.
Have you read my previous message?
Regards

@gonzalonal said:

Thanks @TimO. Now I get it.
What do you think about having two gateways, one with NRF radio and the other one with RFM69 radio?

Will the binding support both gateways simultaneusly with no issues?

Another question..Will you support HearbeatRequest for the development branch?

Thanks, regards.

[TimO]

@gonzalonal : I just downloaded the recent version of the binding again and I don't see this behaviour.

I hope both gateways will work together! This is was the idea. I've not tested it in combination with RFM69 but I don't see a reason why this should not work! :-)

[gonzalonal]

@TimO I have solved my probles using OH2 Beta3 and the last release of the MyS binding.

It seems that the problem is only reproduced with the last release of OH2 from Cloudbees. At least withe the release 372.

Have you tryed it?

[kolaf]

After a full computer crash (overheated CPU, CPU fan stopped working) I'm trying to set everything up on a new computer. Using the latest openhab2 beta 3 I'm having issues with using this binding. Specifically, whenever I add my standard thing configuration I get a buffer overflow in openhab which results in a core dump.

I have downloaded latest binding from the link at github, but that did not affect it. In addition to this binding I am using the zwave binding and rfxcom binding. All three connect to devices through serial ports, although I I'm not sure if they do it in the same way.

You may recall that I have had trouble using these three bindings together earlier, but for some reason things worked out and it has worked quite reliably since then.

I'm not sure which information from the system crash is useful, but if there is anything I can send you to help you figure out what happens, let me know. Also, I realise that this problem might not be related directly with mysensors, but maybe with the serial library used (I saw a reference to NVJavaSeria in the stack trace after the crash.

[kolaf]

Hello again.

As a temporary fix I found a simple TCP/serial Gateway Python snippet that handles the connection to the serial mysensors device and provides a TCP interface to openhab. Switching the binding of aggression from serial to socket and having it connected to this software gateway removes the core dump issue. This confirms my suspicions that the issues are with the serial port library.

It works okay as a workaround until someone figure something out :-)

If anyone else is having issues with the serial connection, this is the by then snippet I found and used:

https://github.com/pyserial/pyserial/blob/master/examples/tcp_serial_redirect.py

[TimO]

@kolaf I'm only using one serial gw and that is running rock stable within OH2. My last update was 22 days ago, so maybe it is time for an update again. :-)

I recently changed my job, so I'm a little low in time at the moment. :-(

[Fredrik Jönsson]

From what i can see this binding is not part of the official bindings for openHAB. Are there any plans to try to get this as a official binding for openhab?

/Fredrik

[TimO]

@Fredrik-Jönsson : Yes, this is on my to do list with high priority. I've done some preparations but need to contact the OH2 developers before creating a PR.

[TimO]

@gonzalonal :

I've found the time to sync my repository with upstream master OH2. Now I do see the behaviour you described above. The status of every item is send out at startup.

Using the current package of the MySensors binding from today with an older version of OH2 does work fine. But my development environment now throws out the status of all things.

Are you using any other bindings? Are they working fine?At first I need to find out if this problem only occures with the MySensors binding or if there is a bug. ;-)

[gonzalonal]

Hi @TimO.
I am using several bindings in my OH2 setup.
As I am using MyS and OH2 in a productive and sensible environement I could try out how the other bindings behaved. As soon as I detect the error I had to rollback my setup. So I can't really tell is there is a bug with the latest snapshot of OH2 or if it is something more specific of MyS binding.

I am currently using OH2 Beta 3 with no issues.

[Fredrik Jönsson]

@TimO That sounds great, i will start trying this out. By reading this thread it sounds like it works quite well..

Thanks for all you time you put into this binding.

/Fredrik

[TimO]

@gonzalonal : I've found the reason for this beaviour and fixed the bug.

@andreacioni contributed a PR to the code that includes a channel for the last update of a thing. If you want to know at which time there was a message from a node you may subscribe to the "lastupdate" channel.

Example:

DateTime   lastUpdate01 "Last Update" { channel="mysensors:baro:gateway:baro01:lastupdate" }

Thanks @andreacioni !

[gonzalonal]

Hi @TimO .
I have tried the binding and the issue is fixed as you have said.
I have been looking at the logs, and found the following regarding last update feature:

15:52:11.580 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 1;253;1;0;2;1
15:52:11.583 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.581-0300
15:52:11.585 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.584-0300
15:52:11.590 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.588-0300
15:52:11.594 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.592-0300
15:52:11.598 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.597-0300
15:52:11.602 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.601-0300
15:52:11.606 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.604-0300
15:52:11.609 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.608-0300
15:52:11.613 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.611-0300
15:52:11.618 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.616-0300
15:52:11.624 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.622-0300
15:52:11.628 [DEBUG] [g.mysensors.handler.MySensorsHandler] - Setting last update for node 1 to 2016-08-08T15:52:11.626-0300

Is this the expected behavior? It seems to me that we should have only one "Setting last.." for value updated.
Maybe is my setup. Can someone check this.
Thanks!

[andreacioni]

Hi @gonzalonal

The implementation of the binding create a thing for every channel of a single node. So the solution result is what you can see in the log. We can do a little bit more to prevent a single message to fire every 'lastupdate' channel of every thing that have the same node ID. But I think it is not a good idea.

[gonzalonal]

Got it!
Thanks for your quick reply @andreacioni

[Gustafsson]

Hi guys,

I've tried to add my ethernet gateway to openhab2 through but I just cant get the Online-status on, it. Do I have to do anything else than just adding it into the things file?

[andreacioni]

Hi @Gustafsson,

Have you read the readme? Readme . Probably you have not configured things? See the readme on how to do that :)

[Gustafsson]

@andreacioni That's exactly what I did.

Things

Bridge mysensors:bridge-eth:gateway [ ipAddress="192.168.254.228", tcpPort=5003, sendDelay=200 ]
        door    frontDoor       [ nodeId="102", childId="4" ]
}

Items

Text    frontDoor       "Door"  { channel="mysensors:door:gateway:frontDoor:tripped" }

Sitemap

sitemap MySitemap label="Main Menu" {
        Frame {
                Text item=frontDoor
        }
}

This is how everything looks like now. I get the door item green in habmin but still the red cross on the gateway. The door item dosn't show me if it's open or closed.