Was heißt "overrun"

[djd1983]

Hallo zusammen,
bei mir wird eine Vaillantheizung betrieben, die zum einen das gespeicherte Wasser via Solarthermie und Brenner erwärmen kann und dann noch die "normalen" Heizungskörper mit Wärme versogt. Anbei ein Schaltbild.

Die Zirkulationspumpen sind nicht vorhanden.
Nun bin ich sehr technikinteressiert und ich meine auch sehr informationstechnisch affin und habe daher Experimente mit dem EBus angefangen. Hier gelang es mir den EBus mittels eines EBusadapters und dem "Ebusdaemon" auszulesen. Ausgelesene Werte werden mir via MQTT zum Anzeigen angeboten. Anbei eine Übersicht der Broadcast Werte.

Nun kommt es ca. 2 mal am Tag vor, dass der Wert "off" von Status01 auf "overrun" wechselt. Zumeist ca 10-15 Min lang. Dabei wird die Zielvorlauf- und Rücklauftemperatur, die ersten beiden Werte unter Status01 (hier 45.0 und 44.5°C) auf 75 Grad gesetzt. Beim ersten Wert von SetMode steht eine drei, was nach meinen Recherchen zunächst heißen würde, dass lediglich die Warmwasseraufbereitung aktiv ist.
Hat einer eine Idee was das für ein Modus ist? Oder handelt es sich vielleicht um einen Fehler?

Viele Grüße und einen schönen Rosenmontag

Sepp

 

[djd1983]

Da ich es gerade zufällig wieder sehe ...

Gruß

 

[Brennwärter]

Scheint nach einem Buffer Overrun, bedeutet, dass die Anlage mehr Daten in den Speicher schreiben (und dann auf dem Ebus senden) wollte, als in das für selbige Daten vorgesehene Speichersegment passen, und deswegen nachfolgende Bits überschrieben hat. Als Beispiel: Wenn die Steuerung für diesen Datenblock 200 Bits eingeplant hat, und 184 Bits schreibt, geht alles gut, aber wenn Sie 216 Bits schreibt, überschreibt sie die nachfolgenden 2 Bytes (16 Bits) mit dem Kram, der nicht mehr passt. Das ist auf dem Ebus evtl. eine Art "Warentrenner" für Werte, welcher dann halt von den übergelaufenen Daten stumpf plattgefahren wird, was dein Gateway erkennt, und dir als "Overrun" anzeigt. Kann auch sein, dass die Therme intern einen größeren Speicherbereich als der Ebus verwendet, also z.B. 240 Bits, wobei auf dem Bus eigentlich nur 200 übertragen werden können, woraufhin die restlichen 40 dann nicht verworfen werden, sondern irgendwo reingeraten.

 

[djd1983]

Hallo Brennwärter,

vielen Dank für Deine Nachricht. Jedoch bin ich aufgrund der Gesamteindrücke der Faktoren unschlüssig, ob eine "(Elektronische-)Speicherüberflutung" tatsächlich die Ursache sein könnte. Das MQTT Format ist eigentlich kein Format welches interpretiert, sondern lediglich Daten einfach weitergibt wie sie rein kommen. Die EBusd Datenbank arbeitet meines Wissens eigentlich auch nur mit Begriffen, die vorher eingegeben und bestimmten Hexadezimalausgaben zugeordnet wurden. D. h. ich denke schon, dass es sich bei "overrun" irgendwie um eine (Heizungs-)interne Funktion handeln könnte. So ist mir eben auch folgendes im EBusLog aufgefallen:

1) 2024-02-14 16:59:13.479 [update notice] received write vr_70 SetActorState QQ=10: off;off;off;off;on;off;off
2) 2024-02-14 16:59:22.494 [update notice] received read bai Status01 QQ=10: 37.5;35.5;-;-;-;off
3) 2024-02-14 16:59:22.786 [update notice] received read vr_70 SensorData QQ=10: 45.00;19.81;-;-;12.56;16.25;c8 50 00
4) 2024-02-14 16:59:23.054 [update notice] received update-write bai SetMode QQ=10: auto;42.0;-;-;0;0;0;0;0;0
5) 2024-02-14 16:59:23.310 [update notice] received read bai Status02 QQ=10: auto;60;75.0;70;70.0
6) 2024-02-14 16:59:23.567 [update notice] received write vr_70 SetActorState QQ=10: off;off;off;off;on;off;off
7) 2024-02-14 16:59:32.533 [update notice] received read bai Status01 QQ=10: 37.5;35.5;-;-;-;off
8) 2024-02-14 16:59:32.825 [update notice] received read vr_70 SensorData QQ=10: 44.94;19.81;-;-;12.38;16.25;c8 50 00
9) 2024-02-14 16:59:33.093 [update notice] received update-write bai SetMode QQ=10: auto;42.0;-;-;0;0;0;0;0;0
10) 2024-02-14 16:59:33.609 [update notice] received write vr_70 SetActorState QQ=10: off;off;off;off;on;off;off
11) 2024-02-14 16:59:37.658 [update notice] received update-write bai SetMode QQ=10: 3;-;-;150;1;0;0;1;0;0
12) 2024-02-14 16:59:40.682 [update notice] received update-write bai SetMode QQ=10: 3;-;-;150;1;0;0;0;0;0
13) 2024-02-14 16:59:42.628 [update notice] received read bai Status01 QQ=10: 38.0;35.0;-;-;-;off
14) 2024-02-14 16:59:42.923 [update notice] received read vr_70 SensorData QQ=10: 44.88;19.75;-;-;12.75;16.25;c8 50 00
15) 2024-02-14 16:59:43.192 [update notice] received update-write bai SetMode QQ=10: 3;-;-;150;1;0;0;0;0;0
16) 2024-02-14 16:59:43.666 [update notice] received write vr_70 SetActorState QQ=10: off;off;off;off;off;off;off
17) 2024-02-14 16:59:52.961 [update notice] received read bai Status01 QQ=10: 44.0;38.5;-;-;-;overrun

Gegen 16:59 Uhr habe ich Warmwasser benötigt. Und aus den bekannten Daten wurde augenscheinlich dabei bestimmte Heizungseinstellung, mutmaßlich zur schnellen Erhitzung des jetzt fehlenden warmen Wassers vorgenommen. In Zeile 2 sieht man die "regulären" Daten wie ich sie schon oben beschrieben habe.

Status01 QQ = akt. Vorltemp / akt Rücklauft / - / - / - / Status der Heizungspumpe off-on-overrun (Vermutung)

Genauso sieht man auch bei SetMode Änderungen (Zeilen 9 und 11). Der erste Wert ist sonst immer auf "auto", schaltet sich jetzt aber auf 3. Vielleicht ein Schaltzustand des Ventils zwischen Warmwasser und Heizung, sprich autmatische Regelung / 1 für Heizungsaktivität / 2 für ??? / 3 für Warmwasser?

Bei soeben durchgeführten weiteren Recherchenb bin ich auf diese Erklärung, leider nur in englsich gestoßen

KCS UK

Es wird von einer Funktion gesprochen, die Überhitzung durch zu heißes Wasser im Boiler, sprich im Hauptgerät, vermeiden soll, indem die Pumpe einfach nur "wild" das Wasser in den Kreislauf pumpt. Die Temperaturen sprechen aber meines erachtens dagegen, da keine Temperatur an die 100°C geht.

Kann das hier jemand aus dem Alltag hier nachvollziehen?

 

[Brennwärter]

Jetzt wird's mir klar! Das ist der Pumpennachlauf, aber irgendwer hat das wohl mit Google Übersetzer übersetzt... Korrekter wäre shutoff delay oder run-on. Das bedeutet, dass die Pumpe nach abschaltung des Brenners noch weiterläuft, um heiße Bauteile abzukühlen und Restwärme zu nutzen. Betriebsablauf ist normalerweise Aus-An-Nachlauf-Aus. Das würde auch mehr Sinn ergeben, denn wenn ein Ende des Datenbusses (Ebus-Adapter oder Therme) einen Overrun erkennen kann, warum repariert man dann als Programmierer nicht gleich das Problem (oder das defekte Datenpaket), anstatt eine solche Erkennung zu bauen, welche dann einfach "PROOOBLEEEEM!!!" schreit, und nichts verbessert?