FHEM Forum

Hallo zusammen,

ich fange hier mal einen neuen Thread an, nachdem das Thema Kompabilität von MQTT2-IO's mit der MQTT_GENERIC_BRIDGE die Tage hier ein Thema war, was dankenswerterweise dazu geführt hat, dass man libmodule-pluggable-perl nicht mehr benötigt: https://forum.fhem.de/index.php/topic,117423.msg1121207.html#msg1121207 (https://forum.fhem.de/index.php/topic,117423.msg1121207.html#msg1121207).

Es gibt aber ein paar weitere Themen, die man in dem Zusammenhang ggf. nochmal aufgreifen bzw. verbessern könnte (prio aufsteigend!).
a) den patch von Nestor hier: https://forum.fhem.de/index.php/topic,117659.0.html (https://forum.fhem.de/index.php/topic,117659.0.html)
b) die interne Abfrage, welcher IO-Typ verwendet wird, kommt mir nicht optimiert vor:

Zitat von: Beta-User am 12 Januar 2021, 21:06:13
Was mir bei der Durchsicht noch aufgefallen war: die Prüfung auf die IO-Type wird jedesmal in der "Vollversion" durchlaufen; evtl. könnten wir überlegen, ob es Sinn macht, das zu beschleunigen (z.B. indem man ein Internal oder einen helper-hash setzt)?

(müßte man wohl löschen, wenn das IODev-Attribut nach $init_done angefasst wird).

c) (v.a. auch an @Rudi):
"Konflikte" zwischen MQTT2_DEVICE und MQTT_GENERIC_BRIDGE - das "autocreate"-(+)-Problem...

Soweit ich es richtig verstanden habe, was wir vor einiger Zeit diskutiert hatten, ist es immer kritisch, wenn potentiell zwei Client-Module (dieselben?) Informationen im Rahmen von dispatch erhalten sollen:

Zitat von: rudolfkoenig am 07 Januar 2019, 09:19:28
In FHEM gibt es mW keine Moeglichkeit, die gleichen Daten von zwei logischen Modulen zu bearbeiten.
Dispatch ruft der Reihe nach alle logischen Module auf (erst die bereits definierten/geladenen, danach die noch nicht geladenen).
Wenn einer der Module "hab was gefunden" meldet, hoert die Schleife auf.
MQTT2_SERVER ruft Dispatch so auf, dass kein Nachladen ungeladener Module stattfindet, falls kein autocreate spezifiziert ist.

Ich habe im Moment keine Idee, wie ich ohne Nebeneffekte mehrere Module aufrufen soll.
MQTT_GENERIC_BRIDGE und MQTT2_DEVICE Parallel zu betreiben sollte gehen (ungetestet), aber nur fuer unterschiedliche Topics, und mit abgeschalteten MQTT2_SERVER bzw. MQTT2_CLIENT autocreate. Falls das nicht der Fall ist, bitte um Beispiel zum Nachstellen.

Im Moment gibt es da zwar die "workarounds", entweder autocreate am IO abzuschalten, oder via bridgeRegex dafür zu sorgen, dass CID leer ist (und MQTT2_DEVICE die Kette daher nicht abbricht). ABER: hat der user - warum auch immer - ein MQTT2_DEVICE mit "passendem" (oder besser unpassendem) readingList-Eintrag, greift sich MQTT2_DEVICE die message und MGB ist "raus".
Das ist eine Sache, die uns mittelfristig vermutlich beschäftigen wird.
Frage (es ist mir bewußt, dass eine "Sonderbehandlung" einzelner Module durch andere Module nicht unbedingt das Architektenherz höher schlagen lassen...): Wäre es nicht sinnvoll/möglich, wenn MQTT2_DEVICE am Ende ggf. prüft, ob MGB geladen ist und der Topic in den dortigen subscriptions drin ist und die betreffende Nachricht dann (nur) in diesen Fällen weiterleitet?

Denn es gibt ein anderes Thema, das auch damit zusammenhängen dürfte:
MQTT_GENERIC_BRIDGE generiert massenhaft incoming-count Events. Rekursion? (https://forum.fhem.de/index.php/topic,98079.0.html)Meine Vermutung: 00_MQTT.pm gibt nur weiter, was auch abonniert ist (und "weiß", was zu wem gehört), MQTT2-IO's geben weiter, was bekannt ist und keinen anderen "bevorrechtigten" Abnehmer hat. Letzteres kann deutlich mehr sein. Es muss also sowieso an irgendeiner Stelle geprüft werden, ob die Nachricht überhaupt relevant ist (wäre natürlich gut, wenn man das nicht doppelt macht). Zumindest, was die Event-Generierung angeht, setzte an dieser Stelle mein patch-Versuch von gestern an, aber das kann auch Unsinn sein.

Soweit erst mal mein Sachstand...

Grüße, Beta-User

ZitatWäre es nicht sinnvoll/möglich, wenn MQTT2_DEVICE am Ende ggf. prüft, ob MGB geladen ist und der Topic in den dortigen subscriptions drin ist und die betreffende Nachricht dann (nur) in diesen Fällen weiterleitet?

Moeglich ja, aber sowas baue ich erst ein, wenn der Weltuntergang unmittelbar bevorsteht. Eher kurz danach.

Vmtl. muesste man erst einen Schritt zuruecktreten, und ueberlegen, was ein Benutzer will bzw. potentiell welche Szenarien sinnvoll sind: MQTT2_DEVICE (MD) alleine, MQTT_GENERIC_BRIDGE (MGB) alleine, MD fuer A,B,C,.. und MGB fuer X,Y,Z oder beide fuer alle.
Danach ueberlegen, wie wir das implementieren.

 :)
Sehe im Moment folgende Szenarien:

A) User kommt von "extern" und hat FHEM gefunden, weil er seine Lieblings- (oder Problem-) Hardware damit eingebunden bekommt. Betreibt FHEM also nur als Abstraktionslayer für einen sehr begrenzten Anwendungfall und will so schnell es geht zurück "in seine Welt" und sich möglichst wenig mit den (Un-) Tiefen von FHEM befassen; Broker ist dann typischerweise extern.
Kann stressfrei MGB mit M2C ohne autocreate verwenden, M2D wird ihn in der Regel nicht interessieren, diesen Teil macht er sowieso extern. (fyi: M2C in Interaktion mit MGB ist im Moment mein "blinder Fleck").

Mögliches Problem: Er findet FHEM irgendwann toll und will die Automatisierung nach FHEM verlagern. M2D wird dann zur "no-go-zone", weil er dann wissen muss, wie man es händisch konfiguriert. Geht auch, ist aber schwierig, v.a., wenn er rausfinden will, welchen topic er in rL angeben muss, damit attrTemplate durchläuft...
(Um diesen User-Typ sollte man sich bemühen, denn er kennt die große weite Welt und kommt nicht zu FHEM, weil er ein großes deutschsprachiges Forum sucht, sondern weil FHEM stabil und flexibel ist!).

B) FHEM-User, der ein "schnelles shiny frontend" haben will und daher die relevanten Daten schnell mal nach MQTT bringt, um sie z.B. in NodeRed zu visualisieren (siehe verlinkten Thread). Die, die das bisher gemacht haben, waren bisher mangels Alternativen mehr oder weniger alle auf mosquitto+MQTT+MGB, aber künftig wird das eher M2S+MGB sein; der "neue" User dieses Typs kommt von M2D her und hat seine shelly/tasmota/zigbee2mqtt-Devices alle schon in FHEM am Laufen. (Evtl. teste ich das mal aus, nachdem ich mich ja sowieso in das Thema eingedacht habe).

Problem: M2D soll auf autocreate bleiben, dieser User-Typus schätzt den Komfort und will keine komplizierte "autocreate-hell", die ihm in einem Moment der Unaufmerksamkeit die externe Anbindung zerschießt...

C) Der "Multi-System-User", der mehrere FHEM betreibt, Daten zwecks Standardisierung via MQTT austauscht und manche "andere" Hardware-Systeme ggf. auch auf dem MQTT-Weg anbindet (zigbee2mqtt ist afaik nur ein Vertreter dieser .*2mqtt-Generation; das Fibaro-HCL, das ich für die update-Geschichte verwendet habe, hat z.B. auch eine gecrackte firmware, auf der direkt auch ein mosquitto läuft, und es gibt afaik auch eine HMCCU2mqtt-Anbindung). Schätzt an FHEM die hohe Flexibilität und ist auch mit Perl soweit vertraut, dass er die Automatisierungen irgendwo in einem Zentralsystem oder auch verteilt abbildet und "irgendwo" das logging erledigt

MAn. nicht unser Problem; dieser Usertyp kennt die vielfältigen Fallsticke bzw. wird sie finden und erfolgreich umschiffen...

Ich nehme mit: man will MGB und M2D (mit oder ohne autocreate), wahlweise einzeln oder beide zusammen.
Als Bonus: M2D autocreate nicht fuer bestimmte Topics.

Z.Zt. geht MGB oder M2D, auch beides zusammen, aber dann nicht mit M2D autocreate.
D.h. es fehlt MGB + M2D mit autocreate, und ein Autocreate-Topic-Filter.

Uebersehe ich etwas?

Zitat von: rudolfkoenig am 13 Januar 2021, 17:12:17
Ich nehme mit: man will MGB und M2D (mit oder ohne autocreate), wahlweise einzeln oder beide zusammen.

"man" will ich nicht für mich in Anpruch nehmen, aber grundsätzlich sehe ich schon Bedarf für eine Koexistenz von "MGB und M2D (mit oder ohne autocreate)".

Wäre interessant, wie andere das sehen...

Zitat
Als Bonus: M2D autocreate nicht fuer bestimmte Topics.

Jein: _automatisches Ausschalten_ von M2D autocreate fuer bestimmte Topics.
Der Bonus geht heute schon: Man definiere ein M2D mit passender bridgeRegexp und hinterlege "" als CID.
Das Problem ist nur, dass es auf diese Weise ein verstecktes und für immer unverstandenes feature bleiben wird, auch wenn es seit einiger Zeit im Wiki steht...

Z.Zt. geht MGB oder M2D, auch beides zusammen, aber dann nicht mit M2D autocreate.
D.h. es fehlt MGB + M2D mit autocreate, und ein Autocreate-Topic-Filter.

Uebersehe ich etwas?

Das Schlagwort vom "Autocreate-Topic-Filter" gefällt mir gut, der Rest geht (mit den genannten Einschränkungen) eigentlich heute schon, und das mit dem Ausschalten von "autocreate" ist - wenn ich es richtig verstanden habe - auch nur die halbe Miete: Es verhindert nämlich nicht, dass "falsche" readingList-Einträge in M2D im Ergebnis dann MGB "abklemmen", oder? Auch das noch abzufangen wäre ggf. die "Luxusvariante".

Zusammengefasst: "Autocreate-Topic-Filter" wäre als (Arbeitstitel) "bridge_2MGB_regexp" für die M2-IO's eventuell eine auch halbwegs vermittelbare Konstruktion?

Hallo allerseits,

ich denke, es ist schwer zu sagen, welche User-Typen alles existierren. Die genannten gibt es sicher, aber vermutlich auch eine Reihe Mischformen.

Ich selbst gehöre vermutlich zum Typ C. Habe 7 FHEM-Instanzen laufen (incl. Test), 2 mal NodeRED (eine davon Test), zigbee2mqtt, ein kleines Zoo Mqtt-fähige Geräte und diverse Testinstallationen von Automation-Software (IOBrocker, HAS) die in Docker-Containern leben und meistens 'down' sind. Die sind per MQTT miteinander verbunden, den Server macht Mosquitto (auch in Container, wie die meisten Sachen hier).

Alle Instanzen haben ihre Aufgabe und sollen nach möglichkeit nicht mehrere Dinge tun. Daher ist ein MQTT2_SERVER nicht meine Wahl.
M2D nutze ich nicht, alles macht die MGB. Dennoch halte ich die saubere Zusammenarbeit von MGB und M2D für sehr wichtig.
Die Gründe für den Verzicht sind diverse.
Zunächst mag ich autocreate nicht - ich mache gerne die Definitionen selbst, wie ich sie verstehe und brauche (sehe dennoch ein, dass für einen durchschnittlichen User autocreate ein Segen ist).
Dann ist mir auch Syntax für M2D nicht geläufig (bin faul - Bridge kann ja auch alles und die kenne ich etwas besser ;D ).
Dazu kommt die Tatsache, dass man mit M2D ein Topic wohl nicht für mehrere Devices 'wiederverwenden' kann. Das ist für mich aber ein valides Anwendungsfall - z.B. aus einem komplexeren (json) Wert in einem Topic mehrere unterschiedliche Geräte zu befüttern. Da die Bridge und M2D sich hier in die Quere kommen können, verwende ich sie gat nicht erst. Es ist mir wichtig, solche unerwartete Seiteneffekte (ich lege ein M2D und an anderen Stellen verschwinden Daten) unbedingt zu vermeiden.

Also bin ich vermutlich was das betrifft eher ein Exot und orientiere mich bei der Entwicklung lieber an Meinungen aus dem Forum (ohne natürlich eigene Interessen zu vergessen :D ).

Meine Sicht darauf, was zu tun wäre, ist ungefähr folgende:
- Lösung des Problems des Zusammenspiels von MGB und M2D (Prio 1)
- Überarbeitung der Dokumentation (Anwender- unf vor Allem Einsteiger-freundlich) (Prio 1)
- Erstellung einer Anleitung mit Vorschlägen zur Standardisierung (Syntax, Topics, etc.) (Prio 2)
- neue Features (Prio 99, mir fehlt aktuell praktisch nichts, aber vlt. kommt noch was wichtiges)
- Fehlerfixes, soweit Fehler gemeldet werden (laufend)
- Optimierungen, wenn Performance-Probleme auftreten (bei Bedarf)

Ich habe schonmal das clientOrder Attribut fuer MQTT2_SERVER und  MQTT2_CLIENT implementiert:

ZitatclientOrder [MQTT2_DEVICE] [MQTT_GENERIC_BRIDGE]
      set the notification order for client modules. This is relevant when autocreate is active, and the default order (MQTT2_DEVICE MQTT_GENERIC_BRIDGE) is not adequate. Note: Changing the attribute affects _all_ MQTT2_SERVER instances.

Damit kann man z.Bsp. MQTT2_DEVICE komplett ignorieren, oder es erst, wenn MQTT2_GENERIC_BRIDGE nichts findet, aktivieren.
Fuer Letzteres muss MQTT2_GENERIC_BRIDGE aber mitspielen, und im ParseFn als erstes [NEXT] zurueckliefern.

Zitat von: rudolfkoenig am 17 Januar 2021, 14:11:13
Damit kann man z.Bsp. MQTT2_DEVICE komplett ignorieren, oder es erst, wenn MQTT2_GENERIC_BRIDGE nichts findet, aktivieren.
Fuer Letzteres muss MQTT2_GENERIC_BRIDGE aber mitspielen, und im ParseFn als erstes [NEXT] zurueckliefern.

Danke, ich denke, damit kann man das Problem zumindest umschiffen. :)
Spricht eigentlich etwas dagegen, wenn die MQTT_GENERIC_BRIDGE immer [NEXT] zurückgebt? Dann würden ja (bei order (MQTT_GENERIC_BRIDGE MQTT2_DEVICE )) immer die passenden MQTT2_DEVICE-Instanzen gesucht?

In diesem Fall [NEXT] zurueckzuliefern ist unproblematisch, MQTT2_DEVICE macht es bereits, ohne "wenn und aber" => bitte in MQTT_GENERIC_BRIDGE auch einbauen.

[NEXT] ist ein Problem z.Bsp. bei FS20: FS20V, USF1000 und BS sind Spezialfaelle, die alle FS20 Signale senden, mit bestimmten Muster. Wenn diese Module [NEXT] zurueckliefern wuerden, wuerde FHEM das Signal auch als "normales" FS20 interpretieren, was nicht zielfuehrend ist.

@hexenmeister:
Habe mal versucht, den Code von MGB an der Stelle zu verstehen (Parse() und onmessage()), um ggf. unterstützen zu können.

Irgendwie habe ich aber zwei gedankliche Hänger, v.a. im gedanklichen Kontext, dass mehrere MGB aktiv sind:
- wenn bei der ersten MGB kein topic matched, gibt Parse() direkt leer ("") zurück, oder ist das ein Mißverständnis?
- Wenn ein topic matched, wird das erforderliche Array incl. "[NEXT]" zurückgegeben, aber es wird nie geschaut, ob es ggf. noch einen zweiten Match gibt?

Das erstere wäre in unserem Kontext schädlich, oder? Und mehrere MGB würden dann auch (zumindest von MQTT2-IO's) auch nicht "korrekt" beliefert werden, oder?
Und ist das letztere (erster match => raus) wirklich (aus Effizienzgründen?) so beabsichtigt? Weiß im Moment nicht, für was man eine 1:n-Zuordnung praktisch benötigt, aber als "Gruppenschaltung" ist sowas ähnliches z.B. auch in der Tasmota-Firmware vercodet. Will sagen: früher oder später wird ggf. jemand drüber stolpern, man sollte es also wenigstens in der Doku erwähnen...?

Bin nicht sicher, ob ich deinen Gedankengang richtig verstehe, aber ParseFn wird nur einmal pro Modul aufgerufen, und nicht pro Instanz.

Davon WR ich ausgegangen.

...ist jetzt alles nicht so einfach, weil sich manches überschnitten hatte...

Also: Unter https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/e2b565deffc5c9d98140f0115cfdb3fd9bfe0d80 ist ein patch zu finden, leider passen die Zeilennummern vermutlich nicht 100% zur svn-Fassung und ggf. muss man auch einen Blick auf das Umfeld werfen.

Diese (gesamte) Fassung läuft jedenfalls bei mir hier im Hauptsystem seit ein paar Minuten, bringt aber dann noch zusätzlich diverse perlcritic-Änderungen und den 1. cref-Vorschlag (noch ohne Hinweis auf das mit dem 2-er-IO-Attribut).

Die wesentlichen Ideen:
- IO-TYPE-Bestimmung etwas optimiert;
- Die Zählung ist jetzt abhängig vom IO-TYPE. Sollte für die neuen IO's die Event-Flut eindämmen und für 00_MQTT.pm 100% kompatibel sein;
- Die Schleife zum Durchlaufen aller MGB-Instanzen ist umgebaut, es sollte jetzt immer NEXT zurückkommen. Da bin ich aber nicht sicher, ob das noch kompatibel zu 00_MQTT.pm ist, weil da das GP_Catch verwendet wird und ggf. jede MGB-Instanz separat aufgerufen wurde (?). Unklar ist mir aber warum dann für 00_MQTT.pm überhaupt das Array verwendet wurde, da hätte eigentlich dann nur die eine Instanz "durchlaufen" werden dürfen und dann macht es ggf. auch Sinn, das return "" zwischendurch zu lassen, aber eben dann mit der Prüfung, ob es 00_MQTT.pm war, das die ParseFn aufgerufen hat.
Den NEXT-Teil habe ich bisher nicht getestet...

Bitte fragen, wenn was offen ist, und sorry für den Telegramm-Stil grade.

Zitat von: rudolfkoenig am 18 Januar 2021, 12:36:12
In diesem Fall [NEXT] zurueckzuliefern ist unproblematisch, MQTT2_DEVICE macht es bereits, ohne "wenn und aber" => bitte in MQTT_GENERIC_BRIDGE auch einbauen.

done :)

Zitat von: Beta-User am 18 Januar 2021, 17:42:31
@hexenmeister:
Habe mal versucht, den Code von MGB an der Stelle zu verstehen (Parse() und onmessage()), um ggf. unterstützen zu können.

Irgendwie habe ich aber zwei gedankliche Hänger, v.a. im gedanklichen Kontext, dass mehrere MGB aktiv sind:
- wenn bei der ersten MGB kein topic matched, gibt Parse() direkt leer ("") zurück, oder ist das ein Mißverständnis?
- Wenn ein topic matched, wird das erforderliche Array incl. "[NEXT]" zurückgegeben, aber es wird nie geschaut, ob es ggf. noch einen zweiten Match gibt?

Das erstere wäre in unserem Kontext schädlich, oder? Und mehrere MGB würden dann auch (zumindest von MQTT2-IO's) auch nicht "korrekt" beliefert werden, oder?
Und ist das letztere (erster match => raus) wirklich (aus Effizienzgründen?) so beabsichtigt? Weiß im Moment nicht, für was man eine 1:n-Zuordnung praktisch benötigt, aber als "Gruppenschaltung" ist sowas ähnliches z.B. auch in der Tasmota-Firmware vercodet. Will sagen: früher oder später wird ggf. jemand drüber stolpern, man sollte es also wenigstens in der Doku erwähnen...?

Habe auch versucht nachzuvollziehen, was mein Gedankengang damals gewesen ist, ist auch schon etwas her... :o
Irgendwie sehe ich auch keinen Sinn "" zurückzugeben. Habe jetzt hier return ("[NEXT]");
So wie ich das sehe, ist aktuell nicht möglich, mehrere Bridges für den selben(!) IO zu haben - die zweite bekommt nichts.
Es macht eigentlich auch nicht viel Sinn - im Gegensatz zu mehreren Bridges mit verschiedenen IODev.
Ich werde es vermutlich umbauen, um für alle Fälle unerwartete Effekte auszuschliessen.

Zitat von: Beta-User am 18 Januar 2021, 21:28:46
Diese (gesamte) Fassung läuft jedenfalls bei mir hier im Hauptsystem seit ein paar Minuten, bringt aber dann noch zusätzlich diverse perlcritic-Änderungen und den 1. cref-Vorschlag (noch ohne Hinweis auf das mit dem 2-er-IO-Attribut).

Die wesentlichen Ideen:
- IO-TYPE-Bestimmung etwas optimiert;
- Die Zählung ist jetzt abhängig vom IO-TYPE. Sollte für die neuen IO's die Event-Flut eindämmen und für 00_MQTT.pm 100% kompatibel sein;
- Die Schleife zum Durchlaufen aller MGB-Instanzen ist umgebaut, es sollte jetzt immer NEXT zurückkommen. Da bin ich aber nicht sicher, ob das noch kompatibel zu 00_MQTT.pm ist, weil da das GP_Catch verwendet wird und ggf. jede MGB-Instanz separat aufgerufen wurde (?). Unklar ist mir aber warum dann für 00_MQTT.pm überhaupt das Array verwendet wurde, da hätte eigentlich dann nur die eine Instanz "durchlaufen" werden dürfen und dann macht es ggf. auch Sinn, das return "" zwischendurch zu lassen, aber eben dann mit der Prüfung, ob es 00_MQTT.pm war, das die ParseFn aufgerufen hat.
Den NEXT-Teil habe ich bisher nicht getestet...

- Ob die Optimierung für die IO-TYPE-Bestimmung so wirklich viel bringt - bin ich nicht überzeugt. Sind ja auch nur Zugriffe auf ("etwas weiter liegende") Hashes.
Bin da aber kein Profi. Wenn das wirklich was bringt - übernehme ich die Änderung. In jedem Fall, wenn man diese cached, dann sollte aber auch Änderungen des iodev-Attributen verarbeitet werden.

- Die Änderung zum Eindämmen von "Nahrichten Flut" schaue ich mir noch genauer an und werde sie übernehmen.

- Die Änderung der Rückgabe in onmessage wird vermutlich MQTT-Kompatibilität brechen.

Werde mir morgen weiter ansehen, sonst wird meine Nacht zu kurz ;D

Na ja, das mit der IO-Frage sind dann halt jedes Mal noch ein paar zusätzliche Vergleiche, und @MQTT2-IO eben für jede Nachricht... _Glaube_, es würde Sinn machen, das soweit als möglich zu optimieren, ggf. bis hin zum nummerischen Vercoden (?) des TYPE und/oder der Weiterreichung der bekannten Info zwischen den Funktionen. (@Rudi: Deine Meinung zu dem Punkt würde mich interessieren).
Der Helper-Hash wird direkt in AttrFn() gefüllt, das sollte eigentlich (bis auf gelöscht) passen, ab Neuvergabe ist alles wieder i.O.. Ein Problem könnte es darstellen, wenn da Unsinn drin steht, sowas könnte man ggf. für den $init_done-Fall abfangen? (ggf. auch in einer gesonderten Funktion später, dann aber mit LOG-Eintrag?)

Was "onmessage" angeht, könnte man die Rückgabe ja wieder abhängig machen vom IO-TYPE. Das wäre dann nur eben wieder nochmal einer dieser Vergleiche mehr.

---

Was mehrere MGB für ein IO angeht, könnte ich mir zumindest einen Anwendungfall vorstellen (aber eher für publish): Hat man z.B. ein "ESP-Display", dann schickt man darauf ggf. parallel dasselbe Reading. (Klar, das geht eigentlich besser via !display, und damit ist es evtl. eher eine Darstellungsfrage).

Sorry, aber ich habe in meinem Vorschlag auf alle Fälle auch noch einen bug drin:

Zitat1 : ERROR: >ARRAY(0x5574eb7a44f8)< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer

Mache grade den Test mit
if( ref($fret) eq 'ARRAY' ) {
      push @ret, @$fret;
    }
Das sieht - jedenfalls was das Log angeht und auf den ersten Blick - besser aus...

Zitat von: hexenmeister am 19 Januar 2021, 00:31:00
- Die Änderung der Rückgabe in onmessage wird vermutlich MQTT-Kompatibilität brechen.

Habe versucht, die Befürchtung im Code nachzuvollziehen. Hier mal meine Überlegungen:

- MQTT ruft direkt onmessage auf:
Eingehende Nachrichten sind "MQTT_PUBLISH", daher ist das die Verarbeitung ab Zeile 542 in 00_MQTT.pm?
Dann wird für alle Clients via GP_ForallClients (diese von Rudi ungeliebte Parse-Funktion) deren "OnMessageFn" aufgerufen, wenn es eine solche gibt.

- Für MGB ist das der Fall (~Zeile 411):
  $hash->{OnMessageFn} = "MQTT::GENERIC_BRIDGE::onmessage";

- Die Rückgabe interessiert 00_MQTT.pm gar nicht, oder?
Die "onmessage" wird (#551) über CallFn() aufgerufen, aber deren Rückgabe wird nicht in eine Variable gepackt oä.. Problematisch könnte also nur "wantarray" sein, aber da keine Rückgabevariable genannt ist, dürfte das auch schlicht "false" sein...?

(- "Parse" ist - soweit ich das erkennen kann für 00_MQTT.pm eigentlich gar nie Thema.)

Ergo sollte es unproblematisch sein, dass 00_MQTT.pm da nun ein Array präsentiert bekommt (oder wie bisher nichts)...

M.E. ist es aber vermutlich einfacher, onmessage() einen weiteren (optionalen, boolschen) Parameter zu spendieren, um die Art der Ansteuerung zu kennzeichnen, ein Vorschlag dazu wäre unter https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/ad030d274ed2bb084f9aeb66b4c416b92a878ee1 zu finden.

[OT]
CallFn() kannte ich noch gar nicht, ist aber ggf. hilfreich, um ein kleines Problem im Zusammenspiel zwischen WeekdayTimer und weekprofile zu beheben.
[/OT]

(Hier OT) betr. die Unterstützung von AttrTemplate:
https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/5365b7dfeb2d896cdbdfca03b9b5af802e4c73ba#diff-3ea12b29d24dcb4406f9722ded23cb7085c438a990ca877cd49ddac5084c3dbf

Und die zugehörige template-file zum Testen (zum Testen kann man beliebige Ziel-Devices nehmen, es gehen z.B. auch "dummy"):
https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/blob/main/lib/AttrTemplate/general_use.template

Zitat von: Beta-User am 19 Januar 2021, 13:31:16
(Hier OT) betr. die Unterstützung von AttrTemplate:

'n Abend!
Habe jetzt folgendes (mehr oder weniger abgewandelt) übernommen:
- increment 'incoming-count' only if at least one device is affected => gegen "Nachrichtenflut"
- Schleife über die Instanzen in Parse => damit alle Instanzen zum Zuge kommen
- Optimierung für die Ermittlung von IODev-Type

und Deine Erweiterung für AttrTemplate.

Kurz getestet, scheint alles noch zu funktionieren :)

Danke für die Patches!

Danke auch für's übernehmen!

Was AttrTemplate angeht, scheinst du die Methode also als gute Idee zu empfinden, dann wird sich jetzt wohl "jemand" um die damit zusammenhängenden Fragen der "Standardisierung" von Topics, Readings und Werten befassen dürfen...
Werde dazu daher den einen oder anderen Thread eröffnen, mal schauen.

Im Nachgang ist mir noch eingefallen, dass man vermutlich AttrTemplate_Initialize() aufrufen sollte, wenn eine MGB nach $init_done definiert wird. Zum Hintergrund: da man die betreffenden attrTemplates nur braucht, wenn eine MGB vorhanden ist, werden die auch nur in diesem Fall geladen. Das würde also Rückfragen vermeiden, warum keine templates zu sehen sind.

---

Eine Sache betr. Optimierung ist mir noch aufgefallen: MGB verwendet derzeit kein NOTIFYDEV. Kostet nicht nur ~30% Performance, es wäre v.a. auch transparenter, wenn dieser Mechanismus genutzt würde. Kann gerne versuchen, dazu was (auf Basis der aktuellen svn-Version ::) ) liefern, wenn das gewünscht ist.

---

Ansonsten wären wir m.E. - abgesehen von Doku-Fragen zur Reihenfolge (clientOrder) - mit dem eigentlichen Thema dieses Threads soweit durch, oder?

ZitatMGB verwendet derzeit kein NOTIFYDEV. Kostet nicht nur ~30% Performance

Die "~30% Performance"-Kosten sind stark davon abhaengig, wie die Konfiguration ist. Wenn alle Events per MGB weitergeleitet werden, dann wird NOTIFYDEV eher Zusatzaufwand bei der Neuberechnung der NotifyFn-Warteschlangen bedeuten. Und weil normalerweise nur eine MGB-Instanz definiert ist, kostet das Fehlen von NOTIFYDEV pro Event "nur" einen zusaetzlichen, potentiell ueberfluessigen NotifyFn Aufruf. Ich weiss allerdings (noch?) nicht, wie teuer ein MGB-NotifyFn Aufruf ist.

Ich will damit nicht sagen, dass man NOTIFYDEV nicht setzen soll, nur dass man Aufwand/Nutzen vorher abwaegen sollte.

Na ja, es wird - soweit ich das verstehe - kurz gecheckt, ob es "global" ist und ansonsten mehr oder weniger direkt geschaut, ob das betr. Device in der internen Device-Liste ist (#2165ff in der aktellen svn-Version). Von daher würde ich annehmen, dass es MGB-intern ziemlich effizient ist bzw. es sich kaum unterscheidet von dem, was zur Auswertung von NOTIFYDEV erforderlich wäre.

Meine Tendenz betr. der "Beispiel-Implementierung" (auch via attrTemplate-Vorschläge) ist eher in Richtung selektiver Weiterleitung einzelner Readings aus tendenziell wenigen Geräten. Von daher dürfte es in diesem gedanklichen Modell so sein, dass z.B. bei der Implementierung eines vollen Bedieninterfaces auf MQTT-Basis vielleicht 30-40% der Devices sich dann auch im Bedieninterface wiederfinden. Dabei bin ich mal davon ausgegangen, dass z.B. bei CUL_HM alle Kanäle via Bulk-update aktualisiert werden, wenn eine Nachricht empfangen wird und habe das einschl. der Kanäle dann als ein Device gezählt.

Ob sich das unter diesen Gegebenheiten lohnt, kannst du vermutlich besser beurteilen. ATM macht das dann eher keinen großen Sinn (oder vielleicht optional, falls jemand das nur dazu nutzen will, ein paar Infos an ein ESP-Display zu schicken?), oder?

Die überwachten Geräte kann man via list sehen, von daher ist das mit der Transparenz auch kein echtes Argument.

Zitat von: Beta-User am 20 Januar 2021, 07:53:31
Was AttrTemplate angeht, scheinst du die Methode also als gute Idee zu empfinden, dann wird sich jetzt wohl "jemand" um die damit zusammenhängenden Fragen der "Standardisierung" von Topics, Readings und Werten befassen dürfen...
Werde dazu daher den einen oder anderen Thread eröffnen, mal schauen.

Im Nachgang ist mir noch eingefallen, dass man vermutlich AttrTemplate_Initialize() aufrufen sollte, wenn eine MGB nach $init_done definiert wird. Zum Hintergrund: da man die betreffenden attrTemplates nur braucht, wenn eine MGB vorhanden ist, werden die auch nur in diesem Fall geladen. Das würde also Rückfragen vermeiden, warum keine templates zu sehen sind.

Die Idee mit den Templates finde ich gut und hatte frühen auch schon mit dem Gedanken gespielt, noch bevor es diesen Mechanismuf gab. Blieb aber auch bei Ideen. Ich muss mir das Verfahren noch genauer angucken, weiß noch nicht, ob ich mir das richtig vorstelle. Was ich gerne hätte, wäre eine Möglichkeit, quasi per Knopfdruck ein bestimmten Device/DeviceTyp gebrauchsfertig einzurichten, in diesem Fall mit Attribute wie "mqttDefaults", "mqttPublish"; "mqttSubscribe" (bzw. können diese je nach Prefix auch anders heißen).

Wäre es schädlich, wenn die AttrTemplate_Initialize() unter Umständen mehrfach aufgerufen wird? Wenn nicht, könne ich einfach in firstInit stecken, dieser wird ggf. bei Setzen von IODev nochmals aufgerufen.

Zitat von: Beta-User am 20 Januar 2021, 07:53:31
Eine Sache betr. Optimierung ist mir noch aufgefallen: MGB verwendet derzeit kein NOTIFYDEV. Kostet nicht nur ~30% Performance, es wäre v.a. auch transparenter, wenn dieser Mechanismus genutzt würde. Kann gerne versuchen, dazu was (auf Basis der aktuellen svn-Version ::) ) liefern, wenn das gewünscht ist.

Ich weiß nicht recht... Die MQTT_GENERIC_BRIDGE braucht potintiell alle Events von allen Geräten mit den entsprechenden Attributen. Es wirf ein Lookup gemacht und wenn das Gerät nicht dabei ist, geht es schon wieder raus. Ich verspreche mir nicht viel davon.

Zitat von: rudolfkoenig am 20 Januar 2021, 09:48:43
Die "~30% Performance"-Kosten sind stark davon abhaengig, wie die Konfiguration ist. Wenn alle Events per MGB weitergeleitet werden, dann wird NOTIFYDEV eher Zusatzaufwand bei der Neuberechnung der NotifyFn-Warteschlangen bedeuten. Und weil normalerweise nur eine MGB-Instanz definiert ist, kostet das Fehlen von NOTIFYDEV pro Event "nur" einen zusaetzlichen, potentiell ueberfluessigen NotifyFn Aufruf. Ich weiss allerdings (noch?) nicht, wie teuer ein MGB-NotifyFn Aufruf ist.

Ich will damit nicht sagen, dass man NOTIFYDEV nicht setzen soll, nur dass man Aufwand/Nutzen vorher abwaegen sollte.

Wenn das Gerät/Event nicht von Interesse ist, läuft es nur auf ein kurzes Lookup hinaus, wenn natürlich gesendet werden soll, kann man man das mit 'expression' sehr teuer machen. ;D

@Rudi: ich hätte noch eine Performance-Frage:
Die Überlegung wäre, ggf. AnalyzePerlCommand statt eval für "expression" aufzurufen. Das kostet etwas Performance, bietet aber dafür "gewohnte Syntax" (z.B. ReadingsNum() sollte sich direkt verwenden lassen, sonst müsste man das entweder mit "::" aufrufen oder in das Package importeren)  und (ggf.) stacktrace.
An sich glaube ich nicht, dass es mit bestehenden Installationen bzw. heutigen expression-Ausdrücken Probleme aufwerfen würde, aber deine Meinung zu diesem Aspekt der Rückwärts-Kompabilität und zur Performance-Frage wäre interessant.

Zitat von: hexenmeister am 20 Januar 2021, 22:21:20
Die Idee mit den Templates finde ich gut und hatte frühen auch schon mit dem Gedanken gespielt, noch bevor es diesen Mechanismuf gab. Blieb aber auch bei Ideen. Ich muss mir das Verfahren noch genauer angucken, weiß noch nicht, ob ich mir das richtig vorstelle. Was ich gerne hätte, wäre eine Möglichkeit, quasi per Knopfdruck ein bestimmten Device/DeviceTyp gebrauchsfertig einzurichten, in diesem Fall mit Attribute wie "mqttDefaults", "mqttPublish"; "mqttSubscribe" (bzw. können diese je nach Prefix auch anders heißen).

Hier findest du eine passende attrTemplate-Datei:
https://forum.fhem.de/index.php/topic,117423.msg1123626.html#msg1123626

Zitat
Wäre es schädlich, wenn die AttrTemplate_Initialize() unter Umständen mehrfach aufgerufen wird? Wenn nicht, könne ich einfach in firstInit stecken, dieser wird ggf. bei Setzen von IODev nochmals aufgerufen.

"Schädlich" nicht, aber unnötig. Der Aufruf macht nur Sinn, wenn man entweder
- eine neue/geänderte template-File hat (ergo: nach dem Abspeichern der oben verlinkten Datei einmalig ausführen), oder
- ein Device erstellt hat, das ggf. zusätzliche attrTemplate möglich macht, die bisher nicht geladen waren (das "prereq:"-Flag, das z.B. die zigbee2tasmota-attrTemplate nicht lädt, wenn es keine bridge (=passende Hardware) gibt.

Beim FHEM-Start wird es sowieso ausgeführt, das Thema beschränkt sich also auf diesen einen Fall...

Die vorliegende .tempate beinhaltet
- etwas englische allgemeine Info ("commandref" ist übertrieben, aber es sollte ausreichen um die Frage zu klären, wie es denn gedacht ist...)
- die Option, das MGB-Device selbst zu konfigurieren (ist derzeit im Wesentlichen halt etwas allgemeine Info sowie ein Vorschlag, wie $base festgelegt werden könnte)
- ein "Device"-Template, mit dem Thermostat-Geräte verschiedener Typen (MAX, CUL_HM und ZWave) mit passenden (einschl. der prefix-Bestimmung ;) ) Attributen versorgt werden können. (Für den "vollen Komfort" würde nur die "automatische Zwischenbestimmung" des Device-Type fehlen, was aber ggf. andere Probleme verursachen könnte).

Kurz:
Du wendest das "base_settings_to_MQTT_GENERIC_BRIDGE" an, und dann für jeden Thermostaten das "mgb_thermostat" (das dich dann nach einigen weiteren Infos fragt). Fertig...
(noch nicht perfekt, aber man hat zumindest die Option, via MQTT die Solltemperatur zu regeln, immer unter der "Flagge" "desired-temp".)

Würde vorschlagen, das Thema attrTemplate in einem separaten Thread abzuhandeln, auch, damit das ggf. mehr "Helfer" mitbekommen und wir dann auch die $base-Geschichte so geregelt bekommen, dass es für die User paßt.

Zitat
Ich weiß nicht recht... Die MQTT_GENERIC_BRIDGE braucht potintiell alle Events von allen Geräten mit den entsprechenden Attributen. Es wirf ein Lookup gemacht und wenn das Gerät nicht dabei ist, geht es schon wieder raus. Ich verspreche mir nicht viel davon.

Das wäre nicht das Problem. Via NOTIFYDEV könntest du (nur) bestimmen, von welchen Geräten du (immer alle) Events haben willst. Aber der Aufwand dürfte in den meisten Fällen nicht gerechtfertigt sein; anders als bei einem klassischen Event-Handler geht es ja bei so einem Querschnitts-Device darum, eine zentrale Stelle zu haben, über die (sowieso) alles läuft; zum Vorsortieren (durch fhem-pl) besteht daher häufig deutlich weniger Anlass...
M.E. kann/sollte man das Modul in dem Punkt lassen "as is".

ZitatDie Überlegung wäre, ggf. AnalyzePerlCommand statt eval für "expression" aufzurufen. Das kostet etwas Performance, bietet aber dafür "gewohnte Syntax" (z.B. ReadingsNum() sollte sich direkt verwenden lassen, sonst müsste man das entweder mit "::" aufrufen oder in das Package importeren)  und (ggf.) stacktrace.

Bin verwirrt: welcher meiner Module braucht ein ::, um auf ReadingsNum zugreifen zu koennen?

Zitat von: rudolfkoenig am 21 Januar 2021, 10:54:42
Bin verwirrt: welcher meiner Module braucht ein ::, um auf ReadingsNum zugreifen zu koennen?

Bei keinem!
Es ging um MGB; da braucht man diesen Umweg (derzeit) in "expression", und die Frage war, ob es im Ergebnis "teuer" ist, das umzustellen.

Dass sich die Frage nicht wirklich allgemeingültig beantworten läßt, ist mir schon klar, ich _vermute_, dass das, was hexenmeister in diesem Beitrag (https://forum.fhem.de/index.php/topic,117423.msg1120947.html#msg1120947) gezeigt hat eher eine komplexe Variante ist, und tendiere daher dazu, das über AnalyzePerlCommand in die "FHEM-übliche" Syntax zu überführen.

AnalyzePerlCommand ist nicht viel teurer in diesem Fall als eval, es werden zusaetzlich nur die $sec,$min,$hour, etc Variablen gesetzt und $we.
Das potentiell teure Authorized ist nur fuer Faelle mit Client-Verbindungen aktiv, was hier nicht der Fall ist.
Und featurelevel <= 5.6 sollte auch kaum jemand setzen.

OK, Danke für die Einschätzung!

@hexenmeister: Kann gerne einen patch vorbereiten (für die beiden Themen AnalyzePerlCommand und AttrTemplate_Initialize), falls Interesse besteht?

Zitat von: hexenmeister am 20 Januar 2021, 22:21:20
Ich muss mir das Verfahren noch genauer angucken, weiß noch nicht, ob ich mir das richtig vorstelle. Was ich gerne hätte, wäre eine Möglichkeit, quasi per Knopfdruck ein bestimmten Device/DeviceTyp gebrauchsfertig einzurichten, in diesem Fall mit Attribute wie "mqttDefaults", "mqttPublish"; "mqttSubscribe" (bzw. können diese je nach Prefix auch anders heißen).

Aktuellste Version/Einführung: MQTT_GENERIC_BRIDGE - sinnvolle defaults (für attrTemplate)  (https://forum.fhem.de/index.php/topic,117987.0.html)

Nachdem ich jetzt ein wenig rumgespielt habe, werfe ich mal eine These in den Raum:

Wer MGB nutzt, will (nur) für matchende Topics (in der Regel) kein autocreate!

Zum Setup: ein Sytem, M2S mit autocreate auf simple, zwei MGB, als externe MQTT-clients dann mosquitto_sub und mosquitto_pub (von einem anderen System aus, was aber egal ist). clientOrder ist (noch) nicht gesetzt (hier aber ebenfalls erst mal irrelevant).

Folge: jeder publish, der eigentlich an die MGB gehen soll, landet in einem M2D (entsprechend der ClientID aus "-i").

Das ist dann super, wenn man "Irrläufer" detektieren will. Für "gute" Kommandos hat man aber in der Regel genau einen Abnehmer, nämlich die MGB (bzw. eine davon).

Würde daraus folgende Schlüsse ziehen:
- clientOrder sollte automatisch auf MGB M2D umgestellt werden, wenn es eine solche gibt (Annahme: dabei die Last ist identisch, egal, welche Reihenfolge gesetzt ist);
- MGB sollte als (änderbaren!) default NICHT [NEXT] zurückgeben, wenn es einen match hatte (=> Attribut dafür einbauen?)

Damit würde auch die Notwendigkeit entfallen, entweder die Infos doppelt auszuwerten (indem man eben das M2D bestehen läßt), oder den User auf diese "bridgeRegexp nach leer"-Lösung zu verweisen...

Aber vermutlich übersehe ich mal wieder was wichtiges?

Mit der Aenderung wird auch das autoload-Verfahren geaendert, d.h. das erste M2D wird nie automatisch angelegt (meine ich, habs aber nicht getestet).

Ich warte mit der Aenderung in M2C, bis MGB fertig ist. :)

Zitat von: rudolfkoenig am 23 Januar 2021, 18:50:55
Ich warte mit der Aenderung in M2C, bis MGB fertig ist. :)

Gerne. Wie genau soll die Änderung aussehen?
- Soll MGB, falls IODefv ein MQTT2_CLIENT ist, automatisch clientOrder Attribut setzen (falls nicht bereits vorhanden)? Oder macht das besser M2C?
- Neuen Attribut (Namensvorschläge?) unterstützen, damit kein [NEXT] zurückgegeben wird, im Falle MGB ein Abnehmer-Device gefunden hat?

Korrekt so?

Moin zusammen,

habe mal das mit der clientOrder in das allgemeine MGB-attrTemplate reingenommen (sollte zur RADIO-Auswahl stehen, falls IODev nicht TYPE MQTT ist), update ist im svn.
Habe eigentlich Skrupel, in "fremden Devices" automatisiert was zu ändern, und finde ich es ok, wenn der User auch Infos hat, was "seine" Attribute eigentlich sollen ("Attribute gehören den Usern...").
Von daher neige ich dazu, den Teil so zu lassen, wie er ist. Nach den ersten Rückmeldungen zu dieser attrTemplate-Geschichte gehe ich davon aus, dass sich das hinreichend verbreiten wird, um auf ausreichend breiter Basis support leisten zu können.

Was NEXT angeht, dieser Vorschlag:

forceNEXT: Only relevant for MQTT2_CLIENT or MQTT2_SERVER as IODev. If set to 1, MQTT_GENERIC_BRIDGE will forward incoming messages also to further client modules like MQTT2_DEVICE, even if the topic matches to one of the subscriptions of the controlled devices. By default, these messages will not be forwarded for better compability with autocreate feature on MQTT2_DEVICE. See also clientOrder attribute in MQTT2 IO-type commandref (link); setting this in one instance of MQTT_GENERIC _BRIDGE might affect all.

forceNext ist equivalent zu "clientOrder MGB". Das als Voreinstellung waere mAn einfacher, damit spart man sich das Schrauben an zwei Stellen.

Da ich aber inzwischen den Faden komplett verloren habe: welches Problem loesen wir hier gerade?

Vermutlich lösen wir grade Verständnisschwierigkeiten bei einem einzelnen User...

Also zur Aufschlauung desselben:
Wenn clientOrder MGB M2D gesetzt ist und ein match gefunden wird, kommt derzeit nach [NEXT] eine Liste der Devices, die bereits beliefert wurden, oder? Wenn ich deine Rückfrage jetzt richtig deute, wird dann (und nur dann) kein weiterer Dispatch-Aufruf an M2D getätigt und das Problem, das ich versuche zu lösen existiert gar nicht....?

Muss ich austesten, aber wenn das so wäre, würde es m.E. entweder reichen, das attrTemplate so zu belassen, wie es ist, oder (für die "volle Nutzerführung") es bei Setzen des IO-Attributs (nur nach $init_done) automatisch aufzurufen?

Ähm, also:

Testumgebung immer noch, update von eben:
defmod MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE

(autocreate ist nicht gesetzt, also default). Eine "umleitende bridgeRegexp" ist afaik nicht gesetzt.

version MQTT.* liefert:

10_MQTT2_DEVICE.pm 23596 2021-01-23 17:25:12Z rudolfkoenig

00_MQTT2_SERVER.pm        23538 2021-01-17 13:02:24Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 23561 2021-01-19 23:13:31Z hexenmeister



Setzt man an einen Topic, den MGB kennt eine message ab, wird autocreate aktiv und erstellt erst mal ein M2D, MGB bekommt davon nichts mit. Erst die zweite Message führt dann dazu, dass MGB aktiv wird.
Löscht man das M2D wieder, beginnt das Spielchen von vorne.

Kommt mir seltsam vor, aber vermutlich übersehe ich auch hier mal wieder was...?

Danke fuers Testen.
Ich habe was uebersehen, fhem.pl ueberschreibt teilweise die clientOrder Reihenfolge, das muss ich noch fixen.
Ich kann aber dein Testergebnis nur so erklaeren, dass bereits am Anfang sowohl eine MGB wie auch eine M2D Definition vorhanden war.
Stimmt das?

Sorry , das sich da unpräzise war. Test war mit dem Haupt-System, und da sind einige M2D definiert.
Ist m.E. in etwa das "User Typ A)"-Szenario.

Ich habe jetzt einige Bugs im Zusammenhang mit clientOrder gefixt.
Kannst du es bitte erneut testen?

Zitat von: rudolfkoenig am 24 Januar 2021, 12:10:53
forceNext ist equivalent zu "clientOrder MGB". Das als Voreinstellung waere mAn einfacher, damit spart man sich das Schrauben an zwei Stellen.

Wenn diese zwei Einstellungen equivalent sind, dann habe ich etwas nicht verstanden.
Die Order bestimmt doch, damit die MGB (wenn sie vorne erwähnt wird) trotz autocreate und auch wenn es zu dem Topic passende Geräte existieren noch etwas mitbekommnt.
Und forceNEXT würde die Bridge anweisen, den "Ball" weiter zu werfen, auch wenn sie was passendes gefunden hat. Bei forceNEXT=0 würde ja in diesem Fall kein M2D mehr was bekommen.
Habe ich das richtig wiedergegeben?

Falls ja, würde ich das so implementieren und den Doku-Text von Beta-User auch so übernehmen (finde ich sehr gut, vielen Dank!).
Voreinistellung (also falls kein Attribut definiert) wäre 1?

clientOrder bestimmt, welche Module was bekommen, in welcher Reihenfolge. Wenn clientOrder=MGB ist, dann kommt M2D nicht dran, egal ob ein M2D definiert ist oder nicht, und was MGB zurueckliefert => forceNext ist ueberfluessig.
Das bisherige Verhalten (immer [NEXT] zurueckliefern) wird benoetigt fuer clientOrder=MGB M2D.

Ok, danke für die Erklärung. Ich bin davon ausgegangen, dass immer beides (M2D, MGB) angegeben werden sollen, nur die Reihenfolge halt anders.
So stimmt das aber. forceNext=0 wäre überflüssig, das das selbe Effekt mit clientOrder = MGB erreiht wird.

Ok, dann brauchen wir fordeNext nicht.

Hallo Rudolf,

in fhem.pl Zeile 4006
    next if(!$dmsg !~ m/$modules{$m}{Match}/s);

Sieht das '!' am if Anfang beim delete unnötigerweise (fatalerweise) übrig geblieben aus.

So war es wohl gedacht
    next if($dmsg !~ m/$modules{$m}{Match}/s);


Gruß,

Ansgar

Danke, habs gefixt.

Zitat von: rudolfkoenig am 24 Januar 2021, 19:53:10
Ich habe jetzt einige Bugs im Zusammenhang mit clientOrder gefixt.
Kannst du es bitte erneut testen?

Mach' ich, vielleicht klären sich dann auch meine Verständnisprobleme betr. clientOrder vs. forceNEXT.
Im Moment bin ich noch nicht überzeugt, dass es keinen Sinn macht, da clientOrder ja global (für den jeweiligen IO-TYPE) wirkt. Rückmeldung folgt, wird aber etwas dauern, vielleicht brauche ich erst noch eine weitere Spielwiese....

@hexenmeister:
Falls du dich mit dem Hinweis auf my $foo = $bar if $baz; # UNDEFINED! (https://forum.fhem.de/index.php/topic,117934.0.html) beschäftigen willst: In https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/6fd40496772d7f2d3046c953409698193aadbd23 wäre mein noch nicht intensiv getesteter Versuch zu finden, die betreffenden Stellen auf "offiziell zulässige" Weise zu notieren.

ZitatIm Moment bin ich noch nicht überzeugt, dass es keinen Sinn macht, da clientOrder ja global (für den jeweiligen IO-TYPE) wirkt.

Nicht mehr, es ist Instanz spezifisch geworden.

Danke für die Info, dann kann ich einfach mit meinem "User will einfach eine shiny MQTT-based-UI haben"-Szenarium weitermachen.

Da gibt es mAn. einen M2S, MGB und eine beliebige Anzahl von M2D, und der User will autocreate für M2D aktiv halten.
Dann sollte er die Reihenfolge in clientOrder umdrehen, also "MGB M2D", und er will (so meine These) weder ein M2D für Topics, die zu MGB passen, noch will er Events an einem "Sammel-M2D" generiert haben.

Habe jetzt nochmal in den aktuellen Code in fhem.pl geschaut (ab #4004 bzw. 4017), und glaube, dass es (zumindest in diesem Szenarium)
a) sinnvoll ist, in MGB konfigurierbar zu machen, ob bei einem Match "[NEXT]" zurückgeliefert wird, und
b) die in +99% gewünschte/erwartete Voreinstellung für forceNEXT "0" ist.

Ad a) nochmal: Es geht ausschließlich um den Fall, dass es einen Topic-Match in MGB gibt, alles andere soll/muss selbstredend an M2D weitergegeben werden!

Im Moment glaube ich auch nicht, dass es ein Problem in anderen User-Szenarien gäbe; der einzige Sonderfall der mir grade vor Augen steht, bei dem das problematisch sein kann wäre, wenn jemand bewußt einen Topic nutzen will, um sowohl eine MGB wie auch M2D zu beliefern. Sowas kann vorkommen, wenn jemand Gruppenschaltungen oä. vornehmen will, aber dann ist er zum einen Fortgeschrittener, und zum anderen findet er dann über forceNEXT bzw. clientOrder auch die erforderliche Doku, um das umzusetzen; dann halt mit dem "Nachteil", dass er Ideen entwickeln muss, um den unbeabsichtigten Rest zu verwerfen.

Hallo zusammen,

kann es sein, dass auf Grund der Optimierungen (MGB, M2C) das retain Flag nicht mehr richtig an den Broker (mosquitto) weitergegeben wird?

Verbose 5 MGB:
2021.01.25 15:47:51 5: MQTT_GENERIC_BRIDGE:DEBUG:> [ZS_zs_CO_MQTT_Generic_Bridge] publish: scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp => 22.0 (qos: 0, retain: 1)

Verbose 5 M2C:
2021.01.25 15:52:12 5: ZS_zs_CO_SCADA_MQTT_Client: sending PUBLISH 19(0)3scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp22.0
2021.01.25 15:52:23 5: ZS_zs_CO_SCADA_MQTT_Client: sending PINGREQ (192)(0)
2021.01.25 15:52:23 5: ZS_zs_CO_SCADA_MQTT_Client: received PINGRESP

Debug Mosquitto:
Client (null) received PUBLISH (d0, q0, r0, m0, 'scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp', ... (4 bytes))
scada/haus/E4/az/THKV_Heizkoerper_Wand/desired-temp 22.0


Sieht für mich so aus, als würde das retain=1 aus MGB globalDefaults verwendet, aber nicht an den Broker weitergegeben. Was M2C damit macht, kann ich nicht erkennen.

Bitte nicht durch die Zeitstempel irritieren lassen, ich habe den Fall zweimal ausrprobiert

VG
Torsten

Fuer MGB kann ich nicht reden, aber M2C scheint noch zu tun, abgesehen davon dass ich an dieser Stelle nichts geaendert habe.
Folgendes sind abwechselnd die Befehle aus FHEM und die mosquitto debug Ausgabe:

fhem> set m2c publish -r a b
1611593233: Received PUBLISH from m2c (d0, q0, r1, m0, 'a', ... (1 bytes))

fhem> { IOWrite($defs{m2d}, "publish", "c:r d") }
1611593510: Received PUBLISH from m2c (d0, q0, r1, m0, 'c', ... (1 bytes))

fhem> attr m2c qosMaxQueueLength 50
fhem> set m2c publish -r e f
1611593812: Received PUBLISH from m2c (d0, q1, r1, m1, 'e', ... (1 bytes))

fhem> set m2c publish  g h
1611593887: Received PUBLISH from m2c (d0, q1, r0, m2, 'g', ... (1 bytes))


@ToKa:
Habe den Verdacht, dass retain ggf. @M2.* schon länger nicht klappt; kannst du mal testweise # 2456 so ändern:
    $topic ="-r $topic" if $retain;
Kann das nicht so recht nachvollziehen, weil da IOWrite aufgerufen wird, kann also auch falsch sein, da kann ggf. Rudi auch was dazu sagen, in der folgenden Zeile steht dann nämlich:
    IOWrite($hash, "publish", $topic.' '.$message);

Hallo Beta-User,

bei mir ist die 10_MQTT_GENERIC_BRIDGE.pm 23561 2021-01-19 23:13:31Z hexenmeister installiert - letztes Update heute morgen gemacht. Bei mir ist es die Zeile 2455, die ich jetzt aber auf Deinen Vorschlag abgeändert und fhem neu gestartet habe.

Danach wird der Wert gar nicht mehr an den Broker übertragen. Aus dem Beispiel von Rudi, sieht das auch eher nach :r statt -r aus.

VG
Torsten

Zitat von: Beta-User am 25 Januar 2021, 13:47:54
Danke für die Info, dann kann ich einfach mit meinem "User will einfach eine shiny MQTT-based-UI haben"-Szenarium weitermachen.

[...] glaube, dass es (zumindest in diesem Szenarium)
a) sinnvoll ist, in MGB konfigurierbar zu machen, ob bei einem Match "[NEXT]" zurückgeliefert wird, und
b) die in +99% gewünschte/erwartete Voreinstellung für forceNEXT "0" ist.
[...]

Hab's jetzt nochmal praktisch durchgespielt. Zumindest in dem o.g. setup wäre es sinnvoll, bei positiven Matches in der MGB [NEXT] _nicht_ zurückzugeben, sonst wird autocreate auch in den Fällen aktiv, in denen die eigentlich gewünschte Aktion bereits erledigt sein sollte.

Anbei daher ein patch, der das Verhalten konfigurierbar macht; mit drin sind diese "my $foo = ... if"-Geschichten. Läuft testweise noch nicht lange, aber es läuft :) ...

ZitatAnbei daher ein patch, der das Verhalten konfigurierbar macht; mit drin sind diese "my $foo = ... if"-Geschichten.

Konstrukte der Art "my $xx = yy if(zz);" sind problematisch, weil $xx den Wert der letzten Schleife behaelt, falls zz nicht zutrifft.
Das hat mich zwar auch schon gebissen, ich habe meine Module aber noch nicht aufgeraeumt, ist TODO.
jw9 hat netterweise auch schon darauf hingewiesen (https://forum.fhem.de/index.php/topic,117934.0.html), leider im komplett falschen Forumsbereich.

Zitat von: rudolfkoenig am 27 Januar 2021, 11:28:34
jw9 hat netterweise auch schon darauf hingewiesen (https://forum.fhem.de/index.php/topic,117934.0.html), leider im komplett falschen Forumsbereich.

...vielleicht sollte man ihm sagen, dass er "nur" Tester werden muss, um im Developer-Bereich posten zu können?

Na jedenfalls sollte der besagte Patch auch eventuellen Bissverletzungen vorbeugen (auch wenn der eigentliche Code hier zwar "nicht regelkonform" ist/war, aber am Ende eigentlich auch so relativ unproblematisch aussieht).

Zurück zum "eigentlichen Programm":

Zitat von: hexenmeister am 14 Januar 2021, 00:02:24
Meine Sicht darauf, was zu tun wäre, ist ungefähr folgende:
- Lösung des Problems des Zusammenspiels von MGB und M2D (Prio 1)
- Überarbeitung der Dokumentation (Anwender- unf vor Allem Einsteiger-freundlich) (Prio 1)
- Erstellung einer Anleitung mit Vorschlägen zur Standardisierung (Syntax, Topics, etc.) (Prio 2)
- neue Features (Prio 99, mir fehlt aktuell praktisch nichts, aber vlt. kommt noch was wichtiges)
- Fehlerfixes, soweit Fehler gemeldet werden (laufend)
- Optimierungen, wenn Performance-Probleme auftreten (bei Bedarf)

- Das Zusammenspiel sollte (bis auf die Frage, wo das retain abgeblieben ist?) soweit gelöst sein;
- Doku:
-- cref zu MGB - Vorschlag für die (seitherige) DE-Version existiert, Rückmeldung steht noch aus;
-- cref zu MQTT_BRIDGE (neu): https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/537e8e149feb4dbfa48361d334326d298ffc597d
-- attrTemplate-feature fehlt in der Doku noch, Vorschlag folgt, wenn die Strukturierung vollends durch ist und die Benennungen für's erste aufgegleist sind;
-- bei Gelegenheit fange ich (oder ein Freiwilliger?) dann einen Wiki-Artikel dazu an, der die Reihenfolge/Basics und das Zusammenspiel ggf. etwas näher erläutert;
- features: da fällt mir im Moment nur die AnalyzePerlCommand-Frage ein. Kann/soll ich da was liefern?

Sonst:
Den TARGETTYPE könnte man auch in option:{} prüfen, vermutlich baue ich das so um. Hat halt den "Nachteil", dass man dann nichts mehr "cross-verwenden" kann (also z.B. nicht mehr mit einem dummy testen), aber wer da was vermisst, ist dann ggf. eher geneigt, uns Baumaterial zu liefern?

Kurz hatte ich die Idee, die MGB-attrTemplate-Aufrufe an die Sprachsteuerungs-attrTemplate dranzuhängen, aber das birgt v.a. bei mehrkanaligen Devices das Risiko, dass der User zwischendurch abbricht und dann Teile unkonfiguriert bleiben. Folglich habe ich das verworfen. Oder gibt's da andere Meinungen?

Nachtrag noch zum Patch-Vorschlag betr. der direkten Initialisierung der attrTemplate:

Am Ende von sub Define() noch folgendes einfügen:
  ::AttrTemplate_Initialize() if $::init_done;
(Vor   
  # noetig hier beim Anlegen im laufendem Betrieb
  InternalTimer(1, \&firstInit, $hash);

@hexenmeister:
Hab's jetzt alles nochmal zusammengeschoben, patch anbei, jetzt sollten auch die <li>-Elemente in der commandref wieder ausgeglichen sein ::) .
Bei der Gelegenheit: Ist es nach wie vor richtig, dass mqttAlias nur in publish-Richtung funktioniert? (Ist/war mir bisher entgangen...)

Dann habe ich mal einen Wiki-Artikel angefangen, der das eher in eine "wie gehe ich das als Einsteiger an?"-Form bringt; wäre nett, wenn ihr da Rückmeldung geben könntet, ob das auch aus eurer Sicht in die richtige Richtung geht.

Weiter gibt's jetzt zu den Thermostaten/attrTemplate auch noch (teilweise) "actuator", das ist btw. auch ein gutes Beispiel für's "zur-Zahl-machen".

Hallo,

es ist ganz schön kompliziert geworden, in FHEM eine MQTT-Schnittstellen in beiden Richtungen zu implementieren. :-)
Ich weiß nicht mehr, was plötzlich anders ist, aber nun kommen meine Publishs nicht mehr am Gerät an, sondern werden in einem MQTT2_fhem-Device gesammelt.

IODev
defmod mosquitto MQTT2_CLIENT mosquitto:1883
attr mosquitto autocreate complex
attr mosquitto clientId fhem
attr mosquitto clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr mosquitto ignoreRegexp fhem/(?!set/)
attr mosquitto keepaliveTimeout 60
attr mosquitto msgAfterConnect -r fhem/connection/status connected
attr mosquitto msgBeforeDisconnect -r fhem/connection/status disconnected
attr mosquitto qosMaxQueueLength 100
attr mosquitto username mqtt

Bridge
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=System->MQTT-Bridge
attr mqttGeneric IODev mosquitto
attr mqttGeneric globalDefaults sub:base={"fhem/set"} pub:base={"fhem"} pub:qos=0 sub:qos=2 retain=0
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count

Das FHEM-Device
attr hmdevice mqttPublish *:topic={"$base/$device/$name"}
attr hmdevice mqttSubscribe :stopic={"$base/$device/$name"}

Publish-Test
fhem/set/hmdevice/state on


M2D-Bridge-Device
Hier kommt das State-Reading mit dem "on" an.

defmod MQTT2_fhem MQTT2_DEVICE fhem
attr MQTT2_fhem IODev mosquitto
attr MQTT2_fhem autocreate 1
attr MQTT2_fhem bridgeRegexp (tele|stat|shellies|valetudo|Advantech)/([^/]+)/.*:.* "$2"\
  zigbee2mqtt/bridge/.*:.* "zigbee2mqtt"\
  sonos/connected.* "sonos"\
  tvheadend/[^/:]+.* "tvheadend"\
  milight/LWT:.* "milight"\
  (ESPClient_[^/]+)/.*:.* "$1"\
  (ebusd[^/]*)/global/.*:.* "$1"\
  [^/]+/(ems-esp[^/]+)/start:.* "$1"\
  (mygateway[\d]+)-(in|out)/.* "$1"\
  (wallpanel|wled)/([^/]+)/.*:.* "$1_$2"\
  go-eCharger/([^/]+)/.*:.* "go_eCharger_$1"\
  owntracks/[^/]+/([^/:]+).* "owntracks_$1"\
  home/(O[^/]*M[^/]*G[^/]*)/LWT:.* "$1"\
  homeassistant/.*/config:.* ""
attr MQTT2_fhem model MQTT2_CLIENT_general_bridge
attr MQTT2_fhem readingList fhem:fhem/set/hmdevice/state:.* state\
fhem:homeassistant/status:.* status
attr MQTT2_fhem setList clear_all:noArg {fhem("deleteattr $NAME readingList;; deletereading -q $NAME (?!associatedWith).*");;return undef}
attr MQTT2_fhem setStateList on off

Hat jemand einen Tipp, woran das liegen kann?

clientOrder am M2_CLIENT passend setzen.

Verstehe ich nicht. Habe ich doch bereits. Erst die MGB dann das M2D.

Hmmm, also...

Hatte das mit der clientOrder irgendwie gestern auf dem Handy übersehen, sorry.

Wenn ich das richtig deute, wird das Device "hmdevice" aber durchaus geschalten, oder?
Das "Problem" ist nur, dass zusätzlich dieser Eintrag in der readingList erscheint?

Wenn das das Thema ist, kannst du entweder
- meinen "forceNEXT"-Patch testen und ggf. "bewerben" (das verhindert in der Standardeinstellung, dass M2D noch was von messages sieht, die die MGB verwerten kann), oder
- deine bridgeRegexp ergänzen, dass der "fhem/"-Topic-Zweig nach "" umgeleitet wird. Damit würde dann (wie bisher auch schon im Wiki dargestellt) autocreate für diese Messages nicht mehr durchschlagen.

Ergänzend:
- Vermutlich macht es Sinn, den "homeassistant"-Zweig, der jetzt in der readingList auftaucht auch noch mit einer bridgeRegexp in ein eigenes Device zu schicken. Das scheint was separates zu sein...
- Nach meinem persönlichen Geschmacksempfinden würde ich "state"-Anweisungen auch ohne "$name"-Anteil im Topic versenden. Siehe dazu meinen Wiki-stub zu MQTT_GENERIC_BRIDGE. Das wäre dann:
attr hmdevice mqttSubscribe :stopic={"$base/$device"}

Zitat von: Beta-User am 30 Januar 2021, 12:54:42

Wenn ich das richtig deute, wird das Device "hmdevice" aber durchaus geschalten, oder?
Das "Problem" ist nur, dass zusätzlich dieser Eintrag in der readingList erscheint?

Nein, es wird auch nicht geschaltet. Und das verstehe ich nicht, weil dies noch vor wenigen Tagen bei unveränderter Konfiguration funktionierte.
Klar, es erscheint auch in der readingList, aber das wäre erst meine zweite Frage gewesen. :-)

Zitat von: Beta-User am 30 Januar 2021, 12:54:42
Wenn das das Thema ist, kannst du entweder
- meinen "forceNEXT"-Patch testen und ggf. "bewerben" (das verhindert in der Standardeinstellung, dass M2D noch was von messages sieht, die die MGB verwerten kann), oder
- deine bridgeRegexp ergänzen, dass der "fhem/"-Topic-Zweig nach "" umgeleitet wird. Damit würde dann (wie bisher auch schon im Wiki dargestellt) autocreate für diese Messages nicht mehr durchschlagen.

Schaue ich mir an, wenn die Basis wieder funktioniert.

Zitat von: Beta-User am 30 Januar 2021, 12:54:42
Ergänzend:
- Vermutlich macht es Sinn, den "homeassistant"-Zweig, der jetzt in der readingList auftaucht auch noch mit einer bridgeRegexp in ein eigenes Device zu schicken. Das scheint was separates zu sein...

Ich habe in den letzten Tagen bestimmt mehr als 500 MQTT-Devices gelöscht und wieder neu anlegen lassen, weil ich aktuell noch spiele.
Um es später hübsch zu machen, wäre dein Vorschlag in der Tat eine gute Idee. Für Mosquitto habe ich auch bereits ein $SYS-Device angelegt.

Zitat von: Beta-User am 30 Januar 2021, 12:54:42
- Nach meinem persönlichen Geschmacksempfinden würde ich "state"-Anweisungen auch ohne "$name"-Anteil im Topic versenden. Siehe dazu meinen Wiki-stub zu MQTT_GENERIC_BRIDGE. Das wäre dann:

Code Auswählen Erweitern

attr hmdevice mqttSubscribe :stopic={"$base/$device"}

OK

Hmm, für den "Verlust" in der MGB habe ich im Moment keine Erklärung, vorausgesetzt, du hast die letzte Version von M2_CLIENT am Start, wovon ich aber ausgehe, du hast ja die Diskussion hier und anderswo wohl verfolgt.

Aber wenn das M2D beliefert wird, _müßte_ das eigentlich ab dem IO passen, und die Reihenfolge wäre auch (ab der 2. Message) wohl egal...

Vielleicht noch eine Sache. Da das "Klartext" ist, müßte auch die einfachere Variante klappen (die weiteren Einstellungen braucht man wohl auch nicht):
attr mqttGeneric globalDefaults sub:base=fhem/set pub:base=fhem
So stellt es (vom Prinzip her) btw. auch die aktuelle attrTemplate-Version ein. Das mit dem "Einklammern" war nur wegen des $device-Teils erforderlich gewesen, wenn ich's richtig verstanden habe. (Dürfte aber mit dem Problem nichts zu tun haben).

Oh man, ist mir das nun peinlich.
Es funktionieren nur CUL_HM-Geräte nicht.
Die mögen kein :
set hmdevice state on

Nachtrag:
Auch wieder quatsch. Mein stopic sah zuvor wie folgt aus:

attr hmdevice mqttPublish *:topic={"$base/$device/$name"}
attr hmdevice mqttSubscribe :stopic={"$base/$device/$name"}

So geht es:

attr hmdevice mqttPublish *:topic={"$base/$device/$name"}
attr hmdevice mqttSubscribe state:stopic={"$base/$device/$name"}

Keine Ahnung woher die falschen Wert kommen. Obwohl ich alle Geräte gleichermaßen mit den Attributen versorgt habe, fehlen bei alle CUL_HM die richtigen mqttSubscribe-Werte. Die Z-Wave-Geräte sehen korrekt aus. Egal, hauptsache es klappt nun. :-)

Zitat von: Beta-User am 25 Januar 2021, 12:38:29
@hexenmeister:
Falls du dich mit dem Hinweis auf my $foo = $bar if $baz; # UNDEFINED! (https://forum.fhem.de/index.php/topic,117934.0.html) beschäftigen willst: In https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/6fd40496772d7f2d3046c953409698193aadbd23 wäre mein noch nicht intensiv getesteter Versuch zu finden, die betreffenden Stellen auf "offiziell zulässige" Weise zu notieren.

Übernommen. Danke für den Patch!

Zitat von: Beta-User am 28 Januar 2021, 19:56:58
@hexenmeister:
Hab's jetzt alles nochmal zusammengeschoben, patch anbei, jetzt sollten auch die <li>-Elemente in der commandref wieder ausgeglichen sein ::) .
Bei der Gelegenheit: Ist es nach wie vor richtig, dass mqttAlias nur in publish-Richtung funktioniert? (Ist/war mir bisher entgangen...)

Habe auch übernommen, danke für deine Arbeit!

Autsch, habe grade gemerkt, dass da das "-r" noch drin war... :o

Das ist leider ein Fehler, kannst du diese eine Zeile wieder auf den alten Stand bringen, bitte?
2469    $topic ='-r $topic' if $retain;
Sollte wieder diesen Stand haben:
$topic.=':r' if $retain;

Zitat von: Beta-User am 01 Februar 2021, 07:37:59
Autsch, habe grade gemerkt, dass da das "-r" noch drin war... :o

Habe ich doch die Änderung gesehen und mich etwas gewundet, da ich jedoch MQTT2 nicht (produktiv) verwende... Sorry, hätte testen sollen.
Ist wieder zurückgerollt.

Anbei noch weitere Vorschläge zur commandref (DE und EN). Kann sein, dass die Zeilennummern etwas verschoben sind, bitte melden, wenn du die komplette Datei benötigst.

...und noch ein Nachtrag, betreffend "id" statt "name" als Anker und Antw:Online Attributhilfe für ähnliche Attribute duplizieren/übernehmen  (https://forum.fhem.de/index.php/topic,120779.msg1166246.html#msg1166246)(Ich hoffe, mich nirgends verzählt und die Anker alle erwischt zu haben).

Ubernommen. Vielen Dank für die Korrekturen :)