Roomba Staubsaugerroboter

Sturi2011 · 05 Oktober 2020, 11:43:41

Hallo,

du könntest aber mit der Rssi und deinen Karten hervorragend eine Karte zur Netzabdeckung erzeugen.
Man müsste ,,nur" den Fahrweg abhängig von rssi einfärben.

Quasi Roomba zum WLan ausleuchten....eigentlich genial, um tote Ecken zu finden / Accesspoints zu positionieren.

Ich glaube ich lass Robi mal bei meinen Problemkunden putzen 😬

Gruß

Andreas

Beta-User · 05 Oktober 2020, 11:45:30

Kleiner Hinweis: mit "periodicCmd" kann auch MQTT2_DEVICE in eingeschränktem Umfang Timer verwalten. Müßte also ggf. gehen, (notfalls mit etwas "Tricksen", da kann ja auch ein Perl-Kommando als setter/getter stehen) ohne ein betreffendes externes Device auszukommen

.

(Beispielsweise verwirft OpenMQTTGateway_BT_scanner immer nach 24h alle "gesammelten Werke"):

Code Auswählen

attr DEVICE setList\
  [...]\
  deleteReadings:noArg {fhem "deletereading -q $NAME (?!associatedWith).*"}
attr DEVICE periodicCmd deleteReadings:1440

Dracolein · 05 Oktober 2020, 12:37:11

Zitat von: Prof. Dr. Peter Henning am 05 Oktober 2020, 11:26:50
Richtig. Es scheint keine Möglichkeit zu geben, die gegenwärtigen Settings aktiv abzufragen. Und weil der Roboter den FHEM Client nicht aufwecken kann, habe ich mit einem kleinen separaten DOIF dafür gesorgt, dass (nur tagsüber und wenn nicht sowieso connected) alle 5 Minuten ein automatischer Connect von FHEM mit dem Roboter gemacht wird. Also spätestens nach 5 Minuten bekommt FHEM das mit - und erhält dann auch regelmäßig die Positionsdaten und die Netzwerkdaten.

Und ja: Ich finde das mit dem sekündlich aktualisierten RSSi auch grenzwertig, habe es darum bis auf ein Reading auch unterdrückt. Aber das ist nunmal der Kram, der vom Roboter kommt - verhindern kann man den wohl eher nicht.

LG

pah

Du hast in Deinem Listung von Seite 1 dieses Threads immerhin (u.a. )

Zitat2020-09-13 12:44:52 state Charging

dort stehen, das müsste imho eine Statusinfo von Deinem Roboter sein, oder nicht?
D.h. zum Zeitpunkt des Connects durch den MQTT2_Client befand sich der Roboter im Dock und war am aufladen.
Deine Workarounds bzgl. zyklischer Verbindungen habe ich gesehen.

Bei mir ändert sich state jedoch nie. Egal, ob der Robi im Dock steht oder gerade fährt, es steht in diesem Reading bei mir immer der zuletzt aus FHEM gesandte Befehl mit Timestamp wann er versendet wurde. Die anderen Readings bzgl. Netzwerk etc. aktualisieren sich brav 1malig bei Connect.

Prof. Dr. Peter Henning · 07 Oktober 2020, 12:33:30

Hmmm. Katastrophal: gestern abend noch problemlos einen Lauf eines der Roboter gestartet, heute morgen ging gar nichts mehr. Das MQTT2_CLIENT bekommt keine Verbindung mehr zu einem der beiden Roboter, auch ein manueller Connect-Befehl bewirkt GAR NICHTS. verbose=5 liefert nur in kurzen Abständen

Zitat020.10.07 12:28:37 5: HttpUtils url=https://192.168.0.xx:8883/
2020.10.07 12:28:37 4: IP: 192.168.0.xx -> 192.168.0.xx
2020.10.07 12:28:46 5: HttpUtils url=https://192.168.0.xx:8883/
2020.10.07 12:28:46 4: IP: 192.168.0.xx -> 192.168.0.xx

Keine Fehlermeldung, kein Rückgabewert, kein nix. Auch keine Response der Roboter.

Steuerung per App geht noch.

Edit: Problem behoben - aber Ursache noch nicht klar. Das Einzige, was tatsächlich Abhilfe schaffte, war ein Hardware-Reset beider Roboter durch kurzen Ausbau des Akkus. Die beiden waren übrigens auch nicht mehr durch die Python-Anwendung Roomba980 erreichbar, ebensowenig durch die JavaScript-Anwendung dorita980. Was kann der Grund sein? Ich habe seit gestern von FHEM aus einen regemäßigen manuellen Connect vorgenommen - aber kein Kommando gesendet. Aus dem Bauch heraus: möglicherweise speichert der interne MQTT-Broker der Roboter die IP-Adresse, von der aus die Connects ohne Daten kommen, in einer Blacklist und nimmt davon nichts mehr entgegen. Oder ein Puffer läuft voll. Oder die Kiste ist in einer Endlosschleife und wartet auf Daten aus der Quelle.

Der langen Rede kurzer Sinn: Vielleicht könnte einer der anderen Interessenten mal versuchen, das Problem nachzustellen: Tagsüber alle 5 Min einen automatischen Connect, und das mal eine Weile laufen lassen. Und schauen, ob der Roboter nach einem Tag noch erreichbar ist.

LG

pah

rudolfkoenig · 07 Oktober 2020, 16:57:01

ZitatKeine Fehlermeldung, kein Rückgabewert, kein nix. Auch keine Response der Roboter.

Hypothese: TCP Verbindungsaufbau samt TLS Handshake ist durchgelaufen, der MQTT Server hat aber nicht auf die MQTT CONNECT Nachricht reagiert.
Ich habe jetzt MQTT2_CLIENT angepasst, damit der Timer in diesem Fall auch zuschlaegt, und eine Meldung produziert.

Prof. Dr. Peter Henning · 08 Oktober 2020, 10:34:18

Update:

1. Schwäche der bisherigen Installation: Wenn die Kiste steckenbleibt, geht der Client natürlich nach dem eingestellten timeout auf disconnected. Das ist übel, weil man ja selten innerhalb von 5 Sekunden die Ursache beheben kann. Nötig ist also ein zyklisches connect, damit man das Weiterfahren dann nicht verpasst.

2. Bei den Karten mache ich derzeit aus Zeitmangel nur geringe Fortschritte. Als erfolgversprechend hat sich Folgendes herausgestellt:

a. Einmalig: Bestimmung der konvexen Hülle des maximalen Saugbereiches aus einem Plan der Wohnung, sowie des entsprechenden Schwerpunktes (Zentroid).
b. Nach jedem Lauf: Bestimmung der konvexen Hülle des abgesaugten Bereiches, sowie dessen Zentroid.
c. Abgleich von b. mit den Daten aus a. liefert die notwendige Transformation, um den abgesaugten Koordinatenbereich genau in den Plan der Wohnung einzupassen.

LG

pah

Eisix · 19 Oktober 2020, 12:31:57

Hallo,

habe gestern mal mein Glück versucht an einem i7

Code Auswählen


Robot Data:
{ ver: '3',
  hostname: 'iRobot-XXXX',
  robotname: 'Putzfee',
  robotid: ''XXXX,
  ip: '192.168.X.X,
  mac: 'XXXX',
  sw: 'lewis+3.10.8+lewis-release-rt320+13',
  sku: 'i755640',
  nc: 0,
  proto: 'mqtt',
  cap:
   { binFullDetect: 1,
     dockComm: 1,
     wDevLoc: 2,
     bleDevLoc: 1,
     edge: 0,
     maps: 3,
     pmaps: 4,
     tLine: 2,
     area: 1,
     eco: 1,
     multiPass: 2,
     pose: 1,
     team: 1,
     pp: 0,
     '5ghz': 1,
     prov: 3,
     sched: 1,
     svcConf: 1,
     ota: 2,
     log: 2,
     tileScan: 1 },
  blid: 'XXXX' }
Password=> XXXX <= Yes, all this string.
Use this credentials in dorita980 lib :)

Passwort und ID auslesen ging. Leider verbindet der MQTT-client nicht.

Code Auswählen


Internals:
   BUF        
   CFGFN      
   DEF        192.168.X.X:8883
   DeviceName 192.168.X.X:8883
   FUUID      5f7c2c61-f33f-9eb9-e80b-2411f9c9f72d0af4
   NAME       PutzfeeClient
   NEXT_OPEN  1603103254.02846
   NR         925
   PARTIAL    
   SSL        1
   STATE      disconnected
   TYPE       MQTT2_CLIENT
   WBCallback 
   clientId   blid
   connecting 1
   lastMsgTime 1603096483.99491
   nextOpenDelay 5
   READINGS:
     2020-10-19 12:27:29   state           disconnected
   powerMap:
   readingsDesc:
     energy:
       rtype      whr
     power:
       rtype      w
   sslargs:
     SSL_version SSLv23
Attributes:
   SSL        1
   autocreate simple
   clientId   blid
   room       MQTT2_DEVICE
   sslargs    SSL_version:SSLv23
   username   blid
   verbose    5

ist bei attr Username und ClientID jeweils die blid einzutragen?

Password habe ich über set gesetzt.
Jemand noch einen Tip für mich?

Gruß
Eisix

Eisix · 19 Oktober 2020, 16:47:49

Noch das Log

Code Auswählen


2020.10.19 16:41:18.247 5: PutzfeeClient: sending CONNECT (16)p(0)(6)MQIsdp(3)(194)(0)(30)(0) blid(0) blid(0)(30)PWD
2020.10.19 16:41:18.248 5: SW: XXXX
2020.10.19 16:41:18.251 1: 192.168.X.X:8883 reappeared (PutzfeeClient)
2020.10.19 16:41:18.257 3: Opening PutzfeeClient device 192.168.X.X:8883
2020.10.19 16:41:18.257 5: HttpUtils url=https://192.168.X.X:8883/
2020.10.19 16:41:18.257 4: IP: 192.168.X.X -> 192.168.X.X
2020.10.19 16:41:18.262 4: HttpUtils: 192.168.X.X: Connection reset by peer (104)
2020.10.19 16:41:18.433 1: 192.168.X.X:8883 disconnected, waiting to reappear (PutzfeeClient)
2020.10.19 16:41:18.449 5: HttpUtils url=https://192.168.X.X:8883/
2020.10.19 16:41:18.450 4: IP: 192.168.X.X -> 192.168.X.X
2020.10.19 16:41:18.455 4: HttpUtils: 192.168.X.X: Connection refused (111)

Prof. Dr. Peter Henning · 19 Oktober 2020, 19:14:27

Zitatist bei attr Username und ClientID jeweils die blid einzutragen?

So hab ich es gemacht, ja.

Ist die SSl-Version richtig gesetzt?

LG

pah

Sturi2011 · 19 Oktober 2020, 20:24:43

Hallo,

username und clientid = blid - keine Leerzeichen?
Password ohne Leerzeichen?
IP richtig?
Aktuelle Firmware mit der APP geflusht?

SSL Passt so mit 23.

Eventuell mal Port 1883 probieren.

Gruß Andreas

Eisix · 19 Oktober 2020, 21:01:31

Hallo,

sslargs SSL_version:SSLv23

blid: 'X'
sollte dann das X sein

Password=> X <= Yes
hier auch das X

IP ist richtig, letzte Firmware ist drauf

Port 1883 habe ich probiert hat nicht funktioniert, aber ich denke 8883 ist richtig sieht man auch am log "Opening PutzfeeClient"

Code Auswählen


telnet 192.168.X.X 8883
Trying 192.168.X.X...

Connected to 192.168.X.X.
Escape character is '^]'.

Gruß
Eisix

Sturi2011 · 19 Oktober 2020, 21:13:26

Hallo,

welche Version von openssl ist auf dem Server?

Gruß Andreas

Eisix · 19 Oktober 2020, 21:54:20

openssl version

OpenSSL 1.1.1f 31 Mar 2020

Prof. Dr. Peter Henning · 20 Oktober 2020, 05:04:28

Zitatblid: 'X'
sollte dann das X sein

Password=> X <= Yes
hier auch das X

Nein. Das Passwort ist ein deutlich längerer String, etwa in der Form

Code Auswählen

Roomba (Feger) IP address is: 192.168.0.zz 
blid is: 3112345678900 
Password=> :1:112345670:g698ehf9j0306A <= Yes, all this string.

LG

pah

Eisix · 20 Oktober 2020, 07:14:24

Hallo pah,

Ich war sehr sparsam mit den den X'en

Also sind alle drei durch : getrennte Felder das Passwort oder nur das letzte?
Das erste Feld :1 ist bei allen gleich
Das zweite Feld :112345670 ist der Unix timestamp der Passworterzeugung
Das dritte ist das eigentliche Passwort
Habe schon alles und das dritte Feld ohne Erfolg probiert.

Gruß
Eisix