Anbindung Junkers Gastherme mit HT3-Bus an FHEM

[franky08]

@Heiko R.

Hallo, beschäftige mich seit kurzen auch mit der Anbindung HT3 an fhem und bin gerade dabei den Adapter nachzubauen. Meine Frage, ist es möglich die Daten an den UART des Raspi über ein FS20 S8M Sendemodul zu übertragen? Kann bei mir die Anbindung nur über Funk lösen, Kabel oder Raspi in die Nähe des Junkers Bedienteils zu bringen geht bei mir leider nicht.
Es gab hier im Forum irgendwo einen Tread um das Sendemodul mit einer modifizierten Firmware zu betreiben (Datenübertragung).

http://forum.fhem.de/index.php/topic,14071.msg88309.html#msg88309

VG
Frank

[Heiko R.]

Hallo Frank,

das klingt interessant. Das Sendemodul hatte ich noch nicht gesehen. Ich habe die Anleitung jetzt nur kurz überflogen.  Die Schaltung benötigt 3.3V und wird in der einen Version direkt vom RPi und in der anderen Version über UM2102 (über USB) versorgt. Im FS20 S8M habe ich jetzt auf die schnelle keinen Ausgang für eine Spannungsversorgung gesehen. Wieviel Spannung die Schaltung verträgt,  kann ich nicht sagen (die Datenleitungen dürfen in der vorliegenden Schaltung auch keinesfalls über 3.3V liegen). Wichtig ist imho die galvanische Trennung, sodass ich die HT3-Schnittstelle nicht direkt anschließen würde.  Das Sendemodul erwartet ein High von bis zu 24V, ein Low von 0V. Der HT3-Bus liefert ein High von 15V und ein Low von 10V. Es muss also auf jeden Fall etwas dazwischen, was das Low auf 0V zieht. Evtl. könntest Du beides (Adapter und Sendemodul) extern mit 3.3V versorgen, aber du müsstest dann sicherlich die Schaltung ändern. Das kann ich auf die Schnelle aber nicht sagen und erfolgt auf eigene Gefahr. Vielleicht gibt es aber hier einen Vollblut-Elektroniker, der sich damit besser auskennt.

Der HT-Bus ist sehr redselig und über Funk dürfen nur eine beschränkte Anzahl an Telegrammen versendet werden. Ich glaube, dass die zulässige Anzahl deutlich überschritten wird.

Es ist noch eine Schaltung in Entwicklung, die auch die Heizung vom Rechner steuern lassen soll. Das wäre dann mit dem Sendemodul nicht moglich.

Ich persönlich habe im Heizungsraum (nur von extern erreichbar) einen RPi, der nur für das Auslesen der Heizung zuständig ist (später auch für das loggen des Gasverbrauchs) und mir per WLAN die Daten über FHEM2FHEM an den Hauptserver schickt.

Gruß,
Heiko

[kaizo]

Hallo Frank,

habe auch einen Rpi dafür genutzt. Bei mir steht der im Keller und ist über WLAN eingebunden. Am Rpi habe ich die Schaltung von Norbert angeschlossen (GPIO-Version) und zuerst auch seine Software HT3 am laufen gehabt. Nachdem Heiko das Modul für Fehm geschrieben hat habe ich mittels Ser2net eine serielle Fernanbindung realisiert. Hierzu ser2net auf dem Rpi installiert und in Fhem die heizung mittels "define Heizung HEATRONIC 192.x.x.x:2000" eingebunden.

Läuft seit Tagen problemlos.

Gruß
Kai

[franky08]

Ja, ist schon klar. Würde aber für mich bedeuten das ich einen 2. Raspi nur für die Heatronic Schnittstelle in Betrieb nehmen müsste, oder?
Hatte bei meinen Überlegungen nicht an die 1% Regel für die Datenübertragung gedacht. Aber der von Norbert vorgestellte Adapter müsste nur modifiziert werden, dann könnte man die Daten über IR übertragen. Es geht bei mir nur um die Überbrückung von wenigen Metern. Wenn man den zur galv. Trennung eingesetzten Optokoppler durch, sendeseitig, einer IR Diode ersetzt und empfängerseitig einen IR Receiver mit nachgeschalteten Schmitt-Trigger verwendet, wäre die Übertragung über IR möglich (denke ich).

Die GPIO´s sind bei mir schon belegt, habe nur die UART Schnittstelle frei. Auf dem Raspi sitzt schon das COC Modul und ein selbstgebauter IR Transmitter/Receiver für IR Fernsteuerbefehle.
VG
Frank 

[Heiko R.]

Moin,

IR funktioniert aber nicht zufriedenstellend durch Wände. Und die IR-Verbindung sollte 9600 Baud vertragen. Bedenke, wie schlecht manche Fernbedienungen funktionieren, wenn man nur zu weit seitlich sitzt. Evtl. ginge ja etwas mit einem panStamp/Arduino o.ä., aber da bin ich zur Zeit zu wenig informiert.

Gruß,
Heiko

[Heiko R.]

Moinsens,

nachdem das Modul jetzt hoffentlich bei allen sauber läuft, eine Ankündigung: Ich habe heute ein Interval für ch_time, ch_Tflow_measured, dhw_Tmeasured und dhw_Tcylinder eingefügt. Ziel ist, einige Werte zu unterdrücken. Der Nachteil ist natürlich, dass z.B. beim Aufheizen zwangsläufig einige Werte verloren gehen und dadurch eine gewisse Ungenauigkeit entsteht. Ich überlege, ob und wie man das abfangen könnte (z.B. Ausnahme bei Brennerbetrieb).

Das Ganze wird über Attribute gesteuert, ein Intervall von 0 blockiert die Ausgabe und damit das Logging. Näheres folgt, wenn ich das Update einstelle.

Gruß,
Heiko

[kaizo]

Hallo Heiko,

fügst du auch die "neuen" Datenfelder, welche Norbert mittlerweile in HT3 eingefügt hat, auch im FHEM-Modul ein?
Ich habe gerade bei ihm mal die decode.py quergelesen und festgestellt, dass er einige neue Datensätze behandelt.
siehe https://github.com/norberts1/hometop_HT3/blob/master/HT3/sw/lib/ht3_decode.py


Ein Auszug:

Code Auswählen Erweitern

            self.__gdata.update(nickname,"Tsoll",i_Soll)
            self.__gdata.update(nickname,"Tist",f_Ist)
            self.__gdata.update(nickname,"Tspeicher",f_Speicheroben)
            self.__gdata.update(nickname,"Cbetriebs_zeit",i_betriebszeit)
            self.__gdata.update(nickname,"Cbrenner_ww",i_brennerww_ein)
            self.__gdata.update(nickname,"VWW_einmalladung",i_WW_einmallad)
            self.__gdata.update(nickname,"VWW_desinfekt",i_WW_desinfekt)
            self.__gdata.update(nickname,"VWW_erzeugung",i_WW_erzeugung)
            self.__gdata.update(nickname,"VWW_nachladung",i_WW_nachladung)
            self.__gdata.update(nickname,"VWW_temp_OK",i_WW_temp_OK)
            self.__gdata.update(nickname,"V_lade_pumpe",i_lade_pump_ein)
            self.__gdata.update(nickname,"V_zirkula_pumpe",i_zirkula_pump_ein)
            self.__gdata.update(nickname,"V_spare1",0)
            self.__gdata.update(nickname,"V_spare2",0)


Gruß
Kai

[Heiko R.]

Hallo Kai,

die Version liegt mir auch vor und die nicht vorhandenen Werte werden auch noch implementiert. Norbert hatte in der Programmierung etwas im Vergleich zur ersten Version geändert, deswegen ist manches noch nicht übernommen. Wird aber kommen.

Wie weit ich bisher: Intervall (in Sekunden) ist implementiert für ch_Tflow_measured, dhw_Tmeasured, dhw_Tcylinder, ch_time.  Durch Intervall 0 kann das Update des Wertes unterdrückt werden (einmal wird er allerdings erscheinen, um einen Vergleichsdatum zu haben; das kann ich später aber noch ändern). Für ch_Tflow_measured ist eine Minimaldifferenz implementiert, die erreicht sein muss, damit der Wert gesetzt ist (z.B. 0.5 °C). Zur Zeit ist das mit dem Intervall UND-verknüpft, das Intervall hat Vorrang (d.h. ist das Intervall noch nicht verstrichen, wird kein Wert gesetzt; auch nicht, wenn die Differenz überschritten wird). Da überlege ich noch, wie ich das sinnvoll machen kann.

Gruß,
Heiko

[Heiko R.]

Hallo,

Seit dem 26.06. habe ich in den Heizkreis-Nachrichten sporadische, nicht erklärbare Ausschläge. Die gemessene Raumtemperatur wird auf 14.4 °C, die geforderte Raumtemperatur auf 17 °C gesetzt. Der Heizkreismodus wird zeitgleich auf "Frost" gesetzt. Direkt danach wird sie wieder auf die alten Werte gesetzt. Der Code ist in dem Bereich nicht geändert worden. Ich schreibe gerade die Logs mit und hoffe, bald eine Erklärung zu haben. Kann jemand das Verhalten bestätigen?

Gruß,
Heiko

[Heiko R.]

Die Heizung hat sich ein paar Tage Zeit genommen, um das merkwürdige Verhalten erneut an den Tag zu legen. Aber die Ursache ist gefunden. Es handelt sich dabei um das 9 Byte lange Telegramm, das zufällig bei 17 Byte Länge die korrekte Checksumme trägt. Das Problem habe ich jetzt beseitigt.

Zudem gibt es jetzt die Attribute

• interval_ch_time, interval_ch_Tflow_measured, interval_dhw_Tmeasured, interval_dhw_Tcylinder
  Intervall in Sekunden zum Update der entsprechenden Werte, 0 unterdrückt das Update
  
• minDiff_ch_Tflow_measured
  Minimaldifferenz in Grad zu Update der entsprechden Werte
  

Beispiel:

Code Auswählen Erweitern


attr Heizung interval_ch_Tflow_measured 15
attr Heizung minDiff_ch_Tflow_measured 0.5
attr Heizung interval_ch_time 0
attr Heizung interval_dhw_Tmeasured 15
attr Heizung interval_dhw_Tcylinder 0


interval_ch_Tlow_measured und minDiff_ch_Tflow_measured sind zur Zeit UND-verknüpft. D. h., wenn das Intervall greift, muss vor dem Update auch die Minimaldifferenz greifen. Ist kein Intervall angegeben, wird nur die Minimaldifferenz betrachtet.

Mit den Attributen aus dem Beispiel werden bei mir bereits etwa 75 % der Telegramme eingespart.

Gruß,
Heiko


Rev: 6192 2014-07-03 16:11:22Z

[strauch]

Hallo Heiko,

Das klingt sehr gut. Ich kam leider immer noch nicht dazu meine Schaltung zu löten.....

[strauch]

Ich hab jetzt mal angefangen meine Schaltung zu löten, wenn alles gut geht kann ich ab Ende der Woche mitreden, ist inzwischen noch irgendwas neues passiert?

[Heiko R.]

Nein, es gibt noch nichts neues.

[strauch]

Jetzt gibts doch was neues. Norbert hat auch ein Adapter zum Senden gebaut:
http://www.mikrocontroller.net/topic/317004?goto=3927874#3925213

Ich hab da mal gefragt ob man die Platinen auch irgendwie bekommt.

[Bennemannc]

Hallo,

jetzt wird die Sache auch für mich langsam interessant. Wofür ist der Raspi eigentlich noch gut ? Kann man die Ganze Sache nicht in einen Sketch bauen, so das nur noch die Werte (auf Anfrage oder periodisch) übertragen werden ?
Ich dachte da so an einen PanStamp.

Gruß Christoph