mqtt2.template: bugs, Fragen, Anregungen

[HomeAlone]

Ich hätte schwören können, dass ich gestern alles inkl. defmod kopiert hatte... na ja, aller guten Dinge sind drei.

Code Auswählen Erweitern

defmod MQTT2_zigbee_nn_Vibrationskontakt MQTT2_DEVICE zigbee_nn_Vibrationskontakt
attr MQTT2_zigbee_nn_Vibrationskontakt IODev mosquittoATnucgulp
attr MQTT2_zigbee_nn_Vibrationskontakt alias MQTT2_zigbee_nn_Vibrationskontakt
attr MQTT2_zigbee_nn_Vibrationskontakt model zigbee2mqtt_AlarmSensor
attr MQTT2_zigbee_nn_Vibrationskontakt readingList zigbee2mqtt/nn_Vibrationskontakt:.* { json2nameValue($EVENT) }\
zigbee2mqtt/nn_Vibrationskontakt/set:.* { json2nameValue($EVENT, 'set_', $JSONMAP) }
attr MQTT2_zigbee_nn_Vibrationskontakt room MQTT2_DEVICE
attr MQTT2_zigbee_nn_Vibrationskontakt setList sensitivity:low,medium,high zigbee2mqtt/nn_Vibrationskontakt/set {"sensitivity":"$EVTPART1"}
attr MQTT2_zigbee_nn_Vibrationskontakt stateFormat Action: action X: angle_X Y: angle_Y Z: angle_Z

setstate MQTT2_zigbee_nn_Vibrationskontakt Action: vibration X: angle_X Y: angle_Y Z: angle_Z
setstate MQTT2_zigbee_nn_Vibrationskontakt 2019-10-16 12:44:08 action vibration
... (der Rest wie bereits gepostet)

Übrigens schneidet er auch mit CTRL+C und CTRL+V ab dem roten Punkt ab.   

Leider klappt es noch nicht: Im Raum MQTT2_DEVICE werden z.B. bei den TempHum Sensoren die Daten in der Übersicht schön aktualisiert - beim Alarm-Sensor aber nicht. Und kurz nachgedacht, habe ich glaube ich, den Fehler gefunden:
Anstelle von:

Code Auswählen Erweitern

attr DEVICE stateFormat Action: action X: angle_X Y: angle_Y Z: angle_Z

muss da

Code Auswählen Erweitern

attr DEVICE stateFormat Action: action X: angle_x Y: angle_y Z: angle_z

stehen (also X, Y, Z -> x, y, z).  mea culpa.

Das set funktioniert leider auch nicht: Das meldet der Sensor (aus dem MQTT-Protokoll)

Code Auswählen Erweitern


{
  "type" : "zigbee_publish_error",
  "message" : "Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.",
  "meta" : {
    "entity" : {
      "ID" : "0x00158d0002a4ee26",
      "type" : "device",
      "friendlyName" : "nn_Vibrationskontakt"
    },
    "message" : "{\"sensitivity\":\"medium\"}"
  }
}

Jetzt könnte man meinen, er findet die Bridge nicht, aber wenn ich ihn drehe, runterfallen lasse etc. melden mir sowohl mosquitto als auch die Webpage für den Sensor fleißig, dass die Daten korrekt ankommen.
Ich habe auch darauf geachtet, vor dem Absenden des set Befehls auf den Button des Sensors zu drücken, damit er aktiv ist, wenn das set command kommt.

Hier der log output vom Mosquitto:

Code Auswählen Erweitern

10/16/2019, 11:17:46 AM - info: Zigbee publish to device 'nn_Vibrationskontakt', genBasic - write - [{"attrId":65293,"dataType":32,"attrData":21}] - {"manufSpec":1,"disDefaultRsp":1,"manufCode":4447} - 1
10/16/2019, 11:17:47 AM - error: Zigbee publish to device 'nn_Vibrationskontakt', genBasic - write - [{"attrId":65293,"dataType":32,"attrData":21}] - {"manufSpec":1,"disDefaultRsp":1,"manufCode":4447} - null failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.
10/16/2019, 11:17:47 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.","meta":{"entity":{"ID":"0x00158d0002a4ee26","type":"device","friendlyName":"nn_Vibrationskontakt"},"message":"{\"sensitivity\":\"low\"}"}}'


Hier der Beweis, dass der Sensor im Netzwerk ist:

Code Auswählen Erweitern

10/16/2019, 11:20:19 AM - info: MQTT publish: topic 'zigbee2mqtt/nn_Vibrationskontakt', payload '{"linkquality":2,"angle_x":2,"angle_y":1,"angle_z":88,"angle_x_absolute":88,"angle_y_absolute":89,"angle":16,"battery":97,"voltage":2995,"action":"vibration","device":{"ieeeAddr":"0x00158d0002a4ee26","friendlyName":"nn_Vibrationskontakt","type":"EndDevice","nwkAddr":47946,"manufId":4151,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.vibration.aq1","hwVersion":3,"swBuildId":"3000-0001","dateCode":"20180130\u0000","status":"online"}}'


Werde das heute Abend noch mal mit dem Sensor direkt neben dem Coordinator testen, aber eigentlich kann das nicht das Problem sein...

Bis dahin habe ich es auch mit den klein geschriebenen Koordinaten getestet - muss jetzt aber fix weg und wollte schon mal das Gefundene rückmelden.

Viele Grüße
Sascha

[Beta-User]

  Das mit der Kleinschreibung hatte ich ja schon angemerkt (aber leider nicht rechtzeitig vor dem Einchecken gesehen).

Was das Setzen des Werts angeht, bin ich etwas ratlos, wo die rückgemeldeten escape-Anweisungen ("\") für die Anführungszeichen herkommen bzw. ob das die Ursache für eventuelle Probleme ist. Kannst du mal mosquitto_pub bemühen und das darüber testen, ob die Reaktion dann dieselbe ist? (Wenn ja, ist nicht FHEM die Ursache und der setList-Eintrag paßt so bzw. muß so bleiben. Der Fehler wäre dann bei zigbee2mqtt zu melden bzw. da im github mal nachzusehen, ob das dort schon bekannt ist). Andernfalls mal ohne die Anführungszeichen versuchen?
Jedenfalls bei allen anderen settern (für zigbee2mqtt) hat das bisher nach diesem Muster (in der Regel auch mit Anführungszeichen) probemlos funktioniert...

[HomeAlone]

OK, mit kleinen Buchstaben für x, y und z klappt die Anzeige. Check!

Bzgl. des Setzens der Sensitivity: Da machst Du alles richtig, hab es gerade überprüft: mosquitto_pub, MQTT.fx und MQTT Explorer schicken die Nachricht genauso raus. Und es gibt jedesmal dieselbe Fehlermeldung.

Ich google gerade noch mal bei zigbee2mqtt nach der Fehlermeldung, ob ich irgendwas finde und frage ansonsten mal dort nach.
Habe gerade etwas gefunden, was darauf hinweist, dass es manchmal zu Instabilitäten mit Routern kommen kann. Abhilfe: Router ablernen neu anlernen, aber das kann ich erst morgen machen, da der im Schlafzimmer meiner kleinen auf dem Schrank ist.

Melde mich, wenn ich was neues weiß. Prizipiell kann man das Template für den Sensor so freigeben. Soll ich es noch im Contributing Thread veröffentlichen, wenn das Update morgen raus ist?

[Beta-User]

Moin, zur Info: die Korrektur habe ich grade (mit) ins svn geschoben, eine weitere Info des Maintainers bzw. die Bitte an ihn, das zu veröffentlichen (über den anderen Thread) ist daher nicht erforderlich  .

Mit reingekommen ist auch ein template für mehrere DS18x20 an Tasmota, siehe hier. Kann sein, dass da noch Optimierungsbedarf besteht...

Ansonsten bin ich mal gespannt, was die Ursache dafür ist/war, warum das auf der zigbee2mqtt-Seite nicht wollte, aber das ist hier eigentlich dann auch OT...

[HomeAlone]

Ich habe jetzt noch einmal ganz von vorne angefangen: Alle MQTT2-Devices, Clients etc gelöscht und Stück für Stück mit dem Aufbau begonnen.
Anbei meine Beobachtungen - und die daraus resultiernden Anregungen

Ich habe, wie im Wiki für den MQTT-Client beschrieben, mit dem Teil für Tasmota, Shelly und ESPEasy angefangen. Zunächst einmal stelle ich mir die Frage, warum diese drei "MQTT-Dialekte" in einer Bridge zusammengefasst werden, obwohl sie anscheinend unterschiedlich aufgebaute MQTT-Messages haben? Sollte ich mich hier irren, dann gerne Kontra geben.
Ansonsten wäre es mMn intuitiver die auto-created Bridge-Devices entsprechend zu trennen: Also nicht nur
MQTT2_GeneralBridge
sondern
MQTT2_BridgeTasmota
MQTT2_BridgeShelly
MQTT2_BridgeESPEasy
MQTT2_BridgeZigbee2MQTT
...
welche wiederum jeweils mit autocreate 0 beglückt werden, damit die Befüllung erst erfüllt, wenn diese "Sub"-Bridges korrekt konfiguriert, bzw. benötigt werden.  Ich weiß nicht, ob man das mit dem autocreate Befehl eine Ebene höher nicht schön lösen könnte? Dann wäre das natürlich noch besser. Also bei der Auswahl des Attributs autocreate eine Liste mit Checkboxen für die gewünschten "Sub"-Bridges. Ich weiß aber nicht, ob das programmatisch (sinnvoll) machbar ist.

Was mir als nächstes aufgefallen ist: Wenn die MQTT2_GeneralBridge mit dem attrTemplate für MQTT2_CLIENT_general_bridge belegt wird, wird das Attribut bridgeRegexp automatisch mit den korrekten MQTT-Strings (hoffe der Begriff ist richtig) befüllt.

Das führt bei mir dazu, dass erst mal keine Geräte automatisch angelegt werden, da ich abweichend vom Standard als prefix noch ein tasmota/ verwende. Also die bridgeRegexp entsprechend angepasst und schwupps, werden die devices erzeugt. Hier zur Verdeutlichung meine MQTT2_GeneralBridge:

Code Auswählen Erweitern

defmod MQTT2_GeneralBridge MQTT2_DEVICE MQTT2_GeneralBridge
attr MQTT2_GeneralBridge IODev mosquittoATnucgulp
attr MQTT2_GeneralBridge alias MQTT2_GeneralBridge
attr MQTT2_GeneralBridge autocreate 1
attr MQTT2_GeneralBridge bridgeRegexp (tasmota/tele|tasmota/cmnd)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"
attr MQTT2_GeneralBridge comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr MQTT2_GeneralBridge model MQTT2_CLIENT_general_bridge
attr MQTT2_GeneralBridge room MQTT2_DEVICE
attr MQTT2_GeneralBridge setStateList on off

Jetzt haben wir an dieser Stelle mMn bereits alles, was wir benötigen, um - zumindest Tasmota-Sensoren - korrekt anzusprechen. Shelly und ESPEasy kann ich gerade nicht überprüfen.

Als nächstes einem automatisch erzeugten Tasmota Geräte die zugehörige attrTemplate zuordnen. Hier eine Sonoff S20 Steckdose nach dem autocreate (und vor der Zuweisung eines attrTemplates):

Code Auswählen Erweitern

defmod MQTT2_SonoffS20004 MQTT2_DEVICE SonoffS20004
attr MQTT2_SonoffS20004 IODev mosquittoATnucgulp
attr MQTT2_SonoffS20004 alias MQTT2_SonoffS20004
attr MQTT2_SonoffS20004 readingList tasmota/tele/SonoffS20004/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_SonoffS20004 room MQTT2_DEVICE


Wähle ich nun das zugehörige attrTemplate (tasmota_basic_state_power_1) aus, öffnet sich ein Dialog:

Code Auswählen Erweitern


Input field:
set MQTT2_SonoffS20004 attrTemplate tasmota_basic_state_power1 CMNDTOPIC TELETOPIC STATTOPIC
Text:
Replace
CMNDTOPIC: with the Command topic prefix, without trailing /
TELETOPIC: with the info topic prefix, without trailing /
STATTOPIC: with the ack topic prefix, without trailing /


Ist dieser Dialog nötig (ich rede wie gesagt vom Tasmota-Device)?: In der readingLIst ist die korrekte Syntax drin, in der bridgeRegex des Bridge-Devices ebenso und zwar in allen möglichen Varianten.
Wenn ich mich hier irren sollte (was übrigens auch bei allem weiter oben Geschriebenem sein kann  ), könnte man das nicht dahingehend vereinfachen, dass man nicht alle drei Topics zusammensetzen muss? Der Aufbau für cmnd, tele und stat ist ja immer identisch und kann, soweit ich weiß, nicht unterschiedlich aufgebaut sein.
Also alternativ etwas wie:

Code Auswählen Erweitern


Please enter the syntax to issue commands to your Tasmota device. Use %COMMAND% as placeholder for the tasmota command, %SENSOR% as placeholder for the sensor.
e.g.: %COMMAND%/%SENSOR% will result in
TELETOPIC = tele/MQTT2_SonoffS20004/...
STATTOPIC = stat/MQTT2_SonoffS20004/...
CMNDTOPIC = cmnd/MQTT2_SonoffS20004/...

Anschließend wird die Definition wie gehabt zusammengebaut.

Und noch einen Schritt weitergehend: Wenn man die jeweiligen "Sub"-Bridges wie oben angeregt definieren könnte, könnte diese Syntax sogar dort einmal hinterlegt werden und die einzelnen Sensoren müssten dann nicht jedesmal den Dialog anzeigen sondern könnten diese einfach nur von einer Ebene höher anwenden.

Ich weiß natürlich nicht, mit welchen Aufwänden das verbunden ist! Aber ich denke, das Das ist mir eben aufgefallen, als ich das jetzt zum ersten Mal richtig durchexerziert habe - zugegebenermaßen jetzt "NUR" für Tasmota Devices.

Unabhängig davon: Ich finde es super, welcher Aufwand bereits betrieben wurde, um die Anbindung der Sensoren möglichst einfach zu gestalten. Daher bitte nicht als Kritik sondern als Anregung verstehen.

Viele Grüße
Sascha

[HomeAlone]

Ich hatte in einem früheren Posting gesagt, ich könne mir die verfügbaren Icons einmal anschauen und für die verschiedenen Sensortypen Vorschläge machen. Das habe ich jetzt gemacht und auch bei mir angewandt. Hier ein erster Wurf:

Code Auswählen Erweitern

Funktion -> icon
==========================
contact -> audio_pause
climate -> temperature_humidity
alarm -> secur_alarm
dimmer -> light_control
smoke detector -> secur_smoke_detector
motion sensor -> people_sensor
switch -> control_home | taster
double switch -> control_on_off | taster_ch
plug -> message_socket
plug with energy -> black_Steckdose.on
Sonoff S20 -> hue_filled_outlet
mqtt_bridge -> mqtt
button -> rc_rec
not defined/default -> mqtt_device


Wer könnte eigentlich neue Icons erstellen und hinzufügen und wo frage ich das an? Bin mir nicht ganz sicher, in welchen Thread das gehört.
Z.B. könnte man den Contact Sensor, welcher mMn sehr häufig vorkommt aus dem Pause Icon einfach erzeugen. Ein mqtt Bridge Icon sollte für den Autor des mqtt und mqtt_device icons auch einfach erstellbar sein.

[Beta-User]

Danke vorab mal für die Icon-Vorschläge. Als patch wäre es zwar einfacher gewesen, aber es geht auch so...

Übernommen habe ich v.a. die farblosen Vorschläge.
Bei den farbigen (und beim Einfärben) ist immer das Problem, dass das auch zum Farbschema passen sollte - bisher war ich da auch eher vorsichtig, aber mittlerweile bleiben ja vom User voreingestellte Icons erhalten . Und da, wo es nichts spezifisches gibt, ist es mMn. besser, nichts zu tun, wen's stört, der kann ja nacharbeiten...
Hoffe, das ist jetzt weitgehend vollständig.

Für neue Icons gibt es einen Thread, da kann man (unter Beachtung eventueller urheberrechtlicher Fragen) Vorschläge machen bzw. einreichen, was man selbst erstellt hat.


Was die bridge-Fragen angeht, scheint es mir so zu sein, dass ein wesentlicher Teil der geschilderten Probleme mit zwei oder drei Dingen zusammenhängen:
1. Es wird "CLIENT" verwendet. Das macht es generell etwas schwieriger;
2. Du nutzt eine "spezielle" Konfiguration; bei den "Praxisbeispielen" steht ganz vorne, dass man es am einfachsten hat, wenn man die "defaults" der Geräte belässt bzw. nur dort ändert, wo es das Wiki erwähnt. Du hast was spezielles gemacht, damit bist du - überspitzt formuliert - "Fortgeschritten" und nicht mehr die engere Zielgruppe des Wiki-Artikels (und der attrTemplates@MQTT2_DEVICE );
3. letztlich scheint es mir aber so zu sein, dass du das "Pech" hattest, dass in den readingList-Attributen (noch) kein LWT-Element drin war, denn eigentlich hätte auch mit deinem Topic-Pfad die "Aufdröselung" klappen sollen (und dann kein Dialogfeld mehr kommen).

Vielleicht checkst du an einem Beispiel, ob das der Fall war bzw. das anders ist, wenn die LWT-Info da ist?

Vom Grundsatz her ist es so gedacht, dass man eigentlich nur autocreate am IO ein- und ausschalten müssen sollte, (fast) alles andere sollte (mit nur einem General-Bridge-Gerät) automatisch passieren, ohne dass man irgendwelche Zweige ausdrücklich zu- oder abschaltet... Nur wer "spezielle" Hardware hat (wie zigbee2mqtt oder eBus), muß dann den jeweils ersten weiteren Schritt dann wieder anschubsen, aber für alle anderen, "einfacheren" Geräte/Zweige, wo es auch keine "Bridge-Hardware" gibt (wie den zigbee2mqtt-Dienst samt Dongle oder den eBus-Daemon), ist eigentlich mMn. auch kein separates Zwischengerät erforderlich. Eher würde man weitere bridgeRegex-Zeilen (z.B. für andere verbreitete ESP-firmwares) hinzufügen.

Würde mich interessieren, was du nach dem "LWT-Test" dazu denkst?

[HomeAlone]

Danke vorab mal für die Icon-Vorschläge. Als patch wäre es zwar einfacher gewesen, aber es geht auch so...

Übernommen habe ich v.a. die farblosen Vorschläge.
Bei den farbigen (und beim Einfärben) ist immer das Problem, dass das auch zum Farbschema passen sollte - bisher war ich da auch eher vorsichtig, aber mittlerweile bleiben ja vom User voreingestellte Icons erhalten . Und da, wo es nichts spezifisches gibt, ist es mMn. besser, nichts zu tun, wen's stört, der kann ja nacharbeiten...
Hoffe, das ist jetzt weitgehend vollständig.

Ja, ich bin absolut bei Dir, nur die "Standard-Icons" zu verwenden. Beim Gosund Zwischenstecker bot sich das aber an, weil der Ring ja - theoretisch - je nach Verbrauch unterschiedliche Farben anzeigen können sollte - auch noch eine Baustelle bei mir. 

Bei den Icons, wo es nichts gibt, würde ich dennoch vorschlagen, das Icon für mqtt_device zu verwenden: Andernfalls hat man unschöne Sprünge bei der Deviceauflistung: Einige Devices mit und einige ohne macht das schnelle Suchen in der Liste schwerer. Ich habe z.B. aktuell 28 Devices eingebunden und finde die Variante mit einheitlicher Listdarstellung übersichtlicher. Siehe angehängter screeny.

Für neue Icons gibt es einen Thread, da kann man (unter Beachtung eventueller urheberrechtlicher Fragen) Vorschläge machen bzw. einreichen, was man selbst erstellt hat.

Ich würde so etwas unter Frontends vermuten, finde da und in den jeweiligen Unterthemen aber nichts passendes. Werde es ansonsten einfach direkt in Frontends mal anfragen.

Was die bridge-Fragen angeht, scheint es mir so zu sein, dass ein wesentlicher Teil der geschilderten Probleme mit zwei oder drei Dingen zusammenhängen:
1. Es wird "CLIENT" verwendet. Das macht es generell etwas schwieriger;
2. Du nutzt eine "spezielle" Konfiguration; bei den "Praxisbeispielen" steht ganz vorne, dass man es am einfachsten hat, wenn man die "defaults" der Geräte belässt bzw. nur dort ändert, wo es das Wiki erwähnt. Du hast was spezielles gemacht, damit bist du - überspitzt formuliert - "Fortgeschritten" und nicht mehr die engere Zielgruppe des Wiki-Artikels (und der attrTemplates@MQTT2_DEVICE );
3. letztlich scheint es mir aber so zu sein, dass du das "Pech" hattest, dass in den readingList-Attributen (noch) kein LWT-Element drin war, denn eigentlich hätte auch mit deinem Topic-Pfad die "Aufdröselung" klappen sollen (und dann kein Dialogfeld mehr kommen).

Vielleicht checkst du an einem Beispiel, ob das der Fall war bzw. das anders ist, wenn die LWT-Info da ist?

Ich als "Fortgeschrittener" hab jetzt erst mal eine halbe Stunde versucht herauszufinden, was LWT sein soll... 
Last-Will retain ist hoffentlich die Antwort.

Habe hierzu noch mal eine Sonoff S20 Steckdose hinzugefügt. Und siehe da: Die hat ein Reading LWT mit dem Wert Online. Zudem weiß er von einem Module Sonoff S2X und weiteren im Webfrontend der Steckdose eingestellten Dingen, was vermutlich der Grund dafür ist, dass es klappt:
Wenn ich bei diesem Sensor die Dropdown Liste bei attrTemplate auswähle, sehe ich (so bilde ich mir zumindest ein) auch viel mehr Auswahlmöglichkeiten. Zudem erscheinen die ganzen Zigbee2MQTT Optionen nicht mehr dort (außer zigbee2mqtt_bridge).
Wähle ich nach der Auswahl des korrekten Templates set an, erscheint der Dialog, von dem ich oben weit und breit erzählt habe nicht mehr. Top! Demzufolge ist es jetzt wirklich intuitiv gelöst.

Hast Du eine Idee, warum vorher das LWT Online nicht in den Readings erschien? Muss man der Bridge erst mal ein wenig Zeit geben, MQTT-Messages zu empfangen, eh man an die Konfiguration der Sensoren geht? 

Vom Grundsatz her ist es so gedacht, dass man eigentlich nur autocreate am IO ein- und ausschalten müssen sollte, (fast) alles andere sollte (mit nur einem General-Bridge-Gerät) automatisch passieren, ohne dass man irgendwelche Zweige ausdrücklich zu- oder abschaltet... Nur wer "spezielle" Hardware hat (wie zigbee2mqtt oder eBus), muß dann den jeweils ersten weiteren Schritt dann wieder anschubsen, aber für alle anderen, "einfacheren" Geräte/Zweige, wo es auch keine "Bridge-Hardware" gibt (wie den zigbee2mqtt-Dienst samt Dongle oder den eBus-Daemon), ist eigentlich mMn. auch kein separates Zwischengerät erforderlich. Eher würde man weitere bridgeRegex-Zeilen (z.B. für andere verbreitete ESP-firmwares) hinzufügen.

OK, kann ich nachvollziehen. Das mit dem AutoCreate und den diversen so automatisch erzeugten "Hilfs-Devices" muss ich auch noch mal nachvollziehen - aber da gucke ich erst noch mal und würde explizit noch mal nachfragen, wenn dann etwas unklar geblieben ist.

Würde mich interessieren, was du nach dem "LWT-Test" dazu denkst?

Nachdem das Reading LWT da ist, finde ich das Handling um Welten einfacher. Jetzt muss ich nur noch genau verstehen, wie das Meshing bei Zigbee2MQTT funktioniert, aber das ist ein ganz anderes Thema... 

Danke noch mal für die große Hilfe!

Viele Grüße
Sascha

[Beta-User]

Was die Teile mit Strommeßfunktion angeht: Da hatten wir neulich eine Diskussion bzgl. shelly, evtl. kannst du dich da bedienen und mal einen Vorschlag machen (oder zwei)?

Was fehlende Icons angeht, bin ich eher auf dem Tripp: lieber keines als ein "falsches". "mqtt" sagt zwar was über die Art der Datenübermittlung aus, aber das ist keine Aussage, die ich "vergrafikenswert" finde. Lieber soll sich der User damit auseinandersetzen, dass er was tun muß, wenn er es "hübsch" haben will. Aber wenn da mehr dafür sind, soll's an mir nicht hängen .
Den Icon-Thread hast du jetzt ja gefunden...

Dass da keine LWT-Info bei vielen deiner Geräte vorhanden war, hing vermutlich damit zusammen, dass FHEM die Infos von mosquitto schon mal abgerufen hatte; wäre wohl anders gewesen, wenn entweder die Geräte mal neu gestartet gewesen worden wären oder die Verbindung von FHEM zu mosquitto neu aufgebaut worden wäre (FHEM-restart oder evtl. auch set active/disable... oä). Evtl. könnte da im Wiki noch was ergänzt werden (?).
Dass und wie da gefiltert wird, hast du ja jetzt live gesehen, und es scheint auch für dich Sinn zu machen, wie das funktioniert bzw. was man wann zu sehen bekommt. Von daher ist es m.E. ok, wenn der user, dem was "fehlt", erst mal darauf verwiesen wird, dass er dafür sorgen sollte, dass FHEM die Daten (nochmal) erhält (bei Tasmota: die LWT-messages). Dann funktioniert auch der Rest (hoffentlich) reibungslos .
(Ich vergesse das nur hin und wieder auch, dass mache Ding ehat gewisse Vorbedingungen benötigen bzw. welche das im Detail sind).

[HomeAlone]

Was die Teile mit Strommeßfunktion angeht: Da hatten wir neulich eine Diskussion bzgl. shelly, evtl. kannst du dich da bedienen und mal einen Vorschlag machen (oder zwei)?

Gerne, gerade schlage ich mich aber noch mit der Topologie meines Zigbee2MQTT Netzes rum. 😅

Dass da keine LWT-Info bei vielen deiner Geräte vorhanden war, hing vermutlich damit zusammen, dass FHEM die Infos von mosquitto schon mal abgerufen hatte; wäre wohl anders gewesen, wenn entweder die Geräte mal neu gestartet gewesen worden wären oder die Verbindung von FHEM zu mosquitto neu aufgebaut worden wäre (FHEM-restart oder evtl. auch set active/disable... oä). Evtl. könnte da im Wiki noch was ergänzt werden (?).

Beachte ich auch gerne. Wenn ich mein Netz neu aufbaue (komme da erst Mitte nächster Woche zu)  gebe ich hierzu noch mal Feedback, was eventuell klarer dargestellt werden kann oder wo mir etwas fehlt.
Viele Grüße
Sascha

[Otto123]

Hi,

mein Ziel wäre gewesen: Ich liefere einen Patch... (ich will keine Kritik üben, ich will nur meinen Eindruck aufschreiben)
Ich scheitere:
- ich müsste wissen wie man ein Patch erstellt, da bin ich aber am lesen. Das allein scheint nicht so schwer
- ich müsste wissen wie das mit dem attrTemplate erstellen wirklich geht. Ist mir auf die Schnelle zu undurchsichtig. Hier stehen ein paar Fragmente, für mich ist es zu wenig und gleichzeitig zuviel. Wenn man sich durch den "dritten" Link gearbeitet hat qualmt der Kopf
Da ich jetzt erstmal ein paar Wochen weg von FHEM sein werde, will ich aber noch mein Ergebnis der letzten Tage teilen:

Ich habe mir die Themen attrTemplate MQTT(2) und HTTPMOD (ich weiß Beta-User Du suchst Mitstreiter-ich bin noch weit davon entfernt ) am Shelly PlugS angeschaut.
Basis war ein aktuelles FHEM, MQTT2_SERVER, die API
Ich habe mit wirklich viel Recherche und Tests diese Minimalvariante gebaut. Die hat keinen Schnickschnack (wie Icon usw) und kann aus meiner Sicht alles was die mqtt API Shelly derzeit hergibt.

Code Auswählen Erweitern

defmod shellyplug_s_2 MQTT2_DEVICE
attr shellyplug_s_2 IODev mqtt2s
attr shellyplug_s_2 readingList shellies/shellyplug-s-040E41/online:.* online\
shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-040E41...mac.*, ? json2nameValue($EVENT) : undef }\
shellies/shellyplug-s-040E41/relay/0/power:.* power\
shellies/shellyplug-s-040E41/relay/0:.* state\
shellies/shellyplug-s-040E41/temperature:.* temperature\
shellies/shellyplug-s-040E41/temperature_f:.* temperature_f\
shellies/shellyplug-s-040E41/overtemperature:.* overtemperature\
shellies/shellyplug-s-040E41/relay/0/energy:.* energy
attr shellyplug_s_2 room MQTT2_DEVICE
attr shellyplug_s_2 setList request_announces:noArg {"shellies/shellyplug-s-040E41/command announce"}\
reading_update:noArg {"shellies/shellyplug-s-040E41/command update"}\
do_fw_update:noArg {"shellies/shellyplug-s-040E41/command update_fw"}\
off:noArg {"shellies/shellyplug-s-040E41/relay/0/command off"}\
on:noArg {"shellies/shellyplug-s-040E41/relay/0/command on"}

Was mich daran stört: Es sind ein Haufen Befehle (on-for-timer usw.) in der List die so nicht vorhanden und auch nicht einfach umsetzbar sind. (ginge mit HTTPMOD)
Kann man die automatische Befehlsliste auch unterdrücken / eindämmen?

Zum Vergleich, das Ergebnis was allein mit autocreate aus dieser Nachricht

Code Auswählen Erweitern

shellies/shellyplug-s-040E41/relay/0/power 0.00
shellies/shellyplug-s-040E41/relay/0 off
shellies/shellyplug-s-040E41/temperature 29.81
shellies/shellyplug-s-040E41/temperature_f 85.65
shellies/shellyplug-s-040E41/overtemperature 0
entsteht:

Code Auswählen Erweitern

defmod MQTT2_shellyplug_s_040E41 MQTT2_DEVICE shellyplug_s_040E41
attr MQTT2_shellyplug_s_040E41 IODev mqtt2s
attr MQTT2_shellyplug_s_040E41 readingList shellyplug_s_040E41:shellies/shellyplug-s-040E41/relay/0/power:.* relay_0_power\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/relay/0:.* relay_0\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/temperature_f:.* temperature_f\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/overtemperature:.* overtemperature
attr MQTT2_shellyplug_s_040E41 room MQTT2_DEVICE
Auffällig ist, dass dabei ein Eintrag für temperature_f (die Temp in Fahrenheit) entsteht, die temperature (in Celsius) aber weggelassen wird. Ist das eine Nachlässigkeit in autocreate vom MQTT2?

Jetzt habe ich das attrTemplate shellyplug angewendet:

Code Auswählen Erweitern

defmod MQTT2_shellyplug_s_040E41 MQTT2_DEVICE shellyplug_s_040E41
attr MQTT2_shellyplug_s_040E41 IODev mqtt2s
attr MQTT2_shellyplug_s_040E41 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $show = '<a href="';;;;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;;;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";;;; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a>" }
attr MQTT2_shellyplug_s_040E41 getList power:noArg shellies/shellyplug-s-040E41/relay/power power
attr MQTT2_shellyplug_s_040E41 model shellyplug
attr MQTT2_shellyplug_s_040E41 readingList shellies/shellyplug-s-040E41/relay/0:.* state\
  shellies/shellyplug-s-040E41/relay/0:.* relay0\
  shellies/shellyplug-s-040E41/input/0:.* input0\
  shellies/shellyplug-s-040E41/online:.* online\
  shellies/shellyplug-s-040E41/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-040E41...mac.*, ? json2nameValue($EVENT) : undef }\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/relay/0/power:.* relay_0_power\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/temperature_f:.* temperature_f\
shellyplug_s_040E41:shellies/shellyplug-s-040E41/overtemperature:.* overtemperature
attr MQTT2_shellyplug_s_040E41 room MQTT2_DEVICE
attr MQTT2_shellyplug_s_040E41 setList off:noArg shellies/shellyplug-s-040E41/relay/0/command off\
  on:noArg shellies/shellyplug-s-040E41/relay/0/command on\
  x_update:noArg shellies/shellyplug-s-040E41/command update_fw\
  x_mqttcom shellies/shellyplug-s-040E41/command $EVTPART1

da fällt mir folgendes auf:
getList
- dieser Eintrag ist nicht funktional
readingList
Die readings sind nicht komplett im Template und werden sofort wieder von autocreate ergänzt?
- temperature und energy fehlt
- shellies/shellyplug-s-040E41/announce: und ... input: gibt es meines Wissens in der shelly Antwort nicht
setList
- announce fehlt. Wobei der Eintrag aus dem Template shelly_announces (könnte man ja zusätzlich anwenden) einen request an alle shelly Geräte auslöst. Das find ich nicht gut.
- update fehlt, stattdessen gibt es ->
- x_mqttcom ist aus meiner Sicht überflüssig weil man alle 5 Kommandos hinterlegen kann.

Ich habe noch ein HTTPMOD Device angelegt, mit dem kann man den Shelly PlugS konfigurieren. Das poste ich an andere Stelle.

Gruß Otto

[Beta-User]

Hmmm,

(ich hoffe, ich erwische jetzt alle angerissenen Dinge, sonst bitte nachfragen):

- Als template wäre wohl besser das mit energy metering gewesen, da sind temperature und energy schon drin, wenn ich das richtig sehe (ich habe nur sehr wenige MQTT-Geräte selbst und muß mich daher auf Zuarbeit verlassen).

- Es gibt gewisse Ungereimtheiten, die aus einer Änderung der Philosophie der shelly-firmware herrühren; das mit dem announce war ursprünglich mal nicht über eine zentrale Stelle gelöst, sondern pro Device. Insgesamt wäre es mMn. (beachte: das ist eine Aussage ohne Praxiserfahrung mit den Geräten und daher sehr "der Spur nach"!) sinnvoll, da die Struktur so zu ändern, dass es eben ein zentrales (announce-) Device gibt, über das updates abgewickelt werden, das braucht man eigentlich nicht "überall", das macht nur den Code und die Nachrichtenauswertung kompliziert...

- Das was du "automatische Befehlsliste" nennst, kommt wohl von den SetExtensions? Und bei dem on-for-timer ist ein auf dem Aktor laufender Timer (statt den aus SE) gemeint? (Geht afaik via MQTT (noch) nicht).

- Das mit temperature verstehe ich nicht. Es scheint jedenfalls dann nach der 2. Meldung wieder in die rL ergänzt zu werden. Ist natürlich irritierend, wenn die erste Meldung "verschluckt" wird, warum auch immer (vermute ein regex-"Problem"). Das ist jedenfalls Bestandteil der pm-Varianten, und daher m.E. jedenfalls kein template-Thema.

- das "plug"-template (mit der getList) ist vermutlich eine Art Karteileiche, wenn die getList keinen Sinn macht, ist das ganze template überflüssig... Werde jedenfalls zumindest mal die getList deaktivieren, mal sehen, ob die irgendjemand fehlt... Dass da "input" dran ist, ist dem Umstand geschuldet, dass da intern das allgemeine shelly-template angewendet wird, und da scheint es einen Button zu geben. Wenn der beim "plug" fehlt, könnte man das ausbauen, aber ob das erforderlich ist, ist eine andere Frage (es ist halt eine überflüssige Zeile, die macht aber auch von alleine keinen Unsinn, sondern nur hier keinen großen Sinn).

- x_mqttcom: Da hatten wir in dem Shelly-Thread afaik eine Diskussion zu (hier nur aus dem Kopf): Klar kann man das technisch gesehen auseinanderdröseln, aber eigentlich sind das Experten-Optionen, die der normale User eigentlich nicht braucht. Dann bekommt er eine ganze Liste und fragt sich, was er damit soll...
Bin da aber leidenschaftslos.

Was HTTPMOD für die shellys angeht, bin ich skeptisch, ob bzw. inwieweit das Vorteile gg. pah's Modul bietet; das ist uU. im Prinzip Doppelarbeit?
Bin da aber schon mangels Hardware nicht durch und will mich damit auch nicht belasten; wie du schreibst: dass ich HTTPMOD-template-Maintainer bin, ist eher eine Notlösung...

Schönen Urlaub jedenfalls,

Gruß, Beta-User

[Otto123]

 
Wie immer in FHEM - viele Lösungen. Klar gibt es noch das Modul von pah - das habe ich mir nicht angeschaut, da für mich die mqtt Variante optimal scheint.

Anregung: Ich würde Templates immer so minimalistisch wie möglich in die Distribution nehmen. Wie Du schon sagst, da bekommt der User sonst einen "Riesenstrauß" und sieht nicht mehr was eigentlich wichtig ist.

SetExtensions: Ja offenbar. In dem Moment wo die setList on und off kennt, kommt das webCmd in die Übersicht und die setExtension Liste in die Auswahlbox.
Aber bei mqtt gehen (ja auch in allen anderen Fällen) meines Wissens ja dann immer nur erstmal on und off. Jeden weiteren setExtension Befehl müsste man ja zu Fuß in die setList stricken. Insofern würde ich mir dort weniger wünschen. Aber das ist sicher auch ein tiefer liegender FHEM Automatismus und kein Template Thema.
Das war ja jetzt ein gedanklicher Fehler von mir  natürlich gehen alle Befehle in der setExtension - klar nur in FHEM und nicht autark in der Hardware.
Für den on-for-timer kann man sicher ein Stück perlcode machen, dafür alleine ist ein HTTPMOD Device überzogen

[aperoap]

Hallo Zusammen,
betreibe seit paar Wochen auch zigbee Komponente bei mir. Bis vor eine Woche habe ich MQTT(mosquitto) und zigbee2mqtt von Koenkk mit cc3251 als Controller und ein cc3251 Router betrieben. Seit eine Woche bin ich auf mqtt2 Server umgestigen un mosquitto gelöscht.
Soweit läuft alles und kann betrieben werden. Die integrierten Templates sind hervorragend.

Problem:

-Der Router wurde erkannt und als mqtt2 device angelegt.
meldet sich minütlich bei Controller und setzt folgende readings.

Code Auswählen Erweitern


Readings
associatedWith MQTT2_zigbee_0x00Xxxxxxxxx 2019-11-09 08:18:50
led_state true 2019-11-09 08:35:50
linkquality 0 2019-11-09 08:35:50
state true 2019-11-09 08:35:50

ich habe leider kein template gefunden, welches (online / offline) Anzeigt wie mqtt.

Anbei Screenshots von komplettes List und angelege mqtt2device.

Der Status bleibt immer auf true, wird minütlich aktualisiert und wechselt nicht auf false auch wenn nicht aktualisiert wird.

Den Vorschlag von Beta-User finde ich sehr gut:
- Vermutlich würde es Sinn machen, in dem Fall auch die Verbindungsqualität irgendwie zu visualisieren (farbig?).

Wäre echt Super.

Ob man LED mit mqtt schalten kann habe ich nicht ausprobiert. Werde ich heute Abend versuchen und berichten.

P.S.

Beta-User ich hoffe bin richtig hier

[Beta-User]

@aperoap:
Hier bist du richtig .

Zunächst mal wäre es natürlich hilfreich, wenn nicht FHEM einen Timer verwalten müßte, um online/offline zu erkennen. Ich meine, dazu gäbe es eine timeout-Option in der yaml, die für alle netzbetriebenen Geräte gültig ist (=>bitte selbst suchen; die entsprechende Option müßte dann in den comment-Text des attrTemplates!).

Für die linkquality hatte ich schon in der Antwort in "contributing" nach dem erwartbaren Wertebereich gefragt, das müßte man dann in ein Farbschema übersetzen. "0" finde ich jedenfalls nicht selbsterklärend. Ist das nun "sehr gut" oder "erdenliedrig"?!?

Für zukünftige Fälle:
Screenshots sind wenig hilfreich, einfacher zu handhaben ist Text, einzupacken in Code-Tags ("#"-Button). Für MQTT2_DEVICE und attrTemplate gerne auch im RAW-Format.


@Otto123:
Die templates sind so, wie die user das haben wollten, die sich aktiv beteiligt haben; das feedback dazu war tendenziell sehr positiv.
Ich sehe das zwar auch so, dass manches nicht erforderlich wäre, aber zum einen ist "abspecken" tendenziell einfacher, wie was dazu zu basteln, oder ich müßte mehrere Varianten anbieten, was auch entsprechender Pflegeaufwand ist.

Im Moment ist user sledge dabei, v.a. das devStateIcon-Thema im Wiki zu erweitern, um da dann auch andere, (einfachere) Varianten auzuzeigen. Wie herum wir das dann am Ende machen: mMn. noch offen (ich tendiere auch leicht zu "weniger ist mehr")...

Was shelly-on-for-timer angeht: die IP-Adresse ist ja bekannt, da kann man vermutlich schon eine HTTP-Lösung basteln (braucht dann aber Passwörter, die man irgendwo eingibt, abspeichert...).