- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#41
FRITZ!Box / Aw: FritzSmart mit Fritz Labor...
Letzter Beitrag von roelleke - 20 September 2026, 12:02:17Hallo,
hier sind die Angaben zu meinem System und der Auszug aus dem LOG.
Ich habe eine Fritzbox 7590 (korrigiert) mit FRITZ!OS: 8.40-136397 BETA zusätzlich sind über LAN noch jeweils ein Repeater 3000ax, 3000, 1200ax und 1200 angeschlossen.
FHEM läuft auf einem Raspberry 4 mit Rasbian Bullseye
Das List des Fritzbox Devices und das LOG sind im Anhang, da sie wohl zu groß ist um eingefügt zu werden.
Die ersten beiden Zeilen des Logs sind mit verbose 2 und der Rest mit verbose 4.
Ich hoffe die Angaben reichen so aus.
hier sind die Angaben zu meinem System und der Auszug aus dem LOG.
Ich habe eine Fritzbox 7590 (korrigiert) mit FRITZ!OS: 8.40-136397 BETA zusätzlich sind über LAN noch jeweils ein Repeater 3000ax, 3000, 1200ax und 1200 angeschlossen.
FHEM läuft auf einem Raspberry 4 mit Rasbian Bullseye
Das List des Fritzbox Devices und das LOG sind im Anhang, da sie wohl zu groß ist um eingefügt zu werden.
Die ersten beiden Zeilen des Logs sind mit verbose 2 und der Rest mit verbose 4.
Ich hoffe die Angaben reichen so aus.
#42
Sonstiges / Aw: [patch] readingsBulkUpdate...
Letzter Beitrag von DS_Starter - 20 September 2026, 11:43:03Einen kleinen Patch für ein potentielles Speicherleck in fhem.pl hätte ich auch noch beizusteuern.
Problem: Der Hash %oldvalue speichert {VAL, TIME} pro Gerätename. Bei CommandRename wird der Eintrag korrekt umgezogen (delete $oldvalue{$old} / $oldvalue{$new} = ..., Zeile 2852–2853). Beim CommandDelete fehlt das Pendant jedoch vollständig – der Eintrag bleibt dauerhaft erhalten.
Auswirkung: In Installationen mit vielen temporären Geräten (z.B. via MQTT2_DEVICE etc.) akkumulieren Einträge ohne Grenze. Jeder Eintrag ist klein (~100 Byte), aber bei tausenden Create/Delete-Zyklen ohne Restart (oder rereadcfg) summiert sich das.
Patch – CommandDelete, Zeile 2400:
Die Änderung wäre absolut minimalistisch.
LG,
Heiko
Problem: Der Hash %oldvalue speichert {VAL, TIME} pro Gerätename. Bei CommandRename wird der Eintrag korrekt umgezogen (delete $oldvalue{$old} / $oldvalue{$new} = ..., Zeile 2852–2853). Beim CommandDelete fehlt das Pendant jedoch vollständig – der Eintrag bleibt dauerhaft erhalten.
Auswirkung: In Installationen mit vielen temporären Geräten (z.B. via MQTT2_DEVICE etc.) akkumulieren Einträge ohne Grenze. Jeder Eintrag ist klein (~100 Byte), aber bei tausenden Create/Delete-Zyklen ohne Restart (oder rereadcfg) summiert sich das.
Patch – CommandDelete, Zeile 2400:
Code Auswählen
...
delete($defs{$sdev});
delete($oldvalue{$sdev}); # NEU
DoTrigger("global", "DELETED $sdev", 1) if(!$temporary);
...
Die Änderung wäre absolut minimalistisch.
LG,
Heiko
#43
TabletUI / Aw: Probleme mit ftui3 seit de...
Letzter Beitrag von HGButte - 20 September 2026, 11:36:20Zitat von: meier81 am 17 September 2026, 21:44:52Hallo setstate,
ich habe leider Probleme mit der Anzeige meiner ftui3 Seite seit dem letzten Update diese Woche.
Nur meine Hauptseite sieht noch "normal" aus, alle weiteren Seiten hängen alle angezeigten Elemente oben links in der Ecke. Ich habe dir mal einen Screenshot angefügt das du siehst was ich meine.
Zudem ist jetzt auch auf der Hauptseite rechts ein ca. 5mm breiter schwarzer Leerraum senkrecht, das Bild wird also nicht mehr vollständig auf die Breite angepasst. Beim refresh kommt dort für ganz kurze Zeit ein Scrollbalken der dann wieder verschwindet und hinterlässt quasi die freie Fläche.
Als Datei habe ich dieCode Auswählenwww/ftui/components/grid/grid.component.jsausgemacht, spiele ich die von vorher wieder ein sieht alles wieder super aus und mit der Änderung verhaut es mir alles von der Anzeige.
Kannst du das bitte nochmal prüfen bzw. mir mitteilen falls etwas zu ändern ist bei mir was ich ändern muss um diesen Fehler zu beheben.
LG und danke dir schonmal.
Markus
Bei mir ist's genauso.
Mit der neuesten Version scheinen das "Resize" nicht mehr zu gehen.
#44
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 20 September 2026, 11:30:29ZitatAuch frage ich mich, ob folgende InfoNein.
NOTIFYDEV GW25,EnO_FSVA_1_M,EnO_FSVA_2_M,WebastoNext,EnO_FMS61NP_KlBadHeiz_Ch1,BydBat1,BydBat2
bedeutet, dass jeglicher Event einer der o.g. Devices zu einer Verarbeitung in SF führt.
Es bedeutet zunächst, dass SF grundsätzlich nur Events der dort angegebenen Devices vom FHEM-Kern durchgereicht bekommt. Es ist ein Filter der die generelle Last im System (durch SF) reduziert. Abhängig davon ob ein Entwickler NOTIFYDEV in seinen Modulen integriert hat, wirst du dieses Internal auch in anderen Devices finden.
Ob ein empfangener Event zu einer Verarbeitung in SF führt, ist von der asynchron-Einstellung des jeweiligen Consumers, Inverters etc. abhängig. Wenn asynchron=1 wird eine SF-Verarbeitung gestartet. asynchron=0 ist der Default.
Mit ctrlDebug=notifyHandling kannst du dir die Eventverarbeitung durch SF ansehen. Weiterhin kannst du dir mit
Code Auswählen
get ... stepTimes ...
einen Überblick über die Verarbeitungsgeschwindigkeit der Bestandteile innerhalb SF verschaffen. #45
Sonstiges / Aw: [patch] readingsBulkUpdate...
Letzter Beitrag von Sidey - 20 September 2026, 11:09:09Guter Fund.
Ich kenne noch eine Stelle, an der regex sehr oft neu compiliert werden müssen.
Und zwar beim Prüfen, welches logische Modul Daten erhält:
Der Wert Match wird im logischen Modul gesetzt, meist ohne die Nutzung von QR sondern rein als String.
Da die obige Prüfung in einer Schleife läuft, wird die regex bei jedem Aufruf neu compiliert. Das müsste aber jeder Maintainer für sein Modul anpassen. Ich werde das mal für meine angehen.
Grüße Sidey
Ich kenne noch eine Stelle, an der regex sehr oft neu compiliert werden müssen.
Und zwar beim Prüfen, welches logische Modul Daten erhält:
Code Auswählen
next if($dmsg !~ m/$modules{$m}{Match}/s);Der Wert Match wird im logischen Modul gesetzt, meist ohne die Nutzung von QR sondern rein als String.
Da die obige Prüfung in einer Schleife läuft, wird die regex bei jedem Aufruf neu compiliert. Das müsste aber jeder Maintainer für sein Modul anpassen. Ich werde das mal für meine angehen.
Grüße Sidey
#46
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Parallix - 20 September 2026, 10:48:14Da mein FHEM auf einem Banana Pro läuft und es gelegentlich bei Modbus-Abfragen zu einem Timeout kommt, versuche ich gerade Problemfälle in Sachen CPU- und Speichernutzung sowie Blockierungen zu identifizieren.
Hierbei ist mir nachfolgendes DEAD aufgefallen:
Auch frage ich mich, ob folgende Info
Hierbei ist mir nachfolgendes DEAD aufgefallen:
Code Auswählen
GMFRUNNING:
abortFn FHEM::SolarForecast::_abortGetMessageFile
bc_pid 30
finishFn FHEM::SolarForecast::_processMessageFile
fn FHEM::SolarForecast::_retrieveMessageFile
loglevel 3
pid DEAD:26054
telnet telnetForBlockingFn_1789889458.07661_127.0.0.1_39932
terminated 1
timeout 30
abortArg:
arg:
block 1
name SF
tsnext 1789896826 Auch frage ich mich, ob folgende Info
Code Auswählen
NOTIFYDEV GW25,EnO_FSVA_1_M,EnO_FSVA_2_M,WebastoNext,EnO_FMS61NP_KlBadHeiz_Ch1,BydBat1,BydBat2bedeutet, dass jeglicher Event einer der o.g. Devices zu einer Verarbeitung in SF führt. Wenn ja, so interessiert mich, ob sich das ändern lässt, ohne das ich in den jeweiligen Devices mittels event-on-... konfiguriere. Gerade was z.B. den Wechselrichter (GW25) angeht, gibt es nämlich eine Vielzahl von Readings, die ich an anderer Stelle benötige, die aber nicht unbedingt zu einem Verarbeitung seitens SF führen (müssen). #47
Solaranlagen / Aw: [36_Senec.pm] FHEM module ...
Letzter Beitrag von curiosus - 20 September 2026, 09:53:42Hallo zusammen,
ich habe die Änderungen der letzten Tage inzwischen noch einmal zusammengeführt und möchte den aktuellen Stand als **36_Senec.pm 2.22.1** zum Testen bereitstellen.
### Was sich in 2.22.1 geändert hat
**SENEC App-/Measurement-API**
* Tages-, Monats-, Jahres- und Gesamtwerte (`*_tag`, `*_monat`, `*_jahr`, `*_total`) an die aktuelle API angepasst
* Berechnung und Aktualisierung der FULL-/Totalwerte korrigiert
* Zeitstempelbehandlung korrigiert, insbesondere UTC → lokale Zeit
* fehlende bzw. leere Tages-Buckets, z. B. rund um Mitternacht, werden abgefangen
* INFO verwendet für die Tageswerte jetzt die aktuellen `*_tag`-Readings
**Performance**
* die alten synchronen `mein-senec`-Statistikabfragen werden nicht mehr automatisch im regelmäßigen API-Poll ausgeführt
* dadurch sollte insbesondere die von Freezemon gemeldete Blockierung von etwa 11–12 Sekunden verschwunden sein
* die alten Funktionen bleiben im Modul erhalten
* bei mir benötigt `periodicCallAPI()` für den synchronen Teil inzwischen nur noch den Bruchteil einer Sekunde; die eigentlichen HTTP-Abfragen laufen anschließend nichtblockierend weiter
* außerdem wurden noch verbliebene Debug-/Log-Ausgaben entfernt
**Wallbox**
* zusätzlich zu den bisherigen Summenwerten gibt es nun Readings für die einzelnen Wallboxen, z. B. `wallbox_1`, `wallbox_1_tag`, `wallbox_1_monat`, `wallbox_1_jahr` und `wallbox_1_total`
* entsprechend auch für `wallbox_2`, `wallbox_3` usw.
* damit lassen sich die Werte der einzelnen Wallboxen beispielsweise direkt in smartVISU verwenden
**Schnellere lokale ENERGY-Werte (`interval_local_energy`)**
Auf Wunsch ist das separate Attribut `interval_local_energy` wieder enthalten.
Das normale Attribut `interval` steuert weiterhin die vollständige lokale Abfrage. Ein sehr kleines `interval` würde deshalb nicht nur die für eine Überschussregelung interessanten Leistungswerte, sondern den kompletten lokalen SENEC-Datensatz entsprechend häufig abfragen.
Mit `interval_local_energy` gibt es dafür wieder einen **eigenen, schnellen lokalen Poll ausschließlich für den ENERGY-Bereich**.
Darüber werden insbesondere die aktuellen lokalen Leistungswerte wie
* PV-Erzeugung (`GUI_INVERTER_POWER`)
* Netzbezug bzw. Netzeinspeisung (`GUI_GRID_POW`)
* Hausverbrauch (`GUI_HOUSE_POW`)
* Batterieleistung, Batteriespannung, Batteriestrom und Ladezustand
aktualisiert.
Damit kann beispielsweise eine externe PV-Überschussregelung wesentlich schneller auf Änderungen von Erzeugung und Einspeisung reagieren, ohne deshalb sämtliche lokalen SENEC-Daten alle paar Sekunden abfragen zu müssen.
Beispiel:
`attr senecAPI interval_local_energy 10`
fragt ausschließlich die lokalen ENERGY-Daten alle 10 Sekunden ab.
`interval_local_energy` ist standardmäßig `0` und damit deaktiviert. Wer das zusätzliche schnelle Intervall nicht benötigt, bekommt also keine weiteren lokalen Abfragen.
Für die Kontrolle des separaten Timers gibt es außerdem das Reading `nextUpdateEnergy`.
**Tests**
Die zuvor beobachtete längere Blockierung durch die alten Statistikabfragen ist bei mir nicht mehr aufgetreten.
Da sich bei SENEC unterschiedliche Anlagen- und Firmwarestände bemerkbar machen können, wäre Feedback von weiteren Installationen durchaus hilfreich.
**Version: 2.22.1**
Viele Grüße
Klaus
ich habe die Änderungen der letzten Tage inzwischen noch einmal zusammengeführt und möchte den aktuellen Stand als **36_Senec.pm 2.22.1** zum Testen bereitstellen.
### Was sich in 2.22.1 geändert hat
**SENEC App-/Measurement-API**
* Tages-, Monats-, Jahres- und Gesamtwerte (`*_tag`, `*_monat`, `*_jahr`, `*_total`) an die aktuelle API angepasst
* Berechnung und Aktualisierung der FULL-/Totalwerte korrigiert
* Zeitstempelbehandlung korrigiert, insbesondere UTC → lokale Zeit
* fehlende bzw. leere Tages-Buckets, z. B. rund um Mitternacht, werden abgefangen
* INFO verwendet für die Tageswerte jetzt die aktuellen `*_tag`-Readings
**Performance**
* die alten synchronen `mein-senec`-Statistikabfragen werden nicht mehr automatisch im regelmäßigen API-Poll ausgeführt
* dadurch sollte insbesondere die von Freezemon gemeldete Blockierung von etwa 11–12 Sekunden verschwunden sein
* die alten Funktionen bleiben im Modul erhalten
* bei mir benötigt `periodicCallAPI()` für den synchronen Teil inzwischen nur noch den Bruchteil einer Sekunde; die eigentlichen HTTP-Abfragen laufen anschließend nichtblockierend weiter
* außerdem wurden noch verbliebene Debug-/Log-Ausgaben entfernt
**Wallbox**
* zusätzlich zu den bisherigen Summenwerten gibt es nun Readings für die einzelnen Wallboxen, z. B. `wallbox_1`, `wallbox_1_tag`, `wallbox_1_monat`, `wallbox_1_jahr` und `wallbox_1_total`
* entsprechend auch für `wallbox_2`, `wallbox_3` usw.
* damit lassen sich die Werte der einzelnen Wallboxen beispielsweise direkt in smartVISU verwenden
**Schnellere lokale ENERGY-Werte (`interval_local_energy`)**
Auf Wunsch ist das separate Attribut `interval_local_energy` wieder enthalten.
Das normale Attribut `interval` steuert weiterhin die vollständige lokale Abfrage. Ein sehr kleines `interval` würde deshalb nicht nur die für eine Überschussregelung interessanten Leistungswerte, sondern den kompletten lokalen SENEC-Datensatz entsprechend häufig abfragen.
Mit `interval_local_energy` gibt es dafür wieder einen **eigenen, schnellen lokalen Poll ausschließlich für den ENERGY-Bereich**.
Darüber werden insbesondere die aktuellen lokalen Leistungswerte wie
* PV-Erzeugung (`GUI_INVERTER_POWER`)
* Netzbezug bzw. Netzeinspeisung (`GUI_GRID_POW`)
* Hausverbrauch (`GUI_HOUSE_POW`)
* Batterieleistung, Batteriespannung, Batteriestrom und Ladezustand
aktualisiert.
Damit kann beispielsweise eine externe PV-Überschussregelung wesentlich schneller auf Änderungen von Erzeugung und Einspeisung reagieren, ohne deshalb sämtliche lokalen SENEC-Daten alle paar Sekunden abfragen zu müssen.
Beispiel:
`attr senecAPI interval_local_energy 10`
fragt ausschließlich die lokalen ENERGY-Daten alle 10 Sekunden ab.
`interval_local_energy` ist standardmäßig `0` und damit deaktiviert. Wer das zusätzliche schnelle Intervall nicht benötigt, bekommt also keine weiteren lokalen Abfragen.
Für die Kontrolle des separaten Timers gibt es außerdem das Reading `nextUpdateEnergy`.
**Tests**
Die zuvor beobachtete längere Blockierung durch die alten Statistikabfragen ist bei mir nicht mehr aufgetreten.
Da sich bei SENEC unterschiedliche Anlagen- und Firmwarestände bemerkbar machen können, wäre Feedback von weiteren Installationen durchaus hilfreich.
**Version: 2.22.1**
Viele Grüße
Klaus
#48
Wunschliste / Aw: Froggit/Ecowitt Wetterstat...
Letzter Beitrag von Beta-User - 20 September 2026, 09:40:54Das sollte nur sagen: Wunschliste ist die falsche Ecke im Forum. Du kannst das selbst verschieben, aber Rudi bekommt dann keinen "Ping", daher wäre die Empfehlung, dort ein neues Thema aufzumachen.
Bitte auch die angepinnten Threads im Anfängerbereich lesen, da stehen einige weitere Informationen wie eben diese mit der Ecke...
Bitte auch die angepinnten Threads im Anfängerbereich lesen, da stehen einige weitere Informationen wie eben diese mit der Ecke...
#49
Wunschliste / Aw: Froggit/Ecowitt Wetterstat...
Letzter Beitrag von Superschlumpf - 20 September 2026, 09:33:30Moin!
Hab mir gestern den SignalDuino mal kurz angeschaut, das scheint ja tatsächlich die Eierlegende Wollmilchsau im Bereich
alles-abgreifen-was-auf-868Mhz-gesendet-wird zu sein.
Und ja, für die HP1000 ist FHEM nur ein weiterer Wetterserver wie Wunderground, Weathercloud und co.
Wobei ich gerade eher zu einem Gateway von Ecowitt tendiere. Ist mir im Moment sympatischer (vielleicht nachher nicht mehr
).
Mit dem Gateway hätte ich im Gegensatz zu meiner HP1000 Station den Vorteil, das die Anbindung über LAN geht, nicht über WLAN. Mein WLAN ist Nachts eigentlich immer abgeschaltet, die Kinder sollen schlafen, und nicht am Handy datteln... (Mobilfunkempfang gibt es in dem Eck hier so gut wie nicht)
Bei deinem Satz
Den Forenbereich habe ich gefunden, aber was soll mir der Anfang sagen, der in der Klammer steht:
"help HP1000" liefert "Module: 50_HP1000.pm...
Und auf jeden Fall sakrischen Dank für deine Unterstützung!
Hab mir gestern den SignalDuino mal kurz angeschaut, das scheint ja tatsächlich die Eierlegende Wollmilchsau im Bereich
alles-abgreifen-was-auf-868Mhz-gesendet-wird zu sein.
Und ja, für die HP1000 ist FHEM nur ein weiterer Wetterserver wie Wunderground, Weathercloud und co.
Wobei ich gerade eher zu einem Gateway von Ecowitt tendiere. Ist mir im Moment sympatischer (vielleicht nachher nicht mehr
).Mit dem Gateway hätte ich im Gegensatz zu meiner HP1000 Station den Vorteil, das die Anbindung über LAN geht, nicht über WLAN. Mein WLAN ist Nachts eigentlich immer abgeschaltet, die Kinder sollen schlafen, und nicht am Handy datteln... (Mobilfunkempfang gibt es in dem Eck hier so gut wie nicht)
Bei deinem Satz
Zitat von: Beta-User am 19 September 2026, 16:09:16("help HP1000" liefert "Module: 50_HP1000.pm Maintainer: rudolfkoenig/orphan Forum: Unterstützende Dienste/Wettermodule")komme ich gerade auf keinen grünen Zweig. Vielleicht bin ich auch gerade einfach zu müde.
Den Forenbereich habe ich gefunden, aber was soll mir der Anfang sagen, der in der Klammer steht:
"help HP1000" liefert "Module: 50_HP1000.pm...
Und auf jeden Fall sakrischen Dank für deine Unterstützung!
#50
Sonstiges / [patch] readingsBulkUpdate: ev...
Letzter Beitrag von snoonsons - 20 September 2026, 09:17:55Hallo,
ein Anwender hat gemeldet, dass FHEM auf seinem Raspi 4 rund 10% CPU zieht, sobald mein Tool (AstraMeter) seine Werte per MQTT schickt:
https://github.com/tomquist/AstraMeter/issues/663
Der Nutzer will eine Möglichkeit haben die Nachrichtenrate zu drosseln. Gemessen sind es 3,7 Nachrichten/s bei knapp 4 KiB/s. Allerdings lassen sich damit die 10% meiner Meinung nach nicht erklären. Also hab ich FHEM mal mit NYTProf profiliert.
Auffällig ist CORE:regcomp mit 378.779 Aufrufen in 60 Sekunden, bei 224 verarbeiteten Nachrichten. Das sind rund 1.500 kompilierte Regexps pro Nachricht.
Der Grund sitzt in readingsBulkUpdate. Die Attributlisten werden mit m/^$l$/ geprüft, und weil der interpolierte Wert bei jedem Eintrag ein anderer ist, kompiliert perl jedes Mal neu, also pro Eintrag pro geschriebenem Reading. Betroffen sind .attreocr, .attreour, .attrminint, .attrtocr, .attraggr und .or.
Der Anwender hat 19 Einträge in event-min-interval. Einmal mit und einmal ohne das Attribut, sonst gleiche Konfiguration und gleiche Last:
ohne event-min-interval 1,478% CPU
mit event-min-interval 2,244% CPU
Das Attribut, das eigentlich Last sparen soll, kostet also gut 50% obendrauf, einfach weil Einträge drinstehen.
Im Anhang ein Patch gegen r31667. Der kompiliert jede Liste einmal und legt sie unter "<attr>.re" im Hash ab, verworfen wird sie, sobald die Liste ersetzt wird oder sich die Länge ändert. An CommandAttr hab ich das bewusst nicht gehängt, weil 44_S7_DRead, 44_S7_DWrite und 44_S7_AWrite .attreocr direkt setzen.
Damit, gleiche Last, viermal abwechselnd gemessen:
ohne Patch 2,271% CPU
mit Patch 1,483% CPU
Die Treffer hab ich gegen die alte Variante verglichen, auch mit Einträgen wie Zaehler.*:60, V[12]_power:1, x.y:60, has:colon, temp:20:linear:avg und oldreadingsAlways, da kommt dasselbe raus. @eocrv behält seine Reihenfolge wegen `$eocrv
Unter Last gefahren hab ich event-on-change-reading, event-on-update-reading und event-min-interval. timestamp-on-change-reading, event-aggregator und oldreadings sind dieselbe Umformung, die hab ich nur isoliert geprüft.
ein Anwender hat gemeldet, dass FHEM auf seinem Raspi 4 rund 10% CPU zieht, sobald mein Tool (AstraMeter) seine Werte per MQTT schickt:
https://github.com/tomquist/AstraMeter/issues/663
Der Nutzer will eine Möglichkeit haben die Nachrichtenrate zu drosseln. Gemessen sind es 3,7 Nachrichten/s bei knapp 4 KiB/s. Allerdings lassen sich damit die 10% meiner Meinung nach nicht erklären. Also hab ich FHEM mal mit NYTProf profiliert.
Auffällig ist CORE:regcomp mit 378.779 Aufrufen in 60 Sekunden, bei 224 verarbeiteten Nachrichten. Das sind rund 1.500 kompilierte Regexps pro Nachricht.
Der Grund sitzt in readingsBulkUpdate. Die Attributlisten werden mit m/^$l$/ geprüft, und weil der interpolierte Wert bei jedem Eintrag ein anderer ist, kompiliert perl jedes Mal neu, also pro Eintrag pro geschriebenem Reading. Betroffen sind .attreocr, .attreour, .attrminint, .attrtocr, .attraggr und .or.
Der Anwender hat 19 Einträge in event-min-interval. Einmal mit und einmal ohne das Attribut, sonst gleiche Konfiguration und gleiche Last:
ohne event-min-interval 1,478% CPU
mit event-min-interval 2,244% CPU
Das Attribut, das eigentlich Last sparen soll, kostet also gut 50% obendrauf, einfach weil Einträge drinstehen.
Im Anhang ein Patch gegen r31667. Der kompiliert jede Liste einmal und legt sie unter "<attr>.re" im Hash ab, verworfen wird sie, sobald die Liste ersetzt wird oder sich die Länge ändert. An CommandAttr hab ich das bewusst nicht gehängt, weil 44_S7_DRead, 44_S7_DWrite und 44_S7_AWrite .attreocr direkt setzen.
Damit, gleiche Last, viermal abwechselnd gemessen:
ohne Patch 2,271% CPU
mit Patch 1,483% CPU
Die Treffer hab ich gegen die alte Variante verglichen, auch mit Einträgen wie Zaehler.*:60, V[12]_power:1, x.y:60, has:colon, temp:20:linear:avg und oldreadingsAlways, da kommt dasselbe raus. @eocrv behält seine Reihenfolge wegen `$eocrv
- ` weiter unten. Im laufenden Betrieb kommen gleich viele Events raus und die Readings sind dieselben.
Unter Last gefahren hab ich event-on-change-reading, event-on-update-reading und event-min-interval. timestamp-on-change-reading, event-aggregator und oldreadings sind dieselbe Umformung, die hab ich nur isoliert geprüft.