readingsGroup erzeugt viele Events

[fruemmel]

Hallo,

mir ist bei der testweisen Entwicklung eines Moduls aufgefallen, dass meine readingsGroups, die perfekt zur optisch kompakten Darstellung einiger Readings genutzt werden können, selbst viele Events auslösen wenn sich Werte ändern.

Kann man das unterdrücken? Die Attribute event-on-change-reading oder event-on-update-reading sind anscheinend bei einer ReadingsGroup nicht verfügbar.

Gruß Wolfgang

[justme1968]

die readingsGroup muss events auslösen weil sonst der longpoll update im browser nicht geht. es sollte aber pro 'quell' event nur ein einziges event der readingsGroup erzeugt werden. wenn es mehr sind oder mehrere gleiche dann gibt es hier einen fehler.

die readingGroup erzeugt diese events aber nur wenn sie gerade in einem browserfenster angezeigt wird. sonst nicht. falls hier etwas nicht stimmt ist es ein fehler. achtung: der eventMonitor zählt hier mit. das lässt sich besser per inform in einem telnet fenster prüfen.

event-on-.* musst du im jeweiligen quell device passend setzen.

wenn es dir nur um die anzeige geht und longpoll updates nicht wichtig sind dann kannst du disable auf 1 setzen.

es gibt inzwischen einen fhem internen mechanismus damit die events zum aktualisieren der readingGroup nicht mehr im event monitor sichtbar sind und auch notifys nicht mehr möglich sind. das muss ich aber erst noch einbauen.

gibt es ein konkretes problem mit den events ?

gruss
  andre

[fruemmel]

Hallo Andre,

ich hatte zum Test eine NotifyFn in einem Modul angelegt und ausgewertet, von welchem device wieviel Events generiert werden. Dabei vielen zwei readingsGroups auf, die vergleichsweise viele Events erzeugt haben. Es wird ja öfters erwähnt, dass events eine relevante Systemlast erzeugen. Da hin und wieder mein Banana eine Denkpause einlegt und eine ReadingsGroup bei apptime auffiel, habe ich das mal etwas genauer betrachtet.

Bei mir kommen die Events teilweise auch ohne dass die readingsGroup im Browser offen ist, evtl. schlummern aber Anzeigen auf dem iPhone. Dort macht ein Aufruf über webApp-Icon anscheinend eine neue Browser-Instanz auf und kommuniziert evtl. auch im standby des iPhones noch.

Kurzum: da ich die Events der readingsGroup nicht benötige, wollte ich diese abstellen. Nach Blick in den Code habe ich jetzt zum Test "alwaysTrigger" auf 0 gesetzt. Longpoll geht noch, allerdings kommen auch immer noch events (obwohl das laut Code für mich nicht nachvollziehbar ist). Allerdings scheinen es jetzt weniger Events zu sein.

//EDIT: Kleine Korrektur: auch mit alwaysTrigger = 0 scheinen noch genausoviele Events zu kommen.

[justme1968]

der default für allwaysTrigger ist sowieso 0. wenn du es auf 1 setzt würden auch events kommen wenn die readingGroup nicht sichtbar ist.

wenn du gar keine events willst kannst du wie oben geschrieben disable auf 1 setzen.

ob events systemlast erzeugen hängt zum grossen tail auch von den notifys ab die dahinter hängen. es macht z.b. einen unterschied on die notifys auf jeweils genau ein device gehen oder einfach alles abgreifen. es sollten aber niemals mehrfach gleiche events erzeugt werden wenn die event-on attribute passend gesetzt sind.

es kann manchmal noch ein kleine weile dauern bis fhem bemerkt das dieses fenster wirklich weg ist.



gruss
  andre

[fruemmel]

Ich habe gerade noch einmal geforscht: Ich habe tatsächlich den Effekt, dass bei einer Aktualisierung der ReeadingsGroup einige Events öfters wiederholt werden:

Code Auswählen Erweitern

Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.Body--Data--PAC--Values--1: <div st
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.akt_verbrauch: <div style="width:15
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.Body--Data--PAC--Values--1: <div st
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.akt_bilanz: <div style="width:150px
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.akt_verbrauch: <div style="width:15
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.Body--Data--PAC--Values--1: <div st
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.akt_bilanz: <div style="width:150px
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.akt_verbrauch: <div style="width:15
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.Body--Data--PAC--Values--1: <div st
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.akt_bilanz: <div style="width:150px
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.akt_verbrauch: <div style="width:15
Fri Oct  2 12:48:31 2015: Event rgKurzInfo : Symo.Body--Data--PAC--Values--1: <div st


Die Readings-Inhalte sind in meinem Log bewusst abgeschnitten, da sich dahinter html-Balken mit Farbverläufen verbergen, die das Log aufblähen würden. Das dargestellte Log ist aus meinem o. g. Testmodul.
Es geht noch ein Stück so weiter, d. h. die events tauchen jedesmal bis zu 10 Mal auf.
Macht es Sinn hier nochmal nachzuforschen?

[frank]

Es geht noch ein Stück so weiter, d. h. die events tauchen jedesmal bis zu 10 Mal auf.
Macht es Sinn hier nochmal nachzuforschen?

da bin ich ja doch nicht alleine. http://forum.fhem.de/index.php/topic,40635.0.html
mit einer älteren version funktioniert es bei mir.

[justme1968]

@frank: ich bin schon die ganze zeit dran dein problem nachzustellen. habe es aber noch nicht geschafft.

@fruemmel: die readingGroup sollte nur ein event pro quell event erzeugen. wenn es bei dir so viele sind stimmt etwas nicht.

ich würde dem problem gerne auf den grund gehen.

wenn einer von euch das ganze mit ein paar dummys reproduzieren kann wäre das klasse. eventuell muss man mit readingsBeginUpdate/readingsBulkUpdate/readingsEndUpdate auf einen schlag mehrere readings im dummy updaten.

wenn es mit deinem testmodul reproduzierbar ist würde das auch helfen.

gruss
  andre

[fruemmel]

Ich bin am Wochenende unterwegs, spätestens Montag kümmere ich mich um Tests.

[fruemmel]

@fruemmel: die readingGroup sollte nur ein event pro quell event erzeugen. wenn es bei dir so viele sind stimmt etwas nicht.

ich würde dem problem gerne auf den grund gehen.

wenn einer von euch das ganze mit ein paar dummys reproduzieren kann wäre das klasse. eventuell muss man mit readingsBeginUpdate/readingsBulkUpdate/readingsEndUpdate auf einen schlag mehrere readings im dummy updaten.

wenn es mit deinem testmodul reproduzierbar ist würde das auch helfen.

Hallo Andre,
ich denke ich bin durch Tests ein wichtiges Stück weiter. Ich habe ein Testmodul geschrieben, dass mit readingsBulkUpdate mehrere Readings in einem Schwung aktualisiert. Alle Readings (im Test bis zu drei Readings) habe ich in einer readingsGroup zusammengefasst.

Ergebnis: Wenn man nur ein Reading updatet, kommt auch von der RG nur ein Event. Wenn man zwei Readings in einem BulkUpdate verändert, kommen von der RG für das erste Reading zwei Events und für das zweite Reading ein Event. Wenn man drei Readings auf einmal verändert kommen von der RG ... für das erste Reading 3 Events, für das zweite noch 2 Events, und für das letzte ein Event. Das schaukelt sich also hoch, wenn man in einer Readingsgroup mehrere Readings verwendet, die aus einem Gerät kommen.

Ich hoffe, dass Du damit auch die Ursache des Problems finden kannst. Auf jeden Fall schonmal vielen Dank für Deinen Einsatz.
Gruß Wolfgang

PS: Hier noch ein Log-Ausschnitt, daran kannst Du die Reihenfolge der von der RG erzeugten Events sehen.

Code Auswählen Erweitern

Sun Oct  4 17:33:57 2015: Event 0 rgET: et.testReading1: 1443972837.71542
Sun Oct  4 17:33:57 2015: Event 0 rgET: et.testReading1: 1443972837.71542
Sun Oct  4 17:33:57 2015: Event 0 rgET: et.testReading2: 1443972837.71542
Sun Oct  4 17:33:57 2015: Event 0 rgET: et.testReading3: 1443972837.71542
Sun Oct  4 17:33:57 2015: Event 0 rgET: et.testReading1: 1443972837.71542
Sun Oct  4 17:33:57 2015: Event 0 rgET: et.testReading2: 1443972837.71542


[justme1968]

ich denke ich habe das problem gefunden.

es war eine geschweifte klammer an eine falsche stelle gerutscht. dadurch wurden bei jedem neuen event alle alten noch mal gefeuert.

mein vi hat es nicht richtig angezeigt weil an einer anderen stelle eine geschweifte klammer in einer regex nicht maskiert war und so die zuordnung klammerpaare nicht mehr gestimmt hat...

gruss
  andre

[fruemmel]

ich denke ich habe das problem gefunden.

Ja das Problem scheint beseitigt zu sein. Jetzt kommen nur noch die zu erwartenden Events. Vielen Dank!