Weihnachtsangebot 2025! 🎄

[klassisch]

Hallo,

Frage zum Bufferimng bzw. Zeitverhalten bei Dateneingang via TCP Server - Zeitdilatationen.

Folgendes Setup:

• Itron Zähler mit Optischer Schnittstelle, "Moderne Meßeinrichtung" Datenausgabe etwa im Sekundentakt
• Hager EHZ001K Leskopf mit RS485 Ausgang
• RS485 <-> TTL Wandler
• TTL<-> Ethernet Wandler mit TCP Server , USR-TCP232-E2
• Smartmeter Adapter

"Testsignal":

• Minute 0: Restart smartmeter Adapter
• Minute 1: elektrische Last aufschalten (Herd)
• Minute 2: elektrische Last abschalten

Auswertung:

• Zeitverzug zwischen dem Sprungsignal und der Antwort
• durch Auswerung logffile Lodgstufe debug. Beobachtung des Leistungswertes

Parameter:

• Meßreihe 1: Abfrageintervall = 0
• Meßreihe 2: Abfageintervall = 5s

Ergebnis:

• Bei Abfrageintervall 0 folgt die ioBroker-Auswertung nahezu instantan dem Leistungssprung. Abweichung im Bereich der Genauigkeit der Versuchsdurchführung
• Bei Abfrageintervall 5s:
  • beim Einschalten folgt der Wert im Logfile dem realen Leistungssprung um 03:47, also ca. 4 Minuten verzögert
  • Beim Ausschalten folgt der Wert im Logfile dem realen Leistungssprung 05:27 also ca. 5 1/2 Minuten verzögert

Nehme an, da sind irgendwelche Buffers, die nicht geflusht werden. Aber wo könnten die stecken?

Bei Abtastintervall von 30Sekunden werden aus 5 Min Mikrowelle in der Realität 20 Minuten in der Aufzeichnung.

Workaround: Abtasten mit 0 und Aufzeichnung im 0_userdata Bereich via Skript.

[klassisch]

Habe jetzt mal den gleichen Test widerholt mit USB statt TCP Datenspeisung
Folgendes Setup:

• Itron Zähler mit Optischer Schnittstelle, "Moderne Meßeinrichtung" Datenausgabe etwa im Sekundentakt
• Hager EHZ001K Leskopf mit RS485 Ausgang
• RS485 <-> USB Wandler
• Smartmeter Adapter

Parameter:

• Meßreihe 2: Abfageintervall = 5s

Ergebnis
Auch bei Abfrageintervall 5 folgt die ioBroker-Auswertung nahezu instantan dem Leistungssprung. Abweichung im Bereich der Genauigkeit der Versuchsdurchführung

Der zeitdiletierende Buffer scheint also in der TCP Strecke zu liegen. Wobei ich nicht sagen kann, ob das im Bereich des TTL <-> Ethernet-Adapters oder im Bereich des ioBroker Hosts (Win 10) liegt.

[klassisch]

Habe heute ein weiteres Experiment gemacht, um die Sache etwas besser einzugrenzen und bin jetzt so weit, daß ich leider auf den ioBroker Smartmeter-Adapter zeigen muß.

Das Experiment fand auf einer unabhängigen Windows 10 Testmaschine statt. (Nur der Vollständigkeit halber, sollte das Experiment nicht beeinflssen: Die Produktivmaschine lief parallel mit, die Daten wurden auf dem RS485 ausgekoppelt und der Produktivmaschine via RS485 <-> USB zugeführt.
Die Testmaschine griff auf den USR-TCP232-E2 zu.
DIese Mal aber NICHT über die ioBroker Mechanismen, sondern über den virtuellen COM-Port Treiber von USRIOT.
Unelgant, aber zu Testzwecken
Abtastintervall wieder 5 Sekunden

Ergebnis:

• Auch bei Abfrageintervall 5 folgt die ioBroker-Auswertung nahezu instantan dem Leistungssprung. Abweichung im Bereich der Genauigkeit der Versuchsdurchführung

Der zeitdiletierende Buffer scheint also in der TCP Strecke des ioBroker-Interfaces zu liegen.
Vermutlich werden auf diesem Weg die Buffer nicht entleert, was der virtuelle COM-Treiber von USRIOT zu tun scheint.

[klassisch]

Kann noch eine Beobachtung zufügen: Die Konfigurationsseite der virtuellen COM Schnittstelle auf dem ioBroker host (Win 10) hat einen Paketzähler "Net Received" im Bild rot umrandet.

Dieser Zähler zählt kontinuierlich die eingehenden Botschaften, unabhängig von der Einstellungdes Abtastintervalls im ioBroker und auch wenn der Adapter pausiert.
Hier scheint ein Unterschied im Vorgehen zu sein. Der virtuelle COM Port nimmt die Pakete anscheinend entgegen wie sie kommen und verwirft sie, wenn sie nicht abgenommen werden. Der ioBroker TCP Client scheint die Pakete in einen Buffer aufzunehmen und sie dann FiFo oder Schieberegisterartig der Applikation zuzuführen.
Aber alles laienhafte Spekulation aus dieser Beobachtung an der Oberfläche abgeleitet.

[apollon77]

@klassisch Scheinbar korrekt ... Es gibt bei tcp cockets kein "flush" in dem Sinne ... mal schauen was ich da tun kann ... ggf muss man immer lesen aber ignorieren, wohl das einfachste. Fix kommt in Update heute Abend, siehe GitHub issues für mehr infos

[klassisch]

@apollon77 Vielen Dank! Bin ja kein Experte und weiß nicht mal, ob das ein push- oder pull-Mechanismus ist. Ich stelle mir nur vor, man abonniert die Botschaft und der Server schickt dann, was er von serial bekommt. Und der Empfänger empfängt. Wenn er das mit Buffersize von einem Paket macht, müßte es klappen. Wenn das Paket gerade gebraucht wird es weiter gereicht, falls nicht, dann halt drop package. Aber eben eine naive Laienvorstellung und die Details sind sicher kompliziert.
Wäre aber schade, wenn man trotz einer TCP-Client Implementierung einen proprietären virtuellen COM Treiber installieren müßte.

[apollon77]

@klassisch Ist ja nicht sinn der Sache ... wenn es tcp kann dann richtig :-)

Fix kommt morgen denke ich

[klassisch]

Thema ist mit smartmeter Adapter Version 3.1.5 gelöst. Getestet mit 5s, 10s, 30s.
Danke an @apollon77 für den schnellen Fix.
Falls jemand wissen möchte, wie man die Smartmeterdaten über WLAN oder LAN überträgt -> https://forum.iobroker.net/topic/36936/guide-zwangsumstellung-auf-smartmeter-freut-euch-drauf
(Fertiglösungen + Selbstbaulösungen)