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

[apollon77]

@Shadowhunter23 sagte in js-controller 7.1 Beta test:

Danke für den Tipp! Ich musste einmal FB-Geräte neu einlesen. Der hat über Wochen alle Geräte gesammelt..

Und genau dafür ist diese Warnung gedacht... Bitte aber ggf auch beim Adapter ein Issue anlegen das man dort ggf optimieren oder fixen kann da so ein ansammeln nicht passiert!

[apollon77]

@Feuersturm sagte in js-controller 7.1 Beta test:

@apollon77 Der benchmark.0 Adapter hat bei mir etwas mehr als 10.000 objects vor längerer Zeit angelegt.

Naja ok, das idst quasi die Aufgabe dieses Adapters den man ja auch eher nicht in produktiv Umgebungen nutzt. der räumt die am Ende eines Laufen an such aber auch weg ... also ggf abgestürzt ?

[apollon77]

@ticaki sagte in js-controller 7.1 Beta test:

Der Pfad ist falsch in der Readme:

Danke, fixen wir

[mcm1957]

@ticaki sagte in js-controller 7.1 Beta test:

@apollon77 sagte in js-controller 7.1 Beta test:

@sigi234 sagte in js-controller 7.1 Beta test:

@apollon77 sagte in js-controller 7.1 Beta test:

(@foxriver76) Added objects warn limit per instance

Wie und wo kann ich das Limit einstellen?

https://github.com/ioBroker/ioBroker.js-controller/blob/master/README.md#objects-warn-limit

Hast du einen validen Case mit mehr als 5000 Objekte?

Der Pfad ist falsch in der Readme:

richtig ist:
system.adapter.<adapter>.<instance>.objectsWarnLimit

Leg bitte ggF ein Issue an oder gleich einen PR. Danke

[apollon77]

@mawe sagte in js-controller 7.1 Beta test:

der viessmann Adapter legt mir auch 8234 Objekte von meiner Heizung automatisch an. Die werde ich bestimmt alle brauchen... Ohh man.

Wenn die korrekt abgelegt sind dann ist das ja ok, wenn sie aber irgendwie aus der historie gesammelt wurden dann nicht.

[OliverIO]

@apollon77

sagte in js-controller 7.1 Beta test:

@mcm1957

Ja mit Admin verwechselt

[mcm1957]

@mawe sagte in js-controller 7.1 Beta test:

Moin,

der viessmann Adapter legt mir auch 8234 Objekte von meiner Heizung automatisch an. Die werde ich bestimmt alle brauchen... Ohh man.

viessmannapi.0 2025-12-07 23:10:44.784 warn This instance has 8234 objects, the limit for this instance is set to 5000.

Wenn das nicht Folge eines Absturzes ist wär das meiner Meinung nach ein Issue f d Adapter. Kann mir bei einer Heizung keine 8000 Mess bzw Steuerpunkte vorstellen - ausser das Ding kontrolliert die Fernwärme einer ganzen Stadt.

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