@michaelkamprath - it does look like a full, comprehensive build is taking place. Takes a few minutes and reports back successfully.

Yes would be appreciated if you could have a quick test on M1.

I'll also add that dpkg was failing with some 404s - I resolved this by changing the Dockerfile with --add-architecture arm64

I've succeeded in getting OpenBK7231T_App to build with Docker on an M1 Mac. A new directory dev_20230315_195628 shows up in output, but it's empty.

Found the problem: two identically packaged bulbs, with identical SKUs, markings etc have totally different chipsets and LED arrangements 😡

@openshwprojects if this turns out to be the case, can we have an option to tint all RGB colours with some added whiteness?

Yep, I've seen this. Actually I think your code is correct, as I'm seeing 8 distinct steps for RGB as documented here: https://www.mikrocontroller.net/attachment/430042/SM2135E_zh-CN_en-US_translated.pdf

I think an explanation for why the stock Tuya bulb is still way brighter, is that maybe the original firmware is combining the RGB LEDs with the white ones to produce colours?

Thanks for the quick release! This partially-resolves the problem. The change now affects the light when showing an RGB colour, but it doesn't seem accurate. Setting 0 0 now makes the light quite dim, rather than turning it off completely.

Describe the bug SM2135_Current only seems to affect CW. The command for me has no effect on RGB at all. For example, setting SM2135_Current 0 0, disables LED temperature altogether, but RGB is unaffected. Boosting this value has a noticeable impact on temperature brightness, but RGB remains unchained.

Firmware:

• Version: 1.15.565
• Device: EXTRASTAR E14 Smart Bulb
• Chip/model: BK7231T

To Reproduce

1. Set bulb to a temperature
2. Run SM2135_Current with a combination of values and note how the change is reflected as brightness
3. Set bulb to an RGB colour
4. Run SM2135_Current with a combination of values (including 0 0) and note that nothing at all happens

Additional context Flipping flag 9 on and off has no difference. I suspect this might be something to do with the communication protocol in drv_sm2135

Also, SM2135_Current only seems to affect CW. The command for me has no effect on RGB at all.

Actually, I've noticed that this is because the web ui is not sending the correct colours for red/blue/green (at least on a Mac). Red is sending as #ff2600 and not #ff0000, and when there's any mixing of channels going on, you get weird results. Maybe a hue rotate is probably better for these bulbs than a full rgb colour picker.

Also, the brightness is still way off - I'm guessing we're not sending the right current value to the SM2135. It looks ok-ish at first glance, then you compare to an identical Smart Life-controlled bulb and the brightness is at least double.

So I've noticed when the last 2 digits are 4 3, the temperature and the brightness work correctly.

For the first 3 digits, I've tried all these combinations, but the colours still aren't lining up correctly:

0 1 2 0 2 1 1 2 0 1 0 2 2 0 1 2 1 0

I've also noticed that the brightness of any given colour appears to be around 50% of what the bulb looks like using the Smart Life app.

It looks like DDP has extremely limited support and doesn't do any of the syncing/timing yet - just the basic ability to send a message to a bulb to set it's rgb - unless I'm missing something.

@lmcd isn't it what the DDP protocol with xLights is for? We already support DDP.

Wow, it already exists. Awesome!

I have an idea I would like to explore to very accurately sync a series of lights within a few milliseconds, and then send a pre-determined sequence of changes with timings over UDP to all lights at once. I'd like to do this, as I previously had issues with Tasmota, where occasionally a light wouldn't change in time due to network conditions/lag.

That would be super cool.

Also, the UI is kinda awful, and would love to come up with something super slick and nice.

Yeah, it's a big project, but it looks like the project could benefit if all of the hand-coded C that deals with http were to focus only instead on implementing a well-designed and documented REST API, and the whole UI could be converted to a nice JS application stored on the filesystem (or hosted on GitHub.io as today with the web app.)

It looks like there was a move in that direction - so now we have both a native http interface as well as a web app with overlapping functionality that is out of sync.

This is actually a tremendously valuable project with a ton of great work behind it from @openshwprojects - but as you say it could use some love and attention from an overall architecture and design standpoint to make it more user and contributor friendly.

Yeah, I'd appreciate a cleanly designed REST api, and also a pub/sub WebSocket endpoint where I can subscribe to events, and receive them in realtime on the webpage, to negate the need for constant polling or page refreshes.

That would be super cool.

I detailed this here: https://github.com/arendst/Tasmota/issues/8305 This would guarantee synchronisation regardless of network conditions, so you could reliably sequence a set of lights to music or something without worrying about it screwing up

Yeah I thought that, and tried swapping these numbers around in many combinations, but didn't get an accurate result :(

Is there a non-invasive way of determining the sm2135 mapping of a bulb? The default mapping kinda works, but the colours are in the right order, and the LED temperature is backwards.

Would be nice if the firmware provided a way of brute forcing combinations until it looks right to the user

We really need to fix coding style and stuff.

Is there a particular C code style you think we should adopt?

Regarding reducing build - I don't know a sensible way to do this, but we already have online and docker builds so there is no problem....

I think for me it's more of a case of reducing surface area of the codebase, to make it easier to understand. Having lots of different unused features, with references to them leaking out all over the codebase adds a lot of mental overhead when trying to understand things.

What would you like to contribute with?

I have an idea I would like to explore to very accurately sync a series of lights within a few milliseconds, and then send a pre-determined sequence of changes with timings over UDP to all lights at once. I'd like to do this, as I previously had issues with Tasmota, where occasionally a light wouldn't change in time due to network conditions/lag.

Also, the UI is kinda awful, and would love to come up with something super slick and nice.

This project has been a life saver, as I was hoping to use Tasmota, but just learned recently that all the new bulbs on the market carry this new chipset, so thanks for all your hard work.

I was hoping to maybe contribute and/or do a personal fork of the project.

Would it be possible to do a quick sweep of the project to cleanup and standardise everything, as I see a lot of placeholder/commented out code, inconsistent variable names, uncommented files, a lot of things prefixed with 'new' etc. Would also be useful in some instances to have abbreviations described at the top of files (e.g. I don't know what HAL means), and some explanation of whatever the Windows part is doing.

Would also love some kind of way of modularising this so I can have a reduced build that only does bulb stuff over HTTP with everything else gone - but I'm not sure how exactly I'd get started with that in C.