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.
Hi Edward. I totally agree. I have Hue and Tradfri operational as well, and Hue is by far the most reliable and stable with openHAB. The LSC devices are very cheap and therefore interesting, but I doubt if the stability issues can be fixed satisfactory.
Anyway thanks for trying out the binding.
@wim.vissers thanks for the work you did for this binding, when i first saw them in the store my first thought was flashing tasmota on them to get rid of there cloud all together. I am running into a problem that the device is online but no commands are being send or data is received by the item. I would love to help debug and make the binding more stable.
@Willemde20 I’m afraid I don’t have may options left to improve the stability of the binding. I will discontinue active development fort hat reason.
I actually flashed Tasmota in a couple of those devices and this works fine. I personally think it is a better solution although it requires a little bit more work to start.
I successfully flashed 2 types of LSC multicolor lamps and one type of LSC filament lamp. The LSC power switch also works, but with Tasmota the manual operation doesn’t work anymore. You can control it fine with MQTT though.
I didn’t succeed in flashing the LSC siren, because the Tuya convert process doesn’t work with this device.
Sorry to hear that the development of the binding is stuck at this moment.
Can you share info about how you flashed the Action LSC bulbs with Tasmota firmware ?
I was looking into to the possibility of that, but for me it was unclear what to use for the filament bulbs. The info I found was for the RGB bulbs, and the plan was to not brick the bulbs with incorrect firmware.
Maybe this is a good alternative for the binding, as MQTT widely supported.
The biggest advances is that when flashed the bulbs won’t suffer from unexpected firmware updates from Tuya.
Flashing new firmware is always a bit risky, but I succesfully flashed 2 color lights and 2 filament lights, following the instructions for Tuya Convert https://github.com/ct-Open-Source/tuya-convert.
I used a dedicated Raspberry PI 3 for it, that worked fine. After flashing the Tasmota firmware you can connect to the WiFi netwrk (the light bulb acts as WiFi AP) and do the setup. What you need is the right template string.
Anyway, the original firmware can be saved as backup, and restored using Tasmota.
I totally agree that this is the better solution. Tuya software seems to be quite protective, and there’s certainly the risk of a software update that makes the binding unuseable.
I am using your binding quite some time now and it seems stable when I load the binding by hand after OH has started. So I can write a script to copy the jar into the addons folder after OH has started.
Very happy still… Thank you for this binding.
Flashing the bulbs is my next move when things do not seem to be stable…
I just tried it out this week. And everything is working just fine.
Do you have a sample Thing configuration file? I prefer to work with config files and not PaperUI.
Where xxxxxn is the device Id (or gw Id), and yyyyn is the local Key. Optionally, you can also specify the IP address with ip=“a.b.c.d”, but I would not recommend that.
@wvissers
Hi
1- Just want to thank you very much.
In fact I flash my LSC filament led with Tasmota.
BUT the SMART LED colored version is now using Realtek RTL8710BN Wi-Fi SOC instead of ESP82xx
So my filamentled were flashed with Tasmota but not my color one…
You saved me !
So thanks a lot !
The price of this lamps are so low instead of other and I think they are good !
In France we buy this lamps in the market named “Action”.
Please propose this binding for a next version of openHAB !
2- After reading all the post you said that the flashing is the best method.
Maybe for the hold versions of Tuya. Not the last.
I did that for many lamps with Tasmota, it was fine. But many others can’t be flashed due to different component.
In Tasmota logs you have :
“this device does not use an ESP82xx and therefore cannot install ESP based firmware”
And Tasmota confirm they will never include this in new versions…
Only your binding works ! So your work is important for the community Please don’t stop it !
3- The last point. I don’t know why in each restart of openHAB it’s necessary to push your jar add-on manually. Is there a way exists not having this trouble ?
After a few days of running smoothly, it stopped working. How can I debug the problem?
I’m not really an openhab expert. So anything you can help me with to restore?
Seems that the Thing is loosing communication with the devices.
Hi
For me a specific binding for tuya is the best way as long as it’s maintained…
You have another way, it’s to use MQTT but the configuration is more difficult !
Have a look there : MQTT for tuya
Best regards
MacLeod
I experienced the same issue with several devices. It seems that the tuya devices refuses connections almost at random. The binding tries to reconnect when it looses connection, but this fails frequently. Sometimes restarting openHAB solves it for some time. But to be honest I found it not reliable enough to continue working with it.
Hi @MacLeod as the binding is not stable enough at this time I won’t propose it for the next version of openHAB.
I agree to your point of course that flashing is not always possible, if the device doesn’t use the ESP82xx family SOC. I’m happy to continue development if I knew a way to increase the stability. If anybody has ideas how to improve it I would like to know.
I’ve seen reactions that people copy the jar every time. That should not be necessary though. I restarted openHAB all the time (I use it in a docker container on an Intel based NAS) without copying the jar again. Sometimes it takes several minutes for the binding to stabilize, but I don’t have to copy it every time after a restart.