Weihnachtsangebot 2025! 🎄

[sneets]

@homoran Ja, einmal hat er nur 10 Sekunden zwischen gedoppeltem und neuem Wert gelassen, stimmt...in 98% der "Doppelungsfälle" waren es immer 20 Sekunden Abstand. Daher meine Vermutung, dass er quasi beim Empfang eines NEUEN Wertes den letztmaligen Poll des alten Wertes zusätzlich nochmal geschrieben hat, was mit den 20 Sekunden Polling-Interval des plenticore-Adapters zusammen passen würde.

Warum da nun auch einmal nur 10 Sekunden Abstand waren....gute Frage.

Na ich beobachte mal weiter, aber jetzt laufen die Werte erstmal zu meiner Zufriedenheit dank gesetzten Hakens!

[Homoran]

@sneets Sorry, das hab ich so nicht sehen können.
Ich hätte deutlich kürzere Zeiten erwartet.

Die Funktion ist dazu da um die Linie im Graphen so lange auf einem Niveau zu halten, bis sich der Wert ändert.
Dazu sollte das Ende der Horizontalen möglichst dicht am neuen Wert liegen.

Deaktiviert man die Funktion durch den Haken in der Checkbox, wird der Graph linear von Punkt zu Punkt verbunden, was nicht der Realität entspricht.

[Ro75]

@sneets zeig doch mal die Daten vom Register "HISTORY DATA".

Ro75.

[sneets]

@ro75 Hier der Screenshot von History Data.
Wie man sieht, liefert der plenticore Adapter tatsächlich immer ca. 5 Minuten lang den gleichen Wert, was wohl heißt, dass der Wechselrichter selbst auch nur in diesem Abstand seine API-Requests neu versorgt. Hätte selbst auch gedacht, dass er quasi Realtime Daten ausliefert, was wohl nicht der Fall zu sein scheint.
Da ich aber nur den Verbrauchsverlauf übers Jahr tracken will, passt das schon. Und das würde für mich auch dafür sprechen, dass ich das "Tabellenfreundliche loggen" mit Dopplung des letzten Werts getrost deaktiviert lassen kann, da das, was der Wechselrichter schickt, ohnehin nicht der Realität entspricht, bis er sich genehmt, seine Daten zu aktualisieren. Im Gegenteil, wenn der Graph zwischen altem und neuem Wert eine gleichmäßig ansteigende Linie zeigt, entspricht das in dem Fall ja sogar mehr der Realität, als der treppenweise Anstieg, der sonst zustande kommen würde. Sehe ich doch richtig, oder?

[Ro75]

@sneets

Der InfluxDB Adapter macht alles richtig. Es sind unterschiedliche Werte, demnach Speicherung. In Influx direkt ist eine Rundung eingestellt und damit sieht es so aus, als wäre was doppelt, was gar nicht ist.

Einstellungssache.

Ro75.

[Homoran]

@ro75 äääh, nein!
die ersten beiden Zeilen sind laufende Rohdaten, die jach öffnen der Seite hinzukamen, und noch nicht final geprüft und nicht gespeichert wurden

zu erkennen an der Bezeichnung der Quelle

[Ro75]

@homoran ja, aber nicht Zeile 2 und 3.

Ro75.

[sneets]

@ro75 Doch, Zeile 2 wurde auch nicht übernommen, sie ist kurz danach aus der History Data wieder rausgeschmissen worden.
Nur ab Zeile 3 im Screenshot befanden sich persistierte Werte im Bild.

[Homoran]

@ro75 sagte in influxdb doppelt Werte:

@homoran ja, aber nicht Zeile 2 und 3.

Ro75.

nein, nur 3 bleibt
und damit gibt es jetzt keine doppelten mehr

[sneets]

Mir ist das Funktionsprinzip von influx und der Sinn der doppelten Werte nun auch klar. Wenn ich einen Sensor x mal abfrage, der Echzeitdaten liefert, und erst nach der 50. Abfrage kommt ein neuer Wert, dann möchte ich quasi Abfrage 49 auch nochmal mit dem alten Wert abspeichern, damit der Übergang möglichst zeitlich korrekt sichtbar wird.

Da mein Plenticore aber nur alle +-5 Minuten seine ausgelieferten Werte aktualisiert, ist diese Herangehensweise bei diesen Werten sinnlos, da der entstehende, gedoppelte "letzte alte" Wert schon von vornherein nichts mit der Realität zum Abfragezeitpunkt zu tun hatte.

Von daher alles gut. Bleibt einzig das Rätsel, ob ich den Plenticore irgendwie überreden kann, seine ausgelieferten Werte in kleineren Intervallen zu aktualisieren. In der Web-UI sehe ich dazu jedenfalls keine Möglichkeit. Wahrscheinlich loggt er einfach fix im 5-Minuten-Takt. Schade, aber nicht weiter schlimm.