Läuft: Heizung mit eBus-Schnittstelle

[alpha1974]

So, dank Reinharts tatkräftiger Unterstützung (nochmals Danke an ihn!) kann ich jetzt auch mit meiner Gas-Therme kommunizieren.
Es handelt sich um eine CGB-2-14 von Wolf mit BM2-Bedienmodul am ebus. Das System scheint überaus geschwätzig zu sein und zahlreiche Messages sind wohl noch nicht in den csv-Files übersetzt; es gibt aber auch zahlreiche Klartext-Meldungen, an deren Auswertung ich mich die Tage machen will.

Beim Filtern des ebus-Logfiles auf Fehlermeldungen ist mir aber schon aufgefallen, dass die Therme (oder wer auch immer) in regelmäßigen Abständen "update broadcast error"-Nachrichten sendet. Hier ein Auszug aus dem Log (mit grep -i error):

Code Auswählen Erweitern

2016-02-09 18:18:31.841 [update notice] update broadcast error QQ=03: E000 18:17
2016-02-09 18:23:32.281 [update notice] update broadcast error QQ=03: E000 18:22
2016-02-09 18:28:32.848 [update notice] update broadcast error QQ=03: E000 18:27
2016-02-09 18:33:33.301 [update notice] update broadcast error QQ=03: E000 18:32
2016-02-09 18:38:33.838 [update notice] update broadcast error QQ=03: E000 18:37

Ist schon jemand dahinter gekommen, was das bedeuten mag?

Gruß
alpha1974

[cs-online]

@R2D2:

so ganz hab ich noch nicht geblickt, wie Du von der Hex auf die berechneten Werte kommst, hab gestern da rauf und runter mit allen möglichen Zerlegungen und Additionen / Multiplikationen etc. und nie kam da was sinnvolles bei rum...
Muss das die Tage nochmal mit mehr Werten machen, aber vor dem Wochenende komm ich da sicher nicht zu.
Die kleine Ungenauigkeit wäre für mich OK, ich will halt nur die ca. Momentanleistung berechnen und loggen können um z.B. die max Leistung besser einstellen zu können und weil ich einfach neugierig bin 
Es bleibt spannend

Grüße

Christian

[Sven77]

Das hat nix dem binärsystem zu tun.
/1000 -> Umrechnung im m³
/2 -> war mir aufgefallen, da immer die Hälfte der Differenz zwischen dem ersten gemessenen Wert und einem zweiten Wert den Unterschied ausmacht

Nun, das ist schon klar - wenn man sich aber die in ebusd eingebauten Datentypen ansieht, stellt man fest dass sowohl 2 (dann eben für dm³) oder 2048 gängige Divisoren sind.
Letztlich wollte ich auch nur davor warnen, zu schnell eine Formel zu entwickeln, die dann ggf. von noch unbekannten Faktoren abhängt und somit der Fehler irgendwann größer wird. Für eine simple Grafik, wann Leistungsspitzen oder Ruhephase auftreten, dürfte es wohl hinreichend genau sein, ja...

[RainerS]

@christian:

Code Auswählen Erweitern

0x05F5 = 1525 (Mittelwert aus den 3 Werten 0x05F3 - 0x05F5 - 0x05F7  --> 0x05F5, für 0,90)
0x074A = 1855 (für 1,08)

1,08 - (((1866 - 1525) / 2 ) / 1000 ) = 1,08 - 0,1705 = 0,9095

Möglicherweise ist der Ansatz mit dem Mittelwert noch zu ungenau (betrifft jetzt zufällig nicht o.g. Rechnung), da die Werte sehr schwanken (+- 8 Liter/h). Eine Berechnung der Normalverteilung könnte den Fehler nochmal
minimieren. Aber da gibt's bestimmt Spezialisten hier 

[Prof. Dr. Peter Henning]

Nix Normalverteilung, das ist doch keine Zufallsgröße !

Gefragt ist hier ein gleitender Mittelwert, siehe dazu meinen Beitrag im Fhemwiki.

LG

pah

[cs-online]

hallo,

würde mich PAH anschliessen. Und muss mich leider auch korrigieren, denn zum einen hab ich tatsachlich bei dem einen Wert von 0,96 eine 6 am Ende auf dem Zettel gehabt und zum zweiten: wenn ich meine 1,02 als Basis nehme, dann passen die Werte bis auf die 2. Nachkommastelle ! Nur die 1,08 weicht etwas ab...

Sehr cool und Super Leistung lieber R2D2 !!!

Werde die Tage noch weitere Messreihen aufnehmen, dazu werde ich erstmal besser drosseln müssen, um eine grössere Spreizung zu bekommen. Denke wir sind auf einem guten Weg, danke !!!

Grüsse Christian

[RainerS]

Gefragt ist hier ein gleitender Mittelwert,

äh, ja  ... wäre  ein Ansatz ...    

[cs-online]

Ja, vermutlich wird die Therme das intern über einen gleitenden Mittelwert über n Messungen gleitend darstellen. Wahrscheinlich müßte man bei den Aufnahmen dann auch den Median nehmen, weil der weniger ausreissergefährtet ist. Aber die Ungenauigkeiten in Summe werden für unsere Zwecke mehr als genau sein. Nur: Je weiter wir Richtung Null kommen, umso ungenauer wird das. Mit der Formel von Dir bekomme ich bei Null Volumenstrom (weil auf Nachtabsenkung ist die Pumpe aus) 0.121 m³/h... Evtl. brauchen wir da noch einen Korrekturfaktor / Offset. Aber im oberen Bereich trifft die recht gut.

Grüße

Christian

[Prof. Dr. Peter Henning]

Ab nächsten Dienstag habe ich endlich wieder etwas Zeit, dann werde ich endlich von der Uralt-Version des ebusd auf eine der neueren umstellen. Natürlich erst an einem 2. Buskoppler...
Dann sehe ich mir das Thema mal an.

Meine Vermutung ist, dass diese Datenlage auch mit der Art der Messung zu tun hat - nämlich über einen Vortex-Sensor. Schaut Euch mal dessen Messprinzip an.

LG

pah

[Marie01]

Guten Morgen!

Ich muss mich hier noch einmal zu Wort melden und brauch von euch Experten Hilfe 

Ausgangslage:
- VWL 102/3 s
- Raspberry mit Jessie
- neueste ebusd Version samt Configuration
- eBus Koppler Ethernet von E-Service

Meine Wärmepumpe von Vaillant besteht aus folg. Komponenten:
- Innengerät mit integrierten WW-Speicher
- Bedienteil
- Außengerät mit Wärmetauscher und Lüfter

Mittlerweile funktioniert mein ebusd. Ich kann Werte lesen und schreibe. Einziges Problem, ich bekomme das Außengerät (Busadresse 0xE0) nicht gescannt.

Code Auswählen Erweitern


pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 45
masters: 3
messages: 632
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"


Was habe ich in der Zwischenzeit schon verändert/probiert:
- Poti mehrmals justiert (feinjustiert) mit der Hoffnung, dass 0xE0 dann gescannt wird
- ebusd Verkabelung direkt auf die Reglerplatine (Ebus-Klemme) geklemmt
- Aktive Meldungen vom Bedienteil an das Außengerät geschickt und mit ebusctl scan full und dann ebusctl scan result kontrolliert ob der Busteilnehmer vorkommt

Habt ihr noch eine Idee was ich machen kann?

Danke.

Marie

[RainerS]

Mit der Formel von Dir bekomme ich bei Null Volumenstrom (weil auf Nachtabsenkung ist die Pumpe aus) 0.121 m³/h... Evtl. brauchen wir da noch einen Korrekturfaktor / Offset. Aber im oberen Bereich trifft die recht gut.

Wenn die Pumpe aus ist, gibt's eigentlich auch keinen Wert, zumindest hatte ich keinen gemessen bzw. er war Null (0x020000)

Da trotz Nachtabsenkung ein Wert vorhanden war, prüfe bitte ob die Pumpe nicht doch läuft. Wenn ja, wäre das der Wert des Durchflusses für das Übertrömventil, welches zum Schutz der Pumpe verbaut ist und bei komplett geschlossenen Heizkreisen zum Rücklauf überbrückt und damit einen geringen Durchfluss verursacht.

Ich wusste von diesem Ventil und hatte daher das System von der anderen Seite her betrachtet (max. Durchfluss) und damit bei einem geschlossenen Überströmventil.

[cs-online]

Hallo zusammen,

nachdem R2D2 super Vorarbeit geleistet hat, und ich gestern beim ,,ins FHEM basteln" festgestellt hatte, daß die Ungenauigkeit Richgung Null immer größer wurde, habe ich heute morgen nochmal gehirnt und dann fiel es mir wie Schuppen aus den Haaren: Es muss doch eine lineare Abhängigkeit zwischen den D.29 und den hex-Werten geben ! Damit muss die Gleichung die Form Y=m*X+b haben.
Nehme ich den obersten Punkt mit X=1866 und Y=1,08 und als zweiten Punkt X=0 und Y=0, dann ergibt sich die Gleichung sinngemäß (bei meinen Werten) mit  Vpunkt=(1,08/1866)*X mit X dem dezimalen Wert für die hex-Werte, also zusammengesetzt aus 5.-6. Stelle und 3.-4. Stelle. Rein geexecelt habe ich so eine max. Abweichung von 0,01m³/h, also 10 Liter pro Stunde, das sollte genau genug sein, um damit auch die Leistung über (Vorlauf-Rücklauf)*Volumenstrom  zu berechnen.

Könnt Ihr das mal mit Euren Werten gegenchecken ?

Übrigens kommt bei Nachtabsenkung (da ist meine Pumpe wirklich aus) bei mir 020000, also 0m³/h raus

Grüße Christian

[cs-online]

Hi Marie,
du könntest mal mit "ebusctl grab" probieren, dann direkt danach Befehl über die Bedieneinheit an die Ausseneinheit schicken, dann "ebusctl grab result", dann müsste er alle unbekannten Nachrichten ausgeben, dann müsstest Du anhand des Anfangs der Nachricht, wo die Sender- bzw. Empfängeradresse dran ist sehen können, wie die miteinander reden...

[Marie01]

Hi Christian!

Das werde ich mal probieren, danke für den Input.
Ich habe mir heut die ebusd.log genauer angeschaut und hier taucht die 0xE0 (=Außeneinheit, OMU) auf, jedoch mit:

Code Auswählen Erweitern

[bus error] scan e0 failed (25 slaves left): ERR: ACK error

Hast du eine Ahnung was diese Fehlermeldung bedeuted?

[RainerS]

@cs-online: wer lesen kann ... ;habe jetzt bemerkt, dass "Null" bei Deiner Berechnung rausgekommen ist  und nicht vom eBus gelesen wurde.

Was wir jetzt nicht feststellen können, welcher Anteil des Volumenstroms (je nach Ventilstellungen am Heizkreisverteiler) durch das Überströmventil direkt wieder zum Rücklauf geführt wird und somit nicht zum Aufheizen genutzt wurde.