Xiamoni Vacuum / Roborock: MQTT-Ansteuerung mit Valetudo / attrTemplate

Begonnen von krikan, 27 Oktober 2019, 09:50:12

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Fehler wurden bisher ignoriert, falls sie nach einem AttrTemplate "Replace" Dialog aufgetreten sind, das habe ich jetzt gefixt.

Syntax der Datei:
- leere Zeilen werden ignoriert
- Zeilen die mit # anfangen sind Kommentare (s.u. desc:)
- speziell werden Zeilen interpretiert die mit einem der folgenden Woerter beginnen: name: filter: prereq: par: desc: farewell: order:
- alle anderen Zeilen werden als auszufuehrende Befehle interpretiert, wenn man "set XX attrTemplate TemplateName" ausfuehrt.
- name: Name des Templates, markiert gleichzeitig das Ende des vorherigen Templates
- filter: devspec2array Ausdruck, der beschreibt, fuer welche Geraete dieses Template anwendbar ist. Wird erst beim "set ?" ausgefuehrt.
- prereq: ist entweder ein Perl-Ausdruck {}, oder ein devspec2array, was genau ein Geraet spezifiziert. Wird beim Einlesen des template Files ausgefuehrt. Falls nicht wahr ist, wird das Template entfernt. Ist fuer sowas wie "setze zusaetzlich Attribut XY falls die Installation HomeAssistant kennt" gedacht.
- par: kann mehrfach vorkommen, Syntax: par:<ParamaterName>:<Kommentar>:<Perl-Code>. Perl-Code versucht den Wert zu finden, falls nicht moeglich (return undef), wird ein Dialog mit "Replace" angezeigt (bzw. Usage:... im telnet). ParameterName wird in jeder Befehlzeile ersetzt mit dem Wert. Zusaetzlich: DEVICE wird mit dem Namen des Geraetes ersetzt.
- desc: Kommentar fuer "set attrTemplate help ?". Die letzte Zeile mit # vor name: wird als desc: interpretiert, falls kein desc: vorhanden ist.
- farewell: wird zum Schluss als Dialog (oder Text in telnet)  angezeigt, falls beim Anwenden der Befehle kein Fehler aufgetreten ist
- order: bestimmt die Reihenfolge der Templates fuers Frontend, falls nicht vorhanden, wird name: genommen.



krikan

Sorry, für verspätete Rückmeldung. Das template vom 30.11.19 aus #12 funktioniert nach meinem Test problemlos. Hier ist wohl noch ein kleiner Typo:
Zitatpar:DEVNAME;BASE_ID typically is rockrobo;
Statt BASE_ID sollte dort DEVNAME stehen.

homeassistant-autodiscovery schiebe ich erst mal. Sehe hier momentan keinen Vorteil. Ggfs. schaue ich mir es aber noch mal bei zwave2mqtt an, was noch auf dem Plan steht.

Ansonsten gehe ich erst mal von MQTT beim Sauger weg. Versuche mich jetzt mal mit der HTTP-REST-API des Saugers; HTTPMOD-template nicht ausgeschlossen.

Rudis Syntax-Erläuterung zu Template würde ich gerne irgendwo ins Wiki packen/verlinken. @Beta-User: hast Du eine bevorzugte Stelle oder sollen wir eine extra Wiki-Seite attrTemplate aufziehen?


krikan

Habe noch einmal probiert, da mir ungetestet bei zone und goto nicht gefiel.
In die setList müsste bitte für zone / goto folgendes:
  zone valetudo/rockrobo/custom_command {"command":"zoned_cleanup","zone_ids":["$EVTPART1"]}
  goto valetudo/rockrobo/custom_command {"command":"go_to","spot_id":["$EVTPART1"]}

zone habe ich erfolgreich getestet; goto eher unerfolgreich, da die spot_id nie akzeptiert wird (im Valetudo-Log: Invalid spot_id)

Beta-User

Thx auch für das Feedback zu dem template, den Typo mach ich noch raus.

Zu den beiden setList-Vorschlägen: die zone_ids sind nummerisch, oder? (=>widget für 0-10?)
Dto. für die spot_id?
Muß man die jeweils evtl. erst anlegen?



Was Wiki angeht:
Mit Rudis input scheint es mir angebracht zu sein, das in einen zentralen Artikel zu übernehmen, evtl. dazu noch ein paar Dinge, die heute in den Praxisbeispielen stehen, insbesondere (sinngemäß) https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate. Da würde ich das aber auch belassen. Dürfte sich jetzt so langsam sehr lohnen, nachdem auch für HMCCU.* ein template-file dazugekommen ist :) .

Wenn ich nichts gegenteiliges höre, mache ich das mit dem neuen Artikel "bei Gelegenheit".

Wenn du "HTTPMOD kannst", wäre ein template für den robi natürlich auch dort cool :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Zitat von: Beta-User am 04 November 2019, 11:12:39
Zu den beiden setList-Vorschlägen: die zone_ids sind nummerisch, oder? (=>widget für 0-10?)
Dto. für die spot_id?
Muß man die jeweils evtl. erst anlegen?
Zumindest die zone_ids sind auf jeden Fall alphanumerisch. Bei den spot_ids gehe ich auch davon aus; mangels Testerfolg aber nicht verifizierbar. Daher besser kein widget.
Ids=Namen muss man separat anlegen, was afaik aber blöderweise nicht mit MQTT geht.

In der aktuellen c't soll es einen Artikel zur Ansteuerung des Saugers per MQTT geben; evtl. könnte man daraus weitere Infos ziehen.

ZitatWas Wiki angeht:
[..] mache ich das mit dem neuen Artikel "bei Gelegenheit".
Aber gerne doch. Wenn Du dann Hilfe brauchst, bitte melden.

ZitatWenn du "HTTPMOD kannst", wäre ein template für den robi natürlich auch dort cool :) .
Können: Nein. Aber ich bin hoffentlich lernfähig. template liefere ich, wenn ich soweit bin. Kann also dauern.  :)

mark79

Danke erstmal allen für das Template.

Ich habe den Robi auch per MQTT2 angebunden, um zu schauen ob er damit schneller erreichbar ist, als mit dem anderen Modul.
Da ich den Robi immer ausschalte und es dann gute 3 Minuten dauert, bis er mit Fhem steuerbar ist.

Wegen dem goto, ich habe nachgeschaut, das wird anders geschrieben, ohne die [ ] und so funktioniert es bei mir:
goto valetudo/rockrobo/custom_command {"command":"go_to","spot_id":"$EVTPART1"}


Siehe auch hier (Example scripts.yaml snippet):
https://github.com/Hypfer/Valetudo/wiki/Home-Assistant-Integration#example-scriptsyaml-snippet-in-home-assistant-for-zoned-cleaning

VG
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

*grins*
Jetzt war ich wohl mal wieder zu schnell... Update mit den ohne eckig Klammer folgt, wenn ich die Rückmeldungen des Tages insgesamt habe (v.a. auch zu dem Tasmota-Shutter-Thema).

Einrichtung der Zonen usw. ist wohl hier beschrieben, einen MQTT-Weg scheint es nicht zu geben(?):
ZitatZones + Spots configuration, mqtt + other config /mnt/data/valetudo/config.json
Macht es Sinn, dazu noch was in comment/farewell mit aufzunehmen? MMn. "sollte man" bzgl. der Dinge auch noch zurechtkommen, wenn man es bis dahin geschafft hatte.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Zitat von: Beta-User am 04 November 2019, 12:59:30
*grins*
Jetzt war ich wohl mal wieder zu schnell...
Und ich zu schludrig.  :-[ 
Danke auch an @mark79 für die Berichtigung. Wenn ich mal vernünftig in den Code https://github.com/Hypfer/Valetudo/blob/master/lib/MqttClient.js geschaut hätte, ...
Sorry.

ZitatMacht es Sinn, dazu noch was in comment/farewell mit aufzunehmen? MMn. "sollte man" bzgl. der Dinge auch noch zurechtkommen, wenn man es bis dahin geschafft hatte.
Habe das über das Webinterface von Valetudo eingerichtet. Der andere Weg ist komplizierter, comment auch mMn überflüssig.




mark79

@krikan kein Ding, dafür ist das Forum da, das man sich gegenseitig hilft. :)

Was man noch aufnehmen könnte, wäre das neue Multifloor Feature, womit man die Map Karte speichern und wechseln kann, via load_map und store_map
Ich habe Valetudo 0.4.0-RE5.1 auf meinem V1 Sauger und damit funktionieren die MQTT2 SetList Befehle:


load_map valetudo/rockrobo/custom_command {"command":"load_map","name":"$EVTPART1"}
store_map valetudo/rockrobo/custom_command {"command":"store_map","name":"$EVTPART1"}


https://github.com/ppisljar/Valetudo/blob/multifloor/lib/MqttClient.js

Hier gibt es mehr Info: https://github.com/Hypfer/Valetudo/pull/317
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

 :) Kein Ding, und schon hätte es sowieso noch ein update gegeben ;D .

Unabhängig davon sehe ich das wie Mark79: Schön, dass wir das so pragmatisch teilen können, am Ende haben alle was davon (jedenfalls die, die es nutzen wollen oder einen "Steinbruch" für eigene Zwecke/neues benötigen)... Und wenn hier Fehler passieren, ist es nicht so dramatisch, im Zweifel ist es schnell repariert.




Einen ersten Wurf zum Wiki gibt es hier:
https://wiki.fhem.de/wiki/AttrTemplate

Noch nicht hübsch, noch nicht vollständig, noch nicht groß woanders verlinkt aber ein Anfang, feedback oder direkte Korrekturen/Ergänzungen: Gerne (aber wohl dann besser im Wiki-Bereich, da bekommen es auch die anderen "template-Ritter" mit :) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Zitat von: mark79 am 04 November 2019, 13:50:33
Ich habe Valetudo 0.4.0-RE5.1 auf meinem V1 Sauger
Ist das Fork https://github.com/rand256/valetudo , was ich aus Deiner Versionsangabe schließe, die ich bei https://github.com/Hypfer nicht finde ? Läuft das stabil?

Zitat von: Beta-User am 04 November 2019, 14:39:45
Einen ersten Wurf zum Wiki gibt es hier:
https://wiki.fhem.de/wiki/AttrTemplate
Danke!

robertPI

Hallo,

ich hänge gerade an dem attrTemplate für meinen Roborock S5. Valetudo ist drauf, läuft, mqtt ebenso.

/mnt/data/valetudo/config.json auf dem Roborock
"mqtt": {
    "enabled": true,
    "identifier": "rockrobo",
    "topicPrefix": "valetudo",
    "autoconfPrefix": "homeassistant",
    "broker_url": "mqtt://192.168.178.58:1883",
    "provideMapData": true,
    "caPath": ""
  },


Autocreate erstellt mir folgendes MQTT2_DEVICE
Internals:
   CFGFN     
   CID        mqttjs_f3ebb274
   DEF        mqttjs_f3ebb274
   DEVICETOPIC MQTT2_mqttjs_f3ebb274
   FUUID      5dd13432-f33f-d2fd-68f2-81d927df4d647a3f
   IODev      myMQTT
   NAME       MQTT2_mqttjs_f3ebb274
   NR         1260
   STATE      docked
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-11-17 12:51:14   cleanArea       125.8
     2019-11-17 12:51:14   cleanCount      10
     2019-11-17 12:51:14   cleanTime       2.7
     2019-11-17 12:51:14   filter          147.0
     2019-11-17 12:51:14   last_run_stats_area 3.7
     2019-11-17 12:51:14   last_run_stats_duration 205
     2019-11-17 12:51:14   last_run_stats_endTime 1573990481000
     2019-11-17 12:51:14   last_run_stats_errorCode 0
     2019-11-17 12:51:14   last_run_stats_errorDescription No error
     2019-11-17 12:51:14   last_run_stats_finishedFlag true
     2019-11-17 12:51:14   last_run_stats_startTime 1573990276000
     2019-11-17 12:51:14   mainBrush       297.0
     2019-11-17 12:51:14   sensor          27.3
     2019-11-17 12:51:14   sideBrush       197.0
     2019-11-17 12:51:14   state           docked
     2019-11-17 12:51:14   subscriptions   valetudo/rockrobo/command valetudo/rockrobo/custom_command valetudo/rockrobo/set_fan_speed
     2019-11-17 12:51:14   valetudo_state_id 8
     2019-11-17 12:51:14   valetudo_state_name Charging
Attributes:
   IODev      myMQTT
   readingList mqttjs_f3ebb274:valetudo/rockrobo/attributes:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE


set MQTT2_mqttjs_f3ebb274 attrTemplate roborock
fragt nach einem Parameter den ich nicht verstehe
"set MQTT2_mqttjs_f3ebb274 attrTemplate roborock BASE_ID"
Replace
BASE_ID: with the BASE_ID typically is home


ersetze ich hier entsprechen mit "home", läuft das attrTemplate nur teilweise durch und bringt folgende Meldung
defmod MQTT2_mqttjs_f3ebb274: Cannot change the TYPE of an existing definition
Please define DEVCID first


Das MQTT2_DEVICE sieht danach so aus
Internals:
   CFGFN     
   CID        mqttjs_f3ebb274
   DEF        mqttjs_f3ebb274
   DEVICETOPIC MQTT2_mqttjs_f3ebb274
   FUUID      5dd13432-f33f-d2fd-68f2-81d927df4d647a3f
   IODev      myMQTT
   LASTInputDev myMQTT
   MSGCNT     546
   NAME       MQTT2_mqttjs_f3ebb274
   NR         1260
   STATE      cleaning
   TYPE       MQTT2_DEVICE
   myMQTT_MSGCNT 546
   myMQTT_TIME 2019-11-17 13:12:31
   OLDREADINGS:
   READINGS:
     2019-11-17 13:11:22   battery_level   99
     2019-11-17 13:12:22   cleanArea       129.5
     2019-11-17 13:12:22   cleanCount      11
     2019-11-17 13:12:22   cleanTime       2.8
     2019-11-17 13:11:22   fan_speed       medium
     2019-11-17 13:12:22   filter          146.9
     2019-11-17 13:12:22   last_run_stats_area 3.7
     2019-11-17 13:12:22   last_run_stats_duration 213
     2019-11-17 13:12:22   last_run_stats_endTime 1573992255000
     2019-11-17 13:12:22   last_run_stats_errorCode 0
     2019-11-17 13:12:22   last_run_stats_errorDescription No error
     2019-11-17 13:12:22   last_run_stats_finishedFlag true
     2019-11-17 13:12:22   last_run_stats_startTime 1573992042000
     2019-11-17 13:12:22   mainBrush       296.9
     2019-11-17 13:12:31   map_data        {"header_length":20,"data_length":65152,"version":{...................
    2019-11-17 13:12:22   sensor          27.2
     2019-11-17 13:12:22   sideBrush       196.9
     2019-11-17 13:12:22   state           cleaning
     2019-11-17 13:12:22   valetudo_state_id 17
     2019-11-17 13:12:22   valetudo_state_name Zoned cleaning
Attributes:
   IODev      myMQTT
   icon       vacuum_top
   model      roborock
   readingList homeassistant/vacuum/valetudo_rockrobo/config:.* { json2nameValue($EVENT) }
  home/rockrobo/state:.* { json2nameValue($EVENT) }
  home/rockrobo/attributes:.* { json2nameValue($EVENT) }
  home/rockrobo/map_data:.* {valetudo2svg("map_data",$EVENT,"www/images/valetudo_map.svg")}
mqttjs_f3ebb274:valetudo/rockrobo/attributes:.* { json2nameValue($EVENT) }
mqttjs_f3ebb274:valetudo/rockrobo/state:.* { json2nameValue($EVENT) }
mqttjs_f3ebb274:valetudo/rockrobo/map_data:.* map_data
   room       MQTT2_DEVICE
   setList    start:noArg home/rockrobo/command start
  charge:noArg home/rockrobo/command return_to_base
  stop:noArg home/rockrobo/command stop
  spot:noArg home/rockrobo/command clean_spot
  pause:noArg home/rockrobo/command pause
  locate:noArg home/rockrobo/command locate
  fan_power:min,medium,high,max,mop home/rockrobo/set_fan_speed $EVTPART1
  zone home/rockrobo/custom_command {"command":"zoned_cleanup","zone_ids":["$EVTPART1"]}
  goto home/rockrobo/custom_command {"command":"go_to","spot_id":"$EVTPART1"}
  load_map home/rockrobo/custom_command {"command":"load_map","name":"$EVTPART1"}
  store_map home/rockrobo/custom_command {"command":"store_map","name":"$EVTPART1"}
   setStateList charge locate pause stop start



eine typische mqtt Nachricht lautet dabei (mosquitto_sub -v -h <IP vom broker> -t '#' )

valetudo/rockrobo/attributes {"cleanTime":"2.9","cleanArea":"133.2","cleanCount":12,"last_run_stats":{"startTime":1573992552000,"endTime":1573992791000,"duration":239,"area":"3.7","errorCode":0,"errorDescription":"No error","finishedFlag":true},"mainBrush":"296.9","sideBrush":"196.9","filter":"146.9","sensor":"27.1","state":"docked","valetudo_state":{"id":8,"name":"Charging"}}


Eine Ergänzung zu dem Template hätte ich auch noch: map-data spengt nicht nur die Zeichenzahl vom Editor im Forum, sondern bäst auch das automatisch angelegte filelog massiv auf. Ich habe das FileLog folgendermaßen eingegrenzt
./log/MQTT2_mqttjs_f3ebb274-%Y.log MQTT2_mqttjs_f3ebb274:(?!map_data)(.*)


Edit 17.11. 18:19
ich bin einen Schritt weiter, BASE_ID auf "valetudo" gesetzt und es funktioniert...

Edit 17.11. 19:13
nächste Frage / Problem: laut https://github.com/Hypfer/Valetudo/wiki/Home-Assistant-Integration
For multiple zones:

          params:
             'zone_ids': ["guest room","study room","bed room","living room"]

At the moment you can only send max 5 zones to clean, any more than that will be ignored.


Mit setList zone valetudo/rockrobo/custom_command {"command":"zoned_cleanup","zone_ids":["$EVTPART1"]}
wird allerdings nur der erste Parameter übergeben. Kann $EVENT durch eine Perl Funktion oder regex in den benötigten array umgewandelt werden?
FHEM auf Raspbery Pi 4
HM: HM-CFG-USB-2,HM-CC-RT-DN,HM-TC-IT-WM-W-EU,HM-SEC-SCo,HM-ES-PMSw1-Pl,HM-Sen-MDIR-WM55 | Philips hue: LCT001,LWL001,FLS-PP lp | Logitech Harmony Ultimate | zigbee2mqtt: WSDCGQ01LM, WSDCGQ11LM, MFKZQ01LM, MCCGQ11LM

Beta-User

Sorry, da scheint noch ein bug im template zu sein, die Zeile sollte wohl eher so aussehen:
par:BASE_ID;BASE_ID typically is valetudo;{ AttrVal("DEVICE","readingList","") =~ m,(valetudo)[/].*:, ? $1 : undef }
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

BM030

Hi,

ich nutze eine leicht veränderte Valetudo-Version https://github.com/rand256/valetudo und Kartenerstellung https://github.com/rand256/valetudo-mapper
was soweit auch super funktioniert.

ich wollte auch das Template nutzen und bekomme bei der Auswahl folgende Meldung angezeigt:
Download started, check the FHEM-log
Please define DEVCID first


Wo muss ich DEVCID anlegen und mit welchem Wert?

In den Attributen bekomme ich unter map_data:
map_data ERROR: Unknown format 2020-01-30 06:31:27

ändere ich die Zeile von:
valetudo/rockrobo/map_data:.* {attrTmqtt2_roborock_valetudo2svg("map_data",$EVENT,"www/images/valetudo_map.svg")}
auf
valetudo/rockrobo/map_data:.* map_data
sind Daten vorhanden und auch die Map wird vom valetudo-mapper erzeugt


Beta-User

Sorry, da wurde was an template umgestellt. Die map-Daten werden direkt umgeleitet und sollten als Grafik irgendwo zu finden sei. Um Devid muss ich mich kümmern, aber erst kommende Woche...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files