mqtt2.template: bugs, Fragen, Anregungen

[Beta-User]

Man _kann_ schon alles modular aufbauen mit der Technik... Ist aber ein ziemlicher Auswand, und man müßte wissen, wo man hinwill usw....

Würde z.B. dazu neigen, das "shelly-announce"-Gerät dazu zu nutzen, das generelle Verhalten der attrTemplate im shelly-Zweig zu beeinflussen, und z.B. im Standard einiges wegzulassen (die Ampel, die announce-Abos, z.B.). Das was man nach meiner persönlichen Meinung besser zentral erledigt eben...

ABER: Das umzubauen, ist ein ziemlicher Aufwand, wer mag, kann für den shelly-Teil gerne patches liefern - ein Anfang wäre der Versuch, das für den shelly 2.5 mal zu modularisieren, Beispiele für die "Mitnutzung" des 1. Kanals findet man zwischenzeitlich auch in einer "bedingten sprachsteuerungs-Variante" schon bei Tasmota .

Ich selbst werde mich bei Gelegenheit erst mal um die Tasmota-Ecke kümmern, da gibt es eine ganze Ladung ähnlicher Fragen (siehe separaten Thread dazu...). Ist aber nicht von so hoher Prio, das funktioniert ja alles erst mal soweit.

[87insane]

PS: Es sollte natürlich ReadingsVal anstatt ReadingsNum heißen... Sorry!

Mein Vorschlag, nach Durchsicht der Speech Geschichte bleibt bei "shelly_total_energy_fix".
Die Optionen gefallen mir. So kann man in der Theorie ein Gerät von A bis Z einrichten. Man könnte fragen, "soll das eine Waschmaschine werden"?, welchen Schwellwert hat diese?, soll es ein Gesamt Energie Reading geben?, welches devStateIcon willst du... usw... Echt genial!

Code Auswählen Erweitern

name:?????????????
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
order:A_10b
desc:Applies to single relay Shelly devices offering energy meassuring like Shelly 1PM or Shelly Plug S
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
par:RADIO_SETUSERREADING;Set userreading for total energy consumption;{ undef }
par:RADIO_DONOTSETUSERREADING;Do not set userreading for total energy consumption;{ undef }
par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old =  AttrVal("DEVICE","userReadings",undef);; !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsVal("$name","relay_0_energy",0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old.', relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsVal("$name","relay_0_energy",0)}'  }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* relay_0_energy\
  shellies/DEVNAME/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $total = ReadingsVal($name,"relay_0_kWh","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons / Total: $total/ Temp: $temp °C</div>"}
attr DEVICE comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr DEVICE webCmd :
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
set DEVICE attrTemplate speechcontrol_type_switch
attr DEVICE model shelly1_w_energy_meassuring
option:{ RADIO_SETUSERREADING }
attr DEVICE userReadings NEWUSERREADINGS

[Beta-User]

ReadingsNum ist m.E. an der Stelle total ok! Why not?!?

Und warum einen anderen Namen nehmen? Das mit dem Umbenennen des templates war nur für's Testen erforderlich, meine Frage bezog sich auf den Namen des Readings - der sollte wohl was mit dem Kanal zu tun haben, aber so lang braucht er nicht zu sein, oder?

Das mit dem "°C" habe ich zwar gesehen, aber den Verdacht, dass das irgendwie spezifisch ist für das jeweilige Zielsystem - da sollte wohl eher ein sauber codiertes "html"-Zeichen stehen, oder? (Hat jemand einen Tipp?).

[87insane]

Hi,

ReadingsNum ist m.E. an der Stelle total ok! Why not?!?

Ja... Geht natürlich aber macht es einen Unterschied?

Und warum einen anderen Namen nehmen? Das mit dem Umbenennen des templates war nur für's Testen erforderlich, meine Frage bezog sich auf den Namen des Readings - der sollte wohl was mit dem Kanal zu tun haben, aber so lang braucht er nicht zu sein, oder?

Finde das Reading sollte klar zu erkennen sein und direkt ersichtlich sein woher/warum. Weswegen in meinen Augen der Ursprung erhalten bleiben sollte und dahinter dann eben etwas wie _total, _fix,..... Ist zwar "lang" aber besser zu erkennen für jeden.

Das mit dem "°C" habe ich zwar gesehen, aber den Verdacht, dass das irgendwie spezifisch ist für das jeweilige Zielsystem - da sollte wohl eher ein sauber codiertes "html"-Zeichen stehen, oder? (Hat jemand einen Tipp?).

Gibt es ja nicht nur in "meinen" Templates. Ist auch in anderen Templates enthalten. Finde es nicht schlimm, das es so muss. Habe es auch nur so hinbekommen "damals".

[OppiM]

Hi,

Ich hab gerade mal versucht, einen Sonoff T1 2ch mit dem Template "tasmota_2channel_split" einzurichten.

Das ursprüngliche Gerät funktioniert danach als CH1 wie erwartet. Das zweite läßt sich zwar schalten, zeigt aber nicht den Status an. Grund ist, dass die readingList nicht richtig gesetzt wird:

Code Auswählen Erweitern

attr MQTT2_SonoffT1_CH2 readingList STATTOPIC/POWER2:.* state

Diese Zeile scheint im Template "tasmota_2channel_split" zu fehlen:

Code Auswählen Erweitern

par:STATTOPIC;ack topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}stat$3" : undef }


Das gleiche gilt für "tasmota_4channel_split".

Gruß,
Michael

[Beta-User]

Danke für die Info, update ist im svn.

[Feuerpfeil]

Hallo zusammen,

auch auf die Gefahr hin, dass es jetzt für mich peinlich werden könnte :

Ich verusche das zigbee2mqtt_ContactSensor Template anzuwenden und bekomme die Fehlermeldung :
"Empty parameters are not allowed"

Versuche ich dann das Template erneut anzuwenden, erscheint ein Dialogfeld :

Specify the unknown parameters for zigbee2mqtt_ContactSensor:
base topic set in configuration.yaml of the zigbee2mqtt bridge   
name of the device in the zigbee2mqtt bridge

Des Weiteren kann ich auch nicht, mittels dropdown, das device auf open/close setzen
set MQTT2_zigbee_DEVICE open

gibt :
Unknown argument false, choose one of attrTemplate


Ich habe allerdings auch keine Homebridge oder sonstigen Sprachassistenten installiert.

Mache ich hier etwas falsch ?

Viele Grüße,
Lars

[Beta-User]

Ohne ein list (oder besser zwei: vorher/nachher) sage ich dazu nichts...
Hat aber vermutlich nichts mit den Sprachsteuerungsgeschichten zu tun, da scheint einfach keine readingList da zu sein, die augelöst würde, daher mußt du beide Angaben in dem Dialogfeld selbst eingeben.

[Feuerpfeil]

Die Readings sind jedenfalls vorhanden :

Code Auswählen Erweitern


Readings
associatedWith     MQTT2_zigbee_pi   2020-03-30 11:37:19
battery      100      2020-03-30 12:27:25
contact      true     2020-03-30 12:27:25
linkquality     60     2020-03-30 12:27:25
voltage     3105     2020-03-30 12:27:25


und

Code Auswählen Erweitern


readingList   zigbee2mqtt/0x00158d00045cfc54:.* { json2nameValue($EVENT) }


nach Anwenden des Templates

Code Auswählen Erweitern


readingList   $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
devicetopic   zigbee2mqtt/0x00158d00045cfc54


[Beta-User]

ok. Damit ist der 2. Durchlauf erklärt (muß ich mir noch was dazu überlegen). Nach dem ersten
sollte im Attribut "devicetopic" auch "zigbee2mqtt/0x00158d00045cfc54" stehen.
Um das "Empty parameters are not allowed" muß ich mich gesondert kümmern, das scheint tatsächlich ein Problem zu sein, weiß aber noch nicht so recht woher...

Was das mit dem "set" angeht: Verstehe ich nicht. Das ist doch ein reiner Sensor, oder etwa nicht? Daher sollte es auch keine setList geben, wenn du - aus welchen Gründen auch immer - einen Anlaß siehst da einzugreifen, mußt du "setreading" verwenden. Aber richtigerweise sollte man m.E. versuchen, das auf der Seite von zigbee2mqtt zu adressieren. Das müßte für aktuelle Daten sorgen, nicht FHEM oder du...

[Beta-User]

Gefunden, und auch gleich noch ein paar weitere "Kleinigkeiten" gefunden (ein volles RAW-listing wäre trotzdem besser gewesen, so mußte ich zum Testen erst mal basteln...):

Code Auswählen Erweitern

name:zigbee2mqtt_ContactSensor
desc: Contact sensor via zigbee2mqtt <br>Tested with: Xiaomi models Aqara and Mijia
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_06
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/]+).+, ? $1 : undef }
attr DEVICE devStateIcon open:fts_window_1w_open@red close:fts_window_1w@green
#attr DEVICE genericDeviceType contact
attr DEVICE eventMap true:close false:open
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap contact:state
deletereading -q DEVICE (?!associatedWith).*
set DEVICE attrTemplate speechcontrol_gdt_and_mapping GENERICDEVTYPE=contact HOMEBRIDGEMAPPING="ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED"
attr DEVICE model zigbee2mqtt_ContactSensor

Damit sollte es laufen, und zwar auch das 2. Mal, und damit sollte es auch in der dropdown-Liste angezeigt werden.

(Wird etwas dauern, bis ich alle betroffenen Templates durch habe, und das gesammelt im update landet, aber bei den anderen taucht der Anlaß für deine völlig berechtigte Frage nicht auf...).

[Feuerpfeil]

ganz herzlichen Dank, für Deine Rückmeldung !

Genau...bei den Templates für zigbee2mqtt_Human_Motion_Sensor so wie zigbee2mqtt_plug, hatte ich die "Probleme" nicht. Daher war ich ein wenig verwundert.
Sorry, dass ich kein RAW-listing geliefert habe. Ich mache einfach zu selten etwas an fhem, sodass mir schnell und gerne, grundlegende Dinge verloren gehen. :-/

Wegen der setList : Da stimme ich Dir zu. Der Status eines Sensors muss, normalerweise, nicht manuell geändert werden.
Die setList wurde automatisch angelegt und da ich gerade ein notify getestet habe, habe ich versucht mittels dem Set aus der setList, den Zustand des Sensors zu setzen.

[Beta-User]

Na ja, der Unterschied zu dem plug ist der, dass der Contact etwas mehr an mapping-Infos braucht, und genau da war der Hund begraben, was aber sehr schwer auffällt, da sich dort (und nur bei dem einen template...) schlicht zwischen dem Parameter= und dem Wert ein Leerzeichen reingemogelt hatte...

Aber so war es ein Anlaß, mal wieder etwas intensiver damit zu spielen und gleich noch was anderes zu verbessern .

(Aber es wäre mir echt neu, dass autocreate bei MQTT2_DEVICE gleich noch eine setList anlegt, vermutlich reden wir da aneinander vorbei...).

[Beta-User]

So, update ist im svn, wäre nett, wenn jemand vorab testen könnte, ob alles soweit i.O. ist - neben dem "Contact" sind noch ein paar Nettigkeiten gefixt:
- Die FILTER waren insgesamt irgendwie "kaputt";
- bei den zigbee-Geräten klappt jetzt auch (wieder) das wiederholte Anwenden (das automatische Auflösen der Parameter war im Zuge der "devicetopic"-Umstellung vorübergehend "kaputt" gegangen).

[slowfinger]

Hallo
mir ist noch im Template

tasmota_2ch_shutter_invert_1 und auch beim tasmota_2ch_shutter_invert_0

aufgefallen, dass die setlist beim Befehl HALF nicht den Rolo auf 50% fährt, sondern die "Kalibrierung hier ist 50%" auslöst. Besser & richtiger (?) wäre

Code Auswählen Erweitern


close:noArg cmnd/Rolladen_KleinerBalkon/ShutterClose1
   open:noArg cmnd/Rolladen_KleinerBalkon/ShutterOpen1
   half:noArg cmnd/Rolladen_KleinerBalkon/ShutterPosition1 50
   pct:slider,0,1,100 cmnd/Rolladen_KleinerBalkon/ShutterPosition1 $EVTPART1
   stop:noArg cmnd/Rolladen_KleinerBalkon/ShutterStop1
   resetClose:noArg cmnd/Rolladen_KleinerBalkon/ShutterSetClose1
   x_configuration cmnd/Rolladen_KleinerBalkon/$EVTPART1 $EVTPART2