Größe Systemvariable

[fairtv]

Ich finde es in Doku und Forum nicht, oder mir fallen die richtigen Suchbegriffe nicht ein:
Weiß jemand die Größen (Byte, Zeichen, ...), die eine Systemvariable (je nach Typ) maximal verkraftet?
Insbesondere Werteliste und Zeichenkette?

[alchy]

Zeichenkette mit ca. 650000 Zeichen funktionierte mal (sofern ich mich an meinen Test richtig erinnere)
Auch mehr ist vielleicht möglich, hab ich aber damals irgendwann abgebrochen.
Den Grund weiß ich aber nicht mehr, wahrscheinlich war dann irgendwann Schluss.

Selber probieren und Ergebnis mitteilen? Warum willst du das wissen?

Alchy

[fairtv]

Ich möchte gerne Wertepaare von Sensoren über einen mittleren Zeitraum sammeln und selbst filtern.
Teilweise könnte das wohl auch der CuXD (zumindest Median und Mean), ich möchte aber noch andere FIlter und alternative Zeiträume versuchen.

Außerdem möchte ich auch größere Sammlungen an Werten aus dem Kraftwerk übertragen, grob auswerten und dann verwenden.

Danke für die Auskunft, 650k sollten schon mal eine Ecke weit genügen.

[Familienvater]

Hi,

da sollte ggf. noch mal JMaus was dazu sagen, ob das zu einem Problem werden kann.

Ich sehe da prinzipiell die folgenden Probleme, abseits eines schnellen Tests im realen Betrieb:

1. Der Speicher müsste zunehmend fragmentieren, wenn dynamisch Speicher neu alloziert werden muss, "abwechselnd" für mehrere stetig wachsende "Arrays", ich weiß nicht, ob es soetwas wie eine Garbage-Collection innerhalb der Rega gibt.

2. Da Systemvariablen in der RegaDom persistiert werden, hat man einerseits keinen 100% Datenverlust im Falle eines "unsauberen" Neustarts, aber ggf. gehen bis zu 12h der letzten Einträge verloren, weil die Rega noch nicht wieder neu geschrieben wurde. Und das spielt auch hierbei mit rein: Die RegaDom wird durch soetwas "noch" größer, als sie es ggf. eh schon ist, und evtl. geht alles im Betrieb gut, bis irgendwann die Rega zu groß zum Einlesen/Parsen nach einem Neustart ist, und das merkt man wahrscheinlich ärgerlicherweise erst nach div. Monaten Datensammeln.

Just my 2 Cents,
der Familienvater

[alchy]

Hab gerade mal ein Schnelltest durchgeführt. Ausstieg schon nach 450000 Zeichen.
Ein weiterer Punkt für die Nichtfunktion zu großer Systemvariablen wird dich erreichen, wenn die Speicherverwaltung zuschlägt.

Code: Alles auswählen

Jul 11 11:01:43 homematic-ccu2 user.err kernel: [218358.850000] Out of memory: Kill process 27191 (ReGaHss.communi) score 555 or sacrifice child
Jul 11 11:01:43 homematic-ccu2 user.err kernel: [218358.860000] Killed process 27191 (ReGaHss.communi) total-vm:175468kB, anon-rss:149268kB, file-rss:0kB
Jul 11 11:01:44 homematic-ccu2 daemon.err cuxd[376]: query_CCU_device_params() is NULL

Als vor langer Zeit ein Logging in Systemvariablen bei Webmatic eingeführt wurde, gab es auch schon diverse Probleme.
Ich würde davon abraten, größere Datenmengen in Systemvariablen zu verfrachten und gebe Familienvater Recht, das da jmaus sicher genauere Angaben machen kann.

Alchy

[fairtv]

Guter Einwand - also datensparsam bleiben und beobachten, was ja nie schadet.

Typischerweise sind die Kraftwerksangaben eine Art großes (nicht riesiges!) Array, und vom Umfang her relativ stabil.
Sammlungen von Sensorwerten zur Weiterverarbeitung habe ich meist in einer Art Ringbuffer, bzw. mit Cap. Also ist auch hier ein Ende absehbar und relativ konstant.
Fragmentierung, Garbage Collection der Zwischenschicht kann ich natürlich nicht bewerten.

Wichtig war mir halt mal ein Gefühl für das Ende zu bekommen.

[dtp]

Mein gut gemeinter Rat. Benutze die CCU nicht als Datengrab!

Für das Loggen von Daten sollte man eine spezielle Datenbank verwenden (z.B. MariaDB oder andere SQL-Datenbank). Dafür eignet sich ganz hervorragend der ioBroker. Mit dem kann man auch eine Auswertung, sowohl mathematisch, als auch grafisch, durchführen.