Wie man sich mit userattr ins Knie schießt

[Dr. Boris Neubert]

Hallo,

habe mir gerade ein neues Gerät vom Typ ECMDDevice angelegt, das ein Attribut offset benötigt. Also

Code Auswählen Erweitern

attr global userattr offset

und, paff, alle vorher definierten Benutzerattribute sind weg, inklusive der von FHEMWEB eingebrachten.

Richtig gewesen wäre

Code Auswählen Erweitern

{ addToAttrList("offset") }

Das ist aber nicht dokumentiert und auch nur eingeschränkt anwenderfreundlich.

Gebraucht hätte ich eigentlich

Code Auswählen Erweitern

attr myDevice userattr offset

Habe ich ein dafür vorgesehenes Feature übersehen oder braucht das niemand außer mir?

Viele Grüße
Boris

[betateilchen]

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.

[hexenmeister]

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...

[Dr. Boris Neubert]

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 

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

[hexenmeister]

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.

[Dr. Boris Neubert]

Dann definierst Du die Attribute sogar pro Instanz, richtig?

Genau.

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

[hexenmeister]

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.

[rudolfkoenig]

@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:

Code Auswählen Erweitern

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.

[betateilchen]

@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.

[hexenmeister]

<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...

[Dr. Boris Neubert]

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

[rudolfkoenig]

attr <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.

[betateilchen]

@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.

[betateilchen]

Ok, ich glaub ich habs verstanden 

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.

[Dr. Boris Neubert]

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

[rudolfkoenig]

Auch 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.

[Dr. Boris Neubert]

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

[rudolfkoenig]

Kannst 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.

[Dr. Boris Neubert]

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

[justme1968]

hab es in LightScene nachgezogen.

[rudolfkoenig]

@Boris: habs eingecheckt.

[Dr. Boris Neubert]

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

attr WLog ?

Grüße
Boris

[rudolfkoenig]

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.

[Markus Bloch]

Hallo zusammen,

aktuell kommt beim Start von FHEM bei mir immer:

Code Auswählen Erweitern

Undefined subroutine &main::addToDevAttrList called at /usr/local/FHEM/share/fhem/FHEM/98_structure.pm line 78, <$fh> line 843.


Letzte Zeilen im Log:

Code Auswählen Erweitern

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

[rudolfkoenig]

Bitte fhem.pl auch updaten.

[Markus Bloch]

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

[Dr. Boris Neubert]

Das neue update Modul speichert fhem.pl nun in einem anderen Verzeichnis. Da muss ich wohl einen Symlink setzen.

  Was? Hast Du eine vom Standardlayout abweichende Situation der Dateien?

Viele Grüße
Boris

[Markus Bloch]

Ja, leider. Ich verwende die Synology-NAS-Pakete von Martin Fischer. Dieses erzeugt auf meiner DS413j  folgende Struktur:

Code Auswählen Erweitern



/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

[betateilchen]

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:

Code Auswählen Erweitern


  my $root = $attr{global}{modpath};
...
    return if(!upd_writeFile($root, $restoreDir, $fName, $remFile));


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.

[rudolfkoenig]

Habs gefixed.

[optimizer]

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

[betateilchen]

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.

[optimizer]

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