mqtt2.template: bugs, Fragen, Anregungen

[Beta-User]

  ...das ist zwar ein "bugs"-Thread, aber zu mqtt2-template .

Bitte die Frage gesondert stellen, für MQTT2_CLIENT bin ich nicht zuständig, und ich bin mir ziemlich sicher, dass Rudi gerne hätte, dass zum einen die aktuelle Version des Moduls getestet wird, lists angefügt und evtl. verbose 5 - logs...

[mahowi]

Danke für's melden. Wundert mich etwas, dass da bisher noch keiner drübergestolpert ist, die regexe sind an der Stelle schon "ewig" so .

Habe jetzt (hoffentlich) alle zigbee2mqtt-templates so umgestellt, dass die funktionieren, egal, ob man die CID noch in der readingList drin hat oder nicht. Ist seit eben im svn (=> kommt mit update morgen), wäre nett, wenn ihr meldet, wenn es doch nicht funktioniert.

Wahrscheinlich ändern die wenigsten das Template zwischendurch, daher fiel das nicht auf.

Jetzt konnte ich das Template bei der Bridge auf jeden Fall fehlerfrei ein zweites Mal anwenden.

[Beta-User]

Danke für die Rückmeldung. In der Tat dürfte es bei "Erstverabreichung" nie ein Problem gegeben haben.

Die Umstellung betraf übrigens alle zigbee2mqtt-templates, aber auch da sollte das jetzt völlig stressfrei "fluppen", wenn man das wiederholt anwendet (die Übung war nicht schlecht, ich habe wieder etwas regexen geübt...).

[HomeAlone]

Ich habe gerade meinen ersten Erfolg mit der Verwendung der mqtt2.templates errungen und nachdem ich fleißig die Templates meinen Sensoren zugeordnet habe ist mir Folgendes in der Darstellung aufgefallen:

Bei den Templates zigbee2mqtt_TempHumSensor und zigbee2mqtt_TempHumHpaSensor werden Temperatur und Luftfeuchtigkeit unterschiedliche dargestellt: Einmal mit den Abkürzungen T und H und einmal mit Temperature und Humidity.

Ich fände es übersichtlicher, wenn hier eine einheitliche Benennung bei denselben Dingen verwendet würde. Persönlich gefällt mir die Langform besser, da intuitiver.

Ich vermute, folgende Zeile in der Templatebeschreibung von zigbee2mqtt_TempHumSensor wäre abzuändern von

Code Auswählen Erweitern

attr DEVICE stateFormat T: temperature H: humidity
in

Code Auswählen Erweitern

attr DEVICE stateFormat {sprintf ("Temperature: %.1f°C Humidity: %.1f%% ", ReadingsVal($name,"temperature",0), ReadingsVal($name,"humidity",0)) }
?


Des weiteren verwende ich das zigbee2mqtt_light_cct Template, welches ein Icon (light_control) verwendet. Das finde ich auch sehr hilfreich bei der Übersicht.
Macht es nicht auch Sinn, so etwas bei den anderen Sensoren (wenn sinnvolle Icons vorhanden sind) zu ergänzen?

Z.B. bei besagten Temperatur/Luftfeuchte Sensoren:

Code Auswählen Erweitern

attr DEVICE icon temperature_humidity
?

Viele Grüße
Sascha

[HomeAlone]

Ich habe einen Sensor, für den noch kein Template existiert: Den Xiaomi DJT11LM Vibration Sensor.

Der Sensor heißt zwar offiziell Vibration Sensor, ich finde aber, dass es eher ein Alarm-Sensor oder Gyroscope-Sensor ist: Er kann Fall, Drehung/Neigung sowie Klopfen registrieren.

Folgende Readings besitzt der via autocreate erzeugte Sensor:

Code Auswählen Erweitern


setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:41 nn_Vibrationskontakt_action drop
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle 83
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_x 2
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_x_absolute 88
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_y 1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_y_absolute 89
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_angle_z 88
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_battery 100
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_dateCode 20180130
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_friendlyName nn_Vibrationskontakt
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_hwVersion 3
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_ieeeAddr 0x00158d0002a4ee26
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_manufId 4151
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_manufName LUMI
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_modelId lumi.vibration.aq1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_nwkAddr 47946
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_powerSource Battery
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_status online
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_swBuildId 3000-0001
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_device_type EndDevice
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_linkquality 126
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:42 nn_Vibrationskontakt_voltage 3005

Leider habe ich das Format in /opt/fhem/FHEM/lib/AttrTemplate noch nicht ganz verstanden - vor allem die ganzen par Zeilen mit den RegExps. Das, was ich vermeintlich verstanden habe würde ich so zusammenfassen:

Code Auswählen Erweitern

name:zigbee2mqtt_AlarmSensor
desc: Alarm  sensor via zigbee2mqtt <br>Can report actions drop, tilt or vibration as well as x,y,z coordinates of its movement.<br>Sensitivity can be set to low, medium or high.<br>Tested with: Xiaomi DJT11LM Vibration Sensor
filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
order:L_15
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
attr DEVICE stateFormat Action: action X: angle_X Y: angle_Y Z: angle_Z
attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model zigbee2mqtt_AlarmSensor


Action kann drei Zustände annehmen: tilt, drop, vibration. Muss das hier noch irgendwie verarbeitet werden?
Auch wenn ich bei Temperature und Humidity die Langform schöner fand: Bei Koordinaten dürfen es gerne knackige Werte X, Y und Z sein.

Zudem kann der Sensor auch einen Wert entgegen nehmen: Sensitivity mit den Werten low, medium, high. Siehe hierzu
https://github.com/Koenkk/zigbee-shepherd-converters/pull/74

Wie würde man das in dem mqtt2.template realisieren? Irgendwie über

Code Auswählen Erweitern

attr DEVICE setStateList low medium high
?

Schon mal vielen Dank für Eure Mithilfe.

Viele Grüße
Sascha

[Beta-User]

Moin, sieht doch schon mal ganz gut aus.

Habe den eben mal eingecheckt, und eine setList hinzugefügt für die Empfindlichkeit, und auch das stateFormat von dem temp/hum angepaßt. Muß zwar nicht zwingend alles einheitlich sein, aber hier schadet es auch nicht... Allerdings sind die Readings, die da via setstate angezeigt werden, etwas komisch, (und ich sehe jetzt erst die Kleinschreibung). Hast du autocreate am IO auf "complex"?

(setStateList ist für "was anderes", aber das könnte man ggf. ach noch ergänzen, wenn es jemand stören sollte, wo das Setzen der Empfindlichkeit jetzt landet.)
Was Icons angeht, habe ich den Code jetzt insgesamt so umgestellt, dass bereits (vom User) gesetzte Icons erhalten bleiben, wenn jemand Vorschläge für die bisher fehlenden macht, pflege ich das auch noch ein, kein Thema...

@HomeAlone: Wenn du da jeweils ein komplettes RAW lieferst, kann ich manches etwas besser nachstellen (hier ist es hoffentlich "gegessen", ggf. muß noch Kleinschreibung genommen werden).

[HomeAlone]

Allerdings sind die Readings, die da via setstate angezeigt werden, etwas komisch, (und ich sehe jetzt erst die Kleinschreibung). Hast du autocreate am IO auf "complex"?

Ja, habe autocreate auf komplex stehen. Mein IO Device ist ein MQTT2_CLIENT, welcher wiederum auf einen mosquitto in einem Docker-Container verweist. Was heißt genau komisch? Habe keine Ahnung von der Materie, aber ich finde sie aussagekräftig 

(setStateList ist für "was anderes", aber das könnte man ggf. ach noch ergänzen, wenn es jemand stören sollte, wo das Setzen der Empfindlichkeit jetzt landet.)
Was Icons angeht, habe ich den Code jetzt insgesamt so umgestellt, dass bereits (vom User) gesetzte Icons erhalten bleiben, wenn jemand Vorschläge für die bisher fehlenden macht, pflege ich das auch noch ein, kein Thema...

Ich kann gerne mal draufgucken, welche Icons passen würden und Vorschläge machen.

@HomeAlone: Wenn du da jeweils ein komplettes RAW lieferst, kann ich manches etwas besser nachstellen (hier ist es hoffentlich "gegessen", ggf. muß noch Kleinschreibung genommen werden).

Meinst Du das RAW aus der Definition des FHEM-Sensors, oder ein anderes RAW? Hier das komplette RAW vom Sensor:

Code Auswählen Erweitern

setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 21:27:33 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-14 22:23:56 nn_Vibrationskontakt_action tilt
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle 83
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_x 84
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_x_absolute 6
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_y 1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_y_absolute 89
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_angle_z 6
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_battery 100
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_dateCode 20180130
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_friendlyName nn_Vibrationskontakt
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_hwVersion 3
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_ieeeAddr 0x00158d0002a4ee26
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_manufId 4151
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_manufName LUMI
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_modelId lumi.vibration.aq1
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_nwkAddr 47946
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_powerSource Battery
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_status online
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_swBuildId 3000-0001
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_device_type EndDevice
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_linkquality 136
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-15 23:11:23 nn_Vibrationskontakt_voltage 3005

Ich teste das von Dir eingecheckte Template morgen aus (da wird es vermutlich im Update sein) und berichte.

Mir ist übrigens noch aufgefallen, dass im RAW am Ende der Zeile mit dem _device_dateCode ein roter Punkt erscheint. Wenn ich alle setstates markiere und kopiere, landen nur die Werte bis zum _device_dateCode 20180130 in der Zwischenablage... siehe Anhang. Könnte das in Verbindung mit "komisch" stehen?

Viele Grüße
Sascha

[Beta-User]

"komisch" meint im wesentlichen: unnötig lang (eben wg. complex). "complex" ist was feines, wenn man es braucht. Aber ich kenne nur ganz wenige Fälle, in denen man es benötigt, der wichtigste sind gleich aufgebaute JSON auf unterschiedliche Topics beim EBUS, die sich dann auch auf eine andere Baugruppe am Bus beziehen.
In der Regel genügt aber "simple", um "aussagefähige" Readingnamen zu erhalten, ganz unabhängig von der Art des IO.

Mit komplettem RAW ist übrigens auch das "defmod" gemeint, so sehe ich nur die setstates .
Ich mache das in der Regel so, dass ich den Curser in das Textfeld plaziere und dann mit Strg+a alles markiere und mit Strg+Einf kopiere (Mausaktionen sind in Browserfenstern immer gefühlter Mist...).

[pwlr]

Moin,
diese Templates sind sicher ne super Sache und erleichtern die Definition in der Entwicklungsphase erheblich. Keine Frage.

Aber wenn alles läuft oder man die Templates nicht braucht (so wie ich mit meinen Device-Eigenentwicklungen), würde ich die gern aus der SetList weg haben
set <device> attrTemplate
Meine Anregung wäre, das mit einem neuen attr individuell steuern zu können. Als Default könnte man die Liste gern aktivieren. Analog zum attr disable.

Was haltet ihr davon?
Moin
Bernd

[Beta-User]

Moin. Mich hat das bisher nicht ernsthaft gestört, hätte aber auch nichts dagegen, das ausblendbar zu machen. M.E. ist das hier aber die falsche Adresse, das gehört allgemein zu attrTemplate (also zu "Automatisierung" lt. Maintainer.txt) und hätte wohl auch Auswirkungen auf weitere Module, die das (potentiell) nutzen (im Hintergrund ist es eine "Extension" zu SetExtensions).

Rudi liest hier zwar vermutlich mit, aber ob er die Frage hier wahrnimmt, kann ich nicht sagen .

[rudolfkoenig]

Will gerade nicht raten: aus welchem Grund will man attrTemplate nicht in der Liste haben?

[pwlr]

weil ich mir Devices mit dem ESP8266-12F selbst baue / programmiere. Da passen die Templates von den Industrieprodukten sicher nicht.
Ich finde auch, dass eine manuelle Definition (eigener Devices) kein Hexenwerk ist und fhem mit der großen Bandbreite der User-Anforerungen möglichst individuell sein sollte.

Wäre (aus meiner Sicht) wirklich gut, weil in der Weboberfläche eines Device dann nur noch die für den Betrieb relevante Dinge auftauchen würden. Fehlfunktionen durch falsche Bedienung eines Nutzers könnten vermieden werden.

[rudolfkoenig]

Wäre (aus meiner Sicht) wirklich gut, weil in der Weboberfläche eines Device dann nur noch die für den Betrieb relevante Dinge auftauchen würden. Fehlfunktionen durch falsche Bedienung eines Nutzers könnten vermieden werden.

Wenn man diese Begruendung ernst nimmt, dann muesste jedes einzelne Befehl bei jedem FHEM-Geraet optional unterbunden werden koennen, und das je nach Zugang konfigurabel. Das konsistent und effizient umzusetzen ist aufwendig (bzw. ich habe keine dazu passende geniale Idee), und der Bedarf bisher ist auch nicht ueberwaeltigend.

[pwlr]

Ich unterscheide immer bei den Bedürfnissen zwischen Entwicklern und Nutzern. Der Nutzer will eigentlich nur (beispielsweise) ein Device ein- oder ausschalten und hat sonst keine Ahnung von fhem. Ich denke da so an meine Familienmitglieder...

Es ist richtig, dass auch bei den anderen Devices jede Menge Befehle angezeigt werden.

Ich dachte an eine Vorgehensweise analog wie bei TYPE dummy und dem attr setList. Z.B.:

attr setList default -> alle Systembefehle werden angezeigt
attr setList default Hugo Emma Erna -> zusätzlich eigene Befehle
attr setlist Hugo Emma Erna -> nur eigene Befehle

Vielleicht geht es ja, ich bin bestimmt kein Fachmann für fhem-Internals. Wollte es nur mal anregen.

Bernd

[Beta-User]

Ähm, darf ich darum bitten, diese OT-Diskussion an anderer Stelle weiterzuführen?

(Es sei hier nur noch angemerkt, dass es zur Beschränkung der Optionen "normaler Nutzer" andere Mechanismen (mir bekannt jedenfalls im Zusammenspiel mit in FHEMWEB, siehe allowedCommands und die forbiddenroom bzw. hidden.*-Attribute) gibt, um das für diese Nutzer gedachte UI "unfallverhütungsgerecht" zu gestalten...)