Add support for the SM16716 RGB LED controller

[gsimon75]

It is used in the Sunyesmart SYF05/07 (aka. Fcmila) smart bulbs, it controls the RGB LEDs via a synchronous serial protocol.

The code works for me in its current form, but as I'm new to the Tasmota codebase, most probably there is a lot to fix about it :), so I'd appreciate any constructive feedback.

The bulb

SM16716 datasheet

A forum discussion about it

My notes

[Jason2866]

Where is or are this devices available?
I didnt found sources to get it easily or for a decent price

[kueblc]

#2293 #1822 xoseperez/espurna#568 http://fastled.io/docs/3.1/class_s_m16716_controller.html

This would be great to have for a number of bulbs and chipsets. Would love to have an option to set color clock and data pins from generic module, and also to be able to use PWM to control the white LEDs, controlled separately from the RGB in my bulb. I've been trying to work it out but I'm too new to the Tasmota codebase to know what I'm doing yet. Let me know how I can help.

[kueblc]

Where is or are this devices available?
I didnt found sources to get it easily or for a decent price

In the US, Walmart sells a cheap (~$13) Tuya based RGBW bulb branded under Geeni / Merkury Innovations

https://www.walmart.com/ip/Merkury-Innovations-Color-Smart-A21-Light-Bulb-75W-Equivalent-No-Hub-Required/254063201

[gsimon75]

Where is or are this devices available?
I didnt found sources to get it easily or for a decent price

For example from AliExpress, just search for "Fcmila"
Fcmila Smart LED Bulb WiFi

[gsimon75]

...Would love to have an option to set color clock and data pins from generic module

That's exactly what I did :).
Added 'SM16716_CLK' and '..._DAT' to the GPIO Pin config choices, so we can select them for any GPIO pin.

... and also to be able to use PWM to control the white LEDs, controlled separately from the RGB in my bulb.

That seems to work in my local build. On MQTT 'cmnd/sonoff/dimmer NN' controls the white PWM, while 'cmnd/sonoff/color RRGGBB' controls the RGB leds.

What I failed to achieve is exactly the opposite: To have one unified 'RGBW' color setting, from which the 'RGB' controls the colors and 'W' controls the PWM of the white leds.
I think I saw something similar in 'sonoff/xdrv_04_light.ino': In addition to PWM it can call through to the WS2812 module (search for 'Ws2812' in that file, with this letter cases), which is another color management driver.
Though I'm somewhat confused, because it is implemented by adding a new LightType, but it's strongly related to how the color components are parsed and converted, etc., so it looks very hard to extend to SM16716 with being backwards compatible.

In fact, this is why I kept it as separate controls, I'm looking for some advice from someone more experienced with this codebase :).

I've been trying to work it out but I'm too new to the Tasmota codebase to know what I'm doing yet.

That makes us two for this category :D.

Let me know how I can help.

To avoid darting off in a wrong direction I'd wait a few days for the opinions of some veterans, but if noone throws a veto, I think we might start experimenting a bit with my branch.

If you have devices with this controller, it would definitely help a lot to test the code with them, but for that I've got to locate why did the CI build fail and fix it first.

Oh, and my second TODO is to figure out how to re-assemble it in a safe and tidy way, like I've got to find some thermal adhesive to glue back the led panel to the heatsink :).

[ascillato2]

Your code don't compile. Please, check travis log for debug.

[ascillato2]

Code don't compile. Check travis log please. Thanks

[gsimon75]

Your code don't compile. Please, check travis log for debug.

I'm on it :).
Actually I've hopefully fixed it in my working copy (a definition is missing from the Greek localisation file), but now before commit I do a full clean build to check whether any other is missing.

(Estimated end of build in about 45 mins, next time I'll start it on a stronger VM.)

[andrethomas2]

Please add void parameter to functions which do not have any parameters, e.g. void SM16716_Update() should be void SM16716_Update(void)

Confirm the logic of

else if (SM16716_Parse_RRGGBB(data, data_len)) { // RRGGBB
  }
  else { // rrr,g,bb

Conditional checks such as these

    if (tok)
      return false; // junk at the end

Should be clearly coded in {} so the following would be preferable

    if (tok) {
      return false; // junk at the end
    }

[kueblc]

@gsimon75 Thanks for your work and your detailed write up, your section on compiling Tasmota without an IDE was especially helpful. I think it would be a great addition to the wiki.

[Zebble]

Nice work! Looking forward to trying this. The Feit WiFi bulbs from Costco (Canada) have the SM16726 that is protocol-compatible. Might snag some Merkury bulbs while im at it...

[Jason2866]

Nice tutorial how to build Tasmota without a local IDE. Could you add it to wiki?

[gsimon75]

Nice tutorial how to build Tasmota without a local IDE. Could you add it to wiki?

Done, also added a link in the Tutorials list.

[Zebble]

@gsimon75 In case you haven't seen the thread talking about the tool from @SynAckFin that enables flashing Tuya devices with Tasmota over the air, here it is:

codetheweb/tuyapi#49

Github for the tool:

https://github.com/SynAckFin/TuyOTA

@kueblc also has a tool to speed up the process through MQTT calls to force an upgrade

https://github.com/kueblc/mocktuyacloud

Between these tools and your support for SM16716, the Feit bulbs should work nicely with Tasmota without ever having to crack open the bulb!

[damondins]

Is there a link to the current bin for this? I have some merkury lights i'd like to test on

[Zebble]

Looks like the Feit bulbs work in white mode (warm/cool adjustments also work) but color doesn't. I suspect the SM16726 isn't on the same pins so I'll need to play around. I don't see the CLK and DAT options in the GPIO pulldowns when I select the Generic module. Any chance of adding this? Then I can more easily experiment and add another template definition.

Nevermind. Found the problem. Needed to add "#define USE_SM16716" to compile settings. I see the options, but still can't come up with a combo that works, nor do I seem to understand how to set the color. If the I use the "color" command with something like "color #321938" should that not set the RGB values? Only seems to play with the white/warm white values and output of the color command gives something that only seems to change 2 values:

00:07:45 RSL: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":19,"Color":"3018","HSBColor":"0,0,19","Channel":[18,9],"CT":326}

Am I misunderstanding?

[gsimon75]

@gsimon75 In case you haven't seen the thread talking about the tool from @SynAckFin that enables flashing Tuya devices with Tasmota over the air, here it is:

Nice :) ! I've added a link for his description to the Tutorials list.

@kueblc also has a tool to speed up the process through MQTT calls to force an upgrade

@kueblc : Could you pls add a link to the wiki? It would be very helpful for those who want to upgrade an old Tasmota version to a new one. (The method by SynAckFin works for the original firmware, if I get it right.)

[gsimon75]

Only seems to play with the white/warm white values and output of the color command gives something that only seems to change 2 values:
00:07:45 RSL: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":19,"Color":"3018","HSBColor":"0,0,19","Channel":[18,9],"CT":326}

That status message comes from xdrv_04_light.ino:590, void LightState(uint8_t append).

I'm new to this codebase, but it seems that some sort of color processing is done in xdrv_04_light.ino, in case when the R-G-B components are controlled by separate PWMs or by a WS2812 controller.

I don't know your 'Feit' bulb, but if it has an SM167x6, then xdrv_04_light.ino has nothing to do with the colors, but as the cold- and warm-white uses PWM1 and 2, those still belong to it.

Now I see two possible reasons:

• Somehow the color command is intercepted and it never reaches xdrv_20_sm16716.ino
• It does, but there's still some bug in xdrv_20_sm16716.ino

I'd like to ask you to do some debugging, if you don't mind :).

1. First please try to configure your bulb with the 'Generic' module, and assign only the cold-white (PWM1) pin and the two of the SM16716, and give it a try with this setup.
   My bulb here has only cold-white, so this is the setup I've tested it with. The presence of the warm-white shouldn't matter, but "shouldn't" and "doesn't" may be different :).

If that doesn't work, then

2. Please enable the logging by un-commenting the definition of D_LOG_SM16716

With that we'll see what exactly the driver is sending to the chip ("Update; pwr=%02x, rgb=%02x%02x%02x"), on what pins ("ModuleSelected; clk_pin=%d, dat_pin=%d)"), what command it got ("Command; topic='%s', data_len=%d, data='%s', code=%d"), what argument it tries to parse ("Parse_Color; data='%s', data_len=%d"), etc.

I hope this will narrow down the problem, so we can catch it in a few iterations :).

[Jason2866]

@gsimon75 OTA upgrading is in Tasmota a included feature...
As far as i understand is the method from @kueblc another possibilty to replace the original firmware with Tasmota

[gsimon75]

If the I use the "color" command with something like "color #321938" should that not set the RGB values? Only seems to play with the white/warm white values and output of the color command gives something that only seems to change 2 values:

00:07:45 RSL: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":19,"Color":"3018","HSBColor":"0,0,19","Channel":[18,9],"CT":326}

I suspect that the sm16716 driver doesn't really handle this warm-white-as-color-component coding.

To have some first-hand experience with it I bought a bulb with separate cold and warm whites (Sonoff B1, that's what I found right now), and its HEX10 color codes gave me an idea.

I'll try to define sm16716 pins for it, they won't control any chip of course, but from the logs I'll see what it tries to do and why is it incorrect.

[kueblc]

@kueblc : Could you pls add a link to the wiki? It would be very helpful for those who want to upgrade an old Tasmota version to a new one. (The method by SynAckFin works for the original firmware, if I get it right.)

@gsimon75 OTA upgrading is in Tasmota a included feature...
As far as i understand is the method from @kueblc another possibilty to replace the original firmware with Tasmota

@Jason2866 is correct, the MockTuyaCloud framework includes an example script that flashes any firmware over the stock firmware on Tuya devices using the vendor OTA upgrade system.

[gsimon75]

Only seems to play with the white/warm white values and output of the color command gives something that only seems to change 2 values

This is going to take some time to solve in a nice way.

Digging into xdrv_04_light.ino (especially at LightCommand()) now I see why it doesn't work with your Feit device and why it worked with my Fcmila.

If the bulb is capable of more than a simple white (that is, light_subtype > LST_SINGLE), then xdrv_04_light.ino takes on the command, handles it the best way it can, and returns true, signalling that the request has been serviced and no need to call further modules. That's why the SM16716 module hasn't even received the color commands on your Feit bulb. If you define only the PWM1 pin and the two SM16716 pins, then light_subtype will be LST_SINGLE (incorrectly, btw, but now it's good for us), and it shall work. But only by coincidence, because it's still a bug!

On my Fcmila exactly this was the case (one white only, plus the SM16716), that's why it worked.

And that's why I had to parse the color command myself in the SM16716 module, now I see.

So first of all I have to extend the light_type setting algorithm in sonoff.ino, so if there are SM16716 pins defined, then add the RGB capabilities, so light_type will be LST_RGBW or LST_RGBWC.

Then I have to add some code to xdrv_04_light.ino so that when it tries to set some RGB value and the SM16716 is present, then call the SM16716-specific functions to set the color.

The function 'LightCommand()' is 315 lines long, with quite a complex business logic in it, and I need to find the right place to add that rgb-setting call. Now I'm at LightAnimate(), which is not just for animating the colors, but for simply setting them as well (light_update=1). We'll see :)...

[Jason2866]

Another OTA way to flash Tuya devices with Tasmota
https://github.com/ct-Open-Source/tuya-convert

[gsimon75]

I'm sort of confused, so I'd welcome any advice. Sorry, this will be somewhat long.

Here is what I found, pls correct me if I'm wrong at something:

• To keep all additional features (schemes, color animation, etc.), this specific RGB controller driver must be integrated into xdrv_04_light.ino, and not must not parse and implement the commands by itself.

• The key to the logic of xdrv_04_light.ino is 'light_type' and 'light_subtype', they control what path the execution takes for any command.

• 'LightTypes' is somewhat of mixed purpose: it contains the capabilities of the device (Cold- and Warm-White, RGB), but also the hw implementation (like RGB is implemented via PWMs, or via My92x1, or via WS2812, or now via SM16716). In certain cases 'LightTypes' (more or less) means just the number of PWMs. The enum numbers are also kind of sensitive, as their lower 3 bits have special meaning (LightSubtypes).

• PWMs are just numbered (PWM1..5), but their roles are situation-dependent, like PWM1 may be WarmWhite, but in another situation it may be Red, it depends on light_type.

This Fcmila bulb I have here has only ColdWhite (but that via PWM1), and RGB via the SM16716 controller. The Feit bulb of @Zebble seems to have Cold- and WarmWhite (via PWM1 and 2), and RGB via this SM chip.

If we don't want RGB support, the light_type is LT_PWM1 and LT_PWM2, and respectively light_subtype is LT_SINGLE and LT_COLDWARM, and it all works well via xdrv_04_light.ino, but there is no color support.

To employ all the features of xdrv_04_light.ino, I tried to change LT_PWM1 to LT_RGBW and LT_PWM2 to LT_RGBWC if the SM-specific pins are defined, and then begun the trouble.

Now that I said there is color support, xdrv_04_light.ino caught CMND_COLOR (very correctly), so it didn't reach xdrv_20_sm16716.ino, so my original approach stopped working.

Then I tried (similarly to the my92x1 support) add an sm-specific call to LightAnimate(), because that is the point where the colors are actually updated.

And the RGB support started working. But the PWM support stopped :( !

It seems hardcoded in the logic of xdrv_04_light.ino that if there is a non-trivial RGB support (eg. light_type = LT_RGBW), then there is no PWM controlling.

It seems to be the consequence of that LightTypes mixes capabilities (like 'have warmwhite', 'have coldwhite' and 'have rgb') with implementations of them (like 'rgb is controlled by 3 PWMs' or 'rgb is controlled by WS2812').

As there is no (or at least I didn't recognise any) code path that contains both PWM control and RGB control, I think I'm out of luck with this case.

Certainly I don't want to turn everything inside out after spending only a few days with the code :D, but it seems that my problem would need some separations in xdrv_04_light.ino:

• separating capabilities (can_rgb) from implementations (rgb_via_pwms, rgb_via_etc.)
• separating high-level control (schemes, animation, hsb-to-rgb conversion, wakeup) from low-level control ('set these intensities to the leds, the way your hardware requires')
• separating pwm functions from numbers, so have PWM_WW, PWM_CW, PWM_R, _G, _B instead of _0.._5
• separating color components (r, g, b) from other controllable values (cw, ww) in variables like 'light_color[]'

Well, seeing so many things to change is like thinking that everyone drives the wrong way on the highway: it's more probable that I'm the one going in the wrong direction :D...

So I'd be thankful if someone could give me some advice (or link some example) how, at what point could I integrate a call to my 'sm16716_setrgb(uint8_t, uint8_t, uint8_t)' into xdrv_04_light.ino, with keeping the white controls at PWM1 and PWM2.

[mike2nl]

@Jason2866 @andrethomas
Jason and me we talked some days ago about the RGB light control.
I was busy to think about how to implement more different light animations.
I found 6 wel animations but the prinziple is pattern control which is not possible
for some of these. Only the strobe would be possible.

We thought about the generic light control and then give the driver the chance to work.
Issue is that brightness, limunace and color temperature is for all the same.
A rethink about the system would be a good idea. Like the display main driver
and then the drivers for each type of hardware type.

Where we start to go. I think it's a bigger project and therefore all the needed
points have to be written down.

@arendst
I think you are the master in this and togehter we can bring the RGB light control system a step further.

[Zebble]

@gsimon75: Thanks for digging into the details on this. I briefly went through some of the code as it pertained to RGB and found the same things you did. Sounds like @Jason2866 and @andrethomas did as well. It does appear the RGB code will need to be refactored...

I'll help where I can, just let me know. Happy to donate some bulbs if that will help as well.

[gsimon75]

* The language files are out of sync with current state as new translations have been added.

Resolved, tests are running.

* Change D_SENSOR_SM16716_POWER text to "SM16716 PWR" as many translations are way too long.

I'm on it, need a few hours.

[kueblc]

• Change D_SENSOR_SM16716_POWER text to "SM16716 PWR" as many translations are way too long.

@gsimon75 Don't waste time doing this manually, I can make that change via script

[gsimon75]

Thanks everyone for all the help and contributions :) !

[kueblc]

Thrilled to help make this happen :)

[elzershark]

SYF05 Modul

if rgbww = #ffffff...
how can I achieve that in channel 4 a 100 is written. in the script. automatically..
if rgbww = #ffffff then... (color x,x,x,100)

[gsimon75]

how can I achieve that in channel 4 a 100 is written. in the script. automatically..
if rgbww = #ffffff then... (color x,x,x,100)

The code of Tasmota only executes commands that are sent to it.
So if it receives an MQTT command like cmnd/wled/color ffffff, then it will set its channels 0..2 all to 100.
To set Channel 4, either that channel must set explicitely by the command cmnd/wled/channel4 100,
or such a color command must be sent that contains information for channel 4, like cmnd/wled/color 000000ff.

Such commands are sent by your home automation assistant software, that is (according to the video), by ioBroker.

Maybe if you set that wled.Color to #000000ff (8 digits, not just 6), perhaps it is sent to Tasmota in this form, or you may try to set wled.WW to 100, but that is also just a guess according to the ioBroker-sonoff module sources.

I'd like to emphasize that this is already deep in the ioBroker part of your setup, and I'm not familiar with it in any way.

But all this is still just curing the symptoms, because the real cause of your problem is that why is your setup trying to set the lights to white by setting 250 to that object test1 (that your're showing at 1:48 in your video)? It should just set 100 to wled.Channel4, or 000000ff to wled.Color, because that is what you need.

I've tried to find this value '250' in the ioBroker-sonoff and ioBroker-iot (the Alexa-interface of ioBroker), but found nothing, so it must be somewhere in your configuration.

All I could suggest is to take a look at 'Skripte/Alexa2 Adapter', and try to find the point where it assigns that '250' to that 'test1' object, and instead of that, set wled.Channel4, just as you did in the 'Dummy2' script.

That's how far I could trace this in ioBroker, so I'm afraid I can't do anything more in this case. Perhaps you should ask the ioBroker developers, they are more familiar with that part, so maybe they have some more helpful ideas.

[elzershark]

hi, but it has nothing to do with iobroker. If the tasmota device is placed on a simulated hue lamp, that will not be set for rgbw or rgbww bulbs. Because only the command #ffffff is sent instead of #ffffff and channal 4. if you could get that channel4, then the simulated hue would work. I know how the lamp works with iobroker and alexa.

[elzershark]

mqtt not on. but hue
http://89.163.196.39/sonoff/Clipboard1.jpg
this is the Modul
http://89.163.196.39/sonoff/Clipboard2.jpg
this send/ gets tasmota when i say "make warm white" she send FFFFFF00..
http://89.163.196.39/sonoff/Clipboard3.jpg
this is for rgb. not for rgbw ore rgbww
can one write that in the tasmota script not so, as soon as FFFFFF00 comes, which stands also in the channel4 100?
if that would work, white, dimming and all colors would go.
this is how only all colors and dimming work.

[gsimon75]

Because only the command #ffffff is sent instead of #ffffff and channal 4.

Exactly, that is the problem. Only '#ffffff' (3 'ff'-s) is sent, and not '#ffffffff' (4 'ff'-s).

But '#ffffff' is not the same as '#000000ff', nor as '#ffffffff', because 3 'ff'-s means that the rgb leds must be at 100% but the white ones must be off, the '000000ff' means that the rgb leds must be off and the white leds fully on, and 4 'ff'-s mean that every led must be fully on.

These are different situations, so on the Tasmota side we cannot just substitute 'ffffff' with 'ffffffff'.
(Think about the use case when someone is just gradually moving from yellow 'ffff00' towards rgb-white 'ffffff': until 'fffffe' just the rgb leds are used, everything is nice and smooth, then it reaches the rgb-white 'ffffff'. If there were such a substitution that you suggest, then at this point suddenly the white leds would turn on to 100%, turning the smooth transition into a harsh full-intensity floodlight.)

So the best would be to solve it on the sender side: if 4 'ff'-s are needed, then 4 'ff'-s should be sent.

If the tasmota device is placed on a simulated hue lamp

I don't know about this 'simulated' lamp concept, but as far as I know, there is no such thing on the Tasmota side, neither is any scripting. This code runs on the bulb itself, so it tries to be minimalistic, it only receives the commands and sets the led intensities.

Any scripting (like that example 'Dummy2' that you showed) is done on the ioBroker side.

hue lamp

Now, this reminds me of a limitation, but that is the limitation of the HSB color space concept, so it's unlikely that we can do anything about it.

If you set the color by its hue+saturation+brightness components (cmnd/wled/hsb hue, sat, bri), then it controls only the rgb leds, and not the white ones. source code

Theoretically it would be possible to use the white leds, but then we needed to know how much brighter is the 'cold-white' than the 'rgb-white', which is different from one model to another, and we don't know it.
(And when the 'warm-white' enters the picture with the rgbwc bulbs, the equations start getting really ugly.)

So, if this 'simulated hue lamp' of yours is actually sending HSB colors (and not RGBW ones), then unfortunately the answer is no: At this point there is no way to control the white leds via HSB colors, and a lot of concept-level thinking is needed even to considering how it could be done.

[elzershark]

ah, ok.. :(

[qingz2004]

How to set up the Walmart Merkury Innovations bulb? It uses TYLC2V and SM726EB.

[kueblc]

Set module to SYF05 and then set GPIO13 to SM16716 PWR

[qingz2004]

@kueblc Works great! Thanks!

[jtroberts1]

I've noticed that the pre-compiled versions haven't been updated since December. So I assume to use the enhancements discussed here I need to compile in PlatformIO, is that correct? I just compiled a new bin file based on the development branch. Hope I'm doing this right, I've just never used the DEV branch before. I should be able to test tomorrow. Thanks again.

[andrethomas]

@jtroberts1 pre-compiled development binaries are updated all the time to http://thehackbox.org/tasmota/ so if its something you need from development that was not included in the last release (https://github.com/arendst/Sonoff-Tasmota/releases/tag/v6.4.1) you can download or OTA from the first mentioned link.

[Jason2866]

@gsimon75 Can you test PR #5702 please? Thx!

@elzershark You can test PR #5702 Color control is implemented via HueEmulation (Alexa)
AND driver is refactored (solving rounding issues)