[BK7231N /CB3S] Czujnik dymu MBG line VS-P443W Tuya - teardown

Witaj, dzięki za przedstawienie wnętrza tego urządzenia. Postaram się rozjaśnić sytuację.

Ten czujnika najprawdopobniej pracuje w oparciu o TuyaMCU, a dokładniej o TuyaMCU dla urządzeń zasilanych bateryjnie.
https://developer.tuya.com/en/docs/iot/tuyacl...niversalserialaccessprotocol?id=K95afs9h4tjjh

MCU pracuje cały czas i kontroluje zasilanie CB3S. CB3S jest tylko właczany, gdy trzeba zaraportować stan. MCU poprzez UART (ten sam co do służy do programowania, tj. TX1 i RX1) raportuje dane do CB3S poprzez protokół TuyaMCU, a gdy moduł WiFI je prześle dalej, to MCU go znów wyłącza.

TuyaMCU raportuje zmienne opisane jako dpID + typ + wartość, trzeba będzie odgadnąć jakie dpID co oznacza. Pewnie stan wykrywania dymu będzie mieć wartości 1 lub 0 i typ bool, a np. poziom baterii typ enum (bądź value?) i wartości 0, 1, 2 oraz 3.

Tego typu urządzenia są wspierane przez OpenBeken, ale dla pewności najpierw należy wykonać capture pakietów UART, baud to 9600 lub 115200, można użyć RealTerm a potem je przeanalizować w TuyaMCUAnalyzer:
https://www.elektroda.pl/rtvforum/topic3970199.html#20528459
https://github.com/openshwprojects/TuyaMCUAnalyzer

Potem trzeba napisać autoexec.bat dla OBK gdzie zmapuje się dpID na kanały oraz nada im znaczenia (typy kanałów), HASS discovery już w tym przypadku powinno działać (zostało ulepszone na początku maja).

Potem trzeba wgrać OBK, tu też jest troszkę zabawy, bo MCU nam będzie wyłączać moduł WiFi i blokować linię UART, więc trzeba pewnie przeciąć ścieżki UART i podpiąć własne zasilanie...

A tak to powinno ruszyć.

Jako materiały powiązane warto polecić te tematy, tutaj uruchamiałem zdalnie u @DeDaMrAz czujnik wilgotności na TuyaMCU:
CB3S/BK7231N] Czujnik temperatury/wilgotności z TuyaMCU - Schemat, inżynieria wsteczna
Tu uruchamiałem sam sensor drzwi na TuyaMCU:
Energooszczędny (?) bateryjny sensor otwarcia drzwi/okna na WiFi DS06

Polecam spróbować to uruchomić w ramach sportu, dość dużo prac poszło już na wsparcie tego typu urzadzeń więc może pójdzie gładko.

PS: Zawsze jest alternatywa - wywalić MCU i jeśli czujnik dymu z osprzętem (nie analizowałem tego dogłębnie) wystawia 0 lub 1 cyfrowe to można to zrobić na samym OpenBeken tak jak czujnik otwarcia drzwi bez MCU (użyć głebokiego snu OBK i wybudzania pinem).

Wyciągnąłem dane czujnika przez Tuya IoT Platform korzystając z API Explorer → Smart Home Device System → Device control → Get Device Specification Attribute:



Oto lista dpID dla tego urządzenia:

Możesz doprecyzować jak to wyciągnąłeś, albo napisać o tym minitutorial? Już o tym wspominała jedna osoba, ale ja tego podejście nie znam. Dodatkowo, czy masz te dane w jakimś JSON lub XML ładnym? Może dałoby się automatycznie generować konfigurację OBK.


Swoją drogą, w ostatnich dniach, dodałem automatyczne konfigurowanie urządzeń z OBK, ale bez TuyaMCU. Jak użyjesz najnowszej wersji flashera: https://github.com/openshwprojects/BK7231GUIFlashTool to wtedy cfg Tuya się sam wczyta, pojawi się w nowym oknie i może nawet się wgrać do OBK, jak włączysz tę opcję. Można również z już zaprogramowanego urządzenia OBK pobrać konfigurację Tuya (nie jest ona nadpisywana) przez Web App -> Flash -> Download Tuya Config i zrobić drag and drop pliku bin na nasze narzędzie:


Wracając do tematu... teraz trzeba to wpisać do autoexec.bat, jednocześnie respektując typy kanałów OBK:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/channelTypes.md
Nie wszystkie typy pewnie będą obecne, mogę dodać coś jak potrzeba.
Ale np widzę że BatteryLevelPercent już jest, jest też ReadOnlyLowMidHigh, niby nie ma specjalnego typu dedykowanego dla statusu wykrywania...

W razie czego, zawsze można dać typ TextField lub ReadOnly i też będzie działać, jedynie automatyczne Hass Discovery nie będzie wiedziało jak to podpiąć.

Jak chcesz to poczekaj, znajdę chwilę to dodam typy kanałów brakujące wraz z ich Hass Discovery, z tego co widzę to brakuje co najmniej SmokeState (1 lub 0), SmokeLevel (0-100)

Edytowałem post i dodałem info jak wydobywać dpID (można też przez Debug device w bardziej ograniczonej formie, ale w API Explorer jest od razu całe info).

Co do flashera GUI to nie wiem jak teraz, ale gdy kombinowałem z czujnikiem otwarcia drzwi pod Linuksem mi się uruchamiał przez mono, ale nie byłem w stanie ani zgrać ani wgrać nim firmware przez co musiałem skorzystać z uartprogram. Z tego co wiem to nie jestem jedyną osobą, która napotkała na ten błąd:

Właśnie dorzuciłem typ kanału SmokePercent wraz z Home Assistant Discovery.

Testowane tylko na Symulatorze (Windows):



Działa:

Niestety w dostępnych device_class od HA nie znalazłem gotowego pod Smoke:
https://developers.home-assistant.io/docs/core/entity/sensor/#available-device-classes
Więc Discovery będzie bez klasy..

Ta Hass Discovery customowych typów kanałów ma raptem z tydzień, może dwa, więc na bieżąco jest ulepszane.

nihildiximus napisał:

Co do flashera GUI to nie wiem jak teraz, ale gdy kombinowałem z czujnikiem otwarcia drzwi pod Linuksem mi się uruchamiał przez mono, ale nie byłem w stanie ani zgrać ani wgrać nim firmware przez co musiałem skorzystać z uartprogram.

Na flasher możesz zrobić drag and drop pliku bin 2MB albo nawet samej partycji Tuya Config pobranej z OBK Web App i też zadziała. Nie musisz koniecznie przez UART wczytywać danych.

nihildiximus napisał:

Z tego co wiem to nie jestem jedyną osobą, która napotkała na ten błąd:

Jak masz jakiś pomysł co może być nie tak to daj znać, nie wiem czemu gubi bajty. Ten błąd to od Ciebie?

Pierwsze bajty się zgadzają, wygląda jakby coś się gubiło z bajtów potem, poza początkowym 0x04 0x0e 0xff 0x01 0xe0

Może coś inaczej działa na systemach... może ten timeout psuje?

Jakbym Ci dał wersję exe z tym zmienionym (albo wyprowadzonym do CFG) to byś potestował, czy to coś pomaga?
EDIT: Ale ten timeout nie powinien psuć, potem ja w pętli sprawdzam BytesToRead dopóki nie osiągną oczekiwanej ilości bajtów... nie wiem, ale jak masz możliwość potestowania to dodam jakąś konfigurację tego i zobaczymy.

Właściwie to można pomyśleć o dodaniu czy to do tego flashera czy do innych narzędzi opcję wyciągania dpID czy nawet całej konfiguracji urządzenia przez API Tuya po podaniu Access ID oraz Access Secret, co umożliwiłoby to tworzenie gotowej konfiguracji do FW na podstawie pliku json.

Added after 2 [minutes]:

p.kaczmarek2 napisał:

Jakbym Ci dał wersję exe z tym zmienionym (albo wyprowadzonym do CFG) to byś potestował, czy to coś pomaga?
EDIT: Ale ten timeout nie powinien psuć, potem ja w pętli sprawdzam BytesToRead dopóki nie osiągną oczekiwanej ilości bajtów... nie wiem, ale jak masz możliwość potestowania to dodam jakąś konfigurację tego i zobaczymy.

Możesz podrzucić to w wolnej chwili przetestuję na tym czujniku.

Zamieszczam kompilację Flashera do testów.

Należy sprawdzić, czy opcje stad:

cos zmieniaja, a dokladnie, kolejno, czy:
1. Czy zmiana cfg_readReplyStyle z 0 na 1, a potem odczyt, coś pomaga?
2. Czy zmiana mult czasów (w obu przypadkach) , np na 10 (dłuższe 10 razy timeouty) coś pomagają?

Cześć,
Czujnik dymu Tuya


Po prostu głośno myślę...
Gdy zasilam CB3S tylko oryginalnym oprogramowaniem Tuya, otrzymuję następujące bajty w TuyaMCU Explorer/Analyzer:
//R 07.07.2023 16:50:50 Odebrano WiFi:
55AA0001000000
//R 07.07.2023 16:50:52 Odebrano WiFi:
55AA0001000000
Czy to oznacza, że CBS3 chce powiedzieć MCU „Jestem obecny”?
Ponieważ sam MCU Tuya nie jest zasilany, nie może odpowiedzieć. Niestety ten komunikat co sekundę uniemożliwia prawidłowe działanie BK7231 Easy UART Flasher.

Więc albo CB3S da się przekonać do wyłączenia (jak? 1. uziemienie pinu RST lub 2. ściągnięcie pinu CEN w dół nie pomogło w moim przypadku) albo...
Czy pomogłoby, gdyby Flasher rozpoznał ten komunikat i jakoś wyciszył CB3S przed uruchomieniem?

Natomiast nie rozumiałem, dlaczego 2nd tu nie działa. I tu pojawia się pytanie, czy Flasher mógłby wystartować bez ściągania CEN?

W tej chwili nie widzę możliwości flashowania mojego czujnika dymu Tuya. Czy komuś w międzyczasie się udało?

Z poważaniem MKMonachium