Taśma świetlna FEIT Smart WiFi — model: FETAPE/RGBW/CNTRSC — FCC ID: SYW-TAPRGBW

Oby tak dalej i powodzenia, takiego urządzenia jeszcze nie widziałem, więc na pewno będzie ciekawie! Pomogę ci, gdy będzie to potrzebne, a także, jeśli masz 2 MB zrzutu flash (kopia zapasowa), opublikuj go tutaj. Wtedy w najgorszym przypadku zawsze możesz przywrócić ustawienia fabryczne.

Niestety udało mi się uszkodzić nakładkę diagnostyczną RX1. Będę musiał zamocować sondę na chipie dla RX1 - czy pinouty są takie same dla 7231N i 7231T? Znalazłem kilka schematów pinout na stronie oznaczonej 7231T.

Mój to 32-pinowy układ QFN 4x4.

Pinouty są takie same.
Arkusz danych BK7231, pinout, programowanie, specyfikacja, wiki (BK7231T, BK7231N)

Niestety nie chce ze mną rozmawiać w obwodzie:



Zamiast próbować modyfikować cokolwiek na tej płycie, myślę, że łatwiej będzie po prostu usunąć chip.

Nie używają płyty rozszerzeń dla tego urządzenia, a jest to paskudny mały chip – QFN 4x4 32 – więc zamówiłem niektóre z nich z Amazon:

https://www.amazon.com/dp/B0B75V1DFP?ref_=cm_sw_r_apin_dp_DVBYW4H7SQENGG29KR9V

Myślę, że będę miał okazję wypróbować mój system gorącego powietrza na jakiejś rzeczywistej pracy SMD, a nie tylko termokurczliwej. :)

Życz mi szczęścia.

Myślę, że możesz przylutować do tych dwóch punktów:

Czy RX1/TX1 jest używany do czegoś innego w tym systemie? Jeśli nie, to flashowanie powinno działać.

Usunięcie chipa najprawdopodobniej nie zadziała, ponieważ może wymagać do działania podstawowych obwodów zewnętrznych, takich jak oscylator kwarcowy.

Użyłem tego przelotowego otworu na podkładkę RX1, którą wyciągnąłem. TX1 jest ok. Może najpierw wypróbuję kilka innych rzeczy:

1: Użyłem pinu zasilania 3,3 V z Pi. Mogę spróbować z zewnętrznym zasilaniem.
2: Wydaje mi się, że poprawnie skonfigurowałem Pi, aby używać HW UART, ale nigdy nie testowałem, czy działa na czymkolwiek innym. Mogę wypróbować inne urządzenie niż Pi, może Windows i USB UART.

Czy używasz metody resetowania CSN/CEN, czy tylko metody resetowania cyklu wyłączania/włączania?

Mam chwilowy przycisk, który zwiera CEN do GND.

Czy jest jakiś powód, aby nie zasilać płyty z własnego zasilacza 24 VDC i zapomnieć o próbie zasilania przez pad VDD? To nie jest urządzenie podłączone do sieci.

Jeśli zasilacz 24 V DC zapewnia galwaniczną izolację od sieci, można go użyć. Właściwie zastosowaliśmy to podejście podczas flashowania taśmy LED BL602, zastosowaliśmy zasilanie 12V DC:

Mam to!

Okazuje się, że używałem niewłaściwego adresu portu szeregowego na Pi. Tak.

CRC nie pasuje, ale myślę, że jest to oczekiwane podczas zrzucania całego obrazu, prawda?




Nadal nie ma radości.

Obwód otrzymuje niezłe 3,3 V z pokładowego zasilania.
TX1 jest podłączony do RXD0 na Pi.
RX1 jest podłączony do TXD0 na Pi.
GND jest podłączony do GND.
CEN jest otwarty, dopóki nie nacisnę przycisku, aby go obniżyć.
VDD nie jest podłączony - ale czytam na nim 3.19v.

Wyłączyłem wejście/wyjście konsoli Pi do pinów szeregowych.
Mam Pi z uruchomionym dtoverlay = pi3-miniuart-bt, który powinien przekazać sprzętowe UART do pinów TXD0 i RXD0 i przekazać oprogramowanie UART do Bluetooth.

Oto, co wysyłam programowi uart:

Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka

pi@Pi3b31:~/hid_download_py $ uartprogram FEIT-LED-Strip-7231N-1_0_9.bin -d /dev/serial1 -r -s 0x0 -l 0x200000

Próbowałem -b 115200, a nawet -b 9600 ...

Jakieś inne sugestie?

Dodano po 1 [godzinach] 26 [minutach]:

Dobra - więc teraz zabawna część. Ustalenie przypisań pinów do wszystkiego.

To jest RGBW - czyli 4 kanały PWN.
Istnieje również chwilowy przycisk używany przez Tuya FW do przełączania świateł za pomocą dotknięcia i przytrzymania, aby przyciemnić lub przytrzymać, gdy jest wyłączony, aby przejść do trybu parowania.
Do urządzenia dołączony jest również pilot Bluetooth, za pomocą którego można nim sterować ręcznie.

Jakieś porady, jak zacząć próbować to wszystko zrozumieć?

Hmm dla PWM, istnieje ograniczona liczba opcji, jest łącznie 6 pinów PWM, więc możesz nawet spróbować zgadywać. Z przyciskiem jest trudniej. Może spróbuj po śladach na płytce, podlinkowałem pinout BK7231 kilka postów wyżej. W ten sposób możesz to zrobić bez zgadywania.

W przypadku przycisku możesz użyć naszej roli SmartLEDButton. Zobacz ten film:

(oczywiście nie musisz wlutowywać guzika jeśli Twoja listwa już taki posiada)

Teraz wszystko działa (oprócz pilota bezprzewodowego):

Wygląda na to, że muszę używać natywnego interfejsu zamiast aplikacji internetowej dla tego urządzenia, ponieważ jest to RGBW (ciepła biel).
Wygląda na to, że potrzebuje flagi 24, aby działać poprawnie.
Przycisk „inteligentny” jest na pinie 26.

Tak więc prawidłowe piny z ustawioną flagą 24 to:



Aplikacja internetowa jest zdezorientowana przez pominięcie kanału, a strona stanu zawiera złe informacje:



0:0 rola PWM-Cool White (która w rzeczywistości jest czerwona)
Rola 1:0 PWM-Green (co jest poprawne)
Rola 2:0 PWM-Blue (co jest poprawne)
Rola 4:0 PWM (która w rzeczywistości jest ciepłą bielą)

Jednak w natywnym interfejsie wszystko działa świetnie!

Dodano po 1 [godzinach] 23 [minutach]:

>>20474622
Poczyniłem duże postępy i zaktualizowałem główny post - ale nie wszystko jest jeszcze w 100%:


Pytanie: Czy istnieje sposób ustawienia zakresu temperatur dla funkcji temperatury barwowej? Pin PWM6 to ciepła biała dioda LED 2700K - ale natywny interfejs zakłada, że jest to 2000K.

Kolejne pytanie: YAML HomeAssistant wygenerowany dla tego światła wydaje się dziwny - eksponuje go jako 4 oddzielne światła, a nie pojedyncze światło zmieniające kolor:


W przypadku moich żarówek FEIT RGBCW i inteligentnych wtyczek HA dodał je automatycznie, gdy tylko zostały ponownie uruchomione i uruchomiły harmonogramHADiscovery. W przypadku tego paska musiałem ręcznie dodać YAML i pokazuje on 4 jednostki (R, G, B, W.) Jakieś porady tutaj?
(Może obejście: zauważyłem, że jeśli wstawię brakujący CW [kanał 3] na nieużywany pin PWM, to tworzy on prawidłowo pojedynczą żarówkę RGBCW - i wydaje się nawet, że działa z flagą 24 - wszystko w HA również Wydaje się, że może to błąd?)

Masz rację. 4 PWM z emulacją jest tak rzadkie, że nie było obsługiwane w kodzie wykrywania.
Dodałem poprawkę do tego:
https://github.com/openshwprojects/OpenBK7231...mmit/8741e4079997463f3e9a8816f9c33d820333f400
Czy możesz teraz sprawdzić, czy automatyczne wykrywanie HA działa teraz poprawnie, nawet przy 4 PWM?

Kod yaml nie odzwierciedla ostatnich zmian. I tak ludzie używają teraz wykrywania HASS.

Interfejs Web App dla diod LED jest przestarzały, dodam do niego powiadomienie.

Wartość Kelvina w GUI dotyczy tylko kosmetyków, ale mogę dodać opcję ponownego mapowania.

Doskonały! Jutro przetestuję odkrycie 4 PWM.

Mapowanie Kelvina dociera aż do HomeKit przez HA, a HomeKit dba o temperaturę barwową dla rzeczy takich jak oświetlenie adaptacyjne – więc możliwość ustawienia rzeczywistej temperatury byłaby świetna.

Czy istnieje możliwość obsługi danych wejściowych z pilota BT?

Jeśli nie, myślę, że to urządzenie jest już prawie gotowe.

Lokalny występ jest fantastyczny z twoim FW w porównaniu z materiałami Tuya - minęło tylko kilka godzin, ale jak dotąd jestem bardzo zadowolony.

Wydaje się również, że wydajność Wi-Fi jest lepsza niż natywne oprogramowanie układowe.

Nie wiem nic o pilocie BT, czy możesz podać więcej szczegółów technicznych, abyśmy mogli to zbadać? Czy to zewnętrzny chip, czy ma wykorzystywać możliwości Beken Bluetooth?

Jeśli chodzi o Wi-Fi, możesz również wypróbować flagę „szybkiego połączenia” w Flagach.

Jakie jest twoje ostateczne ustawienie flag?

Widzę też, że ustawiłeś Btn_SmartLED, to dobrze, właśnie opublikowaliśmy film na ten temat:

Wonko napisał:

Mapowanie Kelvina dociera aż do HomeKit przez HA, a HomeKit dba o temperaturę barwową dla rzeczy takich jak oświetlenie adaptacyjne – więc możliwość ustawienia rzeczywistej temperatury byłaby świetna.

Dobra, zróbmy to, ale nie wiem zbyt wiele o diodach LED z punktu widzenia oświetlenia adaptacyjnego. Wiem, że używamy standardu Home Assistant:

Wartości Kelvina są zakodowane na stałe:


Zakres 154-500 jest używany wewnętrznie. Zakres Kelvina jest używany tylko do wyświetlania.
Czy chcesz, aby polecenie zmieniało led_temperature_min i led_temperature_max, czy tylko wyświetlaną?

Myślę, że właściwym rozwiązaniem byłaby zmiana wewnętrznego zakresu 154-500, a następnie wykonanie lepszego (nie zakodowanego na stałe) obliczenia Kelvina, ale znowu nie mam wiedzy na ten temat.

Sposób, w jaki działa w Homekit, polega na tym, że istnieje absolutna wartość min/max. 154-500 są w Mired, które można łatwo przeliczyć na kelwiny. Przeliczasz tam iz powrotem między Mired i Kelvin, dzieląc 1M przez drugą wartość. Więc 154-500 to systemowe min/max. (Oczywiście kierunki ciepło/zimno są odwrócone - w Kevinie cieplej jest niżej, w Mired chłodniej).

Każda żarówka CT ma również min/max. W przypadku tego paska sprzętowe min/max to 2700K - czyli 370,37 Mired.

Tak więc w Homekit samo akcesorium ma min/max, które mieści się w systemie min/max. (HA robi to samo.)

Dzięki wbudowanemu mieszaniu kolorów RGB efektywny zakres zwiększa się z 2700-2700 do 2700-???? Ze względu na możliwość dodawania fałszywych chłodniejszych kolorów za pomocą RGB.

W każdym razie - jest to zakres. Nie znam odpowiedniego protokołu do zdefiniowania zakresu akcesoriów CT - ale prawie na pewno istnieje sposób, aby to określić. W naszym przypadku paska LED limit ciepła wynosi 370,37 (2700 K), a limit chłodzenia jest zdefiniowany przez algorytm mieszania FW CT RGB, ale tylko z włączoną flagą 24. Bez flagi 24 nasz zakres to pojedyncza wartość: 370,37 (2700K).

Nawiasem mówiąc, z pewnością teoretycznie możliwe jest zmieszanie większej ilości czerwieni z białym światłem po cieplejszej stronie, aby uzyskać prawdziwy zasięg paska do 2000K po ciepłej stronie, jeśli algorytm mieszania kolorów oprogramowania układowego może to zrobić. W tym przypadku chcielibyśmy się upewnić, że „punkt zerowy” miksowania (całkowity brak RGB) przypada dokładnie na 2700K.

Zasadniczo daje nam to kalibrację temperatury barwowej – w teorii mogę ustawić wszystkie światła w pomieszczeniu na określoną temperaturę barwową i wszystkie będą wyglądać tak samo.

Mam nadzieję, że to wszystko ma sens.

Przejście do pilota. Zrobię kilka zdjęć i rozbiorę jedno. Spekuluję, że zapas Tuya FW nasłuchuje na BT dla tego pilota przez cały czas, z wyjątkiem parowania BT. Myślę, że pilot wysyła polecenia BT, które działają za pośrednictwem wbudowanego radia BT kontrolera - bez dodatkowego chipa. Mogę się mylić.

Możliwe, że to nie BT - ale na pewno jakiś rodzaj RF. Mogę spróbować nasłuchiwać RF, próbując sparować pilota z moim Bond Bridge, który może nauczyć się wielu typów zdalnych poleceń RF. Może właśnie do tego służy Pin 24? Coś jak wejście IR?

Zrobię trochę kopania.

Dodano po 1 [godzinach] 22 [minutach]:

>>20475399
Dobra - kilka rzeczy:

1. Poprawka 4 PWM nie działała dla mnie, ale też nie zepsuła niczego nowego. Dodałem komentarze i zrzuty ekranu dotyczące zatwierdzenia w GitHub.

2. Używam następujących flag: 9, 10, 12, 24, 27, 28. Jestem ciekaw korzyści płynących z flagi Fast WiFi connect. Mogę być chętny do przetestowania, jeśli rozumiem, czego szukać. Naprawdę nigdy nie rozłączam urządzeń - więc szybsze ponowne łączenie nie jest czymś, co normalnie bym zauważył. Może trochę więcej wyjaśnień, jak to działa i jak sprawdzić, czy działa, pomogłoby. A mówiąc o WiFi:



Pierwszy obraz to jedno z tych urządzeń z oprogramowaniem układowym Tuya, a drugi to OpenBK. Są tuż obok siebie. Ten z prawej był uaktualnieniem do OpenBK około 14 godzin temu. Zauważ zielony pasek? Tak - twój firmware zachowuje się dużo lepiej w mojej sieci niż Tuya FW. W rzeczywistości moje AP mówią, że „Balans sygnału AP/Client” ze wszystkich 5 pasków OpenBK jest „dobry”, a ta sama wartość dla pozostałych 4 działających Tuya FW jest „słaba”. To oczywiście oznacza, że punkt dostępowy przesyła znacznie silniejszy sygnał niż ten, który słyszy z urządzeń. Ten sam zestaw obrazów jest spójny na wszystkich 9 moich urządzeniach – wszystkie urządzenia OpenBK nie mają już żółtych obszarów wydajności Wi-Fi, a wszystkie urządzenia Tuya mają ten sam niechlujny wzór i słaby balans sygnału. Mam pewną spekulację na ten temat. Wierzę, że Tuya FW nadaje na niższym poziomie mocy - i wierzę, że może to być unikanie oślepiania radia BLE podczas nasłuchiwania pilota. Mogę się mylić co do przyczyny - ale mimo to jest bardzo jasne, że oprogramowanie układowe OpenBK znacznie poprawia wydajność Wi-Fi tych pasków świetlnych. Fantastyczny.

3. Pilot jest rzeczywiście sklasyfikowany jako „BLE Beacon Remote Control”, a szczegóły są tutaj: https://fcc.report/FCC-ID/2AMV5TX227-HF Należy pamiętać, że raport FCC dotyczy poprzedniej wersji urządzenia, ale FEIT otrzymał nowy numer wymieniony pod starym raportem z testu. Moje rzeczywiste urządzenie jest zarejestrowane tutaj: https://fcc.report/FCC-ID/SYW-TAPRGBWREMSC/

Wygląda więc na to, że Tuya FW nasłuchuje tego pilota za pomocą radia BLE. Jestem pewien, że to prawdopodobnie sporo pracy do rozważenia dla twojego oprogramowania układowego, ponieważ BLE to cały dodatkowy zestaw bibliotek i protokołów i tak dalej o ograniczonej wartości - ale istnieje potwierdzenie, że przynajmniej to jedno urządzenie rzeczywiście korzysta i zewnętrzne Beacon BLE jako pilot i nie tylko do "szybkiego" parowania.

Zajrzę do tych jednostek temperatury dzisiaj lub jutro, najprawdopodobniej dodam do tego polecenie, może CTRange , ale pozwól, że najpierw odpowiem na twoje pytanie:

Wonko napisał:

1. Poprawka 4 PWM nie działała dla mnie, ale też nie zepsuła niczego nowego. Dodałem komentarze i zrzuty ekranu dotyczące zatwierdzenia w GitHub.

Czy jesteś pewien, że to nie naprawiło automatycznego wykrywania Hass? Pamiętaj, że podgląd YAML to inny, przestarzały system. Podgląd YAML nie zmieni się, nadal będzie niepoprawny, ale spodziewałbym się, że prawdziwe wykrywanie HASS doda teraz poprawnie 4 urządzenia PWM z flagą „symuluj białą”.

Cytat:

(Warto zauważyć, że mam skonfigurowaną Btn_SmartLED na P26 - więc nie wiem, czy to wyrzuca pwmCount.)

Nie powinno to mieć wpływu na nic.

Czy możesz ponownie sprawdzić lub potwierdzić, że rzeczywiście odnosisz się do wykrywania HASS, a nie do przestarzałego generatora Yaml, który jest (powtarzam) oddzielnym systemem?

Ahh. Widzę. Nie zdawałem sobie sprawy, że generator YAML jest przestarzały. Myślałem, że to strona stanu aplikacji sieci Web jest nieaktualna.

Szybki test pokazuje, że rzeczywiście jest wykrywalny przez HA z 4 PWM w nowej wersji.

Strona stanu aplikacji sieci Web jest przestarzała i pokazuje surowe wartości PWM. Dodam informacje na ten temat lub ukryję.

Generator YAML działa w większości przypadków, ale jest niezależny od wykrywania HA, co wkrótce naprawię.

Okej, więc... Nadal nie jestem pewien, jak poradzić sobie z problemem Kelvina, ale dodałem do tego małe polecenie:
https://github.com/openshwprojects/OpenBK7231...mmit/d47aae3f99d8ec3b3d7ff4e238bbbf4ef415ced0
Później zmieniłem też jego nazwę:
https://github.com/openshwprojects/OpenBK7231...mmit/8968872ad0f026264c648a4ccb85901afb38b209

Wartości domyślne to:

Teraz aktualna wersja pozwala na ich zmianę i nadal będzie poprawnie wyświetlać odpowiednik Kelvina.

Ale myślę, że jest z tym problem!
Jeśli twój Home Assistant nadal ma ustawioną minimalną temperaturę na 154, a ustawisz ją na swoim urządzeniu na 250, to suwak na Home Assistant nie zejdzie poniżej 250. Może to wyglądać dziwnie/zepsuty… ale ja jestem nie jestem pewien, jeszcze nie testowałem.

@Wonko, co o tym sądzisz? Czy CTRange jest dla Ciebie wystarczająco dobrym rozwiązaniem, czy mogę zrobić coś innego lepszego?

HA Modyfikuje suwak, aby działał z zasięgiem światła (lub największym zasięgiem w grupie i blokuje światła z mniejszymi zasięgami). Więc jeśli jest ustawiony w profilu, powinien po prostu działać.

Oto stan YAML dla 2 różnych świateł o różnych zakresach. Pierwsza to przestrajalna biała żarówka Hue. Drugi to pasek LED Meross RGBCW:





Widzisz więc, że te zakresy można konfigurować według urządzenia.

Więc teraz powinienem uwzględnić bieżące ustawienie maksymalne i minimalne w kodzie wykrywania HASS, aby HA mógł wiedzieć, jaki jest zasięg każdego urządzenia?

Tak, uważam, że tak to powinno działać. Gdzieś w schemacie MQTT powinny być wartości zakresu temperatury barwowej. Jeśli nie określisz, z pewnością używa maksymalnego zakresu systemu.

Dodano po 13 [minutach]:

>>20477411
Wygląda na to, że wszystko jest zdefiniowane tutaj:

https://www.home-assistant.io/integrations/light.mqtt/

Więc w tej sekcji dodaj te I wartości pól z nowych poleceń i to powinno załatwić sprawę.

https://github.com/openshwprojects/OpenBK7231...6131a73f839c4/src/httpserver/hass.c#L274-L279

>>20477411
Cześć, widziałem zatwierdzenie polecenia LEDRange - czy to działa teraz, aby ustawić zakres temperatur dla żarówki?

Próbowałem polecenia uruchamiania:

harmonogram zaległościHADiscovery 10; LEDZasięg 154 370

ale działa tak, jakby to było nieznane polecenie:

Błąd: CMD: cmd LEDRange NIE znaleziono (argumenty 154 370)

Och, przepraszam, wygląda na to, że pracuję za dużo. Byłam pewna, że już Ci o tym pisałam.

Tak, istnieje polecenie CTRange (było to LEDRange, ale zmieniłem jego nazwę), które powinno działać, a składnia jest następująca:

powinien automatycznie aktualizować Kelviny w GUI, sprawdź, czy to działa poprawnie. Jednak nadal nie uwzględniamy naszego zasięgu mired podczas wykrywania HA, będę musiał to później naprawić.

UWAGA: to polecenie jest tylko kosmetyczne, nie wpływa na wydajność sprzętową żarówki.

To wyjaśnia to!

Lol, myślałem, że zwariowałem - spojrzałem na kod w zatwierdzeniu 570 i nie mogłem zrozumieć, dlaczego to nie działa.

Tak, działa pięknie - tylko jeden mały nit: Wygląda na to, że zaokrągla wartość mired float do liczby całkowitej. Jeśli ustawię zakres jako 153 370,37, nadal pokazuje 2707 jako niską wartość.

Nie jest to wielka sprawa - pamiętaj tylko, że cały zakres Mired jest dość mały w porównaniu z zakresem Kelvina - więc zachowanie kilku cyfr precyzji pływaka nie jest złym pomysłem.

Zachowanie w HA w ten sposób nie jest okropne - po prostu nie robi nic z żarówką, jeśli przeciągniesz suwak poniżej 2702.

Dziękujemy za dodanie tej funkcji!

Hmmm to rzeczywiście liczba całkowita, przyjrzę się możliwości przekonwertowania jej na liczbę zmiennoprzecinkową.

Odnośnie zakresu Home Assistant Discovery:
https://www.home-assistant.io/integrations/light.mqtt/

Wydaje się, że teraz powinienem dołączyć pola min_mireds i max_mireds?

Tak, uważam, że powinno to wystarczyć!

>>20479539
Witaj, nadal planujesz dodać to do wykrywania HA?
Jeśli jesteś zbyt zajęty, mogę go rozwidlić i utworzyć żądanie ściągnięcia.

@Wonko Jeszcze nie zacząłem, jeśli wiesz, jak to zrobić, zrób to, ale powinno to być bardzo, bardzo łatwe. Tylko w kodzie wykrywania CW dodaj dwie linie, aby wydrukować poprawny klucz i podłącz zmienną globalną „led_temperature_min” do printf ...

Daj mi znać, jeśli sobie z tym poradzisz, a wtedy z przyjemnością połączę Twoje żądanie ściągnięcia. Jeśli nie, mam nadzieję, że zrobię to sam w najbliższych dniach.

Mamy pracowite dni. dzisiaj mamy nadzieję, że będziemy mieć Tasmota Device Groups dla przełącznika ściennego i wideo z konfiguracją wielu żarówek.