Zużycie baterii w czujnikach OpenBeken z chipsetem CBU - doświadczenia użytkownika

Hej,

Chciałem tylko podzielić się moimi doświadczeniami z czujnikami drzwi za pomocą OpenBeken, a właściwie tych tutaj:

https://de.aliexpress.com/item/10050056013505...1sea%21AT%210%21AB&curPageLogUid=mKl79w79H1ek

Myślę, że chipset to CBU.... Po zainstalowaniu OpenBeken odkryłem, że czujnik rozładował baterię w ciągu 4 tygodni, dla wszystkich 4 czujników, które wdrożyłem - natychmiast je wyrzuciłem... dokładniej przyglądając się kwestii pustych baterii, odkryłem, że czasami potrzeba było minut, aby dostać się do mojego domowego WIFI, podczas gdy odbiór sygnału w miejscach, w których miałem zainstalowane czujniki, nie jest w rzeczywistości problemem. "Czas rozruchu", że tak powiem, po prostu zabijał baterie.

Teraz naprawdę zastanawiam się, czy CBU jest rzeczywiście problemem (w co wątpię), czy jest to bardziej problem związany z oprogramowaniem wewnątrz implementacji OpenBeken (co miałoby dla mnie więcej sensu) - lub czy jestem jedyną osobą mającą takie problemy.

Wszelkie komentarze mile widziane!

Żywotność baterii czujników OpenBeken zależy w dużej mierze od konfiguracji czujnika. W przypadku urządzeń innych niż TuyaMCU możesz wybrać dowolny, nawet bardzo długi interwał uśpienia, aby wydłużyć żywotność baterii.
Jeśli podejrzewasz, że występuje problem z połączeniem WiFi, możesz sprawdzić, czy Twój adres MAC kończy się na 00 00, co wskazuje, że usunąłeś partycję kalibracji RF.
Nie spotkałem się jeszcze z tym problemem, ale może warto dwukrotnie sprawdzić, czy plik autoexec.bat zawiera mechanizm awaryjnego uśpienia lub / i zmienić mechanizm awaryjnego uśpienia w sterowniku. Coś w stylu: "Jeśli nie ma połączenia wifi przez 30 sekund, wróć do uśpienia".
Czy możesz pokazać, jakiego skryptu używasz obecnie na swoich czujnikach? Czy używasz naszego zakodowanego sterownika czujnika drzwi, czy używasz niestandardowego napisanego w skrypcie autoexec.bat?

Jeśli używasz konkretnie naszego sterownika DoorSensor, czy próbowałeś dostosować ustawienie DSTime?

Przepraszam, nie miałem jeszcze czasu, aby się tym zająć, ale zamierzam to zrobić, gdy tylko uda mi się zebrać trochę rzeczy ze stołu.

W międzyczasie zdemontowałem je wszystkie, ponieważ po około 3 dniach bateria w moich przednich drzwiach była w zasadzie wyczerpana - całkowicie bezużyteczna. Tak czy inaczej zauważyłem, że przerwa snu w zasadzie nie jest problemem, ale jest problem z połączeniem się z WIFI i przynajmniej udało mi się to w końcu odtworzyć na opisanych urządzeniach tu w innym temacie. .

Mam system Velop MX4000 z 2 routerami nadającymi tę samą nazwę SSID na różnych kanałach w różnych pokojach. Praca z pojedynczym identyfikatorem SSID z mojego komputera Mac, telefonu komórkowego lub taniego routera działa dobrze, ale gdy tylko pojawi się więcej niż jeden identyfikator SSID o tej samej nazwie, zostaje to całkowicie pomieszane i nawiązanie połączenia zajmuje wieki. To też jest trochę powiązane z ten raport a szczególnie ten . Problem występuje dość systematycznie. Umieszczenie czujnika na krawędzi chmury działa całkiem nieźle, ponieważ istnieje super silny identyfikator SSID, na przykład 90% i bardzo słaby o tej samej nazwie, na przykład 5%. Jednak w miarę zbliżania się do zakresu 70/20 zaczynają pojawiać się problemy i zwykle zajmuje to dużo czasu. Wydaje się, że nie jest to wyłącznie problem CB3S, ponieważ zauważyłem podobne zachowanie w przypadku czujek dymu z CBU mającym ten sam problem, a także z TW3S...

Podczas gdy jeden z pozostałych autorów spiera się na temat współpracy z Tasmotą (lub nie wiedząc, dlaczego to działa, czy nie), śledziłem podobną dyskusję na forum Tasmota, ponieważ rzeczywiście miałem dokładnie ten sam problem z Tasmotą. Miałem kamerę ESP32, która działała całkowicie dobrze w moim biurze, ale w ogóle nie działała w garażu. Z dwóch węzłów siatki siła sygnału wynosiła 80/20 i 20/80 w obu lokalizacjach. Konfiguracja w moim biurze sprawiła, że zadziałało w moim biurze (pierwsze połączenie z nw o identyfikatorze 1), ale nie udało się w garażu. Skonfigurowanie go w garażu (pierwsze połączenie z identyfikatorem 2) sprawiło, że działało w garażu, ale prawie bezużyteczne w moim biurze. To jednak standard – nie przenosisz nieskonfigurowanego urządzenia poza miejsce pracy, aby skonfigurować je w miejscu instalacji.

Tak czy inaczej nie pamiętam wątku, ale wiem, że rozwiązaniem problemu były SetOption56 i SetOption57, który później naprawiłem także za pomocą 20 kolejnych urządzeń, od detektorów wycieków gazu po wtyczki zasilające - po zrobieniu tego jest jak doświadczenie dzień i noc To. Bez zaglądania do kodu wydaje się, że te funkcje przechowują identyfikator sieci w celu wybrania sieci, z którą chcesz się połączyć, a nie nazwę SSID (coś w stosie biblioteki ESP), a ponieważ ESP są również zwykle statyczne i nie poruszają się, możesz możesz to zrobić raz i niekoniecznie potrzebujesz SetOption57 (chyba że spodziewasz się, że jeden z twoich węzłów siatki będzie od czasu do czasu niedostępny, np. jeśli zdecydujesz się je celowo wyłączyć).

Tak czy inaczej, czy coś takiego można zaimplementować po stronie OpenBeken, czy też zostało to już zrobione tak, że tego nie zauważę? Oprócz umożliwienia działania poszczególnych elementów Tuyi, myślę, że byłby to ogromny zysk dla całego projektu, ponieważ problem ten nie zniknie i nie wydaje się być powiązany z konkretnymi dostawcami routerów, ale jest to bardziej problem ogólny. W przypadku Fritzboxa w jednym z wątków wysuwam tezę, że albo kanały zostały teraz przydzielone inaczej i dlatego działa, a jak znowu się zmieni to już nie będzie działać...