Läuft: Heizung mit eBus-Schnittstelle

[Sven77]

Okay, das lässt vermuten, dass du weder FHEM noch EBUSD nutzt, somit bist du hier eigentlich falsch!

Die Abfrage der Fehlerhistory des Kessels sollte mit der Hex-Nachricht 08b50303010100 (letztes Byte 0-9 für 10 Fehlerspeicher), Antwort dann 1 Byte Status, 2 Bytes Zeit, 3 Bytes Datum und 2 Bytes Fehlernummer, also z.Bsp.:

31 08 b5 03 03 01 01 00 08 01 ff ff ff ff ff 31 00

Darin stehen dann aber alle Fehler, die in der Vergangenheit aufgetreten sind - alle aktuellen Fehler bekommt man mit Hex 08b503020001, was wiederum bis zu 5 Doppelbytes mit aktuell anliegenden Fehlern meldet:

31 08 b5 03 02 00 01 0a ff ff ff ff ff ff ff ff ff ff

Ich hoffe, das hilft etwas...

[KlaRa]

Hallo Sven,
leider nicht wirklich. Bei mir erscheint ein Broadcast gemäß eBus-Spezifikation. Die Nachricht wurde bei mir nicht weiter behandelt, passt aber zeitlich. Adresse 31 soll demnach ein Businterface sein. Ist bei mir im Protokoll nicht zu finden.

03 FE FE 01 0A 42 41 49 03 01 00 00 00 00 00 58

Allerdings zeigt es sich, daß es zukunftssicherer ist sich einer Plattform wie FHEM anzuschließen. Mein EcoTec ist aus dem Jahr 2007 und war damals eines der ersten dieser Modellreihe. Inzwischen mußte einmal die Basisplatine getauscht werden. Danach war auf einmal die Modulation wesentlich besser. Irgendwann ist vielleicht auch ein neues Brennwertgerät selber notwendig. Dann stehe ich natürlich auf dem Schlauch. Das Know How zu Anpassung habe ich nicht. Ich habe ja einen kleinen Anblick in die Vielfalt der Konfigurationen machen können.

Hast Du ein Tipp für einen raschen Einstieg? Als Hardware wäre mir ein Rasberry PI schon ganz angenehm.
mfg Klaus

[Sven77]

Also ob nun FHEM (nutze ich selbst auch nicht) oder etwas anderes, sei mal dahin gestellt.
Aber Ebusd nimmt dir schon einen erheblichen Aufwand ab - John investiert hier richtig viel Hirnschmalz, Zeit und Arbeit - an dieser Stelle auch mal ein dickes DANKESCHÖN von mir!
Ebenso zur Dokumentation wird hier viel getan, einen Einstieg findest du z.Bsp. unter: https://github.com/john30/ebusd/wiki

Dort stehen auch viele Basics zum Ebus selbst, hier nur in aller Kürze zur Erklärung der geposteten Bytes:
Das erste Byte ist die Quelladresse, da ich aktiv eine Nachricht mit Ebusd geschickt habe, ist diese 31 (Adresse von Ebusd). Wenn du auf dem Bus nur mithörst, müsstest du schauen, wer sonst noch die 08 nach einem Fehler abfragt - oder ignorierst das erste Byte und wartest einfach auf "08 b5 03 ...".
Wenn der Fehler auf der Steuerung erscheint, muss eigentlich irgendwann mal die 10 als Quelle aufgetaucht sein.

Es ist natürlich auch denkbar, dass es noch weitere Nachrichten gibt, um den Fehlerzustand abzufragen. In diesem Fall müsste man in den Nachrichten nach der Fehlernummer (4b) suchen, oder (noch schlimmer) es gibt sogar einfach ein Flag "Fehler oder nicht", dann kommst du um das aktive Abfragen nicht herum.

Aber meine Empfehlung wäre ohnehin, dich in Ebusd einzuarbeiten, das macht die ganze Sache erheblich leichter!

[cs-online]

Hallo Christian,

Wo finde ich diese EMCD-Klasse? Ist das Teil des ebusd?

Für mich ist es schwierig selbst die Bedeutung von bai zu ermitteln. Kannst Du mir Beispiele für eine eBus-Code-Sequenz für eine Fehlermeldung geben? Also auf native - Ebene dieser Art?

mfg Klaus

Hallo,

die Klassendefinition (in FHEM) findest du auf Seite 1 dieses Threads. In native kann ich dir leider nicht helfen, sorry

John hat eine sehr aufwendige Doku erstellt, am besten dort erst mal einlesen.

Grüße

Christian

[KlaRa]

Hallo Sven,
vielen Dank. Dann werde ich mich in aller Ruhe einlesen.

@Christian
Ebenfalls vielen Dank.
mfg Klaus

[p657816]

Guten Abend,

weiß jemand, wie ich an die Rücklauf-SOLL-Temperatur des HK2 rankomme, und zwar die, die im Register C2 der Calormatic 430 angezeigt wird?
Die dazugehörige IST-Temperatur bekomme ich mit

Code Auswählen Erweitern

ebusctl r Flow1Sensor, aber die an der Calormatic direkt darüber angezeigte SOLL-Temperatur kann ich nirgendwo finden.

Kann jemand helfen?

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.3.v3.3-13-gd366bbb
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.430.csv: different version available, vaillant/50.v61.mc.csv: different version available, vaillant/bai.0010003857.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 22
max symbol rate: 157
min arbitration micros: 6
max arbitration micros: 237
min symbol latency: 3
max symbol latency: 19
reconnects: 0
masters: 3
messages: 526
conditional: 20
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010003857.inc" ([PROD='0010009343']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0119;HW=1902", loaded "vaillant/50.v61.mc.csv"

[goosst]

Hello

sorry if my German search skills are not good, but I didn't immediately find an answer (it's a bit of a spider web to find information ).

I can read all the parameters from my vaillant heater and its thermostat thanks to your great ebus adapter.
But the next step is to take over control from my thermostat, so my questions:
- are there any (github)repositories that would be a good start for this and have already implemented a smart room temperature control using ebus commands?
- are there examples of completely eliminating the thermostat or do we have to keep the thermostat active and intervene the messages in some way?

My first goal is to find a way to turn my heater off if the house is empty instead of following the fixed thermostat schedule .

Code Auswählen Erweitern

ebusctl info
version: ebusd 3.3.v3.3
update check: revision v3.3-4-g212b22d available
signal: acquired
symbol rate: 23
max symbol rate: 125
min arbitration micros: 1188
max arbitration micros: 3150
min symbol latency: 4
max symbol latency: 6
reconnects: 0
masters: 5
messages: 351
conditional: 2
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 10: master #2
address 11: master #7
address 15: slave #2, scanned "MF=Vaillant;ID=F3700;SW=0114;HW=6102", loaded "vaillant/15.f37.csv"
address 16: slave #7, scanned "MF=Vaillant;ID=B7000;SW=0120;HW=6202"
address 26: slave, scanned "MF=Vaillant;ID=F3700;SW=0114;HW=6102"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=F3700;SW=0114;HW=6102"


[jkriegl]

Frage: Haben häufige Abfragen über den ebus Einfluss auf die Lebensdauer der Platine einer Therme?

Hintergrund: Vaillant ecoTEC plus gut 9 Jahre alt, kommerzieller ebus, seit fast 4 Jahren FHEM mit ebusd (2.).
Die Therme hatte in den letzten Monaten gelegentlich timeouts und crc-Fehler. Nun ist sie mit Fehler F27 Flammenwächter ganz ausgefallen. Der HB hat die Platine ersetzt.
In der Periode ohne Heizung reduziere ich die Abfragen. Frage ohne f ab. Update von Einstellungen sehr selten bzw. Änderungen an der auroMATIC 620.

[KlaRa]

Nein. Du solltest nur nicht den internen Verkehr auf dem eBus durch zu häufige Anfragen stören. In der Regel macht man das nicht. Man hört ja erst einmal den Verkehr ab und nutzt die nächste Pause.
mfg klaus

[Prof. Dr. Peter Henning]

In der Regel macht man das nicht. Man hört ja erst einmal den Verkehr ab und nutzt die nächste Pause.

Das halte ich für grandiosen Unsinn. Der eBus ist für Multi-Master-Betrieb vorgesehen, und das "Warten auf Pause" ist eben nicht Bestandteil des normalen Betriebs.

@goosst: This is not a good idea, nor is it good practice. A software system driving your heater should be autonomous and certified for safety by third party testers - which is the case in every commercial system. Using your own software to drive the heater might severely shorten the lifetime of the heater, might be environmentally harmful and might even cause fatal accidents to persons. For very good reason it is even unlawful to tinker with the central heating control in several countries of the European Union.

This does in no way prevent you from influencing your heater system by using external commands. One may even trick the "safe" commercial system into believing really weird stuff - some examples are presented  in the Smart Home Hacks.

LG

pah

[john30]

Das halte ich für grandiosen Unsinn. Der eBus ist für Multi-Master-Betrieb vorgesehen, und das "Warten auf Pause" ist eben nicht Bestandteil des normalen Betriebs.

abgesehen davon, dass es Teil des eBUS Protokolls ist, auf das nächste SYN Zeichen zu warten

[jkriegl]

zu meiner Frage: Lebensdauer und ebusd-Abfragen, vielen Dank für die Antworten.
Ich lese daraus, dass häufige Abfragen über ebusd (ECMD) keinen Einfluss auf die Lebensdauer der Therme-Platine haben.
Und folgere: Die Gründe liegen vermutlich wo anders, an der Umgebung: Heizungskeller, sowie Luftfeuchte und dgl.
Derzeit habe ich humidity: 41% (HM...EU), 43% (Xiaomi), Temp 19,2 °C

[cs-online]

Die Platinen sind halt empfindlich, sitzen in der Therme eben auch im Thermisch belasteten Bereich. Meine Therme ist nun 8 Jahre alt und macht auch Zicken. Gerne gehen da Elkos und dergleichen kaputt. Teilweise sind die aber auch reparabel...

Grüße

Christian

[Wardancer]

Guten Morgen zusammen,

ich versuche gerade die Weishaupt-Definitionen von J0EK3R an meine Anlage zu adaptieren. Dabei bin ich auf folgendes Problem gestoßen, was ich mir im Moment null erklären kann. Ich würde gerne die Zeitprogramme der Anlage auslesen, das hat J0EK3R auch für seine Anlage definiert und rein grundsätzlich funktioniert das auch für meine Anlage, das Problem ist aber, dass eigentlich in der EBUS-Antwort die Ende-Zeit des Programmes, sowie die Start-Zeit des Programmes jeweils in einem Byte geschickt werden (zuerst Ende, dann Start). Das ganze dann als vielfaches von 15 Minuten.
Damit bekomme ich z.B. folgendes zurück:

Code Auswählen Erweitern

31355022021014 / 025c17 = 1: hc1 HP1.Mo.1 Das wäre nun mein 1. Heizprogramm für Montag 5c steht für 23:00 Ende und 17 für 5:45 start.

Die Definition von JOEK3R sieht nun folgendermaßen aus (Auszug):

Code Auswählen Erweitern


# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field1,part (m;s),type / templates,divider / values,unit,comment,field2,p$
#,,Zeitprogramme Heizkreis,,,,,,,,,,,
*r,,,,,"35","5022",,,,,,,
r,,HP1.Mo.1,Heizprogramm 1 Mo 1 Start/Ende (Anwender 121) ,,,,"1014",,,_8_TimeStart,,, ,,,_8_TimeEnd,,,


Template Definition:

Code Auswählen Erweitern


# Field Templates für Start/Ende-Zeit der Programme,,,,
_8_TimeStart:Start,TTQ,,,Startzeit
_8_TimeEnd:End,TTQ,,,Endezeit


Jetzt zu meinem Problem: Ich bekomme vom EBUSD immer nur die Endzeit ausgewertet, also die vollständige Rückmeldung zu dem Telegram sieht dann so aus:

Code Auswählen Erweitern

localhost: r -c hc1 HP1.Mo.1
23:00;23:00


Das evtl. Start und Ende oben noch verdreht sind, würde ich verstehen, aber ich verstehe nicht, dass ich obwohl ja 2 Bytes zurückkommen bei der Template-Definition von oben nur das erste, und dann auch noch für beide Werte genutzt wird. Habt ihr da noch nen Tip für mich?

VG und Danke!

[john30]

Jetzt zu meinem Problem: Ich bekomme vom EBUSD immer nur die Endzeit ausgewertet, also die vollständige Rückmeldung zu dem Telegram sieht dann so aus:

da hast du eine gute Lücke gefunden, ist mit commit c26f7b3 gelöst.
Hintergrund der Problematik ist, dass der Datentyp weniger als ein ganzes byte verbraucht.