Modul für Irobot Roomba 980

[Thorsten Pferdekaemper]

Ne, da tut sich nix, bleibt leider online.

Was meinst Du mit "online"? Das Reading "connection" sollte auf "disconnected" gehen. ...und zwar bis man wieder "set ... connect" macht.
Falls das nicht so ist, könntest Du mal verbose auf 3 setzen und das Log hier reinstellen?
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Wie seht ihr das? Macht es Sinn, so einen "Off"-Befehl in das Modul zu integrieren oder gehört so etwas da nicht hinein?

Sorry für die späte Antwort...
Ich finde, dass ein FHEM-Modul möglichst nur das widerspiegeln sollte, was das Gerät auch tatsächlich kann. In dem Fall ist das mit dem "dock" auch so, wenn man es über die App macht. Ich glaube sogar, dass man den "Home"-Knopf auf dem Gerät selbst zweimal drücken muss, wenn man es während der Fahrt nach Hause schicken will. Was über die "eigentlichen" Fähigkeiten des Geräts hinausgeht sollte meiner Meinung nach über FHEM-Mittel erledigt werden. In dem Fall ist es ja relativ einfach:

Code Auswählen Erweitern


set robbie stop; sleep 2; set robbie dock

Das hat sogar den Vorteil, dass FHEM während den 2 Sekunden nicht blockiert.

Andererseits ist es in dem Fall tatsächlich so, dass man sich über die vorhandene Funktionalität wundert. Daher könnte ich mir schon vorstellen, dass man so etwas in dem Fall ins Modul aufnimmt. Allerdings gefällt mir der Name nicht und es darf auf keinen Fall 2 Sekunden blockieren. Es müsste also in etwa so aussehen:

Code Auswählen Erweitern


    # Dock even if running
    $command eq "stopAndDock" and do {
        apiCall($hash,"cmd","stop");
        InternalTimer(gettimeofday()+2, &main::fhem, "set ".$hash->{NAME}." dock");
        last;
    };

Wenn Du das testen magst und es funktioniert, dann kann ich das "offiziell" übernehmen.

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hallo ct,

seit Mittwoch Abend lief es stabil und jetzt plötzlich:

Code Auswählen Erweitern

2017.07.28 16:26:06 1: 10.12.3.14:8883 reappeared (Roombi)
Can't use an undefined value as an ARRAY reference at FHEM/lib/Net/MQTT/Message/Unsubscribe.pm line 25.
2017.07.28 16:26:11 1: BlockingInformParent (BlockingStart): Can't connect to localhost:38791: IO::Socket::INET: connect: Connection refused
2017.07.28 16:26:11 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:38791: IO::Socket::INET: connect: Connection refused
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/opt/yowsup-master/yowsup/demos/cli/cli.py", line 153, in startInputThread
    cmd = self._queuedCmds.pop(0) if len(self._queuedCmds) else input(self.getPrompt()).strip()
EOFError: EOF when reading a line


...ich dreh durch 

Hi,
ich weiß, dass das eine Weile her ist (daher auch Full-Quote), aber ich bin gerade mal am Überarbeiten.
Bist Du Dir sicher, dass der Absturz vom Roomba-Modul kommt? Speziell der Python-Kram kommt mir schon etwas komisch vor. Nach der "reappeared" Message kommt nur noch ein "trigger Roombi CONNECTED". Kann es sein, dass Du irgendwas (notify, FileLog etc.) hast, was darauf reagiert (ob jetzt beabsichtigt oder nicht...).
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

hab das Modul etwas modifiziert, da es ab und zu den Usernamen und Passwort vom Roomba nicht mehr findet. Siehe Anhang. Viel Spaß beim Testen.

Hi,
ich denke, dass der wesentliche Punkt war, dass Username/Password in der UndefFn gelöscht wurden. Das habe ich jetzt in die DeleteFn gepackt, die bei rereadcfg nicht aufgerufen wird.
Außerdem kann man jetzt Username/Password bei modify oder defmod neu setzen.
(Neue Version ist bald im git.)
Gruß,
  Thorsten

[Thorsten Pferdekaemper]

Hi,
so, ich habe jetzt mal alles aus dem Thread hier in die Git-Version übernommen. (https://github.com/ThorstenPferdekaemper/FHEM-Roomba980).
Die ganzen "ct-Sicherungen" sind dabei und das Passwort-Handling ist ein klein wenig besser. D.h. es sollte nicht mehr verloren gehen (z.B. bei rereadcfg) und man kann es per modify/defmod ändern.
Das mit den "Sicherungen" bedeutet, dass FHEM nicht mehr abschmiert (hoffentlich), wenn der Sauger Müll sendet. Dafür gibt's jetzt Log-Einträge.
Ich habe das ganze gar nicht getestet (also 0%, rien, nada, нищо). Wer das jetzt gleich in sein Produktivsystem reinhaut und dann eine schlaflose Nacht hat ist also selbst Schuld. Es wäre natürlich schön, wenn es jemand testen könnte.

Die ganzen Verbindungsabbrüche, Blockaden etc., von denen hier berichtet wird, werden durch diese Version wahrscheinlich nicht gelöst. Da müsste mal jemand anders ran. ...oder das ganze liegt gar nicht wirklich an dem Modul.
Gruß,
   Thorsten


 

[luetty]

Hi,
ich weiß, dass das eine Weile her ist (daher auch Full-Quote), aber ich bin gerade mal am Überarbeiten.
Bist Du Dir sicher, dass der Absturz vom Roomba-Modul kommt? Speziell der Python-Kram kommt mir schon etwas komisch vor. Nach der "reappeared" Message kommt nur noch ein "trigger Roombi CONNECTED". Kann es sein, dass Du irgendwas (notify, FileLog etc.) hast, was darauf reagiert (ob jetzt beabsichtigt oder nicht...).
Gruß,
   Thorsten

Hallo Thorsten,

ich hatte zum Schluß das Gefühl, dass es nicht das Roomba-Modul ist, sondern irgendwas auf die MQTT-Message reagiert und es dann knallt.
Die fhem-Installation ist halt auch über die Jahre etwas gewachsen, lief aber immer stabil.

Daraufhin habe ich das Modul auf einem RPI aktiviert, der per f2f angebunden ist. Ich habe dort dann aber relativ schnell wieder dieses connect/ disconnect Verhalten gehabt, jedoch keinen Absturz.
Letzte Chance war eine komplett frische Linux-VM, jungfreuliches fhem und nur das Roomba-Modul aktiv.
Seit ich es so dediziert betreibe schnurrt die Sache wie ein Kätzchen, keine ständigen dis-/connect's & kein Crash. 

Gut, "schön" ist die zusätzliche VM nicht - stört im Moment aber auch nicht. 

ciao
luetty

[Det20]

Was meinst Du mit "online"? Das Reading "connection" sollte auf "disconnected" gehen. ...und zwar bis man wieder "set ... connect" macht.
Falls das nicht so ist, könntest Du mal verbose auf 3 setzen und das Log hier reinstellen?
Gruß,
   Thorsten

Ne bleibt online, ändert rein garnix. Im Log steht nur:

2018.03.09 16:37:36 1: Error sending message:

[Thorsten Pferdekaemper]

Hi,
könntest Du bitte genau sagen, woran Du siehst, dass das Ding "online" bleibt? Einen Status "online" gibt es IMHO gar nicht.
Ich habe außerdem eine neue Version ins Git gestellt (mit den "ct-Sicherungen" etc.). Könntest Du die mal ausprobieren?
Gruß,
   Thorsten

[Det20]

Einen Status "online" gibt es IMHO gar nicht.

Ahhhh

[Thorsten Pferdekaemper]

Ahhhh

Hä?

[Oliver1985]

Guten Tag zusammen.
Bin ich der Einzige, der die Meldung "Cannot load module Roomba980" erhält, wenn er das define versucht?

[Thorsten Pferdekaemper]

Bin ich der Einzige, der die Meldung "Cannot load module Roomba980" erhält, wenn er das define versucht?

Keine Ahnung. Hast Du denn die Datei 42_Roomba980.pm im FHEM-Folder?
Gruß,
  Thorsten

[Oliver1985]

Jawohl.

Direkt aus deinem Git geladen. opt/fhem/FHEM... korrekt?
Wenn ein Modul nicht existiert erhält man "Unknown module xy", daher nehme ich an, dass es an der richtigen Stelle liegt.
Gibt es irgendwelche Voraussetzungen, die ich hier in diesen 9 Seiten überlesen habe?!

[Thorsten Pferdekaemper]

Hi,
schau mal was im Log steht, ggf. global verbose hochsetzen.
Gruß,
  Thorsten

[Oliver1985]

Hi,
schau mal was im Log steht, ggf. global verbose hochsetzen.
Gruß,
  Thorsten

-.- Hätte niemals angenommen, dass ich bei der Meldung etwas im Log finde: Aber tatsächlich:  "Can't locate Module/Pluggable.pm"

Vielen Dank für den Hinweis, Thorsten. Ich habe ja jetzt einen Ansatz und versuche es mal alleine zu lösen. Melde mich, falls ich nicht weiter komme...

Gruß,
Oliver