Hallo,
habe mir gerade ein neues Gerät vom Typ ECMDDevice angelegt, das ein Attribut offset benötigt. Also
attr global userattr offset
und, paff, alle vorher definierten Benutzerattribute sind weg, inklusive der von FHEMWEB eingebrachten.
Richtig gewesen wäre
{ addToAttrList("offset") }
Das ist aber nicht dokumentiert und auch nur eingeschränkt anwenderfreundlich.
Gebraucht hätte ich eigentlich
attr myDevice userattr offset
Habe ich ein dafür vorgesehenes Feature übersehen oder braucht das niemand außer mir?
Viele Grüße
Boris
Du bist nicht allein...
Das ist doch genau der Krampf bei diesen userattr: Jedes userattr, das irgendein Modul hinzufügt, taucht ab sofort in allen Devices auf, egal ob das sinnvoll ist oder nicht. Selbst bei irgendwelchen dummies habe ich inzwischen sinnloserweise sämtliche von structures angelegten userattr zur Auswahl, die Dropdown-Liste der wählbaren Attribute ist inzwischen unüberschaubar und in keiner Weise dem jeweiligen Device zuordenbar (Welches Attriubut macht bei welchem Device Sinn?).
Die Frage, ob man die Attribute irgendwann mal modulspezifisch verwaltet und nicht mehr nur global, wurde vor einigen Monaten schonmal hier diskutiert.
http://forum.fhem.de/index.php/topic,23816.0.html
Leider ist diese Diskussion, wie viele andere entwicklungstechnischen Grundsatzdiskussionen hier im Dev-Bereich auch, einfach im Sande verlaufen.
Ich wäre auch dafür, die Attribute pro Device(Klasse) definieren zu können. Evtl. wäre ein gangbarer Kompromis, wenn man die Definition etwas erweitert. Wie jetzt definiert sollen die Attribute für alle Devices gelten, oder eben mit userattr <deviceType>:<attrName> nur für die bestimmten. Ist wohl leider mit einigen Umstellungen an etlichen Modulen verbunden...
Habe mir gerade die Diskussion angesehen, auf die Udo verweist, und den Code angeguckt.
attr global userattr bla ist ja zunächst mal nur in FHEM das Äquivalent von use strict in Perl :P
Es sollte m.E. nur verwendet werden, wenn man ein neues Attribut an allen Geräten haben möchte, wie es bei FHEMWEB sinnvoll und nötig ist (sortby, icon, ...).
Man muss doch nur in fhem.pl in CommandAttr() auf das Attribut userattr reagieren (analog wie auf userReadings, IODev und stateFormat) und in getAllAttr() zusätzlich die gerätespezifischen Attribute zurückliefern.
Grüße
Boris
Dann definierst Du die Attribute sogar pro Instanz, richtig? Und wenn man pro Klasse haben will? Wäre eher nützlich...
Ansonsten ist die Idee gut, denn damit kann man die Module-Anpassungen vermeiden.
Zitat von: hexenmeister am 28 September 2014, 14:29:20
Dann definierst Du die Attribute sogar pro Instanz, richtig?
Genau.
Zitat
Und wenn man pro Klasse haben will? Wäre eher nützlich...
Darüber habe ich nachgedacht und mir ist kein Fall eingefallen, wo der Benutzer für alle Geräte einer Geräteklasse dasselbe zusätzliche Attribut haben will. Beispiele?
Im übrigen ginge das m.E. mit der von Dir vorgeschlagenen Syntax attr global userattr <deviceType>:<attrName> und ein bisschen mehr Programmieraufwand ebenfalls.
Grüße
Boris
Beipiel? Ich habe da so ein Control-Attribut, der für alle Rolladen gilt (gelten soll). Dort speichere ich Zeit und Wert bei jeder automatischen Änderung. Damit will ich manuelle Änderungen erkennen und verhindern, dass das System von mir gerade geöffnete Rolladen wieder runterfährt, da es z.B. nach seiner Meinung schon dunkel gunug ist ;)
Man kann das auch pro Instanz machen, ist aber ein overhead.
Dennoch unterstützte ich Dein Vorschlag uneingeschränkt. Evtl. wäre auch mein Vorschlag als zusätzliche Feature vorzuschlagen.
@Boris:
dass attr nicht den Wert erweitert sondern ersetzt, sollte eigentlich klar sein, und im FHEMWEB in der Detail-Ansicht von global kann man bei einer Aenderung es auch einfach erweitern. Ich sehe hier keinen Handlungsbedarf.
@betateilchen:
dass structure komisch geloest ist, streite ich gar nicht ab, das ist aber nicht das Problem von userattr sondern structure.
Beim durchsuchen fand ich folgende komische Zeile:
configDB.pm: _cfgDB_InsertLine($fhem_dbh, $uuid, 'attr global userattr devStateIcon devStateStyle icon sortby webCmd',3);
ich meine das kann so nicht richtig sein.
<deviceType>:<attrName> sehe ich nicht sehr nuetzlich, viel eher ein <deviceNameRegexp>:<attrName>
Da es mir nicht einfaellt, wie man das effizient in userattr einbauen koennte, wuerde ich eine devicenameattr vorschlagen, was seltener verwendet wird. Soweit ich sehe, muss nur getAllAttr modifiziert werden.
Zitat von: rudolfkoenig am 29 September 2014, 12:17:26
@betateilchen:
Beim durchsuchen fand ich folgende komische Zeile:
...
ich meine das kann so nicht richtig sein.
Doch. Und es hat mit dem hier beschriebenen Problem nichts zu tun.
Zitat<deviceType>:<attrName> sehe ich nicht sehr nuetzlich, viel eher ein <deviceNameRegexp>:<attrName>
Ich habe schon angenommen, dass RegExp unterstützt werden, allerdings bin ich schon von dem 'Type' ausgegangen. Mit dem 'Namen' ist man natürlich flexiebler. Typ-weite Zuweisung wäre in machen Situationen jedoch auch ganz nützlich...
Zitat von: rudolfkoenig am 29 September 2014, 12:17:26
dass attr nicht den Wert erweitert sondern ersetzt, sollte eigentlich klar sein, und im FHEMWEB in der Detail-Ansicht von global kann man bei einer Aenderung es auch einfach erweitern. Ich sehe hier keinen Handlungsbedarf.
Dass attr den Wert ersetzt, war mir klar. Allerdings stand mir in dem Moment, als ich das in die fhem.cfg und auf die Kommandozeile geschrieben hatte, nicht vor Augen, dass vor mir schon klammheimlich meine FHEMWEB-Instanzen userattr gesetzt hatten.
Ich habe eine modulare fhem.cfg, bestehend aus einem Master und vielen sachgebietsspezifischen Includes. Ein userattr am Device sorgt für eine Kapselung, bei der niemand Nebeneffekte beachten muss, die man leicht vergisst.
Meiner Meinung nach tun
attr <devicespec> userattr bla
attr global userattr [<classspec>:]bla
<devicespec> wie gehabt Name eines Gerätes, Regex, TYPE=... etc. <classspec> Name einer Klasse oder Regex.
zusammen alle Anwendungsfälle abdecken, die hier diskutiert wurden.
Mit "effizient umsetzen" meinst Du, in getAllAttr() ohne exzessives Pattern Matching auskommen müssen?
Viele Grüße
Boris
Zitatattr <devicespec> userattr bla
Das habe ich implementiert und eingecheckt.
Nachteil: alle Geraete haben jetzt einen zusaetzliches Attribut (userattr).
@betateilchen: beim auslesen der Attribute muss "attr devicename userattr" als erstes ausgewertet werden.
Ich habe das fuer fhem.cfg so geloest, dass beim Speichern userattr als erstes gespeichert wird.
Zitat von: rudolfkoenig am 29 September 2014, 21:54:31
@betateilchen: beim auslesen der Attribute muss "attr devicename userattr" als erstes ausgewertet werden.
Ich habe das fuer fhem.cfg so geloest, dass beim Speichern userattr als erstes gespeichert wird.
Darum kann ich mich erst nach meinem Urlaub (also frühestens übernächstes Wochenende) kümmern.
Hoffentlich habe ich bis dahin verstanden, was Du mir damit eigentlich sagen willst.
Ok, ich glaub ich habs verstanden 8)
Aber an "meinem" beschriebenen Problem ändert sich dadurch ja erstmal nichts. Kannst Du als Modulverantwortlicher das Modul 98_structure bei Gelegenheit so anpassen, dass es seine Attributorgie ab sofort auf sich selbst beschränkt?
Mir ist grade nicht bekannt, welche Module sonst noch globale userattr setzen, die nicht wirklich sinnvoll sind. (gabs sowas nicht auch beim Floorplan?)
Bei DbLogExclude finde ich das globale userattr beispielsweise völlig ok.
Zitat von: rudolfkoenig am 29 September 2014, 21:54:31
attr <devicespec> userattr bla
Das habe ich implementiert und eingecheckt.
Danke, Rudi, ich habe es heute getestet und es tut für meine Zwecke was es soll.
Ich tue mich schwer mit der Dokumentation. Das Attribut ist nur bei global beschrieben und auch die anderen Attribute, die es für alle Geräte gibt, sind nicht offensichtlich. Auch ist nicht offensichtlich, dass einzelne Devices weitere globale Attribute hinzufügen können.
Ist es gewünscht, dass ich einen Patch für die Dokumentation sende?
Grüße
Boris
ZitatAuch ist nicht offensichtlich, dass einzelne Devices weitere globale Attribute hinzufügen können.
Entweder habe ich diesen Satz nicht verstanden, oder ich habe was unbeabsichtigtes implementiert. Kannst Du es bitte anders formulieren?
Wenn du ein Doku-Patch schickst, dann baue ich das ein.
Zitat von: rudolfkoenig am 03 Oktober 2014, 09:08:28
Entweder habe ich diesen Satz nicht verstanden, oder ich habe was unbeabsichtigtes implementiert. Kannst Du es bitte anders formulieren?
Ich meine damit, dass der Leser aus der Dokumentation nicht erkennen kann, dass die an allen Devices vorhandenen Attribute noch davon abhängen, ob er Geräte definiert hat, die über die standardmäßig vorgegebenen Attribute hinaus neue Attribute für alle Geräte definieren.
Die Implementierung ist in Ordnung.
Ich schreibe mal was dazu auf.
Viele Grüße
Boris
ZitatKannst Du als Modulverantwortlicher das Modul 98_structure bei Gelegenheit so anpassen, dass es seine Attributorgie ab sofort auf sich selbst beschränkt?
Habe 98_structure.pm so umgebaut, dass die 3 Attribute nur bei betroffenen Geraeten hinzugefuegt werden.
Die globalen Attribute koennen _nach_ einem Neustart entfernt werden.
Habe es mit fhem.cfg.demo getestet, waere aber fuer ausfuehrlichere Tests dankbar.
In fhem.pl gibt es jetzt auch ein addToDevAttrList, ich meine 31_LightScene.pm koennte davon auch profitieren.
Zitat von: rudolfkoenig am 03 Oktober 2014, 09:08:28
Wenn du ein Doku-Patch schickst, dann baue ich das ein.
Anbei die Rahmen für die Commandref (volle Datei, kein Patch). Nachdem ich meinen inneren Schweinehund niedergekämpft habe, sogar mit deutscher Übersetzung.
M.E. können die Beschreibungen von IODev und eventMap bei FS20 gelöscht werden und stattdessen ein Verweis auf #IODev und #eventMap angebracht werden.
Viele Grüße
Boris
hab es in LightScene nachgezogen.
@Boris: habs eingecheckt.
Zitat von: rudolfkoenig am 03 Oktober 2014, 12:57:10
In fhem.pl gibt es jetzt auch ein addToDevAttrList.
Ist beim Einbau etwas schief gegangen? Die globalen Attribute, die FHEMWEB einbringt, sind weg. Stattdessen ist eine 1 in der Attributeliste.
Nachstellbar z.B. mit dieser Konfiguration:
attr global statefile /path/to/fhem.save
attr global verbose 5
attr global port 7072 global
attr global modpath /path/to/fhem
define MyLog FileLog /path/to/my.log .*
define ui FHEMWEB 8083 global
attr ui stylesheetPrefix dark
attr ui room UI
define W Weather 2122541 1800 de
define WLog FileLog /users/neubert/Development/Perl/fhem-data/W.log W:T:.*
und
attr WLog ?Grüße
Boris
Danke fuer den Hinweis, habs gefixed, und etwas laenger getestet, jetzt scheint es zu funktionieren.
Damit moeglichst wenig Leute ihren Config zerschiessen, habe ich es fuer update zur Verfuegung gestellt.
Hallo zusammen,
aktuell kommt beim Start von FHEM bei mir immer:
Undefined subroutine &main::addToDevAttrList called at /usr/local/FHEM/share/fhem/FHEM/98_structure.pm line 78, <$fh> line 843.
Letzte Zeilen im Log:
2014.10.09 20:22:28.890 5: Cmd: >define Gesamtes_Wohnzimmer_Licht structure Wohnzimmer LED_Kueche Licht_Wohnzimmer Licht_Kueche LED_Serienregal LED_Filmeregal LED_TV_Board<
2014.10.09 20:22:28.891 5: Loading /usr/local/FHEM/share/fhem/FHEM/98_structure.pm
Dannach stürzt FHEM mit der oben genannten Meldung ab.
Heute update gemacht und nun startet FHEM nicht mehr.
Gruß
Markus
Bitte fhem.pl auch updaten.
Hmm, stimmt.
Das neue update Modul speichert fhem.pl nun in einem anderen Verzeichnis. Da muss ich wohl einen Symlink setzen.
Vielen Dank
Gruß
Markus
Zitat von: Markus Bloch am 09 Oktober 2014, 21:12:29
Das neue update Modul speichert fhem.pl nun in einem anderen Verzeichnis. Da muss ich wohl einen Symlink setzen.
:o Was? Hast Du eine vom Standardlayout abweichende Situation der Dateien?
Viele Grüße
Boris
Ja, leider. Ich verwende die Synology-NAS-Pakete von Martin Fischer. Dieses erzeugt auf meiner DS413j folgende Struktur:
/usr/local/FHEM/app/scripts/fhem.sh
/usr/local/FHEM/bin/fhem.pl (alt)
/usr/local/FHEM/share/fhem/fhem.pl (neu)
/usr/local/FHEM/etc/fhem.cfg
/usr/local/FHEM/share/fhem/FHEM/00_CUL.pm
/usr/local/FHEM/share/fhem/FHEM/00_FBAHA.pm
/usr/local/FHEM/share/fhem/FHEM/00_FHZ.pm
/usr/local/FHEM/share/fhem/FHEM/00_MAXLAN.pm
/usr/local/FHEM/share/fhem/FHEM/00_OWX.pm
/usr/local/FHEM/share/fhem/FHEM/00_ZWDongle.pm
/usr/local/FHEM/share/fhem/FHEM/02_RSS.pm
/usr/local/FHEM/share/fhem/FHEM/10_CUL_HM.pm
.....
/usr/local/FHEM/share/fhem/www/ ....
/usr/local/FHEM/var/log/*.log
Das alte update Modul hat fhem.pl an der alten, ursprünglichen Stelle immer brav aktualisiert. Nun allerdings wird fhem.pl unter /usr/local/FHEM/share/fhem/fhem.pl abgelegt.
Gruß
Markus
Zitat von: Markus Bloch am 09 Oktober 2014, 22:05:26
Das alte update Modul hat fhem.pl an der alten, ursprünglichen Stelle immer brav aktualisiert. Nun allerdings wird fhem.pl unter /usr/local/FHEM/share/fhem/fhem.pl abgelegt.
Das neue update Modul verwendet den modpath für die Zielbestimmung:
my $root = $attr{global}{modpath};
...
return if(!upd_writeFile($root, $restoreDir, $fName, $remFile));
Zitat von: Markus Bloch am 09 Oktober 2014, 21:12:29
Da muss ich wohl einen Symlink setzen.
Ich denke, damit schaffst Du in diesem speziellen Fall, wo die fhem.pl komplett ausserhalb der fhem-Struktur liegt, die einfachste Lösung.
Habs gefixed.
Hi,
was ist die einfachste Möglichkeit den Gerätenamen im _initialize für addToDevAttrList ($devname, $newattr) herauszufinden - mit $devname = $hash->{NAME} gehts nicht?
Gruß
optimizer
Was hast Du vor?
Es macht eigentlich keinen Sinn, bereits im Initialize irgendwas auf device-Ebene auszuführen.
Initialize wird nur ein einziges Mal pro Modul aufgerufen. Define aber für jedes Device dieses Typs. Und in Define findest Du den Namen problemlos.
Ich wollte im Modul bestimmte Attribute (Modulspezifisch) in der Liste anzeigen. Jetzt habe ich es im Define untergebracht - auch wenn es nicht Geräteabhängig ist.
Gruß
optimizer