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

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

Vorheriges Thema - Nächstes Thema

krikan

Mit Hilfe von Valetuo (https://github.com/Hypfer/Valetudo) kann ein gerooter Xiaomi Vaccum per MQTT an FHEM angebunden werden. Einige Aspekte dazu wurden bereits im Thread https://forum.fhem.de/index.php/topic,104687.0.html kurz gestreift.

Einbindung per MQTT des Saugers bietet derzeit nicht so viele Funktionen wie mit Hilfe des speziellen Moduls https://fhem.de/commandref.html#XiaomiDevice, das sowohl für die Standard-Firmware als auch die gerootete, china-cloud-freie Variante genutzt werden kann.

In der folgenden Raw Defintion sind alle mir bekannten MQTT-Befehle integriert. Die Benennung der Befehle erfolgt analog zum XiaomiDevice-Modul. Getestet habe ich nur die Standardbefehle ohne Zonenbezug; d.h. zoned_cleandup und go_to sind ungetestet und vermutlich funktionslos.

Die in readingsList genannte Funktion "valetudo2svg()" findet sich in https://forum.fhem.de/index.php/topic,104687.msg986304.html#msg986304 ff. mit Hinweisen zur Einbindung und den Einschränkungen. Wer die Funktion erweitern möchte, so dass auch der Fahrweg, No-Go-Areas usw. angezeigt werden, darf gerne eine Ergänzung liefern.  :)

@Beta-User: Hoffe Du kannst mit den Angaben etwas für attrTemplate anfangen. Wenn Du einen Patch brauchst, dann kann ich den auch liefern. Jedoch dauert das dann noch etwas (länger).

Gruß, Christian

Raw Definition:
defmod MQTT2_mqttjs_5618b3f3 MQTT2_DEVICE mqttjs_5618b3f3
attr MQTT2_mqttjs_5618b3f3 IODev fhemMqtt
attr MQTT2_mqttjs_5618b3f3 icon vacuum_top
attr MQTT2_mqttjs_5618b3f3 readingList fhem/vacuum/valetudo_rockrobo/config:.* { json2nameValue($EVENT) }\
valetudo/rockrobo/state:.* { json2nameValue($EVENT) }\
valetudo/rockrobo/attributes:.* { json2nameValue($EVENT) }\
valetudo/rockrobo/map_data:.* {valetudo2svg("map_data",$EVENT,"www/images/valetudo_map.svg")}
attr MQTT2_mqttjs_5618b3f3 room MQTT2_DEVICE
attr MQTT2_mqttjs_5618b3f3 setList start:noArg valetudo/rockrobo/command start\
charge:noArg valetudo/rockrobo/command return_to_base\
stop:noArg valetudo/rockrobo/command stop\
spot:noArg valetudo/rockrobo/command clean_spot\
pause:noArg valetudo/rockrobo/command pause\
locate:noArg valetudo/rockrobo/command locate\
fan_power:min,medium,high,max,mop valetudo/rockrobo/set_fan_speed $EVTPART1\
zone valetudo/rockrobo/send_command zoned_cleanup\
goto valetudo/rockrobo/send_command go_to

setstate MQTT2_mqttjs_5618b3f3 docked
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:19:04 battery_level 100
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 cleanArea 540.8
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 cleanCount 22
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 cleanTime 9.2
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 command_topic valetudo/rockrobo/command
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:19:04 fan_speed medium
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 fan_speed_list_1 min
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 fan_speed_list_2 medium
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 fan_speed_list_3 high
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 fan_speed_list_4 max
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 fan_speed_list_5 mop
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 filter 140.8
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 json_attributes_topic valetudo/rockrobo/attributes
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 last_run_stats_area 0.2
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 last_run_stats_duration 14
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 last_run_stats_endTime 1572164292000
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 last_run_stats_errorCode 0
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 last_run_stats_errorDescription No error
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 last_run_stats_finishedFlag false
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 last_run_stats_startTime 1572164259000
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 mainBrush 290.8
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:19:05 map_data Wrote www/images/valetudo_map.svg
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 name rockrobo
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 schema state
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 send_command_topic valetudo/rockrobo/custom_command
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 sensor 20.8
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 set_fan_speed_topic valetudo/rockrobo/set_fan_speed
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 sideBrush 190.8
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 state docked
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 state_topic valetudo/rockrobo/state
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_1 start
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_10 send_command
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_2 pause
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_3 stop
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_4 return_home
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_5 battery
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_6 status
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_7 locate
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_8 clean_spot
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 03:12:57 supported_features_9 fan_speed
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 valetudo_state_id 8
setstate MQTT2_mqttjs_5618b3f3 2019-10-27 09:22:04 valetudo_state_name Charging


Beta-User

Paßt soweit, Vorschlag mdB. um Test unten (hab's selbst mangels grade verfügbarem Testsystem auch noch nicht getestet, müßte aber passen).

Dabei bin ich aber davon ausgegangen, dass
- der erste Eintrag in readingList eine Altlast war
- auch bei den letzten beiden setList-Einträgen weitere Argumente (aus der Texteingabe übergeben werden müßten
name:roborock
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*valetudo[/].*
desc:use this to control a rooted Xiamoni Vacuum / Roborock. For further details visit https://github.com/Hypfer/Valetudo<br><br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,104804.0.html<br>
order:X_03
par:BASE_ID;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)[/]valetudo[/].*:, ? $1 : undef }
par:DEVNAME;BASE_ID typically is home;{ AttrVal("DEVICE","readingList","") =~ m,valetudo[/]([^/]+)[/].*:, ? $1 : undef }
deletereading -q DEVICE (?!associatedWith).*
defmod DEVICE MQTT2_DEVICE DEVNAME
attr DEVICE icon vacuum_top
attr DEVICE readingList homeassistant/vacuum/valetudo_DEVNAME/config:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/state:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/attributes:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/map_data:.* {valetudo2svg("map_data",$EVENT,"www/images/valetudo_map.svg")}
attr DEVICE setList start:noArg BASE_ID/DEVNAME/command start\
  charge:noArg BASE_ID/DEVNAME/command return_to_base\
  stop:noArg BASE_ID/DEVNAME/command stop\
  spot:noArg BASE_ID/DEVNAME/command clean_spot\
  pause:noArg BASE_ID/DEVNAME/command pause\
  locate:noArg BASE_ID/DEVNAME/command locate\
  fan_power:min,medium,high,max,mop BASE_ID/DEVNAME/set_fan_speed $EVTPART1\
  zone BASE_ID/DEVNAME/send_command zoned_cleanup $EVTPART1\
  goto BASE_ID/DEVNAME/send_command go_to $EVTPART1
attr DEVCID comment For code "valetudo2svg()" see <a href="https://forum.fhem.de/index.php/topic,104687.msg986304.html#msg986304">this forum thread</a>.
farewell:template has been applied successfully. For map generation you'll need additional code to myUtils, see <a href="https://forum.fhem.de/index.php/topic,104687.msg986304.html#msg986304">this forum thread</a> for details.
attr DEVICE model roborock


EDIT template in readingList geändert, farewell ergänzt
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 27 Oktober 2019, 10:38:22
Dabei bin ich aber davon ausgegangen, dass - der erste Eintrag in readingList eine Altlast war
Nein, das ist keine Altlast. Besser wäre aber vermutlich der Eintrag
homeassistant/vacuum/valetudo_rockrobo/config:.* { json2nameValue($EVENT) }
Das "fhem" statt "homeassistant" am Beginn kommt nur daher, dass ich in config.json das autoconfPrefix von homeassistant auf fhem umgeändert habe. Wird vermutlich keiner machen und hat keine praktische Bedeutung.
Zitat
- auch bei den letzten beiden setList-Einträgen weitere Argumente
Ja. Dort werden weitere Argumente in einem bestimmten Format benötigt. Da ich das aber nicht verwende, bin ich zu faul das zu erforschen.  8)

Tests mache ich später.

Gruß, Christian


Beta-User

OK, den readingList-Eintrag habe ich im letzten Beitrag angepaßt, hoffe, das trifft es, sonst gibt's doch wieder jedes Mal neue Devices (?).

Was das Erforschen angeht: Dazu muß man die Option haben, was via MQTT zu versenden; vielleicht mag das ja jemand anderes austesten... ;)

Ansonsten bin ich unsicher, ob man die "command" Anweisungen nicht (teilweise) in eine Liste packen sollte (start, stop  und pause machen aber wohl schon als separate Kommandos Sinn).
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 27 Oktober 2019, 12:43:50
OK, den readingList-Eintrag habe ich im letzten Beitrag angepaßt, hoffe, das trifft es, sonst gibt's doch wieder jedes Mal neue Devices (?).
Ja, wenn es fehlt gibt es jedes Mal ein neues Device durch autocreate
Die damit abgedeckten/gefilterten MQTT-Nachrichten sind übrigens für MQTT-discovery, was auch bspw. Zigbee2mqtt nutzen soll (https://www.home-assistant.io/docs/mqtt/discovery/#support-by-third-party-tools). Habt ihr Euch mit MQTT-discovery schon mal beschäftigt?

ZitatAnsonsten bin ich unsicher, ob man die "command" Anweisungen nicht (teilweise) in eine Liste packen sollte (start, stop  und pause machen aber wohl schon als separate Kommandos Sinn).
Ich hatte nur versucht die Befehle möglichst "kompatibel" zum XiaomiDevice-Modul anzulegen. Ob das ins derzeitige FHEM/attrTemplate-Schema passt, habe ich nicht angeschaut. Ändern darfst Du das gerne.

Gruß, Christian

Beta-User

Hmm, das Kompabilitätsargument ist erst mal ein guter Einstieg, wenn es wer dann anders haben will, bitte melden... Einstweilen würde ich das dann noch mit
attr DEVICE setStateList charge locate pause stop start ergänzen (was wäre mit "zone" und "go_to"?).

Wenn die erste Version paßt, kann ich das gerne (mit der setStateList ergänzt) erst mal so ausliefern?

Das mit discovery hatte ich zwar bisher (als eher störend) aus den Augenwinkeln gesehen, aber  noch keine Meinung gebildet, ob uns das was hilft; tendenziell habe ich den Eindruck, dass autocreate zumindest auf der Empfangsseite dasselbe macht, ohne entsprechende Infos vorab zu benötigen.
Aber die Idee ist gut, das separat abzufangen, weil a) stören die zusätzlichen Meldungen eigentlich meistens nur (die scheinen zur einmaligen Info für die HA-Software gedacht zu sein, am Device braucht man die eigentlich gar nicht) und b) scheinen da auch die Command-Topics mitgeliefert zu werden. Man könnte daraus also gleich eine setList bauen... Wäre evtl. noch flexibler als (die Erkennung in) attrTemplate? Mal sehen, evtl. kann/will Rudi dazu was sagen?
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

rudolfkoenig

Danke fuer den Link, habs durchgelesen.
Die Nachricht ist homeassistant-spezifisch, d.h. wir muessten Reverse-Engneering betreiben, um es implementieren zu koennen.
Eine Funktion koennte aus der config Nachricht setList aufbauen, und diese Funktion koennte autocreate beim Erkennen eines bestimmten topics automatisch aufrufen.
Es waere schon mal praktisch, wenn wir die config-messages sammeln wuerden.

krikan

Zitat von: rudolfkoenig am 27 Oktober 2019, 17:59:21
Es waere schon mal praktisch, wenn wir die config-messages sammeln wuerden.
Ok:

Habe aus readingsList des bestehenden Devices, den Filter für die config-Messages gelöscht. Nach einem Neustart von Valetudo kommen folgende config-Messages:
2019.10.27 19:19:11.856 4: Connection accepted from fhemMqtt_192.168.188.46_44554
2019.10.27 19:19:11.910 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_09f6e992
2019.10.27 19:19:11.911 4:   fhemMqtt_192.168.188.46_44554 mqttjs_09f6e992 CONNECT V:4 keepAlive:60
2019.10.27 19:19:11.911 5: out: CONNACK:  (2)(0)(0)
2019.10.27 19:19:11.961 5: in:  SUBSCRIBE: (130)c(199)(233)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.27 19:19:11.962 4:   fhemMqtt_192.168.188.46_44554 mqttjs_09f6e992 SUBSCRIBE
2019.10.27 19:19:11.962 4:   topic:valetudo/rockrobo/command qos:0
2019.10.27 19:19:11.962 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.27 19:19:11.962 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.27 19:19:11.962 5: out: SUBACK: (144)(3)(199)(233)(3)
2019.10.27 19:19:11.980 5: in:  PUBLISH: 1(250)(3)(0)$fhem/vacuum/valetudo_rockrobo/config{"name":"rockrobo","schema":"state","supported_features":["start","pause","stop","return_home","battery","status","locate","clean_spot","fan_speed","send_command"],"command_topic":"valetudo/rockrobo/command","state_topic":"valetudo/rockrobo/state","set_fan_speed_topic":"valetudo/rockrobo/set_fan_speed","fan_speed_list":["min","medium","high","max","mop"],"send_command_topic":"valetudo/rockrobo/custom_command","json_attributes_topic":"valetudo/rockrobo/attributes"}
2019.10.27 19:19:11.980 4:   fhemMqtt_192.168.188.46_44554 mqttjs_09f6e992 PUBLISH fhem/vacuum/valetudo_rockrobo/config:{"name":"rockrobo","schema":"state","supported_features":["start","pause","stop","return_home","battery","status","locate","clean_spot","fan_speed","send_command"],"command_topic":"valetudo/rockrobo/command","state_topic":"valetudo/rockrobo/state","set_fan_speed_topic":"valetudo/rockrobo/set_fan_speed","fan_speed_list":["min","medium","high","max","mop"],"send_command_topic":"valetudo/rockrobo/custom_command","json_attributes_topic":"valetudo/rockrobo/attributes"}
2019.10.27 19:19:11.990 5: fhemMqtt: dispatch autocreate=simple\000mqttjs_09f6e992\000fhem/vacuum/valetudo_rockrobo/config\000{"name":"rockrobo","schema":"state","supported_features":["start","pause","stop","return_home","battery","status","locate","clean_spot","fan_speed","send_command"],"command_topic":"valetudo/rockrobo/command","state_topic":"valetudo/rockrobo/state","set_fan_speed_topic":"valetudo/rockrobo/set_fan_speed","fan_speed_list":["min","medium","high","max","mop"],"send_command_topic":"valetudo/rockrobo/custom_command","json_attributes_topic":"valetudo/rockrobo/attributes"}
2019.10.27 19:19:12.008 2: autocreate: define MQTT2_mqttjs_09f6e992 MQTT2_DEVICE mqttjs_09f6e992 fhemMqtt
2019.10.27 19:19:12.015 2: autocreate: define FileLog_MQTT2_mqttjs_09f6e992 FileLog ./log/MQTT2_mqttjs_09f6e992-%Y.log MQTT2_mqttjs_09f6e992


Dazu gehört folgendes neu durch autocreate angelegte Device:
Internals:
   CFGFN     
   CID        mqttjs_09f6e992
   DEF        mqttjs_09f6e992
   DEVICETOPIC MQTT2_mqttjs_09f6e992
   FUUID      5db5dfa0-f33f-a83c-df31-badd9e92e2b6cf0f
   IODev      fhemMqtt
   NAME       MQTT2_mqttjs_09f6e992
   NR         593
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-10-27 19:19:12   command_topic   valetudo/rockrobo/command
     2019-10-27 19:19:12   fan_speed_list_1 min
     2019-10-27 19:19:12   fan_speed_list_2 medium
     2019-10-27 19:19:12   fan_speed_list_3 high
     2019-10-27 19:19:12   fan_speed_list_4 max
     2019-10-27 19:19:12   fan_speed_list_5 mop
     2019-10-27 19:19:12   json_attributes_topic valetudo/rockrobo/attributes
     2019-10-27 19:19:12   name            rockrobo
     2019-10-27 19:19:12   schema          state
     2019-10-27 19:19:12   send_command_topic valetudo/rockrobo/custom_command
     2019-10-27 19:19:12   set_fan_speed_topic valetudo/rockrobo/set_fan_speed
     2019-10-27 19:19:12   state_topic     valetudo/rockrobo/state
     2019-10-27 19:19:12   supported_features_1 start
     2019-10-27 19:19:12   supported_features_10 send_command
     2019-10-27 19:19:12   supported_features_2 pause
     2019-10-27 19:19:12   supported_features_3 stop
     2019-10-27 19:19:12   supported_features_4 return_home
     2019-10-27 19:19:12   supported_features_5 battery
     2019-10-27 19:19:12   supported_features_6 status
     2019-10-27 19:19:12   supported_features_7 locate
     2019-10-27 19:19:12   supported_features_8 clean_spot
     2019-10-27 19:19:12   supported_features_9 fan_speed
Attributes:
   IODev      fhemMqtt
   readingList mqttjs_09f6e992:fhem/vacuum/valetudo_rockrobo/config:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE


Hoffe das Vorgehen genügt. Wenn ich das "alte" Device komplett löschen muss statt nur an readingsList Änderung vorzunehmen, dann kann ich das noch machen.

Beta-User

Zitat von: rudolfkoenig am 27 Oktober 2019, 17:59:21
Danke fuer den Link, habs durchgelesen.
Die Nachricht ist homeassistant-spezifisch, d.h. wir muessten Reverse-Engneering betreiben, um es implementieren zu koennen.
Eine Funktion koennte aus der config Nachricht setList aufbauen, und diese Funktion koennte autocreate beim Erkennen eines bestimmten topics automatisch aufrufen.
Es waere schon mal praktisch, wenn wir die config-messages sammeln wuerden.
Hmmm, ob man echtes "reverse-engineering" braucht: k.a.. Der code von Home-Assistant ist jedenfalls nicht geheim, von daher könnte man das auch von python nach Perl übersetzen (was aber vermutlich mehr Aufwand ist, als die Funktionsweise der discovery-Messages zu "erraten"), als Kern des Ganzen scheint das hier zu dienen: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/mqtt/discovery.py.

Was mir aber in dem Zusammenhang unklar ist: "Wirkt" das nur, wenn man den interen Broker verwendet (der ist deprecated, Quellcode ist hier!) oder auch mit externen Serverdiensten?
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

rudolfkoenig

Wenn ich es richtig verstehe, sendet tasmota/zigbee2mqtt/etc an eine speziell fuer HomeAssistant gedachte Topic eine Nachricht.
Diese bekommt jeder, der sich dafuer beim Broker angemeldet hat, z.Bsp. mit subscribe homeassistant/+/+/config

Mit reverse-engeneering meinte ich rauszufinden, wie man "supported_features":["start","pause","stop",...] in setList umsetzt, das wird mir aus den bisherigen Daten ueberhaupt nicht klar.

Beta-User

Hmm,

kann auch nur raten.
Der Topic-Pfad der discovery-message scheint auch eine Rolle zu spielen. Das war ja hier
fhem/vacuum/valetudo_rockrobo/config
fhem war der Ersatz für homeassistant (siehe Antwortvon krikan auf meine Frage dazu ganz am Anfang) => könnte der "Indikator" sein, dass das eine "spezielle" Message vorliegt.

"vacuum" könnte man als Geräteklasse übersetzen, das scheint mit den Dateien in https://github.com/home-assistant/home-assistant/tree/dev/homeassistant/components/mqtt/vacuum zusammenzuhängen, wo dann wieder drinsteht, was es alles als setter, Readings usw. gibt?

valetudo_rockrobo scheint aus den anderen beiden Angaben aus diesem Beitrag zusammengesetzt zu sein.
Wenn ich mir das so ansehe, erscheint es mir zwar logisch aufgebaut, aber wir müßten dann eine parallele Struktur aufbauen, die dieselben Elemente pflegt, sonst ist es nutzlos. Meine vorläufige Einschätzung daher: Braucht man diese dahinterliegende Datenstruktur auch nch, bringt es wegen des zusätzlichen Pflegeaufwands gg. den templates keinen wirklichen Mehrwert, jedenfalls, solange der user nicht hergeht und dann sehr viel an den topic-Trees dreht (was die Erkennungsrate der template-Codes verschlechtert). Letzteres tun aber nur totale Anfänger (immer weniger, habe ich den Eindruck), oder die, die sowieso wissen, was sie tun und an sich auch ohne autodiscovery-Mechanismus klarkämen.

Ergo sollte man dem geneigten Anwender daher empfehlen, das feature abzuschalten, FHEM-interner Ersatz ist attrTemplate. Meinstens scheint man den HASS-support aktivieren zu müssen, valetudo scheint der einzige Fall zu sein, in dem es by default bereits aktiviert ist.

@krikan: In diesem Beitrag war in dem .json als einziges, das mal als "Schalter" zur Aktivierung ansehen könnte die Angabe des "autoconfPrefix". Lust zu testen, was passiert, wenn das nicht da ist? Sonst war mMn. nichts enthalten, was man als Aktivierung des features interpretieren könnte. Oder hast sonst du irgendeinen "Schalter" gesehen, mit dem man das abstellen kann?

Ansonsten wäre (der Spur nach) die Frage, ob man diese Art messages auf eine (konfigurierbare) "blacklist" beim IO setzen sollte, damit es dort dann direkt verworfen wird?
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 27 Oktober 2019, 16:56:07
Wenn die erste Version paßt, kann ich das gerne (mit der setStateList ergänzt) erst mal so ausliefern?
Beschäftige mich gerade mit dem eingecheckten Template und auch erstmalig überhaupt mit attrTemplate.

Müsste
attr DEVCID comment For code "valetudo2svg()" see this forum thread.
nicht richtigerweise
attr DEVICE comment For code "valetudo2svg()" see this forum thread.
sein.

Fehlermeldung im Log habe ich aber überraschenderweise nicht und mir ist nicht bewusst an den defaults etwas geändert zu haben. Doch richtig!?

Und jetzt beginnen meine eigentlichen Verständnisprobleme zu attrTemplate:
Nach Anklicken von "set MQTT2_mqttjs_5618b3f3 attrTemplate roborock" öffnet sich eine Dialogbox mit dem Befehl "set MQTT2_mqttjs_5618b3f3 attrTemplate roborock BASE_ID" und dem Hinweis "Replace BASE_ID: with the BASE_ID typically is home". "home" führt aber zu so etwas "start:noArg home/rockrobo/command start" Ersetze ich BASE_ID durch "valetudo" ist es ok. Aber wofür gib es dann noch DEVNAME im template!? Wann wird das abgefragt?

Auf die anderen im Thread angesprochenen Einzelpunkte gehe ich erst mal nicht ein, um nicht noch mehr Vewirrung zu stiften.  8) Habe bisher mehr Fragen, als Antworten.

Beta-User

Ups, da war/ist noch einiges verbesserungsfähig gewesen ::) .

So läuft es auf meinem Testsystem mit deiner (auf homeassistant angepaßten) RAW durch:

name:roborock
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*valetudo[/].*
desc:use this to control a rooted Xiamoni Vacuum / Roborock. For further details visit https://github.com/Hypfer/Valetudo<br><br>NOTE: Initial version, not yet fully tested, just build according to https://forum.fhem.de/index.php/topic,104804.0.html<br>
order:X_03
par:BASE_ID;BASE_ID typically is valetudo;{ AttrVal("DEVICE","readingList","") =~ m,([^:]+)(valetudo)[/].*:, ? $2 : undef }
par:DEVNAME;BASE_ID typically is rockrobo;{ AttrVal("DEVICE","readingList","") =~ m,valetudo[/]([^/]+)[/].*:, ? $1 : undef }
deletereading -q DEVICE (?!associatedWith).*
defmod DEVICE MQTT2_\DEVICE DEVNAME
attr DEVICE icon vacuum_top
attr DEVICE readingList homeassistant/vacuum/BASE_ID_DEVNAME/config:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/state:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/attributes:.* { json2nameValue($EVENT) }\
  BASE_ID/DEVNAME/map_data:.* {valetudo2svg("map_data",$EVENT,"www/images/valetudo_map.svg")}
attr DEVICE setList start:noArg BASE_ID/DEVNAME/command start\
  charge:noArg BASE_ID/DEVNAME/command return_to_base\
  stop:noArg BASE_ID/DEVNAME/command stop\
  spot:noArg BASE_ID/DEVNAME/command clean_spot\
  pause:noArg BASE_ID/DEVNAME/command pause\
  locate:noArg BASE_ID/DEVNAME/command locate\
  fan_power:min,medium,high,max,mop BASE_ID/DEVNAME/set_fan_speed $EVTPART1\
  zone BASE_ID/DEVNAME/send_command zoned_cleanup $EVTPART1\
  goto BASE_ID/DEVNAME/send_command go_to $EVTPART1
attr DEVICE setStateList charge locate pause stop start
attr DEVICE comment For code "valetudo2svg()" see <a href="https://forum.fhem.de/index.php/topic,104687.msg986304.html#msg986304">this forum thread</a>.
farewell:template has been applied successfully. For map generation you'll need additional code to myUtils, see <a href="https://forum.fhem.de/index.php/topic,104687.msg986304.html#msg986304">this forum thread</a> for details.
attr DEVICE model roborock
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

Danke, probiere ich (später) aus.

Irritierend finde ich, dass Typos wie
attr DEVCID comment For code "valetudo2svg()" see this forum thread.
nicht zu irgendeiner Meldung (im Log) führen. Man muss schon sehr genau kontrollieren, um solche Probleme zu finden. Kann man nicht eine Meldung zumindest im Log bei verbose 3 aufnehmen?

Gibt es irgendwo (außer code) eine Doku zu attrTemplate?

Beta-User

Eigentlich sollte es schon einen log-Eintrag geben. Da sollte stehen, dass das Device DEVCID nicht exisitert.

Was die "Sprache" (Doku) angeht, gibt's afaik keine wirkliche Doku, aber das ganze ist eigentlich keine große Magie. Etwas untechnisch würde ich das so formulieren:
Es gibt eine Anzahl von "keywords" (die mit dem Dppelpunkt hinten dran), die entweder der Darstellung (filter, desc, order) in "?" dienen, "par" sorgt für die Auflösung von Variablen (was nicht via Perlcode ermittelt werden kann, wird beim Nutzer erfragt, optimalerweise also nichts...), und dann gibt es noch "farewell" und "prereq". farewell enthält die Rückmeldung an den user, wenn alles fehlerfrei durch ist, mit prereq lassen sich Teile ein- und ausschalten (kenne noch keinen Anwendungsfall, aber eingebaut wurde das u.a., damit die Leute, die sich mit Spracherkennung rumschlagen, da ggf. einfache Möglichkeiten haben, die für die jeweils implementierte Lösung passenden Attribute zu setzen).

Zuerst werden die par-Anweisungen ausgewertet und im restlichen Code dann die Variablen durch die ermittelten/erfragten Werte ersetzt.

Der Rest sind dann "Einzeiler", wobei der reinen Lehre nach eigentlich Attribute gesetzt werden, aber im Prinzip alles möglich ist, vom normalen FHEM-Kommando bis hin zur Ausführung von Perl-Code (ganz so, wie ein "execute" im RAW-Eingabefeld).
Vielleicht übernehme ich das in bereinigter Form mal in das "Praxisbeispiele"-Wiki, aber eigentlich ist es recht einfach, mit "copy/paste" aus den bestehenden templates zu arbeiten. (So ist auch der DEVCID-Fehler entstanden...). Wenn man weiß, was man erreichen will, findet man in der Regel v.a. im mqtt2.template-File ausreichend Bausteinchen. Du hattest jetzt nur das "Glück", mit einem speziellen Device und einer "experimentellen" Fassung zu arbeiten, aber meine Erfahrung mit den bsiherigen Zuarbeitern war die, dass die in der Regel recht schnell "den Dreh raus hatten"...
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