openHAB 2.2 binding
-
@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.
-
Ok I reflashed the gateway and it's gotten a little better. Still have some errors though.
Hi @LastSamurai !
You've debug enabled on the gateway, have you? Looks like the binding does not like the (debug) output from the gateway.
But the binding should recover just fine from the exception, only the (debug) message that has lead to this exception won't be parsed. -
Hi @LastSamurai !
You've debug enabled on the gateway, have you? Looks like the binding does not like the (debug) output from the gateway.
But the binding should recover just fine from the exception, only the (debug) message that has lead to this exception won't be parsed.Wow, you are right of course. Debugging is indeed enabled... but than I can just ignore the errors, thank you.
@TimO said in openHAB 2.2 binding:Hi @LastSamurai !
You've debug enabled on the gateway, have you? Looks like the binding does not like the (debug) output from the gateway.
But the binding should recover just fine from the exception, only the (debug) message that has lead to this exception won't be parsed. -
So I disabled debug output on the gateway to avoid the error messages but I still have problems with my setup. I used to have a motion sensor that worked with openhab. Now when the sensor sends a motion event to the gateway nothing happens in openhab.
Part of the log of the motion sensor:
6236 TSF:MSG:SEND,11-11-0-0,s=1,c=1,t=16,pt=1,l=1,sg=0,ft=0,st=OK:1 6307 MCO:SLP:MS=30000,SMS=0,I1=255,M1=255,I2=255,M2=255 6367 TSF:TDI:TSL 6385 MCO:SLP:WUP=-1 6406 TSF:TRI:TSB 6424 MCO:SLP:MS=86400000,SMS=0,I1=1,M1=1,I2=255,M2=255 6481 TSF:TDI:TSL 6500 MCO:SLP:WUP=1 6520 TSF:TRI:TSB 6541 TSF:MSG:SEND,11-11-0-0,s=1,c=1,t=16,pt=1,l=1,sg=0,ft=0,st=OK:1 6612 MCO:SLP:MS=30000,SMS=0,I1=255,M1=255,I2=255,M2=255 6670 TSF:TDI:TSLSo it seems like the message gets send succesfully but on the openhab log I see no mentioning of that (although I enable debug output for mysensors and I can switch on/off some led nodes). Any ideas why? I really want to get this working again.
-
Sorry for bothering you guys, I figured out the problem: I have installed domoticz on the same raspberry and after a restart I forgot to turn it off. So all the missing data was "hidden" away by domoticz instead of openhab.
-
Sorry for bothering you guys, I figured out the problem: I have installed domoticz on the same raspberry and after a restart I forgot to turn it off. So all the missing data was "hidden" away by domoticz instead of openhab.
@LastSamurai :smile:
I'm glad you've found the problem, I was out of ideas. ;-) -
The problem is that the motion sensor still doesn't show up at the gateway although it gets an answer from it. I disabled domoticz though so I need to find another reason ;( Earlier it showed up in domoticz ... strange. I will try to change the id and see if OH picks it up then.
Btw @TimO Any idea yet when you will be able to work on the github issues I posted?
