Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[isy]

Hallo Helmut,
war ein Fehler im Template, habe es gefixt. Morgen im update oder per express:

Code Auswählen Erweitern

{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }

Gruß Otto

Funktioniert, vielen Dank, Otto!

[Otto123]

@Helmut Du weißt schon das diese Befehlsblöcke in die Raw Def gehören?
Du kannst die attr Zeilen mit \ am Ende nicht einzeln eingeben
Und Du kannst den gesamten Block nicht einfach komplett in die FHEM Kommandozeile werfen.

[Beta-User]

Damit das nicht untergeht:

Zu dem Leuchten-Thema noch (im "Anregungs"-Thread): Der ursprüngliche Satz beinhaltet evtl. keine Leuchte mit HUE-Setter. Das sollte man nachholen, die Farbwiedergabe von farbigen Leuchten kann sehr unterscheidlich - und auch "falsch" sein, wenn man rgb-Leuchten mit HUE "füttert" - und umgekehrt...

Bräuchte dazu aber die Endpunkte bei zigbee2mqtt und fände es besser, wenn sich das jemand ansieht, der die Dinger hat und in der Wirklichkeit spielen kann...

Das bezog sich auf:

Dann hätte ich zwei Fragen in Verbindung mit einer "Hue white and color ambiance".

   
• Ein Klick auf die Schaltfläche "white" macht ein gelbes Licht. Wo könnte ich das einstellen/verbessern?

   
• An Stelle des Colorpickers(?) ("FFFFFF") wäre ein Farbslider sehr schön. Den kriege ich auf keinen Fall hin, probiere schon seit ein paar Stunden, hier fehlen die Kenntnisse. Könnte das Template dahingehend erweitert werden?

VG Helmut

Vermutlich handelt es sich bei der angefragten Hardware um sowas:
https://www.zigbee2mqtt.io/devices/929002471601.html

Danach müsste sowas gesendet werden:

color_hs: To control the hue/saturation (color) publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"color": {"hue": HUE, "saturation": SATURATION}} (e.g. {"color":{"hue":360,"saturation":100}}).

Einen "hue"-Slider zu bauen (scheint von 1-360 zu gehen?) wäre nicht so schwierig, aber man müsste vermutlich zum einen den aktuellen saturation-Wert mitgeben (?) und zum anderen weiß ich nicht, ob der aktualisierte hue-Wert dann auch irgendwo zurückkommt.

Diese Möglichkeiten auszutesten geht nur, wenn man die Hardware hat und den MQTT-Verkehr dazu mitschneidet.

Da m.E. die hue-Option unter allen Farbangaben die beste ist (da helligkeitslos), es aber kein z2m-hue-Color-template gibt, fände ich es klasse, wenn sich das jemand mal näher "ansehen" könnte....

@isy: Das ist eigentlich auch nicht besonders schwer, ich würde empfehlen, eines der farbigen z2m-templates als Vorlage zu nehmen, und dort die hue- und sat-slider mal testweise einzubauen, (unangepasste) Vorlage (aus zigbee2tasmota):

Code Auswählen Erweitern


hue:colorpicker,HUE,0,1,254 CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"Hue":$EVTPART1} }\
saturation:colorpicker,BRI,0,1,254 CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"Sat":$EVTPART1} }
Dabei beachten, was Otto zu den backslashes ausgeführt hat...

[isy]

@Helmut Du weißt schon das diese Befehlsblöcke in die Raw Def gehören?
Du kannst die attr Zeilen mit \ am Ende nicht einzeln eingeben

Mann-O-Mann, hatte ich vergessen, lieber Otto!

[isy]

@Beta-User #512: Schaue ich mir an und probier das mal im Testsystem. Melde mich dazu, wenn ich weiterkomme.

Ein z2m-hue-Color-template wäre am Ende natürlich einfacher für alle Anwender.

VG Helmut

[TomLee]

Weiß der Kuckuck was genau jetzt der Grund war dass das Device mit dem info-Topic bei mir immer erstellt wurde obwohl in der rL der Bridge eingetragen.

Meine rL sah ja so aus:

Code Auswählen Erweitern

$DEVICETOPIC/bridge/state:.* state\
  $DEVICETOPIC/bridge/config/devices:.* {}\
  $DEVICETOPIC/bridge/config/log_level:.* log_level\
  $DEVICETOPIC/bridge/config/permit_join:.* permit_join\
  $DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  $DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }\
  $DEVICETOPIC/bridge/log:.* log\
  $DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'log_') }\
  $DEVICETOPIC/bridge/networkmap:.* {}\
  $DEVICETOPIC/bridge/networkmap/graphviz:.* graphviz\
  $DEVICETOPIC/bridge/networkmap/raw:.* raw\
  $DEVICETOPIC/bridge/info:.* {}\
  $DEVICETOPIC/bridge/devices:.* devices\
  $DEVICETOPIC/bridge/groups:.* groups\
  $DEVICETOPIC/bridge/extensions:.* extensions\
$DEVICETOPIC/bridge/log:\"type\".\"devices\".\"message\".* devices

Ich hab jetzt einfach aus Verzweiflung mal den info-Topic-rL-Eintrag um drei Zeilen tiefer verfrachtet, hätte auch höher/tiefer sein können, ich hab wahllos drei gewählt gehabt.
Ich hab die Zeile ausgeschnitten, drei Zeilen tiefer wieder eingefügt und vorsichtshalber das Leerzeichen entfernt und wieder eins hingeschrieben:

Code Auswählen Erweitern

$DEVICETOPIC/bridge/state:.* state\
  $DEVICETOPIC/bridge/config/devices:.* {}\
  $DEVICETOPIC/bridge/config/log_level:.* log_level\
  $DEVICETOPIC/bridge/config/permit_join:.* permit_join\
  $DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  $DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }\
  $DEVICETOPIC/bridge/log:.* log\
  $DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'log_') }\
  $DEVICETOPIC/bridge/networkmap:.* {}\
  $DEVICETOPIC/bridge/networkmap/graphviz:.* graphviz\
  $DEVICETOPIC/bridge/networkmap/raw:.* raw\
  $DEVICETOPIC/bridge/devices:.* devices\
  $DEVICETOPIC/bridge/groups:.* groups\
  $DEVICETOPIC/bridge/extensions:.* extensions\
  $DEVICETOPIC/bridge/info:.* {}\
$DEVICETOPIC/bridge/log:\"type\".\"devices\".\"message\".* devices

Auf einmal klappts, das MQTT2_zigbee_bridge Device mit dem info-Topic wird nicht mehr erstellt, zur Kontrolle, weil ich die Daten ja "verwerfe", hab ich auch das Reading info mal erstellen lassen, klappt.

[OdfFhem]

@TomLee

Hast Du denn mal probiert, die Zeile wieder an die alte Stelle zu setzen ?
Wenn es tatsächlich an dem gelöschten Zeichen lag, sollte das ja klappen ...

Normalerweise spielt die Zeile ja keine Rolle, da neue Topics automatisch immer hinten dran geschrieben werden ...

@TomLee @isy

Bei Dir und auch bei @isy wird dies aber nicht automatisch klappen, da in Eurem FHEM-Device ein bridgeRegexp- und ein readingList-Attribut enthalten ist. Bedeutet: Zunächst wird readingList abgearbeitet und wenn dann was Passendes gefunden wurde, dann ist die Bearbeitung zu Ende. Passt nichts aus der readingList, dann kommt der bridgeRegExp zum Einsatz und generiert - sofern noch nicht vorhanden - ein neues FHEM-Device und "erweitert" dessen readingList um das unbekannte Topic.

Hatte ich jetzt anhand der Dateien von @isy auch so weit nachvollzogen und für das aktuelle Problem reicht bei @isy tatsächlich die - schon von @TomLee erwähnte - Übertragung der "erweiterten" readingList auf das "bridge"-Device - das "neue" FHEM-Device kann dann gelöscht werden. Löscht man ohne vorherige Übertragung der readingList nur das neue FHEM-Device und es kommt wieder eine der unbekannten Topics, dann wird wieder autom. ein neues FHEM-Device angelegt.

[TomLee]

Hast Du denn mal probiert, die Zeile wieder an die alte Stelle zu setzen ?
Wenn es tatsächlich an dem gelöschten Zeichen lag, sollte das ja klappen ...

Jetzt, ja. Es bleibt dabei, es wird kein neues Device mehr erstellt, alles gut.

Ich vermute irgendwie das an dem Leerzeichen gelegen hat das merkwürdig war, das hab ich jetzt schon öfter festgestellt wenn ich was aus der Notizen App (Android) kopiere, kann sein das ich das so gemacht habe, muss aber nicht, ich weiß es nicht mehr.

Bei Dir und auch bei @isy wird dies aber nicht automatisch klappen, da in Eurem FHEM-Device ein bridgeRegexp- und ein readingList-Attribut enthalten ist. Bedeutet: Zunächst wird readingList abgearbeitet und wenn dann was Passendes gefunden wurde, dann ist die Bearbeitung zu Ende. Passt nichts aus der readingList, dann kommt der bridgeRegExp zum Einsatz und generiert - sofern noch nicht vorhanden - ein neues FHEM-Device und "erweitert" dessen readingList um das unbekannte Topic.

Komm ich schon wieder nicht mit, bisher hat das sehr wohl gut geklappt und so wird das Bridge-Template auch ausgeliefert.

Hatte ich jetzt anhand der Dateien von @isy auch so weit nachvollzogen und für das aktuelle Problem reicht bei @isy tatsächlich die - schon von @TomLee erwähnte - Übertragung der "erweiterten" readingList auf das "bridge"-Device - das "neue" FHEM-Device kann dann gelöscht werden. Löscht man ohne vorherige Übertragung der readingList nur das neue FHEM-Device und es kommt wieder eine der unbekannten Topics, dann wird wieder autom. ein neues FHEM-Device angelegt.

Mein Verständnis war und ist genau das jetzt geschilderte.



Wo ich immer noch nicht dahinterkomme ist wie das gemeint war:

*** mein Testsystem ***
- [1.Ebene] FHEM-Device myMqttServer vom Typ MQTT2_SERVER. Auf dessen Detailseite sehe ich unter "Probably associated with" ein FHEM-Device namens MQTT2_myMqttServer vom Typ MQTT2_DEVICE.
- [2.Ebene] Das FHEM-Device MQTT2_myMqttServer wurde automatisch erstellt und dient bei mir als zentraler Verteiler. Im Grunde verfügt es nur über ein "einziges" Attribut namens bridgeRegexp. Auf der Detailseite steht unter "Probably associated with" das FHEM-Device myMqttServer.

Warum soll es iVm. dem MQTT2_Server dieses Device in der zweiten Ebene geben ?
Mir ist bewusst das man ein solches iVm. dem MQTT2_Client (MQTT2_CLIENT_general_bridge) benötigt,  aber doch nicht mit dem MQTT2_SERVER ?

[OdfFhem]

Wo ich immer noch nicht dahinterkomme ist wie das gemeint war:

Warum soll es iVm. dem MQTT2_Server dieses Device in der zweiten Ebene geben ?
Mir ist bewusst das man ein solches iVm. dem MQTT2_Client (MQTT2_CLIENT_general_bridge) benötigt,  aber doch nicht mit dem MQTT2_SERVER ?

Tja - kann man so oder so sehen - vielleicht hilft ein "echtes" Beispiel ... 'muss nicht' heisst übrigens nicht 'kann nicht' ...


*** Szenario #1 ***
Ich unterstelle jetzt mal, dass zigbee2mqtt in den nächsten Tagen mit einem bislang unbekannten Subtopic namens 'ganzneu' vorbeikommt. Die offensichtliche Erweiterung der readingList sähe so oder so ähnlich aus:

Code Auswählen Erweitern


$DEVICETOPIC/bridge/ganzneu:.* ganzneu

Die readingList des FHEM-Devices, das das bridgeRegexp-Attribut besitzt, müsste diese Erweiterung bereits enthalten. Ist aber eher unwahrscheinlich und es gibt erst einmal wieder ein "neues" FHEM-Device, dessen readingList die obige Erweiterung enthält. Um das zu bereinigen, muss man die neue Erkenntnis in das readingList-Attribut des "alten" FHEM-Device übernehmen und das "neue" FHEM-Device löschen. Diese Vorgehensweise kann sich im Grunde oft wiederholen ...

*** Szenario #2 ***
Warum auch immer, möchte man die Namensgebung für neue FHEM-Devices ändern. Alle Geräte, die ab heute auftauchen, sollen nicht mehr "zigbee_$1" heissen, sondern "ZigBee_$1". Wie kriegt man das hin ? Vermutlich durch Anpassung vom bridgeRegexp-Attribut im "alten" FHEM-Device - vorrangig durch Nutzung der FHEM-Oberfläche und NICHT durch Editieren von fhem.cfg. Stöbert man in der MQTT2_DEVICE-Doku, dann fällt auf:

... setting bridgeRegexp will remove the readingList attribute and all readings ...

Bedeutet, das "alte" FHEM-Device fängt im Grunde von vorne an ...


Jetzt könnte man die Erläuterungen zur 2.Ebene angehen; sinnvoll wäre aber, erst mal abzuwarten, ob die obigen Szenarien verständlich sind oder ob es dafür auch ohne 2.Ebene eine alternative Lösung gibt oder ob die Szenarien fehlerhaft dargestellt sind oder ob ...

[Otto123]

Die readingList des FHEM-Devices, das das bridgeRegexp-Attribut besitzt, müsste diese Erweiterung bereits enthalten.

Tut sie doch? Auszug aus dem Template

BASE_TOPIC/([A-Za-z0-9._]+)[/]?.*:.* "zigbee_$1"

Aber ich rede nur theoretisch mit, meine Versuche mit zigbee2mqtt liegen derzeit auf Eis.

Ok es geht um die readingList und nicht das bridgeRegexp - ist mir erst beim dritten Lesen klar geworden. Wobei wenn das bridgeRegexp gut ist kommen bei der Bridge keine ungeplanten Subtopics an und es entsteht kein neuer readingList Eintrag. Der sollte bei den Device ankommen für den die bridge zuständig ist.
Aber klar "irgendwas" kann immer passieren.

[TomLee]

@OdFhem

Danke, ich mein ich kann jetzt folgen 

Zum zweiten Szenario:

Wie kriegt man das hin ?

Muss man das überhaupt ? Ich meine, kann auch daneben liegen, daß das zweite Szenario etwas weit hergeholt ist.
Wozu sollte man auf die Idee kommen zigbee_$1 anzupassen zu müssen ?
Und selbst wenn es einen Grund gibt, dann ist doch davon auszugehen das dies vermutlich ein erfahrener User ist der weiß was er tut , der hat sich die rL vor dem anpassen des bridgeRegexp-Attribut einfach kopiert und trägt sie dann wieder ein.
Weiter schliesst man sich doch auch mit der Anpassung des bridgeRegexp-Attribut von der weiteren Verwendung des Bridge-Template aus (weil irgendwann gibts dazu ja ein update, mit aktualisierter rL) ?
Ich kann mir vorstellen das man das ganze ähnlich wie mit den Sprachtemplates lösen könnte, indem beim anwenden des Bridge-Template gefragt wird ob das alte bridgeRegexp-Attribut beibehalten werden soll oder ein neues angegeben werden möchte ..., ich beschäftige mich damit aber nicht.


Zum ersten Szenario:

Du beschreibst jetzt zum wiederholten Mal den Ablauf wie er bisher halt war, auf was bist du genau aus, das ganze vereinfachen wenn möglich ?

[OdfFhem]

Ok es geht um die readingList und nicht das bridgeRegexp - ist mir erst beim dritten Lesen klar geworden.

Gut erkannt 

Wobei wenn das bridgeRegexp gut ist kommen bei der Bridge keine ungeplanten Subtopics an und es entsteht kein neuer readingList Eintrag. Der sollte bei den Device ankommen für den die bridge zuständig ist.
Aber klar "irgendwas" kann immer passieren.

bridgeRegexp kann da nicht wirklich helfen, denn das neue Subtopic ist ja für das FHEM-Device, das für "zigbee2mqtt/bridge" zuständig ist - also das Gerät, das bridgeRegexp sowie eine unvollständige readingList enthält. Bei @TomLee heisst es (vermutlich) MQTT2_zigbee_Bridge mit großem B, bei @isy heisst es lt. der angehängten Dateien MQTT2_zigbee_pi.

Kommt das unbekannte Subtopic und in der readingList wird nichts Passendes gefunden, wird der bridgeRegexp ausgewertet und erzeugt ein neues FHEM-Device namens "zigbee_bridge" bzw. genauer "MQTT2_zigbee_bridge". Jetzt sieht man schon, dass es sich dabei um ein anders benamtes FHEM-Device handelt (nicht MQTT2_zigbee_Bridge und auch nicht MQTT2_zigbee_pi). Sollte man auf die Idee kommen, das "Einstiegsgerät" direkt MQTT2_zigbee_bridge zu nennen, könnte das der Beginn einer Endlosschleife sein oder vielleicht sogar die Lösung ... ausprobiert habe ich dies nie, da ich auch nicht wirklich möchte, dass das bridgeRegexp-Attribut zu sich selbst führt ...

[OdfFhem]

Zum zweiten Szenario:
Muss man das überhaupt ? Ich meine, kann auch daneben liegen, daß das zweite Szenario etwas weit hergeholt ist.
Wozu sollte man auf die Idee kommen zigbee_$1 anzupassen zu müssen ?

Das ist ja nur ein Beispiel. Wir können das Beispiel auch so abändern, dass man selbst gar nicht der Auslöser für eine bridgeRegexp-Anpassung bist. Man spielt also ein zigbee2mqtt-Update ein und anschließend folgen Topics einer neuen Theorie:

Code Auswählen Erweitern


$DEVICETOPIC/bridge/ganzneu:.* ganzneu
$DEVICETOPIC/devicename/ganzneu:.*

wird zu

Code Auswählen Erweitern


$DEVICETOPIC/bridge/ganzneu:.* ganzneu
$DEVICETOPIC/device/devicename/ganzneu:.* ganzneu

bridge bleibt also gleich und die eigentlichen Geräte werden eine Ebene tiefergelegt ...

Zum zweiten Szenario:
Und selbst wenn es einen Grund gibt, dann ist doch davon auszugehen das dies vermutlich ein erfahrener User ist der weiß was er tut , der hat sich die rL vor dem anpassen des bridgeRegexp-Attribut einfach kopiert und trägt sie dann wieder ein.

Könnte sein. Bedenken sollte man dann aber, dass es ja auch keine Readings mehr gibt und man dementsprechend im Zweifel die setstate-Angaben aus z.B. dem RAW Editor retten sollte. Irgendwelche Module oder eigene Perl-Routinen oder ... könnten ansonsten "traurig" werden.

Zum zweiten Szenario:
Weiter schliesst man sich doch auch mit der Anpassung des bridgeRegexp-Attribut von der weiteren Verwendung des Bridge-Template aus (weil irgendwann gibts dazu ja ein update, mit aktualisierter rL) ?

* Beim Original-Beispiel hat man sich ja - aus welchem Grund auch immer - für eine andere Benamung entschieden und übernimmt dann auch gerne die Kontrolle; man möchte dann das Template nicht mehr autom. übernehmen, aber ein aufmerksamer Blick ermöglicht trotzdem die gezielte Übernahme von notwendigen Anpassungen. Man könnte natürlich auch andersherum vorgehen und übernimmt das Template doch wieder autom. und wendet dann die irgendwo notierten, individuellen Anpassungen nachträglich nochmals an. Oder man hat eine eigene Template-Datei angelegt und übernimmt die notwendigen/wünschenswerten Änderungen des allgemeinen Templates in das eigene und wendet dann das eigene Template nochmals an. Es gibt bestimmt noch weitere Möglichkeiten ...
* Beim jetzt abgeänderten Beispiel ist irgendwer der erste Anwender, der die neuen Topics kennengelernt hat, ein wenig Lösungsfindung betrieben hat und letztlich auch Änderungen fürs Template vorgeschlagen hat. Jeder, der jetzt das neue Template "blind" in sein schon lange bestehendes FHEM-Device übernimmt, hat u.U. vorab nichts gerettet ... (autom. angelegte Sicherungsdateien sind vermutlich trotzdem vorhanden) ...

[OdfFhem]

Zum ersten Szenario:

Du beschreibst jetzt zum wiederholten Mal den Ablauf wie er bisher halt war, auf was bist du genau aus, das ganze vereinfachen wenn möglich ?

Da würde ich sagen, gerne. Ob das "Ergebnis" von allgemeinem Interesse wäre, kann ich natürlich nur begrenzt beurteilen.

* Mein Produktivsystem basiert auf MQTT2_CLIENT und besteht aus 3 Ebenen - nicht sonderlich überraschend:
1.Ebene enthält 1 FHEM-Device (MQTT2_CLIENT) und stellt den Client dar.
2.Ebene enthält 1 FHEM-Device (MQTT2_DEVICE); dieses dient als zentraler Verteiler und besteht praktisch nur aus dem bridgeRegexp-Attribut. Einzige Ebene, die bislang bei mir für die Neuanlage von FHEM-Devices zuständig ist.
3. Ebene enthält beliebig viele FHEM-Devices (MQTT2_DEVICE), die gemäß der 2.Ebene angelegt wurden; haben bislang nie ein bridgeRegexp-Attribut.

* Mein Testsystem basiert auf MQTT2_SERVER und besteht aus 3 Ebenen - eher überraschend:
1.Ebene enthält 1 FHEM-Device (MQTT2_SERVER) und stellt den Server dar.
... alles andere ab der 2.Ebene stimmt mit dem Rest vom Produktivsystem überein

* Durch die exklusive Nutzung vom bridgeRegexp-Attribut in der 2.Ebene
- geht durchs Ändern des bridgeRegexp-Attributes nichts verloren
- werden nie "versehentlich" (immer wieder mal) neue Geräte angelegt, sondern automatisch nur die readingList im betroffenen Gerät ergänzt.

[isy]

By-The-Way:
Meine beiden Devices  MQTT2_zigbee_bridge und MQTT2_zigbee_pi sind jetzt beide im State "online".
Könnte am MQTT (Template) Update heute liegen?