Läuft: Heizung mit eBus-Schnittstelle

[bmwfan]

@John: Heureka! Die Datei wurde geladen. Jetzt mache ich mich mal ans Testen der Parameter.

Besten Dank

Gruß Jürgen

[bacanol]

Habe nun Dank der Hilfe von John alles an den Start bekommen. Eine Sache fehlt mir noch, der HK2 direkt am VCR 620, siehe Anlage. Habe dort die eine FBH angeschlossen, die zweite am VR60. letztere sehe ich auch schön aufgeführt und kann die Werte entsprechend ändern bei Bedarf.

Code Auswählen Erweitern

Readings
Heizkurve
0.50
2017-01-12 16:19:31
Ist_Vorlauftemperatur
29.38
2017-01-12 16:19:31
Max_Vorlaufsolltemperatur
45
2017-01-12 16:19:31
Solltemperatur
25.0
2017-01-12 16:19:31
Solltemperatur_Absenken
20.0
2017-01-12 16:19:31
bzw

Code Auswählen Erweitern

r~mc~FlowTempDesired~Vorlaufsolltemperatur
Vorlaufsolltemperatur
deleteattr
r~mc~FlowTempMax~Maximaler_Vorlaufsollwert
Max_Vorlaufsolltemperatur
deleteattr
r~mc~FlowTemp~VF1_Sensor
Ist_Vorlauftemperatur
deleteattr
r~mc~HeatingCurve~Heizkurve
Heizkurve
deleteattr
r~mc~TempDesiredLow~Absenksollwert
Solltemperatur_Absenken
deleteattr
r~mc~TempDesired~Solltemperatur
Solltemperatur

Leider gibt mir die CSV Datei für den 620er nur den HK1 bis jetzt, an dem meine Therme klemmt.

Hat jemand eine Idee, wie ich weiter kommen kann?

[mirror]

Ich habe Probleme mit der Decodierung der DCFTimeDate in meiner bai. Ich verwende die aktuelle ebusd git Version.

Dieser Eintrag ist ja in vielen bai csv'en drin:

Code Auswählen Erweitern

r,,DCFTimeDate,DCF Datum/Uhrzeit,,,,"E500",,,btime;bdate,,,DCF Time / date stamp struct { uchar sec; uchar min; uchar std; uchar tag; uchar mon; uchar wtg; uchar jah; } Tdcf77_time;

Ein hex Auslesen ergibt:
08b509030dE500 / 072218150c010411

Diese 7 Bytes ergeben 21Uhr 24min 34 sek 12. Jan. 4. Tag Jahr 17.
Also alles OK.

Wenn ich aber das ebusctl read gebe kommt:
pi@raspberrypi:~ $ ebusctl r DCFTimeDate
ERR: argument value out of valid range in decode

Ich habe auch schon mal einen richtig decodierte Parameter gesehen.

[Sven77]

Code Auswählen Erweitern

r,,DCFTimeDate,DCF Datum/Uhrzeit,,,,"E500",,,btime;bdate,,,DCF Time / date stamp struct { uchar sec; uchar min; uchar std; uchar tag; uchar mon; uchar wtg; uchar jah; } Tdcf77_time;

Ein hex Auslesen ergibt:
08b509030dE500 / 072218150c010411

Diese 7 Bytes ergeben 21Uhr 24min 34 sek 12. Jan. 4. Tag Jahr 17.

Da scheint ein Bock drin zu sein; in meiner Version war das noch als HEX:8 definiert, was auch falsch ist - mit HEX:7 klappte es.
Die btime und bdate sind in den Templates als BTI und BDA definiert, also BCD codiert - es ist aber eher HEX codiert...

Versuche mal "btime;bdate" durch "HTI;HDA" zu ersetzen. Wenn das klappt, könnte man besser noch "hdate" und "htime" Templates erstellen, ich habe jetzt keine gefunden.

[alpha1974]

Zu Hülf, ich habe ein vermutlich trivial zu lösendes Problem und bin doch zu blöd, es zu lösen:

Ich kann mit ebusctl hex die Raumtemperatur meines Raumthermostaten (Wolf BM2) auslesen. Aber ich kriege das einfach nicht in eine csv-Zeile umgewandelt.

Code Auswählen Erweitern

root@raspberrypi2_ebusd:/home/pi# ebusctl hex 3550220377b427
02e100

Die Temperatur steckt im zweiten Byte der Antwort:
hex e1=dezimal 225 = 22,5 Grad Celcius, sprich Byte 2 in dezimal umrechnen * 0,1 = aktuelle Temperatur.

Wie lautet denn wohl die passende CSV-Zeile?


EDIT: Ich konnte es doch lösen, des Rätsels Lösung:

Code Auswählen Erweitern

#################################
# 3550220377b427 Raumtemperatur #
#################################

r,betrd_bm2,raumtemp,Raumtemperatur (35->50),,35,5022,77b427,,,UIN,10,°C,,,,,,,,


[mirror]

Da scheint ein Bock drin zu sein; in meiner Version war das noch als HEX:8 definiert, was auch falsch ist - mit HEX:7 klappte es.
Die btime und bdate sind in den Templates als BTI und BDA definiert, also BCD codiert - es ist aber eher HEX codiert...

Versuche mal "btime;bdate" durch "HTI;HDA" zu ersetzen. Wenn das klappt, könnte man besser noch "hdate" und "htime" Templates erstellen, ich habe jetzt keine gefunden.

Hallo Sven,

danke das geht sofort. Was meint John dazu?

Gruß,
Dietmar

[john30]

danke das geht sofort. Was meint John dazu?

Na dann halt in hex Am besten htime und hdate in _templates dazu definieren und dann in den bai's entsprechend verwenden.

[lewej]

Hallo Zusammen,

ich habe eine geotherm 61/3 s mit dem ebusd am laufen.

Ich habe immer wieder unknown Messages drin, sind das Messages die der ebusd nicht kennt, fehlende csv oder sind das Fehler auf dem EBUS?

Code Auswählen Erweitern


2017-01-16 19:17:44.516 [updatenotice]unknown 1050b505072b000100000000 / 00
2017-01-16 19:17:48.764 [updatenotice]unknown 1025b5040132 / 0a00000000000000010000
2017-01-16 19:17:48.914 [updatenotice]unknown 1025b5040131 / 020000
2017-01-16 19:17:52.531 [updatenotice]unknown 10feb505034a0400 
2017-01-16 19:17:54.394 [updatenotice]unknown 1025b505072b000100000000 / 00
2017-01-16 19:17:55.994 [updatenotice]unknown 03e0b5210500050600e7 / 09010690ffb2ff073943
2017-01-16 19:17:56.706 [updatenotice]unknown 03e0b509040e3a0000 / 00
2017-01-16 19:17:57.707 [updatenotice]unknown 03e0b509040e480000 / 00
2017-01-16 19:17:58.842 [updatenotice]unknown 1023b5040132 / 0a00000000000000010000
2017-01-16 19:17:58.992 [updatenotice]unknown 1023b5040131 / 020000
2017-01-16 19:18:03.114 [updatenotice]unknown 10feb505034a0400 
2017-01-16 19:18:04.641 [updatenotice]unknown 1023b505072b000100000000 / 00
2017-01-16 19:18:08.858 [updatenotice]unknown 1050b5040132 / 0a00200603010000010100
2017-01-16 19:18:09.009 [updatenotice]unknown 1050b5040131 / 020001
2017-01-16 19:18:11.741 [updatenotice]unknown 10feb51603040001 
2017-01-16 19:18:12.760 [updatenotice]unknown 10feb505034a0400 
2017-01-16 19:18:14.643 [updatenotice]unknown 1050b505072b000100000000 / 00
2017-01-16 19:18:16.433 [updatenotice]unknown 03e0b5210500050600e7 / 0901068fffb2ff073a43
2017-01-16 19:18:17.003 [updatenotice]unknown 03e0b509040e3a0000 / 00
2017-01-16 19:18:17.622 [updatenotice]unknown 03e0b509040e480000 / 00
2017-01-16 19:18:18.950 [updatenotice]unknown 1025b5040132 / 0a00000000000000010000
2017-01-16 19:18:19.098 [updatenotice]unknown 1025b5040131 / 020000


Gruss

[galileo]

Ich kämpfe jetzt seit Wochen mit dem Auslesen der Werte aus meiner Auromatic 620 und VR60/3. Fast alles funktioniert schon, aber bei der Auromatic
fehlt mir noch das Auslesen des Zustandes vom Ausgang "MA".
Das ist jener Ausgang, welcher anspricht, wenn TD1 grösser/kleiner als TD2 wird (mit Hysterese).
TD1 kann ich auslesen. Das ist Storage4Sensor3 im ec.solsy.sc.csv. Ebenso TD2, das ist SumBackflowSensor ebendort.
Auch die Hysterese kann mit DeltaTOnFlexDtController und DeltaTOffFlexDtController bestimmt werden.
Ich könnte also theoretisch errechnen, ob der Ausgang MA geschaltet werden sollte. Aber eben nur "sollte". Ob er es tatsächlich wird, möchte ich gerne vom Bus auslesen.
Ich habe leider keinen Eintrag im csv gefunden, der dem tatsächlichen MA Ausgang entspricht.

Deshalb meine Bitte: kann mir jemand sagen, ob dieser Wert existiert, oder ob er existieren sollte aber bisher noch nicht gefunden wurde,
ob ich danach suchen könnte und wie ich diese Suche im Fall der Fälle angehen soll.

Vielen Dank für einen Hinweis
Eduard

[Sven77]

Deshalb meine Bitte: kann mir jemand sagen, ob dieser Wert existiert, oder ob er existieren sollte aber bisher noch nicht gefunden wurde,
ob ich danach suchen könnte und wie ich diese Suche im Fall der Fälle angehen soll.

Ich habe keine VRS620, dafür die VRC700 - von der war anfangs gar nichts bekannt.

Sieht so aus, als würde die 620 "nur" auf die normalen b509 reagieren. Auslesen lassen sich diese mit 0d und 2 zusätzlichen Bytes.
Laut CSV scheint die 620 generell im letzten Byte 00 oder 08 zu haben. Also könnte man ein Script schreiben, was 2x 255 Nachrichten per Hex abfragt:

Code Auswählen Erweitern

ebusctl hex ecb509030dxx00
ebusctl hex ecb509030dxx08

Wenn Du sicher bist, dass in der CSV kein entsprechender Wert vorhanden ist, könnte man die bekannten Messages auslassen.
Und dann heisst es warten: das Script zu verschiedenen Zeiten ausführen und danach per diff vergleichen. Mehrmals zu Zeiten wo der MA ein- und dann mehrmals wenn er ausgeschaltet ist.
Danach vergleichen, welche Werte in der einen Dateimenge 00 und in der anderen 01 ist - ach ja; Vaillant ist da variabel, "ein" kann auch manchmal etwas anderes als 01 sein, z.Bsp. 20 oder 64. Oder es ist ganz und gar bitcodiert und "aus" hat auch einen anderen Wert - ich habe schon c0==aus und c8==ein gesehen.....

[john30]

Ich habe immer wieder unknown Messages drin, sind das Messages die der ebusd nicht kennt, fehlende csv oder sind das Fehler auf dem EBUS?

Das sind messages, die ebusd trotz der CSVs noch nicht kennt. Deshalb "unknown".

[galileo]

Hallo Sven77,
Vielen Dank für die Erklärung. Dann werde ich mich einmal an die Arbeit machen. Ist bei mir nur mühsam, weil ich zum Schalten vom MA erst einmal einen ganzen Pufferspeicher händisch auf
Temperatur bringen muss.

@john30:
Kann es sein, dass im WIKI (TCP Client Commands) beim HEX Befehl die Zeile

Code Auswählen Erweitern

Dx     data byte(s) to send
doppelt ist und eigentlich nur jene am Ende gehört? Die erste Dx Zeile ist demnach falsch ?

Grüße,
Eduard

[Sven77]

Ist bei mir nur mühsam, weil ich zum Schalten vom MA erst einmal einen ganzen Pufferspeicher händisch auf Temperatur bringen muss.

Was genau sind denn TD1 und TD2?
Wenn ich das richtig verstehe, wird MA geschaltet, sobald der Puffer wärmer als der Solarkreis ist - das sollte doch jetzt im Winter machbar sein?!
Notfalls mal mit der Hysterese spielen...

[galileo]

Was genau sind denn TD1 und TD2?

TD1 ist die Temperatur im Puffer. TD2 ist die Temperatur im Rücklauf zum Gasbrenner.
Der Solarkreis ist eigentlich keiner, weil stattdessen ein Ofen (Holz) mit Wärmetauscher zum Pufferkreislauf eingebaut ist.
Wenn der Puffer warm genug ist, soll er den Gasbrenner "unterstützen" oder im Notfall auch ersetzen.
Also Ofen einheizen (das geht derzeit sehr gut  ) und dann wieder auskühlen lassen. Mein Problem ist dass beim Bau dieser
Anlage von den "Professionisten" schon so viel falsch gemacht wurde dass der Pufferkreislauf erst seit kurzem wirklich funktioniert
und ich aber bis heute nicht weiss, ob dieser Ausgang MA auch wirklich schaltet. Ich wollte das über den eBus aufzeichnen...

Ich werde mir jetzt einmal ein Script schreiben, wie du es vorgeschlagen hast. Und den MA Ausgang einmal elekrisch messen.
Dann werde ich schon weiterkommen.

[jkriegl]

Wenn ich das richtig verstehe ist der MA ein Indiz dafür, dass aus dem Puffer geheizt wird. Bei mir kommt es tatsächlich vor, dass aus dem Puffer (solar-betankt) geheizt wird und die Therme abgeschaltet wird. Einen Schaltwert habe ich auch noch nicht gefunden.
Kann nur feststellen, die Therme tut nichts, die Hz-Umwälzpumpe läuft und am 620-Display wird "Puffer >> HK" angezeigt. Da die Therme einen Nachlauf hat, ist die Abfrage "wer heizt" = "auto 17.0 Puffer <" zu simpel.
Die Solare Heizungsunterstüzung ist bei auroMatic 620 Anhang S. 46 beschrieben.