Läuft: Heizung mit eBus-Schnittstelle

[Prof. Dr. Peter Henning]

Was ist denn gemeint mit "Volumenstrom, der gerade im Umlauf ist" ? Wo sollte der Volumenstrom denn sonst sein ?

Vaillant nennt dies die Umlaufwassermenge, und es ist unklar, ob das tatsächlich die direkte Auslesung des internen Vortex-Sensors ist (und welche Einheiten das sind, und wie genau die Messung ist...). Wenn das der Fall wäre, könnte man einfacherweise mit der hier angegebenen Rechnung

http://www.fhemwiki.de/wiki/Ertragsmessung_Solarthermie

(allerdings ohne die Spezialitäten von Tyfocor) die Leistungsmessung druchführen.

LG

pah

[Stütti]

...
Jetzt frage ich mich nur, was ich am Raspberry ändern muss, damit es auch darauf sauber läuft. Bei anderen läuft das ja auch!?
- Betriebssystem ist derzeit Raspian. Wechseln? Arch Linux?
- NTP läuft darauf per default.
- Kann es ggf. an der Spannungsversorgung des ebus-Kopplers (eservice) liegen? Der hängt derzeit direkt am USB des Raspberry Pi 2.

Habe es jetzt getestet. Andere Netzgeräte ergaben das gleiche Ergebnis.
Dennoch läuft es jetzt auf dem Raspberry. Die Lösung derzeit ist: Erst ebusd laufen lassen, dann Fhem starten.

Die Ursache ist mir noch nicht ganz klar. Folgende Zeilen im Fhem-Logfile machten mich stutzig:

Code Auswählen Erweitern

2015.12.15 20:29:20 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
2015.12.15 20:29:25 3: Setting TCM_ESP2_0 serial parameters to 9600,8,N,1
2015.12.15 20:29:25 1: /dev/ttyUSB0 reappeared (TCM_ESP2_0)
2015.12.15 20:29:26 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
2015.12.15 20:29:31 3: Setting TCM_ESP2_0 serial parameters to 9600,8,N,1
2015.12.15 20:29:31 1: /dev/ttyUSB0 reappeared (TCM_ESP2_0)

Gruß
Benjamin

[Reinhart]

Hallo Benjamin!

immerhin hast du den Fehler ja schon gefunden, liegt offensichtlich bei der seriellen Kommunikation die ständig abbricht und ein Reconnect versucht wird.

Was ist denn das überhaupt für eine Device der "TCM_ESP2_0" ? Ist das der eBus Koppler? Mach sonst einmal ein "lsusb" am Raspi und poste das. Eventuell kannst du ja Fhem einmal stoppen und schauen ob diese Fehlermeldung dann auch noch kommt und ob dies einen Einfluss auf die Fehlermeldungen des eBuslog hat.

Wie hast du den Koppler angeschlossen, ist der nahe dem Raspi oder näher dem eBus der Therme. Das eBuskabel ist von der Länge her eher unkritisch (20 Meter sollten auch nichts machen), aber das USB Kabel würde ich von der Länge als kritischer sehen und möglichst kurz halten und könnte ohne weiteres die Ursache der Reconnects sein. Der "reappeared" kommt ja dann wenn nach einem Timeout keine Antwort kommt, dann versucht er es einfach wieder und wieder.....

Was mich noch wundert, die Baudrate wird hier mit 9600 ausgegeben, aber laut Doku des Kopplers soll der auf 2400 eingestellt sein. Aber ich kenne diesen Koppler nicht und kann daher auch nicht genau sagen ob das passen sollte, lies hier vielleicht in deiner Doku noch einmal genau nach. Aber vielleicht ist dieser Device ja nicht dein Koppler, das wissen wir erst nach "lsusb" genauer. Oder es meldet sich jemand der diesen Koppler hat und schaut nach wie der sich bei ihm anmeldet.

LG
Reinhart

[Stütti]

Hallo Reinhart,

das "TCM_ESP"-Gerät besitze ich gar nicht - ist wohl ein EnOcean-Gateway.
Laut FHEM-HowTo wird beim Start von FHEM standardmäßig nach angeschlossenen USB-Gräten gesucht (initialUsbCheck) und ggf. automatisch in die fhem.cfg geschrieben.
Mein Koppler (eService) wurde wahrscheinlich falsch erkannt und erzeugte damit folgende Zeile in der cfg:

Code Auswählen Erweitern


define TCM_ESP2_0 TCM ESP2 /dev/ttyUSB0@9600

daher auch die 9600 Baud.

Ich habe den initialUsbCheck auskommentiert und daher läuft es nun.

Danke für den Support!
Gruß
Benjamin

[Reinhart]

Hallo Benjamin!

Freut mich wenn das nun zur Lösung deines Fehlers beigetragen hat und nun fehlerfrei läuft.
Diese Art von Fehler kannte ich nicht, da ich einen eigenen Raspi (b+) habe auf dem der eBus läuft. Auf diesem Raspi läuft keine Fhem Instanz und die Kommunikation erfolgt einfach via ECMD und die serielle USB Schnittstelle steht alleine für den FTDI Adapter zur Verfügung.

Das hat zusätzlich den Vorteil, dass ich am eBus basteln und testen kann ohne FHEM weiter zu beeinflussen. Der Nachteil ist halt der doppelte Stromverbrauch des Raspi, aber davon habe ich schon 3 Stück in Betrieb weil ich einen Raspi2 noch zusätzlich im Stromverteiler eingebaut habe um 3 x S0 Zähler direkt über GPIOs zu erfassen. Mir persönlich ist eine klare Trennung der unterschiedlichen "Module" lieber, aber das muss jeder für sich selbst entscheiden wie es besser ins Gesamtkonzept passt.

LG
Reinhart

[cs-online]

Hallo PAH,

ich gehe mal davon aus, daß mit D.29 der Volumenstrom gemeint ist, den die Pumpe aktuell durch das System drückt. Die Einheit dürfte m³/h sein, denn wenn ich Warmwasser bereite, dann liegt das bei ca. 1, mein Wärmemengenzähler am Speicher zeigt dann auch ca. 1m³/h mit Einheit an. Die Berechnung der Momentanleistung, die gerade vom Gesamtsystem abgenommen wird, wäre also kein Problem über Delta T (Vorlauf-Rücklauf). Für den Warmwasserkreis habe ich so eine Schätzung, weil ich dort 1m³/h "annehme", weil der Speicherkreis ja konstanten Durchfluss haben sollte (es ändert sich ja dort nichts während der Bereitung). Für den Heizkreis kann ich das ohne den D.29 nicht schätzen, weil die Pumpe auch bei fest eingestellten 50% und Energiespar an trotzdem immernoch ein wenig regelt. Außerdem ändert sich ja auch ständig was an den Thermostatventilen. Hundertprozentig genau müßte das ja garnicht mal sein. Also: Wäre schön, wenn man den D.29 auslesen könnte John hatte mir im Mikrocontroler-Forum auch schon den Tip mit Grab/grab result gegeben, aber bei mir und einem anderen aus dem Forum hat das leider nicht so geklappt, deshalb hatte ich die Hoffnung, im FHEM-Kreis hätte es schon einer heraus gefunden.

Schöne Grüße

Christian

[john30]

hat evtl. schon einer die Adresse für D.29 herausgefunden ? Das ist der Volumenstrom, der tatsächlich grad im Umlauf ist. Ich würde den gerne nutzen um die tatsächlich abgegebene Leistung berechnen zu können.... Alle Versuche (auch mit Johns Hilfe) sind bislang leider nicht erfolgreich gewesen...

Versuch mal "w -h 08b509030dfb00" und teile das Ergebnis durch 100.
Wenn da sowas ähnliches wie der angezeigte d.29 Wert rauskommt, wäre mal Dein scan result interessant

VG John

[ms_9]

Hallo PAH,

ich gehe mal davon aus, daß mit D.29 der Volumenstrom gemeint ist, den die Pumpe aktuell durch das System drückt. Die Einheit dürfte m³/h sein, denn wenn ich Warmwasser bereite, dann liegt das bei ca. 1, mein Wärmemengenzähler am Speicher zeigt dann auch ca. 1m³/h mit Einheit an.

Gemäß "Installations- und Wartungsanleitung auroCompact" steht bei mir in der Tabelle "d.29 - Messwert des Durchflusssensors - in m 3 /h"

[cs-online]

Hallo,

@ John: bei D.29 = 1.02 kommt mit  "w -h 08b509030dfb00" -> 02bf06, wenn sich der Rechner nicht vertut, müßte das 179974 Dez entsprechen, also 1799,74, passt also leider nicht... schade. Der Wert schwankte auch bei mehrmaligem Abfragen ein wenig, aber im Display blieb es (sprang einmal kurz nach 0.96 und zurück) konstant.

@MS_9:Messwert des Durchflusssensors - in m 3 /h, ist bei meiner EcoTec Exclusiv auch so, würde ich deshalb doch wohl meinen, daß das ein Volumenstrom ist. Wenn ich Warmwasser bereiten lasse, dann liegt der bei ca. 1m³/h, was sich mit dem Wärmemengenmesser deckt. Bei Heizbetrieb schwankt das meist deutlich drunter.

Grüße

Christian

[john30]

@ John: bei D.29 = 1.02 kommt mit  "w -h 08b509030dfb00" -> 02bf06, wenn sich der Rechner nicht vertut, müßte das 179974 Dez entsprechen, also 1799,74, passt also leider nicht... schade. Der Wert schwankte auch bei mehrmaligem Abfragen ein wenig, aber im Display blieb es (sprang einmal kurz nach 0.96 und zurück) konstant.

nicht ganz, denn das erste Byte der Antwort "02" ist die Länge und der Rest sollte in UIN codiert sein. Damit wäre der Wert 1727, was aber immer noch nichts mit dem realen Wert zu tun haben scheint.
Der Punkt ist: es gibt von der BAI mindestens 6 verschieden Varianten, die sich in den Messages teilweise deutlich unterscheiden. Ausschlaggebend für die Auswahl der richtigen Variante ist das Scan Result und hier insbesondere die HW Version. Schau doch mal nach, was Deine BAI so dazu sagt, dann kommen wir dem Ziel vielleicht etwas näher.
In zwei der 6 BAI Varianten gibt es den Wert d.29 und dieser ist ein Mal als UIN definiert mit Einheit "l/h" und ein Mal als UIN geteilt durch 100 ohne Einheit.
1727 durch 100 ist scheint aber auch noch nichts mit 1.02 zu tun zu haben. Es sei denn, das UI gibt noch einen Faktor drauf und der UIN Wert ist lediglich eine Darstellung der Rohdaten...

VG John

[cs-online]

Hi John,

hier der Scan / Scan result:

localhost: scan result
08;Vaillant;BAI00;0703;7401
15;Vaillant;47000;0126;6002

Grüße

Christian

[john30]

hier der Scan / Scan result:
localhost: scan result
08;Vaillant;BAI00;0703;7401

Tja, damit sind die potentiellen d.29 Messages für HW Version 6701 und 0902 definitiv nicht passend.
Du kannst ja mal ein bisschen beobachten, ob es einen Zusammenhang zwischen dem angezeigten d.29 Wert und dem Ergebnis von "w -h 08b509030dfb00" gibt. Vielleicht lässt sich so ein Faktor determinieren, der vom UI auf den Wert angewendet wird.

Schöne Weihnachten an alle,
John

[rufus999]

Hallo zusammen,

und frohe Weihnachten!

Vielleicht kann mir jemand einen Tipp geben. Ich habe einen ebus-Koppler vom Weihnachtsmann bekommen 
Ich bin dann gleich dem Wiki von FHEM und John30 gefolgt.

Habe soweit ebusd auf einem raspi per .deb Packet in der Version 1.3.0 installiert und soweit wie ich es verstanden habe konfiguriert. Im Ordner /etc/ebusd/ liegen folgende Files:
- 430.csv
- bai.csv
- broadcast.csv
- common.csv
- scan.csv
- _templates.csv
diese Dateien habe ich alle aus dem git 1.x.x "Verzeichnis" geladen (nicht verändert).
Welche ich nehmen musste, habe ich anhand des scans ermittelt.
Meine Heizung ist eine auroCompact VSC S 196/3-5 200 mit calorMatic 430. Außerdem sind zwei Solarpanels auf dem Dach für Warmwasser.

Wenn ich nun den ebusd laufen lasse "ebusd -f -l All -d /dev/ttyUSB0" erhalte ich folgende Ausgaben (siehe Anhang).
Kann mir jemand erklären was das für ein Error ist? Oder was der unknow BC ist?

Ich kann über ebusctl Daten auslesen und auch schreiben. Wie z.B. die Heizkurve ändern und den Status des Heizkreises auf "Aus", "Auto" und "Manuel" ändern.

Vielen Dank im Voraus.

[john30]

Wenn ich nun den ebusd laufen lasse "ebusd -f -l All -d /dev/ttyUSB0" erhalte ich folgende Ausgaben (siehe Anhang).
Kann mir jemand erklären was das für ein Error ist?

Also "ERR: element not found" beim Dekodieren des Status01 liegt daran, dass der Wert 4 für den Pumpenstatus noch nicht definiert ist. Kannst Du mal vielleicht im Handbuch nachschauen, ob es da irgendeinen Spezialwert gibt? Vielleicht Frostschutz oder sowas?
Werde mal einbauen, dass unbekannte Werte einfach als Zahl ausgegeben werden, dann passiert sowas künftig nicht mehr.

Oder was der unknow BC ist?

Die "unknown" Einträge im Log sind schlicht Nachrichten, die noch nicht dekodiert werden, weil sich a) noch keiner die Mühe gemacht hat oder b) der Inhalt unbekannt ist. Für a) gibt es das Ticket https://github.com/john30/ebusd-configuration/issues/3 um die ganzen unbekannten und gesehene Werte zu sammeln.

Ich kann über ebusctl Daten auslesen und auch schreiben. Wie z.B. die Heizkurve ändern und den Status des Heizkreises auf "Aus", "Auto" und "Manuel" ändern.

Das ist eine Frage, oder?
Die Heizkurve kannst Du z.B. mit "ebusctl write -c 430 Hc1HeatCurve 0.25" einstellen, Heizkreis mit "ebusctl write -c 430 Hc1OPMode off" ausschalten (respektive "manual" oder "auto").

[rufus999]

Hallo John30,

vielen Dank für deine schnelle Antwort.
Okay verstehe. Ich werde mal in der Anleitung nach sehen. Das Ändern der Heizkurve und Heizkreis funktioniert.

Danke