Automatischer Staubsauger ohne Cloud-Zwang: Roborock S5 im KNX-Smarthome
You say the word and I’ll go anywhere blindly
I’m a sucker for you, yeah
Any road you take, you know that you’ll find me
I’m a sucker for all the subliminal things
(Sucker, Jonas Brothers)
Sehr lange schlummerte das folgende Projekt auf unserer TODO-Liste. Das Ziel: Integration eines Staubsaugerroboters in die Heimsteuerung zur automatischen/intelligenten Reinigung (des relativ hoch-frequentierten Untergeschosses). Die besondere Herausforderung dabei:
Vollständige Unabhängigkeit von externen Diensten (Cloud-Services)
Lokale Anbindung an die zentrale Smart-Home-Instanz zur flexiblen Automatisierung
Wahrung der vollumfänglichen Funktionsteuerung bei manuellem Eingriff
Die Lösung führt mit Hilfe eines chinesischen Roboters über eine simulierte “Pseudo-Cloud” in die absolute Staubsauger-Glückseligkeit. Von Hersteller-Zwängen befreit, können wir unser Gerät bei Sicherung unserer Privatsphäre innerhalb unserer “Vier Wände” autark betreiben. Wie das geht? Wir haben es für uns so eingerichtet:
Zutaten
Unser Lösungsvorschlag basiert auf den folgenden Ingredienzien:
- Roborock S5 / S50 / S55: Ein vergleichsweise preisgünstiges Gerät mit weiter Verbreitung und leicht erhältlichem Zubehör
- Android-App ( Mi Home Version 5.4.54.apk, 55 MB): Eine ältere Version der Original-Hersteller-App zur Extraktion des Geräte-Tokens (Token = Eindeutiger Identifikationscode zur Steuerung des Geräts)
- Linux (Debian)-Umgebung (Raspberry Pi oder Virtual Machine): Die “Werkstatt” zum Bau und Transfer unserer eigenen Firmware auf den Saugroboter
- Laufende Edomi-Instanz
Selbstgebaute Firmware
Damit wir den Sauger autark betreiben können, bauen wir uns mit Valetudo/Dustcloud eine eigene Firmware, die auf dem Gerät läuft, die Funktionen der Hersteller-Cloud vortäuscht und somit die “Telefonie nach Hause” unterbindet. Bei Bedarf kann die hausgemachte Firmware über die Rücksetzung auf die Werkseinstellungen des Geräts wieder rückstandslos entfernt werden. Somit ist die Gefahr das Gerät nachhaltig unbrauchbar zu machen verhältnismäßig gering.
Die Valetudo-Firmware bildet die Funktionen der Original-Firmware fast vollständig, inklusive der interaktiven Karten-Darstellung, ab.
Wir beginnen mit der Anleitung des Valetudo-Machers. Wer noch kein digitales Schlüssel-Paar zur SSH-Kommunikation besitzt, kann das gemäß Anleitung tun:
https://github.com/Hypfer/Valetudo/wiki/Installation-Instructions
Token-Extraktion
Falls die Token-Extraktion laut Valetudo-Anleitung – wie bei unseren Versuchen – nicht funktionieren sollte, greifen wir auf folgende Methode zurück:
- Android App Mi Home Version 5.4.54.apk installieren
- Gerät laut Anweisungen in der App einbinden
- Logfile auf dem Android in
/sdcard/SmartHome/logs/Plug_Devicemanager/
auf"token:"
absuchen
Für den Fall, dass kein Android-Device verfügbar sein sollte, kann man auf zahlreiche, andere Methoden zur Anzeige des Token zurückgreifen:
Ist die Custom-Firmware erst auf dem Gerät installiert, kann man bereits auf die Konsole zugreifen:
Per ssh verbinden – aus der Linux-Umgebung heraus:
ssh root@rockrobo -i ~/.ssh/id_ed25519
id_ed25519
ist dabei der im Vorfeld generierte, private Schlüssel.
Die Web-Bedien-Oberfläche von Valetudo ist nun auch über die IP-Adresse des Geräts in eurem Netzwerk erreichbar.
Einbindung ins Smart-Home mittels MQTT
Die frische Firmware des Geräts stellt per MQTT-Protokoll alle Attribute, bzw. Status-Informationen bereit. Ebenso nimmt es auch Befehle (Start/Stopp, Saugstufe, Zonen-Reinigung, …) von einem MQTT-Broker entgegen.
Mehr als das benötigen wir zur Steuerung/Automatisierung über unsere Smart-Home-Zentrale nicht.
Wer noch keinen MQTT-Broker auf seinem System hat, kann das für Edomi (Centos6.5) etwa so einrichten:
wget http://packages.psychotic.ninja/6/base/x86_64/RPMS/psychotic-release-1.0.0-1.el6.psychotic.noarch.rpm rpm -Uvh psychotic-release*rpm yum --enablerepo=psychotic install mosquitto service start mosquitto
Sowohl Benutzername als auch Passwort sind so bei unserem lokalen Broker in der Standard-Konfiguration leer. Bei Bedarf bitte anpassen.
Haupt-Funktionen
Die Abbildung der Befehle und Status-Infos in der Visu sowie die Automatik-Logik(en) sind so nur noch Formsache:
Bei uns führt zum beispiel der Roboter die Reinigung automatisch bei Abwesenheit durch sofern sämtliche Voraussetzungen hierfür erfüllt sind:
- Automatik-iKO: Aktiv
- Abwesend > 3 h
- Letzte Reinigung > 8 h
- Aktuelle Uhrzeit zwischen 09:00 – 15:00
- Aktueller Status: Lade Akku
- Anzahl-Auto-Reinigungen am Tag < 1
Karte
Die Kartenübersicht mit dem Standort sowie der Wegstrecke des Geräts wird auch durch Valetudo bereitgestellt. Da die Rechenpower des Robotors für die Erzeugung der Map nicht überbeansprucht werden soll, bereiten wir die Reinigungs-Map gesondert einem “mächtigeren” Gerät auf:
sudo apt-get update sudo apt-get upgrade sudo apt-get install nodejs npm cd ~ mkdir valetudomap cd valetudomap git clone https://github.com/Hypfer/ICantBelieveItsNotValetudo.git cd ICantBelieveItsNotValetudo/ npm install npm start [STRG + C] nano config.json
Der erste Start initialisiert die config.json-Datei für uns.
Anschließend kann man die config-Datei nach seinen Bedürfnissen bearbeiten; Die IP-Adresse des MQTT-Brokers anpassen sowie Webserver auf aktiv setzen:
{ "mqtt": { "identifier": "rockrobo", "topicPrefix": "valetudo", "autoconfPrefix": "homeassistant", "broker_url": "mqtt://:@192.168.0.30", "caPath": "", "mapSettings": { "drawPath": true, "drawCharger": true, "drawRobot": true, "border": 2, "scale": 4 }, "mapDataTopic": "valetudo/rockrobo/map_data", "minMillisecondsBetweenMapUpdates": 10000, "publishMapImage": true }, "webserver": { "enabled": true, "port": 3000 } }
Dienst zur Kartenbereitstellung starten:
nohup nmp start & disown
Die Karte ist dann über die IP-Adresse des Devices und der Portangabe verfügbar.
Fallstricke & Workarounds
Der Sauger führt ggf. sporadisch und eigenmächtig einen Betriebssystem-Reset zwischen 03:00-04:00 durch. Es gibt Berichte dazu, dass dadurch ggf. auch ein Reinigungsvorgang unaufgefordert ausgelöst werden kann! 😱 Das ist ein bekanntes Problem, für das es zum gegebenen Zeitpunkt noch keine (zuverlässige) Lösung gibt:
- https://github.com/dgiese/dustcloud/issues/206
- https://github.com/Hypfer/Valetudo/issues/80
- https://github.com/Hypfer/Valetudo/issues/206
Wir versuchen diesem Glitch in der Matrix mit einer eigenen Logik zu begegnen:
No Map Data:Die Kartendarstellung funktioniert ggf. nicht richtig. Lediglich “No Map Data” ist zu sehen.
Die Lösung hier bringt ein Neustart des Betriebssystems des Roboters.
Um das Gerät (remote) via Edomi-LBS neustarten zu können, sind ein paar wenige Schritte vorbereitend auszuführen:
Auf der Edomi-Konsole (RSA-Schlüssel-Paar erzeugen):
ssh-keygen -t rsa -C "edomi roborock key"
cat ~/.ssh/id_rsa
sollte erste Zeile mit “—–BEGIN RSA PRIVATE KEY—–“ ausgeben
Inhalt der Ausgabe von cat ~/.ssh/id_rsa.pub
kopieren
Auf der Roborock-Konsole (RSA-Schlüssel autorisieren):
nano ~/.ssh/authorized_keys
Inhalt der Ausgabe von cat ~/.ssh/id_rsa.pub
einfügen
Mit [STRG+ X] , Y
beenden/speichern
Somit hat auch nun Edomi Vollzugriff auf das System und kann den Restart etwa so auslösen:
sudo shutdown -r now
Fazit
Ein Traum wird wahr! Der Sauger verrichtet inzwischen zuverlässig seinen Dienst. Die Reinigungsergebnisse sind gut – besonders die kurzweilige Zonenreinigung des exponierten Eingangs-Bereichs ist ein Segen! Wir bleiben mit unseren Daten privat und unabhängig von Hersteller-Diensten/-Launen.
In your face, Beijing! 😛
In your face, Beijing!
made my day .. sehr geil und danke für die Anleitung
Danke für deinen Beitrag! Ich kämpfe gerade mit mqtt/edomi/centos6.5
Habe einen externen MQTT-Broker laufen, aber die MQTT-LBS (subscriber/publisher) bekomme ich nicht installiert, da Mosquitto unter Cents 6.5 nicht verfügbar.
Jetzt habe ich es nach deiner Anleitung versucht, den broker direkt auf 6.5 zu installieren – da startet er aber leider den service nicht mit dem Hinweis “start: unbekannter Dienst”
Hast du en gute Idee für mich? Danke und Grüße!
Sebastian,
eine Ferndiagnose ist immer schwierig. Scheint so als wäre der Dienst nicht (korrekt) installiert. Die PHP-MQTT-Komponenten für die LBS können scheinbar nicht mehr auf Centos 6.5 installiert werden, da inzwischen die notwendigen Repositories nicht mehr verfügbar sind… 🙁 Wenn möglich auf Centos 7 wechseln – mehr fällt mir da leider nicht ein. Viel Erfolg!
Danke dir – ich hatte befürchtet dass ein Wechsel auf CentOs 7 ansteht. Aber was neues hat ja auch immer was gutes ;-). Viele Grüße und weiter so mit dem Blog. Ich habe hier im letzten Jahr so viel gelesen und Input für unsere KNX-Kernsanierung bekommen – Daumen hoch!
Tolle Arbeit!!
Gibt es bereits Erfahrungen bzw. Intensionen, den Cloud-Zwang auch für den “S5 Max” zu unterbinden? Falls ja, wäre ich auch sehr daran interessiert. Grüße
Danke! Meines Wissens gibt es aktuell (Apr. 2020) noch keine Cloud-Befreiung für die aktuellen Geräte (S5 Max, S6, etc.)… 🙁
[…] Saugroboter-Steuerung […]
[…] (Saug-)Roboter/Haustiere bleiben machmal ungewollt ausgesperrt… Dies muss man dann je nach Bedarf […]
saucool! Das würd mir auch taugen… aber unserem Roboter (und das ist inzwischen der 2.) muss eigentlich für jeden Saugvorgang der Staubbehälter geleert werden. Wir haben einen Hund, der offensichtlich sehr haart… aber auch ohne Hund kommt ja immer überraschend viel zusammen. Wie habt ihr das gelöst? Werdet ihr beim Verlassen des smart Homes daran erinnert, dass der Saugi noch geleert werden muss??? 😉
Gruß
Jochen
Wir bekommen eine Email, dass der Roboter fertig ist: Behälter leeren, Mail löschen. Das war’s.🙂