UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[paul53]

@martybr sagte: investiere ich hier lieber in eine neue und größere SSD.

Das ist bei einer Samsung 970 Pro nicht nötig.

[JLeg]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@jleg sagte in ioBroker sehr hohe Diskwrites in Proxmox:

ch hab‘ meine Nadel gefunden: es ist der WLED-Adapter

habe zum Test, ebenfalls WLED deaktiviert und siehe da, Änderungen der objekcts.json sind deutlich weniger geworden

Setz‘ in der WLED-Instanz das Scanintervall einfach auf 300 oder so, und der Spuk ist vorbei... :) Wenn man neue WLEDs anlernen will, kann man‘s ja wieder runtersetzen.

[crunchip]

@jleg hab @Dutchman mal Bescheid gegeben.

so nun hab ich aber immer noch so ca alle 15-16min eine Änderung. Hab ich DWD bzw Weatherunderground in Verdacht, da diese
a) mit dieser cron Zeit laufen,
b) die Tage enorme Errors geworfen haben

[Wildbill]

Ich habe für den DWD-Adapter mal hier ein Issue aufgemacht.

Gruss, Jürgen

[Homoran]

@crunchip sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Hab ich DWD bzw Weatherunderground in Verdacht,

DWD läuft bei mir auch - aber unauffällig

[Wildbill]

@homoran Ich hab das Issue aufgemacht, weil meine objects.json genau alle 15min (das war der DWD-Intervall) und zwar zu den jeweils eingestellten krummen Minuten (4, 19, 34, 49,) gespeichert wurde. Seit ich den DWD-Adapter mal angehalten habe, war zwischen zwei Speicherintervallen ca. eine dreiviertel Stunde, in der zeit hab ich im iobroker aber auch was gemacht. Also kein Verdacht sondern definitiv der DWD der da auf jeden Fall (auch) schuld ist. Allerdings wohl auch nur, wenn es öfter neue Meldungen gibt was bei uns gerade der Fall war/ist wegen Schneefall seit heute Nacht. In den letzten Tagen hatte ich das viertelstündliche Speichern nicht, da gab es allerdings auch keine Meldungen.
Wie oft wird die objects.json eigentich gespeichert, wenn sich an den Objekten gar nichts geändert hat? Kann man das Intervall irgendwo sehen/einstellen?

Gruss, Jürgen

[Homoran]

@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Allerdings wohl auch nur, wenn es öfter neue Meldungen gibt was bei uns gerade der Fall war/ist

dann werde ich das mal beobachten.
Kann natürlich wirklich sein, da dann die DPs neu befüllt werden.
Aber ist das so viel Info?

BTW: ich habe die Karte nicht aktiviert

[paul53]

@wildbill sagte: Wie oft wird die objects.json eigentich gespeichert, wenn sich an den Objekten gar nichts geändert hat?

Gar nicht. Weshalb sollten konstante Objekte wiederholt gespeichert werden ?

[Wildbill]

@paul53 Meiner Meinung nach gar nicht, deshalb meine Frage. Wenn also die objects.json neu gespeichert wird, dann ist das ein Zeichen, dass irgend ein Datenpunkt neu erstellt oder ein bestehender geändert wurde. Beim Dwd bin ich mir dann sicher, aber ich beobachte mal weiter.

Gruß, Jürgen

EDIT: @apollon77 hat das Issue soeben geschlossen, da es wohl eher ein Problem des JS-Controllers ist, der nicht prüft, ob States bereits existieren wenn sie mit setObject upgedated oder neu erstellt werden und auch speichert, wenn es gar keine Änderung gab. Auch dazu gibt es ein Issue, evtl. hilft das ja eh besser. Vermutlich ist es beim Syno-Adapter (den ich aber nicht habe) auch so, und bei vielen anderen auch.

[JLeg]

@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@homoran Ich hab das Issue aufgemacht, weil meine objects.json genau alle 15min (das war der DWD-Intervall) und zwar zu den jeweils eingestellten krummen Minuten (4, 19, 34, 49,) gespeichert wurde. Seit ich den DWD-Adapter mal angehalten habe, war zwischen zwei Speicherintervallen ca. eine dreiviertel Stunde, in der zeit hab ich im iobroker aber auch was gemacht. Also kein Verdacht sondern definitiv der DWD der da auf jeden Fall (auch) schuld ist.

Ja, ist er - nach Abklemmen des WLED waren die nachfolgenden object.json-Änderungen tatsächlich auch bei mir vom DWD, kann man leicht sehen, wenn man sich die Unterschiede zwischen object.json und object.json.bak anzeigen lässt.

[Wildbill]

@jleg Womit lässt Du die Unterschiede anzeigen? Diffuse und jp sind bei mir an der Dateigröße gescheitert.

Gruß, Jürgen

[crunchip]

@homoran ja, seit dem update gibt es nur noch diese Meldung

dwd.0	2021-01-23 17:00:07.039	warn	(1763) slow connection to objects DB. Still waiting ...

[JLeg]

@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@jleg Womit lässt Du die Unterschiede anzeigen? Diffuse und jp sind bei mir an der Dateigröße gescheitert.

Gruß, Jürgen

jq - damit jeweils objects.json u. objects.json.bak konvertieren (nach "lesbar"), und per diff dann einfach anzeigen.

jq . objects.json > objects.pretty.json
jq . objects.json.bak > objects.pretty.json.bak
diff -u objects.pretty.json objects.pretty.json.bak

Der oben erwähnte Fehler im js-controller lässt sich auch gut erkennen, denn es lässt sich oft auch beobachten, dass objects.json zwar neu geschrieben wurde, die beiden Dateien aber 100% identisch sind.

[Dr. Bakterius]

@wildbill Ich habe die Dateien nach Windows kopiert und mit Notepad++ plus Compare-Plugin verglichen. Benötigt bei entsprechenden Dateigrößen aber auch Zeit. Und ich konnte zwischen aktueller Datei und Backup auch keine Unterschiede feststellen. Es scheint, dass es reicht die Objects nur "anzugreifen" um ein Speichern anzustoßen.

[Homoran]

@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:

mit Notepad++ plus Compare-Plugin verglichen

Danke für den Tipp - soeben installiert!

[apollon77]

@wildbill sagte in ioBroker sehr hohe Diskwrites in Proxmox:

EDIT: @apollon77 hat das Issue soeben geschlossen, da es wohl eher ein Problem des JS-Controllers ist, der nicht prüft, ob States bereits existieren wenn sie mit setObject upgedated oder neu erstellt werden und auch speichert, wenn es gar keine Änderung gab.

... also wenn das aus meiner Antwort bei Dir angekommen ist dann hast Du es falsch verstanden!

Ein Objekt mit einem neuen "geändert am" Zeitstempel ist ein geändertes Objekt. Die Diskussion ob das so Sinn macht und ob das ein neues schreiben triggern sollte - das ist das was wir diskutieren müssen ... Gibt mehrere Blickrichtungen darauf!

[paul53]

@apollon77 sagte: Ein Objekt mit einem neuen "geändert am" Zeitstempel ist ein geändertes Objekt.

Das sehe ich auch so. Es sollte Aufgabe des Adapters sein, nur geänderte oder neue Objekte zu schreiben.

[JLeg]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Ein Objekt mit einem neuen "geändert am" Zeitstempel ist ein geändertes Objekt. Die Diskussion ob das so Sinn macht und ob das ein neues schreiben triggern sollte - das ist das was wir diskutieren müssen ... Gibt mehrere Blickrichtungen darauf!

Keine Frage, aber, die gerade diskutierten Fälle waren solche, bei denen es keinerlei Änderungen in der objects.json gab (also auch keine "ts"-Änderungen), aber trotzdem geschrieben wurde. D.h. objects.json und objects.json.bak sind exakt identisch. Die einzigen "Änderungen" sind in diesem Fall der Zeitstempel der beiden Dateien... ;)
Ich habe verstanden, dass das ursächlich an Adaptern liegen dürfte - die Frage wäre aber imo, ob es nicht "oben drüber" jemanden (Objektdatei-Schreibroutine) gibt, der das abfangen (und verwerfen) könnte?

[apollon77]

@paul53 das ist aber nicht so einfach oder viel Logik in jedem Adapter. Vor allem crib adapter haben dieses Problem weil sie jedes Mal alles prüfen müssen. Deswegen Überlegen wir was wir da tun können ;-) das Thema hat’s aber nicht in den 3.2er Controller geschafft. 3.3 dann vllt.

[Wildbill]

@apollon77 OK, möglicherweise habe ich da einen Denkfehler oder ein Verständnissproblem. Aber wie @JLeg schrieb: Wenn es KEINE Änderungen an den Objekten selbst gibt und von einem bestehenden Objekt sich nur der Zeitstempel ändert, weil es 1:1 von einem Adapter oder Skript nochmals "neu" erstellt wurde und sich somit nur der Zeitstempel ändert, dann verstehe ich nicht ganz, warum das dann neu gespeichert werden sollte. Gibt es dafür Anwendungsfälle oder eine schlüssige Begründung oder weil, wie Du geschrieben hast, alles jedes Mal komplett geprüft werden muss und die Systemlast dadurch zu stark steigen könnte? Ansonsten bin ich da auch der Meinung, der Controller sollte das eher abfangen. Etwas mehr Last sehe ich (zumindest auf eine potenten System abseits der Raspi&Co) als unkritischer als zu oft stattfindende (unnötige?!) Schreibzugriff auf die objects.json.
Würde da das Umstellen der Objekte auf redis (die states habe ich schon auf redis) etwas verbessern? Meine objects.json hat aktuell etwas über 15MB, landen da bei redis dann auch nur die "Änderungen" und es werden nur die paar kB geschrieben, die sich geändert haben?

Gruss, Jürgen