Modulweite Attribute

[justme1968]

die vielen attribute sind deshalb in fhemweb und nicht in svg damit man sie als default für alle instanzen auf ein mal setzen kann. wenn man sie nach svg schiebt geht das erst mal nicht mehr sondern man muss sie dann für jeden plot immer wieder einzeln setzen.

es wäre also gut wenn es modul weite attribute gäbe. wenn man sauber über attrval zugreift müsste sich das eigentlich auch transparent implementieren lassen. habt ihr einen vorschlag für die syntax ?

eine möglichkeit wäre etwas das so ähnlich ist wie das hier:

Code Auswählen Erweitern

attr TYPE=SVG ...
ähnlich deswegen damit man sich nicht die möglichkeit nimmt attribute per devspec auf mehr als ein device zu setzen.

wie wäre es gleich attribute für 'virtuelle' objekte wie room oder group mit einzubauen?

vielleicht wäre das sogar eine alternative um attribute direkt für den modul start zu setzen um sie im define schon zu haben.

[betateilchen]

die vielen attribute sind deshalb in fhemweb und nicht in svg damit man sie als default für alle instanzen auf ein mal setzen kann.

Das ist mir schon bewusst. Aber genau deshalb sollte man sie besser im define der Web-Instanz mitgeben. Alles was jetzt als Attribut einen "Schalter" in FHEMWEB steuert, sollte auf 1 gesetzt werden, wenn es im define von WEB steht, ansonsten auf 0.

Code Auswählen Erweitern

define WEB FHEMWEB CORS HTTPS SVGcache closeConn endPLotNow endPlotToday fwcompress longpoll longpollSVG plotfork redirectCmds reverseLogs

Denn Attribute von FHEMWEB sind ja keine "lebenden" Attribute wie in anderen Modulen, wo man schonmal zur Laufzeit das eine oder andere Verhalten beeinflussen muss. Das wären schonmal 12 aus 35 weniger. Und meine zwei vorgeschlagenen Attribute würden auch in diese Liste passen und müssten nicht zwingend als zur Laufzeit änderbares Attribut vorhanden sein.

[rudolfkoenig]

@justme1968: diesen Gedanken habe ich auch schon seit langen, und ich finde dein Vorschlag eigentlich gut, hat aber folgende Probleme:
- benoetigt einen separaten Block im FHEMWEB Detail
- XmlList/JsonList muessen angefasst werden.
- fuer umgepflanzte Attribute muss man ein Upgrade-Code in jedem Modul->AttrFn vorsehen


Ich kam gerade auf einen anderen Vorschlag:
- es gibt neben $module->{AttrList} ein neues $module->{ModuleAttrList}
- mit attr/deleteattr kann man beide aendern, Syntax bleibt gleich, "attr devname ?" liefert beide Listen zusammen zurueck.
- Attribute aus ModuleAttrList gelten automatisch fuer alle Instanzen, attr und deleteattr sorgen dafuer, dass diese Werte in jedem $attr{devname} nachgepflegt werden, sobald es bei einem Instanz geaendert wird.
- bei der Abfrage und Save aendert sich nichts, auch FHEMWEB und andere Schnittstellen (XmlList/etc) bleiben gleich, nur in der Doku muss es erwaehnt werden, dass es ein Modulattribut ist.
- Attribute fuer Modul und Instanz muessen unterschiedliche Namen haben.
Eure Meinung dazu?

@betateilchen: bei HTTPS bin ich auch deiner Ansicht, bei den Anderen nicht. Der Syntax-Umbau bei HTTPS ist mir aber z.Zt. nicht Wert.
Weiterhin:
- closeConn sollte default werden, ein bisschen Performanceverlust ist mir lieber, als viele Anfaenger zu aergern.
- longpollSVG sollte entfernt werden (war eher als Experiment gedacht, um Boris zu zeigen, dass es kaputt ist).
- endPlot*, plotfork und SVGcache sollten zu SVG Modulattribute werden.

Das Urspruengliche "mee too" fuer die style-Attribute will ich trotzdem sehen

[justme1968]

- man bräuchte in fhemweb ein (neues) interface. aber es gehört eh nicht auf device ebene sondern es müsste eine detail ansicht auf modul ebene (oder für raum und gruppe) sein. also sowieso etwas neues. das könnte man zusätzlich in der detail ansicht noch einblenden um die defaults auf einen blick zu sehen.

- xmlslist/json list müßten angefasst werden. die module selber aber nicht. bei deinem vorschlag müsste man jedes modul anfassen. siehe unten.

- wenn man in commandDefine nach dem aufruf der DefFn (analog zu den default attributen) die AttrFn für jedes attribut das im modul gesetzt ist aufruft dann sollte es für das modul völlig transparent. ich weiss nur noch nicht wie man damit umgeht das sich der instanz attribut wert natürlich ändern muss wenn der globale wert sich ändert und es in der instanz nicht überschrieben wurde.


das die attribute auf modul und instanz ebene unterschiedlich heissen müssen finde ich nicht gut. vor allem macht das das setzen eines globalen defaults der dann in der instanz überschrieben werden kann unhandlich da man für jedes attribut das so  verwendet werden kann noch ein zweites mit anderem namen im modul braucht. man muss auch jedes modul anfassen damit das geht. und man hat die anzahl der attribute verdoppelt. ich glaube bei deinem vorschlag muss man unterm strich noch mehr code anfassen.


wie wäre es mit einem vorschlag der beides verbindet:

man könnte das eventuell lösen in dem man den namen für das modul attribut automatisch aus dem name des instanz attributs erzeugt und nur intern verwendet. nach aussen ist immer nur der bisherige instanz name sichtbar.

beispiel:

- im modul gibt es ein attribut verbose
- AttrVal schaut automatisch zuerst nach verbose und wenn nicht vorhanden nach <TYPE>:verbose
- zum setzen der modul weiten defaults verwendet man 'attr <TYPE>:verbose 1'
- ein attr <device> ? gibt die bisherige liste aus
- man könnte an unterschiedlichen stellen sogar die defaults automatisch mit ausgeben

[betateilchen]

Mit der configDB funktioniert Andres Vorschlag jetzt schon (fast) out-of-the-box.

Code Auswählen Erweitern



define type.dummy typeattr
attr type.dummy verbose 5



ergibt:

(http://up.picr.de/18115879xn.png)

Nun wird ein neues Device vom Type "dummy" angelegt:

Code Auswählen Erweitern

define mydummy dummy

ergibt:

(http://up.picr.de/18115882ro.png)

Und schon sind die im typeattr festgelegten Attribute im Define übernommen.

Vorteil:

• funktioniert völlig unabhängig von der Ladereihefolge der einzelnen devices beim fhem-Start
• Völlig reguläres Handling für den Anwender, was das Setzen von Attributen angeht.
• Die default-Attribute können in jedem definierten Device geändert werden.
• Im Modul 98_dummy.pm ist nur eine einzige zusätzliche Codezeile in dummy_Define() notwendig:
  cfgDB_AttrTypeSet($name,'type.dummy') if(configDBUsed());

Code Auswählen Erweitern


sub
dummy_Define($$)
{
  my ($hash, $def) = @_;
  my @a = split("[ \t][ \t]*", $def);

  return "Wrong syntax: use define <name> dummy" if(int(@a) != 2);

  my $name = $hash->{NAME};
  cfgDB_AttrTypeSet($name,'type.dummy') if(configDBUsed());

  return undef;
}


Nachteil:

• man sollte sich auf eine Namenskonvention einigen. Wenn das gelingt, kann man die ganze Sache weitgehend komplett automatisieren und nach CommandDefine verlegen.
• funktioniert so bisher nur mit configDB

Ungelöste Fragen:

• Wie kann man ein Device (vom type=typeattr) anlegen, das das Setzen beliebiger Attribute über die reguläre attr Syntax erlaubt? Es gibt ja keine feste AttrList, deshalb wird immer ein "unbekanntes Attribut" angemeckert

Das Modul "typeattr" ist quasi eine Kopie des Moduls dummy, mit dem Unterschied, dass es keine Set-Funktion gibt.

[rudolfkoenig]

vor allem macht das das setzen eines globalen defaults der dann in der instanz überschrieben werden kann unhandlich

Ok, ich ergaenze meinen Vorschlag von vorhin:
- NEU: AttrVal prueft erst "verbose" und falls nicht vorhanden, dann "moduleverbose". Falls der Programmierer also "verbose" als Modul- und als Instanz-Attribut anbieten will, dann wird in $module->{AttrList} verbose und in $module->{ModuleAttrList} moduleverbose eingetragen, abgefragt wird beides mit AttrVal(...,"verbose",...); Mit "module" meine ich diesen String, und nicht ersetzt durch FS20, etc, und dies ist in AttrVal hart kodiert.

Was mir noch unklar ist: sollten alle Attribute automatisch auch als Modulweite-Attribute zur Verfuegung stehen (damit muessen Module nicht geaendert werden,  $module->{ModuleAttrList} entfaellt), oder soll der Modulautor bestimmen, welche das sind (damit ist ein ModuleAttrList notwendig). Und wenn letzteres, soll er auch darueber entscheiden koennen, ob Modulweite Attribute nicht als Instanz Attribute zur Verfuegung stehen, d.h. soll er das Attribut selbst mit "module" Prefixen oder macht das fhem.pl automatisch?

[justme1968]

oder lieber die frage umdrehen: gibt es einen tatsächlichen anwendungsfall bei dem man die modul und instanz attribute trennen muss?

ich bin dafür das automatisch jedes instanz attribut auch modul weit zur verfügung steht. damit sollte die implementierung einfacher werden und man muss kein modul anfassen.

[betateilchen]

ich bin dafür das automatisch jedes instanz attribut auch modul weit zur verfügung steht.

Dagegen! Die beiden Attributlisten sollten m.E. auf beiden Ebenen immer identisch sein. Man vererbt nicht von unten nach oben.

[justme1968]

ich glaube du meinst dafür

mit automatisch meinte ich das die beiden listen identisch sind bzw. das es nur eine liste gibt.