Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Armilar]

@Homoran sagte in js-controller 7.1 Beta test:

Macht SA so, und auch Renault

Kommt auf die Einstellungen an:

Also nur wenn die Haken gesetzt sind...

Cleverer ist auf jeden Fall den aktuellen Wert aus "01_currentDay" in influxDB, etc. zu schreiben und diesen dann bei Bedarf aggregiert zu visualisieren...

Den Renault kenne ich nicht... Aber da gibt es evtl. auch Möglichkeiten...

[paul53]

@Armilar sagte: "01_currentDay" in influxDB, etc. zu schreiben

Die Periodenwerte enthalten die "previous"-DP (Verbrauch / Kosten).

[Asgothian]

@Homoran sagte in js-controller 7.1 Beta test:

Macht SA so, und auch Renault

Nur weil bestimmte Adapter das so machen ist es trotzdem nicht unbedingt Sinnvoll.

Da müsste man dann mal mit den Entwicklern reden was sie sich dabei gedacht haben.

Generell sollte der Objektbaum eigentlich für 'aktive' Daten, und die History/Datenbank Varianten für 'historische' Daten genutzt werden.

A.

[Steffl]

Stimmt, aber das ist ja dann doch eine Sache vom Adapterentwickler. Und die Frage ist doch, hat der das gewusst.
Ist kein Weltuntergang, aber es wurde nach einer nachvollziehbaren Anwendung gefragt...

[Homoran]

@Asgothian sagte in js-controller 7.1 Beta test:

was sie sich dabei gedacht haben.

bei Renault wahrscheinlich nichts.
Der Inhalt des Datenpunkts kommt so von dem API

[Wildbill]

@Homoran Ich gehe einmal her und exportiere mir die wichtigen Daten (z.B. Sourceanalytix) und schiebe sie in Excel und lösche anschließend den jeweiligen Datenbaum des abgelaufenen Jahres. Hält die Daten relativ schlank und Excel bzw. Libreoffice haben die besseren Tools zum Auswerten und Anzeigen. Da kommt History/Influx und Grafana lange nicht hin.

Gruss, Jürgen

[Steffl]

Die entscheidende Frage ist doch aber, was passiert, wenn ich die 5000 als Limit stehen lasse. Wird der Renault Adapter dann keine Daten mehr aktualisieren oder ist das erstmal egal? Weil am Ladevorgang von 2022 ändert sich ja nix mehr.

[Armilar]

@Steffl

Aus der Interpretation des Namens objectsWarnLimit hat das keinen Einfluss auf die Verarbeitung. Du bekommst ja lediglich eine Warnung und den Parameter je Adapter kannst du ja selbst anpassen...

[crunchip]

@Asgothian sagte in js-controller 7.1 Beta test:

Nur weil bestimmte Adapter das so machen ist es trotzdem nicht unbedingt Sinnvoll.

Da müsste man dann mal mit den Entwicklern reden was sie sich dabei gedacht haben.

Generell sollte der Objektbaum eigentlich für 'aktive' Daten, und die History/Datenbank Varianten für 'historische' Daten genutzt werden.

da zählt aber auch z.b. der valuetrackerovertime und der statistics Adapter auch dazu, sind ja ähnlich wie der soursanalytics

[Steffl]

@Armilar na ja ich werde es sehen, morgen wird wieder geladen. Aber mal weiter gedacht, selbst wenn ich jetzt lösche bis vielleicht noch 2000 Objekte übrig sind, dann darf ich spätestens in einem Jahr wieder ran. Irgendwie hätte ich gehofft, da nicht immer mal wieder manuell eingreifen zu müssen.

[Armilar]

@Steffl

nicht löschen... Dann eher den Entwickler bitten das etwas schlanker zu gestalten...

Ich meinte den Parameter im Expert-Mode:

Musste ich auch bei dem ein oder anderen hochsetzen, obwohl es "nur" Laufzeitdaten sind!

Cooler wäre es natürlich per GUI - aber so geht es auch erst einmal...

[Feuersturm]

@Int17 siehe https://forum.iobroker.net/topic/83149/js-controller-7.1-beta-test/

[Int17]

@feuersturm
Vielen Dank für deine kompetente und hilfreiche Antwort.

[mcm1957]

@apollon77 korrigier mich bitte wnn ich was falsche tipp:

Die 5000er Meldung ist nur ein WARNING (bzw. Information). Am Systemverhalten ändert sich nichts. Dein Adapter wird dadurch weder Daten löschen noch irgendwelche States nicht mehr neu anlegen. Ein Ignorieren der Meldung bewirkt keinerlei Veränderung am normalen Betrieb.

Warum kommt diese Meldung:
Es gibt immer wieder Adapter oder Situationen wo unmengen an States erstell werden, die dann niemand mehr benutzt. Diese States kosten Speicher und kosten auch CPU Zeit da sie vom Kernel im Speicher gehalten werden und bei diversen Aktionen auch gescannt werden müssen. Es gab wiederholt Situationen wo user sich gewundert haben dass ihr System so langsam geworden ist oder dass Backups so groß wurden etc. Diese Meldung soll das Bewußtsein heben, dass für einen normalen Adapter ungewöhnliuch viele States vorhanden sind. Ob das im Einzelfall gewunschen ist und ob der User eh ein System mit 64GB Ram betreit kann nur er beurteilen - und ggF das Warnungslimit hochsetzen.

Generell sollte beim Auftreten der Meldung mal geprüft werden, was das für States sind.
Handelt es sich dabei z.B. um States die wirklich nur temporär sind (z.B. um MACs von Geräten die irgendwann mal im Netz gesehen wurden) oder die durch Übertragungsfehler (verstümmelte IDs etc) entstanden sind, dann kann man die wahrscheinlich einfach löschen.

Historische Daten sollten nicht in den States gespeichert werden. Und ja das ist etwas was der Adapter lösen / anbeiten muss.
Ebenso kann ein Adapter zumindest on Request Cleanups anbieten.
Es ist daher durchaus sinnvoll ein entsprechendes Issue bei einem Adapetr der größere Mengen historischer Daten anlegt zu erstellen.

Ebenso ist es sinnvoll bei einem Adapter der 10000 Datenpunkte eines Apis abholt ein Issue zu erstellen und zu hinterfragen ob es nicht möglich wäre hier eine Auswahl, Filterung etc. umzusetzen. Neu weil ein Wetteradaptrr die Temperaturen aller deutschne Messstationen abfragen kann, wird es wohl kaum sinnvoll sein, dies auch zu tun.

ERGO zusammengefasst:

• keine Panik, es gehen keine Daten verloren
• bei offensichtlichen Schrottdaten (z.B. durch eine Störung) diese löschen.
• bei nicht offensichtlich sinnvoll benötigten Daten ein Issue beim Adapter erstellen mit der Bitte die Stateanzahl zu hinterfragen / optimieren
• wenn man wirklich so viele Daten einer Instanz braucht und ein sntsprechend potentes System hat kann man das Warnlimit anpassen.

[mcm1957]

@Steffl sagte in js-controller 7.1 Beta test:

@Armilar na ja ich werde es sehen, morgen wird wieder geladen. Aber mal weiter gedacht, selbst wenn ich jetzt lösche bis vielleicht noch 2000 Objekte übrig sind, dann darf ich spätestens in einem Jahr wieder ran. Irgendwie hätte ich gehofft, da nicht immer mal wieder manuell eingreifen zu müssen.

Erstell ein Issue beim Adapter. Ein Maintainer der seinen Adapter gut pflegt wird das sicher evaluieren und eine geeignete Optimierung umsetzen.

[mcm1957]

@homoran
Ich rege an diese Topic entweder an den js-controller 7.1.x Testthread anzuhängen oder hier zu schließen.
Inhaltlich gehört das zu 100% zum js-controller Test

[Homoran]

@mcm1957 sagte in js-controller 7.1 Beta test:

an den js-controller 7.1.x Testthread anzuhängen

erledigt!

[JB_Sullivan]

Habe ich es überlesen, oder gab es schon einen Hinweis auf das erhöhen der Objekt Limits?
.... und ja, ich habe unendlich viele Diagramme die ihre Daten alle aus SA beziehen.

[Homoran]

@JB_Sullivan sagte in js-controller 7.1 Beta test:

gab es schon einen Hinweis auf das erhöhen der Objekt Limits

sagte in js-controller 7.1 Beta test:

@MartyBr der Doku nach
https://github.com/ioBroker/ioBroker.js-controller/blob/master/README.md#objects-warn-limit
gilt das für alle

[Armilar]

@Homoran

ist immer noch falsch. Ich hatte schon einen PR gestellt:

nicht system.host.adapter.<adapter>.<instance>.objectsWarnLimit

sondern system.adapter.<adapter>.<instance>.objectsWarnLimit