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

Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

Selfdrivers 31 Sty 2024 00:05 4800 52
  • Cześć wszystkim, niedawno kupiłem taki oto bezpiecznik w formacie DIN wraz z opcją pomiaru zużycia kWh. Jest to model TO-Q-SYS-JWT czyli wersja podobna do TO-Q-SY1-JWT jednak z wyświetlaczem wbudowanym na którym można dokonywać zmian w ustawieniach bezpiecznika (zabezpieczenia undervoltage, overvoltage, temperaturowe, mocowe itp.). Na zdjęciu poniżej możemy zobaczyć urządzenie (sam front po fazie rozebrania).

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Patrzyłem na forum w poszukiwaniu tego modelu bezpiecznika jednak bezskutecznie (jest to totalna nowość na forum więc postanowiłem napisać ten wpis).

    Zacznijmy od podstaw, aby rozebrać sam bezpiecznik należy "wydłubać" metalowe piny które trzymają go "w kupie" (jest ich sześć i strona od której zaczniemy nie jest istotna gdyż ważne aby zagiąć rant kołka do środka a następnie delikatnie wybić pręcik), piszę o tym kroku gdyż sam szukałem dość długo jak rozebrać tego typu bezpiecznik MCB. Gdy wydłubiemy już wszystkie pręty (są złote więc łatwo je zobaczyć) po bokach należy delikatnie podważyć zatrzaski widoczne na wierzchu obudowy. Po tych krokach powinniśmy mieć już otwarty przełącznik MCB.

    Przejdźmy teraz do najciekawszego etapu czyli wnętrza, które prezentuje się tak:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem


    Widzimy tutaj (jak zakładam dobrze, przekaźnik 60A 250V firmy "AT"[?]) oraz dość ciasno upakowane układy scalone. Całość składa się z trzech płytek PCB. Pierwszą jesteśmy w stanie łatwo wyciągnąć po wykręceniu śrubki w prawym górnym rogu PCB (mając MCB lewą stroną skierowany do nas). Po wyjęciu całość prezentuje się tak:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Płytka, która wychodzi pierwsza jest tą która interesuje nas najbardziej gdyż odpowiada ona za łączność WiFi, właściwie na tym etapie rozbierania MCB moglibyśmy poprzestać jednak z racji iż na forum nie ma tego urządzenia jeszcze, zajrzymy dalej do środka.

    Sama płytka z BK7231N prezentuje się tak:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Ja aby wgrać oprogramowanie OpenBeken musiałem białą płytkę odlutować od płytki niebieskiej, która właściwie jedyne co robi to łączy nam płytkę E469716 z resztą MCB. Całość po wylutowaniu wygląda tak:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Płytka z modułem WiFi wydaje się być normalną płytką jednak po odczytaniu oprogramowania otrzymamy następujący wynik analizy configu tuya:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Oprogramowanie do flashowania sugeruje nam iż jest to prawdopodobnie TuyaMCU jednak nie zgadzam się z tym wnioskiem, tak ubogi config wynika po prostu z faktu iż moduł WiFi jedyne za co odpowiada w tym MCB to komunikacja z WiFi i przesył danych, nie steruje on bezpośrednio niczym a jedynie poprzez komendy wykonuje powierzone mu zadania (a raczej przekazuje). Zadania te przekazuje do mikrokontrolera HC32F460, który to znajduje się na płytce z wyświetlaczem (OLED?) i nim steruje. Płytka z wyświetlaczem prezentuje się tak:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    HC32F460 jest najwyraźniej klonem bardziej znanego stm32f103c8t6 i wedle datasheet posiada ona złącza i2c do komunikacji z wyświetlaczem OLED lub innymi peryferiami (samych protokołów jest oczywiście znacznie więcej a ja poruszam tutaj te które nas dotyczą), oraz magistralę UART która to właśnie jest wykorzystywana do komunikacji z modułem WiFi (baudrate to zapewne 115200 gdyż taki jest ustawiony w konfiguracji modułu WiFi aczkolwiek mogę się mylić i dotyczy to czegoś innego). Sam uC posiada również pamięć EEPROM wbudowaną w siebie więc na pozostałych płytkach nie znajduje się żadna kość EEPROM (raczej nie gdyż nie byłem w stanie odczytać oznaczeń jednej z kości na płytce PCB - zdjęcie poniżej).

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Druga kość, którą możemy znaleźć na płytce (HT7017?):

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Kość ta wygląda na kość wykonującą pomiar zużycia energii.

    Cały tył płytki PCB (głównej największej wygląda tak):

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Przesyłam również wsady (z oryginalnym software) z płytki z BK7231N.


    Jeśli chodzi o konfigurację całego MCB to jest to problem z którym jeszcze się nie uporałem (zakładam że należy wysłać odpowiednie komendy TuyaMCU do HC32F460 jednak nadal nie wiem jak dokładnie to ugryźć i stąd prosiłbym również o delikatne wsparcie techniczne tak aby stworzyć plik konfiguracyjny specjalnie dla tego MCB z pomiarem zużycia energii.

    NOTE: Wyświetlacz, pamięć stanu bezpiecznika, przyciski itp. działają poprawnie nawet po wgraniu OpenBeken, wynika to z faktu iż BK7231N nie steruje tymi peryferiami więc jakiekolwiek zmiany w jego sofcie nie zmieniają działania licznika (jedynie "ogłupiają" go o funkcje łączenia się z WiFi i wysyłaniem danych do aplikacji z chin). Samego MCB nie podłączam na razie dopóki nie uda mi się stworzyć pliku konfiguracyjnego (wspólnymi siłami mam nadzieję :) ) dla tego urządzenia. MCB jest aktualnie podłączone do dummy load tak aby móc mieć łatwy dostęp w razie potrzeby oraz aby można było dokonać ew. kalibracji na podstawie znanego obciążenia.

    Fajne? Ranking DIY
    O autorze
    Selfdrivers
    Poziom 8  
    Offline 
    Specjalizuje się w: programista
    Selfdrivers napisał 35 postów o ocenie 11. Mieszka w mieście Zielona Góra. Jest z nami od 2015 roku.
  • #2 20937562
    gulson
    Administrator Systemowy
    Bardzo ciekawe, bezpiecznik, pomiar prądu i sterowanie/odczytywanie przez aplikacje w jednym.
    Dzięki za podzielenie się demontażem bezpiecznika i informacją o zmianie oprogramowania.
    Jak podasz mi Paczkomat to wyślę mały upominek.
  • #3 20937688
    nyquist
    Poziom 26  
    Selfdrivers napisał:
    Kość ta wygląda na kość wykonującą pomiar zużycia energii


    Artykuł ciekawy i brawo za to, że używa Kolega prawidłowego sformułowania mówiąc o "zużyciu energii", podczas, gdy dzisiaj z każdej strony, zaczynając od reklam w tv, a kończąc na wystąpieniach polityków, wszyscy starają się nas przekonać, że "zużywamy prąd" i "płacimy za prąd"! brrr...
  • #4 20937729
    CosteC
    Poziom 38  
    Jest jakaś dokumentacja do tego, czy jest to kolejny chiński ulep, urągający bezpieczeństwu i zdrowemu rozsądkowi?
    Boli mnie jak patrzę na zdjęcia, ale to zapewne zboczenie zawodowe, ze oczekuję zdjęć na których widać jakieś szczegóły.
  • #6 20938044
    CosteC
    Poziom 38  
    Cytując "producenta" to jest "Smart WiFi Switch with metering function – TO-Q-SY1-JWT"
    Bezpiecznikiem to nie jest i nie może pełnić żadnych funkcji zabezpieczających per se. Można by niby to podciągnąć pod funkcję "sterującą" wyłączającą obciążenie gdy wzrośnie prąd, ale patrząc na jakość dokumentacji u "producenta", która jest żałosna, że nawet temu nie warto za bardzo ufać. To nie ma nawet podanej kategorii instalacyjnej i prawie żadnych wymaganych oznaczeń.
    Pomiary... Pomiary są zgodne z niczym i oferują dokładnie żadną dokładność. Tyle oferuje "producent" na swojej stronie.

    Gorąco polecam takie kwiatki techniczne jak "Current Frame: 63A (Suggest under 40A)" jednocześnie: "Rated Current (In) 1A, 2A, 3A, 4A, 5A, 6A, 16A, 20A, 25A, 32A, 40A, 50A, 63A"

    https://elcb.net/product/to-q-sy1-jwt-din-rail-smart-wifi-switch-with-metering-function/
  • #7 20938270
    Selfdrivers
    Poziom 8  
    >>20937729
    Nie do końca wiem o co chodzi ze zdjęciami ale niektóre są prześwietlone specjalnie aby było widać dokładnie oznaczenie chip-u który się tam znajduje. Jestem zawsze otwarty na sugestie :) . Jeśli chodzi o dokumentacje to są szczątkowe, wiadomo BK7231N ma dostępną jednak jeśli o np, klon STM32 to niestety ale jakiś lakoniczny opis wraz z schematami PCB i tyle, żadnych dokładniejszych informacji o rejestrach etc. Co do reszty podzespołów próbowałem szukać ale nic nie znalazłem.
  • #8 20938300
    p.kaczmarek2
    Moderator Smart Home
    Selfdrivers napisał:

    Jeśli chodzi o konfigurację całego MCB to jest to problem z którym jeszcze się nie uporałem (zakładam że należy wysłać odpowiednie komendy TuyaMCU do HC32F460 jednak nadal nie wiem jak dokładnie to ugryźć i stąd prosiłbym również o delikatne wsparcie techniczne tak aby stworzyć plik konfiguracyjny specjalnie dla tego MCB z pomiarem zużycia energii.


    Widzę, że urządzenie będzie uwalniane od chmury. Aby uruchomić je w OpenBeken, trzeba znać baud rate TuyaMCU, oraz dpID (identyfikatory) zmiennych wraz z ich typami, bo one się zmieniają od urządzenia do urządzenia.

    Ogólnie są trzy możliwości rozgryzienia tego.
    1. Możesz dokonać przechwycenia i analizy pakietów na urządzeniu przed zmianą firmware:
    https://www.elektroda.pl/rtvforum/topic3970199.html I wtedy obserwować np co jest przesyłane gdy podłączysz obciążenie np. 60W (i szukać w wartościach zmiennych liczby 60 lub raczej 600 bądź 6000)
    2. Możesz spróbować dostać dpIDs od Tuya:
    Wyodrębnianie identyfikatorów DpID dla urządzeń TUYA MCU
    3. Jak już jest zmienione firmware to po prostu wgraj na OpenBeken jakiś autoexec.bat prosty stąd:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Może:
    
    // 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
    

    a potem restart urządzenia i użyj komendy tuyaMcu_sendQueryState, patrz lista komend:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    Jeśli urządzenie nic nie zgłosi, to zakomentuj linijkę z baud rate, by był użyty domyślny 9600 i wykonaj power off/on całości.
    Powtórz procedurę, wtedy tuyaMcu_sendQueryState powinno otrzymać jakieś dane.
    Potem musisz patrzeć co jest wysyłane pod jakim dpID i odgadywać co może być czym, np. wartośc 2300 to może byc napięcie a dokładniej napięcie razy 10, itd... i znowu, podłącz np. obciążenie 60W i szukaj które dpID ma wartość np. te 60, lub 600, itd. Jak już odgadniesz, to mapujesz to kanały OBK, patrz wspomniane już przykłady autoexec

    Możesz wpisać tutaj słowo kluczowe "TuyaMCU" i znajdą Ci się tematy urządzeń powiązane na Elektrodzie:
    https://openbekeniot.github.io/webapp/devicesList.html
    Pomogłem? Kup mi kawę.
  • #9 20938473
    __Maciek__
    Poziom 20  
    Dodam jeszcze jedną ciekawostkę ... otóż przekaźniki w tych urządzeniach chyba są bistabilne - tam jest ciekawy układ pełnego mostka do sterowania przekaźnikiem w obudowie sot23-6 - podobne mam w selektorze faz - to uważam za plus w statycznej pracy nie pobierają prądu - sprawdź czy logika wyłącza przekaźnik przy wyłączeniu zasilania, w selektorze starcza na to energii.

    W obudowie SO8 masz przetwornicę DC/DC główny zasilacz prawdopodobnie 12V, na części z układem pomiarowym druga przetwornica na zasilanie logiki 3,3V.

    Generalnie coraz więcej tego typu chińskich wynalazków.
  • #10 20938495
    p.kaczmarek2
    Moderator Smart Home
    Rzeczywiście spotykam przekaźniki bistabilne w tego typu sprzętach. W TONGOU TO-Q-SY1-JWT i Zmai90 też taki widziałem. W OBK napisaliśmy do tego sterownik Bridge. Ale by nie wprowadzać nikogo w błąd, od razu napiszę, że jak jest urządzenie na TuyaMCU (takie jak z pierwszego postu) to nie powinno się uruchamiać sterownika Bridge, bo przekaźnikiem steruje MCU, nie moduł WiFi.
    Pomogłem? Kup mi kawę.
  • #11 20938576
    Selfdrivers
    Poziom 8  
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Takie coś otrzymałem w konsoli po uruchomieniu TuyaMCU (zapomniałem o tym kompletnie wczoraj gdy pisałem post), wygląda na to że w powyższym komunikacie są podane dpId (czytałem właśnie post Twój o TuyaMCU i kombinowałem z tym), na razie bezskutecznie próbuję chociaż wysterować przekaźnik aby działał tak jak powinien (on/off). Jeśli chodzi o ustawienie stanu WiFi to faktycznie powyższe komendy skonifgurowały poprawnie stan WiFi (jest teraz na ON) jak tylko uda mi się coś opracować/ustalić to napiszę.

    W najbliższym czasie też planuje kilka nowych urządzeń IoT do smathome kupić więc może akurat coś nowego będę mógł wrzucić, zawsze to doprowadzi do jakiegoś dalszego rozwoju projektu który bardzo szanuje i podziwiam i chciałbym w jakimś stopniu się do niego dołożyć :).
  • #12 20938603
    p.kaczmarek2
    Moderator Smart Home
    Wrzucaj wszystkie urządzenia IoT jakie masz, jedynie proszę nie robić duplikatów istniejących tematów, chcemy dobić do 500 urządzeń wkrótce:
    https://openbekeniot.github.io/webapp/devicesList.html
    Aż boję się sprawdzić, ile z nich to moje tematy. Jestem pewny, że pobiłem tu jakiś rekord.

    Twój zrzut ekranu świadczy o tym, że komunikacja działa, chociaż nie podoba mi się ta sytuacja z dpID 138 po którym jest "35 unwanted non-header bytes", czyżby był błąd w parserze? A może to jednorazowe zakłócenie? Z tego powodu czasem warto przechwycić komunikację na oryginalnym firmware, ale może damy radę i bez tego.

    Natomiast dpID 141 typu boolean może być przekaźnikiem.

    Jeśli tak, to nowy autoexec.bat wygląda:
    
    
    // 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
    
    
    // set channel types for OBK GUI (and Hass Discovery)
    setChannelType 1 toggle
    // linkTuyaMCUOutputToChannel dpId verType tgChannel
    linkTuyaMCUOutputToChannel 141 bool 1
    
    
    

    O ile dpID 141 typu bool to rzeczywiście stan przekaźnika, a moduł WiFi może zmieniać stan przekaźnika (nie to jest to jakimś cudem read-only), to powyższy kod powinien pozwolić Ci sterować tym przekaźnikiem z panelu OBK. Po wykonaniu HASS discovery też z poziomu HA powinno być sterowanie.
    Pomogłem? Kup mi kawę.
  • #14 20939995
    p.kaczmarek2
    Moderator Smart Home
    Spróbuj ponownie komendy z query. Czy za każdym razem się wysypuje z błędem po kilku ID?

    Czy to urządzenie pozwala fizycznym przyciskiem zmienić stan przekaźnika? Fizyczna operacja sprawi, że MCU wyśle zmiane stanu do modułu WiFi i wtedy zobaczysz dpID przekaźnika.
    Pomogłem? Kup mi kawę.
  • #15 20940932
    artin.bruyen
    Poziom 16  
    Gdzie to "urządzenie" można znaleźć w internecie? Jakiś opis, zdjęcia, cena? Moje google nic o tym nie wie. :(
  • #16 20941591
    Selfdrivers
    Poziom 8  
    artin.bruyen napisał:
    Gdzie to "urządzenie" można znaleźć w internecie? Jakiś opis, zdjęcia, cena? Moje google nic o tym nie wie. :(


    https://a.aliexpress.com/_EyCIK5X

    Na aliexpress kupowałem na tej aukcji.

    Dodano po 58 [minuty]:

    p.kaczmarek2 napisał:
    Spróbuj ponownie komendy z query. Czy za każdym razem się wysypuje z błędem po kilku ID?

    Czy to urządzenie pozwala fizycznym przyciskiem zmienić stan przekaźnika? Fizyczna operacja sprawi, że MCU wyśle zmiane stanu do modułu WiFi i wtedy zobaczysz dpID przekaźnika.


    Udało mi się ustalić że przekaźnik ma dpID 16, (ale np dpID 11 wyłącza przekaźnik bez możliwości jego ponownego włączenia, wygląda trochę na to że to jest sygnał "bezpieczeństwa"), próbuję teraz ustalić gdzie są wartości zużycia energii itp. Nie wiem czemu ale podczas przestawiania stanu przekaźnik przyciskiem nie widać zmiany stanu urządzenia o dpID 16 jednak sam toggle wyłapuje tą zmianę i pokazuje poprawny i aktualny stan przekaźnika. Nie wiem czemu ale no nieważne, ważne że widzi stan przekaźnika.

    Tak wygląda odpowiedź TuyaMCU zaraz po jej uruchomieniu:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Taki jest efekt wykonania komendy tuyaMcu_sendQueryState:

    Cytat:
    aMCU:TuyaMCU_ApplyMapping: id 118 with value 1000 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 77 02 00 04 00 00 07 D0 65
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 119, dataType 2-val and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 2000
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 119 with value 2000 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 78 02 00 04 00 00 00 0A 99
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 120, dataType 2-val and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 10
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 120 with value 10 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 83 02 00 04 00 00 01 55 F0
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 131, dataType 2-val and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 341
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 131 with value 341 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 89 02 00 04 00 00 02 58 FA
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 137, dataType 2-val and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 600
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 137 with value 600 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 6F 01 00 01 00 7F
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 111, dataType 1-bool and 1 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 0
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 111 with value 0 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 8D 01 00 01 00 9D
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 141, dataType 1-bool and 1 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 0
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 141 with value 0 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 8C 02 00 04 00 00 00 05 A8
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 140, dataType 2-val and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 5
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 140 with value 5 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 8E 04 00 01 02 A3
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 142, dataType 4-enum and 1 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 2
    Debug:TuyaMCU:TuyaMCU_ApplyMapping: id 142 with value 2 is not mapped
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 04 8A 03 00 00 9A
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 11 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 138, dataType 3-str and 0 data bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 34 00 01 04 3B
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 52 (Unknown) with 8 bytes


    Co ciekawe ciągle otrzymuję takie komunikaty (zwłaszcza po ustawieniu stanu WiFi na 4 czyli connected):

    Cytat:
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 34 00 01 04 3B
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 52 (Unknown) with 8 bytes
    Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 52


    nie do końca wiem co to oznacza i jakie dane ma to na celu przenieść, raczej nie jest to wartość zużycia energii gdyż przy włączeniu obciążenia wartość nie zmienia się.
  • #17 20942168
    p.kaczmarek2
    Moderator Smart Home
    Nie spotkałem jeszcze urządzenia z komendą 52 (0x34). Wygląda na to, że oni serio ciągle muszą coś zmieniać i dodawać nam roboty. Poszukałem informacji i wygląda na to, że to jest:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Zwane również jako:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Powiązane:
    https://developer.tuya.com/en/docs/iot/advanced-features?id=Kav0qqgzfj95f
    https://github.com/kangkoilxu/SmartPetFeeder/blob/main/system.cpp
    Otrzymujesz dane 55 AA 03 34 00 01 04 3B czyli:
    55 AA - nagłówek
    03 - wersja
    34 - typ pakietu
    00 01 - długość
    04 - dane
    3B - suma kontrolna
    Wg. powyższego kodu (przetłumaczone z chińskiego na angielski):
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    jest to:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Niestety nawet znaleziony kod nie pokazuje jak obsługują 0x04 a do tego u nas 0x04 nie ma długości 0x02, ale dodałem chociaż podstawę parsingu tego pakietu do nas:
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem
    https://github.com/openshwprojects/OpenBK7231...mmit/e9493e5520f29d765d2eeb6bee2b3225880a70fa
    W dokumentacji Tuya jednak jest coś więcej:
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem
    Wygląda na to, że moduł WiFi powinien odpowiedzieć 55 aa 00 34 00 02 04 00 39 ale nie widzę by to nas przybliżało do pobrania pomiarów... mogę spróbować tą odpowiedź zaimplementować, o ile w innych pakietach nie ma nic użytecznego
    Pomogłem? Kup mi kawę.
  • #18 20942478
    Selfdrivers
    Poziom 8  
    Nie jestem pewny w sumie czy to by przybliżyło nas do odebrania pomiarów zużycia energii jednak jakbym nie próbował i kombinował to nie mogę zmusić TuyaMCU do podania mi dpID na którym znajduje się wartość zużycia energii/zużytej energii/napięcia/natężenia/mocy.

    Udało mi się ustalić to:

    Cytat:

    startDriver TuyaMCU
    tuyaMcu_setBaudRate 115200
    tuyaMcu_defWiFiState 4
    setChannelType 1 toggle
    setChannelType 2 TextField
    setChannelType 3 TextField
    setChannelType 4 TextField
    setChannelType 5 TextField
    setChannelType 6 TextField
    linkTuyaMCUOutputToChannel 16 bool 1
    linkTuyaMCUOutputToChannel 114 2 2
    linkTuyaMCUOutputToChannel 115 2 3
    linkTuyaMCUOutputToChannel 116 2 4
    linkTuyaMCUOutputToChannel 118 2 5
    linkTuyaMCUOutputToChannel 119 2 6
    tuyaMcu_sendQueryState


    Powyższy skrypt uruchamia moduł TuyaMCU a następnie ustawia odpowiednio pola na textField tak aby można było zmieniać ustawienia TRIP-a kiedy ma zostać wyłączony przekaźnik, część z tych ID strzelałem część TuyaMCU mi pokazała przy wykonaniu komendy podającej stan urządzenia. dpID kolejno odpowiadają za:

    Cytat:
    16 - relay control (toggle)
    114 - over current setting (2 val 4 data bytes)
    115 - over voltage setting (2 val 4 data bytes)
    116 - under voltage setting (2 val 4 data bytes)
    118 - over temperature shutdown (2 val 4 data bytes) (value is multiplied by 10 so 92 degrees is 920)
    119 - over power protection (2 val 4 data bytes)


    nic więcej na razie nie wskurałem, i powoli nie mam pomysłów jak wykrywać te dpID gdyż nawet przestawianie wartości ręczne (na przekaźniku bezpośrednio) czy też zmiana stanu za pomocą toggle czy też wysłanie komendy, która pokazuje stan urządzeń nic nie daje.

    Jeśli chodzi o moje zdanie to faktycznie coś może być w tym że moduł musi wysłać odpowiedź żeby TuyaMCU odpowiedziała aktualnymi wartościami zużycia energii, nie da się po prostu wysłać "na sztywno" tej wartości jakąś komendą tylko dla testu czy to cokolwiek da? Widziałem gdzieś komendy które wysyłają wartości HEX, nie ma może takiej która wyśle całą wiadomość z poziomu konsoli?

    Pytanie z innej beczki teraz, jak mogę usunąć kanał? Mam aktualnie ustawiony kanał 10 jako textField (ale nie używam go) i chciałbym go usunąć całkowicie albo ukryć, szukałem w dokumentacji ale nie udało się nic zdziałać.

    EDIT:

    Pomijam na razie możliwość ustawiania czasu po jakiego upłynięciu dochodzi do wyłączenia przekaźnika (np 26A musi być przez 5 sekund aby moduł zareagował) i takie wartości również można zmieniać z pomocą komendy, co prawda nie ustaliłem ich dpID ale myślę że to aż taki priorytet na chwilę aktualną nie jest, bardziej zależy mi na odczycie wartości zużycia energii/napięcia etc.

    EDIT2:

    wykonałem komendę uartSendHex 55 aa 00 34 00 02 04 00 39 i efektem jest to że nie dostaję już tego zapytania z nagłówkiem 52, przychodzi tylko heartbeat plus pytania o RSSI i czasami status urządzeń jednak nadal brak zużycia energii gdziekolwiek, jednak myślę że taka odpowiedź mogłaby zostać dodana gdyż przestaje wtedy ciągle MCU wysyłać te durne pytanie o info o restarcie plus można dodać np. przy restarcie (ale to już w autoexec) żeby wysyłał komendę restartu, wtedy teoretycznie będzie to działać tak jak z fabryki.
  • #19 20942514
    p.kaczmarek2
    Moderator Smart Home
    Selfdrivers napisał:
    Nie jestem pewny w sumie czy to by przybliżyło nas do odebrania pomiarów zużycia energii jednak jakbym nie próbował i kombinował to nie mogę zmusić TuyaMCU do podania mi dpID na którym znajduje się wartość zużycia energii/zużytej energii/napięcia/natężenia/mocy.

    Czasami bywa prościej, czasem trudniej, dpID nie są u Tuya standaryzowane. Jak z @xury opracowywałem inne urządzenie do pomiary były od razu dostępne.

    Czy nie masz wysyłanych jakiś dpID typu raw bądź string?

    Selfdrivers napisał:

    nic więcej na razie nie wskurałem, i powoli nie mam pomysłów jak wykrywać te dpID gdyż nawet przestawianie wartości ręczne (na przekaźniku bezpośrednio) czy też zmiana stanu za pomocą toggle czy też wysłanie komendy, która pokazuje stan urządzeń nic nie daje.

    W wielu urządzeniach to starczało, w Twojej sztuce coś musi być inaczej zrealizowane.

    Na pewno polecane jest często wykonywanie przechwytywania TuyaMCU na oryginalnym sofcie:
    Analizator TuyaMCU - dekoder pakietów UART dla urządzeń Tuya - dpID detektor

    Mogę też dopisać do kodu odpowiedź na 0x34.



    Selfdrivers napisał:

    Jeśli chodzi o moje zdanie to faktycznie coś może być w tym że moduł musi wysłać odpowiedź żeby TuyaMCU odpowiedziała aktualnymi wartościami zużycia energii, nie da się po prostu wysłać "na sztywno" tej wartości jakąś komendą tylko dla testu czy to cokolwiek da? Widziałem gdzieś komendy które wysyłają wartości HEX, nie ma może takiej która wyśle całą wiadomość z poziomu konsoli?

    Jest, ale trzeba wiedzieć co chcemy wysyłać.
    Mamy:
    - uartSendHex
    - tuyaMcu_sendState
    - itd
    Lista komend: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md


    Selfdrivers napisał:

    Pytanie z innej beczki teraz, jak mogę usunąć kanał? Mam aktualnie ustawiony kanał 10 jako textField (ale nie używam go) i chciałbym go usunąć całkowicie albo ukryć, szukałem w dokumentacji ale nie udało się nic zdziałać.

    W Web App:
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem


    Selfdrivers napisał:

    zależy mi na odczycie wartości zużycia energii/napięcia etc.

    Oto moje sugestie co można zrobić:
    1. pobawić się tuyaMcu_sendQueryState i patrzeć co jest wysyłane, może jest jakiś pakiet typu RAW (bajty) lub String (tekst ASCII)? Np. jakieś dpId wysyłające chociażby 12 bajtów, po 4 bajty na prąd, napięcie i moc? W niektórych urządzeniach tak bywa
    2. wedle dokumentacji Tuya odpowiedź na 55 AA 03 34 00 01 04 3B to domyślnie 55 aa 00 34 00 02 04 00 39, wpisałem to w kod w tym PR:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1058/
    możesz spróbować pobrać z tego PR nową binarkę, wykonać OTA i sprawdzić co się dzieje
    3. w ostateczności można przywrócić flash Tuya ( BK7231GUIFlashTool w opcji backup and flash robi jego kopię 2MB) i wykonać przechwytywanie pakietów, to rozwiąże wszelkie wątpliwości
    Pomogłem? Kup mi kawę.
  • #20 20942524
    Selfdrivers
    Poziom 8  
    Jak pisałem w edicie poprzedniej odpowiedzi wykonałem komendę uartSendHex 55 aa 00 34 00 02 04 00 39 i efekt jest taki że nie dostaję już ciągłych pytań od MCU i logi się "uspokoiły", nadal jednak szukam wartości zużycia energii.

    EDIT:

    aktualny autoexec wygląda tak:

    Cytat:
    startDriver TuyaMCU
    tuyaMcu_setBaudRate 115200
    tuyaMcu_defWiFiState 4
    setChannelType 1 toggle
    setChannelType 2 TextField
    setChannelType 3 TextField
    setChannelType 4 TextField
    setChannelType 5 TextField
    setChannelType 6 TextField
    linkTuyaMCUOutputToChannel 16 bool 1
    linkTuyaMCUOutputToChannel 114 2 2
    linkTuyaMCUOutputToChannel 115 2 3
    linkTuyaMCUOutputToChannel 116 2 4
    linkTuyaMCUOutputToChannel 118 2 5
    linkTuyaMCUOutputToChannel 119 2 6
    tuyaMcu_sendQueryState
    uartSendHex 55 aa 00 34 00 02 04 00 39


    EDIT:

    logi tak wyglądają po wykonaniu uartSendHex:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem
  • #21 20942532
    p.kaczmarek2
    Moderator Smart Home
    Nie widziałem EDIT2 jak pisałem swoją wiadomość, ale rzeczywiście, wymyśliłeś sam to o co chciałem poprosić.

    Zrób teraz ręcznie query state kilka razy i zobacz co nam wyśle TuyaMCU.

    Sprawdź też ten nowy build co dałem bo skoro ta odpowiedź jest poprawna to ją dodam do głównego firmware już by u wszystkich to działało...

    Added after 2 [minutes]:

    EDIT: Wiesz co mam na myśli poprzez "ręcznie"? W Web App log możesz wykonywać komendy poza autoexec.bat, w czasie rzeczywistym
    Pomogłem? Kup mi kawę.
  • #22 20942561
    Selfdrivers
    Poziom 8  
    p.kaczmarek2 napisał:
    Wiesz co mam na myśli poprzez "ręcznie"? W Web App log możesz wykonywać komendy poza autoexec.bat, w czasie rzeczywistym


    Tak właśnie tam wykonuje testowe komendy żeby sprawdzić efekty działania.

    p.kaczmarek2 napisał:
    Sprawdź też ten nowy build co dałem bo skoro ta odpowiedź jest poprawna to ją dodam do głównego firmware już by u wszystkich to działało...


    tam binarka jest może gotowa czy jak to wygląda?
  • #23 20942576
    p.kaczmarek2
    Moderator Smart Home
    OpenBeken posiada automatyczny system kompilacji oparty o Github workflow, oznacza to, że każda nowa wersja jest automatycznie kompilowana dla wszystkich wspieranych platform. W podobno sposób automatycznie kompilowany jest każdy PR i commit, aby pobrać skompilowane binarki nalezy kliknąć w "ptaszek":
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem
    Potem w details:
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem
    Potem w summary:
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem
    Po przewinięciu na dół znajdziesz paczkę z rezultatmi kompilacji:
    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem
    Pomogłem? Kup mi kawę.
  • #25 20942614
    p.kaczmarek2
    Moderator Smart Home
    W takim razie zaakceptuję ten PR i zmiany będą już w głównym firmware. Szukaj dalej, ale jeśli nic się nie uda więcej wymyśleć, to chyba trzeba będzie wykonać przechwytywanie ruchu na oryginalnym sofcie, oczywiście w bezpieczny sposób, bo pewnie układ ma nieizolowaną przetwornicę. Potrzebny pewnie będzie moduł zapewniający izolacją sygnałów UART.
    Pomogłem? Kup mi kawę.
  • #26 20942897
    Selfdrivers
    Poziom 8  
    p.kaczmarek2 napisał:
    W takim razie zaakceptuję ten PR i zmiany będą już w głównym firmware. Szukaj dalej, ale jeśli nic się nie uda więcej wymyśleć, to chyba trzeba będzie wykonać przechwytywanie ruchu na oryginalnym sofcie, oczywiście w bezpieczny sposób, bo pewnie układ ma nieizolowaną przetwornicę. Potrzebny pewnie będzie moduł zapewniający izolacją sygnałów UART.


    Już chyba wiem w czym jest problem ale nie wiem jak to obejść, zauważyłem że czasami pokazuje mi dpID od wartości 16 do góry (ucina potem np 130 i wyżej) a czasami daje mi wartości 116 do góry i możliwe że też obcina gdzieś górny zakres.

    Przykład:

    Wykonałem komendę statusu urządzeń i odebrałem takie dane:

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    zauważ, że na samej górze znajduje się informacja od Debug że id 110 nie zostało z niczym sparowane jednak samo id 110 ani jego wartość nie pokazują się w logu, moja teoria jest taka że urządzeń jest tak wiele że przepełnia to bufor i stąd nie jesteśmy w stanie zobaczyć wartości które odpowiadają np za zużycie energii, napięcie, natężenie. Masz może jakiś pomysł jak ugryźć to? Jakiś zrzut może do pliku .log?

    Dodano po 4 [minuty]:

    Kolejny przykład:

    Ucięło tym razem na "wysokości" 116 (debug jest ale nie samej wartości, czyli widzi ale nie pokazuje w konsoli):

    Demontaż i wgląd w licznik kWh TO-Q-SYS-JWT na szynę DIN z wyświetlaczem

    Dodano po 3 [minuty]:

    Jeszcze jedna sprawa, doczytałem że powyżej dpID 100 znajdują się customowe urządzenia producenta, wszystko poniżej 100 projektuje Tuya jednak niestety lubią bardzo często zmieniać wartości dpID (patrzyłem na domyślnej liście Tasmoty i nie działa żadne dpID z ich listy).
  • #27 20942937
    p.kaczmarek2
    Moderator Smart Home
    Mogę powiększyć bufory bądź skrócić zbędne komunikaty, ale najpierw mi powiedz, czy masz otwartą tylko jedną instancję WebApp?

    WebApp działa tak, że jak otworzysz w dwóch kartach przeglądarki ją to ich instancje "biją się" o log i pół logu jest w jednej karcie, pół w drugiej.
    Pomogłem? Kup mi kawę.
  • #28 20942945
    Selfdrivers
    Poziom 8  
    p.kaczmarek2 napisał:
    Mogę powiększyć bufory bądź skrócić zbędne komunikaty, ale najpierw mi powiedz, czy masz otwartą tylko jedną instancję WebApp?


    Tak, jest odpalona tylko jedna instancja WebApp plus ekran w którym jest sterowanie przekaźnikiem etc (ta stronka - kopia tasmoty).

    Dodano po 1 [minuty]:

    myślę że zmniejszenie liczby komunikatów będzie najepsze. Najlepiej w formacie: dpID - value (type) i jedno po drugim pod sobą

    EDIT: mówię o efekcie wykonania komendy tuyaMcu_sendQueryState

    Dodano po 2 [minuty]:

    Może nawet zrobić nową funkcję o nazwie np. tuyaMcu_sendQueryState_short?
  • #29 20942966
    p.kaczmarek2
    Moderator Smart Home
    Nie opłaca się wprowadzać nowej funkcji w tym celu, niektóre platformy mają tylko 1MB flash a już pojawiały się zgłoszenia, że tam też TuyaMCU będzie potrzebne. Natomiast komunikaty z chęcią skróciłem, nie ma z tym problemu, mogę to od razu na produkcji zrobić.

    Poczekaj z 10 minut aż się skompiluje online i zrób OTA i spróbuj czy coś się zmieniło.

    Added after 1 [minutes]:

    EDIT: Mowa o OTA do nowej publicznej wersji release.

    Added after 0 [seconds]:

    EDIT: Mowa o OTA do nowej publicznej wersji release.
    Pomogłem? Kup mi kawę.
REKLAMA