Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[Beta-User]

@gvzdus:Danke! Kommt bei Gelegenheit ins Wiki.

@Rudi
Habe jetzt nochmal etwas rumgespielt mit der Frage, wann state und wann irgendein anderes Reading zu aktualisieren wäre.
Da es in diesem Thread auch um die Frage ging, wie man eigentlich zwischen Kommando "Mach irgendwas" und der Rückmeldung "Jawoll, ist durch" unterscheiden kann.

Folgendes scheint zu funktionieren:

Code Auswählen Erweitern

#############################
sub
MQTT2_DEVICE_Set($@)
{
  my ($hash, @a) = @_;
  return "Not enough arguments for set" if(!defined($a[1]));

  my $sl = AttrVal($hash->{NAME}, "setList", "");
  my ($sets,$cmdList) = MQTT2_getCmdHash($sl);
  my $cmdName = $a[1];
  my $cmd = $sets->{$cmdName};
  return SetExtensions($hash, $cmdList, @a) if(!$cmd);
  return undef if(IsDisabled($hash->{NAME}));

  $cmd = MQTT2_buildCmd($hash, \@a, $cmd);
  return if(!$cmd);
  IOWrite($hash, "publish", $cmd);
  if ($sl =~  /\b$cmdName.noArg\b/|| $sl =~ /\b$cmdName \b/) {
    readingsSingleUpdate($hash, "state", "set_".$cmdName, 1);
  } elsif ($sl =~ /\b$cmdName\b/) {
    my $v = shift @a;
    readingsSingleUpdate($hash, $v, "set_".join(" ",@a), 1);
  }
  return undef;
}

Damit wird allem, was in Senderichtung geht, ein "set_" vorangestellt, wobei alles, was nicht mit ":.* (irgendwas außer noArg) in der setList steht als Anweisung verstanden wird,  das betr. Reading zu setzen.

Vielleicht findet das noch jemand schick?

Ich hänge dann mal die vollständige patcherei von heute an.
Enthalten: Shelly1, 2, 4 von miggun von hier, die beiden tasmota_pure-Varianten wie von osr hier gepostet (Achtung: nach wie vor nicht vollständige, brauchen einen gepatchten Tasmota; Anpassungen folgen hoffentlich asap), und eine Korrektur der zigbee2mqtt-Sachen mit der dynamischen Erkennung des Base_Topic.

EDIT: Anhang gelöscht...

[Beta-User]

Nach der aktuellen Rückmeldung von osr noch eine aktualisierte Fassung:

EDIT: Patch wieder gelöscht, da der vorherige schon eingespielt war. Aktualisierung folgt...

[rudolfkoenig]

@supernova1963: ist auf dem "Problemsystem" eine autocreate Instanz konfiguriert?
In der ausgelieferten fhem.cfg gibt es eine Definition mit dem Namen autocreate.

@Beta-User:
Wegen der SetFn Aenderung:
Ich verstehe nicht, warum eine Unterscheidung fuer manche Befehle wichtig ist: "state set_on" meine ich zu verstehen, "brightness set_56" nicht. Ich wuerde eher zwei Readings erstellen wollen: "state set_<cmd>" plus "<cmd> <arguments>"
Ich habe aber mit der Loesung ein grundlegendes Problem: wenn z.Bsp. ein Tasmota das Einschalten per POWER1 meldet, und ich deswegen "attr DEVICE stateFormat POWER1" gesetzt habe, dann wird set_on nie (ueber STATE) angezeigt.  Eigentlich muesste die im SetFn ausgeloeste readingsSingleUpdate die stateFormat Evaluirung deaktivieren.
Wenn ich mich irren sollte, bitte melden.

Ich hänge dann mal die vollständige patcherei von heute an.

Ich habe die Aenderungen ohne tiefergehende Pruefung eingecheckt.
Falls es Dir sinnvoll erscheint, koennen wir gerne die Datei in mehrere aufteilen.
Und wenn du Templates selbst einchecken willst: https://svn.fhem.de/#readwrite

[Beta-User]

Wegen "set_"

Vorab: Ich glaube, ich sollte mal einen ESP mit Tasmota flashen; das kommt mir alles irgendwie von hinten durch's Auge vor, und ich kann schlecht nachvollziehen, um was es dir geht. Das folgende kann also auch ganz falsch sein:
Ist es nicht so, dass stateFormat eigentlich in der Verarbeitungskette erst ganz hinten greift und man daher eher überlegen sollte, ob man nicht von vornherein "state" richtig füllt?

Gedanklich komme ich nicht von einem einfachen Schalter her, sondern von farbigen Lampen. Da ist erst mal wichtig, ob die an oder aus sind. Das gehört m.E. in den state. Erst in zweiter Linie kommt die Frage, wie hell oder bunt es ist (oder sein soll), das darf dann gerne auch in untergeordnete Angaben verschwinden.

Die Unterscheidung, wo was hin soll habe ich einfach aus Dummy geklaut, da wird das genauso gemacht: Alles, was als setList da ist, kann man als Reading (dort aber direkt mit dem Wert) setzen. Der einzige Unterschied jetzt ist, dass das set_ vorangestellt wird. Das kommt aus der HM-Welt; da erscheint set_<value> auch, bis der Befehl wirklich mit ACK beim Gerät angekommen ist (MySensors geht sogar so weit, dass der alte Wert da bleibt, bis ein ACK kommt, wenn das angefordert wird). Für CUL_HM kann ich aber nicht sagen, ob alles erst mal im state landet, der Unterschied besteht m.E. aber darin, dass CUL_HM das soweit überwacht, dass es am Ende wieder paßt (ähnlich für MySensors). Die m.E. einfachste Variante war daher, das in den Readings zu machen, weil der Wert ja bei Rückmeldung des geänderten Status ja dann effektiv wieder überschrieben wird.

Zu svn: Wäre wie gesagt Neuland, bin aber nicht abgeneigt, lass mir etwas Zeit. Ich kann übrigens  die Dinge auch nur auf Plausibilität, eine gewisse Konformität etc. prüfen...

Updates zu dem eingepflegten Stand kommen separat.

[Beta-User]

...und der aktualisierte patch (da waren noch doppelte drin):

EDIT: patch gelöscht, mache das dann (hoffentlich) direkt via svn

[akr1983]

Hiho,

ich find ja toll, dass Ihr so fleißig am Modul arbeitet

Kurz zur Info, seit einem der Updates werden leider immer neue Devices angelegt. Also jedes nur 1x, wenn sich ein Gerät meldet. Reicht aber für zig neue Geräte Ich vermute mal, es liegt am gebastelten Regexp. Ich benutze für meine Devices nämlich "friendlyName" in der Zigbee2mqtt configuration.yaml.

Hier mein mqtt2client device:

Code Auswählen Erweitern



Internals:
   CID        mqtt2client
   DEF        mqtt2client
   DEVICETOPIC MQTT2_mqtt2client
   IODev      mqtt2_client
   LASTInputDev mqtt2_client
   MSGCNT     1773
   NAME       MQTT2_mqtt2client
   NR         227
   STATE      OFF
   TYPE       MQTT2_DEVICE
   mqtt2_client_MSGCNT 1773
   mqtt2_client_TIME 2018-12-13 10:53:18
Attributes:
   IODev      mqtt2_client
   bridgeRegexp zigbee2mqtt/([^:]*):.* "zigbee_$1"
   readingList
   room       MQTT2_DEVICE

Und hier eines der neuen Devices die seit dem Update immer wieder auftauchen:

Code Auswählen Erweitern

Internals:
   CID        zigbee_KiZi_Licht_Kommode/set
   DEF        zigbee_KiZi_Licht_Kommode/set
   DEVICETOPIC MQTT2_zigbee__i_i__icht__ommode_set
   IODev      mqtt2_client
   LASTInputDev mqtt2_client
   MSGCNT     2
   NAME       MQTT2_zigbee__i_i__icht__ommode_set
   NR         290
   STATE      ???
   TYPE       MQTT2_DEVICE
   mqtt2_client_MSGCNT 2
   mqtt2_client_TIME 2018-12-12 20:11:26
   Helper:
     DBLOG:
       set_state:
         DBLogging:
           TIME       1544641886.56514
           VALUE      OFF
   READINGS:
     2018-12-11 15:55:48   set_brightness  15
     2018-12-12 20:11:26   set_state       OFF
Attributes:
   IODev      mqtt2_client
   readingList zigbee2mqtt/KiZi_Licht_Kommode/set:.* { json2nameValue($EVENT, 'set_') }
   room       MQTT2_DEVICE

Liebe Grüße
Arne

[Beta-User]

Yep, das liegt an der bridgeRegexp.
Lösungen friendly_name jeweils anpassen, so dass sich das mit der regex verträgt, oder die regex so ändern, dass nur noch passende friendly_name durchgehen...
Oder autocreate abschalten.

[OdfFhem]

DEF                  zigbee_KiZi_Licht_Kommode/set
DEVICETOPIC MQTT2_zigbee__i_i__icht__ommode_set
NAME              MQTT2_zigbee__i_i__icht__ommode_set

Der verwendete bridgeRegexp sorgt dafür, dass auch die Subtopics des jeweiligen MQTT-Device als Teil des FHEM-Device-Namens übernommen werden.
Abhilfe schafft u.a. der folgende bridgeRegexp

Code Auswählen Erweitern


attr MQTT2_mqtt2client bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"

Hinweis: Hierbei wird auch für die zigbee2mqtt-bridge ein eigenes MQTT2_DEVICE angelegt. Aus meiner Sicht konsequent, aber die Meinungen darüber sind geteilt ...

DEVICETOPIC MQTT2_zigbee__i_i__icht__ommode_set

Der Bug, dass Grossbuchstaben durch _ ersetzt wurden, ist bereits behoben - aktuelles FHEM-Update notwendig.

[Beta-User]

Code Auswählen Erweitern


attr MQTT2_mqtt2client bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"

Hinweis: Hierbei wird auch für die zigbee2mqtt-bridge ein eigenes MQTT2_DEVICE angelegt. Aus meiner Sicht konsequent, aber die Meinungen darüber sind geteilt ...

Danke für den neuerlichen Hinweis. Im Ergebnis würde ich mal folgendes vorschlagen:
- Entweder der alternative Regex-Vorschlag kommt in ein comment-Attribut, oder es gibt die Wahl (und damit eben weitere Unübersichtlichkeit)
- Die Regex für die jetzige "0x"-Befürworter würde ich trotzdem ändern, nämlich das 0x in die Klammer ziehen (statt bisher davor). Führt bei bestehenden Installationen evtl. erst mal dazu, dass nochmal Devices angelegt werden, dafür kann man später wechseln (oder habe ich was übersehen?).

Da die Zahl der templates doch stark zu wachsen scheint, macht es vermutlich Sinn, die irgendwie alphanummerisch sinnvoll vorzusortieren. Richtung wäre:
Anni_name_wie_bisher

A steht für Hauptgruppe (A=>ESP-Derivate, B-M=>Kaufgeräte, die nativ MQTT sprechen, L-Z=>Sonstiger Gruscht, z.B. X90_esp_milight_hub_bridge
nn=zweistellig Dezimal, dabei mit Gruppenbildung (A01-09 für Tasmota, A10-19 Shelly...), das i dann ggf. für eine Variante (2-Kanal mit einem oder zwei Geräten A12a_shelly2_two_devices, A12b_shelly2_single_device)

Damit gäbe es also L01a_zigbee2mqtt_bridge und L01b_zigbee2mqtt_bridge_friendly_name_friendly.

War mal wieder ein Schnellschuß, wer bessere Vorschläge hat: noch ist nichts im svn...

Wird ganz schön schnell voll, der Sa...

[OdfFhem]

@Beta-User

Mittlerweile habe ich auch ein wenig die Template-Möglichkeiten erkundet.

Um nicht unnötig Verwirrung durch unterschiedliche reguläre Ausdrücke zu stiften, habe ich die Ermittlung der beiden Parameter BASE_TOPIC und NAMEINTHEBRIDGE bei mir ein wenig vereinheitlicht; zusätzlich habe ich - um näher am verwendeten Namen in der zigbee2mqtt-Dokumentation zu bleiben - NAMEINTHEBRIDGE in DEV_ID umbenannt (DEVICE_ID geht ja leider nicht).

Vielleicht findet die folgende Anpassung - so oder so ähnlich - Einzug in die Template-Datei ...

Code Auswählen Erweitern


par:BASE_TOPIC;base_topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/](.*):, ? $1 : undef }



Für die Benamung der einzelnen Templates verwende ich derzeit sprechende Namen, da die "verschlüsselten" Namen meist zu technisch sind und dabei insbesondere den "Nicht-Profi" schnell überfordern.

Code Auswählen Erweitern


name:zigbee2mqtt_bridge
name:zigbee2mqtt_xiaomi_cubeController_noprefix
name:zigbee2mqtt_hue_dimmerSwitch_noprefix
name:zigbee2mqtt_hue_motionSensor_noprefix
name:zigbee2mqtt_osram_smartPlug_noprefix
name:zigbee2mqtt_xiaomi_thpSensor_noprefix
name:tasmota_smartPlug_noprefix

Dies folgt weitgehend der Namensgebung in der ausgelieferten Template-Datei. Ich fände es auf jeden Fall gut, wenn die Spezialitäten wie prefix,noprefix,... am Namensende stünden, so dass man die verschiedenen Templates für ein Gerät untereinander findet und nicht an völlig unterschiedlichen Stellen der (hoffentlich stetig wachsenden) Auswahlliste. Desweiteren fände ich es gut, wenn zumindest die größeren Gruppen (zigbee2mqtt,tasmota,shelly,...) in jeweils eigenen Dateien untergebracht wären; "Einzelschicksale" kann man ja dann in einer Sammeldatei aufnehmen.

Da Templates nicht nur für MQTT2_DEVICEs gedacht sind, wird die Zahl der Template-Dateien wohl stetig steigen, so dass man auch dafür eine Namenskonvention bräuchte ...

[Beta-User]

@OdfFhem:
Sieht so aus, als wärst du mir meilenweit voraus, was Regex etc. angeht, ich denke, ich sollte bei dir in die Lehre gehen . Muß mich erst mal auseinandersetzen damit, was das im einzelnen bedeutet, bin eigentlich ziemlicher und bekennender noob...

Schön wäre, wenn man das bridge-Thema in einer für alle passenden Form umsetzen könnte, was eigentlich heißt: Alles, es _sei denn_ (log|state|networkmap/.*|??); das gehört für mich zum eigentlichen Bridge-Device (kein Anlaß, darüber zu streiten, nur mein Gefühl, dass diese Dinge in _ein_ Device gehören). Vielleicht hast du eine Idee dazu (ich habe zwar die Idee, aber regex: s.o....).

Was mehrere Dateien angeht: Finde ich spontan nicht, eine Datei ist zwar scheinbar unübersichtlicher, aber zum einen sollte man das eh' irgendwie gruppieren und am Ende bekommt man als User eh' alles (was zur FILTER-Vorgabe paßt!) in FHEMWEB alphanummerisch (?) sortiert präsentiert => da sollte m.E. die Ordnung herkommen. Das zu verteilen, was eigenlich zusammengehört, macht m.E. nicht sooo viel Sinn (die topic-Struktur ist schon MQTT-spezifisch, der einzige Vorteil wäre die Beispielwirkung (eigene template-Dateien erstellen? - Die Option an sich ist gut und das mache ich grade auch, aber eher für Testzwecke.).

Den _noprefix-Vorschlag finde ich sehr gut (wird zwar der "normale User" erst mal wenig damit anfangen können).

Allerdings schwebt mir im Moment vor, zumindest per #-Kommentar klarer zu machen, welchen Status ein einzelnes tempalate hat (stable/testing/experimental), um z.B. Dinge, die zwar gut, aber noch nicht ausgereift sind unter die Leute zu bringen (das leidige Milight-Thema z.B.). Aber da bin ich auch noch nicht gedanklich so durch, was Sinn macht (wer liest schon Kommentare, und das ggf. auch noch im Quelltext...). Wenn, wäre ein Dialogfeld vorab cool, aber das wäre dann wieder ein feature request, von dem ich (noch) keinen Plan habe, ob er Sinn macht... (im Moment des Schreibens kam mir der Gedanke, das einfach an den Namen ranzuhängen, dann weiß (hoffentlich) jeder, woran er ist...

Gruppierung nach Hersteller: weiß ich im Moment noch nicht. Für zigbee2mqtt vermute ich eher nicht, weil diese erste Anstraktion schon der java-Dienst leistet (so interpretiere ich die eine Meldung, dass die Osram auf Anhieb mit meiner Tradfri-Vorgabe lief), aber für andere Fälle mag das anders sein.
Die bisherige Namensgebung war eher herkunftsorientiert, ob man das so beibehalten sollte oder - jedenfalls für zigbee2mqtt - eher funktionsorientiert benennen? Dann würde aus
zigbee2mqtt_hue_dimmerSwitch_noprefix L_02_zigbee2mqtt_dimmerSwitch_noprefix (ganz ohne hue oder auch mit. Ohne, wenn es eh' gleich wäre (oder dann nur eine interne Weiterleitung auf das andere template?)...
Rückmeldungen erbeten, wir stehen hier nach meinem Eindruck erst am Anfang...
Dafür würde ich aber evtl. nicht diesen Thread verwenden, sondern den mit der template-Funktionalitäts-Ankündigung? Oder ich mach einen gesonderten auf? (Wenn es hier in MQTT diskutiert wird, müssen halt ggf. alle mit dem leben, was wir hier ausarbeiten).

Danke auf jeden Fall für die Ideen und das Mitdenken, wie gesagt, ich bin eigentlich ziemlicher noob in vielen Dingen und auf kritische Rückmeldung angewiesen!

[OdfFhem]

@Beta-User
Bzgl. regulärer Ausdrücke bin ich weit davon entfernt, ein Experte zu sein, aber den hier verwendeten RegExp glaube ich verstanden zu haben. Um Dir unnötige Kopfschmerzen zu ersparen, kann ich "kurz" meine Interpretation darlegen:

• Es geht um ([^/]+)[/].*: für BASE_TOPIC bzw. [^/]+[/](.*): für DEV_ID
• Läßt man die runden Klammerpaare weg, ergibt sich [^/]+[/].*: bzw. [^/]+[/].*: - beide Ausdrücke sind also identisch
• Dieser reduzierte Ausdruck besteht aus vier Teilen: 1 - [^/]+, 2 - [/], 3 - .*, 4 - :
• [^/]+ steht für eine beliebige Anzahl Zeichen, aber zumindest für ein Zeichen; ein vorangestellter / wird für die Verarbeitung ignoriert
• [/] steht für ein einzelnes Zeichen - nämlich /
• .* steht für eine beliebige Anzahl Zeichen
• : steht für ein einzelnes Zeichen - nämlich :

Angewendet auf folgendes Beispiel:

Code Auswählen Erweitern


attr MQTT2_zigbee_cubeController1 readingList zigbee2mqtt/cubeController1:.* { json2nameValue($EVENT) }

ergeben sich dann folgende 4 Teile:

• zigbee2mqtt
• /
• cubeController1
• :

Folgendes Beispiel (mit führendem /) ergibt ein identisches Ergebnis:

Code Auswählen Erweitern


attr MQTT2_zigbee_cubeController1 readingList /zigbee2mqtt/cubeController1:.* { json2nameValue($EVENT) }


Durch die Verwendung der runden Klammerpaare kann man nun festlegen, welche Teile für eine mögliche Weiterverarbeitung bereitgestellt werden:

• ([^/]+)[/].*: stellt den sich aus Teil 1 ergebenden Ausdruck als $1 für die Weiterverarbeitung bereit - also zigbee2mqtt und somit das BASE_TOPIC
• [^/]+[/](.*): stellt den sich aus Teil 3 ergebenden Ausdruck als $1 für die Weiterverarbeitung bereit - also cubeController1 und somit die DEV_ID

Beim zigbee2mqtt/bridge-Thema kann ich noch nicht ganz nachvollziehen, warum man dies in dem allgemeinen MQTT2_DEVICE unterbringen möchte. Für mich ist das eindeutig ein eigenes MQTT2_DEVICE, das einen eigenen Status, eigene Befehle, eigenes Icon, usw. hat. Sollte z.B. in (ferner) Zukunft die Hue-bridge ebenfalls nativ MQTT unterstützen, müsste diese und jede weitere MQTT-bridge ansonsten ja auch in das allgemeine MQTT2_DEVICE, wobei aus meiner Sicht dann die Unübersichtlichkeit vorprogrammiert ist. Aber da es ja über den bridgeRegexp individuell gesteuert werden kann, sehe ich auch in der AllInOne-bridge zunächst einmal kein grundlegendes Problem ... im Zweifel muss man auf friendly_names "verzichten".

Zu klären wäre allerdings noch die Frage, ob immer alle regulären Ausdrücke von bridgeExpr ausgewertet werden, oder ob der erste passende Ausdruck zum Ende der Auswertung führt.
Sollte der zweite Fall zutreffen, könnte man ja - wenn nicht bereits vorhanden - irgendetwas einbauen/festlegen, das dazu führt, dass die MQTT-Meldung via readingList und nicht via nachgelagertem MQTT2_DEVICE weiterverarbeitet wird - analog zu einer nicht passenden MQTT-Meldung ... ein vorgelagerter zigbee2mqtt/bridge-Ausdruck würde in einem solchen Fall dann alle "Probleme" beseitigen.


Mehrere Dateien hatte ich nur im Hinterkopf, da schon die alten Römer das "divide et impera"-Prinzip verfolgten - frei nach dem Motto: was man nicht sieht, kann auch nicht verwirren. Gegenargument könnte natürlich sein: was man nicht findet, kann auch erst gar nicht zur Verwirrung führen. Eine bzw. mehrere Dateien haben wahrscheinlich ihre individuellen Vor- bzw. Nachteile.


Die Idee mit dem Entwicklungsstand finde ich wichtig und würde diesen auch auf jeden Fall in den Template-Namen (vermutlich ans Ende) integrieren. Als Nur-Kommentar im Template-Quellcode geht es wohl unter, denn hier schaut der Normalanwender vermutlich nie rein. Ich würde aber auch nur testing,experimental,usw. gesondert aufführen. stable scheint mir überflüssig, da ich ohne besonderen Hinweis davon ausgehe, dass ein Template einsatzbereit ist.


Bzgl. der Template-Namenskonvention erachte ich es als sinnvoll, das Template möglichst genau zu benennen, so dass der Normalanwender sein Gerät auch tatsächlich findet - und das möglicht einfach und eindeutig. Die Abstraktion - d.h. Rückgriff auf bereits vorhandene Template-Definitionen - würde ich eher in der Template-Datei vornehmen.

Ein gutes Beispiel bzgl. Mehrdeutigkeit sind die beiden Templates tasmota_basic und tasmota_1channel. Hier musste ich erst in die Template-Datei schauen, um festzustellen, welches Template denn nun zu meiner Tasmota-Steckdose passen könnte.
Hinweis: Im tasmota_basic-Template müsste POWER1 noch in POWER umbenannt werden.

[Beta-User]

@OdfFHEM:
Danke für die Erläuterungen.
Detailierte Rückmeldung folgt dann ggf. später, muß ich erst im Detail ansehen, was auf die Schnelle verstanden war: s.u..

@all:
Einen ersten Cleanupversuch und ein gewisses renaming habe ich eben mal durchgespielt und eingecheckt.
War alles etwas sehr auf die Schnelle und gegen die Regel ungetestet.
Da das hier aber nur einen Randbereich betrifft, den man nicht nutzen muss, hoffe ich auf euer Verständnis, gemeldete Probleme bügle ich dann asap wieder aus . Ging v.a. auch darum, dass man "live" darüber diskutieren kann und Neueinsteiger dann nicht hinterher wieder verwirrt sind, weil alles ganz anders heißt.

Schönen Tag und nettes Testen allseits.

[Badflex]

Hallo, nochmal eine Frage zu Tradfri Bulb.
Die Temperaturfarben passen ja sehr gut. Aber was muss ich machen um die Farben der Color Bulbs zu ändern?
Egal welche Farbe ich einstellen, es ist immer hellblau.
Bin aber der Meinung es ging schon mal.
Habe  den atrTemplete colorbulbWithoutColorTemp genommen.

[rudolfkoenig]

wer liest schon Kommentare, und das ggf. auch noch im Quelltext...

AttrTemplate, ab sofort

AttrTemplate wertet jetzt "desc:" Zeilen aus (description), und nimmt, falls kein desc: vorhanden ist, den letzten Kommentar vor name:
Wenn fuer ein Geraet desc: oder Kommentarzeilen vorhanden sind, dann gibt es einen zusaetzlichen attrTemplate ? Befehl, wo diese Daten ausgegeben werden. Fuer FHEMWEB als <li> Aufzaehlung, sonst Newline-getrennt.

Siehe Anhang, mit dem aktuellen Kommentaren.