Anbindung Junkers Gastherme mit HT3-Bus an FHEM

[sbiermann]

@Heiko, Patch ist geschrieben. Funktioniert bei mir wunderbar. Ist der gleiche Mechanismus der auch schon im NUT Modul verwendet wurde. Die eigentliche Arbeit, also das Prüfen des Reconnect usw. wird vom DevIo erledigt. Du findest die Änderungen hier: https://github.com/sbiermann/fhem und als Diff hier an den Beitrag angehängt.

Viele Grüße
Stefan

[td]

Hallo (Heiko),

wird es zukünftig weitere readings geben?
So liefert der Regler ja noch einige weitere Parameter, wie z. B. geforderte und tatsächliche Vorlauftemperaturen der Heizkreise 1 und 2 oder den Stellwert eines externen Reglers.

Mit Bitte um Rückmeldung,
td

[elral]

Hallo Heiko,

ich habe den gesamten Thread jetzt noch mal gelesen aber bzgl. schreibend auf dem Bus zuzugreifen "nur" die Aussage gefunden, das es geplant ist.
In der Commandref wird jedoch beschrieben, dass u.a. der Mode und Trequested gesetzt werden kann.
Das funktioniert bei mir jedoch nicht, kann aber auch am Adapter liegen den ich am WE zusammen gebaut habe.

Kannst Du mir sagen, ob es im Modul realisiert ist?
Wenn ja, ist es geplant um weitere Befehle zu erweitern (muss mal bei microcontroller.net lessen was bisher realisiert ist) und funktioniert das bereits bei jemanden?

Vielen Dank und Grüße

Ralf

[sbiermann]

Hoi,
mit dem FHEM Modul kann ich lesen und schreiben auf dem Bus. Funktioniert einwandfrei bei mir. Ich nutze es in der Kombination mit dem HCS Modul.

Viele Grüße
Stefan

[moorjunge]

Nabend,

bei mir leider das gleiche.
Ich kann zwar auf dem Bus lesen, aber leider nicht schreiben.

Als Heizung habe ich eine ZSN18-7 KE mit eingebautem FW100.
Der Adapter ist ein ht_pitiny.

Bei einem hc1_mode_request erhalte ich folgende Meldung im Log:
5: HEATRONIC_WriteHC_mode:eco using value:2 success:1

Bei Änderungen des Modus am FW100 werden unter hc1_mode gleich die Änderungen angezeigt.

Gruß
Thiemo

[sbiermann]

Funktioniert den die Software von Norbert? Sprich könnt ihr über ht_netclient.py die Heizung schalten? Wenn das geht, sollte das Modul auch funktionieren.

Am FW100 muss, wenn der Adapter richtig funktioniert, etwas stehen wie "Netcom aktiv" und man kann den Modus (Heizen, Auto, etc.) nicht mehr ohne Nachfrage bzw. abbrechen der Netcom Steuerung ändern.

[elral]

Da ich den Raspi mit FHEM neu aufgesetzt habe, hatte ich die SW von Norbert nicht mehr aufgespielt.
Norbert hat mir bereits einige Tips zum testen des Adapters gegeben, das werde ich heute abend mal in Angriff nehmen.
Ggf. muss ich Norberts SW noch installieren.
Meldungen wie "Netcom aktiv" habe ich nicht gesehen, aber auch nicht richtig darauf geachtet.

Im übrigen ist meine Heizung eine ZWB30-4C23, auch mit eingebautem Regler (Typ muss ich noch mal nachschauen).

Danke und Grüße

Ralf

[moorjunge]

Auf die Software von Norbert bin ich leider erst gestern Abend so richtig aufmerksam geworden.
Ich werde heute Abend mal den Raspi mit dem Programm beglücken und dann nochmal Rückmeldung geben.

Gruß
Thiemo

[sbiermann]

Ah, dann nutzt ihr also nicht den ht_proxy als Zwischenstation. Ihr habt vermutlich sowas wie

Code Auswählen Erweitern

define Boiler HEATRONIC /dev/ttyAMA0@9600
gemacht. Beim ht_pitiny muss die Baudrate auf 19200 gestellt sein damit es funktioniert, die Beschreibung des Moduls in der commandref gibt 9600 Baud vor. Das könnte eine Fehlerursache sein, ansonsten würde ich auf einen Hardwarefehler tippen.

[moorjunge]

Ah, dann nutzt ihr also nicht den ht_proxy als Zwischenstation. Ihr habt vermutlich sowas wie

Code Auswählen Erweitern

define Boiler HEATRONIC /dev/ttyAMA0@9600
gemacht.

Genau, jedoch gleich mit 19200.
Damit empfange ich dann auch die Readings.

Ich hab den Raspi heute nochmal neu aufgesetzt.
Nun zeigt sich folgendes Verhalten:
Heatronic über ttyAMA0 definiert -> Readings werden aktualisiert; Schreiben auf dem Bus kommt nicht an.
Heatronic über 127.0.0.1 definiert -> Schreiben auf dem Bus kommt bei der Steuerung an; Readings werden nicht aktualisiert.

Eine Änderung zwischen Async und Socket in /HT3_db_cfg.xml brachte auch keine Änderung. Wobei ich da vielleicht nochmal genauer hingucken muss.

[elral]

Ah, dann nutzt ihr also nicht den ht_proxy als Zwischenstation. Ihr habt vermutlich sowas wie

Code Auswählen Erweitern

define Boiler HEATRONIC /dev/ttyAMA0@9600
gemacht.

Ja genau, so habe ich das definiert, auch wie Thiemo mit 19600 da ich ja Daten empfangen kann. Meine HW ist O.K., das habe ich gestern abend noch geprüft.
Norbert hat mir aber im mikrocontroller.net diese Nacht auch mitgeteilt, dass der ht_proxy.server zwingend notwendig ist um auf den Bus zu senden.
Nun muss ich mal schauen, was und wie ich installieren  muss und danach noch im define ändern muss.

Grüße

Ralf

[sbiermann]

Ich benutze den Proxy, was aber daran liegt das meine FHEM Instanz auf einen anderen Pi läuft als der Adapter gesteckt ist. Das ist der einzige Grund bei mir. So wie ich den Sourcecode des 89_HEATRONIC Moduls lese braucht es auch den Proxy nicht zwingend dazwischen. Nur wenn es übers Netzwerk geht muss der ht_proxy laufen da das Modul eine Gegenstelle auf dem anderen Pi braucht. Der Proxy hat aber den Vorteil man kann nicht nur das FHEM Modul nutzen sondern theoretisch auch beliebig viele andere Clients an den Adapter. Praktisch ist es durch die Rechenleistung des Pi beschränkt.
Im Pi müssen noch ein paar Dinge eingerichtet werden, TTY Ausgaben unterbinden und getty spawn verhindern, siehe angehängte Grafik. Das habt ihr denke ich gemacht oder? Das könnte nämlich auch eine Fehlerursache sein.

[moorjunge]

Im Pi müssen noch ein paar Dinge eingerichtet werden, TTY Ausgaben unterbinden und getty spawn verhindern, siehe angehängte Grafik. Das habt ihr denke ich gemacht oder? Das könnte nämlich auch eine Fehlerursache sein.

Guten Morgen,

jupp, wobei bei Jessie ein  "sudo systemctl disable serial-getty@ttyAMA0.service" nötig war.
Dort gibt es die inittab nicht mehr.

Wie bereits gesagt, bei der Definition über ttyAMA0 bekomme ich auch Daten.
Nur bei 127.0.0.1 werde die Readings nicht gefüllt.

Magst Du vielleicht die Passagen Deiner HT3_db_cfg.xml bzw ht_proxy_cfg.xml teilen?

Was mir auch aufgefallen ist, wenn ich die Homepage auf dem Pi mit dem Port 8086 anspreche, dann werden zwar die Bilder gezeigt, aber die Graphen werden nicht erzeugt.

Gruß
Thiemo

[sbiermann]

Hier der code der ht_proxy_cfg.xml

Code Auswählen Erweitern

#
##
#  Importend:
#   If you are using the ht_proxy - Server, then the interface has
#   has to be set to: SOCKET
#    see config-file: HT3_db_cfg.xml
#     and paramter  :<comm_type>SOCKET</comm_type>
#
#  required comport-configurations for 'proxy-server'
#   1. If you use a 'ht_transceiver'-board (ht_piduino or ht_pitiny)
#      you have to configure:
#        <baudrate>19200</baudrate>
#        <serialdevice>/dev/ttyAMA0</serialdevice>   (for RaspberryPi UART)
#
#   2. If you use a 'HT3_miniAdapter'-board
#      you have to configure:
#        <baudrate>9600</baudrate>
#        <serialdevice>/dev/ttyAMA0</serialdevice>   (for RaspberryPi UART)
#
#   3. If you use a 'HT3_microAdapter'-board with USB<->UART interface
#      you have to configure:
#        <baudrate>9600</baudrate>
#        <serialdevice>/dev/ttyUSBx</serialdevice>   (for any USB-Port x)
#
-->

  <item>ht_proxy_configuration</item>

  <!-- global configuration-values -->

  <!-- currently only ONE com-/tty-port with devicetype:='MODEM' is supported --
>
  <transceiver_numbers>1</transceiver_numbers>

  <!-- proxy-server configuration-values -->
  <proxy_server>
    <serveraddress></serveraddress>
    <servername></servername>
    <portnumber>8088</portnumber>
    <logfilepath>./var/log/ht_proxy.log</logfilepath>
    <ht_transceiver_if devicename="RX">
      <parameter>
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>RX</devicetype>
    </ht_transceiver_if>
    <ht_transceiver_if devicename="MODEM">
      <parameter>
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <baudrate>19200</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <devicetype>MODEM</devicetype>
      <deviceaddress_hex>0D</deviceaddress_hex> <!-- currently unused value -->
    </ht_transceiver_if>
  </proxy_server>

  <!-- proxy-client(s) configuration-values
   #   devicetypes of client(s) currently supported: 'MODEM' or 'RX'.
   #   Type 'MODEM' can be used in parallel but must not send
   #   parallel at the same time and has to wait for the end
   #   of any other transmission.
  -->
  <proxy_client devicename="RX">
    <serveraddress>localhost</serveraddress>
    <servername></servername>
    <portnumber>8088</portnumber>
    <logfilepath>./var/log/ht_client_rx.log</logfilepath>
    <devicetype>RX</devicetype>
  </proxy_client>

  <proxy_client devicename="MODEM">
    <serveraddress>localhost</serveraddress>
    <servername></servername>
    <portnumber>8088</portnumber>
    <logfilepath>./var/log/ht_client_modem.log</logfilepath>
    <devicetype>MODEM</devicetype>
  </proxy_client>
</ht_proxy_cfg>

Hier der entsprechende Eintrag aus der HT3_db_cfg.xml

Code Auswählen Erweitern


    <!-- global configuration-values -->
    <data_interface>
      <comm_type>SOCKET</comm_type> <!-- communication-types are:
                                            ASYNC:=tty/comport; SOCKET:= socket-interface
                                            If daemon: 'ht_proxy' is used then <comm_type>SOCKET is required !
                                    -->
      <proto_type>RAW</proto_type>  <!-- protocoll-types     are:
                                            RAW:=transparent  ; TRX   :=TBD (transceiver-messages with header) -->
      <parameter name="ASYNC">
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>9600</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
      <parameter name="SOCKET">
        <proxy_config_file>./etc/config/ht_proxy_cfg.xml</proxy_config_file>
      </parameter>
    </data_interface>


Ich nutze nur den ht_proxy von Norbert, die anderen Softwareteile wie das rrd_tool, ht_netclient, ht_logger, usw., sind bei mir deaktiviert bzw. werden nicht genutzt.

[elral]

Hallo zusammen,

Im Pi müssen noch ein paar Dinge eingerichtet werden, TTY Ausgaben unterbinden und getty spawn verhindern, siehe angehängte Grafik. Das habt ihr denke ich gemacht oder? Das könnte nämlich auch eine Fehlerursache sein.

ja, habe ich auch gemacht.

So wie ich den Sourcecode des 89_HEATRONIC Moduls lese braucht es auch den Proxy nicht zwingend dazwischen.

Laut Norbert ist der aber auch bei FHEM zwingend erforderlich. Es wird wohl noch eine CRC angehängt. Wobei ich mich frage ob das nicht auch direkt aus dem Modul gemacht werden kann.

Ich nutze nur den ht_proxy von Norbert, die anderen Softwareteile wie das rrd_tool, ht_netclient, ht_logger, usw., sind bei mir deaktiviert bzw. werden nicht genutzt.

So habe ich das jetzt vor, muss "nur" mal sehen wie ich das konfiguriert bekomme. Norberts Anleitung liegt parat, muss mich jetzt nur mal durchfuchsen was ich unbedingt brauche bzw. deaktiviere.

jupp, wobei bei Jessie ein  "sudo systemctl disable serial-getty@ttyAMA0.service" nötig war.

Ich bin gerade dabei, einen Raspi 3 neu aufzusezten. Guter Hinweis, da bin ich gestern nämlich drüber gestolpert und wollte mich heute abend auf die Suche begeben.

Danke und Grüße

Ralf