Readings und Attribute mit dem selben Namen und Fhemweb

Begonnen von StefanStrobel, 11 Januar 2018, 19:57:03

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo,

Bei ArduCounter ist aufgefallen, dass es zu interessanten Effekten kommt, wenn ein Modul zulässt, dass ein Reading den selben Namen wie ein Attribut verwendet.
In diesem Fall aktualisiert Fhemweb bei einer Änderung des Reading-Werts auch die Darstellung des Attributs. Beim erneuten Laden der Seite ist alles wieder ok, aber sobald sich das Reading wieder ändert, steht der Wert auch beim Attribut.
siehe https://forum.fhem.de/index.php/topic,19285.270.html (Post 271)
Ich habe das mit HTTPMOD nachgestellt. Dort kann der Anwender die Namen der Readings per Attribut einstellen. Das Verhalten ist identisch.
Sollten die Modulautoren prüfen, dass Readings nicht den gleichen Namen wie wie ein Attribut haben dürfen?

Gruss / Thanx
   Stefan

Damian

Zitat von: StefanStrobel am 11 Januar 2018, 19:57:03
Hallo,

Bei ArduCounter ist aufgefallen, dass es zu interessanten Effekten kommt, wenn ein Modul zulässt, dass ein Reading den selben Namen wie ein Attribut verwendet.
In diesem Fall aktualisiert Fhemweb bei einer Änderung des Reading-Werts auch die Darstellung des Attributs. Beim erneuten Laden der Seite ist alles wieder ok, aber sobald sich das Reading wieder ändert, steht der Wert auch beim Attribut.
siehe https://forum.fhem.de/index.php/topic,19285.270.html (Post 271)
Ich habe das mit HTTPMOD nachgestellt. Dort kann der Anwender die Namen der Readings per Attribut einstellen. Das Verhalten ist identisch.
Sollten die Modulautoren prüfen, dass Readings nicht den gleichen Namen wie wie ein Attribut haben dürfen?

Gruss / Thanx
   Stefan

Ich würde es als Bug bezeichnen, das passiert insb. auch bei DOIF-Modulen, da sie das Attribut State haben. Die Konvention, dass ein Attribut nicht den gleichen Namen haben darf, ist mir nicht bekannt.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

herrmannj

witzig, bin da vor wenigen Tagen auch drüber gestolpert aber aus einer anderen Richtung. Mir ist aufgefallen das fhemweb versucht auf $hash->{ROOM} zu zugreifen. Das scheint das gleiche Thema zu sein allerdings hab ich das verdrängt.

In fhemweb suche ich nur sehr ungern ... Aber ich kann das abfangen und einen stacktrace machen. Ich schieb ma in developer wenn keine Einwände kommen.

herrmannj

#3
das ist der stacktrace der dazu führt das auf $hash->{room} zugegriffen wird (anstelle des attributes room)
main::devspec2array('room!=.+') called at FHEM/01_FHEMWEB.pm line 608
main::FW_initInform('HASH(0x9545108)', 1) called at FHEM/01_FHEMWEB.pm line 852
main::FW_answerCall('/fhem?XHR=1&inform=type=status;filter=room=Unsorted;since=1515701692;fmt=JSON&fw_id=32×tamp=1515701694260') called at FHEM/01_FHEMWEB.pm line 549
main::FW_Read('HASH(0x9545108)') called at fhem.pl line 3500
main::CallFn('WEB_127.0.0.1_51196', 'ReadFn', 'HASH(0x9545108)') called at fhem.pl line 702


allerdings bekomme ich den nicht sicher reproduziert.

Ich habe einen dummy (name dummy) angelegt, setlist on off gesetzt und geschaltet, bin zwischen detail und übersicht gesprungen und finde den stacktrace für alle definiertern device. Irgendwo innerhalb der beschriebenen Schritte passiert es, danach löst scheinbar weder die Detailseite noch das schalten des dummy das erneut aus.

Mal hoffen dass das a) was mit dem zu tun hat und b) Rudi mit dem stacktrace sofort die Ursache erkennt.

update:
Der Aufruf von 'devspec2array('room!=.+')' führt sicher zum Aufruf von $hash->{room} auf allen device (hash). Da sich mir der Syntax dieser Funktion allerdings noch nie erschlossen hat vermag ich nicht zu sagen ob das nun bug, feature oder nur Teil der Landschaft ist.. :)

update2:
das ist ein stacktrace meiner test umgebung, die ist Stand Dezember (stacktrace, line#)

rudolfkoenig

Ich brauche kein Stacktrace:
- die Wert-Spalte der Readings und der Attribute ist jeweils mit dem html-Attribut informid="geraetename-attribut/readingname" versehen.
- sowohl bei Reading-Aenderung, wie auch bei Attribut-Aenderung sendet FHEMWEB per longpoll [geraetename-attribut/readingname, wert, <html-fuer-die-darstellung>]
- fhemweb sucht nach allen Elementen mit dem passenden informid-Attribut, und ersetzt den Inhalt.

Um das Problem zu loesen, koennte man FHEMWEB.pm so anpassen, dass Attribute einen zusaetzlichen Tag im informid enthalten.
Ist eigentlich ein Bug in FHEMWEB, aber Attribute mit dem gleichen Namen wie Readings anzubieten verwirrt meiner Ansicht den Anwender, bzw. man muss immer Attribut oder Reading dazusagen, was bei einer besseren Namenswahl nicht erforderlich ist.
So eine Verwirrung gibt es jetzt schon bei state und STATE, und da ist die Schreibweise eigentlich unterschiedlich.

justme1968

die informId der attribute eindeutig zu machen ist trozdem eine gute idee.

wie wäre es mit einem a- am anfang? ist zwar immer noch nicht 100% windeutig, aber ziemlich sicher ohne konflikte rückwärtskompatibel.

auch wenn gleich lautende namen meist keine gute idee sind haben wir die explizite unterscheidung zwischen internal, reading und attribut haben wir ja auch in der devspec und bei list mit :i,:r und :a.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Habs eingebaut, hoffentlich ohne Nebeneffekte.
Einer dieser Faelle, die leichter ausschauen, als sie dann sind.