[Rozwiązano] Miganie i konfigurowanie Micro IR Blaster (Ali 1005006823624599) za pomocą BK7231N

Podobnie jak wiele innych, oto mały odbiornik / nadajnik podczerwieni dzięki uprzejmości atc1441 (chociaż ten, o którym pisał, wygląda inaczej).
Kupiłem ten pod koniec 2024 roku, wydaje się, że nadal jest dostępny za 7 USD na Ali, 1005006823624599
Całe urządzenie ma zaledwie 38 mm średnicy i 15 mm grubości.

Ma BK7231N na wspólnej płytce CBU. Cztery diody IR na górze i odbiornik. Niebieska dioda LED stanu i przycisk na spodzie.
Trywialny do flashowania za pomocą urządzenia szeregowego USB, piny są oznaczone pod płytką. Zwykle lutuję do nich przewody o przekroju 30.





Konfiguracja:

>>21573835
Teraz chciałbym prosić o pomoc... powyższy zdalny blaster działa dobrze dla mojego pilota TV, dekodując różne kody. Ale dla mojego pilota AC po prostu nie działa.
Podsumowanie moich frustrujących pytań w tej dyskusji o AI chociaż myślę, że AI śni o kompilacji v1.18.130 i prawdopodobnie kilku innych rzeczach.

Próbowałem włączyć wszystkie flagi IR. Komendy takie jak set IRdebug 1 nie są obsługiwane. Mniej więcej te same komunikaty pojawiają się na MQTT. Wszystkie posty na forum dotyczące IR są dość stare. Byłbym zadowolony z jakiegoś rodzaju przechwytywania RAW - chcę wysłać tylko trzy polecenia dla AC (on-cool-lowfan-16C ; on-fan-lowfan ; off)

Czy bufor (surowy) jest zbyt mały dla tego pilota? Czy istnieje wersja nightly/alpha, która zawiera najnowszy IR, lub czy możesz polecić modyfikację, którą mogę zbudować, która będzie odbierać ten pilot?

Dziękuję!

W wersji v1.18.110 pilot generuje takie kody w dzienniku:
.

Mój autoexec.bat:


Moja konfiguracja:

coś innego w wersji irRemoteESP?

https://github.com/openshwprojects/OpenBK7231....110/OpenBK7231N_QIO_1.18.110_irRemoteESP.bin
https://github.com/openshwprojects/OpenBK7231...1.18.110/OpenBK7231N_1.18.110_irRemoteESP.rbl

Dzięki - to zupełnie co innego.
Teraz dostaję coś za każdym naciśnięciem pilota.

Niestety dane są za każdym razem inne:
info:ir:ir unknown ffffffff,0xf3963672,172
info:ir:ir unknown ffffffff,0x8301fb23,172
info:ir:ir unknown ffffffff,0x928f624f,172
info:ir:ir unknown ffffffff,0xbeb94b2f,172
info:ir:ir unknown ffffffff,0xc21ea93,172
info:ir:ir unknown ffffffff,0xa620bed1,172
info:ir:ir unknown ffffffff,0xc0311423,172
info:ir:ir unknown ffffffff,0xf187fb6b,172
info:ir:ir unknown ffffffff,0x981bd6be,172
info:ir:ir unknown ffffffff,0x5019b230,172
info:ir:ir unknown ffffffff,0xea55b743,172
info:ir:ir unknown ffffffff,0xf561a712,172
info:ir:ir unknown ffffffff,0x9b520955,172
info:ir:ir unknown ffffffff,0x821ba9ff,172

Czasami, gdy sygnał jest silny, dekoduje go jako KELON168, ale wtedy debug nie drukuje zdekodowanego wyniku (zły CRC?).


Info:IR:Odebrany kod AC:KELON168
Debug:IR:Zdarzenie IR fire trwało 0ms
Info:IR:IR Unknown ffffffff,0x6CA9AFD2,172
Info:IR:Odebrany kod AC:KELON168
Debug:IR:Zdarzenie IR fire trwało 0 ms
Info:IR:IR Unknown ffffffff,0x41E59780,172
Info:IR:Odebrany kod AC:KELON168
Debug:IR:Zdarzenie pożaru IR trwało 0 ms
Info:IR:Odebrany kod AC:KELON168
Debug:IR:Zdarzenie pożaru IR trwało 0ms
Info:IR:IR Unknown ffffffff,0x7771B42A,172

Włączając flagę 14, otrzymuję to na MQTT
70,0x83060302000080000000000000810002000008000A
Odpowiada temu w dzienniku:
Info:IR:Odebrany kod AC:KELON168
Info:IR:IR MQTT publish �A zajęło 2 ms
Debug:IR:IR zdarzenie pożaru zajęło 0ms

Czy możesz zasugerować kolejne kroki?

bkespoke napisał:

Czy mógłbyś zasugerować kolejne kroki?

hmm, nie bardzo wiem co dalej. Nie miałem żadnego doświadczenia z wersją irRemoteESP.

Zastanawiam się, czy powersave może mieć na nią wpływ, tak jak w przypadku standardowej wersji ir. Czy masz ustawione powersave 1 ?

Jeszcze raz dzięki. Powersave wydaje się mieć wpływ, ale był wyłączony.

Mam powersave 0 (próbowałem powersave 1, wtedy komunikaty powersave pojawiają się wszędzie w logach, czego wcześniej nie widziałem. Powersave 1 powoduje również, że znany dobry pilot odczytuje śmieci, podczas gdy powersave 0 dekoduje coś przez większość czasu.

Co ciekawe, w dziwnych przypadkach, gdy nie udaje się zdekodować działającego pilota, wartości szesnastkowe są po prostu śmieciami.

Wartości szesnastkowe z mojego pilota AC są zawsze śmieciami, bez wzorca.

Ale pytając o bardzo sporadyczne udane dekodowanie, wszystkie mówią:
Info:IR:Odebrano kod AC:KELON168
dla dowolnego przycisku na pilocie. Podczas gdy z działającym pilotem TV otrzymuję różne kody.
Czy to oznacza, że to tylko przypadkowe dekodowanie?

hmm. nie jestem pewien.
szturchając @p.kaczmarek2 i @DeDaMrAz, którzy moim zdaniem są współautorami wariantu irESP.

od tego postu - trochę kontekstu IR i aktualne znane problemy:
https://www.elektroda.com/rtvforum/topic4093142-300.html#21605592

Udało mi się więc rozwiązać ten problem, przynajmniej w przypadku mojej obecnej aplikacji, przy pomocy diody odbiornika podczerwieni, analizatora logicznego i Gemini AI.
Urządzenie „LG” wykorzystuje płytkę sterującą podczerwienią typu TCL, która wysyła trzy 56-bitowe kody PDM w standardzie NEC, rozdzielone przerwami trwającymi 8 ms.
Bufor Openbeken jest zbyt mały dla tak długiego kodu, dlatego nie mogłem go odebrać. Nie potrafi też wysłać wszystkich trzech kodów pod rząd, ale okazuje się, że tak naprawdę potrzebny jest tylko pierwszy kod!

Oto kilka kodów, które działają w przypadku mojego przenośnego urządzenia marki LG, numer modelu LP0731WSB, numer części pilota DG11J1-99
* Chłodzenie, niska prędkość wentylatora, wartość zadana 16°C: IRSend NEC,48,0xC160C0400000 (urządzenie schodzi tylko do 18°C)
* Chłodzenie, wysoka prędkość wentylatora, temperatura zadana 20°C: IRSend NEC,48,0xC16080440000
* Tylko wentylator, niska prędkość wentylatora: IRSend NEC,48,0xC160C02E0000
* Przełączanie zasilania: IRSend NEC,48,0xC160E0440000
(ostatni kod wyłączy urządzenie, ale jednocześnie włączy je z ustawieniami: chłodzenie, niska prędkość wentylatora, 20 °C, więc aby mieć pewność, że urządzenie zostanie wyłączone, należy wysłać kolejny kod, a następnie kod przełączania zasilania)

Więcej od Gemini:
Kluczowe spostrzeżenia dotyczące działania protokołu klimatyzatora
Bajt 3 (0x80 vs. 0xC0): Przy ustawieniu „Low Fan” bajt 3 miał wartość 0xC0 (11000000). Przy wysokiej prędkości wentylatora zmienił się on na 0x80 (10000000). Potwierdza to, że drugi bit bajtu 3 steruje prędkością wentylatora.
Bajt 4 (0x44 vs. 0x40): W podstawowym poleceniu chłodzenia o wartości 16°C użyto wartości 0x40. Dodanie 2°C w celu uzyskania 18°C spowodowało zwiększenie wartości bajtu 4 o 0x04 ($0\text{x}40 + 0\text{x}04 = 0\text{x}44$). Oznacza to, że prawdopodobnie można matematycznie obliczyć inne temperatury (np. 20°C to 0x48, 22°C to 0x4C itd.). Ta ostatnia część okazuje się błędna, ale bajt 4 faktycznie kontroluje ustawienie temperatury.

W załączniku znajduje się kilka surowych wyników dekodowania.

Udało mi się naprawić klimatyzację.