openHAB 2.2 binding
-
@LastSamurai Thank you for your kind words and I'm very glad if you could help here. The RGBW implementation is the most advanced and I've no RGBW sensor myself to test it.
I've commented your issue reports!
@TimO Thank you! You already solved one of my problems. I'll try to also look into the dimming problem although I first need to understand the openhab structure.
I just added another issue in github as sometimes my nodes don't seem to update.
Also I really want to be able to only activate the white part of the node when needed (as mixed white just looks bad, afterall thats why you use RGBW leds). I can change the level of the white leds via my openhab android app but I have found no way to set the leds to 00 00 00 FF. The RGB part always stays on. Should I add another gitHub issue for this or is there just some other kind of control I need to use?
-
@philro and @syren : to get this straight: The sanity check is enabled but it won't send messages to the gateway after the connection is lost? The monitoring of the connection in the binding is very top-level, so it may happen, that a connection is lost and there is no information about that. But the sanity check needs to fail in that case and should try a reconnect.
What are your exact parameters for the bridge/gateway?@TimO Sorry for the delay
the Problem is that the sanity-check didn't recognize if the Gateway is offline.
My Settings are quite standard. I took a screenshot of my Settings and from the openhab Things page. At the Moment where the screenshot was taken, the Gateway are powered off till 24 hours.
So, no Sensor or Gateway could be online
After i powered the Gateway on again, nothing happens in openHAB. I need to restart openHAB and all starts working again.
Greets Phil
-
I have the same problem as @philro describe. I run a new topic here https://forum.mysensors.org/topic/7346/openhab-don-t-want-to-reconnect-after-gateway-restart . When I disconnect and than connect again or restart gateway everything seems to be Online but I can't take no action with actuators and don't receive any information from nodes. Also in log of OpenHab and gateway debug I can't see any "sanity check" behavior.
-
There are some new issues, OpenHab disconnect form gateway by it self, and did not reconnect. It was in the middle of the night when only temperature sensors sending data sometimes when temperature change.. After I restart openhab2 service all starts to work normal..
-
Ok, I've found that sanity check starting when you configure your thing through .thing file not from PaperUI. The sanity checker runs but when I disconnect and connect gateway sanity check send message to gateway and return that gateway isn't connected and start counting retries to disconnecting. That repeats until I restart OpenHab..
-
Ok, I've found that sanity check starting when you configure your thing through .thing file not from PaperUI. The sanity checker runs but when I disconnect and connect gateway sanity check send message to gateway and return that gateway isn't connected and start counting retries to disconnecting. That repeats until I restart OpenHab..
@nofox It's definatly not working the way it should work. It also should not make any difference if the configuration comes from PaperUI or from a .thing file. It is not possible to differentiate between those configuration modes within the binding.
My gateways are using static IPs, so I need to find a way to reproduce this behaviour. :-)
-
@nofox It's definatly not working the way it should work. It also should not make any difference if the configuration comes from PaperUI or from a .thing file. It is not possible to differentiate between those configuration modes within the binding.
My gateways are using static IPs, so I need to find a way to reproduce this behaviour. :-)
-
@nofox It's definatly not working the way it should work. It also should not make any difference if the configuration comes from PaperUI or from a .thing file. It is not possible to differentiate between those configuration modes within the binding.
My gateways are using static IPs, so I need to find a way to reproduce this behaviour. :-)
-
I have added 2 more issues in github. Most importantly there seems to be an issue with ACK right now. So if you have enabled acknowledgment on one of your things and sometimes see no reactions from your leds (or whatever you are using) try disabling ACK. I helped in my case.
-
Hello,
Not sure if it is related to the above mentioned ACK issue... I have some distanced actuators, and was heavily relying on the repeated message send if no ACK. I habe the impression with this upgrade, it does not work as before. Can it be the case? -
Hello,
Not sure if it is related to the above mentioned ACK issue... I have some distanced actuators, and was heavily relying on the repeated message send if no ACK. I habe the impression with this upgrade, it does not work as before. Can it be the case?@krejcarek I haven't heard anything from @TimO recently but have you tried it without ACK enabled? In my case the rate of success increased visibly. There are still some cases where the message doesn't get send successfully though, so I am still waiting for the working ACK feature ;)
-
@krejcarek I haven't heard anything from @TimO recently but have you tried it without ACK enabled? In my case the rate of success increased visibly. There are still some cases where the message doesn't get send successfully though, so I am still waiting for the working ACK feature ;)
@LastSamurai I haven't found the time to look at the issues lately, I'm sorry. :-/
I'm on vacation for the next 10 days and will continue my work after after that. :) -
Hi TimO, I am interested in Mqtt version of binding as I like the flexibility of my system with Mqtt. I see that Sean has already a PR open for this quite some time and I do not see any reason why his changes would break things. Any idea when can we expect this to be merged. Also I have just started getting involved in things and although don't have much time but will try to contribute around this area.
-
Hi TimO, I am interested in Mqtt version of binding as I like the flexibility of my system with Mqtt. I see that Sean has already a PR open for this quite some time and I do not see any reason why his changes would break things. Any idea when can we expect this to be merged. Also I have just started getting involved in things and although don't have much time but will try to contribute around this area.
Hi @gahlawathome !
The code for the MQTT support is only working within the development environment. If I try to compile a jar, there is a dependency problem which I was not yet able to solve. There is MQTT support in ESH and in OpenHAB. The MQTT binding needs the one from Openhab because it is still based on Openhab 1. The MQTT support in the binding needs to be based on ESH, but you can't fulfill both dependencies because only one library at a time is allowed.
I need to check if there has been some development on a MQTT 2.x binding, that would solve the problem.
-
Hi @gahlawathome !
The code for the MQTT support is only working within the development environment. If I try to compile a jar, there is a dependency problem which I was not yet able to solve. There is MQTT support in ESH and in OpenHAB. The MQTT binding needs the one from Openhab because it is still based on Openhab 1. The MQTT support in the binding needs to be based on ESH, but you can't fulfill both dependencies because only one library at a time is allowed.
I need to check if there has been some development on a MQTT 2.x binding, that would solve the problem.
@TimO Thank you very much for a very clear explanation. I will also search around MQTT 2.x on OpenHAB and post here if I find something relevant.
-
@TimO Hope you had a nice vacation!
Is there already some new version of the binding to test?I was on vacation too lately and when I powered my openhab system back on I got lots of problems with my gateway and sensor connections. First I got a never ending circle of failing startup checks (although I could already switch lights). After I disabled the check it seemed to work. But when restarting a sensor node (that did not send any values after the controller restart) I got this error:
16:55:54.552 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;159004 Skipping security for command 3 type 16 16:55:54.604 [DEBUG] [rsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;159011 TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=16,pt=0,l=0,sg=0,ft=0,st=OK: 16:55:54.747 [WARN ] [rsAbstractConnection$MySensorsReader] - Exception on reading from connection java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:288)[:1.8.0_144] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)[:1.8.0_144] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)[:1.8.0_144] at java.io.InputStreamReader.read(InputStreamReader.java:184)[:1.8.0_144] at java.io.BufferedReader.fill(BufferedReader.java:161)[:1.8.0_144] at java.io.BufferedReader.readLine(BufferedReader.java:324)[:1.8.0_144] at java.io.BufferedReader.readLine(BufferedReader.java:389)[:1.8.0_144] at org.openhab.binding.mysensors.internal.protocol.MySensorsAbstractConnection$MySensorsReader.run(MySensorsAbstractConnection.java:335)[205:org.openhab.binding.mysensors:2.2.0.201707241115] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_144] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144] at java.lang.Thread.run(Thread.java:748)[:1.8.0_144]Any idea why or how to fix this? Everything was working fine before
PS I also just got another error while switching a light (the light still worked though):
17:08:31.549 [WARN ] [rsAbstractConnection$MySensorsReader] - Exception on reading from connection java.text.ParseException: class java.text.ParseException : Message length is not > 4 at org.openhab.binding.mysensors.internal.protocol.message.MySensorsMessage.parse(MySensorsMessage.java:337)[205:org.openhab.binding.mysensors:2.2.0.201707241115] at org.openhab.binding.mysensors.internal.protocol.MySensorsAbstractConnection$MySensorsReader.run(MySensorsAbstractConnection.java:345)[205:org.openhab.binding.mysensors:2.2.0.201707241115] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_144] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144] at java.lang.Thread.run(Thread.java:748)[:1.8.0_144] 17:08:31.678 [WARN ] [rsAbstractConnection$MySensorsReader] - Exception on reading from connection java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:288)[:1.8.0_144] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)[:1.8.0_144] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)[:1.8.0_144] at java.io.InputStreamReader.read(InputStreamReader.java:184)[:1.8.0_144] at java.io.BufferedReader.fill(BufferedReader.java:161)[:1.8.0_144] at java.io.BufferedReader.readLine(BufferedReader.java:324)[:1.8.0_144] at java.io.BufferedReader.readLine(BufferedReader.java:389)[:1.8.0_144] at org.openhab.binding.mysensors.internal.protocol.MySensorsAbstractConnection$MySensorsReader.run(MySensorsAbstractConnection.java:335)[205:org.openhab.binding.mysensors:2.2.0.201707241115] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_144] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144] at java.lang.Thread.run(Thread.java:748)[:1.8.0_144] -
Ok I reflashed the gateway and it's gotten a little better. Still have some errors though.
