Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Andersmacher]

Ich nutze seit Jahren den modbus-Adapter (für Zugriff auf meinen WR) mit folgenden Einstellungen eigentlich problemlos:

Erst jetzt ist mir aufgefallen (weil ich ein entsprechendes Widget in VIS eingebaut habe), daß das eingestellte Datenabfrageintervall (1000ms) nicht mit der angezeigten pollTime (300ms, Werte schwanken zwischen gut 200ms und knapp 500ms) übereinstimmt:

Ist das so zu verstehen, daß die pollTime nicht die Zeitspanne zwischen zwei Pollings, sondern die benötigte Dauer für einen Pollingdurchgang ist? Ich frage deshalb, weil der Aktualisierungszeitstempel der abgefragten Werte im ioBroker-Objektbaum weder um 1s noch um 300ms anwächst. Vielmehr scheint er bei etwa 1s plus 300ms zu liegen, aber dann wäre der Begriff "Datenabfrageintervall" etwas verwirrend. Es wäre dann eher eine Tot- oder Wartezeit!?

Weiß jemand, wie es wirklich ist / sein soll und/oder kann mir einen Tipp geben, wo mein Denk-/Parametrierungfehler liegt?

[Homoran]

@andersmacher sagte in Frage zum modbus Datenabfrageintervall:

mit der angezeigten pollTime

den Datenpunkt hatte ich bisher noch gar nicht gesehen.

nachdem ich die mir jetzt eine Zeitlang angesehen habe

scheint es so zu sein,

@andersmacher sagte in Frage zum modbus Datenabfrageintervall:

daß die pollTime nicht die Zeitspanne zwischen zwei Pollings, sondern die benötigte Dauer für einen Pollingdurchgang ist?

Das Abfrageintervall ist definitiv die Zeit zwischen zwei Poll"starts".
Die Polltime muss natürlich kürzer sein.

Ich habe keine so hohe PollTime, seltsamerweise beim Bus mit den Meisten Daten sogar die allerkürzeste.
Auch liegt die Schwankung (zumindest in den paar Minuten Beobachtung) im einstelligen Bereich.

@andersmacher sagte in Frage zum modbus Datenabfrageintervall:

weder um 1s noch um 300ms anwächst. Vielmehr scheint er bei etwa 1s plus 300ms zu liegen, aber dann wäre der Begriff "Datenabfrageintervall" etwas verwirrend. Es wäre dann eher eine Tot- oder Wartezeit!?

nein, weder noch.

Die Timestamp Differenz sollte 1 sec +/- die Schwankung sein.

Das Datenabfrageintervall ist fix. Wenn die pollTime auch fix ist bliebe der Unterschied der Timestamps bei 1 sec.

[Andersmacher]

@homoran Danke ersteinmal für Dein Testen und die spontane Rückmeldung.

Ich habe 42 Eingangsregister für die Abfrage definiert. Da fand ich die 300ms nicht auffällig groß. Habe aber keine Ahnung, was da an Aufwand hintersteckt.

Wenn ich statt meiner 300ms nur 50ms oder noch weniger hätte, würde ich die "Verschiebung" der Zeitstempel weg von der erwarteten 1s-Differenz vermutlich gar nicht entscheiden können, weil man dann ja vermutlich auch noch "Laufzeiten" im System als Einflußgröße hat!?

Ich habe meine Abfragezeit jetzt mal auf 5s hochgesetzt. Dadurch habe ich mehr Zeit zum Beobachten und Kopfrechnen und konnte die 10tel Sekunden noch berücksichtigen:
Bei mir ist die Differenz der Zeitstempel dann doch Datenabfragezeit + pollTime!
Nach 3 mal 5s hat sich mein Zeitstempel um 16s verschoben, was ja in etwa 3 mal 300ms entspricht. Das ist reproduzierbar.

Das Abfrageintervall ist definitiv die Zeit zwischen zwei Poll"starts".

Das kann ich daher leider nicht bestätigen!

[Homoran]

@andersmacher sagte in Frage zum modbus Datenabfrageintervall:

Das kann ich daher leider nicht bestätigen!

Danke!
Dann wird das Datenabfrageintervall also erst nach dem vollendeten Poll wieder gestartet?
Wäre sinnvoll, aber dann könnte es bei zu kurzem Datenabfrageintervall nie zu Problemen kommen, weil die Antwort zu lang gedauert hat

[Andersmacher]

@homoran Ja, scheint so: Technisch sinnvoll/sicher, aber vokabelmäßig verwirrend und meiner Ansicht nach auch schade, weil man dadurch keine "verläßlichen" Abfragezeitpunkte bekommt/definieren kann, die man mit anderen "synchronisieren" könnte. Wenn man das wollte, müßte man wohl irgendwie tricksen.

Bei mir war der Auslöser der ganzen Aktion, daß ich endlich einmal in den Griff bekommen wollte, daß beim Berechnen/Messen von Erzeugung/Einspeisung/Bezug keine negativen Verbräuche mehr auftreten. War bei mir von Zeit zu Zeit der Fall und hat dann immer sehr unschöne Auswirkungen in Grafiken.
Im Forum wurde ja schon öfter darüber diskutiert, wie man das in den Griff bekommen kann und tendenziell wurde als Lösung wohl Triggern der Berechnungen auf das letzte ausgelesene modbus-Register propagiert, weil man als Auslöser des Problems die Abfrage der modbus-Register annimmt (soll keine Wertung sein).

Zumindest bei mir bringt das nichts, weil bei mir Bezug und Einspeisung vom Sunny Homemanger (HM) via UDP ca. sekündlich ins Netzwerk kommt, und nur die Erzeugung vom WR via modbus abgefragt wird. HM und WR/modbus messen/liefern die Werte somit niemals synchron. Selbst wenn man die HM-Werte vom WR lesen und in seine modbus-Register eintragen läßt, um sie dann von dort mit den Erzeugungswerten zusammen via modbus wieder auszulesen, stammen die HM-Werte ja noch immer aus einer andere Meßperiode, als die WR-Werte.
Da kann man sich Kopfstellen. Bei starken/schnellen Sonnenschwankungen kommt es immer mal wieder zu negativen Werten.
Ich hab das so gelöst, daß ich die dann einfach im Skript ignoriere/unterdrücke, also weder anzeige noch anders weiterverwerte. Nach wenigen Sekunden stehen ja dann in der Regel wieder sinnvolle Wert zur Verfügung.

Editiert: "negative Bezüge" durch "negative Verbräuche" ersetzt.

[Homoran]

@andersmacher sagte in Frage zum modbus Datenabfrageintervall:

Bei starken/schnellen Sonnenschwankungen kommt es immer mal wieder zu negativen Werten.

das habe ich aber auch ohne modbus.
ich starte eine api Anfrage im WR, wenn der Smartmeter Wert aktualusiert wird.
selbst diese minimale Zeitverschiebung reicht um negative Hausverbrauchswerte zu erhalten

[Andersmacher]

@homoran sagte in Frage zum modbus Datenabfrageintervall:

selbst diese minimale Zeitverschiebung reicht um negative Hausverbrauchswerte zu erhalten

Ja, weil aus meiner Sicht eben nicht die Abfrage das Problem ist, sondern die verschiedenen Zeitpunkte, zu denen die Meßwerte entstehen, weil sie aus unterschiedlichen Geräten kommen.

[Homoran]

@andersmacher sagte in Frage zum modbus Datenabfrageintervall:

sondern die verschiedenen Zeitpunkte, zu denen die Meßwerte entstehen, weil sie aus unterschiedlichen Geräten kommen.

nicht nur das!
Selbst die Werte eines Gerätes können schon alt sein, wenn sie abgerufen werden.
im nächsten Moment wären sie aktualisiert worden.

[Andersmacher]

@homoran Naja, allerdings wäre das "nur" ein Aktualitäts- und kein Konsistenzproblem. Negative Verbräuche könnten dadurch nicht entstehen.

[Homoran]

@andersmacher sagte in Frage zum modbus Datenabfrageintervall:

Negative Verbräuche könnten dadurch nicht entstehen.

jein!
Wenn du es hinbekommen würdest die Abfrage zweier Geräte absolut synchron hinzubekommen, die dort im "Abfragespeicher" liegenden Werte aber unterschiedlich alt sind, dann doch.

[Andersmacher]

@Homoran Genau, siehe:

Ja, weil aus meiner Sicht eben nicht die Abfrage das Problem ist, sondern die verschiedenen Zeitpunkte, zu denen die Meßwerte entstehen,

Ich glaube, wir meinen das gleiche
Nochmals Danke, für Deinen Input!