Witajcie, przedstawię tu wnętrze oraz zmianę firmware kolejnej lampki LED. Temat wyróżni się tym, że ta LEDówka korzysta z protokołu I2C do kontroli swoich kolorów, a dokładniej do komunikacji między modułem WiFi/Bluetooth WBLC5 (BK7231T) i stałoprądowym kontrolerem LED SM2135Eh. Opiszę tu też sam protokół komunikacji z SM2135Eh i dam prosty przykład jego implementacji bazujący na cyfrowym IO, czyli bez sprzętowego I2C.
Na koniec tematu też pokażę jej konfiguracje w OpenBeken.
Zakup WOJ14415
Lampką tą zakupiłem na polskim portalu aukcyjnym na skutek prośby jednego z użytkowników mojego OpenBeken - zostałem poproszony, by dodać wsparcie układu SM2135.
Produkt znalazłem pod hasłem Żarówka LED GU10 5W RGB SPECTRUM SMART WIFI TUYA, poza tytułem oferty jest też jego kod producenta - WOJ14415.
Kupiłem go wraz z innymi lampkami smart, dzięki czemu miałem darmową przesyłkę.
Produkt przybył w takim pudełeczku:
UWAGA - produkt jest brandowany na "spectrum", ale jest kompatybilny z aplikacją Tuya! Sprawdzane.
Wnętrze WOJ14415
Plastikowe "szkiełko" wyjąć jest dość łatwo. Wtedy już widać, że w środku jest SM2135:
Z usunięciem płytki z LED trochę się siłowałem. Ciężko było. Ostatecznie zrobiłem mały otwór z drugiej strony i ją wypchałem na zewnątrz.
Piny od płytki są podpisane. Widać tu m. in CLK, które jest zegarem od I2C. Niepodpisany obok pin to pewnie DATA, linia danych I2C. Oprócz tego m. in. jest 3.3V (zasilanie kontrolera LED), 20V (zasilanie LEDów?), masa...
LEDy są osobno ciepłe, zimne i kolorowe (RGB).
Reszta układu z modułem WiFi:
Na płytce raczej to co zwykle, rezystor bezpiecznikowy (FR1, Fusible Resistor), jakaś przetwornica step down 8HMP (wraz z dławikiem 4R7 czyli 4.7uH), pewnie do zasilania modułu WiFi...
Te 8HMP to może być TP6841S6:
Co kryje się pod naklejką? Moduł z BK7231T:
WBLC5. Wymiary:
Wyprowadzenia:
Niestety piny od programowania nie są podpisane. Na szczęście uzupełniłem dla was grafikę:
Przylutować trzeba się będzie pod co najmniej TX1 i RX1.
Jeszcze dla zasady, spód płytki, m. in. mostek prostowniczy, jakiś jeszcze inny element w SMD (ktoś rozpozna?):
Nie analizowałem głębiej już płytki z zasilaniem, pora skupić się na SM2135.
Pięciokanałowy kontroler I2C LED SM2135
Kontroler SM2135 służy do obsługi lampek RGBCW, czyli obsługuje 5 osobnych kanałów. Sterowany jest poprzez linie I2C, czyli do sterowania 5-cioma kanałami starczają dwie linie, DAT i CLK. Dodatkowo wymaga też zasilania. 5 kanałów + 2 linie + zasilanie daje nam już 8 pinów, więc sprytny producent masę dał na spodzie układu:
SM2135 pracuje na wyprostowanym napięciu sieciowym. Nie potrzeba dla niego dodatkowego zasilacza. Przykładowa aplikacja SM2135 przedstawiona jest poniżej:
Niezbyt zgadzam się z tym podpisem "AC->DC" na przetwornicy step down zasilającej mikrokontroler (moduł WiFi/Bluetooth), gdyż tam już na wejściu jest już DC. Oprócz tego wszystko się zgadza, choć czasem między step down a modułem MCU nie ma osobnego regulatora LDO, o ile przetwornica daje stabilne 3.3V dla układów ESP czy tam Beken (bądź innych, rzadziej stosowanych).
Diagram komunikacji I2C:
Oto jego opis z noty katalogowej, niezbyt się z nim zgadzam, chociażby to "8byte + 1ack" to raczej błąd, powinno być 8 bitów i jeden ack.
Spróbuję go Wam przetłumaczyć i wyjaśnić.
Start transmisji oznaczany jest poprzez przejście DATA ze stanu wysokiego na niski gdy CLK jest wysoki.
Koniec transmisji oznaczany jest poprzez przejście DATA ze stanu niskiego na wysoki gdy CLK jest wysoki.
W trakcie wysyłania danych, zmiana stanu DAT powinna następować gdy zegar jest nisko.
Po 9 cyklach zegara układ sam generuje ACK, tj. ustawia pin DATA w stan niski.
Wysyłanie danych odbywa się poprzez podanie bajtu adresu rejestru i kolejnych bajtów zawartości (można podać ich kilka).
Jeśli chodzi o rejestry, to kolejno mamy:
- limit prądu (1 bajt) - adres 0xC0
- tryb RGB lub CW (1 bajt) - adres 0xC1
- dane koloru (5 bajtów, RGBCW) - adres 0xC2 itd
Wartości limitu prądu:
Wartości koloru oraz wyboru trybu:
Po wysłaniu danych (można wysyłać różne ilości bajtów, wskaźnik na docelowy adres zwiększa się sam) należy również wygenerować sygnał stop.
Oto cała transmisja:
Wiem, że to wszystko może wydawać się niezbyt intuicyjne, więc spójrzmy już na praktyczny przykład:
Kod: C / C++
Uważny czytelnik zobaczy tu już pewną nieścisłość... tryb RGB ale 5 kolorów? W praktyce tak to działa, że w trybie RGB można ustawić wszystkie 5 wyjść i dodatkowo w ten sposób sterować również odcieniami bieli (zimny i ciepły). Kolejność bajtów z tablicy jest zmieniona, bo na tej płytce tak były podłączone LEDy.
W moim przypadku tyle starczyło by obsłużyć wszystkie tryby. Innych sposobów nie implementowałem.
Zostaje kwestia samego I2C. Można użyć sprzętowego, ale można też zrobić to w software poprzez proste digitalWrite i digitalRead, czyli zmiany stanów pinów cyfrowych w stylu Arduino.
Dokładnie taką implementację mają popularne software dla ESP (bazujące na Arduino) i to z tego podejścia skorzystałem.
(Uzupełnienie: poprzez "taką implementację" mam na myśli implementację komunikacji z SM2135, nie ogólnie całe software I2C. Podkreślam to dla zasady - dzięki @khoam)
Kod: C / C++
Tu już powinno pojawić się pierwsze pytanie od czytelnika - czemu "SetHigh" ustawia w tryb.... wejścia? A nie wyjścia w stanie wysokim?
To dlatego, że urządzenie powinno móc wygenerować odpowiedź, te właśnie słynne ACK, czyli "nadpisać" stan wysoki ustawiony poprzez rezystor pull up (programowalny) na pinie input.
Można to sobie wyobrazić tak jak działanie przycisku, gdy na pinie wejściowym mamy przycisk (między nim a masą) to ustawiamy programowany pull-up i domyślnie jest stan 1, ale jak ktoś wciśnie przycisk to jest stan 0.
Kod: C / C++
Oto procedura pisania jednego bajtu. Ta dziwna pętla z przesunięciem bitowym po prostu iteruje kolejne bity bajtu i kolejno sprawdza, czy dany bit jest zapalony w bajcie który chcemy wysłać.
Następnie ma miejsce odebranie bitu ACK, zgodnie z tym co pisałem wcześniej pin DAT ustawiony jest w tryb wysoki ale poprzez input pullup (a nie output o stanie 1), dzięki czemu można odczytać odpowiedź od układu poprzez ReadDigitalInput. Stanowi to proste sprawdzenie, czy komunikacja się powiodła.
To był dość uproszczony opis, ale myślę, że tyle starczy. Wiemy już jak działa ustawianie kolorów w lampkach na SM2135 oraz przy okazji też nieco dowiedzieliśmy się o samym I2C.
Swoją drogą nie widzę tu opcji wyboru adresu urządzenia (czyli nie ma możliwości chyba połączenia wielu SM2135 na jednej magistrali), ale chyba producent tego wcale nie planował...
Pełny kod implementacji komunikacji na którym się wzorowałem (oparty o digitalWrite itd):
https://github.com/arendst/Tasmota/blob/devel...tasmota/tasmota_xlgt_light/xlgt_04_sm2135.ino
Szybki test z aplikacją Tuya
Aplikacja Tuya była omawiana wielokrotnie, więc bez większego komentarza.
W tryb parowania wszedłem poprzez pięciokrotne podłączenie i odcięcie zasilania lampki. Bluetooth musiał być włączony w telefonie. Parowanie wymagało podania danych mojego WiFi, by podłączyć lampkę do internetu. Parowanie przebiegło bez problemów.
SM2135 w OpenBeken
Ten akapit przeznaczony jest już dla użytkownika. Wgrywanie OpenBeken realizujemy tak jak np. opisywałem tutaj:
Ogrodowy podwójny przekaźnik Tuya CCWFIO232PK - BK7231T - programowanie
RESET wykonałem poprzez odcięcie zasilania. Aby nie przeciążyć portu USB prądem pobieranym po podłączeniu przez kondensatory, zasilanie pociągnąłem osobno. Oczywiście przez zewnętrzny LDO 3.3V.
W samym OpenBeken po standardowej konfiguracji wybieramy piny SM2135 I2C:
To zasadniczo wszystko. Od tego momentu możemy kontrolować lampkę z Home Assistant:
Kod: YAML
(konfiguracja YAML nie różni się niczym od konfiguracji lampki RGBCW opartej o pięć kanałów PWM na BK7231T)
Można też kontrolować ją z poziomu OpenBeken, ale wymaga to jeszcze zaznaczenia jednej flagi w Options->General, gdyż bez pinów PWM sam system na razie nie wykryje, że to RGBCW:
Od tego momentu uzyskujemy panel:
Opcja poziomu jasności jest wspólna, natomiast z trybów "temperatura bieli" oraz "barwa RGB" możemy wybrać tylko jeden w danym momencie. Tak jak w Home Assistant.
Kolejność kanałów w OpenBeken
Kolejność kanałów RGB nie jest standaryzowana. Przekonałem się o tym dzięki pomocy testerów mojego firmware. W związku z tym do OpenBeken dodana została komenda:
SM2135_Map 0 1 2 3 4
Komenda ta mapuje kolejno kanały RGBCW (pięć kanałów) na indeksy kanałów SM2135.
Urządzenie nie zapamiętuje mapowania samo z siebie, komendę należy dodać do "short startup command" z Options bądź "autoexec.bat" z LittleFS w nowym panelu javascript.
Kompatybilność z Tasmota Device Groups
OpenBeken jest kompatybilny z Tasmota Device Groups, które pozwalają synchronizować pracę wielu urządzeń jednocześnie, jak również sterować dużą ilością urządzeń bez pośrednictwa Home Assistant.
Podsumowanie
W ten sposób udało uruchomić się SM2135. Dzięki dobrej dokumentacji oraz dostępności gotowych sterowników nie było z tym żadnego problemu. Proste operacje na pinach IO są dostępne na każdej platformie, więc wystarczy przeportować kod. Co prawda w przypadku mojego OpenBeken sterowanie jest zrealizowane nieco inaczej niż w innych systemach (na ten moment wszystko idzie przez tryb RGB, wszystkie 5 kolorów) ale na ten moment nie odczułem z tym żadnych problemów.
Na koniec dodam, że obecność I2C (jak i tym bardziej modułu WiFi/Bluetooth, 32-bitowego) w zwykłych LEDówkach (no dobra, kolorowych) w pewien sposób skłania mnie do przemyśleń. Pomału wszystko robi się "online", nic dziwnego, że prowadzę projekt OpenBeken który pozwala odciąć takie gadżety od serwerów producenta i uniezależnić się od inwigilacji i ewentualnych problemów (co jak chmura padnie?).
Chciałbym też podziękować użytkownikowi @rawilson za polecenie mi sprawdzenia tej lampki. Przygoda była ciekawa a OpenBeken zyskał kolejny sterownik.
Załączam notę katalogową omawianego układu SM2135 .
Fajne? Ranking DIY Pomogłem? Kup mi kawę.
