logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Przewodnik flashowania, instalacji i konfiguracji TuyaMCU - skonfiguruj dpID dla Home Assistant

p.kaczmarek2 24 Lut 2024 08:48 18033 48

TL;DR LABEL_AI_GENERATED

  • Przewodnik pokazuje, jak flashować, instalować i konfigurować urządzenia TuyaMCU w OpenBK7231T, mapując dpID na kanały i łącząc je z Home Assistant.
  • Opisuje identyfikację TuyaMCU przez dodatkowy MCU, linie UART RX1/TX1, odczyt konfiguracji z flasha i sprawdzanie komunikacji przed dalszą konfiguracją.
  • Do pracy z dpID używa analizatora, tuyaMcu_sendQueryState i linkTuyaMCUOutputToChannel 24 val 1; podane prędkości to 9600 i 115200.
  • Efektem ma być lokalne sterowanie bez chmury, automatyczne encje Home Assistant, ręczny YAML, MQTT, DP po HTTP i własny GUI na LittleFS.
  • Największe ograniczenie to współdzielenie portu flashowania z MCU, więc zwykle trzeba rozłączyć RX/TX lub inaczej odizolować układ przed wgraniem firmware.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
Treść została przetłumaczona angielski » polski Zobacz oryginalną wersję tematu
Słuchaj:
  • Schemat blokowy współdziałania MCU i modułu Wi-Fi.
    Tutaj pokażę Ci krok po kroku jak skonfigurować urządzenie TuyaMCU, jak uzyskać listę dpID, jak zmapować dpID na kanały i opublikować je w Home Assistant oraz jak stworzyć niestandardową stronę dla urządzenia. W tym temacie omówię tematykę TuyaMCU od strony praktycznej, tak abyś mógł łatwo uwolnić swoje urządzenia tego typu od chmury.

    Temat tłumaczony z języka angielskiego, w trakcie poprawek!

    Ale przede wszystkim - nie flashuj najpierw urządzenia, zacznij od przeczytania tego przewodnika. Dzieje się tak dlatego, że jedna z metod ekstrakcji dpID wymaga urządzenia z oryginalnym wsadem

    0. Przeprowadź badania ogólne
    Pierwszym krokiem jest oczywiście ustalenie, czym jest TuyaMCU. Dlatego też zaleca się najpierw zapoznanie się z podstawową lekturą.
    - przeczytaj nasz tekst: Protokół TuyaMCU - komunikacja pomiędzy mikrokontrolerem a modułem WiFi
    - przeczytaj dokumentację Tuya: https://developer.tuya.com/en/docs/iot/tuya-c...-serial-port-access-protocol?id=K9hhi0xxtn9cb
    - otwórz nasze lista urządzeń , zaznacz pole wyboru „szczegółowe” i wyszukaj „TuyaMCU”, przeczytaj znalezione rozbiórki
    - przeczytaj naszą stronę z przykładami autoexec, przynajmniej te związane z TuyaMCU https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Aby uzyskać ogólną wiedzę na temat OBK, proszę:
    - przeczytaj nasze dokumenty: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
    - obejrzyj nasze poradniki dotyczące flashowania: https://www.youtube.com/@elektrodacom

    1. Sprawdź, czy Twoje urządzenie jest za pomocą TuyaMCU
    Teraz musisz wiedzieć, czy Twoje urządzenie korzysta z TuyaMCU. Więc,
    tSpróbuj odpowiedzieć na następujące pytania:
    - czy po otwarciu obudowy urządzenia znajduje się dodatkowy MCU w obudowie SOIC lub TQFP (lub podobnej) w pobliżu modułu WiFi?
    - czy moduł WiFi jest podłączony do MCU liniami RX1/TX1 (UART1)?
    - kiedy robisz ekstrakcja konfiguracji z nasz flasher , czy znajduje baud ustawienie w lampie błyskowej?
    - czy po flashowaniu urządzenia Twoje urządzenie nadal ma funkcjonalne przyciski, nawet bez konfigurowania ich w OBK?
    - czy Twoje urządzenie ma ekran?
    Jeśli odpowiedziałeś TAK na niektóre pytania, istnieje szansa, że Twoje urządzenie to TuyaMCU.

    2. Określ ustawienie transmisji
    Najlepszym sposobem sprawdzenia ustawień transmisji jest użycie naszego narzędzia Flash: nasz flasher , po prostu uzyskaj kopię zapasową flash 2 MB urządzenia pobraną przez UART Lub po prostu pobierz partycję konfiguracyjną Tuya poprzez ekstrakcję konfiguracji Tuya w OBK i przeciągnij i upuść go na flasherze:
    Interfejs programu BK7231 Easy UART Flasher z ustawieniami i informacjami o urządzeniu TuyaMCU
    Szybkość transmisji TuyaMCU wynosi 9600 (domyślnie) i 115200 (duża prędkość)

    3. Określ znaczenie identyfikatorów dpID
    W tym miejscu przydatne jest posiadanie jeszcze niesflashowanego urządzenia, ale jest wiele sposobów. Jeśli jeszcze nie sflashowałeś urządzenia:
    - możesz po prostu weź je od Tuyi
    - jeśli posiadasz izolowany konwerter USB na UART i wiesz jak go bezpiecznie podłączyć (bo zasilanie urządzenia nie może być odizolowane od sieci), możesz skorzystać z naszego Analizator TuyaMCU aby podsłuchiwać komunikację i obserwować, które dpID są wysyłane podczas wykonywania określonej akcji w aplikacji Tuya, na przykład zmień przekaźnik i obserwuj, który dpID jest wysyłany
    Jeśli już flashowałeś OBK:
    - możesz uruchomić sterownik i ustawić prędkość TuyaMCU w autoexec, a następnie użyć tuyaMcu_sendQueryState polecenie, aby uzyskać dpID z MCU. Następnie trzeba obserwować ich wartości i odgadnąć ich znaczenie (przykładowo, jeśli termometr pokazuje 21,5C, a jeden dpID ma wartość 215, to można podejrzewać, że to temperatura)
    - możesz również przeszukaj naszą listę urządzeń w przypadku podobnych urządzeń może niektóre dpID pasują
    - możesz także użyć tuyaMcu_sendState polecenie wysłania czegoś do TuyaMCU, na przykład wartości przekaźnika i obserwowania, czy zmienia się na urządzeniu fizycznym, patrz dokumenty poleceń

    5. Uruchom sterownik i sprawdź, czy istnieje komunikacja
    Dzieje się tak, gdy musisz już sflashować urządzenie. Wcześniejsze kroki można było wykonać bez flashowania, ale teraz nadszedł czas na zmianę oprogramowania sprzętowego.
    Głównym problemem związanym ze zmianą oprogramowania sprzętowego urządzeń TuyaMCU jest to, że korzysta z niego TuyaMCU ten sam port co flashowanie .
    Oznacza to, że będziesz musiał coś z tym zrobić zerwać połączenie MCU na czas flashowania, przynajmniej w większości przypadków.
    Można to zrobić na wiele sposobów:
    - odetnij ścieżki (RX i TX) prowadzące do MCU i napraw je po flashowaniu
    - odłączyć płytkę za pomocą TuyaMCU (jeśli to możliwe, jeśli płytki są oddzielne)
    - wylutuj moduł TuyaMCU lub WiFi (czasami jest to możliwe)
    - wylutować rezystory na torach RX/TX (jeśli są, niektóre urządzenia ich nie posiadają)
    Alternatywnie , możesz także spróbować zajrzeć do arkusza danych MCU i sprawdzić, czy możliwe jest wprowadzenie go w stan RESET poprzez podciągnięcie go w dół lub w górę.
    Futhermote , istnieją również rozwiązania do flashowania OTA, ale nie są one niezawodne i większość nowych urządzeń jest łatana.

    6. Uruchom sterownik i sprawdź, czy istnieje komunikacja
    Teraz czas na konfigurację podstawowego pliku autoexec.bat w OBK:



    Oto konfiguracja początkowa:
    
    // Start TuyaMCu driver
    startDriver TuyaMCU
    // set TuyaMCU baud rate
    //tuyaMcu_setBaudRate 115200
    // 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
    

    The tuyaMcu_setBaudRate jest skomentowany, w razie potrzeby usuń komentarz. To powinno zapewnić podstawowe pulsy TuyaMCU i komunikację w dzienniku aplikacji internetowej OpenBeken. To również powinno sprawić tuyaMcu_sendQueryState praca.
    Nie zapomnij o tuyaMcu_defWiFiState 4 linia. Domyślnie OBK wysyła stan „sparowany” (0x04) tylko wtedy, gdy włączone jest MQTT, ale niektóre urządzenia zawsze wymagają, aby stan Wi-Fi był „sparowany” (0x04) przed wysłaniem danych. Będzie to kontrolować diodę LED Wi-Fi MCU, a nawet może sterować brzęczykiem. Niektóre urządzenia będą wysyłać sygnały dźwiękowe brzęczyka, jeśli nie są sparowane.


    7. Zmapuj identyfikatory dpID
    W OBK możesz mapować dpID na kanały.
    Kanał jest jak zmienna, może przechowywać liczby całkowite.
    Możesz dostosować sposób wyświetlania kanałów, ustawiając ich typy, na przykład:
    
    setChannelType 1 Toggle
    

    Spowoduje to utworzenie przełącznika GUI i tego:
    
    setChannelType 1 temperature
    

    Spowoduje to utworzenie wyświetlacza temperatury.
    Aby zobaczyć pełną listę typów kanałów, sprawdź: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/channelTypes.md
    Mimo to, aby uzyskać dane z MCU, musisz zmapować dpID na kanał, więc:
    
    // Map given dpID to channel 1
    // dpID type value
    linkTuyaMCUOutputToChannel 24 val 1
    

    Powyższy kod odwzorowuje dpID 24 na kanał 1, z wartością typu.
    Istnieje wiele możliwych typów.
    Istnieją typy Tuya:
    - 0-surowe
    - 1-bool
    - 2-wartość
    - 3-strunowy
    - 4-wyliczenie
    - 5-bitowa mapa
    I tam typy specyficzne dla OBK. Na przykład, jeśli chcesz, aby podany dpID był zawsze publikowany przez MQTT w formie szesnastkowej, możesz:
    
    linkTuyaMCUOutputToChannel 24 MQTT
    

    Spowoduje to opublikowanie wartości w temacie tm/TYPE/dpID za każdym razem, gdy TuyaMCU ją wyśle.

    Istnieją również specjalne typy złożonych pakietów danych surowych. Poniższy przykład dotyczy pakietu surowego napięcia + prądu + mocy dla urządzenia TAC2121C:
    
    linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
    

    Powyższy kod zostanie automatycznie ustawiony Napięcie, prąd i moc kanały.
    Aby zobaczyć pełne przykłady konfiguracji, sprawdź nasze przykłady autoexec:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Możesz także skorzystać z naszej listy urządzeń:
    https://openbekeniot.github.io/webapp/devicesList.html
    Wpisz „ściemniacz TuyaMCU” w polu wyszukiwania (na przykład) i wyszukaj.

    Jeśli więc nie znasz znaczenia identyfikatorów dpID, przepływ pracy jest następujący:
    1. spróbuj zapytać o stan z MCU
    2. napisz konfigurację, aby mapować otrzymane dpID na kanały
    3. zapisz konfigurację i uruchom ponownie
    4. Obserwuj, czy konfiguracja działa, jeśli czegoś brakuje, dokonaj poprawek
    Wykonuj małe kroki, pojedynczo, w ten sposób możesz zbudować nawet skomplikowane urządzenie. Jeśli masz jakiś problem, nie wahaj się zapytać na forum.

    8. Utwórz niestandardowy GUI
    Jest to całkowicie opcjonalne, ale jeśli chcesz mieć niestandardowe GUI na swoim urządzeniu, możesz stworzyć własną stronę w HTML i JS i hostować ją na LittleFS:
    OpenBeken jako mini hosting HTTP - pisanie stron w JavaScript, Tasmota REST
    Istnieje bardzo przydatna funkcja, którą można wykorzystać w tym celu, nazywa się to DP . Można go wysłać za pośrednictwem protokołu HTTP z JavaScript na stronie REST:
    Zrzut ekranu JSON z danymi dpID
    Aby to zadziałało, musisz włączyć następującą flagę: flaga 46 .
    Spowoduje to przechowywanie ostatnich wartości dpID w formacie szesnastkowym i umożliwi dostęp do nich w JSON.
    To samo polecenie działa poprzez MQTT , wyśle odpowiedź pod adresem stat/TuyaMCU/DP .


    9. Sparuj z Asystentem Domowym
    Istnieje wiele sposobów parowania, które w dużym stopniu zależą od osobistych preferencji i konkretnego urządzenia.
    Najprostszym sposobem jest po prostu użycie automatycznego wykrywania HASS, które tworzy encje Hass oparte na typach kanałów OBK i ich odpowiednich nazwach:



    Bardziej zaawansowany sposób polega na napisz samodzielnie konfigurację YAML i po prostu włóż go do konfiguracja.yaml Twojego Asystenta Domowego.
    Jest kilka dobrych trików, które mogą w tym pomóc, na przykład możesz użyć specjalnego argumentu za linkTuyaMCUOutputToChannel aby włączyć publikowanie dpID w surowej formie szesnastkowej, aby mógł być później przetworzony przez HA:
    
    linkTuyaMCUOutputToChannel 6 MQTT
    

    Ustaw, zapisz i uruchom ponownie i obserwuj, co dzieje się w dzienniku Home Assistant. Możesz także użyć narzędzia Home Assistant MQTT do oglądania pakietów MQTT.

    Czy możesz pokazać przykładowy temat demontażu ściemniacza TuyaMCU?
    Cóż, jak powiedziałem, skorzystaj z naszej listy urządzeń, ale mimo to oto jedna próbka:
    Ściemniacz OpenBeken i TuyaMCU - instrukcja/tutorial konfiguracji
    A tutaj jest konfiguracja urządzenia wentylatorowego :
    BK7231T Treatlife DS03 Przełącznik wentylatora/ściemniacza światła: Flash OTA i instrukcja konfiguracji (TuyaMCU dpID)
    A oto rozbiórka miernika mocy:
    [BK7231N ] Demontaż i flashowanie Tomzn TOMPD-63 WIFI (nie mylić z TOMPD-63LW)

    Czy możesz pokazać próbkę niestandardowej strony REST dla urządzenia
    Możesz zapoznać się z naszym samouczkiem dotyczącym BW-AF1:
    OpenBeken na frytkownicy BW-AF1 z WiFi - wnętrze, TYWE3S/WB3S, konfiguracja
    Posiada niestandardową stronę REST do sterowania frytkownicą.


    Czy możesz pokazać próbkę niestandardowego skryptu dla urządzenia?
    Sprawdź naszą konfigurację podobną do TAC2121C z kontrolerem limitu ładowania:
    Integracja Home Assistant: Reflashowanie BK7231N w inteligentnym liczniku energii Tuya na szynę DIN TAC2121C
    Ostateczny skrypt znajduje się na końcu tematu.

    A co z urządzeniami zasilanymi bateryjnie?
    Urządzenia TuyaMCU zasilane bateryjnie są wyjątkowe – MCU steruje w nich mocą modułu WiFi. MCU włącza moduł WiFi tylko wtedy, gdy musi zgłosić dane. Wymaga to specjalnego sterownika tzw Czujnik tm .
    Aby uzyskać więcej informacji, zobacz przykładowy przewodnik po tmSensor:
    Energooszczędny (?) Czujnik drzwi/okien na baterie do WiFi DS06
    [CB3S/BK7231N] Czujnik temperatury/wilgotności z TuyaMCU – schemat, inżynieria odwrotna



    Streszczenie

    Istnieje wiele sposobów konfiguracji i flashowania urządzeń TuyaMCU. Identyfikatory dpID TuyaMCU można wyodrębnić przed flashowaniem, ręcznie (poprzez wąchanie protokołu) lub automatycznie ze strony chmury Tuya. Można również zażądać identyfikatorów dpID TuyaMCU i je sprawdzić po flashowaniu, za pomocą polecenia zapytania o stan. TuyaMCU można skonfigurować w elastyczny sposób, albo za pomocą standardowej strony OBK, albo za pomocą w pełni niestandardowego interfejsu REST, który może być hostowany na dowolnym urządzeniu OBK z LittleFS. Urządzenia TuyaMCU skonfigurowane za pomocą OBK można również sparować z Home Assistant, zarówno poprzez automatyczne Home Discovery, jak i bardziej zaawansowaną i elastyczną ręczną konfigurację YAML. Istnieje również wiele sposobów na uzyskanie danych TuyaMCU z urządzenia OBK - możesz po prostu użyć kanałów OBK, możesz użyć specjalnego łącza MQTT dpID lub możesz użyć polecenia DP, aby zażądać wszystkich wartości dpID na żądanie. Polecenie DP działa zarówno poprzez HTTP, jak i MQTT. Możesz także tworzyć skrypty dla urządzeń OBK, aby zautomatyzować konfigurację, zarówno z Home Assistant, jak i bez niego.
    Daj nam znać, jeśli masz jakieś pytania związane z TuyaMCU, dołożymy wszelkich starań, aby pomóc Ci skonfigurować Twoje urządzenia!

    Fajne? Ranking DIY
    Pomogłem? Kup mi kawę.
    O autorze
    p.kaczmarek2
    Moderator Smart Home
    Offline 
    Inżynier programista z wieloletnim doświadczeniem embedded i full stack developer.
    Specjalizuje się w: embedded, Full-Stack Developer
    p.kaczmarek2 napisał 14755 postów o ocenie 12877, pomógł 659 razy. Jest z nami od 2014 roku.
  • #2 21057937
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    Aktualizacja TuyaMCU! Szczegółowe informacje na temat nowej funkcji OBK TuyaMCU można znaleźć w poniższym temacie:
    Jak uzyskać listę typów i wartości dpID dla sflashowanych urządzeń TuyaMCU z OpenBeken
    Pomogłem? Kup mi kawę.
  • #3 21159305
    morgan_flint
    Poziom 14  
    Posty: 251
    Pomógł: 4
    Ocena: 63
    Witaj @p.kaczmarek2 !

    Być może są jeszcze dwie możliwości, chociaż nie jestem pewien, jak sprawić, by działały, lub czy są one zbędne z innymi... być może członkowie, o których mowa poniżej, mogą udzielić więcej informacji:

    - @crg1darkspr1te mówił w tym poście o rozpakowaniu/odszyfrowaniu fabrycznego firmware , i uzyskanie pliku .json z informacjami o identyfikatorach DpID.

    - @divadiow mówił w tym poście o " Odpowiedź API Tuya dla tego urządzenia ", i dał plik .json podobny do poprzedniego, ale z drugą częścią z bardziej opisowymi informacjami o DpID (wygląda bardzo podobnie do tej w skróconej metodzie w moim samouczku .

    Może będą mogli podać więcej informacji o swoich metodach!
  • #4 21228240
    io2345
    Poziom 10  
    Posty: 273
    Pomógł: 1
    Ocena: 7
    Wydaje się, że numery kanałów większe niż 99 nie są obsługiwane. Próbowałem użyć 101 i 102, ponieważ były to moje odpowiednie dpID, ale elementy sterujące nie były wyświetlane w GUI, dopóki nie zmieniłem numeru kanału na 7 i 8.
  • #5 21229830
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    W OBK dostępne są 64 kanały:
    Fragment kodu w pliku „new_pins.h” zdefiniowanego w projekcie OpenBK7231T_App, pokazujący, że dostępnych jest 64 kanały. .
    Pomogłem? Kup mi kawę.
  • #6 21407813
    erdeidominik1999
    Poziom 8  
    Posty: 47
    Pomógł: 1
    Ocena: 1
    Hy!
    Czy jest jakiś sposób na utworzenie typu kanału podobnego do menu wyboru? Muszę mieć na przykład 4 stałe opcje wyboru.
    Kolejne pytanie:
    Mam kontroler ładowania słonecznego, który działa z tuyamcu, mój problem polega na tym, że niektóre informacje są zgłaszane w jednym dp, które są oddzielnymi wartościami, na przykład: dp ma następującą wartość: 00 77 00 04 00 53, pierwszy i drugi bajt to jedna zmienna, trzecia, czwarta to inna, a piąta, szósta to inna. Znalazłem, że RAW_TAC2121C_VCP robi coś takiego, ale tam jest 8 bajtów, możesz @p.kaczmarek2 stworzyć taki typ, ale z 6 bajtami?
  • #7 21441949
    doudouni100
    Poziom 4  
    Posty: 7
    >>21229830 Cześć

    Czy jest jakiś sposób aby to zmienić ?

    Mam czujnik temperatury i wilgotności, a kanał baterii to 101, więc nie można go wyświetlić.
  • #8 21441971
    erdeidominik1999
    Poziom 8  
    Posty: 47
    Pomógł: 1
    Ocena: 1
    >>21441949
    Czy masz więcej niż 64 kanały? Dlaczego chciałbyś używać ch101?
  • #9 21441973
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    Nie trzeba go zmieniać. Możesz zmapować dowolny dpID do dowolnego kanału. Na przykład:
    
    
    startDriver TuyaMCU
    
    // cook on/off 
    setChannelType 1 Toggle
    setChannelLabel 1 "Cook"
    linkTuyaMCUOutputToChannel 111 bool 1 
    // power on/off
    setChannelLabel 2 "Power"
    setChannelType 2 Toggle
    linkTuyaMCUOutputToChannel 101 bool 2 
    
    // set temperature
    setChannelLabel 3 "New Temperature"
    setChannelType 3 TextField
    linkTuyaMCUOutputToChannel 103 val 3
    
    .
    Zobacz przykłady tutaj: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md

    Dodano po 54 [sekundach]:

    erdeidominik1999 napisał:

    Mam kontroler ładowania słonecznego, który działa z tuyamcu, mój problem polega na tym, że niektóre informacje są raportowane w jednym dp, które są oddzielnymi wartościami, na przykład: dp ma następującą wartość: 00 77 00 04 00 53, pierwszy i drugi bajt to jedna zmienna, trzecia, czwarta to inna, a piąta, szósta to inna. Znalazłem, że RAW_TAC2121C_VCP robi coś takiego, ale tam jest 8 bajtów, czy możesz @p.kaczmarek2 stworzyć taki typ, ale z 6 bajtami?

    RAW_TAC2121C_VCP tylko z 6 bajtami i w tym samym formacie?
    Pomogłem? Kup mi kawę.
  • #10 21441988
    erdeidominik1999
    Poziom 8  
    Posty: 47
    Pomógł: 1
    Ocena: 1
    >>21441973
    Tak samo z RAW_TAC2121C_VCP z 6 bajtami. Typy muszą być Voltage_div10, Current_div10, Power_div10, ale myślę, że Current_div10 nie istnieje. Innym typem, który nie istnieje, ale jest potrzebny, jest Percent_div10, ponieważ procent baterii jest wyrażany w procentach z mnożnikiem 10.
  • #11 21442008
    doudouni100
    Poziom 4  
    Posty: 7
    >>21441973
    Dzięki! Udało się!!!
    Próbowałem tego wcześniej, ale nie zmieniłem liczby po "enum"

    Więc dla każdego, kto ma czujnik, jest to autoexec:
    startDriver TuyaMCU
    startDriver tmSensor
    // dpID 27 to temperatura div 10
    setChannelType 27 temperature_div10
    linkTuyaMCUOutputToChannel 27 val 27
    // dpID 46 to % wilgotności
    setChannelType 46 Humidity
    linkTuyaMCUOutputToChannel 46 val 46
    // dpID 101 to stan baterii - niski (0), średni (1) i wysoki (2)
    setChannelType 10 Tylko do odczytu
    linkTuyaMCUOutputToChannel 101 enum 10
    setChannelLabel 10 Battery
    Zbliżenie na zieloną płytkę PCB z zamontowanym na niej niebieskim modułem elektronicznym.
  • #12 21442013
    erdeidominik1999
    Poziom 8  
    Posty: 47
    Pomógł: 1
    Ocena: 1
    >>21442008
    Możesz również użyć kanału 1,2,3, myślę, że jest to czystsze. Nie trzeba mieć tego samego kanału co tuya dp.
  • #13 21443231
    morgan_flint
    Poziom 14  
    Posty: 251
    Pomógł: 4
    Ocena: 63
    doudouni100 napisał:
    startDriver tmSensor

    Czy naprawdę trzeba uruchamiać tmSensor?
    Dopóki MCU Tuya zarządza interfejsem z czujnikiem, Open Beken nie musi się tym zajmować, tak myślę
  • #14 21443445
    doudouni100
    Poziom 4  
    Posty: 7
    >>21443231 .

    Hej !

    Prawdopodobnie masz rację ! To ma sens.

    Po wypróbowaniu wszystkiego, co znalazłem na tym forum i innych bez powodzenia, pomyślałem, że sam spróbuję i przy okazji czegoś się nauczę.

    "StartDriver tmSensor" był tam z moich poprzednich prób i nie kwestionowałem tego, bo co ja tam wiem :)

    Kiedy znalazłem odpowiednie kanały z TuyaMCUAnalyzer dla temperatury, wilgotności i baterii, po prostu podłączyłem te liczby do poprzedniego autoexec i zadziałało!

    Nie mogę sobie wyobrazić, że to zaszkodzi, a ponieważ jest zasilany bateryjnie, nie zamierzam go rozbierać i próbować.

    A może moja ciekawość zwycięży i rozbiorę go teraz, gdy o tym wspomniałeś :)
  • #15 21443483
    morgan_flint
    Poziom 14  
    Posty: 251
    Pomógł: 4
    Ocena: 63
    doudouni100 napisał:
    Nie wyobrażam sobie, że to zaszkodzi, a ponieważ jest zasilany bateryjnie, nie zamierzam go rozbierać i próbować.

    Nie, nie zaszkodzi, ale nie musisz go rozbierać, możesz edytować autoexec.bat z interfejsu internetowego
  • #16 21443600
    doudouni100
    Poziom 4  
    Posty: 7
    >>21443483 .

    Tak jak mówiłem, jest zasilany bateryjnie i pozostaje włączony przez kilka sekund, aby cokolwiek wysłać, a Wi-Fi wyłącza się, aby oszczędzać baterię,

    Będę musiał go rozebrać, aby wymusić zasilanie modułu Wi-Fi, aby pozostał włączony wystarczająco długo, aby wprowadzić zmiany z poziomu interfejsu internetowego.
  • #17 21443630
    erdeidominik1999
    Poziom 8  
    Posty: 47
    Pomógł: 1
    Ocena: 1
    >>21443600 Jeśli wyłączysz i włączysz go 3 razy, przejdzie do trybu bezpiecznego i nie uruchomi autoexec, więc wifi się nie wyłączy.
  • #18 21443655
    morgan_flint
    Poziom 14  
    Posty: 251
    Pomógł: 4
    Ocena: 63
    W przypadku niektórych moich zasilanych bateryjnie urządzeń Tuya (również czujników temperatury i wilgotności) dłuższe naciśnięcie przycisku podświetlenia wymusza również dłuższe działanie WiFi. Na podstawie zdjęć nie mogę stwierdzić, czy Twoje urządzenie ma taki przycisk
  • #19 21474001
    erdeidominik1999
    Poziom 8  
    Posty: 47
    Pomógł: 1
    Ocena: 1
    erdeidominik1999 napisał:
    >>21441973
    Tak samo z RAW_TAC2121C_VCP z 6 bajtami. Typy muszą być Voltage_div10, Current_div10, Power_div10, ale myślę, że Current_div10 nie istnieje. Innym typem, który nie istnieje, ale jest potrzebny, jest Percent_div10, ponieważ procent baterii jest wyrażany w procentach z mnożnikiem 10.

    @p.kaczmarek2 Czy możesz dołączyć ten typ?
  • #20 21602808
    blacksun2
    Poziom 8  
    Posty: 59
    Ocena: 1
    Witam,

    Wciąż jestem bardzo nowy w OpenBeken i mam trudności.
    Jednym z problemów jest temat TuyaMCU.
    Powyższe pytanie jest dokładnie takie samo - skąd wiadomo, czy urządzenie korzysta z TuyaMCU?
    Czy nie ma niezawodnego sposobu, aby się tego dowiedzieć?

    Proszę, nie zrozum źle tych pytań lub stwierdzeń. Wiele z nich odzwierciedla frustrację związaną z niepowodzeniem.
    OBK jest znacznie bardziej skomplikowany niż Tasmota. W przypadku Tasmota wystarczy wiedzieć tylko dwie rzeczy: Który chip ESP jest zainstalowany i które funkcje mogą wymagać kompilacji do Tasmota.
    Następnie umieszczasz całość w kompilatorze online i gotowe. Nic więcej nie trzeba wiedzieć.

    Na początku myślałem, że EasyFlasher jest narzędziem z wyboru dla PIN-ów i MCU. Zawsze myślałem, że jeśli narzędzie nie może wyodrębnić kodów PIN, to jest to urządzenie MCU. Ale to nie może być prawda, ponieważ kupiłem siedem różnych inteligentnych gniazd z funkcjami pomiarowymi z Aliexpress. Narzędzie wyodrębniło kody PIN tylko dla jednego z nich (tego z Aubess). Ponieważ jednak inne inteligentne wtyczki działają wyłącznie z przypisanymi kodami PIN za pomocą https://openbekeniot.github.io/webapp/devicesList.html, EasyFlasher niewiele mi o nich mówi.

    Odnośnie pytania: Czy MCU jest zainstalowany? Jak rozpoznać MCU? Bez przeszkolenia w zakresie mikroelektroniki laik nie jest w stanie stwierdzić, czy na przykład odcisk BL0937 jest MCU, czy nie.

    EasyFlasher nigdy nie pokazał mi ustawienia szybkości transmisji podczas próby wyodrębnienia kodu PIN.
    Oprócz inteligentnych wtyczek kupiłem również kolekcję zasilanych bateryjnie urządzeń Tuya. W zestawie znajduje się czujnik temperatury i wilgotności "TH08B", czujnik ruchu "TH01", czujnik ruchu "P01", czujnik ruchu "HW400B" (okrągły, złącze USB-C), "WiFi Carbon Monoxide Detector" z wyświetlaczem oraz "Smart Air Box" (mierzy 5 różnych wartości w powietrzu).

    Czy mogę założyć, że wszystkie urządzenia Tuya zasilane bateryjnie są urządzeniami TuyaMCU?
    Czy istnieją również urządzenia mieszane, które używają PIN-ów i TuyaMCU? Wtedy, jako laik, mógłbym pracować metodą eliminacji. Jeśli PIN-y są wymienione na liście urządzeń - nawet jeśli jest to tylko jeden - to mogę być pewien, że TuyaMCU nie jest już problemem.

    A co z urządzeniami korzystającymi z oprogramowania eWeLink lub CozyLife? Czy zawsze używają one kodów PIN?

    Czy dobrze zrozumiałem, że przegląd urządzeń na stronie https://openbekeniot.github.io/webapp/devicesList.html pomaga tylko w przypadku urządzeń, które używają PIN-ów, a nie TuyaMCU?
    Ten przegląd jest również podstawą dla WebApp -> Config.
    Laik, taki jak ja, po zainstalowaniu OBK czyta, że wszystko, co musi zrobić, to wybrać odpowiednie urządzenie, kliknąć "Kopiuj ustawienia urządzenia", a następnie kliknąć "Zapisz kody PIN" i "Zapisz typy" i gotowe.
    Po tym, jak zadziałało to z inteligentnymi wtyczkami, zrobiłem to samo z TH08B, TH01 i P01 i byłem zaskoczony, że nic nie zadziałało.

    Jeśli urządzenie jest urządzeniem TuyaMCU, muszę pracować z analizatorem TuyaMCU. Jak widziałem, narzędzie może teraz również bezpośrednio odczytywać RX i TX i nie potrzebujesz już RealTerm.
    Próbowałem bezpośrednio z TB08B i nie udało się, patrz załącznik.
    Muszę zmierzyć RX1 i TX1 za pomocą narzędzia, tj. punkty, w których również flashuję OBK, prawda?

    Następnie strona Release:
    https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.18.133
    W zakładce "Assets" wciąż jest sporo plików ze skrótami w nazwie. Po procesie eliminacji mogę już zdecydować, że nie potrzebuję plików z "ESP" i "berry". Ale nadal pozostało kilka plików. nadal:
    OpenBK7231N_1.18.133_powerMetering.rbl
    OpenBK7231N_1.18.133_sensors.rbl
    OpenBK7231N_1.18.133_tuyaMCU.rbl
    OpenBK7231N_1.18.133.rbl
    OpenBK7231N_ALT_1.18.133.rbl
    OpenBK7231N_ALT_QIO_1.18.133.bin
    OpenBK7231N_ALT_UA_1.18.133.bin
    OpenBK7231N_QIO_1.18.133_powerMetering.bin
    OpenBK7231N_QIO_1.18.133_sensors.bin
    OpenB K7231N_QIO_1.18.133_tuyaMCU.bin
    OpenBK7231N_QIO_1.18.133.bin
    OpenBK7231N_UA_1.18.133_powerMetering.bin
    OpenBK7231N_UA_1.18.133_sensors.bin
    OpenBK7231N_UA_1.18.133_tuyaMCU.bin
    OpenBK7231N_UA_1.18.133.bin
    OpenBK7231N_UG_1.18.133_powerMetering.bin
    OpenBK7231N_UG_1.18.133_sensors.bin
    OpenBK7231N_UG_1.18.133_tuyaMCU.bin
    OpenBK7231N_UG_1.18.133.bin

    Jeśli jako laik wiesz, że masz do czynienia z urządzeniem TuyaMCU, pojawia się pytanie, czy potrzebujesz standardowego "OpenBK7231N_QIO_1.18.133.bin", czy tego z tuyMCU w nazwie.

    W przypadku inteligentnych wtyczek laik może się zastanawiać, czy potrzebny jest plik z poerMetering.

    Krótko mówiąc, czy istnieje przegląd tego, co oznaczają skróty i gdzie można dowiedzieć się, kiedy należy użyć której wersji?
    Załączniki:
    • th08b_receive_datetime.txt (1.81 KB) Musisz być zalogowany, aby pobrać ten załącznik.
    • th08b_send.txt (8.29 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #21 21603621
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    blacksun2 napisał:

    Powyższe pytanie jest dokładnie takie samo - skąd wiadomo, czy urządzenie korzysta z TuyaMCU?
    Czy nie ma niezawodnego sposobu, aby się tego dowiedzieć?

    Wszystkie urządzenia TuyaMCU znalezione do tej pory mają MCU podłączone przez UART do modułu WiFi. Istnieją jednak również urządzenia, w których MCU nie używa protokołu TuyaMCU, jak widać tutaj: https://www.elektroda.com/rtvforum/topic4119999.html
    Więc najpierw poszukaj MCU podłączonego przez UART, a następnie prawdopodobnie spróbuj przechwycić ruch lub po prostu flashuj i wypróbuj sterownik TuyaMCU na OBK, aby sprawdzić, czy działa.


    blacksun2 napisał:

    OBK jest znacznie bardziej skomplikowany niż Tasmota. W przypadku Tasmoty musisz wiedzieć tylko dwie rzeczy: Który chip ESP jest zainstalowany i które funkcje mogą wymagać kompilacji do Tasmoty.
    Następnie umieszczasz całość w kompilatorze online i gotowe. Nic więcej nie trzeba wiedzieć.

    Jestem przekonany, że to nieprawda. Konfiguracja TuyaMCU na Tasmocie jest podobna do naszej, trzeba też znać dpIDy. W przypadku Tasmota TuyaMCU trzeba sporo skonfigurować, zobacz tutaj: https://tasmota.github.io/docs/TuyaMCU-Devices/
    Co gorsza, w Tasmocie wpisujesz te komendy ręcznie, zamiast kopiować autoexec.bat

    blacksun2 napisał:

    Na początku myślałem, że EasyFlasher jest narzędziem z wyboru do PINów i MCU. Zawsze myślałem, że jeśli narzędzie nie może wyodrębnić PIN-ów, to jest to urządzenie MCU.

    Jeśli nie znajdzie żadnych pinów, ale znajdzie szybkość transmisji, istnieje spora szansa, że urządzenie to TuyaMCU.[/quote]


    blacksun2 napisał:
    Bez przeszkolenia w mikroelektronice laik nie jest w stanie stwierdzić czy np. odcisk BL0937 to MCU czy nie.

    Kilka rzeczy do odnotowania:
    - można znaleźć arkusz danych BL0937 i dowiedzieć się, że nie jest to MCU
    - BL0937 nie jest podłączony przez port UART, więc nie jest to TuyaMCU
    - podczas gdy BL0942 wykorzystuje port UART, taki sam jak MCU, to ma arkusz danych wyraźnie mówiący, że nie jest to TuyaMCU
    - urządzenia z BL0942 i BL0937 zwykle mają piny wyodrębnione przez flasher


    blacksun2 napisał:

    Czy mogę założyć, że wszystkie urządzenia Tuya zasilane bateryjnie są urządzeniami TuyaMCU?

    Istnieje wiele urządzeń zasilanych bateryjnie, które nie korzystają z TuyaMCU. Używają one mechanizmu głębokiego uśpienia.
    https://www.elektroda.com/rtvforum/find.php?q=DeepSleep
    https://www.elektroda.com/rtvforum/find.php?q=PinDeepSleep

    blacksun2 napisał:

    Czy istnieją również urządzenia mieszane, które wykorzystują PINy i TuyaMCU?

    Jest to rzadko używane, ale widziałem urządzenie TuyaMCU z pinem UART + używanym do sygnalizacji stanu WiFi.
    https://www.elektroda.com/rtvforum/topic4089722.html


    blacksun2 napisał:

    A co z urządzeniami korzystającymi z oprogramowania eWeLink lub CozyLife? Czy one zawsze używają PIN-ów?

    TuyaMCU jest używany tylko na urządzeniach Tuya, jak sądzę.


    blacksun2 napisał:

    Czy dobrze zrozumiałem, że przegląd urządzeń na https://openbekeniot.github.io/webapp/devicesList.html pomaga tylko z urządzeniami, które używają PIN-ów, a nie z TuyaMCU?

    Ta lista zawiera wszystkie urządzenia. Są tam również urządzenia TuyaMCU:
    Przewodnik flashowania, instalacji i konfiguracji TuyaMCU - skonfiguruj dpID dla Home Assistant .
    Tylko, że w ich przypadku trzeba otworzyć podlinkowany temat i znaleźć autoexec.bat


    blacksun2 napisał:

    Taki laik jak ja po zainstalowaniu OBK czyta, że wszystko co ma to Aby to zrobić, należy wybrać odpowiednie urządzenie, kliknąć "Kopiuj ustawienia urządzenia", a następnie kliknąć "Zapisz kody PIN" i "Zapisz typy" i gotowe.
    Po tym, jak zadziałało to z inteligentnymi wtyczkami, zrobiłem to samo z TH08B, TH01 i P01 i byłem zaskoczony, że nic nie zadziałało.

    Słuszna uwaga, może musimy dodać wiadomość lub lepszy mechanizm do tego, ale w zasadzie dla urządzeń TuyaMCU musisz otworzyć połączony temat urządzenia na Elektrodzie i znaleźć pasujący plik autoexec.bat i spróbować go zaimportować i uruchomić.

    Należy pamiętać, że Tuya może coś zmienić w międzyczasie, więc dobrze jest mieć podstawową wiedzę na temat TuyaMCU. I zawsze możesz zapytać na forum.

    Nie możemy automatycznie pobrać pliku autoexec.bat do LittleFS, ponieważ strony Github są tylko HTTPS, a OBK nie ma wbudowanego HTTPS (TLS) w głównym wydaniu. Dlatego musisz skopiować go ręcznie. Mogliśmy to zrobić tylko przez Web App.... Pomyślę o tym.



    blacksun2 napisał:

    Jeśli urządzenie jest urządzeniem TuyaMCU, muszę pracować z TuyaMCU Analyzer. Jak widziałem, narzędzie może teraz również bezpośrednio odczytywać RX i TX i nie potrzebujesz już RealTerm.
    Próbowałem bezpośrednio z TB08B i nie udało się, patrz załącznik.
    Muszę zmierzyć RX1 i TX1 za pomocą narzędzia, tj. punkty, w których również flashuję OBK, prawda?

    Tak, ale nigdy nie mierz gdy urządzenie jest podłączone do sieci!!! Może to spowodować zwarcie 230V do komputera!!! Można również pominąć podłączenie i użyć innej metody, aby uzyskać dpID:
    https://www.elektroda.com/rtvforum/topic4021129.html

    blacksun2 napisał:

    Następnie, strona Release:
    https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.18.133
    W sekcji "Assets" wciąż jest wiele plików ze skrótami w nazwie. Po procesie eliminacji mogę już zdecydować, że nie potrzebuję plików z "ESP" i "berry". Ale nadal pozostało kilka plików. nadal:
    OpenBK7231N_1.18.133_powerMetering.rbl
    OpenBK7231N_1.18.133_sensors.rbl
    OpenBK7231N_1.18.133_tuyaMCU.rbl
    OpenBK7231N_1.18.133.rbl
    OpenBK7231N_ALT_1.18.133.rbl
    OpenBK7231N_ALT_QIO_1.18.133.bin
    OpenBK7231N_ALT_UA_1.18.133.bin
    OpenBK7231N_QIO_1.18.133_powerMetering.bin
    OpenBK7231N_QIO_1.18.133_sensors.bin
    OpenB K7231N_QIO_1.18.133_tuyaMCU.bin
    OpenBK7231N_QIO_1.18.133.bin
    OpenBK7231N_UA_1.18.133_powerMetering.bin
    OpenBK7231N_UA_1.18.133_sensors.bin
    OpenBK7231N_UA_1.18.133_tuyaMCU.bin
    OpenBK7231N_UA_1.18.133.bin
    OpenBK7231N_UG_1.18.133_powerMetering.bin
    OpenBK7231N_UG_1.18.133_sensors.bin
    OpenBK7231N_UG_1.18.133_tuyaMCU.bin
    OpenBK7231N_UG_1.18.133.bin

    Jeśli jako laik wiesz, że masz do czynienia z urządzeniem TuyaMCU, pojawia się pytanie, czy potrzebujesz standardowego "OpenBK7231N_QIO_1.18.133.bin", czy tego z tuyMCU w nazwie.

    Stockowy OBK obsługuje TuyaMCU i będzie działał dobrze. OBK oznaczony jako "TuyaMCU" jest nieco lepszy, ponieważ ma usunięte niepotrzebne rzeczy i może mieć większą przestrzeń LFS (mniejszy plik OTA), ale w wielu przypadkach nie ma to znaczenia.

    blacksun2 napisał:

    Krótko mówiąc, czy istnieje przegląd tego, co oznaczają skróty i gdzie można dowiedzieć się, kiedy użyć której wersji?

    @divadiow Myślę, że musimy to dodać
    Pomogłem? Kup mi kawę.
  • #22 21603630
    divadiow
    Poziom 38  
    Posty: 5209
    Pomógł: 446
    Ocena: 914
    Tak, wyobrażam sobie, że wiele rzeczy mogłoby być jaśniejszych. Musi to być nie lada zadanie, gdy po raz pierwszy spojrzysz na OBK (pamiętam, że tak było! I nadal czasami jest). Tasmota ma tę zaletę (?), że jest tylko Espressif, więc droga do uwolnienia urządzenia z chmury jest nieco węższa (choć pełna konfiguracja niekoniecznie łatwiejsza - jak wskazano).

    Ale tak, niektóre urządzenia mogą być łatwiejsze niż inne, wymagając tylko szablonu widocznego na liście urządzeń. Niektóre mogą być urządzeniami TuyaMCU ze standardową komunikacją TuyaMCU i wymagać konfiguracji autoexec, podczas gdy inne mogą być urządzeniami TuyaMCU z niestandardowym protokołem. Niektóre urządzenia mogą wymagać nowych sterowników. Jest tak wiele wariantów i możliwości. Następnie, jak mówisz, zmiana jest wprowadzana przez Tuya/OEM i konieczne jest ponowne dostosowanie.

    Dodano po 6 [minutach]: .

    Warto również zauważyć, że niektóre konfiguracje autoexec mogą dyktować zachowanie urządzenia w oparciu o preferencje autora, zamiast ściśle przestrzegać domyślnych ustawień fabrycznych - więc czasami może istnieć pewna elastyczność lub niejednoznaczność.

    Dodano po 25 [minutach]: .

    przerobiona strona listy urządzeń, jak wskazano tutaj https://www.elektroda.com/rtvforum/topic4126651.html#21582086 może być uruchomiona. Jeśli użytkownik jest świadomy podświetlenia "TuyaMCU" (lub innego wskaźnika), może to pomóc. Prawdopodobnie musi istnieć wyraźny punkt początkowy podróży dla użytkowników, a następnie intuicyjne oznakowanie od tego punktu, aby pomóc.
  • #24 21690537
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    Ok, więc moim pierwszym zmartwieniem jest to, że podzielił sterownik i dodał "TuyaMCULE", więc zepsułoby to istniejące skrypty i przewodniki...
    Pomogłem? Kup mi kawę.
  • #25 21791482
    protectivedad
    Poziom 9  
    Posty: 40
    Pomógł: 2
    Ocena: 5
    Przesłałem żądanie ściągnięcia https://github.com/openshwprojects/OpenBK7231T_App/pull/1914, które dodaje obsługę urządzeń zasilanych bateryjnie i korzystających z wersji 3 komunikacji TuyaMCU. Implementacja TuyaMCU tych urządzeń nie pozwala na żądanie statusu czujników. Status czujnika jest przesyłany do modułu Wi-Fi dopiero po tym, jak moduł Wi-Fi poinformuje TuyaMCU, że połączył się z Wi-Fi i serwerem MQTT. W tym czasie TuyaMCU używa polecenia 0x34 do przesłania informacji o czujniku.

    Na przykład:
    55 AA   03   34      00 0E   0B01000101010101016501000101   BE   
    HEADER   VER=03   Unk      LEN   0B01000101010101016501000101   CHK   
    

    Wcześniej te pakiety były ignorowane.

    PR pozwala na przetwarzanie tych pakietów i aktualizację statusu czujników po ich połączeniu. Dla mojego czujnika drzwi ZY-D02 używam:
    // tuyaMCU
    startDriver tuyaMCU
    
    // dpID 101 is contact sensor - closed(0), open(1)
    linkTuyaMCUOutputToChannel 101 bool 1
    setChannelType 1 ReadOnly
    
    // dpID 102 is battery state - low(0), mid(1) and high(2)
    linkTuyaMCUOutputToChannel 102 enum 3
    setChannelType 3 ReadOnlyLowMidHigh


    Dzięki tej konfiguracji komunikacja sterownika z TuyaMCU:
    Heartbeat
    Informacje o produkcie
    Konfiguracja MCU
    Status Wifi
    a po podłączeniu do MQTT czujnik odeśle wszelkie zmiany od ostatniego połączenia MQTT:
    Aktualizacja czujnika 1
    Aktualizacja czujnika 2
    Aktualizacja czujnika ...

    Po czym sterownik wyśle:
    Heartbeat
    Heartbeat
    ...

    Dopóki TuyaMCU nie odetnie zasilania modułu wifi. W przypadku urządzeń bateryjnych nie jest to pożądane, ponieważ zużywa dodatkową energię baterii bez celu.

    Tak więc istnieje dodatkowe polecenie:


    Uruchomienie tuya_powerSave ograniczy komunikację do:
    Informacje o produkcie
    Wifi Status
    a po podłączeniu do MQTT czujnik odeśle wszelkie zmiany od ostatniego połączenia MQTT:
    Sensor Update 1
    Aktualizacja czujnika 2
    Aktualizacja czujnika ...

    Odzwierciedla to protokół komunikacyjny w wersji 0. Powinno to również zmniejszyć zużycie baterii, choćby z tego powodu, że komunikacja na liniach TX/RX wymaga mocy obliczeniowej i czasu.
  • #26 21791730
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    To interesujące, więc są jak.... 3 rodzaje TuyaMCU? Byłem pewien, że mamy tylko zasilane sieciowo TuyaMCU i zasilane bateryjnie tmSensor.

    Pamiętam też, że widziałem twoje pytanie:
    Cytat:

    Kiedy BK7238 jest ponownie zasilany, kanały są zerowane, a następnie, gdy TuyaMCU wysyła status, są wypełniane. Problem polega na tym, że 0 jest takie samo jak zamknięte drzwi. Więc ignoruje aktualizację i nie publikuje do MQTT. Czy sterownik TuyaMCU powinien wypełnić kanały wartościami z poprzedniego cyklu zasilania?

    Jestem świadomy tego problemu, ale nie testowałem go zbyt często, ponieważ urządzenia zasilane bateryjnie są z natury trudne w obsłudze i wolę Zigbee. Biorąc to pod uwagę, założyłem, że "publish self state on mqtt connect" załatwi sprawę, a jeśli nie, można ustawić wartość startową kanału na zapamiętywanie wartości między restartami (-1). Alternatywnie, może moglibyśmy załatać logikę kanałów, aby zawsze publikować, jeśli zasilanie bateryjne TuyaMCU jest uruchomione?
    Pomogłem? Kup mi kawę.
  • #27 21791914
    protectivedad
    Poziom 9  
    Posty: 40
    Pomógł: 2
    Ocena: 5
    Pracuję na dwóch różnych urządzeniach, TuyaMCU (BK7238) i nie-TuyaMCU (BK7231N), więc czasami problemy łączą się w mojej głowie.

    p.kaczmarek2 napisał:
    To ciekawe, więc są jak.... 3 rodzaje TuyaMCU?


    Na to wygląda. Przechwyciłem komunikację dla urządzeń TuyaMCU na firmware fabrycznym i OBK (przed moim PR). TuyaMCU wysyła wersję 3 i nie odpowiada na żadne żądania inne niż Hearbeat, Product ID, MCU Conf i Wifi Status. Tylko status Wifi wydaje się cokolwiek robić, co powoduje, że TuyaMCU wysyła wszelkie zmiany stanu i stan baterii za pomocą polecenia 0x34 po podłączeniu.

    p.kaczmarek2 napisał:
    można ustawić wartość startową kanału, aby zapamiętać wartość między restartami (-1).


    W przypadku TuyaMCU było to rozwiązanie z moim PR.

    To, co sprawiło mi pewne problemy, to fakt, że w przypadku urządzeń innych niż TuyaMCU użycie (-1) spowoduje uszkodzenie czujnika w pewnych warunkach. Jeśli więc ustawisz go na zapamiętywanie przez bootowanie (-1) i przejdzie w stan uśpienia (1), nigdy nie zmieni stanu po przebudzeniu. Musisz zmusić go do zmiany stanu z powrotem na (0) podczas czuwania, a następnie pozwolić mu zasnąć w stanie (0). Mój czujnik jest zamknięty w stanie (1). Więc jeśli czujnik jest zamknięty i przechodzi w stan uśpienia, otwarcie drzwi budzi czujnik, ale wartość nigdy się nie zmienia. Musisz zamknąć i ponownie otworzyć drzwi, gdy czujnik jest uśpiony, a następnie opublikuje wartość otwarcia. Spędziłem trochę czasu, próbując dowiedzieć się, gdzie jest problem i miałem zamiar dodać problem, ale nie-TuyaMCU działa z ustawieniem Startup (0), więc zostawiłem to w spokoju.
  • #28 21791945
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    Ahh... więc ta komenda TuyaMCU "powerSave" tak naprawdę nie oszczędza energii? Po prostu włącza tryb zasilania bateryjnego? Musiałem cię źle zrozumieć. Może trzeba zmienić jej nazwę, żeby pasowała do tego, jak działa.

    Poza tym, czy to jest gotowe do scalenia?
    Pomogłem? Kup mi kawę.
  • #29 21791977
    protectivedad
    Poziom 9  
    Posty: 40
    Pomógł: 2
    Ocena: 5
    Niestety, jest to trochę błędne określenie.

    p.kaczmarek2 napisał:
    To po prostu włączenie trybu bateryjnego?

    Nie. W moich dodatkach nie ma czegoś takiego jak "tryb zasilania bateryjnego". Mój PR robi dwie rzeczy:
    1) Przetwarzanie komend 0x34 z TuyaMCU;
    2) Polecenie zmniejszające ruch między TuyaMCU a modułem WiFi.

    Pierwsza z nich umożliwia działanie urządzeń takich jak moje, a druga pozwala na dłuższe działanie baterii.

    Daj mi znać, jeśli chcesz zmienić składnię.

    p.kaczmarek2 napisał:
    Poza tym, czy to jest gotowe do scalenia?


    Tak.
  • #30 21791984
    p.kaczmarek2
    Moderator Smart Home
    Posty: 14755
    Pomógł: 659
    Ocena: 12877
    Więc chyba lepiej nazwać to tuyaMcu_batteryPoweredMode zamiast powerSave, ale może masz lepszy pomysł? Wiesz, teraz to jedyny czas, kiedy możemy to zmienić, kiedy już to scalimy i ludzie zaczną tego używać, nie będzie łatwego sposobu na zmianę nazwy bez zepsucia konfiguracji.
    Pomogłem? Kup mi kawę.
Słuchaj:

Podsumowanie tematu

LABEL_AI_GENERATED
Dyskusja dotyczy szczegółowego przewodnika po flashowaniu, instalacji i konfiguracji protokołu TuyaMCU w urządzeniach z firmware OpenBeken (OBK) oraz integracji z Home Assistant. Omówiono metody ekstrakcji i mapowania identyfikatorów dpID na kanały sterujące, w tym ograniczenia numeracji kanałów (maksymalnie 64 kanały obsługiwane). Przedstawiono przykłady konfiguracji autoexec.bat z przypisaniem typów kanałów (np. Toggle, TextField, enum) i mapowaniem dpID do kanałów, co umożliwia publikację stanów urządzeń w Home Assistant. Poruszono problem obsługi urządzeń bateryjnych TuyaMCU, które komunikują się w wersji 3 protokołu, gdzie status czujników jest przesyłany po połączeniu Wi-Fi i MQTT za pomocą komendy 0x34. Wprowadzono nową komendę tuyaMcu_batteryPoweredMode (wcześniej powerSave) do optymalizacji zużycia energii i poprawy stabilności komunikacji. Dyskutowano o automatycznym ładowaniu sterownika TuyaMCU przez przypisanie do pinów RX/TX, co ułatwia konfigurację i zmniejsza ryzyko błędów podczas flashowania. Przedstawiono również optymalizacje czasów uruchamiania i połączenia MQTT, skracające czas publikacji stanu do około 2,8-3 sekund. Wskazano na różnorodność urządzeń TuyaMCU, w tym zasilanych bateryjnie i sieciowo, oraz na potrzebę indywidualnej konfiguracji i testów. Podkreślono, że TuyaMCU wymaga ręcznej konfiguracji autoexec.bat, a integracja z Home Assistant jest możliwa dzięki mapowaniu dpID na kanały i odpowiedniemu typowi danych. W dyskusji pojawiły się także propozycje ulepszeń GUI i dokumentacji oraz sugestie tworzenia dedykowanych przewodników dla konkretnych modeli urządzeń.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA