Witajcie moi drodzy.
Przetestuję tutaj 'smart' włącznik/ściemniacz światła WiFi QTouch, sparuję go z aplikacją eWeLink na Androida, przeanalizuję jego budowę, przedstawię podsłuchiwanie jego protokołu komunikacji na UART (komunikacja między ESP a mikrokontrolerem UTF) oraz narysuję schemat. Ujawnię również duże nieścisłości między rzeczywistą formą produktu a tym, co obiecuje sprzedawca. Będzie to już drugi temat o serii QTouch. Na koniec spróbuję też wydobyć hasło i SSID mojego WiFi z wsadu jego ESP, zobaczymy, czy się uda.
Poprzedni temat o QTouch
Poprzednio już rysowałem schemat włącznika QTouch, ale zupełnie innego.
Ten wcześniej testowany wyróżniał się tym, że wpinało się go w przewód L (bez N) i o dziwo działał, łącznie z WiFi. Jego układ był dość sprytnie zrealizowany, szczegóły tutaj:
https://www.elektroda.pl/rtvforum/topic3793509.html
Włącznik który zaraz przedstawię wymaga podłączenia zarówno N i L, a z kolei wyróżnia się tym, że oferuje możliwość ściemniania oświetlenia (oczywiście oparte jest ono na triaku, więc nie zadziała z dowolną żarówką).
Zakup ściemniacza QTouch Quadra
Produkt kupiłem w naszym kraju przez portal sprzedaży wysyłkowej za 80 zł:
Włącznik reklamowany jest jako wspierający WiFi i pilot RF 433 (uwaga: w rzeczywistości pilota nie wspiera):
Sprzedawca podaje poprawny schemat montażowy włącznika (jest to dość ważne, gdyż w załączonej w pudełku instrukcji jest niepoprawny schemat!!):
Ale na ofercie sprzedawcy są też inne niepoprawne informacje. Sprzedawca najpierw sugeruje, że włącznik ten podłączamy na 12/24V a potem podaje, że napięcie pracy to 170-240V...
Nie zgadzało mi się to, więc podpytałem sprzedawcę o zdanie, ale sprzedawca potwierdził, że ten włącznik nie działa na 230V i wymaga transformatora, a każdy z jego trzech przycisków (jaśniej, ciemniej, wyłącz) można sparować z pilotem:
Niby broszura producenta też podkreśla, że ten produkt ma RF433:
Czy sprzedawca ma rację? Jak jest w rzeczywistości?
Pora się przekonać.
Zawartość zestawu
Z opakowania produktu wprost wynika, że wspierana jest komunikacja przez WiFi i RF433:
Kod produktu: QBP.DIM.WIFI
W środku mamy instrukcję, włącznik i kondensator...
Instrukcja, niestety nie dotyczy ona tego produktu. Ta instrukcja jest od włącznika który nie potrzebuje podpięcia zera (wpinanego w fazę), a nie od ściemniacza:
Tył:
Na obudowie jest inny kod produktu niż w ofercie. LX-WIFI-03O (EU). Pod tym hasłem można znaleźć oferty spoza naszego kraju. Nie ma w nich nic o RF433.
Pierwsze uruchomienie
Po montażu (zgodnie z instrukcją ze strony, nie tej z pudełka):
Przyciski są podświetlane, moim zdaniem całość jest dość estetyczna i mi się podoba.
Przyciski reagują dość wolno, ale ściemnianie jest płynne, lecz nie od 0.
Parowanie z aplikacją eWeLink i sterowanie przez telefon
Przed parowaniem należy wprowadzić urządzenie w tryb RESET poprzez dłuższe naciśnięcie przycisku (aż zacznie migać szybko na niebiesko).
Parowanie działa w trybie "Szybkie parowanie".
Parowanie wymaga podania SSID i hasła naszego WiFi (tylko 2.4GHz wspierane).
Aplikacje urządzeń Smart szczegółowo opisywałem w poprzednich tematach z tej serii.
Zrzuty z parowania krok po kroku:
Aplikacja oferuje interfejs jak poniżej (można sterować jasnością paskiem, od 1% do 100%):
Jeśli interesuje Was więcej informacji na temat aplikacji sterowania włącznikiem, to polecam zapoznać się z tymi tematemi:
https://www.elektroda.pl/rtvforum/topic3687040.html#18652154
https://www.elektroda.pl/rtvforum/topic3749207.html
Co prawda jest tam o innej aplikacji, ale one są bardzo podobne
Parowanie z pilotem RF433MHz
Nie byłem w stanie sparować tego włącznika QTouch z żadnym z moich pilotów, mimo iż drugi QTouch (ale bez ściemniacza) bez problemu z pilotem działał.
Moje piloty:
Podejrzewam, że ten QTouch ze ściemniaczem nie wspiera jednak RF (i analiza jego płytki to potwierdza, ale o tym zaraz)
Wnętrze ściemniacza
Pora zajrzeć do środka. Frontowy panel można zdjąć podważając go płaskim śrubokrętem.
Panel z ESP jest po prostu wyjmowany (choć chyba też był lekko przyklejony):
Wnętrze ściemniacza - płytka z ESP
Na tej płytce są tylko układy na niskie napięcie, 3.3V. Jej rolą jest obsługa komunikacji przez WiFi, procesu ściemniania (lecz wykonujący ściemnianie triak jest na drugiej płytce) oraz przycisków dotykowych.
Mamy tu ESP8285 (czyli ESP8226 z wbudowana pamięcią Flash), UTF87001 i HD6001.
HD6001, mikontroler przycisków dotykowych. Tak, mikrokontroler, nie zwykły układ przycisku dotykowego.
UTF87001, kolejny mikrokontroler, produkowany przez Songhan. Chyba w architekturze C51. Bardzo mało znalazłem o nim informacji. Programuje się go jakimś adapterem SoniX SN-Link3.
Pinout:
Informacje o programowaniu:
Alternatywne miejsce na złącze między płytkami:
Alternatywne miejsce na moduł WiFi (może się przydadzą te pady jak do nich przylutujemy kabelki?):
Tranzystor 1AM (do włączania triaka?).
Czyli MMBT3904LT1.
Dwa przydatne punkty lutownicze:
Obok ESP jest tylko generator zegara 26MHz (nie ma osobnej pamięci na SPI gdyż to jest ESP8285 z wbudowanym Flash):
Wnętrze ściemniacza - płytka z zasilaczem i triakiem
Na tej płytce są przede wszystkim układy na napięcie sieciowe:
Rezystor bezpiecznikowy, mostek prostowniczy MB6S, dość ciekawe podłączenie ścieżek z rezystorami i dioda prostownicza:
Wejście też ochrania warystor:
Warystor 05d471k, specyfikacja:
Nie widzę tu żadnych filtrów, czy ten włącznik nie sieje zakłóceń?
Kondensator 4.7uF 400V:
Ta dioda F7 to chyba część układu snubbera (gasika) szpil od zasilacza. Sam układ kontrolujący zasilacz (wraz z wbudowanym tranzystorem, gdyż to flyback) jest pod transformatorem:
Jest też transoptor PC817 (lecz on nie jest częścią układu zasilacza, lecz jest potrzebny do kontroli ściemniania):
I po drugiej stronie jest triak wraz z jego sterownikiem.
MOC3021 produkcji Fairchild:
I sam triak, BT136S-600E:
Skoro już tu jesteśmy, to możemy zajrzeć do noty katalogowej MOC3021 i wyjaśnić jego podłączenie do BT136S.
Dodatkowo, z AN-780A:
Rezystor o wartości 360 omów (2W) ochrania tu optotriak przed dużym prądem w momencie włączenia. Rezystor 470 omów (2W) oraz kondensator 0.05uF (tutaj: 0.047uF MKP X2 275V) redukuje zakłócenia dla MOC3021.
Podmienione kondensatory? Pomiary napięcia
Już na tym etapie mi coś nie pasowało.
Po stronie wtórnej są kondensatory, kolejno ULR "srebrny" na 6.3V o pojemności 470uF, a dalej jest zwykłe elektrolityczny na 10V, też 470uF.
Czy nie powinno być na odwrót?
Sprawdziłem napięcia na nich:
Rzeczywiście, na tym na 6.3V jest niecałe 4V a za układem o sześciu nóżkach który definitywnie jest LDO lub ew. mini przetwornicą step down jest 3.3V (i kondensator na 10V).
Ale chyba widzę tego uzasadnienie. Seria ULR:
To jest kondensator o niskim ESR, a na wyjściu zasilacza flyback właśnie taki powinien być. Trochę niskie napięcie, ale chyba i tak ten lepszy niż zwykły elektrolityczny który jest dalej. A może jednak chińczyk pomylił miejsca?
Ciąg dalszy teardown - wylutowanie transformatorka
(chronologicznie wykonałem to nieco później, ale niech już ten akapit tu będzie dla przejrzystości...)
Do pełnego zrozumienia (i późniejszego narysowania schematu) brakowało mi jeszcze kilku połączeń, więc zdecydowałem się pozbawić płytkę transformatorka, a potem też kilku innych elementów:
Spód:
Wierzch:
Kontroler przetwornicy to HT2812H.
I tu mamy dziwną sytuacje - bo w sieci są dwa elementy o takiej nazwie (ew. bez H).
Generator tonu od Holteka (to nie ten układ):
I kontroler przetwornicy od Hot Chip (to ten układ):
HT2812H to "high performance primary sensing regulator" (skrótowo: PSR), fraza "primary sensing" oznacza, że bierze sprzężenie ze strony pierwotnej, tutaj z dzielnika rezystorowego z uzwojenia pomocniczego (w przeciwieństwie do brania sprzężenia ze strony wtórnej przez transoptor)
Mamy tu jego przykładową aplikację (warto zwrócić uwagę, że bez transoptora, więc ten transoptor na PCB ma inną rolę):
i nieco bardziej szczegółowo:
Oraz pinout:
Pierwsza próba programowania
Na początku myślałem, że wystarczy wykorzystać pady wolnego miejsca na TYWE3S czy tam ESP12, przylutować tam przewody, UART RX TX i esptool.py zadziała:
Pinout ESP12F (piny zgodne też z TYWE3S):
Samą procedurę programowania omawiałem już kilka razy, m. in. tutaj:
https://www.elektroda.pl/rtvforum/topic3749207.html
Niestety to nie zadziałało. Esptool.py nie był w stanie nawet rozpoznać ESP.
Szybkie sprawdzenie połączeń multimetrem wyjaśniło czemu:
UTF87001 jest połączony z ESP825 poprzez UART i pewnie się też z nim komunikuje. To uniemożliwia programowanie ESP. Trzeba by wylutować UTF87001.
I wylutuję UTF87001 - ale to później.
Teraz pora sprawdzić, co takiego te układy do siebie przesyłają?
Można wykorzystać do tego połączenie które już mam. UART nie daje zasady, że musi być tylko jedno RX dla jednego TX. Można do jednego TX dać dwa RX i po prostu podsłuchiwać w ten sposób komunikację.
Protokół - pakiety UART wysyłane w trakcie naciskania przycisków dotykowych
Zacząłem od sprawdzenia co dzieje się gdy naciskamy przyciski dotykowe. W tej sytuacji dane wysyła UTF87001 a odpowiada mu ESP.
Po kilku próbach odgadłem baud - 19200.
Poniżej zamieszczam zebrane pakiety. Warto podkreślić, że pakiety oddzielone są znakiem ESC (dziesiętnie 27), nie ma tam CR LF:
Naciskanie środkowego przycisku:
Kod: C / C++
(pakiety oddzielone są tylko znakiem ESC, w powyższych przykładach dopisałem przejścia do nowych linii dla czytelności)
Format wygląda jak JSON (bez nawiasów).
Wciśnięcie na dłużej (nawet aż do trybu reset) nic nie zmienia:
Kod: C / C++
Szybkie wciskanie przycisku ściemniacza (aż do oporu aż całkiem będzie ciemno):
Kod: C / C++
Odpowiedzi (to co wysyła ESP):
Kod: C / C++
Protokół - pakiety UART wysyłane w trakcie sterowania przez aplikację mobilną
Pora sprawdzić co dzieje się na UART gdy sterujemy włącznikiem przez eWeLink.
W tej sytuacji wymianę danych inicjuje ESP. ESP wysyła do UTF następujące dane.
Gdy włączamy/wyłączamy lampę:
Kod: C / C++
Gdy zmieniamy jasność:
Kod: C / C++
Tuż po włączeniu zasilania:
Wynika z tego, że najwidoczniej ESP tylko pośredniczy w komunikacji a ten dziwny mikrokontroler zajmuje się i przyciskami i regulacją jasności.
Tu jeszcze wypada wyjaśnić czym jest tajemnicze 1623604401.
Ja jak widzę już "1623" to wiem od razu o co chodzi.
To jest bieżący czas zakodowany w postaci ilości sekund które upłynęły od początku 1970 roku. To tzw. czas epoch, unixowy, POSIX.
źródło: https://www.epochconverter.com/
Tyle informacji mi starczy.
Wgrywanie wsadu ESP
Pora odlutować UTF87001, zwolnić tym samym linie UART i zaprogramować ESP.
Użyłem do tego taniego GJ-8018LCD pseudo "hot air" z Chin (ogólnie to on słaby jest, ale jest lekki i przenośny).
Programowanie od razu zaczęło działać. Komenda esptool.py chip_id:
Zgrywanie flash (kopia zapasowa flash):
esptool.py read_flash 0x0 0x100000 20210613_qtouch_dimmer_flash_1M.bin
Wgrywanie flash.
esptool.py write_flash 0x0 tasmota-scripting.bin
(wybrałem Tasmota-scripting by zostawić sobie możliwość potestowania ich systemu skryptów):
Tasmota wgrana, pora potestować włącznik z Tasmotą.
Po wgraniu wsadu
Pierwsze co zobaczyłem po wgraniu wsadu i skonfigurowaniu WiFi dla Tasmoty to to, że o dziwo już domyślne ustawienie działało dla przycisku i diody LED (tej diody LED co miga szybko gdy jesteśmy w trybie parowania):
Takie jak tutaj:
https://tasmota.github.io/docs/devices/Sonoff-Basic/
Czyli taka konfiguracja:
GPIO0 to jest przycisk a GPIO13 to jest LED.
A drugie co odkryłem to to, że przyciski od ściemniania (te po bokach) wciąż świecą na czerwono a po naciśnięciu świecą na niebiesko, czyli w ich obsłudze nie bierze udziału ESP.
Postanowiłem sprawdzić wszystko z żarówką (po odłączeniu komputera):
Szybko okazało się, że nawet po wgraniu Tasmoty na ESP dalej działa:
- sterowanie jasnością żarówki (gdy jest zapalona)
- włączanie i wyłączanie żarówki środkowym przyciskiem
To potwierdza, ze te dwie operacje są wykonywane w pełni przez układ UTF.
Natomiast ESP tylko steruje diodą LED od przycisku środkowego oraz też może odczytywać jego stan, ale nie może sterować bezpośrednio żarówką.
Czyli przycisk środkowy jest podłączony zarówno do UTF jak i do ESP
(i to logiczne, bo ESP potrzebuje go by wykryć tryb parowania, a UTF by włączać/wyłączać żarówkę).
Próba kontroli z portu szeregowego z poziomu konsoli Tasmoty
Teraz przydałoby się wykorzystać zebraną wiedzę w praktyce i spróbować posterować układem UTF87001 poprzez ESP.
Tasmota wspiera tzw. Serial Bridge:
https://tasmota.github.io/docs/Commands/#serial-bridge
Obsługuje się go z poziomu konsoli Tasmoty.
W teorii wystarczy wpisać:
seriallog 0
Baudrate 19200
SerialDelimiter 27
I to powinno starczyć do obsługi UART, potem wysyła się komendą SerialSend (lub jej wersjami - są osobne dla hex, itp).
Dodatkowo komenda:
SetOption22
powinna zwracać "On".
Niestety u mnie to nie chciało to za pierwszym razem działać. Musiałem kilkukrotnie włączać i wyłączać seriallog by UART zaczęło odbierać:
Widać, że Tasmota odbiera od UTF87001 komendy AT+UPDATE (pojawiają się zdarzenia Serial Received), zarówno jasności jak i switcha.
Teraz można by z poziomu Tasmoty wysyłać komendy do UTF87001 ale niestety wymagałoby to raczej już implementacji obsługi tego w języku C, albo ewentualnie w tym prostym języku skryptowym Tasmoty...
Potwierdzenie działania protokołu
Tasmota nie wspiera natywnie tego protokołu komunikacji z UTF87001, więc postanowiłem sprawdzić tylko jeszcze jego działanie na Arduino. UWAGA: Nie powinno się podłączać Arduino UNO bezpośrednio do ESP gdyż Arduino ma poziomy logiczne 5V, a ESP 3.3V i nie jest oficjalnie 5V-tolerant. (Chociaż przyznam, że często są opinie, że jednorazowe takie podłączenie nie zaszkodzi).
Arduino będzie zamiast ESP wysyłać komendy do UTF8700.
Przygotowałem więc kod:
Kod: C / C++
I podpiąłem je do włącznika, oczywiście zasilane z powerbanku (nie mojego!):
Sukces!
Na ten moment nie wiem czy te AT+START w ogóle jest potrzebne, może i nie, ale kod powyżej definitywnie działa i pozwala sterować UTF87001 przez UART.
Kilka ciekawostek z oryginalnego wsadu QTouch
Przed wgrywaniem Tasmoty wykonałem kopię zapasową oryginalnego wsadu ESP z tego włącznika. Wsad oczywiście jest w formie binarnej, skompilowany, a do jego dekompilacji trzeba by mieć odpowiednie narzędzia (chociaż myślę, że w innym temacie może mi się uda to przedstawić), ale mimo to można spróbować go przejrzeć nawet w notatniku w poszukiwaniu stałych tekstowych które są dla nas czytelne.
Przykładowo:
error HTTP/1.1 101 Switching Protocols action params reason config hb hbInterval regInterval IP port cmd upgrade redirect notify sledOnline off GET /api/ws HTTP/1.1
Host: iotgo.iteadstudio.com
Connection: upgrade
Upgrade: websocket
Sec-WebSocket-Key: ITEADTmobiM0x1DabcEsnw==
Sec-WebSocket-Version: 13
Invalid owner uuid iotgo_tree_register iotgo_tree_date AT+SEND=fail AT+SEND=ok version romVersion model ts GET /device HTTP/1.1 POST /ap HTTP/1.1 { } ssid password serverName id_to_app %d HTTP/1.1 200 OK
Content-Type: application/json
Connection: keep-alive
Content-Length: {"error":0} {"error":400,"reason":"timeout"} {"error":401,"reason":"Wrong password"} {"error":402,"reason":"No AP found"} {"error":403,"reason":"Connect failed"} {"error":404,"reason":"Unknown exception"} accept post " tţ?%02x OK
Powyżej widzimy strzępy zapytań HTTP wysyłanych do/przez API. W tym ciekawy URL iotgo.iteadstudio.com.
Swoją drogą, te ITEADTmobiM0x1DabcEsnw można wpisać w Google i otrzymać:
https://github.com/vponomarev/Sonoff-Server/blob/master/doc/ServerExchange.log.txt
AT+SIGNAL= AT+CONF_LIST= , ERROR
AT+START
AT+DEVID?
AT+DEVID= AT+DEVMAC?
MAC: - AT+VER
FWTRX-TA85 AT+SHA256
OK
AT+GPIO_LOW
AT+GPIO_HIGH
AT+WIFI
AT+END
AT+SEND= >
LENGTH ERROR
AT+READ_CONF= AT+TRANSSEND= AT+FWVER?
AT+FWVER= ITEAD_PD_T 27955416 AT+CWJAP= AT+GPIO_IN= AT+GPIO_OUT= AT+GPIO_READ= AT+GPIO_LOW= AT+GPIO_HIGH= AT+SETBAUD= AT+TRANSREV_ON AT+TRANSREV_OFF enabled type do startDo endDo once repeat duration * factory! factory? factory?
Powyżej widzimy komendy wsadu AT który ten ESP oryginalnie ma wgrany.
A tu powyżej widzimy (ocenzurowane!) hasło i SSID mojej sieci WiFi, zapisane oczywiście jako plaintext, czyli zwykły tekst, bez żadnej próby zamaskowania.
Mogliby chociaż zrobić prosty XOR na tym łańcuchu znaków by go zamaskować przed najprostszym wyszukaniem, ale jak widać uznali to za zbędne.
Z tego też powodu nie opublikuję tu tego wsadu. Czytający też powinni mieć świadomość, że wyrzucając urządzenie Smart mogą nieświadomie upubliczniać hasło swojego WiFi...
Schemat ściemniacza QTouch
Na koniec pora zebrać jest wszystkie zdobyte informacje w jedno miejsce i przedstawić szkic schematu produktu.
Schemat nie jest pełny, narysowałem tyle ile potrzebowałem do zrozumienia działania produktu.
Wartości rezystorów na schemacie są podawane w kodach SMD, czyli 472 oznacza 4.7kΩ (chyba, że napisano inaczej)
Płytka z ESP (schemat po korekcie 2021-06-22):
Wyjaśnienia roli elementów.
Zabezpieczenia wejścia:
- mamy tu warystor RS (nazwa z płytki)
- i rezystor bezpiecznikowy R0
- innych filtrów brak
Blok zasilacza:
- MB6S, wiadomo, mostek prostowniczy
- między mostkiem prostowniczym a kondensatorem elektrolitycznym C1 jest dodatkowo dioda prostownicza D4, nie bez powodu, to dla transoptora (o tym zaraz)
- zasilacz zrealizowany jest na HT2812H w topologii flyback
- R8 o wartości niecałe 5 omów to bocznik, na nim HT2812H wykonuje pomiar prądu (pin CS - Current Sense)
- R21 i R10 o kodach 472 (4.7k omów) tworzą dzielnik rezystorowy, do sprzężenia zwrotnego, HT2812H mierzy na nim napięcie na uzwojeniu pomocniczym poprzez pin FB (Feedback)
- dioda szybka F7 doładowuje C5 z uzwojenia pomocniczego, kondensator zasilający HT2812H poprzez jego pin VCC
- na starcie pracy układu C5 ładowany jest bezpośrednio z 325V poprzez R12 i R11 (kody smd 155, czyli 1.5M omów)
- D1 szybka i R7 stanowią snubber (gasik) szpil na uzwojeniu pierwotnym
Blok transoptora:
- transoptor potrzebny jest by mikrokontroler wiedział kiedy narasta wyprostowana sinusoida (by móc na bazie tego regulować jasność i włączać triak), nie jest potrzebny dla zasilacza (bo z reguły jak ktoś widzi transoptor to myśli, że to zasilacz regulacje napięcia bierze ze strony wtórnej)
- Dioda D4 jest za mostkiem Greatza dlatego, by prąd z kondensatora elektrolitycznego nie "cofał" się, bo na transoptor chcemy by szła sinusoida (a właściwie jej połówki już wyprostowane mostkiem)
- transoptor podaje sygnał do pinu AIN0 od UTF87001 na drugiej płytce
Blok triaka:
- triak to BT136S, sterowany jest przez MOC3021, optotriaka, on zapewnia też izolację
- duży rezystor 2W, 470 omów ochrania tu optotriak przed dużym prądem w momencie włączenia (szczegóły w AN780)
- duży rezystor 2W, 360 omów oraz kondensator C3 MKP X2 przy triaku pełnią rolę snubbera, schemat jest zgodnie z notą katalogową MOC3021
- MOC3021 sterowany jest poprzez tranzystor 3904 znajdujący się na drugiej płytce, przez UTF87001
Blok ESP/mikrokontroler (na schemacie przedstawiony szczątkowo)
- ESP8285 wraz z osprzętem (na schemacie pominięty) i antenką na PCB ze ścieżki
- UTF87001 obsługuje ściemnianie, włączanie, wyłączanie, komunikuje się z ESP po UART
- HD6001 obsługuje przyciski dotykowe
- ESP8285 jedynie odczytuje stan głównego przycisku by móc wejść w stan RESET, kontroluje tylko diodę informującą o stanie parowania i komunikuje sie z UTF87001 przez UART
- środkowy przycisk dotykowy jest współdzielony przez ESP i UTF, oba układy odczytują jego stan
- na płytce nie ma układu odpowiedzialnego za RF433 (nie ma nawet na niego miejsca), nie ma antenki PCB od RF433, nie ma buzzera od RF433, RF433 definitywnie nie jest wspierane
Podsumowanie
Takiego zamieszania i dezinformacji nie spotkałem jeszcze w przypadku produktów Smart, choć wiele ich z Chin zamawiałem.
Co prawda ten produkt tutaj był od polskiego sprzedawcy, ale wiadomo, że i tak "made in china".
Produkt QBP.DIM.WIFI przyszedł do mnie w pudełku sugerującym, iż wspiera on pilot RF433MHz, a w rzeczywistości wcale go nie wspierał (można to stwierdzić po braku antenki od RF, po braku buzzera od sygnału parowania RF i po braku układu scalonego co może wspierać RF).
Instrukcja w środku przedstawiała z kolei podłączenie innego włącznika (innego włącznika; tego co się wpina w przewód L i nie trzeba podprowadzić N; do tego stąd trzeba podpiąć oba przewody).
W opakowaniu też był kondensator (zwany "adapterem") który tu nie jest niezbędny i też wprowadza w błąd.
Sprzedawca i opis z oferty dodatkowo sugerował, że włącznik ten stosuje się za transformatorem (?!) na niskim napięciu, a nie na napięcie sieciowe, co też nie było prawdą.
Sam włącznik też pewnie nieźle szumi w sieci (komentarze innych kupujących potwierdzają), nie ma żadnych filtrów na wejściu, dobrze, że chociaż rezystor bezpiecznikowy i warystor dali.
Sama budowa tego włącznika jest dość ciekawa, ale bardzo nieprzyjazna względem DIY/Tasmoty/Home Assistant, bo ciężko jest wgrać nowy wsad na ESP (trzeba odlutować inny układ) a samo wgranie tego wsadu nam dużo nie da, bo by posterować czymkolwiek trzeba by implementować komendy UART...
A szkoda, bo estetycznie ten włącznik mi się podoba.
PS: Możliwe, że spróbuję dalej pociągnąć projekt i dodać wsparcie tego włącznika do Tasmoty, może się uda to zrobić w pełni przez jej skrypty, ale to dopiero zobaczę.
W załącznikach daję noty katalogowe elementów ze środka oraz dodatkowo noty kilku podobnych kontrolerów przetwornic PSR.
Fajne? Ranking DIY Pomogłem? Kup mi kawę.
