Wie man sich mit userattr ins Knie schießt

Begonnen von Dr. Boris Neubert, 28 September 2014, 13:46:42

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

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  :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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

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

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

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...
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

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.

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!