Online Attributhilfe für ähnliche Attribute duplizieren/übernehmen

Begonnen von DS_Starter, 01 Mai 2021, 08:03:04

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

Zitat von: rudolfkoenig am 01 Mai 2021, 12:33:51Falls jemand einen Vorschlag hat, wie man vom Attributnamen auch in anderen Faellen zum Hilfstext-ID kommt, bitte melden.
Mich mal meld...
Ich habe mal folgendes Experiment in fhemweb.js eingebaut:

    if(!$(aTag).length) { // old style #2 syntax : webCmd
      var v = (val).replace(/[^a-z0-9_-]/ig,'_');
      aTag = $("#content > #workbench").find("a[name="+v+"]");
    }

// PFE experiments begin
if(!$(aTag).length) {
$("#content > #workbench").find("a[id^='"+mtype+"-"+selType+"-'][data-pattern]").each(
function(index) {
if( val.match($(this).data("pattern")) ) {
aTag = $(this);
return false;
};
return true;
}
);
};
// PFE experiments end


    if($(aTag).length) {
      var liTag = $(aTag).next("li");

...und in meiner Doku steht jetzt folgendes:

<li><a id="FUIP-attr-backend_" data-pattern="backend_.*">backend_.*</a>: Adresse eines (entfernten) Backend-FHEMs<br>

Wenn ich jetzt aus der Liste "backend_home" auswähle, dann kommt diese Doku hoch.
Ich dachte erst, dass das für die Performance ganz schlecht wird, aber es ist gar nicht so schlimm, da sowieso nur die Elemente ausgewählt werden, die auch das "data-pattern" Attribut haben. Das dürfte nicht wirklich schlimm sein.

Was haltet Ihr davon?

Gruß,
   Thorsten

FUIP

DS_Starter

Guten Morgen,

habe heute früh auf allen Instanzen nochmal ein Update vorgenommen und jetzt läuft es ganz hervorragend.  :)
Auch bei Set/Get.
Weiß nicht was da gestern schief gelaufen war.

Nochmals herzlichen Dank Rudi, das ist eine sehr hilfreiche Erweiterung.

LG und einen schönen Sonntag.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

rudolfkoenig

ZitatWas haltet Ihr davon?
Viel, gekauft, ich habe dein Patch etwas vereinfacht eingebaut.

@Heiko: da diese Methode auch das implizite Loeschen der Zahlen am Ende abdeckt, aber transparent ist, habe ich den Hack mit dem Loeschen der Zahlen am Ende entfernt => Es tut mir leid, aber du muss deine Doku mit data-pattern="consumer.*" erweitern :)

Thorsten Pferdekaemper

#18
Hi,
danke für's Einbauen!

Das mit dem "return false" / "return true" war übrigens Absicht und es tut auch was. Zumindest das "return false" sollte bewirken, dass nicht weitergesucht wird, wenn ein Match gefunden wird. Das bringt ein paar Mikrosekunden und sorgt auch dafür, dass der erste Treffer benutzt wird. Bei Dir wird jetzt der letzte Treffer genommen. Das ist meiner Meinung nach nicht ganz so intuitiv.
Momentan ist das vielleicht egal, aber wenn das vielleicht mal ein bisschen mehr benutzt wird, dann wird es schwierig, das noch zu ändern.

EDIT:
Es gibt auch noch die "Kapitel"-Namen in der Doku, also z.B.

   <a name="Helloattr"></a>

Sollte das auch geändert werden in

   <a id"Hello-attr"></a>

?
Analog für define, set, get (etc.?)

Sind die ganzen Sachen eigentlich irgendwo dokumentiert? Hier z.B. sieht es etwas anders aus: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#.22Hello_World.22_Beispiel
und hier steht dazu gar nichts:
https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation


Gruß,
   Thorsten
FUIP

rudolfkoenig

Das Optimieren habe ich auch ueberlegt, und habe die Microsekunden fuer die etwas bessere Lesbarkeit geopfert.
Falls mehrere data-patterns fuer ein Attribut zutreffen, dann tut mir das nur ein ganz ganz bisschen Leid.

ZitatSollte das auch geändert werden in
Ja, die Ursache bzw. Beschreibung ist hier https://forum.fhem.de/index.php/topic,118915.msg1135123.html#msg1135123
Ich habe in den MQTT2* Modulen damit angefangen, und habe vor meine anderen Module bei Gelegenheit auch nachzuziehen.

DS_Starter

ZitatEs tut mir leid, aber du muss deine Doku mit data-pattern="consumer.*" erweitern

Kein Problem  :) ... habs angepasst und funktioniert.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Thorsten Pferdekaemper

Zitat von: rudolfkoenig am 02 Mai 2021, 11:39:02
Das Optimieren habe ich auch ueberlegt, und habe die Microsekunden fuer die etwas bessere Lesbarkeit geopfert.
Falls mehrere data-patterns fuer ein Attribut zutreffen, dann tut mir das nur ein ganz ganz bisschen Leid.
Das ist auch ok für mich.

Zitat
Ja, die Ursache bzw. Beschreibung ist hier https://forum.fhem.de/index.php/topic,118915.msg1135123.html#msg1135123
Ich habe in den MQTT2* Modulen damit angefangen, und habe vor meine anderen Module bei Gelegenheit auch nachzuziehen.
Mal sehen, vielleicht habe ich die Muße, das irgendwo im Wiki aufzuschreiben.

Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
ich habe mich jetzt nochmal damit befasst, nicht zuletzt wegen der Doku. Dabei sind mir noch folgende Sachen aufgefallen:

Anzeige mehrerer Hilfetexte, wenn's mal nicht ganz so schnell geht
Wenn das Laden des ersten Hilfetextes etwas dauert (kann bei großen Modulen schnell mal passieren), dann klicke ich manchmal schon auf das nächste Attribut. Das Ergebnis sieht dann so aus, wie im Screenshot "DoppelteDoku".
Die zweite Doku geht erst weg, wenn man die ganze Seite aktualisiert. (Wenn man schnell klickt, kann man auch mehr als zwei hinbekommen.)
Das Problem liegt daran, dass das Laden der Doku asynchron passiert und man währenddessen ein anderes Attribut wählen kann. Das Löschen der "alten" Doku wird aber am Anfang synchron gemacht.
Lösen lässt sich das so:

      if(!$(liTag).length)
        liTag = $(aTag).parent().next("li");
      if($(liTag).length) {
// PFE experiments begin
$("#devSpecHelp").remove();
// PFE experiments end
        $(sel).closest("div[cmd='"+selType+"']")
           .after('<div class="makeTable" id="devSpecHelp"></div>')
        $("#devSpecHelp").html($(liTag).html());
      }
    }
    wb.remove();

...wobei ich mir nicht 100% sicher bin, ob die Callbacks immer in der richtigen Reihenfolge kommen. Soweit ich es ausprobiert habe hat es immer gepasst.

Device specific help geht manchmal nicht auf
Ich hatte mich schon lange gewundert, warum die "Device specific help" manchmal erst beim zweiten Klick aufgeht. Das passiert dann, wenn man vorher schon eine Set-/Get- oder Attribut-Hilfe offen hat. Dann geht beim ersten Klick die offene Hilfe zu und erst der zweite Klick öffnet die richtige Hilfe.
Das kann man auch relativ einfach wegbekommen:

  $("div.devSpecHelp a").each(function(){       // Help on detail window
    var dev = FW_getLink(this).split("#").pop();
    $(this).unbind("click");
    $(this).attr("href", "#"); // Desktop: show underlined Text
    $(this).removeAttr("onclick");

    $(this).click(function(evt){
  // PFE experiments begin
          if($("#content > #devSpecHelp").length) {
  // if($("#devSpecHelp").length) {
  // PFE experiments end  
  $("#devSpecHelp").remove();
  return;
      }
  // PFE experiments begin
  $("#devSpecHelp").remove();
  // PFE experiments end  
      FW_getHelp(dev, function(data){
        $("#content").append('<div id="devSpecHelp"></div>');
        $("#devSpecHelp").html(data);
        var off = $("#devSpecHelp").position().top-20;
        $('body, html').animate({scrollTop:off}, 500);
      });
    });
  });

Dadurch bleibt die vorherige Funktionalität erhalten (d.h. man kann die "Device specific help" auch wieder zumachen), aber eben nur auf die "Device specific help" bezogen.

Attribut-Hilfe erscheint nicht, wenn man das Attribut über den Link auswählt
Bisher erscheint die Attribut-Hilfe nur, wenn man das Attribut über die Drop-Down-Liste auswählt. Das mache ich praktisch nie, wenn das Attribut schon gesetzt ist.
Man kann das auch relativ einfach ändern:

  $("table.attributes tr div.dname")    // Click on attribute fills input value
    .each(function(){
      $(this)
        .html('<a>'+$(this).html()+'</a>')
        .css({cursor:"pointer"})
        .click(function(){
          var attrName = $(this).text();
          var sel = "#sel_attr"+$(this).attr("data-name").replace(/\./g,'_');
          if($(sel+" option[value='"+attrName+"']").length == 0)
            $(sel).append('<option value="'+attrName+'">'+attrName+'</option>');
          $(sel).val(attrName);
          FW_detailSelect(sel, true);
    // PFE experiments begin
  $(sel).trigger("change");
          // PFE experiments end  
        });
    });

Man könnte sich auch auf den Standpunkt stellen, dass man das Attribut ja schon kennt, wenn man es mal gesetzt hat. Komischerweise ist das bei mir oft nicht so. Außerdem schreiben einige Module Vorbelegungen explizit in die Attribute rein, wodurch die Attribute auch schon da sind, bevor man sie als Benutzer angefasst hat.

Gruß,
   Thorsten


FUIP

rudolfkoenig

ZitatAnzeige mehrerer Hilfetexte, wenn's mal nicht ganz so schnell geht
Die Ursache liegt vmtl. nicht in der grossen Doku, sondern im langsamen (weil blockierten) FHEM.
Ich habe die Aenderung uebernommen.

ZitatDevice specific help geht manchmal nicht auf
Da war eigentlich Absicht, damit man die Hilfe entfernen kann. Mit der Aenderung hat man zwei identische IDs im Dokument, was nicht der reinen Lehre entspricht, und erfordert, dass Ueberall die lange Identifikation (#content>#devSpecHelp, usw) verwendet wird. Ich habe die Aenderung erstmal nicht eingebaut.

ZitatAttribut-Hilfe erscheint nicht, wenn man das Attribut über den Link auswählt
Das habe ich urspruenglich aus genau dem erwaehnten Gruenden nicht eingebaut, wollte "alte Benutzer" nicht aergern.
Bin aber nicht mehr sicher, dass meine Grunde valide sind, und habe die Aenderung uebernommen.

Thorsten Pferdekaemper

Hi,
danke für's Übernehmen!

Zitat von: rudolfkoenig am 04 Mai 2021, 10:09:47
Da war eigentlich Absicht, damit man die Hilfe entfernen kann. Mit der Aenderung hat man zwei identische IDs im Dokument, was nicht der reinen Lehre entspricht, und erfordert, dass Ueberall die lange Identifikation (#content>#devSpecHelp, usw) verwendet wird. Ich habe die Aenderung erstmal nicht eingebaut.
Die identischen #devSpecHelp waren vorher schon da. Meine Änderung bedeutet nur, dass beim Klick auf den Link nur geprüft wird, ob "#content>#devSpecHelp" offen ist und nicht irgendein #devSpecHelp.
Mit meiner Änderung kann man die Set/Get/Attribut-Hilfe tatsächlich nicht mehr entfernen. Ich hätte aber auch nicht vermutet, dass man durch einen Klick auf "Device specific help" die Attribut-Hilfe wegbekommt. Ich selbst weiß das jetzt alles und habe kein persönliches Problem damit. Ich hatte halt eher einen Bug dahinter vermutet als Absicht.
Schöner wäre es meiner Meinung nach, wenn es direkt bei der Set/Get/Attribut-Hilfe ein Knöpchen gäbe, um die Doku zu schließen. Ich kann ja mal was dazu ausprobieren.

Gruß,
   Thorsten
FUIP

Beta-User

Hätte dazu auch noch zwei Fragen:

Zum einen gibt es in RandomTimer mit onCmd bzw. offCmd zwei Attribute, die fast dasselbe machen. Eigentlich wollte ich schlicht denselben Text verwenden, aber das klappt nicht, dass das auch bei onCmd erscheint:
<li><a id="RandomTimer-attr-offCmd" data-pattern="RandomTimer-attr-o.*Cmd"></a>
        <code>onCmd, offCmd</code><br>
        Setting the on-/offCmd changes the command sent to the device. Default <code>onCmd</code> is <code>set &lt;device&gt; on</code>. The device can be specified by a @.<br>
        <br>
        <b>Examples</b>

Falls jemand eine Idee hat, wie man solche "mittige Variablenfälle" abfangen kann, oder ist hier dann nur das Anzeigen eines Querverweises die passende Lösung? Meine diversen Experimente (nur mit a id="RandomTimer-attr-o"), um direkt den vollen (einmaligen) Text anzuzeigen waren leider nicht erfolgreich.

Zum anderen gibt es Module, die globale Attribute bereitstellen, deren "Präfix" aber vom User geändert werden kann (konkret: RHASSPY, aber MQTT_GENERIC_BRIDGE macht das z.B. genauso). Falls jemand eine Idee hat, wie es ggf. gehen kann, "fremden Modulen" die eigenen (flexibel zu benennenden) Attribute beizubringen, würde ich das zumindest in RHASSPY einbauen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatEigentlich wollte ich schlicht denselben Text verwenden, aber das klappt nicht, dass das auch bei onCmd erscheint:
Das funktioniert mit data-pattern="o.*Cmd" (gerade getestet).
Wichtig: das ID der ersten <a> in der Hilfe dient als Modulbezeichner, d.h. die Hilfe sollte mit <a id="RandomTimer"></a> anfangen.

ZitatZum anderen gibt es Module, die globale Attribute bereitstellen, deren "Präfix" aber vom User geändert werden kann (konkret: RHASSPY, aber MQTT_GENERIC_BRIDGE macht das z.B. genauso).
Um das zu wissen, muss FHEM wissen, wer dieses Attribut spendiert hat.

Ich habe jetzt addToDevAttrList und addToAttrList mit einem optionalen $module Parameter erweitert, damit kann man die Quelle spezifizieren.

Damit erscheinen in der Liste die FHEMWEB Attribute im FHEMWEB-Abschnitt (und nicht mehr unter "global userattr") und die Modul eigenen Attribute unter dem Abschnitt mit dem Modulnamen (nicht mehr "Module").
Letzteres kann man als Nachteil empfinden, weil damit die Modulattribute je nach Modulnamen ganz nach unten rutschen koennen.

Beta-User

Zitat von: rudolfkoenig am 09 Juli 2021, 19:38:02
Das funktioniert mit data-pattern="o.*Cmd" (gerade getestet).
Wichtig: das ID der ersten <a> in der Hilfe dient als Modulbezeichner, d.h. die Hilfe sollte mit <a id="RandomTimer"></a> anfangen.
Ups, manchmal ist es "so einfach" ::) ...

Die Änderung in RandomTimer habe ich eben eingecheckt, ganz lieben Dank!

"<a id= ..." war da schon eine ganze Zeit drin, insgesamt muss ich sagen, dass das eine klasse Sache ist! Bestes Erlebnis damit: Vor einiger Zeit hatte ich das auch bei den MySensors-Modulen eingeführt, allerdings erst mal rudimentär mit wenigen id's nachgezogen, und dann anlässlich eines kleineren Problems ergänzt. Reaktion des testenden Users:
Zitat von: uwetaz am 12 Mai 2021, 20:08:27
PS1: Dass bei den Drop Downs jetzt Hilfen angezeigt werden ist prima. [...]

Zitat
Um das zu wissen, muss FHEM wissen, wer dieses Attribut spendiert hat.

Ich habe jetzt addToDevAttrList und addToAttrList mit einem optionalen $module Parameter erweitert, damit kann man die Quelle spezifizieren.

Damit erscheinen in der Liste die FHEMWEB Attribute im FHEMWEB-Abschnitt (und nicht mehr unter "global userattr") und die Modul eigenen Attribute unter dem Abschnitt mit dem Modulnamen (nicht mehr "Module").
Letzteres kann man als Nachteil empfinden, weil damit die Modulattribute je nach Modulnamen ganz nach unten rutschen koennen.
Auch hier erst mal ein Danke! Zumindest in der Theorie hört sich das mit der Gruppierung für mich nicht nach einem (großen) Nachteil an. Der einzige Haken scheint mir zu sein, dass die Liste/das dropdown damit ggf. noch länger wird. Dafür weiß man aber, wo was hingehört und kann auch leichter wieder aufräumen, wenn ein Modul "seine" Attribute nicht selbst wieder löscht (was ja durchaus sinnvoll sein kann).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: rudolfkoenig am 09 Juli 2021, 19:38:02
Damit erscheinen in der Liste die FHEMWEB Attribute im FHEMWEB-Abschnitt (und nicht mehr unter "global userattr") und die Modul eigenen Attribute unter dem Abschnitt mit dem Modulnamen (nicht mehr "Module").
Letzteres kann man als Nachteil empfinden, weil damit die Modulattribute je nach Modulnamen ganz nach unten rutschen koennen.
Fyi: Hab's jetzt mal bei RHASSPY und MGB ergänzt (Patch für hexenmeister folgt) und finde es sehr hilfreich, dass man jetzt (Modulunterstützung vorausgesetzt) sehen kann, was woher kommt und wie ggf. der erwartete Inhalt in dem Attribut in etwa aussieht! Grade bei diesen "querliegenden Devices" ist es sehr viel einfacher, sich (als User) zu orientieren.

Zitat von: Thorsten Pferdekaemper am 02 Mai 2021, 11:07:44
Sind die ganzen Sachen eigentlich irgendwo dokumentiert? Hier z.B. sieht es etwas anders aus: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#.22Hello_World.22_Beispiel
und hier steht dazu gar nichts:
https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation
Habe die zwei Stellen mal ergänzt, wobei das Hello_World-Beispiel eigentlich mal getestet werden sollte. Hatte bei den Modulen, die ich bisher in die Richtung geändert habe hin und wieder das Problem, dass manche Formatierungen dann dazu geführt haben, dass die Querbeziehungen nicht mehr passten (ein <p> an der falschen Stelle, und es kommt nichts mehr...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 12 Juli 2021, 14:25:17
Patch für hexenmeister [...]
wäre hier zu finden: https://forum.fhem.de/index.php/topic,117737.msg1166261.html#msg1166261.

Diesen patch mal anzusehen ist evtl. auch für die interessant, die ggf. wissen wollen, wie "schwierig" eine Komplettumstellung einer cref auf den aktuellen Stand ggf. ist. Da ist "alles" drin:
- Allg. die Umstellung auf "id" statt "name" und Ergänzung mit ein paar weiteren Sektionen (in DE und EN...), ich hatte wie geschrieben ein paar kleinere Probleme, bis der Text jeweils wirklich sichtbar war, v.a. bis klar war, dass <p> (an der falschen Stelle gesetzt) teils Schwierigkeiten machen und nichts in die id-Anker-Klammer reingeschrieben werden darf;
- Erweiterung der Attributliste für alle "überwachten Geräte" (nicht via global, das macht der RHASSPY-diff, s.u.);
- "negative lookbehind": es gibt Attribute am "Zentralgerät", die mit "data-part=".*Attr" ' matchen würden, aber eine etwas andere Beschreibung haben...

Und hier noch das RHASSPY-diff betr. v.a. die "normalen" Attribute, die das in  global schiebt (das war vorher schon auf "id"-Stand). Das nur, damit man ggf. Anschauungsmaterial hat, wie es funktioniert:
diff --git a/10_RHASSPY.pm b/10_RHASSPY.pm
index 3b672a3..ea0e8ee 100644
--- a/10_RHASSPY.pm
+++ b/10_RHASSPY.pm
@@ -432,13 +432,13 @@ sub initialize_prefix {

     return if defined $old_prefix && $prefix eq $old_prefix;
     # provide attributes "rhasspyName" etc. for all devices
-    addToAttrList("${prefix}Name");
-    addToAttrList("${prefix}Room");
-    addToAttrList("${prefix}Mapping:textField-long");
+    addToAttrList("${prefix}Name",'RHASSPY');
+    addToAttrList("${prefix}Room",'RHASSPY');
+    addToAttrList("${prefix}Mapping:textField-long",'RHASSPY');
     #addToAttrList("${prefix}Channels:textField-long");
     #addToAttrList("${prefix}Colors:textField-long");
-    addToAttrList("${prefix}Group:textField");
-    addToAttrList("${prefix}Specials:textField-long");
+    addToAttrList("${prefix}Group:textField",'RHASSPY');
+    addToAttrList("${prefix}Specials:textField-long",'RHASSPY');

     return if !$init_done || !defined $old_prefix;
     my @devs = devspec2array("$hash->{devspec}");
@@ -4736,25 +4736,25 @@ Each of the keywords found in these attributes will be sent by <a href="#RHASSPY

<ul>
   <li>
-    <a id="RHASSPY-attr-rhasspyName"></a><b>rhasspyName</b>
+    <a id="RHASSPY-attr-rhasspyName" data-pattern=".*Name"></a><b>rhasspyName</b>
     <p>Comma-separated "labels" for the device as used when speaking a voice-command. They will be used as keywords by Rhasspy. May contain space or mutated vovels.</p>
     <p>Example:<br>
     <code>attr m2_wz_08_sw rhasspyName kitchen lamp,ceiling lamp,workspace,whatever</code></p>
   </li>
   <li>
-    <a id="RHASSPY-attr-rhasspyRoom"></a><b>rhasspyRoom</b>
+    <a id="RHASSPY-attr-rhasspyRoom" data-pattern=".*Room"></a><b>rhasspyRoom</b>
     <p>Comma-separated "labels" for the "rooms" the device is located in. Recommended to be unique.</p>
     <p>Example:<br>
     <code>attr m2_wz_08_sw rhasspyRoom living room</code></p>
   </li>
   <li>
-    <a id="RHASSPY-attr-rhasspyGroup"></a><b>rhasspyGroup</b>
+    <a id="RHASSPY-attr-rhasspyGroup" data-pattern=".*Group"></a><b>rhasspyGroup</b>
     <p>Comma-separated "labels" for the "groups" the device is in. Recommended to be unique.</p>
     <p>Example:
     <code>attr m2_wz_08_sw rhasspyGroup lights</code></p>
   </li>
   <li>
-    <a id="RHASSPY-attr-Mapping"></a><b>rhasspyMapping</b>
+    <a id="RHASSPY-attr-Mapping" data-pattern=".*Mapping"></a><b>rhasspyMapping</b>
     <p>If automatic detection (gDT) does not work or is not desired, this is the place to tell RHASSPY how your device can be controlled.</p>
     <p>Example:</p>
     <p><code>attr lamp rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off,response="All right"<br>
@@ -4765,7 +4765,7 @@ GetState:response=The temperature in the kitchen is at [lamp:temperature] degree
MediaControls:cmdPlay=play,cmdPause=pause,cmdStop=stop,cmdBack=previous,cmdFwd=next</code></p>
   </li>
   <li>
-    <a id="RHASSPY-attr-rhasspyChannels"></a><b>rhasspyChannels</b>
+    <a id="RHASSPY-attr-rhasspyChannels" data-pattern=".*Channels"></a><b>rhasspyChannels</b>
     <p>Used to change the channels of a tv, set light-scenes, etc.<br>
     <i>key=value</i> line by line arguments mapping command strings to fhem- or Perl commands.</p>
     <p>Example:</p>
@@ -4776,7 +4776,7 @@ orf drei=channel 203<br>
     <p>Note: This attribute is not added to global attribute list by default. Add it using userattr or by editing the global userattr attribute.</p>
   </li>
   <li>
-    <a id="RHASSPY-attr-rhasspyColors"></a><b>rhasspyColors</b>
+    <a id="RHASSPY-attr-rhasspyColors" data-pattern=".*Colors"></a><b>rhasspyColors</b>
     <p>Used to change to colors of a light<br>
     <i>key=value</i> line by line arguments mapping keys to setter strings on the same device.</p>
     <p>Example:</p>
@@ -4787,7 +4787,7 @@ yellow=rgb FFFF00</code></p>
     <p>Note: This attribute is not added to global attribute list by default. Add it using userattr or by editing the global userattr attribute. You may consider using <a href="#RHASSPY-attr-rhasspySpecials">rhasspySpecials</a> (<i>colorCommandMap</i> and/or <i>colorForceHue2rgb</i>) instead.</p>
   </li>
   <li>
-    <a id="RHASSPY-attr-rhasspySpecials"></a><b>rhasspySpecials</b>
+    <a id="RHASSPY-attr-rhasspySpecials" data-pattern=".*Specials"></a><b>rhasspySpecials</b>
     <p>Currently some colour light options besides group and venetian blind related stuff is implemented, this could be the place to hold additional options, e.g. for confirmation requests. You may use several of the following lines.</p>
     <p><i>key:value</i> line by line arguments similar to <a href="#RHASSPY-attr-rhasspyTweaks">rhasspyTweaks</a>.</p>
     <ul>
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files