Autor Thema: Roomba Staubsaugerroboter  (Gelesen 1677 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11623
  • eigentlich eher "user" wie "developer"
Antw:Roomba Staubsaugerroboter
« Antwort #30 am: 14 September 2020, 18:40:12 »
Hmm, bei der readingList kann man die CID jedenfalls dann rauslassen, wenn man nicht mehrere von den Dingern hat (es sollte wg. des individuellen IOs dann trotzdem klappen, aber es dürfte andere rL geben, wenn das Ding irgendeinen Namen hat?).

 Statt die ID irgendwie als regex-Teil zu nehmen, kannst du auch $DEVICETOPIC als Wildcard hernehmen (muß dann entsprechend gesetzt sein).

Wirf mal einen Blick auf den tasmota2zigbee-Teil. Da gibt es Logiken, einen inneren JSON zu erkennen und dann auch nur den auszuwerten; ansonsten gibt es bei json2nameValue() einen 4. Parameter, um Teile rauszufiltern (filter als Schlagwort sollte für j2nv wenige Treffer liefern).

Parameter kann man mit $EVTPART1 etc. übergeben, damit sollte z.B.
boost:true, false cmd {"json_elemente":"$EVTPART1"}gehen. Auch da gibt es einige Beispiele in der mqtt2.template-file, wenn man nach EVTPART sucht. setList kann auch Perl, es muß am Ende dann einfach ein String mit topic+Payload zurückgeliefert werden, wie du das zusammenbaust, bleibt dir überlassen (schnelles Beispiel: tasmota_rgbw_led). Zur Doku: Du darfst das gerne besser machen, ich suche noch nach einem freiwilligen, der einen Artikel zu den ganzen MQTT2_DEVICE-Attributen bzw. auch den allgemeinen FHEMWEB-Attributen entwirft (anhand eines shelly-pm). Da würde dann Perl-setList zwar erst ganz am Ende kommen, aber wer auch immer den schreibt, kann das ja aufnehmen ;) ... (Ansonsten ist die mqtt2.template ein ziemlich guter Steinbruch für alles mögliche, man muß nur wissen, nach was man sucht...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 2530
Antw:Roomba Staubsaugerroboter
« Antwort #31 am: 14 September 2020, 18:59:58 »
Zitat
boost:true, false cmd

Ist das richtig mit dem Leerzeichen zwischen dem Komma und false ? das klappt doch nicht oder doch ? Habs nicht ausprobiert...
Wenn doch, Kommentar einfach ignorieren.

edit:
für die mit weniger Erfahrung:
attr widgets setList 00select:1,2,3,4,5,a,b,c,def,hik
« Letzte Änderung: 14 September 2020, 19:46:16 von TomLee »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11623
  • eigentlich eher "user" wie "developer"
Antw:Roomba Staubsaugerroboter
« Antwort #32 am: 14 September 2020, 19:03:41 »
Unbeabsichtigt, sorry...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7453
Antw:Roomba Staubsaugerroboter
« Antwort #33 am: 15 September 2020, 14:14:56 »
Zitat
Zur Doku: Du darfst das gerne besser machen, ich suche noch nach einem freiwilligen, der einen Artikel zu den ganzen MQTT2_DEVICE-Attributen bzw. auch den allgemeinen FHEMWEB-Attributen entwirft (anhand eines shelly-pm).
Setze ich gerne auf meine Agenda. Allerdings schreibe ich derzeit an einem neuen Buch, das kann also ein Jahr dauern...

LG

pah

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11623
  • eigentlich eher "user" wie "developer"
Antw:Roomba Staubsaugerroboter
« Antwort #34 am: 15 September 2020, 14:31:59 »
Setze ich gerne auf meine Agenda. Allerdings schreibe ich derzeit an einem neuen Buch, das kann also ein Jahr dauern...
;D

Lass mal, vielleicht finde ich vorher einen anderen Freiwilligen, der das dann auch tatsächlich mal macht....? ("Jüngst" kam das mit dem eocr&Co wieder ganz neu in den Fokus :'( .)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7453
Antw:Roomba Staubsaugerroboter
« Antwort #35 am: 15 September 2020, 16:38:09 »
So, ich habe eine arbeitsfähige Version der ganzen Angelegenheit.

Unschön ist noch die gigantische Menge an Readings - von denen man dann die meisten wieder mit der jsonMap eliminieren muss. Mir schwebt derzeit vor, stattdessen ein paar Hilfsfunktionen zu definieren, die an Stelle von json2nameValue aufgerufen werden können und aus dem strukturierten JSON-Zeug wenige aussagekräftige Readings machen.

LG

pah

Offline TomLee

  • Hero Member
  • *****
  • Beiträge: 2530
Antw:Roomba Staubsaugerroboter
« Antwort #36 am: 15 September 2020, 16:50:27 »
Geht es denn nicht mit dem optionalen 4. Parameter von json2nameValue diese weniger aussagekräftigen Readings gleich zu erhalten ?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11623
  • eigentlich eher "user" wie "developer"
Antw:Roomba Staubsaugerroboter
« Antwort #37 am: 15 September 2020, 16:54:57 »
Halte ich für zielführend mit den Hilfsfunktionen, falls das mit "filter" in json2nameValue() nicht passt (?). (In der Hinsicht war TomLee schneller :) )

Es gibt eine funktionierende Konstruktion für ebus und den anderen Sauger, die man übertragen könnte: da wird myUtils-Code vom attrTemplate dann aus dem contrib-svn nachgeladen. Die "extended version" gäbe es in zwave.template: der zugehörige myUtils-Code ist dort auch noch als package ausgeformt...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline GerhardSt

  • New Member
  • *
  • Beiträge: 40
Antw:Roomba Staubsaugerroboter
« Antwort #38 am: 15 September 2020, 18:58:41 »
Hallo!

Find ich super, wenn man den Roboter wieder steuern kann.
Hab es gleich mit dem Roomba e5 probiert, damit funktioniert es auch.
Allerdings dürfte etwas noch nicht ganz stimmen, den so lange MQTT aktiv ist, leuchten am Roboter alle weißen LED (CLEAN, WLAN, Home) auf dauer.
Normal gehen die nach kurzer Zeit aus.
Ist das bei den anderen Typen auch so?

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7453
Antw:Roomba Staubsaugerroboter
« Antwort #39 am: 15 September 2020, 21:14:53 »
@Beta-User: filter wird es nicht tun. Wenn ich z.B. aus dem länglichen JSON-Ausdruck die Datenwerte für state_reported_cleanSchedule_H_7=9 und state_reported_cleanSchedule_m_7=0 nicht möchte, sondern daraus den Zeitpunkt 9:00 (Samstags) konstruieren will, komme ich um etwas Perl-code nicht herum.


@GerhardSt: Ich habe das jetzt mit einem 960 und einem 981 ausprobiert, zu anderen Typen kann ich nichts sagen. Aktuelle Version von readingList und setList anbei (DEVICETOPIC ist auf die BLID gesetzt). Finde ich aber prima, bei so vielen unterschiedlichen Typen kann man nur gemeinsam etwas erreichen. Es ist ganz instruktiv, sich dafür mit verbose=5 im MQTT2_CLIENT die rohen Events anzuschauen.

Bei mir sehe ich auch nichts von dauerhaft leuchtenden LEDs. Allerdings verliert, wenn ich "ecoCharge" true setze, der Roboter seine Verbindung und kann per MQTT offenbar auch nicht mehr aufgeweckt werden. Wenn ich etwas mehr Zeit habe, werde ich mal ausprobieren, ob ein Wake-On-Lan-Paket das Teil wieder aufweckt.

LG

pah

readingList:

$DEVICETOPIC:wifistat:.*  { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC:.*pose.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC:.*batPct.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC:.*Command.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC:.*cleanSchedule.* { json2nameValue($EVENT,'',$JSONMAP) }

setList

start:noArg cmd {"command": "start", "time": 1, "initiator": "localApp"}
stop:noArg cmd  {"command": "stop", "time": 1, "initiator": "localApp"}
dock:noArg cmd  {"command": "dock", "time": 1, "initiator": "localApp"}
resume:noArg cmd  {"command": "resume", "time": 1, "initiator": "localApp"}
pause:noArg cmd  {"command": "pause", "time": 1, "initiator": "localApp"}
CarpetBoost:true,false delta {"state": {"carpetBoost": $EVTPART1}}
TwoPass:true,false delta {"state": {"twoPass": $EVTPART1}}
VacHigh:true,false delta {"state": {"vacHigh": $EVTPART1}}
BinPause:true,false delta {"state": {"binPause": $EVTPART1}}
OpenOnly:true,false delta {"state": {"openOnly": $EVTPART1}}

jsonMap ist inzwischen etwas länglich
state_reported_pose_point_x:position_x
state_reported_pose_point_y:position_y
state_reported_pose_theta:position_theta
state_reported_lastCommand_initiator:lastCommandInitiator
state_reported_lastCommand_command:lastCommand
state_reported_lastCommand_time:0
state_reported_localtimeoffset:0
state_reported_mac:0
state_reported_netinfo_addr:0
state_reported_netinfo_bssid:
state_reported_netinfo_dhcp:0
state_reported_netinfo_dns1:0
state_reported_netinfo_dns2:0
state_reported_netinfo_gw:0
state_reported_netinfo_mask:0
state_reported_netinfo_sec:0
state_reported_signal_rssi:signalRSSI
state_reported_signal_snr:signalSNR
state_reported_utctime:0
state_reported_wifistat_cloud:0
state_reported_wifistat_uap:0
state_reported_wifistat_wifi:0
state_reported_wlcfg_sec:0
state_reported_wlcfg_ssid:0
state_reported_cleanMissionStatus_cycle:cmCycle
state_reported_cleanMissionStatus_error:cmError
state_reported_cleanMissionStatus_expireM:cmExpireM
state_reported_cleanMissionStatus_initiator:cmInitiator
state_reported_cleanMissionStatus_mssnM:cmMMission
state_reported_cleanMissionStatus_nMssn:cmNMission
state_reported_cleanMissionStatus_notReady:cmNotReady
state_reported_cleanMissionStatus_phase:cmPhase
state_reported_cleanMissionStatus_rechrgM:cmRechargeM
state_reported_cleanMissionStatus_sqft:cmSqft
state_reported_binPause:sBinPause
state_reported_carpetBoost:sCarpetBoost
state_reported_openOnly:sOpenOnly
state_reported_schedHold:sSchedHold
state_reported_twoPass:sTwoPass
state_reported_vacHigh:sVacHigh
state_reported_audio_active:audioActive
state_reported_batPct:battery
state_reported_bin_full:binFull
state_reported_bin_present:0
state_reported_dock_known:0
state_reported_batteryType:0
state_reported_cap_binFullDetect:0
state_reported_cap_carpetBoost:0
state_reported_cap_eco:0
state_reported_cap_edge:0
state_reported_cap_langOta:0
state_reported_cap_maps:0
state_reported_cap_multiPass:0
state_reported_cap_ota:0
state_reported_cap_pose:0
state_reported_cap_pp:0
state_reported_cap_svcConf:0
state_reported_hardwareRev:0
state_reported_sku:0
state_reported_soundVer:0
state_reported_uiSwVer:0
state_reported_cleanSchedule_cycle_1:tpSunday
state_reported_cleanSchedule_cycle_2:tpMonday
state_reported_cleanSchedule_cycle_3:tpTuesday
state_reported_cleanSchedule_cycle_4:tpWednesday
state_reported_cleanSchedule_cycle_5:tpThursday
state_reported_cleanSchedule_cycle_6:tpFriday
state_reported_cleanSchedule_cycle_7:tpSaturday
state_reported_cleanSchedule_h_1:tpSundayH
state_reported_cleanSchedule_h_2:tpMondayH
state_reported_cleanSchedule_h_3:tpTuesdayH
state_reported_cleanSchedule_h_4:tpWednesdayH
state_reported_cleanSchedule_h_5:tpThursdayH
state_reported_cleanSchedule_h_6:tpFridayH
state_reported_cleanSchedule_h_7:tpSaturdayH
state_reported_cleanSchedule_m_1:tpSundayM
state_reported_cleanSchedule_m_2:tpMondayM
state_reported_cleanSchedule_m_3:tpTuesdayM
state_reported_cleanSchedule_m_4:tpWednesdayM
state_reported_cleanSchedule_m_5:tpThursdayM
state_reported_cleanSchedule_m_6:tpFridayM
state_reported_cleanSchedule_m_7:tpSaturdayM
state_reported_bbchg3_avgMin:0
state_reported_bbchg3_estCap:0
state_reported_bbchg3_hOnDock:0
state_reported_bbchg3_nAvail:0
state_reported_bbchg3_nDocks:0
state_reported_bbchg3_nLithChrg:0
state_reported_bbchg3_nNimhChrg:0
« Letzte Änderung: 15 September 2020, 21:20:37 von Prof. Dr. Peter Henning »

Offline Sturi2011

  • Full Member
  • ***
  • Beiträge: 165
    • http://www.fohl.net
Antw:Roomba Staubsaugerroboter
« Antwort #40 am: 17 September 2020, 09:11:45 »
Hallo und erstmal vielen Dank für eure Mühen.

ich hatte schon länger vor meinen Roomba einzubinden.
Auf Wunsch der Regierung ist zufällig vorgestern der 2e 675 angekommen.

Ich habe es nach pah s "nackten Konfigurationsdaten" und jsonMAP / setList / readingList eingebunden.

Ich kann bestätigen:Die Roomba 675/676 funktionieren - auch mit der aktuellsten Firmware.

Gruß und Dank

Andreas
« Letzte Änderung: 17 September 2020, 09:19:49 von Sturi2011 »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11623
  • eigentlich eher "user" wie "developer"
Antw:Roomba Staubsaugerroboter
« Antwort #41 am: 17 September 2020, 09:47:06 »
@Beta-User: filter wird es nicht tun. Wenn ich z.B. aus dem länglichen JSON-Ausdruck die Datenwerte für state_reported_cleanSchedule_H_7=9 und state_reported_cleanSchedule_m_7=0 nicht möchte, sondern daraus den Zeitpunkt 9:00 (Samstags) konstruieren will, komme ich um etwas Perl-code nicht herum.
:) einleuchtend...

Daher gab es ja auch gleich die "extended Version":
Die "extended version" gäbe es in zwave.template: der zugehörige myUtils-Code ist dort auch noch als package ausgeformt...
Das mit package würde ich hier (vom Bauchgefühl her) für die "richtige" Vorgehensweise ansehen; das ganze hat dann ja wirklich den "Einschlag" eines eigenständigen Moduls, und evtl. läßt sich ja was vom Code des seitherigen Moduls wiederverwerten?
(Vermutlich werde ich auch den anderen MQTT2-Sauger-Code mal Richtung package umbauen, ist aber low prio).

(Ansonsten finde ich es klasse, dass sich so schnell weitere User für diesen "usecase" eingefunden haben, Danke für's "Anschubsen"!)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7453
Antw:Roomba Staubsaugerroboter
« Antwort #42 am: 17 September 2020, 10:00:23 »
Ich habe mich ja bisher immer um attrTemplate herumgedrückt. Allerdings erscheint es mir ab sofort sinnvoll, und ich werde auch das mit dem Package bevorzugen.

Es ist eigentlich auch logisch, dass bei der Vielzahl der vorhandenen Module damit etwas unterhalb der Modulebene enststeht, das mit verteilt werden kann.

Betreffend die Roombas habe ich Folgendes auf der Agenda:
- Bessere Rückmeldungen in FHEM über Zustand und Ablauf der Reinigung
- Erzeugen von Cleaning Maps via FHEM (aus den gemeldeten Positionen)

Wenn ich herausfinde, wie man die Kiste an eine bestimmte Position manövrieren kann, könnte man auch so etwas wie "hier ist es schmutzig, mach mal bitte da sauber" erreichen, ohne die Kiste hochzuheben.

LG

pah
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11623
  • eigentlich eher "user" wie "developer"
Antw:Roomba Staubsaugerroboter
« Antwort #43 am: 17 September 2020, 10:25:39 »
Ich habe mich ja bisher immer um attrTemplate herumgedrückt.
Na ja, das überrascht vielleicht, aber ich war auch erst skeptisch, ob das ganze ein "gutes" Werkzeug ist und noch skeptischer, als ich dann entschieden habe, via attrTemplate die "on/off"-Meldungen auf den Tasmota-firmwares auf Kleinschreibung umzukonfigurieren und damit etwas zu machen, was auch "außerhalb FHEM" Auswirkungen hat.

Grundsätzlich hat sich die ganze Methodik aber m.E. bewährt, vor allem für Sachen, die sehr "offen" in der Konfiguration sind und dem, was sie an Daten und Kommandos liefern, wie eben MQTT2_DEVICE (oder HTTPMOD, aber da lag es mAn. an dem bisherigen Maintainer, dass das nicht so recht vorwärts gekommen ist (wobei: "gefühlt" ist da auch deutlich mehr Bewegung drin als früher)).

Bin mal gespannt, ob das Werkzeug auch tauglich ist für "spezifischere" Dinge, z.B. ZWave, aber mAn. besteht schon ein gewisser Bedarf nach einer Standardisierung für FHEM auch da, wo es nicht zwingend wäre (wie eben bei ZWave). Mal sehen, können wir ja an anderer Stelle mal vertiefen...
(Für Mitleser: tendenziell wäre das auch ein Weg, standardisierte Konfigurationen für MODBUS zu teilen. Falls da jemand Starthilfe braucht: melden! Ich kenne da aber im Prinzip auch nur das Schlagwort.)

Zitat
Es ist eigentlich auch logisch, dass bei der Vielzahl der vorhandenen Module damit etwas unterhalb der Modulebene enststeht, das mit verteilt werden kann.
MAn. hängt das eher weniger an der Zahl der Module, sondern eher an der Art des "Inputs": MQTT2_DEVICE, HTTPMOD und MODBUS "leben" eigentlich vorwiegend durch Attribute, da ist der Weg über (z.B.) attrTemplate einfach sehr viel schneller, was updates und Reaktionen auf (z.B.) firmware- oder Webseiten-updates angeht, auch, weil die User nicht in den Modulcode müssen und daher eher geneigt sind, "patches" zu liefern.

Das mit der Zusatzsoftware ist zweischneidig, weil die (z.B. bei Systemwechseln) ggf. separat nachinstalliert werden muss. Da werden wir also irgendwann die ersten "Einschläge" haben... Insgesamt ist das Verfahren aber an sich soweit transparent (und bekannt), dass das handhabbar sein dürfte.

Von daher: Willkommen an Bord und viel Erfolg mit der Agenda für den Roomba!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Sturi2011

  • Full Member
  • ***
  • Beiträge: 165
    • http://www.fohl.net
Antw:Roomba Staubsaugerroboter
« Antwort #44 am: 17 September 2020, 12:14:29 »
Hallo,

das mit den dauerhaft leuchtenden LEDs kann ich für die 675/676 bestätigen.
Eventuell fehlt hir noch ein Poweroff? Oder kann mann die Verbindung des MQTT2 Clients geplant trennen und erneut aufbauen?

Ich bin zu jeder Schandtat (testen) bereit.

edit: nach etwas Geteste - wenn ich das MQTT Topic /blid/disconnect sende disconected der Client kurz conneted sich aber aufgrund von
nextopendelay nach 5 Sekunden wieder. Da hilft auch kein KeepAlive 0. Wenn ich das MQTT2_Client Device lösche geht Robi nach ca.
einer Minute schlafen. Lege ich es wieder an und trage das Passwort ein, ist er sofort wieder erreichbar. Das Licht ist dann aber auch an.

Gruß Andreas
« Letzte Änderung: 17 September 2020, 17:45:33 von Sturi2011 »