Różnice między SniffUART a TuyaMcu Analyzer: Ulepszona komunikacja adaptera USB

Na GitHub dostępny jest kolejny program Windows o nazwie „SniffUART”.



Jaka jest różnica w stosunku do TuyaMcu Analyzer?
- usprawnienie komunikacji z szeregowymi adapterami USB.
- wszystkie wiadomości Tuya określone przez Tuya są dekodowane.
- łatwe w utrzymaniu, oznacza, że błędy można łatwo naprawić i dodać dalsze dekodowanie.

Dużo pracy - mam nadzieję, że warto.
Proszę spojrzeć na plik Readme.md na GitHub.
https://github.com/MkMunich/SniffUART

Doceniam twoją opinię.
Z wyrazami szacunku,
MK_Monachium

Dobra robota! Na pewno go wypróbuję, gdy dostanę następne urządzenie TuyaMCU.

Czy dekodujecie również pakiety z datami (kalendarzami)?

p.kaczmarek2 napisał:

Czy dekodujecie również pakiety z datami (kalendarzami)?

Z pewnością. Jeśli te komunikaty są określone w McuSerialPort
https://developer.tuya.com/en/docs/iot/tuya-c...ess-protocol?id=K9hhi0xxtn9cb#QueryServerTime
lub McuLowPower
https://developer.tuya.com/en/docs/iot/tuyacl...iversalsersialaccessprotocol?id=K95afs9h4tjjh

wtedy są już uwzględnione.

Zacząłem od specyfikacji McuHomeKit
https://developer.tuya.com/en/docs/iot/wifi-m...lopment-overview-for-homekit?id=Kaa8fvusmgapc

Czy protokół HomeKit różni się od standardowego TuyaMCU? W jakich urządzeniach jest używany? Nie zagłębiałem się jeszcze w ten protokół.

Na pierwszy rzut oka komunikaty są bardzo podobne. Większość wiadomości wygląda identycznie, ale zauważyłem, że jedna odpowiedź ma inne znaczenie...

Z „nagłówka” specyfikacji Tuya:
„W tym temacie opisano, jak połączyć MCU z modułem Wi-Fi Tuya, który można podłączyć zarówno do platformy Tuya IoT, jak i platformy Apple HomeKit. Po zaimplementowaniu protokołu szeregowego produkt może komunikować się z modułem Wi-Fi Tuya i wchodzić w interakcje z Produkty „Powered by Tuya” i produkty kompatybilne z HomeKit”.

Do tej pory widziałem z przykładów, które zostały przesłane do TuyaMCU Analyzer, było kilka urządzeń korzystających z tego protokołu.

Dodano po 29 [minutach]:

W przypadku, gdy wiadomości są identyczne, deleguję dekodowanie z McuHomeKitMsg do McuSerPortMsg. Ma to tę zaletę, że kod nie jest powielany i widać (wewnątrz kodu źródłowego), że wiadomość jest taka sama.

@mkmunichmk

Dobra robota!!

Postanowiłem to przetestować, ponieważ ja i @p.kaczmarek2 pracujemy nad czymś związanym z TuyaMCU, ale jak dotąd nie mam szczęścia w dekodowaniu wiadomości. Dowolny pomysł?

Ustawiłeś dekoder MCU Low Power?

Przechwytywanie w HEX wygląda na w porządku i możemy je zdekodować za pomocą TuyaMCU Analyzer od @p.kaczmarek2

Wygląda na to, że SniffUART ma problem ze znalezieniem końca wiadomości. Będziesz musiał pobawić się parametrem „Read Timeout” w ustawieniach portu. Ten czas w ms określa odstęp czasowy między komunikatami. Zwykle port szeregowy wysyła wszystkie bajty naraz (używając wewnętrznego 16-bajtowego bufora, jeśli układ). Oczywiście sterownik Windows mógł „dzielić” strumień bajtów, więc pierwszy bajt mógł nadejść natychmiast, a „reszta” z drugim wywołaniem ReadBytes. W tym celu skonfigurowałem minimalną długość wiadomości wynoszącą 2 bajty. Może powinienem zwiększyć tę stałą wartość w kodzie.
Ale najpierw powinieneś spróbować zwiększyć limit czasu odczytu do np. 100 ms.

Jedną ze zmian wprowadzonych w ostatniej chwili było zwiększenie priorytetu wątku. Jeśli możesz skompilować kod źródłowy, możesz to skomentować
w PortHandler.cs w linii ~33
_readThread.Priority = ThreadPriority.Highest;
Może "AboveNormal" by pomogło? Proszę daj mi znać.

Hmm, więc nie buforujesz ich razem? Przyjąłem inne podejście w moim flasherze, możesz sprawdzić mój kod bufora pierścienia, aby uzyskać więcej informacji.

p.kaczmarek2 napisał:

możesz sprawdzić mój kod bufora dzwonka

Chciałem tego uniknąć, ponieważ generalnie wiadomości mogą mieć różne (jak to powiedzieć) struktury. W przeszłości miałem protokół, w którym było (prawie) niemożliwe znalezienie początku i końca wiadomości. Zgadzam się, wiadomości Tuya są bardziej ustrukturyzowane, np. mają 2-bajtowy nagłówek.
Niestety nie mam wielu różnych urządzeń Tuya do testowania. Ale jestem pewien, że znajdziemy rozwiązanie (np. twój bufor pierścieniowy).

Mój ostatni komentarz wydaje się zagubiony Więc znowu:
Zaktualizowałem SniffUART.exe na GitHub (ponieważ nie wiem, czy jesteś w stanie skompilować źródła).

Przywróciłem normalny priorytet wątku i zwiększyłem ReceivedBytesThreshold=75; (Być może jest to wciąż za mało dla wiadomości o długości > 75 bajtów).

Wskazówka dotycząca limitu czasu odczytu: Ten czas nie powinien być zbyt krótki, ponieważ określa „odległość” do następnej wiadomości. Zakładam, że nie może to być szybsze niż 100 ms w urządzeniu Tuya.

Proszę dać mi znać, czy to pomogło.
Z poważaniem, MK_Monachium

Zaraz wypróbuję i zdam relację.

Jedną rzeczą, którą zauważyłem, jest to, że masz tylko 9600 bps, wiesz, że są tam urządzenia 115200 bps?

Tasmota pozwala wybrać między 9600 a 115200 z flagą, w OpenBK możesz określić dowolny rozsądny baud.

SniffUART obsługuje wszystkie (typowe) prędkości transmisji. Wskazówka: możesz również określić różne ustawienia dla każdego portu, ale zwykle ustawiasz flagę Plik->Ustawienia portu->Jeden port.

Ukończyłem McuHomeKitMsg. Tak więc wszystkie znane (mnie) wiadomości Tuya powinny zostać zdekodowane.
Aby zobaczyć, jak wyglądają zdekodowane wiadomości, pobierz SniffUART.exe z GitHub, uruchom go i otwórz menu Plik->Dekoduj okno dialogowe Wiadomości. Następnie wklej przykładowe komunikaty testowe „Test Mcu*.txt” do okna dialogowego i naciśnij „Dekoduj”. Cieszyć się!

Nie miałem wielu wiadomości z prawdziwych urządzeń Tuya. W przypadku, gdy specyfikacja zawierała przykłady, przeniosłem je do „Test Mcu*.txt”. Jeśli nie było podanego przykładu, wymyśliłem własny.
Jakość specyfikacji Tuya jest czasami w porządku, czasami mogłem tylko zgadywać i dekodować tak, jak to rozumiałem. Nie oczekuję, że będzie bezbłędny. Dekodowanie zawiera ~3500 linii kodu...
Skorzystaj z usługi GitHub, aby zgłosić problemy.

Podpowiedź dla @p.kaczmarek2, który pytał o różnice w klasach dekoderów: w miarę możliwości przekierowałem dekodowanie do McuSerPortMsg. Możesz zobaczyć w kodzie źródłowym, gdzie odbywa się dekodowanie. Jedną z głównych różnic jest jednostka danych, która jest zupełnie inna w McuHomeKitMsg.

@mkmunichmk

Czy masz coś przeciwko udostępnieniu tutaj skompilowanego pliku binarnego? Lub stworzyć nową kompilację na GitHub?

Rzeczywista kompilacja znajduje się na GitHub.

Dobra wiadomość: poprawiłem komunikację UART. Koniec wiadomości jest teraz wykrywany przez przekroczenie limitu czasu po odebraniu ostatniego bajtu wiadomości.
Do przetestowania użyłem zasilanego bateryjnie kontaktu drzwiowego Tuya (stara wersja z kontaktronem i TuyaMCU). Nie jestem pewien, czy znalazłem problem...
Ponieważ mój kontaktron Tuya nie jest urządzeniem DS06 i wygląda ze sprzętu bardzo podobnie do https://www.elektroda.com/rtvforum/topic3914412.html#20350672 nie wiem czy zakładać nowy wątek? @p.kaczmarek2 Proszę o radę.

@mkmunichmk, jeśli możesz szczegółowo opisać nowe urządzenie, możesz to zrobić. Dodaj zdjęcia, informacje o konfiguracji, przechwycone pakiety... możemy wysłać Ci darmowy prezent za przesłanie dobrego, szczegółowego opisu urządzenia:
https://www.elektroda.com/rtvforum/topic3950844.html#20500470

Oto mój temat dotyczący czujnika drzwi:
https://www.elektroda.com/rtvforum/topic3914412.html
jeśli u Ciebie jest inaczej to podziel się informacją.

Zrobiłem to ... https://www.elektroda.com/rtvforum/topic3914412-30.html#20686497
Z poważaniem MK_Monachium