Are you using openhab 2.4 or 2.5Mx to this binding ?
After about one hour both my bulbs stops responding to OH commands and I get the same exeption as i written in my previous post.
Olaf
When I see : org.openhab.binding.tuya-2.4.0-SNAPSHOT.jar, I think It work on openhab 2.4 
Something strange. I tried to remove the LSC lights from the paper UI, because they just were not working with the bidning. After restarting the openhab Service, because they were reluctant to be removed, they suddenly became online (?).
Weird stuffā¦
Yes, have seen that. Itās a double check.
I will have to see wether it is feasable to add a kind of āgeneric deviceā with configurable DPS values.
I tried to install the jar-file into the addons folder, but it does not get picked up and installed.
Other addons does work when installed this way, but Iām running openhab 2.3.0 instead of 2.4.0.
Earlier I tried to upgrade my openhab installation, but had to downgrade again because of other addons not working properly with 2.4.0ā¦
Is there a workaround to install this on a 2.3.0 installation?
I havenāt got a 2.3.x installation any more. It might be possible to rebuild it in a 2.3.x development environment, but it would certainly require some changes in the source code.
Thanks for this binding, I have it working with a Tuya Smart Plug. At first it went āOnlineā, but I couldnāt switch the plug on or off, rebooted a couple of times, still nothing. Left it 15 minutes whilst I made a cup of tea, came back and it works!
I do still get a few messages go through unexpectedly though:
2019-10-23 22:00:04.226 [hingStatusInfoChangedEvent] - ātuya:powerplug:f4ea8b1aā changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Connection reset by peer
2019-10-23 22:00:22.357 [hingStatusInfoChangedEvent] - ātuya:powerplug:f4ea8b1aā changed from OFFLINE (COMMUNICATION_ERROR): Connection reset by peer to ONLINE
I canāt see any pattern to them. Itās not like the plug is really going offline, as when it does that it still works with the Tuya app.
As you can see, the binding is still work in progress. Those devices tend to disconnect often. The stability of the binding should certainly improve. It seems that devices only accept one connection at a time, but I havenāt figured out exactly how the Tuya app manages to get precedence. The binding uses heartbeat messages, broadcast listeners and watchdogs to attempt reconnection at regular intervals.
Wim, youāve done a brilliant bit of work here anyway. Iāve tried to look for a pattern in the disconnections, but canāt see one, it looks random (though I know it isnāt). At moment I canāt get a connection at all with Openhab, even with the phone the Tuya app is on switched off, and everything rebooted.
Connected 3 color LEDs, 1 normal LED and a power plug. As soon as I blocked their ip adress UDP and TCP in my router to the internet, things start to be stable. But long term testing is needed.
Hi, as this topic is very interesting Iām trying to add an Action LSC Filament Led Bulp.
The challenge Iām obviously facing is finding the localKey value for this specific bulp. I followed the route using the Burp Suite (on Mac OSX). While intercepting the traffic from my iPhone I can see the deviceId (as well as a number of other values like clientId) but I donāt see the localKey value listed?
Can anyone of you geniuses point me in the direction how to figure out the localKey value of this specific bulb?
Any assistance would be greatly appreciated
Thnx,
E
I have copy/pasted the data that is seen with Burp Studio to a text editor, and just let it look for the text ālocalkeyā
If its not there check an other package and look for it.
Make sure you look at the response message. It should contain a reasonable amound of data.
Aaahhh, thanks Olaf, I was to impatience. At the time of posting my question I only had POSTs in Burp without a RESPONSE tab. Looking again after your response I also had a RESPONSE and found two localKey entries. One in the top section and another in the lower parts of the file. Both have a different Key value.
Using the first value (after restarting the OH Service) brings the Item online. In PaperUI the bulb is listed in the Control Tab. Switching the Bulb on in PaperUI triggers an event in the OH Log changing the Bulb from OFF to ON. However the physical Bulb remains OFF. Switching the Bulb off in PaperUI triggers an event changing the Bulb from ON to OFF . . .
2019-11-02 14:52:17.839 [ome.event.ItemCommandEvent] - Item 'TuyaSmartFilamentLEDLamp01_SwitchPowerOnOff' received command ON
2019-11-02 14:52:17.844 [nt.ItemStatePredictedEvent] - TuyaSmartFilamentLEDLamp01_SwitchPowerOnOff predicted to become ON
2019-11-02 14:52:17.854 [vent.ItemStateChangedEvent] - TuyaSmartFilamentLEDLamp01_SwitchPowerOnOff changed from OFF to ON
After 5 minutes an error appears in the OH Event log stating:
2019-11-02 15:00:13.215 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.tuya.handler.FilamentLedHandler@f88b0a': null
java.nio.channels.CancelledKeyException: null
at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) ~[?:?]
at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82) ~[?:?]
at org.openhab.binding.tuya.internal.net.TuyaClient.send(TuyaClient.java:12) ~[?:?]
at org.openhab.binding.tuya.internal.net.TuyaClient.send(TuyaClient.java:95) ~[?:?]
at org.openhab.binding.tuya.internal.CommandDispatcher.dispatchCommand(CommandDispatcher.java:74) ~[?:?]
at org.openhab.binding.tuya.handler.AbstractTuyaHandler.handleCommand(AbstractTuyaHandler.java:259) ~[?:?]
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:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at com.sun.proxy.$Proxy130.handleCommand(Unknown Source) [223:org.openhab.binding.tuya:2.4.0.201910281911]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
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:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Iām lost.
Any thoughts?
Needles to say that operating the Bulb from the iPhone App works perfect.
Thnx,
E
It is actually a very interesting observation [w8_17] that blocking the Cloud service IP address is causing the binding to be stable. I havenāt been able to reverse engineer the Tuya app further, but my guess is that the Tuya cloud API is used when available, and that this is causing so many connection errors. If that is the case, I suppose it will be nearly impossible to make the binding as stable as the Tuya app using only the local API.
I donāt have the option in my router to block certain IP-addresses unfortunately, but Iām interested in hearing the result anyway.
I havenāt seen behavior like this Edward. Usually when connecting to the device fails there is an IOException āConnection rest by peerā. I will have a look at the code to at least avoid the CancelledKeyException, but I realize that this will not be a final solution. The stability is the major thing that need to be fixed before this binding is actually useful.
Are there any other messages in the log that may be of interest? Is there a message when you inspect the status in PaperUI next to the status? Have you double checked the device ID and key values? I
Hi @wim.vissers
Maybe a stupid question with a logic answer, but why are you reverse engineering the Tuya App ? Basically there is a Tuya-API available that can be used for making the binding ? Itās easy for me to say, iām not a programmerā¦I really appreciate your work, I canāt do this.
At the moment I run the Tuya-MQTT is I also have some stability Issues with the binding, but when you have this stable I will go over to the binding instead of running the Tuya-MQTT scripts. Bindings is the strength of Openhab, and a lot easier. The Tuya-MQTT is also running local but seems not to suffer from parallel communication with Tuya APP ( Cloud ). At least in my setup.
I have got a Openhab test instance running with 2.5M4, that is running your binding. ( My main system is still on 2.4 Stable ). At first it looked more stable that on 2.4 Both my bulbs stayed online for several days. Only after 1 day I couldnāt control them anymore while the still say there online. But I to test your latest version, so let you know.
Hi @landzaat
No, not a stupid question at all. It would be awesome if you could register from openHAB directly to the Tuya Cloud. I havenāt found a way to do that however. The Tuya API seem to be quite protected. If you know of a usuable API client to the cloud service Iām interested.
The Tuya MQTT was something I also wanted to test. Since it is based on the same software than my binding, I would like to study the differences, But since that implementation apparently also suffers from stability issues Iām afraid some issues will remain with this approach.
I appreciate your efforts to test the binding. I experience the same issues. Sometimes it works fine for days in a row, and suddenly it stops behaving properly even when it reports the item is online. .
you can controlle the wall switch 3 gangs
Hi Wim, thanks for your swift reply and I appreciate your work on this (challenging) Binding.
However, after 3 solid days of trying to get this to work in general I just gave up. The Action LSC Bulbs are just not stable enough to be handled to non tech people So it wasnāt that I threw the towel because of OH, it was because of the fact that I couldnāt get the actual Bulbs to behave in a predictable way. In my case I happily invest a little more in proven technology like Hue.
But who knows . . . maybe I will step in again in the future.
Thanks again for your assistance and keep up the good work.
Thnx,
E