Neues Modul: BOTVAC (für Neato BotVac Connected)

[bugware]

Guten Abend.

Vor der Reinigung erst irgendwelche Readings setzen zu müssen finde ich für automatisierte Abläufe immer etwas umständlich, deswegen bevorzuge ich die Lösung mit den Optionalen Parametern. Werden keinen Parameter im set Befehl angegeben, sollen die Werte aus den Attributen verwendet werden. Da ich die Reinigung über FHEM automatisiert starte sind mir die Wertelisten in der Weboberfläche nicht so wichtige. Zu 99% werden bei mir sowieso die gleichen Parameter verwendet, hier finde ich die Attribute super. Über die optionalen Parameter wäre man dann aber trotzdem noch flexibel.

Man braucht die zusätzlichen Readings ja nicht immer neu setzten. Wie bei den Attributen jetzt auch, würden die zusätzlichen Readings immer gesetzt bleiben. Der Unterschied ist nur, dass man sie setzten kann ohne die Config zu speichern. Und auch für eine Automatisierung, die die Parameter dann doch mal anpasst, wären Readings in meinen Augen die sauberere Lösung als Attribute.

Die optionalen Parameter (mit oder ohne Auswahl) und mit Fallback auf die Attribute, also so wie Schlimbo schreibt, wären natürlich auch prima, aber wie ich es verstehe ging das mit FHEMWEB nicht sauber. Da ich das nachher meist nicht über FHEMWEB nutze, wäre das für mich persönlich auch nicht dramatisch.

Beides Varianten fände ich besser als nur die Einstellung über Attribute. Wenn ich den source code richtig deute werden im Moment immer die Attribute verwendet, oder?

Beste Grüße.

[Schlimbo]

Man braucht die zusätzlichen Readings ja nicht immer neu setzten. Wie bei den Attributen jetzt auch, würden die zusätzlichen Readings immer gesetzt bleiben.

In einem automatisierten Ablauf müsste ich die Readings aber trotzdem vor einer Reinigung immer setzen, da ich ja nicht weiß, ob ein vorhergegangener Ablauf die Readings geändert hat.

[bugware]

Hallo.

In einem automatisierten Ablauf müsste ich die Readings aber trotzdem vor einer Reinigung immer setzen, da ich ja nicht weiß, ob ein vorhergegangener Ablauf die Readings geändert hat.

Das wäre doch bei den Attributen auch so. Die könnten ja auch geändert worden sein. Schlimmer noch, wenn jemand die Attribute ändert und dann ohne die config zu speichern FHEM neustartet, dann stehen da wieder die alten Werte.

Zudem kann man die Readings, wie schon gesagt, in anderen GUIs wie z.B. TabletUI auf dem üblichen Wege zur Kontrolle anzeigen (und bei Bedarf ändern). Das ginge mit Attributen nur mit Umwegen (und die Config will gespeichert werden).

Schlußendlich, wenn die Werte bei dir sowieso quasi nie geändert werden, dann ist es doch egal ob sie als Attribut oder als Reading vorliegen, oder?

Ich persönlich würde Sie häufiger, d.h. je nach Einsatzort, ändern.

Beste Grüße.

[Schlimbo]

Version 0.4.3 ist im Git und löst nach setMapBoundaries ein reloadMaps aus.

Danke, das Reading "boundaries" wird  jetzt nach einem setMapBoundaries aktualisiert.
Um Ressourcen zu sparen, würde hier aber auch ein getMapBoundaries ausreichen.

Auch die Aktualisierung der Karte nach einer Reinigung klappt bei mir. Wenn der D7 da etwas langsamer ist, kriegt er eine Sonderbehandlung.

Beim D7 bekomme ich nach der Reinigung häufig noch die alte Karte angezeigt.
Als workaround habe ich mir hierfür jetzt ein DOIF angelegt, das nach 10s noch mal einen reloadMaps ausführt.

Code Auswählen Erweitern

defmod di_reloadMaps DOIF ([Sauger:stateId] == 1 or [Sauger:stateId] == 4) (set Sauger reloadMaps)
attr di_reloadMaps wait 10

Die allgemeinen Kommandos antworten eigentlich mit einem aktuellen Status, daher bin ich mir nicht sicher, ob das Modul den wirklich nochmal explizit anfordern muss. Ich hatte bei mir das Gefühl, dass damit immer die richtigen Infos im Modul angezeigt werden.

Habe es gerade noch mal getestet, du hast recht, im Response sind die richtigen Infos vorhanden, muss ich noch mal etwas beobachten, weil das bei mir nicht immer so funktioniert hat.
Kann auch sein, dass die API bis vor kurzen bei houseCleaning:basic-3 nur einen "Standard Response" und keinen "State Response" geliefert hat, in der Doku steht nämlich noch "Standard Response".

Beim Testen ist mir aber noch ein anderer Problem aufgefallen:
Es gibt zwei unterschiedlich Rückmeldungsarten, "Standard Response" und "State Response".
https://developers.neatorobotics.com/api/robot-remote-protocol/request-response-formats
Das müsste in "BOTVAC_ReceiveCommand" noch abgefangen werden, da bei einem "Standard Response" die Parameter  "state", "action", "error" und "alert" nicht vorhanden sind und hierdurch das Reading state dann auf "Unknown" gesetzt wird, sowie ein anstehender error oder alert gelöscht wird.

Einen "Standard Response" gibt es z.B. bei findMe, setSchedule, setMapBoundaries, dismissCurrentAlert.

Das wäre doch bei den Attributen auch so. Die könnten ja auch geändert worden sein. Schlimmer noch, wenn jemand die Attribute ändert und dann ohne die config zu speichern FHEM neustartet, dann stehen da wieder die alten Werte.

In meinem Systeme ändert keine Automation, Attribute oder die config und somit kann ich mich darauf verlassen das die Attribute nicht verändert werden.

Ein Beispiel:
Meine Attribute sind wie folgt gesetzt

Code Auswählen Erweitern

attr Sauger cleaningMode turbo
attr Sauger cleaningNavigationMode normal
attr Sauger cleaningSpotHeight 200
attr Sauger cleaningSpotWidth 200

In 99% der Fälle würde ich einfach "set <name> startCleaning map" verwenden und es werden die default Einstellungen aus den Attributen verwendet.
Will ich mal eine Reinigung mit anderen Parametern starten würde ich nicht die Attribute ändern, sondern dies einfachen als options Parameter mitgeben wollen z.B. "set <name> startCleaning map eco"
Beim nächsten "set <name> startCleaning map" könnte ich mir sicher sein, dass wieder meine default Parameter verwendet werden.

Wird das jetzt über die Reading gehandled, würde ich für die eco-Reinigung also folgendes ausführen:

Code Auswählen Erweitern

set <name> nextCleaningMode eco
set <name> startCleaning map

Für meine Standard Reinigung (99% der Fälle) müsste ich also jedes mal folgendes ausführen

Code Auswählen Erweitern

set <name> nextCleaningMode eco
set <name> nextCleaningNavigationMode normal
set <name> startCleaning map
Da ich ja nie weiß, ob zwischenzeitlich eine Reinigung mit anderen Parametern durchgeführt wurde.

[vuffiraa]

Hallo,

momentan ist die Implementierung so, dass die Attribute genommen werden. Wenn es keine Attrubute gibt, wird in die Readings geschaut, und dann gibt es noch einen Default-Wert.

Meine momentane Idee für die Umsetzung wäre:
- die Befehle unterstützen optionale Parameter, aber im FHEMWEB werden sie parameterlos definiert und
- es gibt neue Readings next*.

Damit kann man in der Kommandozeile alle Parameter direkt angeben und die Reinigung starten. Im Fhemweb stellt man erst die Readings ein und startet dann die Reinigung, jeweils über die entsprechenden Set-Befehle. Jetzt kann man noch die Werte der letzten Renigung als defaults hinzuziehen, oder es werden einfach feste defaults genommen, das ist dann vielleicht auch klarer.

Gruß Vuffiraa

[bugware]

Hallo.

Meine momentane Idee für die Umsetzung wäre:
- die Befehle unterstützen optionale Parameter, aber im FHEMWEB werden sie parameterlos definiert und
- es gibt neue Readings next*.

Damit kann man in der Kommandozeile alle Parameter direkt angeben und die Reinigung starten. Im Fhemweb stellt man erst die Readings ein und startet dann die Reinigung, jeweils über die entsprechenden Set-Befehle. Jetzt kann man noch die Werte der letzten Renigung als defaults hinzuziehen, oder es werden einfach feste defaults genommen, das ist dann vielleicht auch klarer.

Klingt für mich gut. Ich hoffe Schlimbo kann sich auch damit anfreunden.

Beste Grüße.

[Schlimbo]

Hallo vuffiraa,

- die Befehle unterstützen optionale Parameter, aber im FHEMWEB werden sie parameterlos definiert

Wenn alle Reinigungsoptionen in einem Befehl übergeben werden können ist das für mich auch okay.

Habe gerade noch etwas mit spotCleaning experimentiert:
Im Modul ist noch ein Fehler, das cmd für spotCleaning müsste "startCleaning" und nicht "startSpot" heißen.
Habe hierfür gerade ein Pull Request erstellt, in dem ich auch noch die Unterscheidung der beiden Rückmeldungsarten, "Standard Response" und "State Response" nachgezogen habe.

- In der App wird beim SpotCleaning nur 400x400 an oder aus angeboten? Was macht er bei aus? Hat schon jemand probiert, welche Wertekombinationen beim D7 für das SpotCleaning möglich sind? Gehen auch Rechtecke wie 100x200? Hatte noch keine Zeit es selbst zu testen (zwei kleine Kinder ).

Habe die Möglichkeiten von spotCleaning gerade bei mir getestet:
-Es muss kein Quadrat sein, der Bereich ist von 100 - 400 cm, in 1 cm Schritten einstellbar. Rechtecke von z.B. 152x244 sind also möglich.
Im Anhang eine Zeichnung welcher Bereich bei spotCleaning gereinigt wird und wie cleaningSpotHeight & cleaningSpotWidth wirken.

Gruß
Schlimbo

[vuffiraa]

Hallo vuffiraa,Wenn alle Reinigungsoptionen in einem Befehl übergeben werden können ist das für mich auch okay.

Habe gerade noch etwas mit spotCleaning experimentiert:
Im Modul ist noch ein Fehler, das cmd für spotCleaning müsste "startCleaning" und nicht "startSpot" heißen.
Habe hierfür gerade ein Pull Request erstellt, in dem ich auch noch die Unterscheidung der beiden Rückmeldungsarten, "Standard Response" und "State Response" nachgezogen habe.

Gruß
Schlimbo

Dann werde ich die Anpassungen mal angehen.

Deine Änderungen schaue ich mir an. Du hast aber nicht auf der letzten Version gearbeitet, den Fehler bei der Spot-Reinigung hatte ich gestern schon behoben.

Gruß Vuffiraa

[Schlimbo]

Doch hatte ich, aber spotCleaning hat trotzdem noch nicht funktioniert. Schau dir meine Änderungen bitte noch mal an.

[vuffiraa]

Doch hatte ich, aber spotCleaning hat trotzdem noch nicht funktioniert. Schau dir meine Änderungen bitte noch mal an.

Habs gesehen. Da waren tatsächlich 2 Fehler. Ich hatte nur deinen Commit-Kommentar gelesen und dachte, dass kenne ich doch...

Darf ich mal fragen, in welcher Umgebung du entwickelst? Ich nehme Eclipse und verlinke die Dateien im Workspace mit den Git-Repository. Das funktioniert soweit ganz gut, solange ich nur selber entwickle. Bei einem Fetch gehen die Links aber flöten und ich muss das per Hand korrigieren.

Gruß Vuffiraa

[Schlimbo]

Nutze hierfür nur einen einfachen Text Editor. Mit Eclipse und EPIC habe ich mich noch nicht beschäftigt.
Gruß Schlimbo

[bugware]

Hallo zusammen.

Ich würde gerne nach dem Säubern die letzte Karte per Mail versenden.

Das was im Cache liegt, ist ein SVG. Vielleicht kann über

Code Auswählen Erweitern

BOTVAC_ShowMap("<device>"[,"<width>"[,"<height>"]])
etwas ähnliches wie beim SVG-Versand zudsammenstricken.

Siehe auch Beiträge https://forum.fhem.de/index.php/topic,51713.msg548498.html#msg548498 und https://forum.fhem.de/index.php/topic,51713.msg645801.html#msg645801 sowie die folgenden.

Wo liegt denn dieser Cache? Hat so etwas vielleicht schon jemand geschafft und könnte mir seine Lösung beschreiben?

Vielen Dank und beste Grüße.

[Schlimbo]

Der Cache liegt im unsichtbaren Reading ".map_cache"

Ich lasse mich über Telegram informieren, eventuell kannst du ja hiervon was übernehmen:

Code Auswählen Erweitern

defmod newMap.ntfy notify Sauger:map_date.* {\
my $map_status = ReadingsVal('Sauger', 'map_status', '');;\
my $map_date = ReadingsVal('Sauger', 'map_date', 'unknown');;\
my $map_area = ReadingsVal('Sauger', 'map_area', 'unknown');;\
my $error = ReadingsVal('Sauger', 'error', '');;\
my $alert = ReadingsVal('Sauger', 'alert', '');;\
my $msg = '';;\
if ($map_status eq "complete") {\
  $msg = '<b>Reinigung beendet!</b>\n';;\
}\
else {\
  $msg = '<b>Reinigung abgebrochen!</b>\n';;\
}\
$msg .= 'Fehler: '.NEATO_GetErrorText($error).'\n' if ($error ne '');;\
$msg .= 'Warnung: '.NEATO_GetErrorText($alert).'\n' if ($alert ne '');;\
$msg .= 'Gereinigte Fläche: '.$map_area.'qm\n';;\
$msg .= 'Map Date: '.$map_date;;\
fhem "define at_newMap at +00:00:10 set myTelegramBot _msg $msg;;;; set myTelegramBot cmdSend {ReadingsVal('Sauger', '.map_cache', '')}"\
}

Die 10 Sekunden Verzögerung habe ich eingefügt, da das laden der Map beim eintreten des triggers "map_date" noch nicht abgeschlossen ist.

[bugware]

Guten Abend.

Danke, funktioniert auch mit einer Mail. Code in 99_myUtils.pm:

Code Auswählen Erweitern

sub SendLastCleaningMap() {
  my $map_status = ReadingsVal('heinzelmann', 'map_status', '');
  my $map_date = ReadingsVal('heinzelmann', 'map_date', 'unbekannt');
  my $map_area = ReadingsVal('heinzelmann', 'map_area', 'unbekannt');
  my $error = ReadingsVal('heinzelmann', 'error', '');
  my $alert = ReadingsVal('heinzelmann', 'alert', '');
  my $msg = '';
  if ($map_status eq "complete") {
    $msg = 'Reinigung beendet!\n';
  } else {
    $msg = 'Reinigung abgebrochen!\n';
  }
  $msg .= NEATO_GetErrorText($error,$alert).'\n' if ($error ne '' || $alert ne '');
  $msg .= 'Gereinigte Fläche: '.$map_area.' qm\n';
  $msg .= 'Map Date: '.$map_date;
  #Log 3, $msg;
  fhem("define at_heinzelmann_newMap at +00:00:30 { my \$map = ReadingsVal('heinzelmann', '.map_cache', '');; my \$filename = './log/map.png';; open(my \$fh, '>', \$filename) or die \"Could not open file '\$filename'\";; print \$fh \$map;; close \$fh;; DebianMail('mail\@mail.mail','Heinzelmann','$msg',\$filename,-1);; }");
}

Beste Grüße.

[Schlimbo]

Hallo Vuffiraa,
weiß nicht ob du die Diskussion zur Vereinheitlichung der Batterie Readings hier im Forum mitbekommen hast. Es gibt mittlerweile eine Guidline für diese Readings:
https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings
Was hältst du deshalb davon, das Reading "charge" in "batteryPercent" umzubenennen?