Czy ktoś próbował, instalować Valetudo na robocie odkurzającym pracującym pod kontrolą aplikacji WeBack? A może inna podmiana firmware? To problem znany. Różne roboty pracujące pod kontrolą aplikacji weback, przestały z nią współpracować. Można było założyć nowe konto i wskazać lokalizacje “Chiny” ponoć działało. Mi już nie. Mam dwa takie roboty, jeden mój, drugi “zdobyczny” . RoboJet i Puron. W zasadzie nie chodzi mi konkretnie o Valetudo ale o cokolwiek co pozwoli mi na współpracę z HA. Spędziłem sporo czasu czytając to i owo, podłączając się UARTem do płytki, próbując dostać się do systemu. NIC. System ma linuksowy, ale nie potrafię dostać się do czegokolwiek. Może ktoś z koleżanek i kolegów temat przerabiał?
Nie próbowałem, ale skomentuje:
- Valetudo wymaga systemu Linux(zazwyczaj procesorów Allwinner) lub specyficznych MCU z Rockchip. A takie według tego co wiem znajdują się w robotach od Xiaomi, roborock, dreame i viomi.
- Z tego co wyczytałem roboty z apką WeBack bazują na tanim kontrolerze Wi-Fi (np. od RTL/Realtek lub Tuya/Espressif) i główny mikrokontroler (STM32 lub pokrewnym).
- Tu wrzucę od AI(osobiście się z tym zgadzam):
- Po porządnym prompcie dla Perplexity twierdzi on że:
Wiele robotów z aplikacji WeBack w rzeczywistości działało na modułach Tuya Wi-Fi (często brandowanych jako Tywe3S, WR3 lub podobne).
- Zdejmij obudowę i przyjrzyj się modułowi Wi-Fi na płycie głównej. Jeśli ma oznaczenia Tuya, to oznacza, że komunikacja między “mózgiem” robota a Wi-Fi odbywa się po protokole TuyaMCU.
- Co to oznacza? Jeśli to Tuya, to te roboty można zmigrować do lokalnego ekosystemu za pomocą Tuya Local lub LocalTuya w Home Assistant, o ile uda się je sparować z aplikacją Smart Life / Tuya Smart zamiast WeBack. Czasami wystarczy wprowadzić robota w tryb parowania i wyszukać go aplikacją Tuya.
Oczywiśicie ekspertem robotów sprzątających to ja nie jestem, ale w sprawach Linuxa i MCU mam troszkę wiedzy.
ESP8266 (Tywe3S i podobne moduły) to jest tam co najwyżej jako moduł komunikacyjny, więc moim zdaniem szanse na sukces są zerowe jeśli faktyczny producent nie przygotował dla tego sprzętu obrazu do konwersji na inne rozwiązanie chmurowe niż WeBack.
BTW (na moje oko to te chmury nie mają wiele wspólnego z czymś faktycznie koniecznym do działania w miarę autonomicznego sprzętu).
Rzeczywiście niektórzy dystrybutorzy nie zostawili użytkowników “z ręką w nocniku”, więc jeśli chcecie sobie po-analizować co tam być może jest w środku to proszę bardzo
pierwszy link z ikoną pdfa to jest de facto firmware dla 2 różnych modeli.
Wstępnie być może to jest jakiś SoC na Cortex-A (lub generalnie arm v7).
Lepiej jednak sprzęt rozebrać i wypruć sobie elektronikę do analizy (moje skromne zdanie jest takie że to i tak skończy w PSZOKu).
A czemu wątek jest akurat w Integracjach dla HA to nie mam bladego pojęcia. (obecnie przeniosłem w jedyne sensowne miejsce)
Poza tematem jak widać komponent niestandardowy (którego rozwój został porzucony) korzystał z chmury (w której były zmiany)
istnieje świeższy fork
gdzie ostatnie wydanie ma zaledwie 2 miesiące (więc sądzę, że nadal działa)
ale to nie rozwiąże problemu, gdy sprzęt został celowo odcięty przez właściciela chmury
Nie pytałem się czy ma linuksa, bo wiem, że ma. Robót rozebrany leżał u mnie na biurku 2 tygodnie. Podłączone 2 UARTY, ma jeden na płycie z Linuksem, drugi na płycie głównej. Założyłem wątek, licząc, że ktoś kiedy dobrał się do takiego sprzętu. Mam dwa, jeden mój, drugi od znajomych, dwie nazwy, dwa takie same roboty. Więc musi być na rynku ich wiele.
No ale i tak nie mam dobrych wiadomości - wiadomo jest jakiś producent, który tłucze to masowo, ale
- Oprogramowanie musi pasować do sprzętu (dlatego w tym linku powyżej są 2 różne softy do 2 modeli zapewne różniących się peryferiami, bo przypuszczam, że płyty główne nawet mogą mieć identyczne)
- Producent chipsetu to “chinol pełną gębą” (Zhuhai Yiwei Technology Co., Ltd. dawniej Yiwei Semiconductor, znany też jako A-Micro) jeśli znajdziesz jakąkolwiek dokumentację (nawet po chińsku) to będziesz mistrzem wyszukiwania, jakkolwiek w związku z tym nie liczyłbym na cud - nie masz szans działając samotnie konkurować z firmami, które dostają od chińskiego rządu dotacje rzędu miliarda juanów.
- Szansa na dopasowanie “cudzego” softu jest też właściwie zerowa, potentat rynku Tuya sprzedaje swoje oprogramowanie (a nie je rozdaje, i to sprzedaje tylko producentom), więc nie pozwala na dołączenie do swojej chmury nieautoryzowanego sprzętu (nawet jeśli skądś byś wyczesał firmware pasujące do flaków) kontrola może nie jest bardzo rygorystyczna, ale jest (raczej sprowadza się do sprawdzania zakresów numerów seryjnych SoC lub MAC-adresów).
Tak, to wszystko na pewno prawda. Ciężki temat. Na razie, na okres letni złożyłem go do kupy, i wsadziłem małe ESP D1 mini. Służy tylko i wyłącznie jako zamiennik pilota. Podłączony do odbiornika IR odkurzacza przekazuje komendy z HA do niego. Bez “zwrotki” czyli nawet nie wiadomo czy robi to co chcemy. Na zimę jak zamknę domek letni przywiozę go i dalej powalczę. A może ktoś to w między czasie “ogarnie’“ . Póki co może kilka faktów. Podłączony do WiFi ma otwarte tylko dwa porty 80 i 9999. Na 80 oczywiście serwer www, ale próbowałem wielu podejść i zawsze zwraca tylko:
{
"platform_thing_type": "_CLEAN_ROBOT",
"firmware_version": "1.6.0",
"firmware_type": "yubot-ywls"
}
Z 9999 można się połączyć, ale dalej nic sensownego nie udało mi się uzyskać:
nc -v 192.168.146.99 9999
Connection to 192.168.146.99 port 9999 [tcp/distinct] succeeded!
Podczas uruchamiania, na UART-ach można podejrzeć działanie:
U-Boot 2017.01-rc2 (Jun 09 2020 - 14:18:49 +0800) Amicro
Model: Linux SDK
DRAM: 64 MiB
SF: Detected mx25l25635f with page size 256 Bytes, erase size 64 KiB, total 32 MiB
…..
[INIT] starting ygclient
[INIT] starting daemon
[daemon] daemon start, version: 2.2
[daemon] register signal handler
[daemon] wait client connect…
uart debug server start
[ 15.594444] RTW: nolinked power save enter
[daemon] set daemon oom_score_adj: -1000
[daemon] set factory_mode oom_score_adj: -1000
[daemon] memory_monitor: tcp/udp use 0 KB
[daemon] memory_monitor: demo_rplidar use (5444, 4034, 3396) KB
[daemon] memory_monitor: wifi_app_server_grit use (1408, 506, 340) KB
[
……
144 frames decoded (0:00:05.1), -1.7 dB peak amplitude, 0 clipped samples<0D><0A>[ 5.315367] am580-mmc 1c10000.mmc: card claims to support voltages below defined range<0D><0A>[ 6.141823] spi_irq open.<0D><0A>[ 7.427291] am580-mmc 1c10000.mmc: card claims to support voltages below defined range<0D><0A>[Factory Mode] start …<0D><0A>[Factory Mode] firmware downloader start …<0D><0A>[ 9.506815] RTW: module init start<0D><0A>[ 9.510321] RTW: rtl8189fs v5.7.9_35795.20191128<0D><0A>[ 9.514962] RTW: build time: Apr 16 2020 14:21:52<0D><0A>[ 9.711413] RTW: == SDIO Card Info ==<0D><0A>[ 9.715190] RTW: card: c3a6d000<0D><0A>[ 9.718530] RTW: clock: 25000000 Hz<0D><0A>[ 9.722215] RTW: timing spec: sd high-speed<0D><0A>[ 9.726593] RTW: sd3_bus_mode: FALSE<0D><0A>[ 9.730350] RTW: func num: 1<0D><0A>[ 9.733415] RTW: func1: c3130800 (*)<0D><0A>[ 9.737169] RTW: ================<0D><0A>[ 9.933785] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator<0D><0A>[ 10.162960] RTW: HW EFUSE<0D><0A>[
……
W/g mnie pytka z Linuksem jest w robotach mających lidar i obsługujących mapy. Obie płytki są połączone nie UARTem tylko USB - ale tutaj się nie wgryzłem.
1 Like
Port 80(HTTP) to endpoint Discavery.
Port 9999 (TCP) To jest klucz do wszystkiego. tutaj działa usługa wifi_app_server_grit wymieniona w logach. To lokalny socket TCP przez który aplikacja wysyła komendy sterujące bezpośrednio do robota, gdy telefon był w tej samej sieci Wi-Fi.
Skoro 9999 przyjmuje połączenie przez nc (netcat) znaczy to, że usługa żyje lokalnie i nie potrzebuje chmury do nawiązania sesji.
- Prawdopodobnie komunikacja tam odbywa się w formacie binarnym (HEX) lub surowym JSON.
- Jeśli masz chęci - możesz postawić na komputerze prostego skryptora w Python i spróbować wysyłać na ten port podstawowe komendy, np.
{"cmd": "start"},{"action": "clean"}i obserwować, czy robot zerwie połączenie, czy odpowie błędem.
Przejżałem jeszcze forka. Działa mniejwięcej tak:
najpierw loguje się do serwera OAuth (chmury) po token JWT pobiera listę robotów, a potem nawiązuje połączenie WebSocket (WSS) za pomocą protokołu AWS IoT (Amazon Web Services)
Co najciekawsze, z kodu wynika, jak ustrukturyzowane są komendy, które robot przyjmuje jako payload.
Dałem AI plik, aby wyciągną komendy:
- Jak wygląda payload komend
W plikuwebackapi.pyzdefiniowano dokładne nazwy zmiennych oraz funkcji, na które reaguje oprogramowanie robota. Kluczem do sterowania jest parametr sterujący stanem pracy:working_status.Oto słownik komend, który musisz wysłać do urządzenia:
- Start (Auto):
{"working_status": "AutoClean"}- Stop (Baza):
{"working_status": "BackCharging"}- Pauza:
{"working_status": "Standby"}- Spot (Punktowe):
{"working_status": "SpotClean"}- Lokalizuj (Dźwięk):
{"working_status": "LocationAlarm"}Zmiana siły ssania lub poziomu wody:
Roboty WeBack używają tego samego parametru
fan_statusdo kontrolowania wentylatora lub pompki mopującej (zależnie od tego, czy wpięty jest pojemnik na kurz, czy na wodę). Payload wygląda tak:
{"fan_status": "Quiet"}(Cichy){"fan_status": "Normal"}(Standardowy){"fan_status": "Strong"}(Mocny){"fan_status": "Max"}(Maksymalny)2. Architektura wiadomości na porcie 9999
Skoro robot w Twojej sieci lokalnej otwiera port TCP
9999, oznacza to, że usługawifi_app_server_gritprawdopodobnie nasłuchuje surowych pakietów TCP opakowanych w format JSON – dokładnie takich, jakie chmura wysyłała do robota.W kodzie forka widzimy, jak integracja przygotowuje paczkę dla usługi AWS IoT. Dla lokalnego portu
9999nie potrzebujesz nagłówków AWS (jaktopic_nameczyopt). Robot bezpośrednio w swoim sofcie oczekuje struktury ukrytej wewnątrztopic_payload→state.Spróbuj wysłać na port
9999(np. przez Pythona lub zaawansowane zapytanie wnc) poniższy czysty payload JSON:{ "state": { "working_status": "AutoClean" } }Jeśli robot oczekuje pełnej enkapsulacji (bo jego serwer lokalny działa 1:1 jak parser chmurowy), struktura może wymagać dodania timestampu:
{ "notify_info": "sync_thing", "cmd_timestamp_s": 1783850000, "topic_payload": { "state": { "working_status": "AutoClean" } } }
A i odkryłem odnośnie generowania map w HA. Roboty z tym softem przesyłają surowe dane mapy spakowane algorytmem zlib i zakodowane w base64:
Pythonself.data = json.loads(zlib.decompress(base64.b64decode(data_input)))`
Oznacza to, że robot wysyła paczkę tekstową z której HA wyciąga bitmapę, a potem biblioteka PIL (Pillow) rysuje na niej pozycję ładowarki, ścieżki oraz pozycję robota. To dowód na to że układ AM580 z Linuksem na małej płytce cały czas generuje i obrabia te dane lokalnie, a nie w chmurze.
NIestety moja wiedza jest zbyt małą. Siedziałem pare godzin z AI i próbowałem różnych rzeczy. Teraz też spróbowałem za pomocą nc wysłać komendy, jakie napisałeś. Nic, nigdy nie dostałem żadnej odpowiedzi ani nie było reakcji robota. Jednej rzeczy nie rozumie, jak opierając się na przeglądaniu integracji, która przecież jest integracja do weback a nie do urządzenia można wyciągnąć tak daleko idące wnioski? Na dzień dzisiejszy robót przechodzi “z sukcesem” cały proces rejestrowania w chmurze za pomocą weback, ale poza komunikatem, że jest OK i tym, że robót łączy się ze wskazaną siecią lokalną nic się nie dzieje. Podsłuchiwałem co wysyła robót : NIC. Nie próbuje się łączyć z chmurą. praktycznie jest nieaktywny po wifi. Doszedłem do wniosku, że w czasie łączenia z aplikacją nie dostaje odpowiednich danych rejestrujących go w chmurze. Teraz żona mi zabrała robota, aby sprzątał 
, ale niezniechęcony szukam czegoś takiego na OLX aby leżał na biurku. Podzieliłem zadanie na 2 etapy. 1 - podłączenie się po UART i odbieranie danych aby widzieć stan robota. 2 - ogarnięcie mapy, to co napisałeś jest nadwyraz ciekawe, bo wynika z tego, że tą mapę można by przechwycić. Zapewne płytka z Linuksem wysyła ją po porcie szeregowym do płyty głównej, bo tylko tak można ją wysłać do chmury.
Jeżeli robot był na kogoś zarejestrowany to nie ma szans dodać go ponownie do chmury, to że się łączy nie znaczy że jest w chmurze aktywny. Możesz spróbować zarejestrować się w innej lokalizacji chmurowej o ile jest taki wybór. Tu jakiś stary wątek: https://community.home-assistant.io/t/weback-cloud-integration-testers-and-help-required/186155
Nie, to nie jest mój cel i nie będą kombinował. Celem jest sterowanie lokalnie.
O ile pamiętam w starszych wersjach trzeba było wgrać zrotowany soft podłączając się kabelkami, mały błąd to uwalony odkurzacz. Jeżeli to odkurzacz do testów to można sobie testować.
Moją pierwszą myślą było Valetudo, ale jak już tutaj napisano, wersji sprzętowych jest dużo i nie ma pewności, że jakaś pasuje do tego robota. Nie ma go na liście kompatybilnych. Teraz więc idę po, wydaje mi się, mniejszej lini oporu. Jak mogę włączyć, zatrzymać, to chciałbym tylko wyciągnąć z niego aktualny stan pracy, błędów czy akumulatorów, Na moje to się wyciągnie z UARTA. To mój pierwszy cel.