Roomba Staubsaugerroboter

Begonnen von Prof. Dr. Peter Henning, 10 September 2020, 16:40:34

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Zuerst müsste man testen, ob die Leuchten tatsächlich mit dem "Connect"-Zustand zusammenhängen. Das kann man z.B. testen, indem in das MQTT2_CLIENT temporär mit einer anderen IP-Adresse umdefiniert.

Einen Poweroff-Befehl gibt es bei meinen Robotern nicht - vlt. mal ein Foto des 676 mit/ohne LED posten?

Wie reagieren die LED, wenn man den Roboter nicht mit FHEM (=localApp) sondern dem Handy (=remoteApp) steuert?

Kann MQTT2_CLIENT den Robot wieder aufwecken, wenn seine LED aus sind?

LG

pah

Sturi2011

#46
Hallo,

wenn ich den Client umdefiniere oder wie oben geschrieben aus der Fhem CFG entferne, geht er braf schlafen.
Der Zustand ist unabhängig davon, ob er auf der Ladestation oder im Raum rumsteht. Es leuchtet Power und WLan.

Füge ich den Client wieder ein, wacht er brav auf und lässt sich bedienen. Allerdings sind dann die LED auch wieder an.

Für mein Verständniss fehlt hier in der Implementierung von MQTT2_Client das schon öfter angesprochene Connect/Disconnect.

edit:
Man könnte jetzt quick an dirty mit modify device 'ip vom Mars':8883 arbeiten und das in einen AT packen sowie mit einem Notify
vom Client Device triggern - aber schön ist anders....

Besser wäre ein Disconect sowie regelmäßiges Connect alle 60? Minuten um die Statuswerte zu refreshen.
Dann geht zwar alle 60 Minuten das Licht für 2 Minuten an aber das wäre zu verschmerzen.
Das Connect kann dann ebenfalls per Notify vom MQTT2_Device erzwungen werden für Start und
das Disconnect ausgesetzt werden für z.B. 2h. (Länge Reinigungszyklus)


Gruß Andreas

Prof. Dr. Peter Henning

Gibt es. Setzt man das Attribut disable=1, sollte die Connection aufgelöst werden. disable=0 stellt den Zustand wieder her, in dem sich der Client selbsttätig wieder verbindet.

Bitte mal ausprobieren, was das mit den LED macht.

LG

pah

Sturi2011

Hallo,

leider nix - schon getestet. Das Attribut verhindert das Senden von Informationen, der Status bleibt aber connected.
Robi geht also nicht schlafen. Sonst wäre es einfach...

Gruß Andreas

Prof. Dr. Peter Henning

#49
OK, habe einen Feature request abgesetzt. Diskussion erfolgt hier: https://forum.fhem.de/index.php/topic,114299.0.html

LG

pah

Sturi2011

#50
Hallo,

vielen lieben Dank.

edit:
Wenn was zu testen ist - ihr Logs braucht - immer Her damit. Gern auch per PM

edit2:
ZitatIch würde das sogar noch weiter treiben: Nicht am CLIENT muss eingestellt werden, wie lange sein KeepAlive dauern soll. Sondern das wäre am DEVICE zu machen, welches dies dann dem CLIENT mitteilt.

Gibt es dann die Möglichkeit mit dem späteren Template zu sagen, für welchen Befehl das Keepalive wie lange dauert?

Für Stop macht da aus meiner Sicht ein anderer Wert Sinn als für Start - wo mann vermutlich das Ende des Reinigungszyklus abwartet um z.B. Koordinaten zu bekommen.


Gruß Andreas

Sturi2011

Guten Abend,

mit der neuen Version aus dem SVN disconnected er ordnungsgemäß.
Robi geht dann nach 2 Minuten schlafen. Neue Befehle werden
ordnungsgemäß entgegen genommen und er wacht auf und tut.
Dafür vielen Dank.

Irgendwie is es aber noch nicht ganz rund. Für Werte >6 bei Disconnect after bleibt die Connection einfach opened.
Wenn ich also als Wert 30 Sekunden eintrage, geht er niemals in den disconnect - zumindest was ich in den letzten
20 Minuten testen konnte.

Gruß Andreas

Prof. Dr. Peter Henning

#52
Werde ich morgen testen. Ich habe jetzt die ganze Mimik der Erstellung von Readings in externe Programme ausgelagert, ist sehr viel einfacher. Meine readingList lautet nur noch
$DEVICETOPIC:.*  {roomba::reading($EVENT)}
sowie meine setList
start:noArg {roomba::command("start")}
stop:noArg {roomba::command("stop")}
dock:noArg {roomba::command("dock")}
resume:noArg {roomba::command("resume")}
pause:noArg {roomba::command("pause")}
CarpetBoost:true,false {roomba::setting("carpetBoost",$EVTPART1)}
TwoPass:true,false {roomba::setting("twoPass",$EVTPART1)}
VacHigh:true,false {roomba::setting("vacHigh",$EVTPART1)}
BinPause:true,false {roomba::setting("binPause",$EVTPART1)}
OpenOnly:true,false {roomba::setting("openOnly",$EVTPART1)}

jsonMap ist leer. Der zugehörige Code - kann man z.B. in myUtils packen, hängt unten dran. Achtung: Das ist experimenteller Code, Alpha-Version

LG

pah

Beta-User

Die readingList und setList sieht ziemlich cool aus!

Wir sollten das Namensschema-Thema mal allg. (im Developer-Bereich?) zur Diskussion stellen, in der zwave-Geschichte sieht das "etwas aufgedröselter" aus, was mich allerdings auch nicht nur glücklich macht, aber am Funktionsaufruf leichter erkennen läßt, wo der Code eigentlich herkommt. Bauchgefühl ruft nach praktikablem Mittelweg...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sturi2011

Guten Abend in die Runde,

den Alpha Code teste ich morgen Mittag - die Regierung ruft.
Dann mache ich auch noch mal einen Wireshark um zu sehen,
Was da hin und her fliegt und warum bei Disconnect >6 die
Verbindung stehen bleibt.

Gruß Andreas

Prof. Dr. Peter Henning

#55
EDIT: Ich habe gerade die Aufrufe in der readingList ebenso wie in der setList grundlegend geändert. Ist nötig, weil ich bei der Kartenerzeugung Referenzen auf das Device benötige. Nachstehend die aktuellen Definitionen, so werden sie auch bleiben.

Der Roomba-spezifische Code zur Erzeugung von Readings und zum Setzen diverser Parameter umfasst jetzt ca. 400 Zeilen, ich habe ihn darum erst einmal in ein Modul 99_RoombaUtils.pm ausgelagert. Wo man diesen Code später hinsteckt, lasse ich für den Moment noch offen - im Moment genügt es, dass 99_RoombaUtils beim FHEM-Start in /opt/fhem/FHEM liegt. Man kann das natürlich auch von Hand laden.

readingList:
$DEVICETOPIC:.* {roomba::reading($NAME,$EVENT)}

Die setList ist jetzt wegen der einzustellenden Saugprogramme etwas länger geworden.
start:noArg {roomba::command($NAME,"start",$EVENT)}
stop:noArg {roomba::command($NAME,"stop",$EVENT)}
dock:noArg {roomba::command($NAME,"dock",$EVENT)}
resume:noArg {roomba::command($NAME,"resume",$EVENT)}
pause:noArg {roomba::command($NAME,"pause",$EVENT)}
CarpetBoost:true,false {roomba::setting($NAME,"carpetBoost",$EVENT)}
TwoPass:true,false {roomba::setting($NAME,"twoPass",$EVENT)}
VacHigh:true,false {roomba::setting($NAME,"vacHigh",$EVENT)}
BinPause:true,false {roomba::setting($NAME,"binPause",$EVENT)}
OpenOnly:true,false {roomba::setting($NAME,"openOnly",$EVENT)}
ProgHold:true,false {roomba::setting($NAME,"schedHold",$EVENT)}
ProgSun:time {roomba::setsched($NAME,0,$EVENT)}
ProgMon:time {roomba::setsched($NAME,1,$EVENT)}
ProgTue:time {roomba::setsched($NAME,2,$EVENT)}
ProgWed:time {roomba::setsched($NAME,3,$EVENT)}
ProgThu:time {roomba::setsched($NAME,4,$EVENT)}
ProgFri:time {roomba::setsched($NAME,5,$EVENT)}
ProgSat:time {roomba::setsched($NAME,6,$EVENT)}


Das Modul befindet sich in der Anlage.

Nächster Punkt auf der Agenda: Karte zusamenbauen mit SVG. Funktioniert schon teilweise, der abgefahrene Pfad wird nach dem Ende des Durchlaufs in dem Reading cmPath abgelegt.

Vielleicht könnte jemand anders mal Folgendes probieren:
1. Robot mit einem "start" vom Dock entfernen.
2. Robot mit einem "stop" anhalten.
3. Mit einem geänderten set-Befehl die gegenwärtige Positionauf irgendetwas  _setzen_
4. Robot mit einem "dock" zum Dock schicken.

Die Frage steht nämlich im Raum, wie man die Kiste dazu bringen kann, an eine bestimmte Position zu fahren. Orientiert sie sich nur am IR-Signal der Docking Station? Was, wenn dieses nicht empfangen wird - geht es dann nach der Position?

LG

pah


Prof. Dr. Peter Henning

#56
OK, hier die erste mit FHEM erzeugte Karte. Roomba 960, saugte im Dachgeschoss. Schränke etc. sind gut erkennbar, ebenso der Treppenabsatz.
Die acht-förmigen Strukturen links sind Stuhlbeine (in der Mitte ein Tisch), die U-förmige Aussparung links oben ist ein Sessel, die 5-blasige Struktur rechts ein Schreibtischstuhl.

Unangenehm: Die Kiste läuft nicht senkrecht zur Wand los. Das bedeutet, dass man ggf. aus den Daten irgendwie ableiten muss, um welchen Winkel das Koordinaten gedreht werden müssen, um das so in einen Grundriss einzupassen.

LG

pah

Sturi2011

#57
Guten Abend,

erstmal zur Map -> genial.

Ich bin leider nicht früher zum Wireshark gekommen - kankes Kind... :(

Zum Thema Timeout > 5

Es ist tatsächlich so, dass alle 5 Sekunden vom Roomba ein Status kommt und er deswegen nicht in den Disconnect geht.
Das Timeout muss also doch eingehende Signale für den Timeout-Timer ignorienen. Doch noch eine "Bestellung"....

Siehe Screenshot vom Wireshark

Gruß Andreas

Prof. Dr. Peter Henning

Wieso ? Mit einem Timeout von 5 Sekunden kann man doch gut leben.

LG

pah

Sturi2011

Guten Abend,

prinzipiell schon, aber dann muss man ihn während der Reinigung pollen um die Position und die Statuswerte zu erhalten. Meine Idee war eher für verschiedene Aufgaben verschiedene Timeouts mitzugeben. Quasi für Start z.B. 2h um eben solange Stauswerte zu erhalten oder für Dock 10 Minuten - länger braucht er nicht zum Finden des Docks.

Gruß Andreas