BK7238 Lampa sufitowa LED (RGBIC+CCT) - Integracja z asystentem domowym?

Cześć,

Kupiłem 3x te lampy sufitowe z AliExpress:
https://www.aliexpress.com/item/1005009635507929.html

Specyfikacje:
- WiFi + BLE (2.4GHz)
- Chip: BK7238 (Beken)
- 5 kanałów: RGBIC + CCT
- Główny biały panel (3000K / 4000K / 6000K)
- Dodatkowy pierścień RGBIC (efekty / światło otoczenia)

⸻

Aktualna sytuacja
- Urządzenie działa w pełni w aplikacji BRITURN
- Wykryto również za pomocą aplikacji Magic Home, ale:
- Działa tylko ON/OFF
- Brak kontroli RGB / CCT / efektów
- Asystent domowy:
- Próbowałem integracji Flux LED (Magic Home) → nie powiodło się: "Nieznany model FBF615. Nie można określić protokołu"

Obserwacje
- Urządzenie udostępnia lokalny punkt dostępowy WiFi (tryb nieskonfigurowany)
- Po sparowaniu → uzyskuje IP, ale protokół wydaje się niestandardowy
- Prawdopodobnie niestandardowe oprogramowanie układowe, niezgodne z MagicHome

Zgodnie z dokumentacją HA, Flux/MagicHome działa tylko wtedy, gdy protokół pasuje do znanych kontrolerów... co nie wydaje się mieć miejsca w tym przypadku.

Jakieś wskazówki, jak go sflashować, zintegrować?

PROSZĘ O POMOC

>>21884139 >>21884139

Dzięki @insmod!!!

Wczoraj wieczorem sflashowałem go za pomocą OpenBK7238.

Zamiast odlutowywać moduł, wypróbowałem boczne GPIO i działało świetnie!!!

1. Zrobiłem kopię zapasową oryginalnego firmware (załączony plik).
2. Flash ze starą wersją OpenBK7238 > boot się zawiesił.
3. Flash ponownie z ostatnią wersją OpenBK7238 połączoną > wszystko działa!!! Świetna robota @insmod

4. Teraz wyzwaniem jest skonfigurowanie modułów.

Policzę diody LED i spróbuję odkryć więcej...

Cześć wszystkim,

Chciałem podzielić się moimi spostrzeżeniami po tym, jak spędziłem sporo czasu próbując uzyskać lampę sufitową RGBIC CCT opartą na BK7238 działającą z OpenBeken.

Jest to typowa jednostka w stylu Tuya z:
- Główny biały panel CCT (ciepły/zimny)
- Zewnętrzny adresowalny pierścień RGB (RGBIC)

⸻

Szczegóły sprzętowe
- Moduł: WB43-M5 v1.2
- Główny układ scalony: Beken BK7238
- PŁYTKA DRUKOWANA: HD-ZJZM24W-HC
- Pierścień RGB: 38 diod LED (adresowalne, prawdopodobnie SM16703P lub podobne)

Co działa ✅

Po wielu próbach i błędach udało mi się w pełni uruchomić główne białe światło.

Konfiguracja pinów:

P6 -> PWM -> kanał 1 (zimny)
P8 -> PWM -> kanał 0 (ciepły)

Polecenie uruchomienia
backlog setChannelType 0 cwww

Daje to pełną kontrolę nad
- Jasność
- Temperatura barwowa

Tak więc strona sterownika CCT została potwierdzona jako działająca i stabilna.

⸻

Co NIE działa ❌

Pierścień RGBIC w ogóle nie działa z aktualną wersją oprogramowania układowego.

Próba konfiguracji

Próbowałem przypisać GPIO jako:
SM16703P_DIN

Próbowano wykonać polecenia:
SM16703P_Init 38 GRB
SM16703P_SetPixel all 255 0 0
SM16703P_Start

All return... cmd ... NIE znaleziono
CMD: cmd SM16703P_Init NIE znaleziono

Wygląda to następująco:

Kompilacja "merge" naprawia bootowanie BK7238, ale została skompilowana bez obsługi adresowalnych diod LED (pikseli).

jakieś wskazówki @insmod na ten temat?

>>21884507
Aktualizacja do ostatniej wersji OpenBK7238, 1.18.287
Przed użyciem poleceń SM16703P należy najpierw użyć "start driver SM16703P"

Jeszcze raz dziękuję @insmod, aktualizacja do najnowszego oprogramowania rzeczywiście włączyła sterownik RGB.

Zaktualizowałem do najnowszej wersji OpenBeken:
- Wersja: 1.18.287
- Inicjacja sterownika: startDriver SM16703P; SM16703P_Init 38 GRB

Obserwacja sprzętu

Wygląda na to, że jest to urządzenie oświetleniowe 2 w 1 sterowane przez WB43-M5 v1.2 (BK7238):
- Kanał 1: główna biała dioda LED (CCT/jasność)
- Kanał 2: Adresowalne diody LED RGB (SM16703P)

Tak więc fizycznie za jednym kontrolerem kryją się dwa niezależne systemy oświetleniowe.

Co działa
- Sterownik SM16703P działa poprawnie
- Pasek RGB reaguje prawidłowo na: SM16703P_SetPixel all R G B; SM16703P_Start
- Kanał biały działa, ale tylko jeśli sterownik jest zatrzymany. Tak więc przy zatrzymanym sterowniku biały działa w pełni (suwaki sterowania kolorem i jasnością), po uruchomieniu sterownika suwak koloru białego znika i pojawia się pole, które po kliknięciu otwiera selektor kolorów dla świateł RGB.

Problem (na poziomie firmware)

Oprogramowanie układowe wyświetla wszystko jako pojedynczą jednostkę światła.

W rezultacie:
- Urządzenie zachowuje się jak połączone światło
- Prawidłowo reprezentowany jest tylko kanał główny (biały)
- Pasek RGB nie jest mapowany do własnego światła logicznego

Ograniczenie główne

Obecny model oprogramowania układowego wydaje się zakładać: Jedno urządzenie = jedno światło

Ale ten sprzęt jest wyraźnie: Jedno urządzenie = dwa niezależne światła

Z tego powodu:
- Sterownik RGB działa, ale nie ma reprezentacji na poziomie jednostki
- Nie ma separacji między białymi i RGB ścieżkami sterowania

Oczekiwane zachowanie

W idealnym przypadku oprogramowanie układowe powinno umożliwiać
- Wiele jednostek światła na urządzenie, np:
- Light_Master_Bedroom_White
- Light_Master_Bedroom_RGB
- Powiązanie SM16703P z własnym logicznym wyjściem światła
- Niezależne sterowanie obydwoma kanałami

P26 jest ustawiony na używanie SM16703P_DIN

W Home Assistant mqtt są to wykryte atrybuty:

min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6493
supported_color_modes: color_temp
friendly_name: Światło w sypialni głównej
supported_features: 0
color_mode: color_temp
jasność: 255
color_temp_kelvin: 2000
hs_color: 30.601, 94.547
rgb_color: 255, 137, 14
xy_color: 0.598, 0.383

Dodano po 3 [minutach]:

Tak to wygląda w praktyce:

Tak, wyświetla się jako pojedyncza jednostka świetlna, a użycie RGB wyłącza CW i odwrotnie.
Ale tylko wtedy, gdy zimna biel jest ustawiona na kanał 3, a ciepła - kanał 4. W ten sposób nie ma potrzeby wyłączania sterownika SM16703P.

@p.kaczmarek2
Jakieś sugestie?
Przynajmniej dobrze byłoby móc sterować SM16703P przez kanały i móc ręcznie ustawić 2 oddzielne jednostki w HA.

Zacząłem robić tutaj trochę AI slop, aby być może rozwiązać problemy z dziwnymi urządzeniami LSC z paskami WS2812B+PWM CW/WW RGBIC+CCT https://github.com/openshwprojects/OpenBK7231T_App/compare/main...divadiow:O penBK7231T_App:lsc

ale straciłem pewność siebie i zainteresowanie, więc nie wiem.

Głównym problemem jest kompatybilność wsteczna. Nie możemy zepsuć istniejących konfiguracji, więc musielibyśmy ostrożnie zaktualizować sterownik LED.

Może dodać flagę zezwalającą na podział?

Pytanie: czy chcemy dwie oddzielne jednostki świetlne, czy pojedynczą jednostkę świetlną, która może pracować w trybie RGBCW (wszystkie diody LED włączone)?

Może zamiast tego moglibyśmy dodać niestandardową integrację WS2812 HA, która działa osobno, a główny sterownik LED pozostaje nienaruszony?

>>21884900

Obecny scenariusz: kontrola globalna

Urządzenie
└── ONE Light (globalne & niechlujne kontrole)
├── Ciepła biel PWM (P6)
├── PWM zimna biel (P8)
└── SM16703P_DIN (P26)

Wynik:
- Cała kontrola odbywa się przy tym samym globalnym poziomie światła
- RGB nie jest odizolowane od kanałów bieli
- Włączenie RGB wpływa na sterowanie białym światłem w interfejsie użytkownika (suwak działa tylko dla RGB, nie dla białego)

Kilka opcji to:

Proponowane rozwiązanie 1: jedno światło z kontrolkami podrzędnymi
Urządzenie
└── ONE Light
├── Białe elementy sterujące
│ ├── Ciepła biel PWM (P6)
│ └── PWM zimna biel (P8)
└── Elementy sterujące RGB
└── SM16703P_DIN (P26)

Wynik:
- Zachowano jedną jednostkę światła w celu zapewnienia kompatybilności
- Biały i RGB mogą być sterowane niezależnie w tym samym świetle
- Oba systemy mogą współistnieć. Home Assistant MQTT może w razie potrzeby utworzyć wirtualne urządzenie

Proponowane rozwiązanie 2: podział na dwa światła
Urządzenie
├── Światło 1: Białe światło
│ ├─── PWM ciepły biały (P6)
│ └── PWM zimna biel (P8)
└── Światło 2: światło RGB
└── SM16703P_DIN (P26)

Wynik:
- Dwa oddzielne źródła światła
- Białe i RGB są w pełni niezależne
- Bardziej bezpośrednie dopasowanie do układu sprzętowego

Flaga umożliwiająca dowolne z tych rozwiązań byłaby świetna!!!

Lub przypisanie innego kanału dla P26 > SM16703P_DIN > Kanał 2, na przykład, aby odizolować go od kanałów 0 i 1 (zimna / ciepła biel)?

W BK7238 SM16703P_DIN jest zakodowany na stałe na P16, bez względu na to, co jest ustawione w GUI.
Jeśli go usuniesz, nic się nie zmieni.
Wewnętrznie wykorzystuje kanały 0, 1, 2 dla RGB, co oznacza, że nie można ich używać, gdy sterownik jest uruchomiony.
Kanały 3 i 4 są zarezerwowane dla zimnej i ciepłej bieli.

Możesz ustawić ciepłe/zimne kanały na dowolne wyższe niż 4, a następnie ręcznie utworzyć światło w HA configuration.yaml, które będzie z nich korzystać.

przepraszam za przerwę. Po prostu dodaję dziennik rozruchu zrzutu dla rekordu

Hej chłopaki,

Eksperymentowałem z oprogramowaniem układowym i udało mi się stworzyć rozwiązanie, które lepiej odzwierciedla sposób, w jaki te hybrydowe urządzenia RGB + CCT są faktycznie okablowane.

Co zrobiłem

Wprowadziłem nową koncepcję sterownika o nazwie virtualLights, która dzieli globalną kontrolę światła na dwa niezależne światła logiczne.

Zamiast jednej połączonej jednostki, urządzenie jest teraz widoczne jako:

Urządzenie
├── Światło 1: Białe światło
│ ├── PWM ciepły biały (P6)
│ └── PWM zimny biały (P8)
└── Światło 2: światło RGB
└── SM16703P_DIN (P16)

Jak to działa?

* Biały (CCT) → standardowe kanały PWM
* RGB → obsługiwane przez SM16703P (adresowalne diody LED przez SPI)
* sterownik virtualLights → dzieli sterowanie na dwie niezależne jednostki

Konfiguracja startowa

To jest bieżąca konfiguracja startowa:
backlog startDriver SM16703P; SM16703P_Init 38 GRB; SM16703P_Start; startDriver VirtualLights; VirtualLights_Enable 1;

Wynik

* Dwie oddzielne jednostki światła
* Biały i RGB w pełni niezależne
* Brak konfliktów trybów (np. nadpisywanie białego i RGB)
* Lepsze dopasowanie do rzeczywistego projektu sprzętu

Uwaga projektowa

Podział virtualLights może być opcjonalny.

Pomysł polega na tym, aby była to funkcja oparta na flagach, aby użytkownicy mogli wybrać:

* VirtualLights_Enable 1 → podział na dwa światła
* VirtualLights_Enable 0 → powrót do klasycznego zachowania pojedynczego światła

Pozwala to zachować kompatybilność wsteczną, jednocześnie umożliwiając dokładniejszą konfigurację dla urządzeń, które tego potrzebują.


Kolejne kroki

Jeśli jest zainteresowanie, mogę przygotować pull request ze zmianami (sterownik + integracja).

Chętnie poznam opinie lub dostosuję implementację 👍

Jak to wygląda:


Firmware > OpenBeken7238 OpenBeken7...Lights.zip (2.1 MB)Musisz być zalogowany, aby pobrać ten załącznik.

wygląda super.

a jeśli zdecydujesz się nie uruchamiać sterownika VirtualLights, czy SM16703P zachowuje się tak, jak pierwotnie pod każdym względem? Zastanawiam się tylko, jaki byłby wpływ dla każdego, kto ma w pełni skonfigurowane urządzenie do podstawowej obsługi SM16703P, jeśli OTA do wydania zawierającego zmiany kodu dla tego, jeśli został scalony.

Proszę otwórz PR, abym mógł go porównać, a także, czy nadal przechodzi autotesty?