Hello, first thanks for your great work. I tried to flash 3 different types of LED lamps so far with openbeken. 1 works great, 2 not. In this thread i ask for help for my first problem LED:
i identified the CBU chip, connected the serial adapter and saved the firmware. The BK7231Flasher was not able to extract the GPIO informations from the firmware.
Then i flashed the firmware suggested by the flasher. Success, but now i have to configure the GPIO pins, where i don't have experiences. I already tried the GPIO doctor, but i didn't get any reaction from the lamp while wildclicking.
From here i ask you how to go further.
If i remember correctly, i could open a tuya developer account, flash back the original firmware, register the device with the tuya developer account and try there to get more infomartions about the device. Would i get there the necessary informations, is this the way to go ?
and try to guess/play around with dpIDs, but I must admit, I haven't seen many LED TuyaMCU devices. So maybe original packets capture can help.
In general, it's a bit strange device. As I just said, most of LEDs devices are not TuyaMCU, they are either raw PWM or "I2C" LED drivers like SM2135, SM2235, BP5758D, etc.
In case of your lamp, if you don't want to use TuyaMCU, you could maybe inspect the PCB and with some electronics knowledge you could figure out which LED drivers are used and interface them with PWM IOs of the BK7231N. Maybe that could work. Just remove TuyaMCU and convert device to raw PWMs.
( startDriver TuyaMCU was already placed somewhere else, as the driver was already loaded )
In fact this works, although the respnsiveness is sometimes not the best.
Now i think the harder parts.
dpId 21, dataType 4-DP_TYPE_ENUM and 1 data bytes
raw data 1 byte:
dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
raw data 4 int: 367
dpId 23, dataType 2-DP_TYPE_VALUE and 4 data bytes
raw data 4 int: 182
dpId 24, dataType 3-DP_TYPE_STRING and 12 data bytes
dpId 25, dataType 3-DP_TYPE_STRING and 2 data bytes
21: probably switch between RGB and white ?
22: brightness ?
23: Kelvin value of white ?
24: RGB value in a string variable ?
25: ?
... yes, sniffing the MCU traffic would be helpful now
Edit:
yes, 21 switches the color modes, i use additionally in the autoexec.bat
If you link channel 15 to some dpID, and use this command, then value 200 will be send to dpID linked to channel 15.
You can use this during testing and development.
dpId 24, dataType 3-DP_TYPE_STRING and 12 data bytes
I think I will add a new channel type for you here. Don't worry, I am online every day, I will do my best to get your device running. It's just that.... it's a first TuyaMCU LED I ever saw. Your device is very unique, that's why we need to do some little work before it will be working.
I will now update tuyaMcu_sendState command to also support strings. Do you happen to know (or is it in Tasmota docs?) how the values of dpID24 looks like here? If it's a 12 bytes of data, then it's not just an RGB string like "FF0000" for red, because it is just 6 bytes. Is it RGBHSV?
With latest update (update your obk first), you can try:
this should send that string to dpID 25 (3 is a data type string). This will work without mapping. This is for testing only, I think. Let me know if that command works for you.
Setting 23 to a value sets the colormode (dpId 21) to 0 (white) and
changes the colortemperature of white.
The range is from 10 (ww) to 990 (cw).
How did i find the range ? I did set the value to 2000, which
is out of range. Then i changed the colormode in the webinterface
to RGB and then back to white and switched off and on (by using dpId 20).
It seems the TuyaMCU checks in this case
the entered min-max values and sets the allowed max and min value, if it's out of range.
So in my case, the value changed from 2000 to 990.
Setting 22 to a value sets the colormode (dpId 21) to 0 (white) and
changes the brightness of white.
The range is from 50 (dark) to 1000 (light).
TuyaMCU uses different types of RGB Hex format where the most recent is 0HUE0SAT0BRI0 (type 1) and the older being RRGGBBFFFF6464 (type 2). Depending on the MCU, code can be case sensitive.
After enabling the RGB function check the TuyaReceived information and use TuyaRGB to configure and store the correct (or the closest) format:
TuyaRGB 0 - Type 1, 12 characters uppercase. Example: 00DF00DC0244 (default)
TuyaRGB 1 - Type 1, 12 characters lowercase. Example: 008003e8037a
i ordered at amazon 2 of these lamps, so i flashed one lamp back
with the saved tuya firmware before flashing with openbeken.
I paired the lamp with the tuya app.
Then i paired the app (and the included devices) in the tuya developer account (i did this
to free my AirConditioner from the cloud some weeks ago, but using the LocalTuya plugin of Homeassistant).
So we get some more acurate informations regarding my lamps:
TuyaMCU uses different types of RGB Hex format where the most recent is 0HUE0SAT0BRI0 (type 1) and the older being RRGGBBFFFF6464 (type 2). Depending on the MCU, code can be case sensitive.
If not, you can just check them all and see which one is working ,right? Let me know.
I have the same device and the same problems. Did you have success in controlling the color and brightness?
Not yet, I was on vacation for some days, so I will continue investigating in the near future. As you can see from the last posts, we are near finding out how to control the color part of this lamp.
I can help with C implementation. I could add some kind of interface so we have a colour picker on the WWW page and it sends a proper TuyaMCU packet, but I need to know how to construct that packet.
So dpID 24 is colour in HSV, type string, Ascii code?
TuyaMCU uses different types of RGB Hex format where the most recent is 0HUE0SAT0BRI0 (type 1) and the older being RRGGBBFFFF6464 (type 2). Depending on the MCU, code can be case sensitive.
After enabling the RGB function check the TuyaReceived information and use TuyaRGB to configure and store the correct (or the closest) format:
TuyaRGB 0 - Type 1, 12 characters uppercase. Example: 00DF00DC0244 (default)
TuyaRGB 1 - Type 1, 12 characters lowercase. Example: 008003e8037a
00f903b6024d looks like 008003e8037a, 12 lowercase characters
I can help with C implementation. I could add some kind of interface so we have a colour picker on the WWW page and it sends a proper TuyaMCU packet, but I need to know how to construct that packet.
So dpID 24 is colour in HSV, type string, Ascii code?
Sorry, I forgot about this topic. You should feel free to remind me, when I don't reply for some time. I remember that I looked at your images and got confused by their order, but I can see that colors seem to be okay.
Sorry, I forgot about this topic. You should feel free to remind me when I don't reply for some time.
No problem, I respect that you invest your time in this project.
p.kaczmarek2 wrote:
Please test and let me know if there are any problems.
OK. I tested it and made a "factory reset" and started then with:
"Toggle Light" works. "LED RGB Color" - the color picker works, the chosen color will be presented by the LED. "LED Dimmer / Brightness" works, but values below 13 make the LED go off.
"LED Temperature Slider" doesn't work. Changing something there does turn off the LED, but I think this is not a problem, as this Slider should only work in the white mode of the LED, right?
Thank you for your kind words. If you like our project, please post a teardown in our IoT section if you encounter an undocumented IoT device. You can also subscribe to our Elektroda com YT channel: https://www.youtube.com/@elektrodacom
Regarding the testing, it seems your device is RGB only, right? So there is no way to display cool and warm white...
It seems we just have to hide the white temperature slider. The only question is, are there also TuyaMCU RGBCW lights? I do not currently have enough knowledge to judge.
Regarding the testing, it seems your device is RGB only, right? So there is no way to display cool and warm white...
It is an RGBCW lamp.
DP 21: switch between RGB and white mode: 1 -> RGB, 0 -> white DP 22: brightness: The range is from 50 (dark) to 1000 (light) DP 23: Kelvin value of white: The range is from 10 (ww) to 990 (cw) (see posts above https://www.elektroda.com/rtvforum/topic3982779.html#20612603)
Hmm, okay, so it seems that we need to support those extra dpIDs. Can you tell me whether dpID 22 (brightness from 50 to 1000) affects the colors sent by OpenBeken?
I am asking because currently OpenBeken does brightness internally and sends already scaled values as Tuya Color. We do not send anything to dpID 22 yet.
Can you tell me whether dpID 22 (brightness from 50 to 1000) affects the colors sent by OpenBeken?
dpID 22 affects only the brightness in white mode.
I want to summarize:
dpID 20: switch the lamp on and off. If the lamp is switched on again, previous color mode and brightness is restored. 0 -> off, 1 -> on dpID 21: switch between RGB and white mode: 0 -> white, 1 -> RGB dpID 22: brightness only in white mode: The range is from 50 (dark) to 1000 (light), NOTE: when changing this value, dpID 21 is set to 0 -> white automatically dpID 23: Kelvin value of white: The range is from 10 (ww) to 990 (cw), NOTE: when changing this value, dpID 21 is set to 0 -> white automatically dpID 24: color (and indirectly brightness) in RGB mode, handled by your code already fine dpID 25: scene management, not yet investigated more, at least for me not needed, so UNUSED
So, in white mode the "Toggle Light" switch does not work (I assume it sets the color to black?)
Hello @nethawk, I will try to add that dpIDs support for your device soon, it's just that I have very limited time and we are also working on simulator Release: https://github.com/openshwprojects/obkSimulator I can try to come up with something for those dpIDs today, but that may require some more testing.
But in general, if you like our project and want to help us, you can: 1. help us spread the word, post on some social media (they may be in your native language or international), or post on Youtube, maybe reach out to YouTubers, etc, so more people know that we are making multiplatform IoT firmware to help users regain their privacy 2. you can post another teardown of any IoT device on our forum, so we can grow this list: https://openbekeniot.github.io/webapp/devicesList.html (I am doing multiple teardowns per month, starting in 2021, so for 2 years already) 3. you can also post an IoT guide here: https://www.elektroda.com/rtvforum/forum517.html if you know something interesting or useful related to generic IoT, feel free to add a short article (or even a long one, if you have time) 4. you can make a donation at my Paypal here: https://www.paypal.com/paypalme/openshwprojects so I can invest more funds into development, mostly devices, parts, dev boards (for example, I recently bricked BL602 dev board by trying to add MAC change feature, silly me... have to buy a new one)
Of course, if you are a developer, you could also help maintain the code, but that requires some C knowledge.
Please keep in mind that the project is done by volunteers in their free time and is a non-profit open-source firmware, so it's often hard to get enough manpower and time to get features ready quickly.
tuyaMcu_sendState 22 2 50 -> white brightness to dark works
tuyaMcu_sendState 22 2 990 -> white brightness to light works
tuyaMcu_sendState 22 2 500 -> white brightness to mid works
tuyaMCU_sendColor 24 1 1 0 1 -> RGB mode, color near yellow works
tuyaMCU_sendColor 24 1 0 0 1 -> RGB mode, color red works
p.kaczmarek2 wrote:
PS: What's going on with dimmer on RGB? I thought it was reported to be working and I didn't change RGB handling.
with 1.17.182 the RGB part (on the web interface) is partly broken: the color picker: doesn't change the color at all the brightness dimmer: doesn't change the brightness at all
Can you check whether the dimmer and temperature behave differently in the latest release?
I am sorry, this didn't succeed.
To enter RGB mode, set the color to red: tuyaMCU_sendColor 24 1 0 0 1 In RGB mode: The color picker doesn't work. Changing the brightness dimmer causes the lamp to go into white mode and dim white correctly.
Now we are in white mode: The dimmer works, The temperature doesn't work.
I know, this is frustrating. Maybe we should calm down the TuyaMCU LED and wait a few days before continuing?
Or, for better debugging, I could:
1. If you like, I can send you the lamp by snail mail.
2. I can give you direct IP access to the lamp (via VPN or port redirection) and give you access to a webcam to see what happens.
Does temperature at least work with those commands then?
I have double checked my code in Simulator, and for this CCT color:
It sends:
55AA0006001016020004000003E817020004000000A5DE
which is:
55 AA 00 06 00 10 16020004000003E817020004000000A5 DE
HEADER VER=00 SetDP LEN fnId=22 Val V=1000,fnId=23 Val V=165 CHK
Maybe it also doesn't like compound packets and i will need to send two dpID values with some interval time... or maybe something else is wrong
Does temperature at least work with those commands then?
RGB mode:
Starting with 1.17.182 the RGB part does not work like it did with previous versions.
The color picker doesn't work and the dimmer doesn't work since 1.17.182
Now testing 1.17.186
RGB mode:
Using the webpage nothing new: color picker doesn't work, dimmer doesn't work.
Using the CMD works:
tuyaMCU_sendColor 24 1 1 0 1
-> RGB mode, color near yellow works
tuyaMCU_sendColor 24 1 0 0 1
-> RGB mode, color red works
white mode:
webpage dimmer for brightness works
webpage slider for temperature doesn't change something
Using the CMD works:
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 16 02 00 04 00 00 03 E8 17 02 00 04 00 00 00 6F AC
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 1000
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 23, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 111
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 15 04 00 01 00 28
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 21, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte:
So what is the difference between changing the brightness (white) and the tempearature (white)
Using the webinterface i changed again the brightness
-> works
setting the brightness using the slider i see in the logs:
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 16 02 00 04 00 00 03 E8 17 02 00 04 00 00 00 6F AC
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 22, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 1000
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 23, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 111
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 15 04 00 01 00 28
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 21, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte:
I see no real difference between changing brigtness and temperature (white) in the logs.
p.kaczmarek2 wrote:
Maybe it also doesn't like compound packets and i will need to send two dpID values with some interval time... or maybe something else is wrong
I am not an expert but if i would guess:
Probably there is an timing issue, TuyaMCU processes dpId 22 while it already
receives dpId 23 instruction. If that's true:
If you would first send dpId 23, followed by dpID 22 (in one command) the
temperature would be processed, but not the brightness.
Suggestion 1: Send 2 seperate commands for dpId 22 and 23, like you already
do for dpId 21, so you can include some milliseconds of sleep.
Suggestion 2: Send only the dpId to the MCU that was changed.
Added after 7 [minutes]:
I include one additional link, only to confirm, that we are right about the dpIds in use:
The discussion revolves around the flashing and configuration of the YB8007/300 LED panel using the BK7231N chip and OpenBeken firmware. The user successfully flashed one LED lamp but faced issues with GPIO extraction using BK7231Flasher. Participants suggested trial and error with pin assignments for color control and identified the device as a TuyaMCU type, requiring specific commands for color and brightness adjustments. The conversation included troubleshooting steps, such as using dpIDs for controlling color modes, brightness, and temperature settings. The user reported mixed results with RGB and white modes, leading to further development of the firmware to improve functionality, including a color picker and adjustments for temperature control. The integration with Home Assistant was also discussed, highlighting the need for a queue system to manage command packets effectively. Summary generated by the language model.