Ostatnio natknąłem się na ciekawe urządzenie TuyaMCU, które nie wysyłało wszystkich dpID, mimo że ustawiłem stan WiFi 0x04 w autoexec.bat. Śledzenie komunikacji przechwyconej z oryginalnego oprogramowania również nie spowodowało opublikowania dpID. (Dla przypomnienia dpID są to numeryczne identyfikatory przypisane do konkretnych funkcji urządzenia, każdy dpID odpowiada za konkretną funkcjonalność (np. włącznik, jasność, temperatura)). Nie odpowiadał nawet na zapytania o stan TuyaMCU! Okazało się, że przyczyna była zupełnie nieoczekiwana, więc postanowiłem ją tutaj udokumentować. Mam nadzieję, że pomoże to większej liczbie osób uzyskać urządzenie wolne od chmury.
Podstawowa lektura
Ten temat jest rozszerzeniem poprzednich tematów dotyczących protokołu TuyaMCU, więc założę tutaj, że czytelnik jest zaznajomiony z podstawami:
Protokół TuyaMCU - komunikacja pomiędzy mikrokontrolerem a modułem WiFi
TuyaMCU flashing, setup and configuration guide - konfiguracja dpID dla Home Assistant
Analizator TuyaMCU - dekoder pakietów UART dla urządzeń Tuya - detektor dpID
Wyodrębnianie DpID dla urządzeń TUYA MCU
Jak uzyskać listę typów i wartości dpID dla sflashowanych urządzeń TuyaMCU z OpenBeken
Urządzenie użyte do demonstracji
Poniższa demonstracja opiera się na Tuya DIN 4P 1-63A, który został mi podarowany przez czytelnika. Tutaj jednak skupię się tylko na formacie Raw z pakietów TuyaMCU, pełny teardown zostanie opublikowany osobno.
Poniższy problem występuje również na MGF-T3-SMART, który również został mi podesłany przez innego czytelnika:
Dziękuję za podesłanie tych urządzeń i pomoc w ich odkryciu!
REKLAMA
Przechwytywanie komunikacji początkowej
Na początku zdecydowałem się użyć mojego analizatora TuyaMCU , aby wykonać podstawowe przechwytywanie komunikacji między MCU a modułem WiFi:
.
Pierwszą interesującą rzeczą jest to, że pakiet WiFi state nie jest w ogóle wysyłany! Dzieje się tak, ponieważ to urządzenie używa czegoś o nazwie Przetwarzanie przez moduł Wi-Fi , na co wskazuje obecność ładunku pakietu 0x02 (MCUConf).
Cytat:
Przetwarzanie przez moduł Wi-Fi - piny GPIO modułu Wi-Fi zmieniają stan wskaźnika Wi-Fi (wskaźnik LED). Moduł Wi-Fi jest resetowany w oparciu o wejścia GPIO.
W trybie przetwarzania przez moduł Wi-Fi, moduł Wi-Fi wyzwala reset, gdy wykryje, że wejście GPIO jest na niskim poziomie przez ponad 5 sekund. Piny GPIO używane przez wskaźnik Wi-Fi i przycisk resetowania Wi-Fi są konfigurowane za pomocą słowa komendy 0x02.
Ładunek komendy to 0807, co oznacza, że P08 to dioda LED WiFi, a także wyjście stanu WiFi dla MCU, a 07 to przycisk parowania...
Uwaga: jeśli pakiet 0x02 (MCUConf) nie ma ładunku, to przetwarzanie jest wykonywane przez MCU i wszystko działa po wyjęciu z pudełka, nie są wymagane żadne dodatkowe piny .
Pierwsza konfiguracja autoexec.bat i wiele problemów .
Sflashowałem moduł WiFi za pomocą OpenBeken, ustawiłem autoexec.bat z podstawowym skryptem i próbowałem nakłonić TuyaMCU do wysyłania większej ilości danych, jednak wszystkie moje próby kończyły się jak na razie niepowodzeniem. Uderzenia serca były odbierane poprawnie (więc UART baud był OK) i byłem w stanie kontrolować główny przekaźnik i uzyskać kilka odczytów, ale nie więcej niż to:
Kod: JSON
Zaloguj się, aby zobaczyć kod
i nie otrzymałem żadnych dalszych dpID...
Próbowałem zwykłego podejścia, 0x04 WiFi state, ale wygląda na to, że wspomniane urządzenie w ogóle go nie używa:
// set TuyaMCU default wifi state 0x04, which means "paired",
// because some TuyaMCU MCUs will not report all data
// unless they think they are connected to cloud
tuyaMcu_defWiFiState 4
ani zapytanie nie odpowiedziało z większą ilością danych:
// every 10 seconds, request update from TuyaMCU
addRepeatingEvent 10 -1 tuyaMcu_sendQueryState
Wszystko do tej pory zawodziło, aż postanowiłem spróbować ustawić pin diody WiFi...
Proste rozwiązanie problemu .
Okazało się, że wspomniany już P08 nie służy tylko do obsługi diody WiFi - ma podłączoną diodę, ale umożliwia też wysyłanie kolejnych dpID. Przetestowałem to za pomocą GPIODoctor:
.
Oznacza to, że MCU jest fizycznie podłączony do tego pinu i odczytuje jego stan...
Więc po ustawieniu jego stanu na AlwaysHigh (lub AlwaysLow , w zależności od urządzenia):
Kod: JSON
Zaloguj się, aby zobaczyć kod
Teraz wygląda na to, że mamy pełny zestaw danych! Właśnie tego potrzebowaliśmy do dalszego przetwarzania.
Podsumowanie
Jeśli urządzenie TuyaMCU zgłasza pakiet MCUConf o niezerowej długości, zgłaszane wartości bajtów to stan WiFi i piny przycisku reset. Pin stanu WiFi jest używany nie tylko do diody LED - jest również używany do umożliwienia wysyłania dalszych identyfikatorów dpID z MCU. Tak więc, aby uzyskać z niego wszystkie wartości, należy ustawić go na AlwaysLow lub AlwaysHigh w ustawieniach OBK. Tylko ten sposób będzie działał dla urządzeń w trybie przetwarzania WiFi, żadne "WiFistate 0x04", ani "odpytywanie stanu" nie będą tutaj działać.
Załączyłem powiązany dokument TuyaMCU w formacie PDF, możesz go sprawdzić, aby uzyskać więcej szczegółów . Co ciekawe, NIE pokazuje, że MCU odczytuje również stan diody LED...
.
Więc chyba nie zadali sobie trudu, aby dobrze udokumentować przypadek, który tu opisałem.
Fajne? Ranking DIY Pomogłem? Kup mi kawę.
