Add support for SM2135 as used in Action LSC SmartLed

[arendst]

Extend Tasmota with support for SM2135 five channel intelligent dimmer led with constant current driver interfaced using I2C as used in Action LSC Smart Leds (https://www.action.com/nl-nl/p/lsc-smart-connect-slimme-multicolor-ledlamp-2/)

SM2135E_zh-CN_en-US_translated.pdf

See https://www.mikrocontroller.net/topic/479796#5950544 for background info.

[Jason2866]

Great since there are many Shops in Europe :-)

[arendst]

VERY EXPERIMENTAL as I have many questions using the current documentation.

I currently fail to flash these bulbs so I cannot test it yet.

In order to use it you will need to add define USE_SM2135 to my_user_config.h or your override file.

[TimelessNL]

Great work arendst! I dumped the firmware of the E14 bulb so maybe there is a chance tuya-convert will be compatible soon. I'll test your experimental driver (probably sunday evening) and report my findings.

Have to find a 15v psu first I guess, that's printed on the LED circuit board but I suppose 12v will due as well🤔

EDIT: Any specific information you want me to test? I noticed in the datasheet that RGB cannot be used simultaneously with W/YW?

[ggaljoen]

From what I read in the spes the address starts from 0xC0 1100 0000

define SM2135_ADDR 0x40 Or did I got that wrong?

[ggaljoen]

@TimelessNL the 15V and Vin are different. RGB from 15V and White/warm from Vin. Can you measure that?

[TimelessNL]

mmh interesting... I can try to measure that, but I tried tuya-convert-new-api on my bulb (in parts) and guess what? It works just fine. So do we still need to know the voltage since any bulb can now be ota'ed?

Also flashed my bulb with tasmota-dev and tried the experimental SM2135 support. Unfortunately this does not seem to work quite yet 😢

Results:

• Chip is detected and CW/WW sliders are shown.
• All colors do show but are completely random. (command: color 1 = red, color 2 = green, color 1 = any other random color)

When I set scheme 2 the bulb goes berzerk. It is just flashing random colors together with CW/WW.

UPDATE: this is the i2c connection settings for the GU10 and E14:

[arendst]

Regarding tuya-convert you just did you use python2 or python3?

I think I have to sacrifice my bulb and try to open it up to find if it still uses the esp8266...

[ggaljoen]

@arendst can we flash ota over and over until we got the i2c driver part right? Is commandline i2c an option? else we need to listen the lsc talking to it.

@TimelessNL my next trail and errors will be after this weekend (drukke agenda)

[arendst]

The fact the chip respons to commands means the I2C address is just fine. All that needs to be done is figuring out the color positions in the string and chip timing.

Ota can be done many times but it makes more sense that I try to get it working as that will solve the issue much quicker.

[digiblur]

@arendst not sure if you noticed but I did figure out why 3 different brands of my bulbs didn't work with the new branch of tuya convert. Simply changing the build on my Raspberry Pi from Stretch to Buster fixed it. (Timing issues maybe?) I posted about it in the long thread discussing flashing the bulbs. You might have some luck with yours and not destroy it.

EDIT: Add link - https://github.com/ct-Open-Source/tuya-convert/issues/273#issuecomment-535780741

[arendst]

Thx. I did use Buster on a latest Raspberry Pi but failed. I'll do it over again tomorrow and report.

[TimelessNL]

Regarding tuya-convert you just did you use python2 or python3?

I just installed ubuntu 18.04 on a spare laptop and removed sudo apt-get upgrade -y from install_prereq.sh and ran the script. Some update seem to cause issues to tuya-convert. So I just skipped the upgrade part. This worked fine for me.

Please take note that I use the new-api branch. Only that one works with the GU10 and E14 bulbs.

I think I have to sacrifice my bulb and try to open it up to find if it still uses the esp8266...

You bought the LSC E14 or GU10 bulb right? It would be strange that they manufactured a RTL and ESP version 🤔 because I bought some today and they did contain the ESP like my first sacrificed bulb did.

[ggaljoen]

@TimelessNL do you got an E27 also? Could you triple check that it won't flash, now you got it up and running?

[TimelessNL]

@ggaljoen you disassembled the E27 bulb right? I saw the picture and it shows a Tuya WR3L which according to the datasheet is a RTL8710: User-Manual-4311156.pdf so no ESP8266 unfortunately.

I could have tested it only if they where in stock, all E27 bulbs in my local area are pretty wanted :laughing:. The WL3L can however be replaced with a ESP (pin compatible) because that's what I did with the siren. But I doubt that is worth it since there are better E27s on the market that are better equipped than 6 5050 style RGB LEDs.

[arendst]

Just got two E14 bulbs and will try to update one and continue work on the driver.

[TimelessNL]

Great. Good luck!

[arendst]

Well flashing went easy using kueblc's new-api version.

Now on to the next phase...

[TimelessNL]

How is the next phase going arendst? Did you find anything interesting?

[arendst]

No luck yet. Had no time today as the shutter needed to get merge.

What I found out so far is that the chip responds with all i2c addresses when scanned - not good. Unable to send anything to the chip. Only tested on pre-2.6.0

Next actions will be

• try core 2.4.2 which has different wire driver
• experiment with i2c stretch time and/or clock rate
• open second device, connect logic analyser using opto couplers to sda/clk and monitor tuya i2c traffic

[TimelessNL]

Ah that's unfortunate. I was using 2.5.2 last time but did not actually scan for adresses. But were you able to get any light out of it? Because my bulb actually produced colors in different brightness levels so your sketch seemed to be able to talk to the chip in some manner.

I will try tomorrow evening to see if I can work out some buspirate magic (been a long time though so I may be a bit rusty). Also something that came to mind, I was looking at the ESP sdk repo from tuya which did not contain that much code. But since the E27 RGB contains the RLT chip and the RTL repo contains many more examples we might find something interesting there, but that's just a guess.

[ggaljoen]

Be carefull with connecting something to the bulb; the gnd is on some level connected to your L or N 230V. As Arendst stated, use opto's to uncouple from the mains wires/voltages! Got the Magic black smoke escaped that way... My specs remarkable reading was not to have a device address only mentioned a data address, strange.

[TimelessNL]

Thanks for the warning, I've seen your post earlier. That's why I was planning to power the chip from my bench power supply. That makes it even saver for myself to probe this thing.

[arendst]

Progress!!

After a day of rest and re-applying power to the bulb it now responds to color commands. Still no correct relation but at least I have some kind of communication going.

[TimelessNL]

I was trying some experimental writes to this chip and it seems to me that RGB cannot be used with CW. Also on the last page of the datasheet it somewhat states (in chinglish)

two groups led Light by MCU Alternate control work, can not work simultaneously.

So I suppose this is different than how Tasmota normally handles RGBCW right?

[Keeze]

You're right, Byte 2 selects RGB of WY mode...

[TimelessNL]

Meh that's unfortunate. 😞 I was hoping that byte 2 only selected RGB/YW for that operation and that the other mode stayed on it's last set state.

[TimelessNL]

@arendst small question, where did got the 0x40 for SM2135_ADDRfrom? Because it does not matter what address I use, it always responds with a random color 😕

[arendst]

The 0x40 comes from the datasheet you provided. It documents addresses from 0xC0 to 0xC6. As I2C device addresses are ALWAYS from 0x01 to 0x7F the correct addresses should be 0x40 to 0x46.

When I do a I2CScan I also see response on all addresses. This means the device most probably does not adhere to the correct I2C specs and implementing it will need special consideration.

In my test environment I had to disable all I2C devices except the SM2135. In the meantime I wrote an extra layer on top of I2C device recognition to handle this phenomenon; Once a SM2135 is recognised all other I2C devices will be disabled.

The main task still lies ahead; the bulb responsw is stil inpredictable as different colors appear with same I2C data send.

Regarding the RGB/CW switch I think that's all to do with power management; to make sure onle one of them is active the power supply can be smaller while still selling RGB/CW functionality. In my test driver this is also anticipated where CW is only allowed when RGB are all set to 0.

[Keeze]

When I do a I2CScan I also see response on all addresses. This means the device most probably does not adhere to the correct I2C specs and implementing it will need special consideration.

That's what I also noticed:

[19:17:57][I][i2c:033]: Scanning i2c bus for active devices… [19:17:57][I][i2c:040]: Found i2c device at address 0x08 [19:17:57][I][i2c:040]: Found i2c device at address 0x09 [19:17:57][I][i2c:040]: Found i2c device at address 0x0A [19:17:57][I][i2c:040]: Found i2c device at address 0x0B [19:17:57][I][i2c:040]: Found i2c device at address 0x0C [19:17:57][I][i2c:040]: Found i2c device at address 0x0D [19:17:57][I][i2c:040]: Found i2c device at address 0x0E [19:17:57][I][i2c:040]: Found i2c device at address 0x0F

The main task still lies ahead; the bulb responsw is stil inpredictable as different colors appear with same I2C data send.

Just some considerations from a noob (and I may be talking s***) ;) I saw that you don't use bit 0? And do you always send the whole command (8bytes), including the RBW / WY switch. As I interpret the datasheet, you only have to send the required commands and as long as the module is in RGB mode it stays in RGB mode. You use bit 0 to point to the first register you want to change.

So when using all 8 bytes, you also have to send the bytes of the mode, not used. Also, I don't think you have to set the RGB value to 0 when switching to White mode.

[arendst]

PROGRESS!!

I managed to take control over the bulb albeit NOT using the wire library. It seems the protocol is a bit different from I2C. My local tweaks allow full control over colors and whites. As some already noticed its either colors OR whites but that should be normal practice anyway.

Now on to finding a way to implement seamlessly with the other light protocols...

[arendst]

Released support for SM2135 using the template below:

{"NAME":"LSC RGBCW LED","GPIO":[0,0,0,0,0,0,0,0,181,0,180,0,0],"FLAG":0,"BASE":18}

[TimelessNL]

Great work! I'll probably visit the Action anytime soon to buy some more bulbs :laughing:

[Xenomes]

Great job guy's!! So the LSC RGBW LED bulb's with E14 and GU10 socked are flash-able with the new Tasmota firmware and the E27 need a board swap to a ESP one to do the same (right?).

[TimelessNL]

Yes, not sure about the E27 though, I can't verify that it has the SM2135 on the pictures I have seem of the PCB.

[haubke]

Wich tasmota firmware are you using? Development or do you have a binarie?

[Jason2866]

@haubke http://thehackbox.org/tasmota/pre-2.6/sonoff.bin the official source for Tasmota http://thehackbox.org/tasmota/

[ascillato2]

Closing this issue as it has been added. Thanks.

[TimelessNL]

@arendst I just tested your implementation and it indeed works great! Thanks. One quick observation however. At this moment the I_max for RGB is set to SM2135_20MA but the bulb is rated for 5W. Being the RGB input is 15V * 0.06A the total power draw result in +/-1W. I know that the chip default is SM2135_20MA for RGB and SM2135_30MA for CW.

But the E14 has:

• 4x RGB
• 8x WW
• 8x CW

And the GU10 has

• 5x RGB
• 8x WW
• 8x CW

That means the current though each individual RGB LED is max 5mA and each inididual CW led is max 4mA. Correct me if I'm wrong but aren't the chip defaults a little conservative? Not tested the heat output though.

[arendst]

I configured it conservative indeed. I had an overtemp shutdown with CW set to 20mA. The chip powers off at 85 C.

I had planned to do some measurements comparing the tasmota bulb with a tuya bulb but I couldn't find a second E14 socket in time.

Feel free to experiment and let us know to correct equilibrium between lumen and temperature.

NB. I suggest you read the sm2125 datasheet regarding current calculations.

[EddyDsSmartHome]

Hi, just want to say LSC GU10 is working. Flashing with the new master on a Rapi 3 Buster lite, using the Tasmota 6.6.0.15 as firmware Also working "Etersky EU Socket"

Thanks to all who make it possible.

[oopsitsaflame]

Hi, i managed to get the GU10 flashed with latest Tasmota (and only had one panic attack when my router did not assign a IPv4 but only a v6). After searching in the templates it dawned to me that i still had to add a custom one. (just writing this here for the next one). Is support for the RGB LEDs planned to? (edit: just saw that they work in Home Assistant. I didn't know that. Just was refering to the html-frontend)

[FransTwisk]

I'm a bit confused: I read that the E14 and the GU10 can now work using Tasmota, but is the E27, which specifically mentioned in the start-post now also flashable?

[arendst]

No, the E27 is not supported as it it does not contain an ESP8266.

[FransTwisk]

Thanks for the clarification.

[TimelessNL]

I've added the compatible LSC bulbs to the tuya-convert wiki

I successfully flashed 5x E14's & 4x GU10's with Tasmota 6.6.0.15 (including sm2135 support) and they all worked perfectly.

Except for 1 stubborn GU10 ... I have no clue to why that one does not work, it did have one broken CW LED out of the box so that may have something to do with it. If I use the 'old' driver it behaves exactly the same as any other SM2135. But when I use the newer driver it seems to work for a while (RGB scheme2) then freezes, then continue to work, then stops completely and after several minutes continues normal operation after which the cycle repeats. Very strange... The white colors are a completely different story, they work after initial power-up but then completely ignores future commands, and a long power cycle is needed to restore operation. I don't think it's a driver issue as for now, since 9 other bulbs are working just fine.

I removed the plastic cap (very easy btw, no glue) to see if I could spot any manufacturing defect. But everything seemed normal.

[Jason2866]

Mhh, behaviour could be a power issue. Looks like overheating

[TimelessNL]

Power issue is feasable. But overheating shouldn't be possible since this behaviour starts within seconds after cold boot. Sometimes the bulb doesn't even light and after 2min suddenly comes to life on scheme2. And none of my bulb including this one gets even slightly warm in RGB mode.

Currently I'm enjoying my 9 other working bulbs and have put this bulb back in it's box labeled as 'defective'. Somewhere in the next few weeks I can have another troubleshooting attempt, since I then have a thermal camera in my possession to do some thermal tests.

Maybe this is the only bulb around that has this issue, but if somebody else faces this same issue they now know they are not alone :P

[WaaZaa666]

As I'm new to Tasmota (used to ESPHome...), what is the exact tasmota build you have been using for the LSC GU10's? Got into vtrust-recovery state before, retried flashing with a link found above from Jason2866, but now it's not doing anything anymore... I was expecting to find a Tasmota SSID, correct?

UPDATE

Tinkered a little bit, am able to recover again. Now created a custom bin file with tasmocompiler. I should just need to put in the "#define USE_SM2135" in custom parameters and select development/2.6.x/English/Sonoffs? Compile and upload with the tuya convert?

[Jason2866]

If Tasmota is flashed and there is no visible AP -> It is dead Jim

[WaaZaa666]

As mentioned in the update, was able to access the vtrust-recover, so some flash was not OK before. Luckily tuya-convert has some kind of recovery mode. Anyhow, Is my idea on creating the firmware correct? "Now created a custom bin file with tasmocompiler. I should just need to put in the "#define USE_SM2135" in custom parameters and select development/2.6.x/English/Sonoffs?"