i will do anything you need regarding testing this. i will buy new esp32s, etc. anything that moves this and potentially gets these lights (chip) into WLED is my main priority. the quicker we can do that, the quicker we can get it into a release.
WLED_16.0.0-alpha_ESP32_V4_WLEDpixelBus_experimental.bin (1.2 MB)
try this, works on my TM1814 and pattern looks correct for TM1815
not sure the govee can take the full brightness so be careful setting it to 100%
Major update with much more detailed testing. I switched to a QuinLED Dig-Quad with proper level shifting and got much more consistent results.
Hardware: QuinLED Dig-Quad, ESP32-WROOM-32E (ESP32-D0WD-V3 rev.3.1), GPIO 16, Govee H7050 ground lights (15 pucks, 12V)
TM1815 experimental bin: Confirmed type:35 with correct timings (t0h=740 t0l=1780 t1h=1440 t1l=1060) but lights show no response to any commands — stuck on power-on state.
SM16825 RGBCW: Gets the most response. Tested all 6 color orders with pure red and documented results per column in a 5x3 matrix. No color order fully fixes the mapping — column 2 is always WW regardless of command, suggesting the 5-channel byte order can’t be corrected with the standard RGB color order dropdown alone. Yellow artifacts suggest R+G mixing in wrong channels.
Is there a way to specify the full 5-channel byte order independently? Or could a ledmap.json help remap the channels? The chip in these lights may have a non-standard RGBCW order similar to the walkway lights in issue #4365.
agengr1293, are you using the H7050 pathway lights? i think they are first gen of the pathway lights. if so, can you share the LED Setup in WLED?
They are the string lights. See pictures above. Shows the internal chip with LEDs on them. Also shows which controller I am using.
SM16825 is a completely different chip and its supported by WLED - does it not work in a standard build? also color order mapping is limited. my driver allows to map it in any way but the UI does not allow for all options to be set. What order does govee use?
Good news — got it fully working! Before the solution, here are the critical gotchas that caused me days of confusion:
Gotchas:
-
30 LEDs not 15 — each physical puck has 2 addressable channels so you must set length to 30
-
Global brightness scale must be 100% — the new WLED feature was silently scaling brightness and preventing the white channel from turning off fully
-
White brightness is inverted — bri:255 = completely OFF, bri:1 = full brightness
-
Dig-Quad with level shifting required — bare ESP32 without level shifting gave unreliable results
-
RGB color order — not GRB as you might expect
Working config for Govee H7050 ground lights (first gen, 15 pucks, 12V):
-
LED type: WS281x
-
Color order: RGB
-
Length: 30
-
Two segments, both 0-30, spacing 1
-
Segment 0, offset 0 = RGB channel
-
Segment 1, offset 1 = White channel (inverted brightness)
Full RGB, cold white, and warm white all independently controllable.
Questions for you:
-
Based on this offset behavior, can you determine the actual byte order Govee used?
-
Is native support possible without the dual segment workaround?
-
Would a ledmap.json simplify this for end users?
-
Is there a way to fix the inverted white brightness natively so the brightness slider behaves normally for end users?
Further investigation reveals the exact chip structure:
Each physical puck contains 6 LEDs — 3 RGB and 3 dedicated Warm White. Cold white is simply RGB at full blast [255,255,255], not a separate channel. This makes it effectively a 2-byte-per-puck device:
-
Byte N (even): RGB
-
Byte N+1 (odd): Warm White — active low (0 = full brightness, 255 = off)
Protocol confirmed: WS281x at 800kHz, RGB color order, 12V.
This seems like it should be straightforward to support natively — essentially WS281x with an active-low W channel. Is the main blocker just the inverted white, or is there something else preventing native support?
Final update after running an automated test matrix (Claude AI + webcam + Python):
Root cause confirmed: Each puck contains 2 × standard WS2812B chips in series — one RGB, one Warm White. It is NOT a 4/5-channel chip. SK6812, TM1814, SM16825 all fail because they send the wrong byte count (60 bytes vs the required 90).
The dual-segment WS281x setup IS the correct native implementation — not a workaround.
White inversion is hardware-level — the WW chip is wired active-low. Cannot be fixed by any LED type or color order setting.
Feature request: A WS281x_RGBWW LED type with automatic W channel inversion would make this plug-and-play for end users. The protocol is plain WS281x — just needs the WW byte automatically inverted.
EDIT: After all of this, I just realized I hijacked your thread. I’m so sorry.
Hope your having a great day! I noticed that TM1815 did not make the v16.0.0 release. Do you think it will be in the next release?
I can’t say, it will be there eventually.