Roomba Staubsaugerroboter

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

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Seltsam. Ich erhalte Status und Position auch bei einem Timeout von 5 Sekunden. Und zwar bei beiden Kisten.

LG

pah

Sturi2011

Hallo,

ich habe jetzt noch mal getestet. Wenn er mehr als 5 Sekunden DisconnectTimeout eingestellt bekommt, macht er keinen Disconnect.
Dies geschieht aufgrund der eingehenden Statusmeldungen. Stelle ich ihn auf 5 Sekunden ein, disconnected er den MQTT Client.
Das bedeutet, dass er das MQTT Abonnement sauber beendet. Damit bekommt er vom MQTT Server des Roombas keine weiteren
Informationen mehr mitgeteilt - ergo auch keine Statuswerte.

Gruß Andreas

rudolfkoenig

ZitatDamit bekommt er vom MQTT Server des Roombas keine weiteren Informationen mehr mitgeteilt - ergo auch keine Statuswerte.
Ich verstehe noch nicht, warum erwaehnenswert ist, dass ohne eine Verbindung keine Daten ausgetauscht werden. Uebersehe ich etwas?

Sturi2011

Guten Morgen,

Ja ich hatte versucht zu erklären, dass ein Disconnect Timeout >5 nicht zum Disconnect führt, da vom Roboter Statusdaten kommen. Ich habe aber Timeout und nicht DisconnectTimeout geschrieben, was vermutlich zu Missverständnissen führte. Siehe die letzten Posts.

Daher habe ich das mit dem Disconnect noch einmal explizit beschrieben, wobei es natürlich wie erwartet dem Protokoll entspricht.

Gruß Andreas

Prof. Dr. Peter Henning

Ich verstehe das Problem auch nicht - bei mir laufen die beiden Kisten wie gewünscht.

LG

pah

Sturi2011

#65
Hallo die Herren,

also bei den 675/676 verhält es sich folgendermaßen:

Stelle ich ein DisconnectTimeout kleiner/gleich 6 ein, disconnected er nach der eingestellten Anzahl an Sekunden. Dabei ist es völlig egal, ob er in einem Reinigungszyklus ist oder auf dem Dock steht. Offensichtlich überträgt er hier beim Reinigen auch nur alle ca. 6 Sekunden etwas (Position,...)

Stelle ich ein DisconnectTimeout größer 6 ein bleibt die Verbindung dauerhaft bestehen. Auch hier ist es egal in welchem Zyklus er sich befindet. Es werden regelmäßig Statusdaten übertragen.

Wenn ich mir was wünschen dürfte, dann die Implementierung von Connect und Disconnet als Methoden für den MQTT2_Client. Dann könnte mann mit Notifys und AT Timern arbeiten.

Also z.B.
Wenn Status docked, dann disconnect.
Stündlich einen Connect und nach 2 Minuten wieder ein Disconnect um die Aktuellen Akkustände zu erhalten.
usw usf

Vermutlich verhält es sich bei den größeren Modellen der Roomba anders mit den Intervallen (Mehr Rechenleistung?)

Gruß Andreas

Prof. Dr. Peter Henning

#66
Ich habe keine Problem, das mit den Connects und Disconnects zu verstehen. Allerdings verstehe ich nicht, welche Auswirkung das auf das Verhalten der Roboter haben sollte. Nur im Schlafmodus sollte die Verbindung disconnected sein, damit die Kiste sich wirklich ausruht und die LED ausgehen.

Nachtrag: ein automatischer Disconnect von wenigen Sekunden führt bei einem langsamen Start des Roboters dazu, dass die Verbindung nicht mehr besteht. Gleiches gilt, wenn der Robot durch die App gestartet wird - der Roboter kann eben nicht von sich aus die Verbindung mit FHEM herstellen. Damit kommen in FHEM auch keine Positionsupdates mehr an. Merkt man aber natürlich und kann - z.B. mit dem Setzen eines bereits gesetzten Attributes - sofort für einen Reconnect sorgen. Da die Positionsupdates ca. 1x pro Sekunde kommen, wird die Verbindung dann offengehalten.

Natürlich könnte man auch mit einem "get" bestimmte Daten abfragen - allerdings habe ich den MQTT-Topic zur Statusabfrage noch nicht herausgefunden. Das nochmalige Setzen eines Attributes löst die Sendung dieser Statusinformationen aus.


Also aus meiner Sicht alles in Butter, und das System ist problemlos ohne weitere Änderungen an MQTT_Device oder _Client einsetzbar.

LG

pah


Sturi2011

Hallo,

leider nicht, denn unter 6 Sekunden Disconnected er immer, über 6 Sekunden Bleibt die Verbindung für immer bestehen.
Dabei ist es völlig egal in welchem Zustand sich der Robooter befindet.

Die Positionsupdates kommen beim 675 leider auch nur - wie oben geschrieben alle 6 Sekunden.

Attribute im Robotter sinnlos hin und her setzen möchte ich eher nicht. Get würde ein pollen des Robotters verlangen.

Wenn ich das Attribut DisconnectAfter per Notify für die Reinigung verändere erscheint im Fhem das rote Fragezeichen...

Gruß Andreas

Sturi2011

Hallo,

noch ein Nachsatz zum 99_RoombaUtils.pm

Zeile 174:

  }elsif( $cmd =~ /("stop")|("dock")/){

Stop und Dock funktioniert bei mir nur mit zus. eingefügten Anführungszeichen.
Das haben Sie aber bestimmt auch schon selbst herausgefunden - nur für Leute die hier mitlesen...

rudolfkoenig

Ich habe jetzt set connect bzw. disconnect hinzugefuegt.

Prof. Dr. Peter Henning

@Rudi: Danke.

@Sturi
Zitat}elsif( $cmd =~ /("stop")|("dock")/){
Äh - nö. Das funktioniert korrekt auch ohne Anführungszeichen, wi eman auch leicht unter https://regex101.com/ testen kann.

Allerdings fliegt das auch umgehend wieder heraus - dann man kann nicht 100 kB String in ein FHEM_Reading packen.

Ich knobele noch an einem Algorithmus für die Nachbearbeitung der Karten. Denn tatsächlich läuft der Roboter durchaus in leicht unterschiedlicher Richtung los.


LG

pah

Sturi2011

Hallo in die Runde,

@Herr König,

vielen Dank für die viele Arbeit. Ich werde heute Abend respektive morgen Vormittag ausgiebig testen.

@Herr Henning,

Ohne die Anführungszeihen kommt bei mir leider LastCommand Start (oder was auch immer ich vorher gedrückt habe)
wenn ich auf Stop oder Dock drücke...mit Anführungszeichen funktioniert es.
Das mag am Perl 5.20.2 im Docker Container liegen.

Prallel dazu wirft er den Fehler:

2020.09.23 15:51:27 1: ERROR evaluating my $DEVICETOPIC=   $evalSpecials->{'%DEVICETOPIC'};my $EVENT=   $evalSpecials->{'%EVENT'};my $EVTPART0=   $evalSpecials->{'%EVTPART0'};my $NAME=   $evalSpecials->{'%NAME'};{roomba::command($NAME,"stop",$EVENT)}: Can't use an undefined value as an ARRAY reference at ./FHEM/99_RoombaUtils.pm line 175.

Nach Einbau der Hochkommata ist der Fehler weg. Ob das nun ursächlich war.... wenn es rausfliegt ist es sowieso egal.

->Notiz an mich selbst Container updaten!

Zur Ausrichtung der Map:
Eventuell den Winkel der Karte zu zwei Berührungspunkten mit der Wand links und rechts neben der Dockingstation abgleichen.
Das funktioniert aber nur, wenn die Dockingstation an einer glatten Wand steht - was aber in den seltendsten Anwendungsfällen
so sein wird. Damit wäre es nicht universell einsetzbar.
Alternativ können wir mal testen, ob mann eine virtual Wall als Fixpunkt einsetzen kann und ob dazu Stauswerte zurückkommen,
respektive wie er die Virtual Wall erkennt.

Wenn es Testcode gibt und nirgendwo eine Virtual Wall vorhanden ist, würde ich zu Testzwecken eine bestellen.

Gruß Andreas

rudolfkoenig

ZitatOhne die Anführungszeihen kommt bei mir leider LastCommand Start (oder was auch immer ich vorher gedrückt habe) wenn ich auf Stop oder Dock drücke...mit Anführungszeichen funktioniert es.
Das ist vermutlich wie bei der Homoeopathie. Wissenschaftlich nicht zu erklaeren :)

Prof. Dr. Peter Henning

Ich habe 3 Virtual Walls - da gibt es kein Datum in den Statuswerten, dass er die getroffen hat. Ich habe schon Vorstellungen, wie man die Karten aufarbeiten kann.

Anbei zur Belustigung die Karte zweier Läufe in meinem Dachgeschoss - so richtig deterministisch ist das nicht.


LG

pah

carlos

Ich schaffe es immer noch nicht, dass sich mein MQTT2_Client mit meinem Roomba verbindet.
Im log sehe ich nur:
2020.09.27 23:13:34 5: HttpUtils url=https://192.168.178.62:8883/
2020.09.27 23:13:34 4: IP: 192.168.178.62 -> 192.168.178.62
2020.09.27 23:13:36 4: HttpUtils: https://192.168.178.62:8883/: Can't connect(2) to https://192.168.178.62:8883:  SSL connect attempt failed error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

Bin für jede Hilfe dankbar.

Gruß

Carlos
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly