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

[Asgothian]

Ich habe im Zigbee-Adapter extra eine Funktion eingebaut über die der Adapter prüft welche DP sich in deinem Namespace befinden, und ob diese weiterhin genutzt werden.
Vielleicht sollte so eine Funktion beim Start auch für andere Adapter vorgesehen werden.

Aktuell mache ich das recht Hemdsärmlig über das Anpassen der Farbe der DP ID im Admin. Wenn js-Controller / Admin da ein Flag anbieten wüden könnte man das verallgemeinern.

A.

Nachtrag - Ich hab das gepaired mit einer Funktion diese erkannten 'nicht weiter verbundenen DP's' vom Adapter löschen zu lassen. Die muss der Nutzer aber explizit ausführen, damit da nicht aus versehen automatisch was umgehauen wird was noch Wert hat.

[BBTown]

Nach dem Update auf v7.1.0 wird bei mir die Scripte Seite nicht mehr aufgebaut (Javascript-Adapter ist bei mir die v9.0.13)

[ilovegym]

@mcm1957

nee, kein Fehler, sondern der ViessmannApi-adapter ist so designed - er holt einfach alles von der API ab.
Die 8000 States sind da ganz normal, egal welches und wieviele Devices man hat.

Der alte Unifi-Adapter war ja auch so ein Kandidat (den neuen teste ich nicht mehr, da ich mir ein Script dafür geschrieben habe) / mit default Einstellungen hatte ich da über 60000 States mehr.. gut, da gabs wenigstens ein Filter..

Ich finde den Weg, hier mal auf das Environment zu achten, sehr gut.

@asgothian hat ja im Zigbee-Adapter schon so ein Cleanup-Button eingebaut, das fand ich damals bei der Umstellung schon recht praktisch, vielleicht sollte man hier generell ein flag im Controller haben, das lange nicht genutzte States markiert und dann ein Clean (mit Protokoll) anbieten..?

[BBTown]

sagte in js-controller 7.1 Beta test:

Nach dem Update auf v7.1.0 wird bei mir die Scripte Seite nicht mehr aufgebaut (Javascript-Adapter ist bei mir die v9.0.13)

hier mache ich mal schnelle eine Rolle Rückwärts, es liegt scheinbar am Script-Adapter, da mit der v9.0.11 die Darstellung auch unter dem js-controller v7.1.0 korrekt ist.

Ich mache eine Meldung beim Script-Adapter auf

[crunchip]

@apollon77 sagte in js-controller 7.1 Beta test:

Details? Am Ende kommt das vor allem bei Source Analytics ja stark auf Deine Nutzung an

Stimmt, zum einen, je nachdem was man in der Instanz alles anhakt, ob Verbrauch, Zählerstände und wieviele Geräte man mit erfasst.
Monats, Quartals oder Jahresordner.
Pro Gerät werden dementsprechend zwei Hauptordner angelegt, für das Jahr und current.
Jedes Jahr werden dann wiederum neue Jahresordner.
Somit kommen entsprechend der Einstellung tägliche, wöchentliche, monatliche, Quartals und Jahresordner dazu, pro Gerät.
Ich habe bei mir die zurückliegenden Jahre schon ausgemisstet, sonst hätte ich locker über 50000

Edit:
Die ganzen Datenpunkte für Kosten vergessen zu erwähnen

[Int17]

Hallo,
bekomme seit heute obige Meldung. Habe keine neuen HM-Geräte den vorhandenen 50 Geräten, hinzugefügt. Kann ich das Limit irgendwo hochsetzen (iobroker.json)?

[ilovegym]

als Beta-Tester haste bestimmt doch im entsprechenden Thread gelesen, worum es da geht und wie man es einstellen kann.. oder? :)

[Steffl]

Ich habe die Limit Meldung auch beim Renault Adapter.
renault.0 (1612312) This instance has 10506 objects, the limit for this instance is set to 5000.
Das ist die Ladehistory der letzten 3 Jahre. Ich würde die schon behalten wollen und notfalls auch die nächsten 3 Jahre.

[Asgothian]

@Steffl sagte in js-controller 7.1 Beta test:

Das ist die Ladehistory der letzten 3 Jahre. Ich würde die schon behalten wollen und notfalls auch die nächsten 3 Jahre.

Ich stelle da mal ganz ketzerisch die Frage - ist der Objektbaum des ioBroker der korrekte Ort um historische Daten zu erhalten ? Sollten diese nicht lieber in einer mit standard-Werkzeugen auswertbaren Datenbank landen ?
Das du die Daten weiter behalten willst ist nachvollziehbar. Aber in der aktiven Datenablage haben sie eigentlich nichts zu suchen.

Nur so nebenbei - jeder Adapter der 'alle States beim Start abonniert' (Insbesondere: Jede Instanz des Skript-Adapters, aber wahrscheinlich auch Node-Red und andere) - holen sich diese für sie hoch interessanten alten Daten mit in Ihren Speicher hinein, damit sie auf deren Änderungen schnell reagieren können.

Das ist Ressourcenverschwendung im ganz grossen Stil :)

Wenn du mal sehen willst über wieviel Speicher da gesprochen wird kannst du ja mit diesen Haken mal spielen um einen Vorher/Nachher vergleich bei der Speichernutzung des Systems zu bekommen

[Homoran]

@Asgothian sagte in js-controller 7.1 Beta test:

ist der Objektbaum des ioBroker der korrekte Ort um historische Daten zu erhalten ?

Macht SA so, und auch Renault

[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.