Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi

[Hans (Gast)]

Hallo zusammen,
der Adapter ist bereits von der Heizung getrennt ☺
Das Verhalten kann ich allerdings nicht nachvollziehen. Selbst wenn der 
Optokoppler defekt wäre, warum soll das einen Einfluss auf das 
WLAN-Modul am Pi haben. Da würde ich eher mit einem Komplettausfall des 
Pi rechnen. Nichts desto trotz habe ich die Schaltung durchgemessen und 
mit einer externen Spannungsquelle als Simulator des Ht3-Buses getestet. 
Dabei konnte ich keine Fehler feststellen, alles hochohmig und der 
Optokoppler funktioniert, ohne dass das WLAN abstürtzt.
Die Spannung vom HT3-Bus der Heizung habe ich allerdings noch nicht 
gemessen. Da die Heizung aber gut funktioniert, gehe dort nicht von 
einem Fehler aus. Aber selbst wenn, warum sollte ein Fehler der Heizung 
das WLAN rauskicken. Hmmm, ich habe keinen Reim drauf.

Bin dankbar für alle Anregungen,

Hans

[adam (Gast)]

Hallo Hans,
nach zwei Jahren störungsfreier Arbeit hatte ich die gleichen Symptome.
Neue WLAN-Antenne hat nicht geholfen.
Ich hatte die Backup der SD-Karte (gesichert direkt nach der 
Installation) mehrmals wiederhergestellt (kleine sqlite-DB) , nach paar 
Tage wieder das gleiche.

Da die neue Version 0.3 gibt, habe Jessie und HT3 neu installiert und 
Raspi mit Lan-Kabel verbunden.
Seit einem Monat kein Ausfall.

[Hans (Gast)]

Hallo Adam,

OK, dann werde ich jetzt nochmal anstatt Stretch-Lite ganz normal 
Stretch ausprobieren. Denke aber, dass ich keinen Unterschied 
feststellen werde. Probieren geht über studieren :-)
Ich halte euch auf dem Laufenden.

VG

Hans

[adam (Gast)]

Hans schrieb:
> OK, dann werde ich jetzt nochmal anstatt Stretch-Lite ganz normal
> Stretch ausprobieren.

Hallo Hans,
funktioniert mit Stretch?

Norbert,
funktioniert HT3 problemlos mit Stretch?
Lohnt sich umsteigen?

[Norbert S. (junky-zs)]

Hallo Adam,

>funktioniert HT3 problemlos mit Stretch?
Problemlos nicht, aber die Lösung ist ja da.
Siehe paralleler Projekte & Code - Thread:
Beitrag "Re: Heizungs-Datenerfassung (HT3)"

Es geht dort um die Generierung der Grafiken mit rrdtool.
Details und Lösung sind da beschrieben.
Der Rest läuft wohl. Ich selber setzte Stretch nicht ein und nutzte 
Wheezy bzw. Jessie, kann also keine weiteren Details prüfen.
Aber der python-Code wird wohl auch mit Stretch (ohne Stress) problemlos 
laufen :-)

Gruß

[Hans (Gast)]

Hallo zusammen,

möchte euch eine kleine Rückmeldung zu meinem Problem mit dem 
WLAN-Adpater geben. Habe heute Wheezy aufgespielt und und die 
Datenerfassung läuft perfekt. Das Problem scheint also bei Stretch und 
USB / GPIO-Anbindung zu liegen.
Jetzt stellt sich für mich die Frage welche  Distribution für die 
HT3-Datenerfassung die Richtige ist ? Wheezy oder Jessie ?


Sonnige Grüße aus dm Münsterland

Hans

[Norbert S. (junky-zs)]

Hallo Hans,

> Wheezy oder Jessie ?
"Jessie" := Debian 8 !

Der Support für "Wheezy" := Debian 7 läuft in 2018 aus.
 "Wheezy LTS will supported from 26 April 2016 to 31 May 2018".
Siehe URL:
https://www.debian.org/News/2016/20160425

Gruß Norbert

[Andreas W. (urbansunited)]

Hallo zusammen,

dank Norbert habe ich endlich mein System am Laufen wie es sein soll.
Nachdem ich meine "Testinstallationen" auf einen RPi1b gemacht hatte und 
es da dann endlich lief, bin ich rüber auf einen RPi3 mit Stretch 
gegangen.
Viele neue Probleme, die ich aber alle in den Griff bekommen habe.
Dazu kommt am WE aber noch eine gesonderte Installationsanleitung.

Jetzt will ich das RPi3 Wlan Problem unter Stretch lösen:

Sollte euer Wlan mit Strech nicht klappen, müssen folgende Anpassungen 
gemacht werden.
Ich gehe hier von einer Stretch Fresh-Installation aus!

1. Wi-fi-Country des Raspberry Pi einstellen

sudo raspi-config
Dort unter Internationalisation Options -> Change Wi-fi Country die 
länderspezifischen Einstellungen anpassen. Für Deutschland bitte DE 
Germany auswählen

2. Unter /etc/wpa_supplicant/wpa_supplicant.conf euere Wlan Daten 
eingeben:
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

network={
    ssid="Name Wlan Netzwerk"
    psk="Passwort zum Wlan"
}

Dann speichern

3. Prüfen, wie das Wlan device heisst. Normal wlan0, kann aber auch 
anders betitelt sein, zB. nxb827ec3f7f60

danach starten wir das Wlan neu:

sudo ifdown wlan0 (oder wie auch immer euer wlan device heisst - evtl. 
anapassen)
sudo ifup wlan0 (oder wie auch immer euer wlan device heisst - evtl. 
anapassen)

4. Die Datei /etc/network/interfaces lassen wir unverändert!!!! Sollten 
da selbstgemachte Einträge enthalten sein, bitte löschen.

5. Config anpassen: sudo nano /etc/dhcpcd.conf
6. Für die statische IP Anbindung bei eth0 die # entfernen und die Daten 
anpassen.
   Für die Wlan config folgendes hinzufügen (ich hatte es unter den eth0 
part gesetzt, kann aber auch ganz nach unten):

inferface wlan0
static ip_address=192.168.0.200/24
static routers=192.168.0.254
static domain_name_servers=8.8.8.8 192.168.0.254

speichern und reboot

Dann sind wir fertig und es sollte wieder mit dem RPi3 eigenem Wlan 
funktionieren.

Gruß

URBANsUNITED

[Jan (Gast)]

Hallo Andreas,

das WE ist noch nicht rum, und ich will nicht ungeduldig sein. Wäre 
trotzdem toll, wenn Du in Deiner Installationsanleitung auch auf die 
spezifischen Einstellungen eingehen könntest, die Raspbian Stretch für 
den GPIO braucht, um mit dem Pitiny zu funktionieren.

Ich habe letzte Woche versucht, vom einen Pi3 mit Jessie auf den anderen 
Pi3 mit Stretch unmzuziehen und habe es ums Verrecken nicht hinbekommen, 
die "richtigen" Einstellungen in der config.txt etc. einzugeben, dass 
mir auch Daten auf dem Pitiny ankommen oder gesendet werden. Nach ein 
paar Stunden basteln habe ich aufgegeben und den Pitiny wieder an den 
"alten" Raspi gesteckt... aber die Herausforderung ist nur aufgeschoben.

Danke!
Jan

[Andreas W. (urbansunited)]

Hallo,
wie schon angekündigt, wollte ich meine Installationsschritte den Usern 
nicht vorenthalten.
Ich habe folgende Hard und Software im Einsatz:
Raspberry Pi 3b
ht_pitiny Adpater
Raspbian Stretch minimal Image stand September

Wer die gleiche Hard und Software nutz, findet anbei meine Anleitung zur 
Installation des Betriebssystems und kleineren Anpassungen.
Ich habe mich dabei der Anleitung von Norbert bedient und habe meine 
Anpassungen entsprechend eingebaut.

Gruß

Andreas

[Andreas W. (urbansunited)]

Wer kann mir bitte weiterhelfen?

Ich möchte an meinen RPi3 jetzt noch einen 433Mhz Sender anschließen.
Wie gehe ich da vor? Wie greife ich die Gpios ab?

Danke

Andreas

[Norbert S. (junky-zs)]

Hallo Andreas,

wenn Du zusätzliche Hardware zusammen mit dem ht_pitiny-Adapter 
anschliessen willst so hängt dies davon ab welche Schnittstelle diese 
Hardware hat.

Auch spielt der Typ des RaspberryPi eine Rolle, der ht_pitiny-Adapter 
benutzt die ersten 26 Pins (2*13) des Raspberry-GPIO.
Wenn Du z.B. einen RaspberryPi mit 40Pin Sockel hast, so kannst Du dort 
die freien Pins nutzen.

Der ht_pitiny-Adapter benutzt nur die RX/TX-Pins des UART und die 
SPI-Pins (Mosi/Miso/Clk) für ein eventuelles Softwareupdate.
Die restlichen Pins sind frei.
Die Pinzuordnung ist festgelegt unter der URL:
 https://pinout.xyz

Gruß Norbert

[Jo (Gast)]

Hallo, ich habe noch zwei wenig benutzte Pitiny Adapter da. Hatte sie 
vor einiger Zeit von Norbert für einen Kollegen und für mich gekauft, 
dann aber aufgegeben weil ich mit dem Thema doch ein wenig überfordert 
war.

Wer Interesse hat bitte melden!

[Patrick (Gast)]

Hallo Jo,

ich hätte Interesse an einem Pitiny Adapter. Wie können wir denn da 
zusammenkommen?

Grüße
Patrick

[Jo (Gast)]

Hallo Patrick
Habe mal eine temporäre Adresse erstellt: [e-mail]
Schreibe die Adresse an und ich werde mich mit meiner echten
Adresse melden. Denke wir werden uns schon einig!

Gruss
Jo

[Ferdinand S. (sir_bacon)]

Hallo Jo,

Dann möchte ich mich gerne melden für der zweite Adapter. Ich wird mir 
dann melden am gleiche Emailadresse, aber erst heute Abend.

Gruß, Ferdinand

[tzem (Gast)]

Hat jemand noch ein piduino oder pitiny adapter über was er nimmer 
braucht

[Ferdinand S. (sir_bacon)]

Gutentag,

Ein kurze Frag zu der Pitiny Adapter. Ich habe eine Nefit Heizung, der 
Niederländische Marke von Bosch, und der spricht EMS. Wenn ich alles gut 
gelesen habe spricht der Pitiny auch EMS. Oder habe ich etwas übersehen 
oder falsch gelesen?

Im Nachbarthread habe ich auch schon ein Frag dazu gestellt, aber noch 
kein Antwort bekommen. 
Beitrag "Re: EMS > Adapter > NetIO > Raspi"

Gruß, Ferdinand

[Holger R. (Gast)]

Hallo Zusammen,

ich versuche zzt. HT3 wieder unter Stretch zum Laufen zu bekommen.

Unter Jessie funktionierte HT3 mit dem HT3-Adapter sauber.
Aufgrund der IP Symcon muss ich auf Stretch aktualisieren.

Upgrade auf Jessie => Stretch durchgeführt und ich bekomme die folgende 
Fehlermeldung in Ccollgate.log

28.12.2017 17:05:47 INFO: Starting 'Ccollgate.run()
28.12.2017 17:05:47 CRITICAL: cht_if_worker();Error;couldn't open 
requested device:/dev/ttyAMA0
28.12.2017 17:05:47 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
28.12.2017 17:05:47 CRITICAL: ccollgate().run();Error; terminated

Neuinstallation (auf neuer SDCard) nach der Anleitung von URBANsUNITED 
gemacht, leider ohne Erfolg, gleiche Fehlermeldung.

Hat jemand eine Idee wo ich hinfassen muss?
Was übersehe ich?

Danke für Eure Unterstützung im Voraus

Holger

[Norbert S. (junky-zs)]

Hallo Holger,

den Portalias: /dev/ttyAMA0 gibt es so wohl nicht mehr und ist durch 
'serial0' bzw. 'serial1' ersetzt.

Mit: 'ls -l /dev' kannst Du kontrollieren ob /dev/serial0 vorhanden ist.

Ersetze in den Konfigurations-Files diese Werte durch:
  <serialdevice>/dev/serial0</serialdevice>

Betroffene Konfigfiles sind:
 ~/HT3/sw/etc/config/ht_proxy_cfg.xml
(falls der Bus-Adapter direkt vom ht_proxy.server ausgelesen wird.
Dies ist default so.)

 ~/HT3/sw/etc/config/HT3_db_cfg.xml
(Dies nur falls der ht_proxy.server nicht genutzt wird und statt SOCKET 
auf ASYNC konfiguriert wurde: <comm_type>ASYNC</comm_type>)

Nach der Konfigurationsänderung den PI neu booten.

Weitere Details zur Linux Portkonfiguration findest Du u.A. unter URL:
https://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/#Serial_Aliases

Gruß Norbert

[Norbert S. (junky-zs)]

Hallo Ferdinand S,

>Wenn ich alles gut gelesen habe spricht der Pitiny auch EMS?
Die Bezeichnung und Funktion von:'EMS' ist leider zwischen Buderus und 
Junkers unterschiedlich.
Beiden ist allerdings der 2-Draht Bus mit Spannungsversorgung und 
Signalisierung gemeinsam.
Die Protokolle sind jedoch unterschiedlich.

Der ht_pitiny-Adapter setzt das Bus-Signal in ein serielles auswertbares 
Protokoll um. Die Auswertung der Daten muss dann allerdings mit der 
externen Software gemacht werden.
Die Dekodier-Software für die ht-Adapter 
(Mini-/Micro-/ht_piduino-/ht_pitiny-Adapter) ist für das 
Junkers-Bustelegramm geschrieben.
Diese passt nicht zu Buderus EMS bzw. EMS-Plus.

Marke____Bus-Bezeichnung
Buderus: EMS und EMS-Plus
Junkers: EMS2 oder älter Heatronic3, Heatronic4i

So wie ich bisher in den Beschreibungen gefunden habe verwendet 
'nefit'den Buderus EMS bzw. den EMS-Plus Bus.
Der ht_pitiny Adapter passt nicht zu diesem Bus da er aktiv 
Pollingantworten in den Heizungs-Bus sendet.
Du kannst aber eventuell die passiven Mini- oder Micro-Adapter verwenden 
um mit einer eigenen Software die Signale zu dekodieren.
Software dazu gibt es auch unter URL:
https://github.com/bbqkees/Nefit-Buderus-EMS-bus-Arduino-Domoticz

Gruß Norbert

[Ferdinand S. (sir_bacon)]

Hallo Norbert,

Danke für das Antwort, und noch ein gutes Neujahr!

Also, der ht_pitiny würde nicht gehen. Schade, dann kann ich nicht der 
fertige Adapter von Jo benutzen.

Brauch ich also eine micro-adapter. 2 Fragen dazu:
* Gibt es die schon mal fertig zu bewerben?
* Wurde diese dann funktionieren mit der S/W EMS-collector von 
Maniac103: https://github.com/maniac103/ems-collector ?

Gruß, Ferdinand

[Jo (Gast)]

Hallo
Da Ferdinand den Adapter nicht gebrauchen kann, ist er wieder zu haben.

[Mark W. (markidas)]

Ich hätte Interesse am Pitiniy Adapter :-)

[Jo W. (basteljo)]

Zur Info: Beide Pitiny-Adapter sind nun verkauft.
Viele Grüße und viel Bastelspass
Jo

[Martin T. (Gast)]

Hallo Norbert

Erstmal danke für diese fantastische Arbeit.

Nachdem meine Vailant Therme nun langsam aber sicher den Geist aufgibt 
plane ich einen Systemwechsel auf Junkers.
Mir wurde als Therme eine ZSR 18/7 KE angeboten.
Diese hat meines Wissens nach eine HT3 Steuerung.

Da ich im restlichen Haus eine SmartHome Anlage basierend auf Home 
Assistant betreibe suche ich nach einer Möglichkeit auch die Therme zu 
integrieren.

Nun zu meiner Frage.
Derzeit gibt es lt. Junkers Programm für die ZSR 18 3 verschiedene 
Regeleinheiten
C(W/R)100 (1 Heizkreis)
C(W/R)400 (4 Heizkreise, 2 WW Kreise regelbar)
CT100/CT200 (Raumthermostate mit Wlan)

Welche davon kann dein HT-Logger decodieren =?

lg
Martin

[Norbert S. (junky-zs)]

Hallo Martin T.,

>Mir wurde als Therme eine ZSR 18/7 KE angeboten.
>Diese hat meines Wissens nach eine HT3 Steuerung.
Ja, hat sie laut den Junkers-Unterlagen (siehe Bild).

Somit ist dieses Heizgerät auch mit MBLan2 und eben auch mit den 
ht_transceivern (ht_pitiny / ht_piduion) steuerbar.

>Welche (C100/C400/CT100/CT200) davon kann dein HT-Logger decodieren =?
Die wichtigsten Telegramme des CW100 werden dekodiert, eine Steuerung 
mit den ht_transceivern ist auch möglich.
Ich selber hatte einen CW100 an meinem Heizungssystem und konnte die 
Telegramme damit dekodieren (sind im aktuellen Release von 2017 
enthalten).

Die C400 Regler und deren Telegramme sind sehr ähnlich dem C100-Typen, 
haben natürlich zusätzliche Telegramme, aber auch diese werden 
grossteils dekodiert.

Aber nichts ist perfekt und deshalb habe ich mir einen CW400 mit CR10 
und zugehörigem Solarmodul zugelegt. Diese funktionieren ja auch am 
Heatronic3 - Bus.
Nach dem Umbau meiner Heizung (2. Quartal 18) geht das Dekodieren weiter 
:-)

Beim den CT100/CT200 - Reglern weiss ich nicht wirklich ob dort andere 
Telegramme gesendet werden.
Vielleicht hat jemand damit schon Erfahrung gesammelt. Bitte dann hier 
posten.

Gruß Norbert

[Harald G. (hallo_s)]

Weiß jemand oder der neue Junkers Regler CW100 mit dem älteren 
Solarmodul ISB1 in Verbindung mit der älteren Cerapur ZSB 14-3 
funktioniert?
CW100 hat EMS2 BUS Cerapur ZSB14-3 sowie das Solarmodul ISM1 hat 
Heatronic3 neue Thermen Cerapur ZSB 14-4 müssten demnahc Heatronic4i 
haben.

[Nils R. (augur)]

Moin.

Mal ne Frage, ich hab schon länger einen Adapter und einen MB-Lan2 am 
Bus laufen und seit gefühlt letztes Jahr kann ich die Zeitpläne mit der 
Iphone App nicht mehr ändern. Kann das durch die Kombination beider 
Komponenten am Bus kommen oder ist einfach die App defekt (was ich von 
Junkers bzw. Bosch beinahe erwarten würde)?

Vielleicht hat ja noch jemand ein MB-Lan2 am laufen...

Viele Grüße,
Nils

PS. Bei mir stellt sich auch die Sommer/Winterzeit nicht automatisch um. 
Laut Junkers soll sich mein Heizungsbauer das anschauen (toller 
Support...). Sagt das auch jemanden was? In den Einstellungen ist es 
egal, ob ich die Umschaltung aktiviere oder nicht.

[Norbert S. (junky-zs)]

Hallo Nils,
die Bus aktiven ht-Adapter (ht_pitiny, ht_piduino) kann man parallel zum 
MBLAN2 betreiben.
Es muss allerdings die Geräte-Adresse des ht-Adapters von default 13dez. 
auf 10dez. geändert werden. Dann gibt es da auch keine Kollisionen am 
ht-Bus.
Ich glaube aber das Du dies schon gemacht hast und dies als Grund 
ausscheidet.

Welchen Regler (Fxyz oder Cxyz) hast Du in Deinem System und hast Du 
diesen eventuell getausch?
Da habe ich so meine negativen Erfahrungen gemacht, siehe URL:
http://www.heizungsforum.de/board/index.php?thread/11181-mblan2-funktioniert-nicht-mehr-mit-regler-fw100/&postID=116041&highlight=MBLAN2#post116041

Funktionieren die anderen Steuermöglichkeiten (Betriebsmode, 
Temperaturniveau) mit dem MBLAN2 und dem ht-Adapter?

Gruß Norbert

[Nils R. (augur)]

Hi,

die Einbindung mit der Adresse hab ich geändert und es lief bzw. läuft 
auch. Die Umschaltung der Modi oder auch das Auslesen der Parameter 
klappt einwandfrei. Nur die Zeitpläne kann ich nicht mehr mit der Bosch 
App ändern. Hab eine FB120 und hab diese von Anfang an drinnen.

In den App Rezensionen hab ich auch von ähnlichen Problemen bei einem 
anderen Nutzer gelesen. Bosch hab ich mal angeschrieben, aber bisher kam 
da nichts zurück zu dem Zeitplanproblem.

Viele Grüße,
Nils

[Andreas W. (urbansunited)]

Hi!

Wer hat denn eigentlich die Heizungssteuerung mit in seine Home 
Automation eingebunden?
Welche Software nutzt ihr dafür? FHEM, openhab oder?
Ich habe nämlich meine Thermostate für die Fussbodenheizung in den 
Räumen rausgeworfen und steuer aktuell die Anlage über die 
Durchflussmenge und Zeitsteuerung.
Die Thermostate takteten die Heizung einfach zu oft (locker 20x und 
mehr) plus sie waren absolut unzuverlässig, was die angezeigte 
Temperatur anging. 23° eingestellt, 24,5° war der Raum dann, weil das 
Thermostat sich wieder dekalibiriert hatte.
Die aktuelle Umsetzung befriedigt mich aber noch nicht ganz:
0300-0700h Heizung an
0700-0900h Heizung aus
0900-1100h Heizung an
1100h-1400h Heizung aus
1400h-1600h Heizung an
1600h-0300h Heizung aus
Für die angepeilten 23° komme ich damit hin, aber es geht doch bestimmt 
komfortabler? Man könnte ja die Schaltbefehle bequem auch per FHEM 
senden, oder???

Außerdem, wie kriege ich die Pumpenleistung runter? Bei mir ist sie 
immer im 90-100% Bereich. Ist das normal? Hab mal ein Bild dazu 
angehängt.

Danke

URBANsUNITED

[Kaa (Gast)]

Hallo,

ich überlege auch bei mir den BUS mitzuloggen. Ich hatte eine CT100 die 
aktuell jedoch durch ein Tado-Thermostat ersetzt wurde.

Da der Versand aus China für die Bauteile doch eine Weile dauern würde 
und kein Conrad o.ä. in der Nähe ist:
Hat jemand die Teile für einen Bausatz oder einen Bausatz rumliegen?

Wenn ich es richtig verstanden habe wird der Adapter zusätzlich in die 
bestehende Verkabelung mit eingebunden. Ist hierbei etwas im besonderen 
zu beachten?

[whatever_42 (Gast)]

Hallo,

ich besitze in meiner Mietwohnung auch eine Junkers Heizung, welche über 
das Thermostat gesteuert wird von dem ich ein Foto gemacht habe. Kann 
ich die hier besprochene pitiny Lösung dafür auch verwenden? Ich hatte 
bis jetzt den Eindruck als würde diese Lösung eine richtige Verkabelung 
mit der Heizung erfordern und mein Thermostat scheint ja recht 
offensichtlich 868 MHz für die Kommunikation zu verwenden. Falls ich die 
pitiny Lösung dafür verwenden kann, wüsste ich gerne wie und würde dann 
vermutlich auch gerne eines haben, also falls noch jemand so ein Ding.

Vielen Dank schon mal im Voraus.

[Norbert S. (junky-zs)]

Hallo whatever_42,

alle hier beschriebenen Adapter erwarten auf dem Heizungs-Bus das 
Heatronic3, Heatronic4i oder EMS2 Protokoll. Auf diesem Bus werden 
ständig Telegramme zwischen den Modulen ausgetauscht.

Über Funk im 868 MHz Band ist eine ständige Kommunikation nicht erlaubt.
Daher funktioniert die Datenerfassung nicht mit Deinem Funk-Regler TR10.
Eine Verbindung mit mindestens Heatronic3-Bus ist erforderlich.

Gruß Norbert

[Michael (Gast)]

Guten Morgen zusammen,

bin mit diesem Projekt genau das gefunden, was ich gesucht haben. Vielen 
dank für die tolle Vorarbeit und die ausführliche Anleitung. Leider habe 
ich dennoch ein Problem. Beim Hardwaretest (HT3-mini Adapter) will die 
LED (sie ist nicht defekt) nicht leuchten. Eingangswiderstand am HT3 
Anschluss liegt bei 1,3kOhm, galvanische Trennung ist auch gegeben. Das 
sollte also passen. Wenn ich nun am Klemmblock die 14,5V anlege, 
passiert nichts. An der LED messe ich eine Spannung von 7,5V, was 
sicherlich zu hoch ist.

Bauteile wurde alle nach Liste bestellt. In den Abbildungen 3 und 4 der 
Anleitung ist der Transistor unterschiedlich orientiert, gehe davon aus, 
dass er sich entsprechend Abb 2 leichter löten lies. Habe daher den 
Aufbau nach Abbildung 1 und 4 gemacht.

Habe das Ganze auf dem Steckbrett und gelötet versucht. Leider mit 
gleichem Ergebnis.

Die Installetion hat einwandfrei funktioniert, muss diese eigentlich 
noch gestartet werden oder reicht die Installation und der Neustart? 
Habe dazu in der Anleitung nichts gefunden, wie kann eine korrekte 
Installation überprüft werden?

@Norbert, ist es möglich noch einen piduino oder pitiny Adapter zu 
erwerben?

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,

>Beim Hardwaretest (HT3-mini Adapter) will die LED nicht leuchten.
Hast Du mal die Polarität des Bus-Kabels am Klemmenblock getauscht?
Die richtige Polarität ist wichtig, sonst wird die LED auch nicht 
leuchten.

>An der LED messe ich eine Spannung von 7.5V, was sicherlich zu hoch ist.
Wenn Du zwischen der Anode der grünen LED und der analogen Masse (AGND) 
misst so kann dies durchaus so sein. Ca. 15 Volt minus der Zenerspannung 
9.1 Volt kommt in etwa hin.
Wenn Du allerdings direkt über der Diode (zwischen Anode und Kathode) 
diese 7,5 Volt hast, dann ist die Diode defekt oder eben die Polarität 
des Bus-Anschlusses nicht richtig.
Prüfe also noch mal die richtige Polarität an Hand des Schaltplans:
Klemmenblock Pin1 ist an Diode D1 und da muss Plus sein.

Du kannst danach auch mal den Eingang Pin1 des Optokopplers mit der 
analogen Masse AGND (am Optokoppler Pin2) verbinden. Die grüne LED muss 
dann leuchten.

Es muss nichts neu (Heizung etc.) gestartet werden, die Bus-Signale und 
die Modul-Betriebsspannung sind immer da.

Ich habe noch einen ht_pitiny Adapter. Bitte PM an mich. Weiteres dann 
dort.

Gruß Norbert

[Tzem A. (tzema)]

Hat jemand noch ein piduino oder pitiny adapter über was er nimmer
braucht.

oder kann mir einen Löten????

bitte PN wenn jemand noch ein der oben genannten Adapter übrig hat

Danke

[Stefan S. (kami)]

Hallo zusammen,

ich habe auf einem Rpi 3 einen Pitiny mit meiner Junkers Therme im
Einsatz nun möchte ich ein 2,2 TFT LCD über SPI und I2C anschliessen.
Geht das oder blockiert da der Pitiny den Anschluss??

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.,
>... nun möchte ich ein 2,2 TFT LCD über SPI und I2C anschliessen.
Der I2C Bus wird nicht genutzt und der SPI-Bus 'nur' für einen 
Software-Update des ht_pitiny bzw. des ht_piduino.

Allerdings würden die SPI-Signale für das TFT (insbesondere Clk, MOSI) 
den ht_pitiny- / ht_piduino-Adapter beeinflussen.
Insbesondere beim ht_pitiny Adapter liegt das Signal SPI:CLK und das 
Bus-Signal HT-RX (Heizungsbusdaten) am gleichen CPU-Pin.
Es würden keine gültigen Heizungsbusdaten mehr erkannt werden, da der 
SPI-Clock zum TFT diese dann überschreibt.

Helfen kann da nur das Trennen der SPI-SCK und SPI-MOSI Leiterbahn zum 
Adapter-Sockel. Allerdings ist dann auch nicht mehr das Software-Update 
des Bus-Adapters durch den RaspberryPi möglich.

Besser ist also ein Display mit einem DSI- oder HDMI-Interface. 
Allerdings dann wohl auch teurer.

Andere Möglichkeit ist zwei RPi's zu verwenden:
- RPi(2) mit dem ht_pitiny-Adapter bestücken (ein RPi Typ B reicht 
völlig).
- die Heizungs-Daten mit dem ht_proxy.server auf dem RPi(2) an den 
RPi(1) (mit dem TFT-Display) senden.

Gruß Norbert

[Stefan S. (kami)]

Hallo,

vielen Dank für die Info. Aber inzwischen habe ich selber eine bessere 
Lösung gefunden. der RPi hat einen 2ten SPI und den kann auch mit jedem 
Display nutzen. Aus diesem Grund darüber erledigt.

Danke.

Gruß kami

[Stefan S. (kami)]

Hallo zusammen,

habe einen Raspberry Pi 3 B+ mit dem Pitiny draufgesteckt. Habe die 
Software geupdatet und auch an der Platine gebastelt. Kann ich irgendwie 
sehen, ob auf dem Bus Daten ankommen? Die Hardwareverbindung ist 
aufgebaut aber in die SQLlite Datenbank werden keine Daten geschrieben. 
Wie kann ich mich an das Problem rantesten? Funktion der LEDs?? Danke

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.,

Hardware-Kontrolle:
H1. zur Prüfung der Hardwarware sollte man mit der elektrischen 
Kontrolle beginnen (kein Kurzschluss am HT-Busanschluss etc.) und dann 
nach Anschluss an den Heizungsbus die LED's kontrollieren.
Eigenschaften der grünen und roten LED-Anzeigen siehe Bild.

H2. Falls man mehr als einen aktiven ht-Adapter (ht_pitiny oder 
ht_piduino) am Heizungsbus hat, muss einer davon eine andere 
Geräte-Adresse erhalten.
Default ist (13)dez. eingestellt. Diese muss dann bei einem Adapter 
auf (10)dez. eingestellt werden. Wie dies geht ist in der Doku 
beschrieben.
Wird dies nicht beachtet so kann es Telegramm-Kollisionen auf dem 
Heizungsbus geben und der Heizungsbetrieb kann beeinträchtigt werden.
Es sind maximal zwei ht-Adapter am gleichen Heizungsbus erlaubt (wenn 
kein MBLan2 vorhanden ist).

Software-Kontrolle:
S1. Letztes Software-Release von github installieren/updaten.
Ältere rrdtool-Datenbanken (erstellt mit Release 0.1x) müssen auf 
Release (0.3) aktualisiert oder besser noch neu erzeugt werden.

S2. Wenn die LED's auf dem Adapter korrekte Funktion zeigen, kann der 
Datenempfang kontrolliert werden. Dabei wird in diesem Beispiel der 
aktive ht_proxy.server vorausgesetzt.
Aktion:
  Mit einem Browser die Heizungsdaten anzeigen lassen:
    http://<IP-Adresse des RPi>:8088/
Es werden die Heizungs RAW-Daten angezeigt. Bei einem ht_pitiny- oder 
ht_piduino-Adapter wird zusätzlich der Header mit ausgegeben (#HR...) 
siehe Bild.

S3. Kontrolle ob perl-scripte im /tmp-Ordner längere Zeit liegen 
bleiben. Dies deutet dann auf eine Fehlfunktion beim Daten-Eintrag in 
die rrdtool-Datenbank hin. Zum Test kann so ein perl-script von Hand 
aufgerufen werden.
Dabei auf zeitliche Reihenfolge achten, älteste Scripte zuerst und nur 
einmal aufrufen. Falls dann Fehler angezeigt werden sind diese 
auszuwerten.

Gruß Norbert

[Stefan S. (kami)]

Hi Norbert,

alles gut inzwischen. Lag an einer losen Verbindung.

Jetzt rennt alles wieder.

Danke.

Gruß Stefan

[Erhard P. (erhard_p)]

Hallo Norbert,

Dir und den anderen Mitwirkenden und Diskutanten hier im Forum zum Thema 
"Heatronic 3 Adapter" zuallererst ein ganz großes Dankeschön für die 
tolle Ausarbeitung und die ausführlichen Beschreibungen und Anregungen 
zu Hard- und Software!

Unsere Junkersheizung ist zwar schon seit ca. 5 Jahren in Betrieb, 
allerdings wurde der Solaranteil zur Unterstützung der 
Brauchwassererzeugung erst vor ziemlich genau einem Jahr hinzugefügt. 
Schon bald nach der Erstinstallation hatte ich immer wieder den Wunsch, 
die ganzen Verläufe mitzuschreiben ("ein Bild sagt mehr als tausend 
Worte bzw. als ein Zahlenfriedhof"). Nach Ergänzung des Solaranteils 
hab' ich die Recherche wieder aufgenommen und intensiviert und bin 
letztendlich hier gelandet.

Die komplette Anlage besteht aus Gas-Brennwertgerät ZBR 28-3 mit 
Heatronic 3 und eingebautem FW200-Regler, einem Heizkreis mit Mischer am 
IPM1, einem Pufferspeicher zur Heizwasserversorgung der 
Frischwasserstation LSS-TF 40 mit integriertem Frischwasserregler sowie 
dem Solarteil mit ISM1.

Für die Aufzeichnungen kommt der HT3-MicroAdapter zum Einsatz an einem 
betagten Laptop, die Anpassung der Software bzgl. Schnittstelle hat im 
zweiten Anlauf auch geklappt. Soviel zur langatmigen Einleitung.

Leider ist der Frischwasserregler autark und nicht mit dem HT3-Bus 
angebunden. Dafür hat er einen Datenlogger, der auf eine SD-Karte 
schreibt, die man dann mit dem TS_Analyser_1 der Fa. Steca (die 
offensichtlich auch der Entwickler/Hersteller des Junkers-Gerätes ist) 
auswerten kann. Ausserdem hat der Regler noch eine RS232 und eine RS485 
Schnittstelle (Zweck?).

Der langen Rede kurzer Sinn: Ist es denkbar, dass die Daten des 
Frischwasserreglers in ein zusätzliches Diagramm der 
Heizungs-Datenerfassung (HT3) mit aufgenommen werden, z.B. mittels eines 
zweiten Adapters?

Es wäre schön, wenn diese Idee von Dir oder einem der Cracks hier im 
Forum wohlwollend kommentiert würde. Schon mal vielen Dank.

Gruß, Erhard

[Norbert S. (junky-zs)]

Hallo Erhard,

sicher können die Daten mit übernommen werden.
Mein Vorschlag wäre die Daten in dem ohnehin vorhandenen 
Warmwasser-Diagramm der rrdtools-db zu schreiben und darzustellen.
Das Problemchen ist jedoch weniger die Darstellung sondern die Erfassung 
und Dekodierung der Schnittstellen-Daten.
Diese Daten von der SD-Karte auszulesen ist nicht sehr handlich (Karte 
raus/rein).
Von der RS232 Schnittstelle zu lesen sollte möglich sein mit einem 
entsprechenden Adapter (siehe URL und Bild)

https://www4.lernplattform.schule.at/gwk/pluginfile.php/18358/mod_folder/content/0/Thema6_Landschaftslabor/Energieversorgung/EN-instruction_manual-PA_CAB_2_Tarcom_data_cable_5000500063.pdf?forcedownload=1

Aber Achtung: die Steca RS232 Schnittstelle hat wohl 'nur' 3.3 Volt und 
daher auf keinen Fall direkt mit einem Seriellen Port eines PC's 
verbinden.
Hinzu kommt leider das die RS232 nicht galvanisch getrennt ist.

Das Protokoll jedoch ist mir nicht bekannt und hat wohl gar nichts mit 
Heatronic3 zu tun.
Steca hat wohl auch wenig mit Junkers/Buderus (Bosch) zu tun und das 
Protokoll wird wohl auch Steca-Eigenbau sein. Jedenfalls habe ich da 
nichts gefunden.
Daher must Du dann wohl selber mal die Daten erfassen und dekodieren. 
Wenn man dann Substanz hat ist der Rest nur noch ein wenig 
Zusatzsoftware, die dann die Daten in die rrdtool-Datenbank (Warmwasser) 
schreibt.

Noch ein paar Fragen zu Deiner Anlage:
1. Der FW200 kann zwei Kreise bedienen, es ist jedoch wohl nur ein 
gemischter Heizkreis angeschlossen?
2.Wie ist denn der Pufferspeicher mit dem Heizgerät verbunden?
Über Warmwasser klar, aber hat der irgenwelche Temperatursensoren?

Gruß Norbert

[Erhard P. (erhard_p)]

Hallo Norbert,

vielen Dank für Deine Stellungnahme und Deine Gedanken zu meiner Anfrage 
bzgl. der Erfassung und Darstellung der Daten der Frischwasserstation.

Gleich vorweg muss ich mich "outen" als absoluter Noob, was Software im 
Allgemeinen und programmieren im Besonderen betrifft (so als gelernter 
Maschinenbauer), dagegen elektronische Schaltungen zusammenlöten, geht 
so leidlich, wenn nicht zu "smd"-lastig.

Jetzt zu Deinen Punkten:

> Mein Vorschlag wäre die Daten in dem ohnehin vorhandenen
> Warmwasser-Diagramm der rrdtools-db zu schreiben und darzustellen.
So etwa hab' ich mir das auch vorgestellt.

> Diese Daten von der SD-Karte auszulesen ist nicht sehr handlich (Karte
> raus/rein).
So hab' ich das in der Not zwei-/dreimal gemacht, dazu muss aber die 
Wärmedämm-Schutzhaube abgenommen und die Datenloggerfunktion deaktiviert 
werden (korrekterweise, ähnlich USB-Stick auswerfen) , bevor die 
SD-Karte entnommen werden kann. Die Datenkorrelation zw. FriWaSt und 
Hzg. ist da natürlich nicht gegeben, deswegen ja mein Ansinnen mit 
zweitem Adapter und parallelem Mitschreiben. Die Dateien werden im 
.CSV-Format Tages-/Monats-/Jahresweise gespeichert, was ich als Anhang 
beifügen könnte (oder fliegt da mein Beitrag raus?).

> Von der RS232 Schnittstelle zu lesen sollte möglich sein mit einem
> entsprechenden Adapter (danke für Deinen Vorschlag).
Geht als Adapter auch die Schaltung mit dem CP2102-Chip (neu: CP2102N), 
wie z.B. im HT3-MicroAdapter verwendet? So einen hätte ich noch.

> Daher musst Du dann wohl selber mal die Daten erfassen und dekodieren.
Das hab' ich ja bereits gemacht und die Kurven mit dem TS_Analyser_1/2 
von Steca angezeigt bekommen, aber halt ohne Zusammenhang.

> 1. Der FW200 kann zwei Kreise bedienen, es ist jedoch wohl nur ein
> gemischter Heizkreis angeschlossen?
--> nur ein gemischter Heizkreis.

> 2.Wie ist denn der Pufferspeicher mit dem Heizgerät verbunden?
> Über Warmwasser klar, aber hat der irgendwelche Temperatursensoren?
--> ein Temperatursensor, bezeichnet mit Speicherfühler-oben.
Der Pufferspeicher wird heizungs-technisch wie ein Brauchwasserspeicher 
behandelt.

Gruß Erhard

[Norbert S. (junky-zs)]

Hallo Erhard,

> Geht als Adapter auch die Schaltung mit dem CP2102-Chip (neu: CP2102N),
Ja, der ist ein 3.3Volt Typ.

> Die Dateien werden im .CSV-Format Tages-/Monats-/Jahresweise gespeichert, was
> ich als Anhang beifügen könnte...
Dies Daten werden ja schon vom TS_Analyser_1/2 dekodiert und angezeigt. 
Da sehe ich keinen Bedarf.
Die Baustellen sind auf der RS232 Schnittstellte zu finden weil dort 
sicher eine etwas andere Reihenfolge / Struktur als auf der SD-Karte 
(*.csv) vorhanden ist.
Auch kann es passieren, dass diese Schnittstelle von sich aus gar nichts 
ausgibt und man als Startsequenz ein 'Zauberwort' auf die Schnittstelle 
geben muss damit eine Antwort ueberhaupt kommt (Viessmann macht dies 
z.B. so).
Ich hoffe nicht das dies so ist und das die Daten wie bei Heatronic von 
selber sprudeln. Wenn dem jedoch nicht so ist wird es ekelig.
Bedarf sehe ich also bei:
1. RS232 Schnittstelle zum fliegen bringen.
2. Daten der RS232 ZUSAMMEN zeitgleich mit Daten der SD-Karte erfassen.
3. Ergebnisse vergleichen und Strukturen finden.
4. Software dazu erstellen und Daten in rrdtool-db schreiben.

Vielleicht hat ja jemand dies schon für den Frischwasser-Regler von 
Steca erstellt. Falls ja bitte melden.

Gruß Norbert

[Erhard P. (erhard_p)]

Hallo Norbert,

vermutlich ist Dir und den potentiellen Mitlesern hier im Thread bereits 
bekannt, um welchen Frischwasser-Regler es geht, trotzdem der 
Vollständigkeit halber hier ein link auf die Steca-Original-Ausführung 
TF A603 MC:

http://www.steca.fr/images/stories/documents/TH/regulateurs-eau/Manuel-TF-A603MC_EN.pdf

Den link hab ich nur über Umwege ergoogelt, auf der Steca-homepage ist 
die Druckschrift auch im Archiv (--> Solarthermie --> Produktarchiv) 
nicht (mehr) zu finden. Das Junkers - Pendant hat die 
Druckschrift-Sachnummer: 6 720 644 711. Die Seite der Junkers / Bosch 
"Technische Dokumentation" mit dem link:

https://www.junkers.com/fachkunde/unterlagen_fachkunde/technische_unterlagen_fachkunde/technische_unterlagen

geht gerade nicht.

Auf der Seite 14 der Druckschriften ist die Schnittstelle hardware-mäßig 
beschrieben.

Eine weitere Gerätebeschreibung findet sich unter diesem link:

http://westech-solar.com/download/steca/st603_mc.pdf

Dort wird unter Schnittstellen ein "Steca TPC 1-Bus" (?) erwähnt.

Vielleicht helfen diese Hinweise irgendwie weiter.

Gruß Erhard

[Max R. (Gast)]

Braucht noch jemand einen ht_pitiny Adapter? Ich habe einen übrig, finde 
keine Zeit ihn zu integrieren. Bitte PN. Gruß

[Hartmut (Gast)]

Hallo zusammen,

ich "durfte" gerade einmal alles von vorne Aufsetzen und bin auf ein 
Problem gestoßen, welches ich nicht ganz erklären kann.

Hardware: Pi 2 Model B V1.1
Raspbian Stretch
HT3-mini Adapter

ASYNC Interface auf /dev/ttyAMA0

Ich erhalte beim start des collgate folgende Fehler:

03.08.2018 23:47:22 CRITICAL: cht_if_worker();Error;couldn't open 
requested device:/dev/ttyAMA0
03.08.2018 23:47:22 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
03.08.2018 23:47:22 CRITICAL: ccollgate().run();Error; terminated

Auch ein Test mit HT3_Analyser schlug fehl.

Irgendwie bin ich darauf gekommen einmal den Proxy mit dem collgate zu 
vergleichen und auf eine Abweichung gestoßen:

in ht_proxy_if.py ist folgende zeile auskommentiert:
#disabeld, no timeout  self.__port.setInterCharTimeout(0.1) #VTIME; set 
to 0.1*1sec

Kommentiere ich diese Zeile auch im ht3_worker.py aus, so funktioniert 
der HT3_Analyser einwandfrei.

Warum ist die Zeile im ht3_worker noch einkommentiert? Absicht, Feature 
oder Bug?

Danke für Eure Hilfe und Gruß
Hartmut

[Norbert S. (junky-zs)]

Hallo Hartmut,

ja, dieses timeout kann im ht3_worker.py deaktiviert werden.

Allerdings benutzt (per Default) der ht_collgate gar nicht das serielle 
Interface /dev/ttyAMA0 sondern holt sich die Daten vom ht_proxy über das 
SOCKET-IF.
Und nur der ht_proxy.server bemuckelt die serielle Schnittstelle.
Mehrere Instanzen auf einer seriellen Schnittstelle geht nun mal nicht.

Daher der Proxy, der dann die Heizungs-Daten per Socket an N-Clients 
sendet.
Wie gesagt, dies ist die Default-Einstellung in den 
Konfigurations-Files.
Dies ist auch unabhängig davon ob alle Prozesse nur auf einem PI oder 
verteilt auf mehreren laufen.
Einzig die Baudradte muss je nach Adapter-Typ im proxy-Konfigfile 
angepasst werden, ansonsten ist dies auch unabhängig vom Adapter-Typ.

Offensichtlich benutzt Du nicht den ht_proxy.server sondern je nach 
Bedarf den HT3_Analyser ODER ht_collgate. Beides gleichzeitig geht dann 
natürlich nicht, da Du ja das Konfigurations-File 'HT3_db_cfg.xml' wohl 
von SOCKET auf ASYNC umgestellt hast.
Dies hat natürlich die oben geschilderten Nachteile.

Gruß Norbert

[Hartmut (Gast)]

Hallo Norbert,

Danke für deine schnelle Antwort.

Ich nutze schon seit einigen Jahren die erfassung der Heizungsdaten, bin 
aber jetzt auf einen aktuelleren Pi umgestiegen und habe daher mein 2015 
zuletzt aktualisiertes System neu aufgebaut.

Da ich ausschließlich eine Website, welche lokal gehosted wird, als 
Frontend für die Ergebnisse nutze, habe ich darauf verzichtet den Proxy 
einzusetzen.
Den Analyser habe ich nur verwendet, um zu überprüfen, ob die Daten 
korrekt gelesen werden. Sonst setze ich keine weiteren Schnittstellen 
ein.

Wenn ich dich richtig verstehe ist die Zukunft des Projekts aber eher 
der Proxy und due würdest mir eher empfehlen auch für meinen 
Anwendungszweck auf diesen umzusteigen. Richtig?

Auf jeden Fall einmal Danke für dieses Projekt!

Gruß
Hartmut

[Norbert S. (junky-zs)]

Hallo Hartmut,

da Du ja 'nur' Heizungsdaten erfassen willst, kannst Du auch auf den 
proxy.server verzichten.
Allerdings hast Du dann den Nachteil, das bei jedem Aufruf eines anderen 
Tools z.B. HT3_Analyser etc. das gerade laufende Programm stoppen musst 
weil es ja exklusive auf den seriellen Port zugreift.
Genau dies vermeidet der proxy.server und er sendet die Heizungsdaten 
vom seriellen Port an N verbundene Clients.
Dies ist die default-Einstellung in den Konfigurationsfiles.

Wenn man die Heizung steuern will (mit ht_pitiny oder 
ht_piduino-Adapter) dann muss man den proxy.server verwenden, da dieser 
die Steuer-Kommandos für die Adapter aufbereitet und an den seriellen 
Port sendet.

Gruß Norbert

[Hartmut (Gast)]

Hallo zusammen,

das System läuft jetzt nach der Umstellung auf den Proxy schon eine 
ganze Zeit fehlerfrei, bis folgendes aufgefallen ist:

Es liegt neben der eigentlichem SQLite-Datenbank (aktuell über 200MB 
groß) noch ein 110MB großes sqlite-journal File.

Im Log sehe ich regelmäßig die Bereinigung alter Datensätze (Zeit für 
die Bereinigung ist auf 30 Tage gesetzt) aber die Datenbank wächst 
trotzdem.

Ich vermute die SQLite Datenbank hat sich irgendwann an einer 
Transaktion verschluckt und danach alle Löschoperationen 
zwischengespeichert, während die DB weiter wuchs.

Hat das jemand von Euch auch schon einmal erlebt?
Gibt es bekannte Gründe dafür?

Danke für eure Infos.

Gruß
Hartmut

[Markus B. (spektrum)]

Hallo Norbert,

mein System hat nun zwei Jahre erfolgreich funktioniert:
 - Raspberry #1 mit ht_proxy und ht_piduino
 - Raspberry #2 mit FHEM und HEATRONIC
 - FW100

Wegen eines korrupten Filesystems musste ich meinen Raspberry #1 mit 
ht_piduino und ht_proxy im Sommer neu aufsetzen. Die Raspian Version hat 
sich auf stretch geändert. Weitere Änderungen habe ich nicht 
vorgenommen.

Nach der Neuinstallation von Raspberry #1 kann ich nun den hc1_mode 
nicht mehr umschalten. Weder über ht_netclient, noch über HEATRONIC.
Laut Log werden Daten zwar gelesen und geschrieben. Die HEATRONIC zeigt 
auch weiterhin fortlaufend die aktuellen Readings, wie Temperatur, 
Brenner, ... von der Heizung. Die Verbindung funktioniert, nur Schreiben 
kann ich nicht (mehr).

Was kann ich noch prüfen?

Hier das ht_proxy.log

25.09.2018 20:28:30 INFO: ----------------------
25.09.2018 20:28:30 INFO: cht_proxy_daemon init
25.09.2018 20:28:30 INFO: cht_proxy_daemon(); common serveraddress used
25.09.2018 20:28:30 INFO: cht_proxy_daemon start as 
proxy-server:'';port:'8088'
25.09.2018 20:28:30 INFO: logfile:'./var/log/ht_proxy.log'
25.09.2018 20:28:30 INFO: cportwrite();thread start; devicetype:MODEM
25.09.2018 20:28:30 INFO: cportread() ;thread start; devicetype:MODEM
25.09.2018 20:28:36 INFO: Client-ID:1; ('192.168.6.34', 54188) connected
25.09.2018 20:28:36 INFO: Server   :('0.0.0.0', 8088)
25.09.2018 20:28:36 INFO: Client-ID:1; register(); got devicetype:MODEM
25.09.2018 20:28:36 INFO: csocketsendThread(); socket.send thread start
25.09.2018 20:28:36 INFO: Client-ID:1; added; number of clients:1
25.09.2018 20:28:36 INFO: Client-ID:1; cht_RequestHandler(); 
socket.receive thread start
25.09.2018 20:28:36 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x10\xff\x0e\x00e\x01'
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:10
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:0e
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:65
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:36 DEBUG: Client-ID:1;cportwrite();value:3f
25.09.2018 20:28:39 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x18\xff\x0e\x00e\x01'
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:18
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:0e
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:65
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:39 DEBUG: Client-ID:1;cportwrite();value:26
25.09.2018 20:28:42 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x10\xff\x04\x00y\x01'
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:10
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:04
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:79
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:42 DEBUG: Client-ID:1;cportwrite();value:57
25.09.2018 20:28:45 DEBUG: Client-ID:1; 
recv:b'#\t!S\x11\x18\xff\x04\x00y\x01'
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:23
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:21
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:53
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:11
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:06
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:18
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:ff
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:04
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:00
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:79
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:01
25.09.2018 20:28:45 DEBUG: Client-ID:1;cportwrite();value:4e
25.09.2018 20:28:48 INFO: Client-ID:1; ('192.168.6.34', 54188) 
disconnected
25.09.2018 20:28:48 INFO: Client-ID:1; removed; number of clients:0
25.09.2018 20:28:48 INFO: Client-ID:1;cportwrite();couldn't read from 
queue

[Norbert S. (junky-zs)]

Hallo,

@ Markus B.
Die Bytes in den Debug-Ausgaben des ht_proxy sind korrekt.
Somit wird wohl kein Software- sondern ein Hardware-Fehler/Problem 
vorhanden sein. Sicher setzt Du das letztgültige Software-Release ein.

Daher kontrolliere mal die grüne und rote LED. Beide müssen kurz 
aufblitzen, insbesondere die Rote zeigt einen Sendevorgang an.
Dies immer und auch dann wenn keine Kommandos zur Heizung gesendet 
werden.
Hat sich da etwas in Deiner Hardware-Umgebung geändert, längeres Kabel 
zur Heizung etc?

@ Hartmut (Gast)
Das sqlite-Journal ist ja nur temporär und sollte daher nicht so gross 
werden wie bei Dir. Daher kontrolliere noch einmal die 
User-Berechtigungen zur Datenbank und eventuell vorhandene 
Fehlermeldungen.
Du schreibst auch 'das System läuft fehlerfrei...' somit nehme ich an 
das Du die Daten aus der sqlite-Datenbank nicht benötigst sondern 'nur' 
die Grafiken der rrdtool-Datenbank auswertest.
Somit könntest Du auch im Konfiguration-File die sqlite-Datebank 
deaktieren.

Gruß Norbert

[Markus B. (spektrum)]

Hallo Norbert,

nachdem die bisherige Fehlersuche nicht erfolgreich war, habe ich den 
atmega Chip ausgetauscht. Jetzt funktioniert es wieder. Was jedoch nicht 
heissen soll, dass es zwingend am Chip lag.

Danke und Grüße.
Markus

[Norbert S. (junky-zs)]

Hallo Markus,

ich glaube auch nicht das der Atmega Chip defekt ist. Versuche mal den 
alten Chip erneut mit den Programm- und EEPROM-Daten zu füttern.
Er wird wahrscheinlich wieder laufen.

Wenn dem so ist, dann kontrolliere mal die Fuses-Einstellungen. Diese 
sollten so eingestellt sein, das ein Beschreiben von Flash-/EEPROM bei 
Unterspannung vermieden wird.
Kann also durchaus sein das sich die EEPROM-Daten beim Ausschalten des 
RPi verändert hatten und beim erneuten Einschalten die Checksumme nicht 
mehr stimmt.
In diesem Fall läuft der ht_piduino/ht_pitiny-Adapter 'nur' im 
Empfangsmode.
Empfehlung:
Fuses checken. Details stehen in der Doku unter:
 https://github.com/norberts1/hometop_ht_transceiver/docu/fuses.ods

Gruß Norbert

[Markus B. (spektrum)]

Hallo Norbert,

den alten Chip gibt es nun nicht mehr. Er hat bei der Operation seine 28 
Beinchen eingebüßt :-)

Vor dem Austausch hatte ich bereits versucht, den Chip neu zu betanken. 
Es gab beim Schreiben der extended Fuse jedoch eine Fehlermeldung: FF 
<-> 0F (Lesefehler) und es hat danach auch immer noch nicht 
funktioniert.

Daher der Gedanke den Chip zu tauschen.
Es funktioniert mit dem neuen Chip jetzt.
Den Fuse-Fehler gibt es aber auch beim neuen Chip.

Viele Grüße
Markus

[Stefan S. (kami)]

Moin zusammen,

kann man einen Junkers FR 50 Raumregler zusammen am Bus mit dem HT3 und 
einem RPi verwenden?

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.

der Regler FR50 erlaubt leider nicht die Steuerung der Heizung durch 
MBLan2 oder ht_pitiny/ht_piduino.
Das hat Junkers in diesen Regler-Typ nicht eingebaut.

Allerdings kann man trotzdem die Heizungsdaten mit den hier 
vorgestellten Adaptern und dem RPi dekodieren und sich anzeigen lassen.

Gruß Norbert

[Stefan S. (kami)]

Okay vielen Dank aber ich dachte man kann die Heizung eh nicht ansteuern 
nur auslesen??

Gruß kami

P.s. Ich habe in meiner Heizung einen fr 120 verbaut an den ich den fr 
50 und den ht3 hängen will.

[Norbert S. (junky-zs)]

Hallo Stefan S.,

die Junkers-Heizungen können auch mit den aktiven Adaptern: ht_pitiny 
bzw. ht_piduino gesteuert werden, der Empfang geht mit allen 
Adapter-Typen.

Allerdings sind ein paar Dinge erforderlich.
1. Heatronic3/Heatronic4i oder EMS2 - Bus
2. Fxyz- oder Cxyz-Regler
Das Fertigungs-Datum der Fxyz Regler ist wichtig, siehe:
  Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
3. FR50 Regler lässt sich nicht steuern

Die Steuerbarkeit der einzelnen Parameter hängt von den Reglern ab. Die 
Basisfunktionen: 'Temperatur', 'Heizungsmode' beherrschen alle.

Ich selber habe verschieden Regler am Heatronic3 - Bus verwendet bzw. 
getestet (auch Steuerfunktion)
FW100 mit FB10 / FB100
CW100
CW400 mit/ohne CR10
Den FR120 habe ich nicht, jedoch Foren-Teilnehmer haben damit schon 
Erfolg gehabt.
Zur Kombination: FR120 mit FR50 kann ich nichts sagen. Mir kommt diese 
Kombination auch eigenartig vor, es sei denn man hat zwei separate 
Heizkreise bei denen beide Raumtemperatur geführt sind.
Gruß Norbert

[Stefan S. (kami)]

Hi Norbert,

vielen Dank jetzt sehe ich es auch. Mir ist wichtig über den Regler FR 
50 mit etwas Hardwaremodifikation die Warmwassersofortfunktion 
auszulösen. Das geht ja sonst nicht, wenn ich das richtig sehe. Dafür 
will ich den Button per µC schaltbar machen.

Sehe ich das so richtig? Der HT3-Adapter soll parallel einfach nur zum 
Loggen der Daten von der Heizungsanlage am Bus hängen bleiben.

Vielen Dank.

Gruß kami

[Norbert S. (junky-zs)]

Hallo Stefan S.,

> Mir ist wichtig über den Regler FR 50 mit etwas Hardwaremodifikation
> die Warmwassersofortfunktion auszulösen.
Dein Regler FR120 hat ja eine eigene Taste dafür.
Wozu also noch separat eine Hardware-Modifikation?

Gruß Norbert

[Henrik (Gast)]

Hallo,

ich versuche gerade meinen ht_pinity in betrieb zu nehmen (Danke 
nochmals Norbert). Ich bekomme allerdings wenn ich die DBs erstellen 
möchte folgende Fehler:
pi@raspi_htpinity:~/HT3/sw $ cd
pi@raspi_htpinity:~ $ cd ./HT3/sw
pi@raspi_htpinity:~/HT3/sw $ ./create_databases.py
------------------------------------------------
Create: sqlite -database
sqlite-database:'./var/databases/HT3_db.sqlite' created and access 
possible
------------------------------------------------
Create: rrdtool-database (if request is enabled)
cdb_rrdtool.createdb_rrdtool();INFO;Database:'./var/databases/HT3_db_rrd 
'  will be created
rrdtool create /home/pi/HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd 
--start 1343999400 --step 60 DS:T_vorlauf_soll:GAUGE:120:U:U 
DS:T_vorlauf_ist:GAUGE:120:U:U DS:T_ruecklauf:GAUGE:120:U:U 
DS:T_mischer:GAUGE:120:U:U DS:V_modus:GAUGE:120:U:U 
DS:V_brenner_motor:GAUGE:120:U:U DS:V_brenner_flamme:GAUGE:120:U:U 
DS:V_leistung:GAUGE:120:U:U DS:V_heizungs_pumpe:GAUGE:120:U:U 
DS:V_zirkula_pumpe:GAUGE:120:U:U DS:V_speicher_pumpe:GAUGE:120:U:U 
DS:T_aussen:GAUGE:120:U:U DS:C_betrieb_gesamt:GAUGE:120:U:U 
DS:C_betrieb_heizung:GAUGE:120:U:U DS:C_brenner_gesamt:GAUGE:120:U:U 
DS:C_brenner_heizung:GAUGE:120:U:U DS:V_displaycode:GAUGE:120:U:U 
DS:V_causecode:GAUGE:120:U:U DS:V_spare_1:GAUGE:120:U:U 
DS:V_spare_2:GAUGE:120:U:U RRA:LAST:0.5:5:1051200 
RRA:AVERAGE:0.5:1:525600 RRA:MAX:0.5:5:105120 RRA:MIN:0.5:5:105120 
failed: cannot allocate memory at /usr/share/perl5/RRDTool/OO.pm line 
444
db_rrdtool.createdb_rrdtool();Error;<db_rrdtool.createdb_rrdtool();Error 
;rrdtool-database:'./var/databases/HT3_db_rrd'  not created>
rrdtool-databases:'./var/databases/HT3_db_rrd' not available

Wo liegt mein Problem?

Gruß

Henrik

[Nils R. (augur)]

Hi.

Sieht für mich so aus als hättest du nicht genug Platz auf der SD Karte 
oder wo das Programm die Daten ablegt. Du brauchst dafür 1GB glaube ich. 
Schau mal mit DF nach.

Vg Nils

[Henrik (Gast)]

Ist eigentlich ne 16Gb Karte....

pi@raspi_htpinity:~/HT3/sw $ df
Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root       15242096 4655676   9938332   32% /
devtmpfs           87792       0     87792    0% /dev
tmpfs              92112       0     92112    0% /dev/shm
tmpfs              92112    3776     88336    5% /run
tmpfs               5120       4      5116    1% /run/lock
tmpfs              92112       0     92112    0% /sys/fs/cgroup
/dev/mmcblk0p1     41853   22540     19313   54% /boot
tmpfs              18420       0     18420    0% /run/user/1000

[Henrik (Gast)]

Kann es sein, dass mein Raspi nicht genügend RAM frei hat? Habe die 
Version 1 mit 256Mb?

pi@raspi_htpinity:~/HT3/sw $ free -m -t
              total        used        free      shared  buff/cache 
available
Mem:            227          81          42           9         102 
89
Swap:            99           0          99
Total:          327          81         142
pi@raspi_htpinity:~/HT3/sw $

[Norbert S. (junky-zs)]

Hallo Henrik,

kann durchaus sein das diese 256Mb zumindest für die Erzeugung der 
Datenbanken zu klein ist.
Testehalber kannst Du ja die Grösse der rrdtool-DB Files reduzieren.
Dazu im File: /HT3/sw/lib/rd_rrdtool.py und Zeile: 428 den Wert von 
1051200 auf 105120 reduzieren.
Die rrdtool-DB Files werden dann kleiner.
Die Datenhaltung ist dann halt keine 10 Jahre mehr, aber bis dahin hast 
Du sicher einen neueren RasPi:
 self.__rrdtoolh.write('        archive     => { \n')
 self.__rrdtoolh.write('            rows     => 105120,\n')
 self.__rrdtoolh.write('            cpoints  => 5,\n')
 self.__rrdtoolh.write("            cfunc    => 'LAST',\n")
 self.__rrdtoolh.write('        },\n')
Wenn Du die sqlite-DB nicht brauchts, dann im Konfigurationsfile 
deaktiviert lassen.
Nach der Änderung alte DB-Fragmente loeschen und dann noch mal die 
Datenbanken mit createdatabases erzeugen.
Gruß Norbert

[Henrik (Gast)]

Moin Norbert,

danke für deine Hilfe! Allerdings habe ich es gestern Abend noch 
geschaft, in dem ich eine SWAP angelegt habe. Danach liesen sich die DBs 
erzeugen. Läuft jetzt auch soweit alles, bis auf das ich keine Daten der 
Heizkreise bekomme?

Mein System:
Junker Cerapur ZSB 14-4C (CW400 integriert)
2 gemiste Heizkreise an MM200

[Norbert S. (junky-zs)]

Hallo Henrik,
prima das es jetzt läuft. Daten werden auch in die Grafiken geschrieben.

Allerdings sind tatsächlich zu wenig Daten in den Heizkreis-Diagrammen.
Dies liegt hauptsächlich noch an den neuen Telegrammen der MM200 die 
noch zu dekodieren und mit in die Grafik auszugeben sind.
Ich selber habe zwar eine CW400 jedoch keine MM200.
Deshalb wäre ist gut wenn Du ein binäres Logfile Deiner Anlage über ca. 
1-2 Std. erstellen kannst. Eventuell mit markanten Punkten wo etwas am 
Mischer passiert.
Wie das geht ist beschrieben unter:
Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi"
Das Binärfile kannst Du ja hier posten. Dann kann ich die Daten 
analysieren und die Software anpassen.
Gruß Norbert

[Henrik (Gast)]

Hallo Norbert,

anbei mein Logfile. Nochmal zu meinem Setup:

Junker Cerapur ZSB 14-4C (CW400 integriert)
2 gemischte Heizkreise an MM200
1x Temperaturfühler an hydraulischer Weiche an MM200 angeschlossen.

Im Zeitraum des Logs wurden die Msicher kontinuierlich angesteuert, 
mindestens eine Warmwasserbereitung ist inkludiert. Es kann sein, dass 
der Brenner nicht all zu oft gelaufen ist, da meine bessere Hälften den 
Kamin an hat und somit eine Rücklaufanhebung über den Pufferspeicher 
stattgefunden hat.

Hoffe meine Daten helfen.
Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

>Hoffe meine Daten helfen.
Ja sehr!

Habe mit Deinem Logfile die Software anpassen können.
Anpassungen sind im Besonderen bei der Dekodierung der Telegramme und 
bei den Anzeigen für die Heizkreise gemacht worden (siehe HK meiner 
Anlage).

Da du wohl der einzige mit 2 gemischten Heizkreisen und dem MM200-Modul 
bist ist es an Dir die obige Test-Software auf Dein System loszulassen.
Die Software ist jedoch für möglichst alle Junkers-Systeme ausgelegt und 
somit auch für andere Systemkonfigurationen geeignet.

Das obige Tar-File ist das komplette Projekt in einer Testversion.
Nach dem Entpacken liegen alle Files unter ./tmp/HT3/....
Kannst ja Deine alte Installation unter ~/HT3 umbenennen und das neue 
(Testversion) an dessen Stelle setzen. Die Datenbankstruktur hat sich 
nicht geändert. Somit kannst Du die alten Dateninhalte weiter nutzen.

Beim rrdtool-draw der Heizkreise sind die Draw's und Legenden 'T-Soll 
(Vorlauf)', 'T-Mischer' und 'HK-Pumpe' hinzugekommen.
Hinweis: 'T-Mischer' wird immer angezeigt auch wenn kein Mischer im 
System vorhanden ist.
Probier es aus und falls Probleme auftauchen oder Verbesserungen 
sinnvoll sind dann hier posten.

Wenn die Software einen Release-Status erreicht hat wird die natürlich 
wieder unter Github veröffentlicht:
URL
https://github.com/norberts1/hometop_HT3

Gruß Norbert

[Henrik (Gast)]

Moin Norbert!
Danke für die Testversion. Habe diese soeben mal versucht zu 
implemnetieren. Hab meine lauffähige Version umbenannt und die neue 
Version umkopiert.
Danach HT3_db_conf & ht_proxy_conf angepasst und meine alten DBs nach 
/var/databases kopiert.
Danach konnte ich mit FHEM weiterhin daten auslesen, allerdings wurden 
keine .pngs erstellt und über MQTT konnten ebenfalls keine Daten 
abgerufen werden. Daraufhin habe ich die Datenbanken noch einmal 
gelöscht und über das Skript neu generiert. Auch hier nach konnten nur 
via FHEM Daten ausgelesen werden. ht_proxy und ht_collgate laufen....
Hast du einen Tipp für mich wo ich noch Suchen könnte?

Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

es müssen insgesamt drei ht_Daemons laufen: ht_proxy.py, ht_collgate.py 
UND httpd.py (siehe Bild).
httpd.py dient dabei als http.server für den anfragenden Browser. Ohne 
den wirst Du keine Anzeige im Browser erhalten. Die *.png Files müssen 
auch in dem Verzeichnis vorhanden sein wo der httpd.py Daemon läuft.
Dies ist aber schon so in der Default-Konfiguration eingestellt.

Ebenso ist die Startreihenfolge wichtig:
 zuerst: ht_proxy.py
 dann  : ht_collgate.py oder/und FHEM
Dies wird nach einem boot/reboot automatisch durch die Start-scripte 
gewährleistet.

MQTT ist per default NICHT aktiviert. Dazu das Konfig-File 
'collgate_cfg.xml' anpassen und MQTT aktivieren. Danach ht_collgate.py 
neu starten.

Hinweis: Ich habe erst einmal nur die rrdtool-draw Schnittstelle mit der 
*.png-File Ausgabe/Anzeige bearbeitet. Die anderen Schnittstellen muss 
ich noch bearbeiten/ergänzen.
Das FHEM Modul ist ja noch nicht geändert und somit werden dort die 
'neuen' Informationen auch nicht angezeigt.

Gruß Norbert

[Henrik H. (henrik_h271)]

Danke Norbert,
jetzt läuft es. Werde jetzt erst einmal ein bisschen Daten sammeln und 
dann noch einmal Rückmeldung geben. Über MQTT müsste ich die neuen Daten 
doch schon auslesen können korrekt?

Gruß

Henrik

EDIT: Müssen die DBs zwingend neu erstellt werden? In den pngs wird 
nicht die aktuelle Mischerposition angezeigt, ist das korrekt?

[Stefan S. (kami)]

Hallo zusammen,

ich habe gesehen, das auf dem HT-Bus immer ein gewisses Telegramm 
gesendet wird, wenn die Warmwassersofortfunktion aktiviert wird. Das 
möchte ich gerne mit einem kleinen Python-Client erkennen und auswerten. 
Ehrlich gesagt komme ich aber noch nicht so richtig mit dem 
Beispielclient zurecht. Gibt es ein Beispiel von jemanden hier, wie ich 
die einzelnen Telegramme richtig darstellen kann:

Mein Skript sieht zur Zeit so aus:

import sys, time
sys.path.append('lib')
import ht_proxy_if

import time

configfile="./etc/config/ht_proxy_cfg.xml"

print("   -- start socket.client --")
client=ht_proxy_if.cht_socket_client(configfile, 
devicetype=ht_proxy_if.DT_MODEM)
str = ""
while 1:
  ch= client.read(1).decode("latin-1")
  #print (ch)
  if ch != "#":
      str = str + ch
  else:
    if "HR" in str:
      print (str)
    str = ""

damit sehe ich zwar einzelne Zeilen aber ich möchte natürlich mehr 
filtern können.

Kann mir jemand dabei helfen?

Vielen Dank.

Gruß kami

[Stefan S. (kami)]

Hi,

habe es inzwischen durch eine Erweiterung der Ccollgate.py ergänzt und 
klappt super.

Trotzdem Danke.

Gruß kami

[Norbert S. (junky-zs)]

Henrik H. schrieb:
> Über MQTT müsste ich die neuen Daten
> doch schon auslesen können korrekt?
Es fehlen noch die <accessname> Namen für die neuen Parameter im 
Konfigurationsfile und den Heizkreisen. Diese kannst Du bei Dir manuell 
für Deine zwei Heizkreise nachtragen in <systempart name="heizkreis1"> 
und <systempart name="heizkreis2">
        <logitem name="V_spare_1">
            <datatype>INT</datatype>
            <datause>GAUGE</datause>
            <maxvalue>100</maxvalue>
            <default>0</default>
            <unit>Grad</unit>
            <displayname>T-Soll (Vorlauf)</displayname>
            <accessname>hc1_Tflow_measured</accessname>
bzw. für HK2:
            <accessname>hc2_Tflow_measured</accessname>

        </logitem>
        <logitem name="V_spare_2">
            <datatype>INT</datatype>
            <datause>GAUGE</datause>
            <maxvalue>100</maxvalue>
            <default>0</default>
            <unit></unit>
            <displayname>Heizkreispumpe</displayname>
            <accessname>hc1_pump</accessname>
bzw. für HK2:
            <accessname>hc2_pump</accessname>
        </logitem>
Nach der Änderung den ht_collgate ntürlich wieder neu starten damit die 
Änderungen übernommen werden.

Henrik H. schrieb:
> Müssen die DBs zwingend neu erstellt werden? In den pngs wird
> nicht die aktuelle Mischerposition angezeigt, ist das korrekt?
Nein und Ja. Müssen nicht neu erstellt werden und Mischerposition wird 
nicht mit im rrdtool-draw angezeigt weil ja dies wohl weniger 
interessant ist und weil keine freien 'V_spare logitems' mehr im 
Konfigfile vorhanden sind.
Kann man zwar eintragen, aber dann muss die Datenbank wieder neu 
erstellt werden.
Gruß Norbert

[Henrik H. (henrik_h271)]

Das mit den fehlenden Namen hätte mir ja auch auffallen können... 
**grummel**
Alles in Allem sehen die Werte gut aus, bis auf diese Auffälligkeiten:

- "V_spare_1" (Sollvorlauf nach Mischer): dieser Wert hat bei mir in 
beiden Heizkreisen einen offset von +5°C (Bsp.: Sollvorlauf am CW400 ist 
27°C ausgelsen werden 32°C). Kann dies irgendwie mit der Erhöhung des VL 
der Therme zusammen hängen? Dieser steht für beide Heizkreise auf 
+5°C...
- Bekommen wir irgendwo den Temperaturwert der hydraulischen Weiche her?

Mischerstellung, Pumpenstatus und Ist-Vorlauftemperatur passen soweit!
Ein riesen Dankeschön schonmal an dich Norbert!

Gruß

Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

Henrik H. schrieb:
> - Bekommen wir irgendwo den Temperaturwert der hydraulischen Weiche her?
So wie ich den Junkers-Unterlagen zum ZSB14-4 entnehmen kann, hat dieses 
Geräte keine internen Temperatur-Fühler. Alle Fühler sind extern am 
'Wärmetauscher' (T0) und in den Mischermodulen (TC1 & TC2). Die Werte 
werden vom Lastschalt-Modul MM200 erfasst und dem Regler CW400 bzw. 
System übergeben.
So kann ich dies (als Nichtfachmann) dem Anlagenbeispiel (siehe Bild) 
entnehmen.
Einen Temperaturfühler an der Hydraulischen Weiche sehe ich erst mal 
nicht.
Bitte vergleiche mal Deine Anlage mit dem beigefügten Anlagenbeispiel 
(klar, Solaranlage hast Du nicht, aber der Rest wird wohl so in etwa 
stimmen).

> dieser Wert hat bei mir in
> beiden Heizkreisen einen offset von +5°C (Bsp.: Sollvorlauf am CW400 ist
> 27°C ausgelsen werden 32°C)
Dies ist etwas komisch. Nicht der Offset an sich sondern, das die 
ausgelesenen Werte=32°C um 5°C GRÖSSER sind.
Wenn diese Werte von den Temperaturfühlern TC1 & TC2 in den 
Mischermodulen gemessen werden, so sollte der Wert wohl KLEINER sein, da 
die Temperaturfühler HINTER dem Mischer und der Heizkreispumpe eingebaut 
sind. Der Vorlauf-Istwert (T0 direkt am Heizgerät im 
Wärmetauscher/Trennsystem) muss ja wohl eine höhere Temperatur haben als 
die im/hinter dem Mischer.
Der Offset an sich ist ja wohl nötig, damit die Mischer nicht immer auf 
die 100% Position (voll offen) laufen und die Leitungs-Verluste zu den 
Heizkreisen berücksichtig sind.

Gruß Norbert

[Henrik H. (henrik_h271)]

Hallo Norbert,

Norbert S. schrieb:
> Bitte vergleiche mal Deine Anlage mit dem beigefügten Anlagenbeispiel
> (klar, Solaranlage hast Du nicht, aber der Rest wird wohl so in etwa
> stimmen).

Grundsätzlich passt der Aufbau so, allerdings komplett ohne Solar und 
Pufferspeicher für den Kamin, den hat der Heizungsbauer selbst mit einer 
Rücklaufanhebung an die Junkers angebunden. Diese kennt also den 
Pufferspeicher gar nicht, sonder soll über den Temperaturfühler an der 
Weiche mitbekommen, dass Wasser vom Pufferspeicher gespeist wird. Den 
externen Brauchwasserspeicher können wir wohl vernachlässigen ;-)

Norbert S. schrieb:
> Einen Temperaturfühler an der Hydraulischen Weiche sehe ich erst mal
> nicht.

Im Diagnosemenü vom CW400 habe ich die Vorlauftemperatur vom Kessel und 
einmal von der hydraulischen Weiche (siehe Bild). Der Fühler an der 
Weiche ist am MM200 am Anschluss T0 angeschlossen. Somit muss der Kessel 
ja auch einen internen Fühler haben.

Norbert S. schrieb:
> Dies ist etwas komisch. Nicht der Offset an sich sondern, das die
> ausgelesenen Werte=32°C um 5°C GRÖSSER sind.
> Wenn diese Werte von den Temperaturfühlern TC1 & TC2 in den
> Mischermodulen gemessen werden, so sollte der Wert wohl KLEINER sein, da
> die Temperaturfühler HINTER dem Mischer und der Heizkreispumpe eingebaut
> sind.

Da haben wir glaube ich etwas aneinander vorbei gesprochen. Es geht um 
den Vorlauftemperatur-Sollwert der Heizkreise. Dieser ist laut CW400 für 
meinen HK1 auf dem Bild bei 28°C (Fussbodenheizung), laut Screenshot 
wird aber 33°C ausgelesen (Differenz 5°C). Die Temepratur anhebung von 
5°C gilt ja logischerweise für die Vorlauftemperatur vom Kessel und 
nicht für die vom Heizkreis, somit haben die beiden Temperaturen nichts 
miteinander zu tun.

Vielleicht kannst du ja nocheinmal schauen :-)

Ich wünsche dir und deiner Familie ein schönes Fest und bedanke mich 
schon einmal für deinen tollen Support!

Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

ich habe noch einmal die Telegramme kontrolliert und jetzt wohl die 
richtigen Werte für die T-Soll (Vorlauf) der Heizkreise eingebracht.
Der Wert und das Telegramm hängen stark davon ab, ob ein Lastschaltmodul 
(IPM/MM) im System ist oder eben nicht.
Ebenso ist jetzt die gemessene Temperatur der hydraulischen Weiche mit 
in der rrdtool-Grafik enthalten (siehe Bild).
Wenn keine hydraulische Weiche im System ist, so wird dies in der Grafik 
als 'nicht vorhanden' dargestellt. Bei Deinem System sollte da aber der 
richtige Temperatur-Wert dargestellt werden.

Die Testsoftware liegt als komplettes Paket nach dem Auspacken unter 
~/tmp/.
Die vorhandene Datenbank kannst Du weiterhin verwenden, es wird für die 
hyrdaulische Weichen-Temperatur der Logitem-Name: 'V_spare_2' des 
Heizgerätes verwendet.
Die HT3_Analyser.py / HT3_SystemStatus.py zeigen den Display-Wert 
'T-Hydr.Weiche' an, wenn eine Weiche vorhanden ist.

Bitte vergleiche die Werte mit den Anlage-Daten. Die sollten jetzt mit 
den CW400 Anzeigen übereinstimmen.

Hinweis: Der T-Soll (Vorlauf) Name für die Heizkreise im Konfigfile hat 
sich geändert von:
<accessname>hcx_Tflow_measured</accessname>
auf
<accessname>hcx_Tflow_desired</accessname>

Gruß Norbert

[Michael W. (wemi2019)]

Hallo,
ich bin neu im Forum und würde mich freuen, wenn ich von Euch Hilfe 
bekommen würde. Nachdem im letzten Urlaub meine Junkers Gastherme 
ausgefallen ist, und ich es erst Tage später an der Raumtemperatur, die 
ich über HomeMatic Heizkörper-Thermostate überwache, gemerkt habe, habe 
ich mal im Internet gesucht, wie ich meine Heizung überwachen kann. 
Dabei bin ich auf diesen äußerst interessanten Beitrag gestoßen und habe 
gleich beschlossen, den HT3 MiniAdapter nachzubauen und die Heizung mit 
einem Raspberry Pi 3B zu überwachen. Habe gleich alle notwendigen Teile 
bei Conrad bestellt und alles zusammengebaut und lt. sehr guter 
Anleitung durchgemessen und in Betrieb genommen.
Ich muss dazu sagen, dass ich kein Elektroniker bin und mit Linux bisher 
auch fast keine Erfahrungen habe.

Jetzt habe ich folgendes Problem:
- der HT3 MiniAdapter ist direkt an die FW100 angeschlossen. Die grüne 
LED leuchtet bzw. blinkt sehr schnell, eher ein Flackern
- Die Software und Datenbank SQLite ist auf dem Raspberry 3 lt. 
Anleitung installiert. Es scheinen aber keine Daten anzukommen.
- Ich habe mal testweise das Programm HT3_CSW_analyser.py gestartet, 
aber auch dort kommen keine Daten an.

Ich weiß jetzt nicht, ob ich ein Hardware- oder Software-Problem habe. 
Wie kann ich ermitteln, ob von dem MiniAdapter überhaupt Daten kommen?
Kann mir jemand helfen und sagen, wie ich dem Problem auf die Spur 
kommen kann?

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,
Michael W. schrieb:
> Die grüne LED leuchtet bzw. blinkt sehr schnell, eher ein Flackern
Adapter OK und mit richtiger Polarität am Heizungs-Bus verbunden.
> und lt. sehr guter Anleitung durchgemessen und in Betrieb genommen.
Spricht für den Adapter, wird dann in Ordnung sein.

> Es scheinen aber keine Daten anzukommen.
Da Du einen Raspberry Pi 3B benutzt, solltest Du die Einstellungen der 
seriellen Schnittstelle kontrollieren. Default wird diese von Bluetooth 
benutzt.
Sie dazu Beitrag:
https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth

Bitte auch unbedingt auf die richtige Baudrate von 9600Baud achten (beim 
mini-Adapter).

Empfangs-Kontrolle mit einem Terminalprogramm möglich, z.B. minicom oder 
miniterm.py (Dazu natürlich die HT-Applikation beenden).

Wenn die Software korrekt installiert ist und der ht_proxy.server läuft 
kannst Du den Empfang der Daten auch mit einem Browser überprüfen mit:
 http://<IP des Raspi>:8088

Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
vielen Dank für die schnelle Unterstützung. Nachdem ich nach Anleitung 
die Einstellung der seriellen Schnittstelle geändert habe und Bluetooth 
deaktiviert habe, bekomme ich jetzt auch mit dem Programm 
HT3_CSW_analyser.py Daten, die auch richtig aussehen. Das ist schon mal 
super.
Leider werden immer noch keine Daten in die Datenbank geschrieben. Die 
Aktivierung des Startscripts ht3_logger mit dem Befehl # insserv 
ht3_logger hat zumindest keine Fehlermeldung gebracht. Doch nach dem 
Neustart müsste doch im Taskmanager ein entsprechender Process zu sehen 
sein, was aber nicht der Fall ist. Da bräuchte ich noch mal Deine Hilfe. 
Wie bereits gesagt, ich arbeite mich in Linux erst so langsam ein.

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,
Michael W. schrieb:
> Leider werden immer noch keine Daten in die Datenbank geschrieben. Die
> Aktivierung des Startscripts ht3_logger mit dem Befehl # insserv
> ht3_logger hat zumindest keine Fehlermeldung gebracht.
Der Daemon: ht3_logger ist veraltet und sollte deaktiviert werden.
Du verwendest offensichtlich ein altes Release.
Das letztgültige ist IMMER zu finden unter:
 https://github.com/norberts1/hometop_HT3
Installation der Applikation wie folgt:
1. Als User Pi einloggen
2. Software-Paket holen mit:
 git clone https://github.com/norberts1/hometop_HT3.git
3. Das von git angelegte Verzeichnis verschieben:
 mv ~/hometop_HT3/HT3 ~/HT3
4. Konfiguration für mini-/micro-Adapter anpassen (Baudrate auf 9600)
 Dies im Konfigurationfile ~/HT3/sw/etc/ht_proxy_cfg.xml machen (siehe 
Doku und Beschreibung im Konfigurationsfile).
5. Start-Scripte installieren (siehe Doku). !Startscript HT3_Logger 
deaktivieren!
6. Datenbanken anlegen mit
 ./create_databases.py
7. Reboot und Daumen drücken :-)
Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
habe mir die Version von https://github.com/norberts1/hometop_HT3.git 
geholt und nach Anleitung installiert.
Ich hatte ziemliche Probleme, die Datenbanken anzulegen. Das Python 
Script ließ sich bei mir nur aus der Python-Shell starten. Dabei kam es 
zu einer Fehlermeldung, dass die HT3_db.sqlite nicht angelegt werden 
konnte. Da ich in der XML-Datei geshen habe, dass bei vorhandener 
Datenbank, alle Tabellen gelöscht und wieder neu angelegt werden, habe 
ich die Datenbank von meiner ersten Installation einfach in das 
entsprechende Verzeichnis kopiert. Dann lief das Script ohne Probleme 
durch.
Leider existiert das gleiche Problem wie vorher. Die Startscripts 
ht_collgate und ht_proxy werden scheinbar nach dem reboot nicht 
ausgeführt.
Kannst Du mir noch mal helfen?

Gruß Michael

[Michael W. (wemi2019)]

Hallo Norbert,
den ersten Fehler habe ich bereits selbst gefunden. Die Datenbank 
HT3_db.sqlite wurde nicht richtig erzeugt, weil in dem XML-Script 
HT3_db_cfg.xml der Parameter <sql-db><enable> auf "off" gesetzt war. 
Nach der Änderung auf "on" wurden alle Datenbanken korrekt erzeugt.
Der ht_proxy und ht_collgate werden aber beim Startup des Systems 
scheinbar nicht gestartet. Um diesen Fehler zu beheben, fehlen mir im 
Moment noch die Linux Kenntnisse.
Wäre schön, wenn Du mir noch mal helfen könntest.

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,
Michael W. schrieb:
> den ersten Fehler habe ich bereits selbst gefunden. Die Datenbank
> HT3_db.sqlite wurde nicht richtig erzeugt, weil in dem XML-Script
> HT3_db_cfg.xml der Parameter <sql-db><enable> auf "off" gesetzt war.
Dies ist kein Fehler. Nur wenn die sql-Datebank und deren Schnittstelle 
benötigt wird, muss dies aktiviert sein. Default ist die deaktiviert um 
Resourcen zu sparen.
Für die grafischen Anzeigen ist nur die rrdtool-Datenbank nötig.

> Da ich in der XML-Datei geshen habe, dass bei vorhandener
> Datenbank, alle Tabellen gelöscht und wieder neu angelegt werden,...
Es werden keine vorhandenen Datenbanken gelöscht und Tabellen neu 
angelegt.

> ..., habe ich die Datenbank von meiner ersten Installation
> einfach in das entsprechende Verzeichnis kopiert.
Denkbar schlechteste Lösung, weil eine Datenbank aus irgendeinem 
Release-Stand ja nicht zu dem aktuellen Release passen wird.

> Die Startscripts ht_collgate und ht_proxy werden scheinbar nach dem
> reboot nicht ausgeführt.
Bitte die Logfiles unter ~/HT3/sw/log auf Fehlermeldungen kontrollieren.
Die Prozesse lassen sich auch von Hand in einem 'Terminal'-Fenster 
starten.
Dazu in das Verzeichnis ~/HT3/sw wechseln und aufrufen: 'ht_proxy.py' 
bzw. 'ht_collgate.py'. Fehlermeldungen sind dann sichtbar.

Mein Rat an Dich:
- löschen aller Datenbanken unter ~/HT3/sw/var/databases
- Kontrolle der Baudrate im Konfigurationsfile
- Terminalfenster öffnen
- cd ~/HT3/sw
- ./create_databases.py
Dies alles natürlich mit dem aktuellen Release wie oben unter den 
Punkten 1. bis 7. beschrieben.
Gruß Norbert

[Michael W. (wemi2019)]

Hallo Norbert,
ich bins schon wieder. Habe alle Deine Ratschläge befolgt und mir auch 
noch einmal in der Doku die verschiedenen Konfigurationsmöglichkeiten 
angesehen.

Ich benutze den HT3-miniAdapter und habe die Konfiguration für das 
ASYNC-Interface ausgewählt. Wenn ich das richtig sehe, darf ich dann den 
Proxy-Server (ht_proxy) nicht benutzen.

Die HT3_db_cfg.xml sieht dann im Bereich der Definition fürs 
Data_Interface wie folgt aus:
    <data_interface>
      <comm_type>ASYNC</comm_type>
      <proto_type>RAW</proto_type>
      <parameter name="ASYNC">
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>9600</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
    </data_interface>

Wenn ich nun ht_collgate.py manuel starte bekomme ich im Ccollcate.log 
folgende Fehlermeldung:

23.01.2019 17:57:56 INFO: Starting 'Ccollgate.run()
23.01.2019 17:57:56 CRITICAL: cht_if_worker();Error;could not get 
configuration-values
23.01.2019 17:57:57 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
23.01.2019 17:57:57 CRITICAL: ccollgate().run();Error; terminated

Was mache ich blos falsch?

Gruß Michael

[Michael W. (wemi2019)]

Hallo Norbert,
ich bin jetzt einen ganzen Schritt weiter gekommen. Die geschilderten 
Probleme sind jetzt behoben.

Ich habe bei der Installation einen großen Fehler gemacht, indem ich das 
ZIP-File von github auf dem PC unter Windows entpackt habe und dann die 
gesamte Verzeichnisstruktur mit WinSCP auf den Raspberry hochgeladen 
habe. Damit sind vermutlich die notwendigen Datei-Attribute verloren 
gegangen.
Ich habe die alte Installation gelöscht, die ZIP-Datei auf dem Raspberry 
entpackt und die gesamte Installation/Konfiguration neu gemacht. Nun 
läuft alles.

Es tut mir Leid, dass ich durch meine Dummheit Dir so viel Mühe gemacht 
habe. Vielen Dank noch einmal für Deine Geduld.

Das einzige was ich bisher nicht hinbekommen habe, ist eine 
Konfiguration ohne den Proxy-Server.
Die HT3_db_cfg.xml sieht dann im Bereich der Definition fürs 
Data_Interface wie folgt aus:
    <data_interface>
      <comm_type>ASYNC</comm_type>
      <proto_type>RAW</proto_type>
      <parameter name="ASYNC">
        <serialdevice>/dev/ttyAMA0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>9600</baudrate>
        <config>"8N1"</config>  <!-- only 8N1 available -->
      </parameter>
    </data_interface>

Wenn ich nun ht_collgate.py manuell starte bekomme ich im Ccollcate.log
folgende Fehlermeldung:

25.01.2019 15:57:43 INFO: Starting 'Ccollgate.run()
25.01.2019 15:57:43 CRITICAL: cht_if_worker();Error;couldn't open 
requested device:/dev/ttyAMA0
25.01.2019 15:57:43 CRITICAL: ccollgate().run();Error;could not start 
'ht-interface' with file:'./etc/config/HT3_db_cfg.xml'
25.01.2019 15:57:43 CRITICAL: ccollgate().run();Error; terminated

Hast Du da noch einen Tip für mich?

Gruß Michael

[Norbert S. (junky-zs)]

Hallo Michael,

Michael W. schrieb:
> Error;couldn't open requested device:/dev/ttyAMA0
Kann sein, das in Deinem RPi die alternative Schnittstelle: /dev/ttyS0 
zu verwenden ist. Must dann halt den Namen im Konfigfile entsprechend 
anpassen.
Kannst ja mit: ls /dev/ttyAM* bzw.: ls /dev/ttyS* nachsehen ob diese 
Schnittstellen vorhanden sind.

Achte auch darauf, das diese in der Gruppe:dialout sind.

Michael W. schrieb:
> Ich habe bei der Installation einen großen Fehler gemacht, indem ich das
> ZIP-File von github auf dem PC unter Windows entpackt habe...
Norbert S. schrieb:
> 2. Software-Paket holen mit:
>  git clone https://github.com/norberts1/hometop_HT3.git
Dies hätte Dir einiges an Arbeit erspart.

Gruß Norbert

[Chris15 (Gast)]

Hallo zusammen,

hat mittlerweile jemand den Code auf eine Arduino portiert?
Sprich das z.B. bei einem Arduino Mega über Serial1 der HT3-Bus 
ausgelesen wird und über Serial0 im Monitor der Wert für die aktuelle 
Vorlauftemperatur ausgegben wird?

Besten Dank.

Gruß
Chris

[Henrik (Gast)]

Moin Norbert,

habe die neue Software jetzt einige Zeit beobachtet. Soweit scheinen 
alle Werte zu stimmen und decken sich auch mit der Anzeige am CW400. 
Einzig der Temperaturwert für die weiche wird bei dir wesentlich 
schneller übertragen. Junkers schein nur jede Minute den Wert zu 
aktualisieren.
Bis hierher schon einmal ein riesiges DANKE an dich! Echt Top Arbeit.

Wie kann ich eigentlich Befehle über MQTT testen?

Wenn dir noch was einfällt was ich testen kann/soll dann bitte melden!

Gruß

Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,

> Wie kann ich eigentlich Befehle über MQTT testen?
Dies ist in der Doku im Kapitel: 2.3.2 'MQTT-Client' beschrieben.
Beispiel für einen Fxyz-Regler:
2.2 Setzen der Soll-Temperatur auf 21.5 Grad des Niveaus „heizen“ mit:
mosquitto_pub -d -h <host IP-Adr.> -t set/hometop/ht/hc1_Tdesired -m 
"21.5,heizen".

Im Konfigurationsfile: HT3_db_cfg.xml haben alle steuerbaren logitems 
einen zusätlichen Parameter:
 <set_param>Befehle f. Fxyz || Befehle f. Cxyz</set_param>

Wie diese Befehle zu nutzen sind ist im Modulkopf des Konfiguratiosfile: 
HT3_db_cfg.xml beschrieben.

Gruß Norbert

[Henrik (Gast)]

Moin Norbert,
ich habe jetzt längere Zeit versucht mit den Befehlen klar zu kommen. 
Via MQTT scheint nur nach jedem Neustart genau ein Befehl (allerdings 
nur HK1, siehe unten) durch zu kommen.

Mit dem ht_netclient kann ich immerhin den HK1 komplett steuern. Sobald 
ich allerdings den Parameter "-hc 2" anhänge, passiert auf diesem 
nichts, sondern der Befehl wird für den HK 1 ausgeführt.

Noch eine Frage im Rande: Wenn ich den HK 1 in den manuellen Modus mit 0 
°C setzte, geht der Betriebsstatus auf 0 --> also aus, der Mischer fährt 
auf 0% aber die Pumpe geht nicht aus... Müsste sie aber eigentlich oder?

Besteht außerdem die Möglichkeit die gedämpfte Außentemperatur 
auszulesen?

Gruß
Henrik

[Norbert S. (junky-zs)]

Hallo Henrik,
Henrik schrieb:
> habe jetzt längere Zeit versucht mit den Befehlen klar zu kommen.
> Via MQTT scheint nur nach jedem Neustart genau ein Befehl (allerdings
> nur HK1, siehe unten) durch zu kommen.
Ich nehme mal an Du hast für den Heizkreis 2 auch den richtigen Befehl 
gewählt mit 'hc2_...' ?

Zur Kontrolle kannst Du im ht_proxy den Debug-Mode aktivieren:
Zeile im Pyhton-Script: ht_proxy.py aktiveren, darunter die deaktiveren:
 ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile, 
loglevel=logging.DEBUG)
 # ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile)
und den ht_proxy.py und danach ht_collgate.py neu starten mit
sudo /etc/init.d/ht_proxy stop
sudo /etc/init.d/ht_proxy start
sudo /etc/init.d/ht_collgate stop
sudo /etc/init.d/ht_collgate start

Die Debug-Ausgaben werden dann in das Log-Verzeichnis geschrieben unter 
~/HT3/sw/var/log/ht_proxy.log
Die Kommandos zum ht_pitiny sind darin enthalten. Du kannst diese ja zur 
Kontrolle hier posten.

> Mit dem ht_netclient kann ich immerhin den HK1 komplett steuern. Sobald
> ich allerdings den Parameter "-hc 2" anhänge, passiert auf diesem
> nichts, sondern der Befehl wird für den HK 1 ausgeführt.
Beispiel mit ht_netclient für Heizkreis 2:
ht_netclient.py -tc2 21.5 -hc 2
(Einstellung Temperatur-Niveau:Comfort2 auf 21.5 Grad und Heizkreis: 2)

Änderungen dieser Werte werden bei den Cxyz-Reglern leider nicht sofort 
mit einem Telegramm quittiert, es kann durchaus mehr als eine Minuten 
dauern bis ein Wechsel des Parameters mitgeteilt wird (Kontrolle mit 
HT3_Analyser möglich).
Es hängt auch davon ab ob im 'auto'-mode gerade 'Comfort1' oder 'Eco' 
oder ... durch Programm aktiviert ist und dann für 'Comfort2' der Wert 
ändert wird.
Die Änderung wird auch dann nur für 'Comfort2' gemacht und nur dann 
angezeigt wenn 'Comfort2' aktiv ist.
Die Abhängigkeiten sind derer viele und mit den Cxyz-Reglern leider noch 
mehr geworden.

> Wenn ich den HK 1 in den manuellen Modus mit 0
> °C setzte, geht der Betriebsstatus auf 0 --> also aus, der Mischer fährt
> auf 0% aber die Pumpe geht nicht aus... Müsste sie aber eigentlich oder
Die HK-Pumpen haben eine Nachlaufzeit, die im Regler einstellbar ist.

> Besteht außerdem die Möglichkeit die gedämpfte Außentemperatur
> auszulesen?
Habe ich in den Telegrammen bisher nicht gefunden.

Gruß Norbert

[Henrik (Gast)]

Hi Norbert,
ich habe mir mal die Mühe gemacht und das Gesamtsystem neu aufgesetzt 
(also mit aktuellem Stand vom Git). MQTT liefert soweit jetzt alle 
Werte, soweit ist alles wieder wie vorher.

Norbert S. schrieb:
> Ich nehme mal an Du hast für den Heizkreis 2 auch den richtigen Befehl
> gewählt mit 'hc2_...' ?
Den korrekten MQTT-Befehl habe ich gewählt, allerdings funktioniert das 
ja schon nicht mit dem ht_netclient...

Norbert S. schrieb:
> Zur Kontrolle kannst Du im ht_proxy den Debug-Mode aktivieren:
Sobald ich den Debugmode aktiviere, kann ich keine Befehle mehr mit dem 
ht_netclient absetzten.

./ht_netclient.py -tc2 22.0 -hc 2
Is controller-type any of CTxyz/CRxyz/CWxyz y/n ?y
couldn't connect to server
Traceback (most recent call last):
  File "./ht_netclient.py", line 239, in <module>
    main(configfile, ems_bus)
  File "./ht_netclient.py", line 106, in main
    client= ht_proxy_if.cht_socket_client(configfile, devicetype = ht_proxy_if.DT_MODEM)
  File "lib/ht_proxy_if.py", line 857, in __init__
    self._socket.connect((self._ip_address, self._port_number))
ConnectionRefusedError: [Errno 111] Connection refused

Im ht_proxy.log:

26.03.2019 09:04:35 INFO: Client-ID:2; ('127.0.0.1', 39742) connected
26.03.2019 09:04:35 INFO: Server   :('0.0.0.0', 8088)
26.03.2019 09:04:35 INFO: Client-ID:2; register(); got devicetype:MODEM
26.03.2019 09:04:35 INFO: csocketsendThread(); socket.send thread start
26.03.2019 09:04:35 INFO: Client-ID:2; added; number of clients:2
26.03.2019 09:04:35 INFO: Client-ID:2; cht_RequestHandler(); socket.receive thread start
26.03.2019 09:04:35 INFO: Client-ID:1;cportwrite();couldn't read from queue
26.03.2019 09:04:45 INFO: Client-ID:2; ('127.0.0.1', 39742) disconnected
26.03.2019 09:04:45 INFO: Client-ID:2; removed; number of clients:1
26.03.2019 09:04:45 CRITICAL: csocketsendThread();Error on socket.send
26.03.2019 09:04:45 INFO: Client-ID:1;cportwrite();couldn't read from queue

Norbert S. schrieb:
> ht_netclient.py -tc2 21.5 -hc 2

Der Befehl ändert die Temperatur im HK1, egal welchen hc Parameter ich 
übergebe.....


Bin zur Zeit erstmal ratlos......

Gruß
Henrik

[Christoph (Gast)]

Moin Moin,

funktioniert das ganze auch mit Lüftungsanlagen von Junkers/Bosch?
Laut Handbuch haben die ja auch einen Bus.

Hier mal die Installationsanleitung meiner Bosch Vent 5000C:

https://www.bosch-thermotechnology.com/ocsmedia/optimized/full/o222405v52_6720811375.pdf

An den Bus kann Zubehör (z.B. MB-LAN) angeschlossen werden - dann müsste 
das doch klappen, oder?

Grüße,

Christoph

[Grunzrakete (Gast)]

Moin,

bei mir hängt seit einigen Tagen eine Junkers ZWR 18-7 KE 23..blubb mit 
CR100 rum. Hatte mich schon gefreut, die mit eurer tollen bisher 
geleisteten Arbeit leicht anbinden zu können. Zumal in der 
Installationsanleitung

Leider scheint sich bei Junkers etwas getan zu haben: Man scheint sich 
innerhalb von Bosch Thermotechnik auf EMS geeinigt zu haben. In der 
Installationsanleitung des CR100 
(https://www.waerme24.de/media/dokumente/Bosch_Regelungen_Installationsanleitung_CR100_CW100.pdf) 
steht jedenfalls überall EMS 2 drin. Auf dem Gerät steht auch nicht 
Junkers sondern einfach nur Bosch. Eine kurze Google-Suche ergab, dass 
das Ding auch bei Buderus eingesetzt wird. Logisch man will langsam mal 
weg davon alles doppelt zu produzieren.

Mit den Teilen die ich herumliegen hatte hab ich sowas wie den 
HT3-Microadapter gebaut und mit dem Oszi verifiziert, dass ich 
tatsächlich das was auf dem Bus zu sehen ist auch herausbekomme.

Mit dem Zeug was da herauskommt kann jedoch Norberts Software nichts 
anfangen und es sieht mir auch nicht wirklich nach EMS aus (Doku gibt es 
ja in nem Wiki). Hat irgendwer schon mal bei richtig neuen 
Junkers-Anlage Versuche unternommen?

Besten Dank und Gruß,
Grunz

[Norbert S. (junky-zs)]

Hallo,
Grunzrakete schrieb:
> Leider scheint sich bei Junkers etwas getan zu haben: Man scheint sich
> innerhalb von Bosch Thermotechnik auf EMS geeinigt zu haben. In der
> Installationsanleitung des CR100 steht jedenfalls überall EMS 2 drin.
Stimmt, EMS2 ist aber ebenfalls ein 2-Draht-Bus so wie HT3 bzw. HT4i 
(Junkers).
Habe selber den alten FW100-Regler durch zuerst einen CW100- und jetzt 
einen CW400-Regler (beide EMS2) ersetzt. Dieser läuft sehr gut an meinem 
Heizgerät mit dem HT3-Bus.
Auf diesem Regler steht ebenfalls Bosch drauf (ist seit 2017 so) und ist 
als EMS2 Bus gekennzeichnet, jedoch ist Junkers drin.
Wichtig ist die 10stellige Artikelnummer, die muss passen.
Leider kennzeichnet Buderus ebenfalls den Bus als 'EMS-Bus', trotzdem 
laufen die Buderus-Regler nicht mit einem Junkers-Gerät.
Dies liegt dann weniger am Bus (2-Draht sind die beide) sonder an den 
Telegrammen die darüber laufen. Die sind leider zwischen Buderus/Bosch 
und Junkers/Bosch unterschiedlich.
Du hast aber ein Junker-Heizgerät und daher sollten die Telegramme 
Deines CR100 Reglers/ der Heizung dekodiert werden.

Habe Logfiles von z.B. Junkers 9000i Geräten und die Telegramme werden 
ebenfalls dekodiert.

Welche Software-Version setzt Du ein?

Vielleicht kannst Du ein Logfile erstellen und hier ins Forum posten.

Gruß Norbert

[Grunzrakete (Gast)]

Hallo Norbert,
danke für deine rasche Antwort.

Neueste Softwareversion von github.

Im Anhang gibt es eine log-Datei.

Besten Dank

Grunz.

[Norbert S. (junky-zs)]

Grunzrakete schrieb:
> Im Anhang gibt es eine log-Datei
Die Daten im Logfile enthalten keine Junkers Heizungs-Telegramme.

Dies kann zwei Gründe haben:
1. Baudrate in der Konfiguratin des Adapters
2. Hardware des Adapters

Bitte kontrolliere die Baudrate, die in der Konfiguration einzugeben 
ist.
Für den Micro-Adapter ist 9600 Baud erforderlich. Siehe Details in der 
Doku.

Grunzrakete schrieb:
> Mit den Teilen die ich herumliegen hatte hab ich sowas wie den
> HT3-Microadapter gebaut und mit dem Oszi verifiziert.
Bitte die seriellen Signale kontrollieren. Ein serielles Byte fängt mit 
einer fallenden Flanke an und hört mit einer steigenden Flanke auf. Dies 
gemessen direkt am RX-Eingang des UART-USB-Wandlers.

Gruß Norbert

[Grunzrakete (Gast)]

Hallo Norbert,

ich hatte mir die Signale nur mit einem analogen Oszi angesehen. Hab 
jetzt nochmal mit einem digitalen geguckt und siehe da mein 
Ausgangssignal sah nicht so gut aus.. :-) Basiswiderstand in der 
Inverterstufe war um eine Größenordnung zu groß. Da hab ich wohl zu 
später Stunde ins falsche SMD-Kistchen gegriffen.

Nun läuft es und deine Software scheint auch das Meiste zu verstehen. Es 
gibt allerdings eine Menge Telegramme mit ??? davor.

Hab das Ganze übrigens mit Optokoppler 6n139 und einem dahinter in die 
Sättigung getriebenen PNP Transistor gebaut. Zenerdioden zu 9,1V und 
3,3V in Reihe mit Vorwiderstand und Schottkydiode davor und feddich. Was 
halt gerade da war :-)

Besten Dank für die tolle Software Norbert!

Gruß/Grunz

[Frank R. (frenpi)]

Ursachenforschung: Datenaufzeichnung lückenhaft (siehe Bilder).

HT3 läuft seit ein paar Wochen prima (Danke, Norbert). Seit 4 Tagen gibt 
es kuriose Aufzeichnungslücken. In der zwei-Tagesdarstellung wurde 
nichts mehr angezeigt, obwohl die Daten korrekt mit dem HT3_Systemstatus 
angezeigt werden. Die Daten werden auch immer noch korrekt zum ioBroker 
über mqtt gepublished.

Ich habe dann in rrdtool_draw.pl mal my $start_time = time()-20160*60 
gesetzt (20160 sind 14 Tage, 14x60x2).

Siehe da, Vor 4 Tagen war noch alles ok - dann wurden die Daten 
anscheinend "ausgedünnt".

Dazu fällt mir nur ein ein Performance-Problem ein. Warum sollten die 
Daten plötzlich nur noch teilweise aufgezeichnet werden.
Ist ein Raspi 1 Modell A - die SQLilte DB ist ca. 120 MB groß, 
Datenbanken liegen auf USB-Stick. Außer HT3 läuft nix.
Top liefert load average um 5,25, 5,29, 5,13...

Oder gibt es eine andere Idee?

Beste Grüße, Frank

[Stefan B. (sbiermann)]

Hallo Frank,
die Auslastung ist viel zu hoch, der läuft mit 500% Auslastung. Mein Pi 
mit der HT3 Software und noch ein GlusterFS Server als docker Container 
ist bei 60-70% Auslastung. Du solltest mit "top" schauen was da die 
Auslastung verursacht.

Viele Grüße
Stefan

[Frank R. (frenpi)]

Danke für die Rückmeldung - TOP in der Anlage zeigt zwar, dass er schon 
ziemlich beschäftigt ist, aber dass 50% davon von ht_collgate, ht_proxy 
und ubs-storage kommen. Muss ich wohl doch auf den anderen Raspi 
umziehen, den ich hier noch habe.
Die Werte sind aber ziemlich konstant.

Wundert mich allerdings, dass das sich das erst seit 5 Tagen zeigt. Ich 
dachte, das könnte auch an der gewachsenen Sqlite Datenbank liegen, aber 
abschatten in der Config hat nichts genützt.

Ein erneuters Sichten von Ccollgate.log zeigt allerdings, dass seit dem 
Zeitpunkt der teilweisen Aufzeichnung das erste Mal Autoerasing 
Activitities von sqlite eingetragten wurden. Kann das damit 
zusammenhängen? (Anlage)

[Frank R. (frenpi)]

Das Abschalten von Sqlite hat doch geholfen. Auslastung ist jetzt immer 
noch zwischen 1,6-1,9 aber Aufzeichnung geht wieder.

[F. S. (f_s352)]

Hi Leute,

hat noch einer eine Platine für den Raspi übrig oder benötigt diese 
nicht mehr? Für eine PN wäre ich sehr dankbar.  Viele Grüße

[F. S. (f_s352)]

Hallo,

vorab ein Dank an Norbert, dass ich noch einen HT_pitiny bekommen habe!
Ich bin kein Experte und habe lange gekämpft bis ich den Adapter auf 
einem Raspberry 4 zum Laufen gebracht habe.

Ich möchte meinen Notizen aber teilen, vielleicht hilft es ja dem einen 
oder anderen Newbie...

AUSGANGSSITUATION

Adapter: HT_pitiny
Rechner: Raspberry 4
Image: Raspbian Buster Lite
HT Manual: Rev. 0.3

KOMMENTARE ZUR INSTALLATIONSANLEITUNG

Notiz in eigener Sache:
Möchte man den SSH Zugriff auf dem Raspberry aktivieren, so ist mit 
Windows eine Datei mit der Bezeichnung SSH in die Bootpartition zu 
legen.

3.1 Installation Betriebssystem

Debian-Buster ist der Nachfolger von Debian-Jessie
Deaktivieren der default eingeschalteten TTY-Systemausgaben ist bei 
Debian-Buster auch nicht notwendig
Anpassen der /etc/inittab ist bei Debian Buster ebenfalls nicht 
notwendig.
Deaktivieren von Bluetooth ist beim Raspberry 4 nicht notwendig.
Mann muss aber beim Raspberry 4 die serielle Konsole wie folgt 
deaktivieren:
sudo raspi-config -> 5 Interfacing Options > P6 Serial > Login 
accessible over serial > No > serial port enable > Yes

3.2 Applikationen

Der Befehl git muss zuerst noch installiert werden:
$ sudo apt-get install git
Der HT3_logger sollte nicht mehr verwendet werden, der ht_collgate 
ersetzt den HT3_logger.
Zum Aktivieren der Startskripte funktioniert beim Raspberry 4 der Befehl 
insserv nicht mehr.
Folgende Befehle sind statt sudo insserv zu verwenden:
$ sudo chmod +x /etc/init.d/daemonXY
$ sudo systemctl enable daemonXY
Es sollte ht_proxy verwendet werden (SOCKET, kein ASYNC!)
Beim Raspberry 4 liegt der HT_pitiny auf /dev/serial0 (dies ist 2x im 
ht_proxy_cfg.xml zu ändern)

DEBUGGING:

Befehl zur Prüfung der aktiven HT Prozesse:
$ ps ax | grep HT (es sollte httpd, proxy und collgate laufen)

Möchte man die Applikationen HT3_Analyser oder HT3_Systemstatus über SSH 
verwenden, ist folgendes zu tun:
Installation von PUTTY und Xming auf dem Windows Rechner
In Putty unter Connection > SSH > X11 > Enable X11 forwarding aktivieren 
und x display location auf ":0.0" setzen.
Die Session in Putty mit SAVE abspeichern.
Im Terminal prüfen, ob "echo $DISPLAY" den Wert localhost:10.0 ausgibt.
Nun öffnet sich beim Aufruf von $ ./HT3_Systemstatus.py oder $ 
./HT3_Analyser eine schöne Applikation.


Viel Spaß beim "Kämpfen" :-)

[gezuppe (Gast)]

Hi Zusammen,
bei meinem RasPi A hat sich leider die SD Karte verabschiedet und so 
habe ich nun einen RasPi 3 mit Stretch aufgesetzt aber leider bekomme 
ich das Ganze nicht mehr zum Laufen.
Auf dem RasPi habe ich eine HTmini, dass Pinout sollte ja gleich 
geblieben sein.
Beim Start des HT_collgate bekomme ich folgende Meldung:
CRITICAL: cht_if_worker();Error;couldn't open requested 
device:/dev/serial0

- Ich habe auch ttyAMA0 probiert.
- pi user ist in der Dialout Gruppe
- BT ist aus

Hat noch Jemand eine Idee? ICh habe mich dur viele Foren/Bugs gewühlt 
finde aber keine Lösung...

Grüße Sebastian

[Norbert S. (junky-zs)]

Hallo Sebastian,

gezuppe schrieb:
> Auf dem RasPi habe ich eine HTmini, dass Pinout sollte ja gleich
> geblieben sein.
Ist gleich geblieben.

gezuppe schrieb:
> Beim Start des HT_collgate bekomme ich folgende Meldung:
> CRITICAL: cht_if_worker();Error;couldn't open requested
Dies liegt an der nicht mehr unterstützen Funktion:
 self.__port.setInterCharTimeout()
für die serielle Schnittstelle.
Da diese Funktion nicht mehr benötigt wird kann sie deaktiviert oder 
gelöscht werden.
Manuell in folgenden Modulen/Zeilen:
 lib/Ccollgate.py / 487
 lib/ht3_worker.py / 175
 lib/ht_proxy_if.py 281 (war dort schon deaktiviert)

oder komplettes Release: 0.3.2 mit
 git clone https://github.com/norberts1/hometop_HT3.git

Gruß Norbert

[Rene R. (rene3388)]

Anbei noch die Logs und Configfiles!


Sehr geehrte Forenteilnehmer!
Lieber Norbert!

Ich habe den "Raspi_HT3MiniAdapter" nachgebaut, durchgemessen/ 
durchgetestet und nun (via ISM1)am HT3-Bus angebunden.

Therme: Junkers CerapurModul-Solar ZBS14210S3, 1xISM1, 1xFW100;
RPi: Model B+ V1.2, Raspian-Buster

Status:
Am HT3MiniAdapter leuchtet D4 durchgehend, D3 flackert leicht.

Fehler: Es kommen keine Daten am RPi an, bzw. wird nichts in die 
SQL/RRDtool Datenbanken geschrieben.

Ich vermute, dass es an der RPi-Konfiguration liegt, da ich bedingt 
durch Raspian-Buster ein paar Installationspunkte anders machen musste 
(siehe Anhang).
Habt ihr eine Idee woran es liegen könnte?

Vielen Dank und Grüße!
Rene

[Michael W. (wemi2019)]

Hallo Rene,
bei mir läuft der Raspi_HT3MiniAdapter auch unter Raspbian-Buster seit 
einem Jahr problemlos. Ich kann mich dunkel erinnern, dass ich am Anfang 
Probleme hatte, das ganze ohne ht_proxy ans laufen zu bekommen. Bei mir 
läuft seitdem der Proxy-Server. Hat auch den Vorteil, dass man die Tools 
HT3-Analyser und HT3_systemstatus parallel benutzen kann.
Ich würde es mal mit ht_proxy versuchen.
Viel Glück
Michael

[Norbert S. (junky-zs)]

Hallo Rene,

Deine Installation sieht soweit gut aus.
Du benutzt zwar nicht den ht_proxy.server sondern nimmst direkt den 
ht_collgate.py daemon.
Somit wird Dein mini-Adapter direkt mit 9600 Baud vom ht_collgate 
bedient und so kann man das System u.A. auch betreiben.
Zusammen mit dem ht_proxy.server ist es ein wenig komfortabler aber 
nicht zwingend nötig wenn man die anderen Tools (HT3_Analyser usw.) 
nicht benötigt.

Dies ist aber auch wohl nicht die Ursache. Ich habe vielmehr die 
Befürchtung das die serielle Schnittstelle unter /dev/tty.... gar nicht 
mehr vorhanden ist. Schau bitte mal nach ob unter /dev/tty* irgendeine 
serielle Schnittstelle vorhanden ist wie:
 ll /dev/ttyAMA*
oder
 ll /dev/serial*

Wenn diese nicht vorhanden ist, dann war wohl Deine Aktion:
 $ sudo systemctl stop [e-mail]
 $ sudo systemctl disable [e-mail]
zuviel des Guten.
Jedenfalls habe ich dies nicht auf meinem RPiB+ ausgeführt.

Auch sieht mein Eintrag in der /boot/cmdline.txt wie folgt aus:
 console=tty1 root=/dev/mmxytzer rootfstype=ext4 elevator=deadline
 fsck.repair=yes rootwait

Falls /dev/ttyAMA0 vorhanden ist dann bitte folgenden Befehl ausführen 
und Ausgabe kontrollieren:
stty -F /dev/ttyAMA0
 speed 9600 baud; line = 0;
 min = 0; time = 0;
 -brkint -icrnl -imaxbel
 -opost -onlcr
 -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Gruß Norbert

[Rene R. (rene3388)]

Hallo Michael!

Vielen Dank, für den Input!
Ich hatte diese Konfiguration gewählt, weil sie mir einfacher erschien 
und werde zuerst noch versuchen, den Fehler in dieser zu finden/lösen.

Wenn dies nicht gelingt, werde ich es mit deinem Vorschlag probieren.

lg
Rene

[Rene R. (rene3388)]

Hallo Norbert!


Folgende Informationen hätte ich,


Eingabe:
ls /dev/tty*

Ausgabe:
/dev/tty    /dev/tty12  /dev/tty17  /dev/tty21  /dev/tty26  /dev/tty30 
/dev/tty35  /dev/tty4   /dev/tty44  /dev/tty49  /dev/tty53  /dev/tty58 
/dev/tty62  /dev/ttyAMA0
/dev/tty0   /dev/tty13  /dev/tty18  /dev/tty22  /dev/tty27  /dev/tty31 
/dev/tty36  /dev/tty40  /dev/tty45  /dev/tty5   /dev/tty54  /dev/tty59 
/dev/tty63  /dev/ttyprintk
/dev/tty1   /dev/tty14  /dev/tty19  /dev/tty23  /dev/tty28  /dev/tty32 
/dev/tty37  /dev/tty41  /dev/tty46  /dev/tty50  /dev/tty55  /dev/tty6 
/dev/tty7
/dev/tty10  /dev/tty15  /dev/tty2   /dev/tty24  /dev/tty29  /dev/tty33 
/dev/tty38  /dev/tty42  /dev/tty47  /dev/tty51  /dev/tty56  /dev/tty60 
/dev/tty8
/dev/tty11  /dev/tty16  /dev/tty20  /dev/tty25  /dev/tty3   /dev/tty34 
/dev/tty39  /dev/tty43  /dev/tty48  /dev/tty52  /dev/tty57  /dev/tty61 
/dev/tty9

=====================================

Eingabe:
stty -F /dev/ttyAMA0

Ausgabe:
speed 9600 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

=====================================

Sieht soweit OK aus oder?

lg
Rene

[Ingo W. (uebrig)]

Hatte in einer ähnlichen Anwendung auch Probleme mit dem RasPi UART.
Hier hat mir 
https://buyzero.de/blogs/news/praktische-kommunikation-per-uart-und-rs485-am-raspberry-pi 
geholfen. Ich zitiere mal:

Standardmäßig ist außerdem eine Linux Console über den "Haupt-UART" des 
Systems vorgesehen. Diese würde uns bei der Kommunikation stören, und 
muss daher abgeschaltet werden.

 Das funktioniert wie folgt:

sudo nano /boot/cdmline.txt

hier muss der Teil mit console=serial0,115200 gelöscht werden (kann 
ähnlich ausschauen).

Da wir den PL011 verwenden wollen, müssen wir bei Pi 3B / 3B+ / 3A+ & 
der Zero Reihe Bluetooth abschalten (optional gäbe es auch die 
Möglichkeit die zwei UARTs zu tauschen, da der miniUART aber u.a. an die 
Taktrate des VideoCores fixiert ist bringt das Nachteile und 
zusätzlichen Konfigurationsaufwand mit sich). Wir gehen wie folgt vor:

sudo nano /boot/config.txt

Hier wird folgende Zeile ganz am Ende eingefügt:

dtoverlay=pi3-disable-bt

Diese Zeile vertauscht in der Softwarekonfiguration die Pins, so dass 
wir jetzt über die uns zugänglichen Pins am Raspberry Pi (siehe Pinout 
oben) den PL011 UART nutzen können.

Außerdem ist es wichtig den Systemservice zu disablen, der mit Bluetooth 
kommuniziert (da er sonst weiter über die Pins kommunizieren versuchen 
würde):

sudo systemctl disable hciuart

Das sollte ausgeben: "Removed 
/etc/systemd/system/multi-user.target.wants/hciuart.service".

Jetzt ist es an der Zeit, den Pi neu zu starten:

sudo reboot

[Rene R. (rene3388)]

Hallo Ingo!

.)In meiner config.txt wurde "console=serial0,115200" bereits entfernt.
.)Bei meinem Raspi handelt es sich wie beschrieben um ein Model B+ V1.2.
(Daher kein integriertes BT)

lg
Philipp

[Daniel H. (Gast)]

Hallo zusammen,

ich würde meine Heizungsanlage auch gerne etwas "smarter" machen. Leider 
fehlt mir eine wenig das Geschick den HT_pitiny selbst zusammenzubauen.
Meine Frage wäre nun, ob jemand von euch noch einen HT_pitiny übrig hat 
und ihn mir verkaufen möchte ?

Vielen Dank und viele Grüße
Daniel

[Remo P. (remo66)]

Hallo allerseits,

ich bin seit kurzem auch Besitzer einer modernen Heizung von Bosch mit 
HT- Bus (Cerapur 9000i).
Als Informatiker habe ich auch schon einige Projekte mit dem Raspberry 
gemacht und auch ein paar im dauerhaften Betrieb.
Jetzt würde ich natürlich auch gern mit meiner Heizung kommunizieren und 
eventuell hier auch etwas beitragen.
Ich weiß es ist schon einige Male gefragt worden, aber auch ich hätte 
gern ein HT_pitiny Board.
Das Repository [[https://github.com/norberts1/hometop_ht_transceiver]] 
ist toll, aber die Herstellung/Bestückung für ein einzelnes Exemplar ist 
für mich doch ein recht großer Aufwand.
Könnt Ihr mir weiterhelfen?

Schöne Grüße!
Remo

[Norbert S. (junky-zs)]

Hallo Remo,
Remo P. schrieb:
> Ich weiß es ist schon einige Male gefragt worden, aber auch ich hätte
> gern ein HT_pitiny Board
Ich habe z.Zeit auch keine Boards.
Sende mir eine PM.
Wenn ausreichend Anfragen kommen kann ich noch ht_pitiny-Boards 
erstellen.
Gruß Norbert

[Rene R. (rene3388)]

Hallo Norbert!

Frage zur Bestückung des USB MicroAdapter's,
Den Mini-USB-UART-Umsetzer UM 2102 (91859) scheint es bei ELV nicht mehr 
zu geben.
Kann man stattdessen einen "CP2102 USB to TTL Serial Converter 5 PIN" 
(zum Beispiel: 
https://www.amazon.co.uk/Yizhet-Converter-Compatible-Arduino-Windows/dp/B07TFSZ3ZP)
verwenden?

Vielen Dank!
Philipp

[Norbert S. (junky-zs)]

Rene R. schrieb:
> Den Mini-USB-UART-Umsetzer UM 2102 (91859) scheint es bei ELV nicht mehr
> zu geben.150952
Es gibt eine neuere Version bei ELV (150952). Die ist wohl auch 
Pin-kompatibel zur Vorgängerversion und billiger als die von Amazon.
Es funktioniert aber jeder USB-UART Wandler wenn dieser eine Spannung 
liefert (3.3 oder 5 Volt) und logischerweise einen RX-Anschluß hat.
Allgemein gilt, die Schaltung ist sehr universell einsetzbar. Die kann 
auch an jedem MC mit UART angeschossen werden.

Gruß Norbert

[Remo P. (remo66)]

Hallo zusammen,

Dank Norbert habe ich nun auch eine funktionierende Anbindung an meine 
Heizung(Cerapur 9000i/CW400/1HK/kein Solar/RPi2/HT_pitiny).
Nach Konfiguration funktioniert jetzt auch alles soweit.
Nur gelingt es mir nicht den HTTP- Server auf dem RasPi anzusprechen.
Alle anderen Sachen (HT3_Analyser/HT3_Systemstatus.py etc.) 
funktionieren remote.
Kann mir vielleicht jemand mal die Konfiguration kurz mitteilen.
Die Doku habe ich eigentlich gelesen. ;-)
Den HTTPD- Daemon habe ich natürlich gestartet und die RRD- DB's werden 
auch gefüllt.
Vielleicht hapert es nur an der richtigen URL im Browser.

Schöne Grüße!
Remo

[Remo P. (remo66)]

Hat sich erledigt.

Durch eine kurzen Blick in "httpd.py" herausbekommen das es Port 8086 
ist.
Sorry für die Anfrage, aber ich habe doch eine ganze Weile gesucht.

Gruß Remo

[Andreas W. (urbansunited)]

Hi!

Ich bin bei meiner Suche nach Einbindung der Junkers Heizung in Home 
Assistant auf das Projekt EMS-ESP
https://github.com/proddy/EMS-ESP
gestoßen.
Meine Fragen:
Kann der ht_pitiny adapter damit irgendwie verbunden werden?
Oder kann sonnstwie die Systeme verbinden und dann per HA die Heizung 
steuern und auslesen?
Auslesen ist nicht das Problem, dafür läuft ja MQTT, aber das direkte 
Steuern?
Oder brauche ich ein neues Board dafür?
Oder hat jemand schon etwas in HA gebaut?

Beim EMS-ESP hab ich schon nachgefragt

https://github.com/proddy/EMS-ESP/issues/456#issuecomment-674030617

Danke und besten Gruß

Andi

[Norbert S. (junky-zs)]

Hallo Andreas,
Andreas W. schrieb:
> Auslesen ist nicht das Problem, dafür läuft ja MQTT, aber das direkte
> Steuern?
> Oder brauche ich ein neues Board dafür?
Nein, Du brauchst nur den ht_pitiny- oder den ht_piduino-Adapter um die 
Heizung auch mit MQTT-Kommonados zu steuern.
Siehe dazu auch meine Doku und obige Test-Beispiele.

Andreas W. schrieb:
> Kann der ht_pitiny adapter damit irgendwie verbunden werden?
ht_pitiny-Adapter (deviceID:0x0D) und EMS-ESP (deviceID:0x0B) können 
parallel am gleichen Heizungsbus (Heatronic oder EMS) angeschlossen 
werden. Da unterschiedliche Device-Adressen verwendet werden kollidieren 
die Telegramme und Kommandos nicht.

Andreas W. schrieb:
> Oder hat jemand schon etwas in HA gebaut?
Ein 'Home Assistant' (HA) Binding habe ich noch nicht im Projekt, aber 
vielleicht hat jemand hier im Forum dies schon für MQTT und RX/TX 
realisiert?

Gruß Norbert

[Bert (Gast)]

Hi Andreas, Norbert,

Ich habe von Norbert einige Jahre züruck auch ein ht_pitiny gekauft.
Aber noch nicht verbunden mit mein Junkers Brenner. Kein Zeit gehat.
Habe seit ein halb Jahr auch den Switch gemacht von FHEM nach Home 
Assistant.

Jetzt wollte ich die ht_pitiny nutzen om den Junkers Brenner ein zu 
binden in HA.
Aber da ist kein directe HA integration von Norbert. Jetzt lese ich das 
es auch geht über MQTT (lesen UND schreiben).

Auf meine HA ist auch ein MQTT Broker installiert. (benutze es für 
Tasmota flashed ESP chips).
Also kan ich die Norbert HT3 software installieren auf ein Pi und ins 
config MQTT localhost ändern nach mein HA MQTT Mosquito broker IP und 
über HA MQTT autodiscovery die topic eintragen für lesen und steueren 
(von Temp setpoint) so ich verstehe.

Habe auch den EMS-ESP Project gefunden welche basiert ist auf ein 
ESP8266 oder ESP32 chip.
Diese software sieht einfacher aus und ist HA ready.
Kein install von Pi mit OS, und HT3 software von Norbert, nur ein 
einfaches flash von ein BIN file auf den ESP8266 und connectieren mit 
ESP-EMS site. (mein entschuldigung Norbert :-) )

Kann ich mit einem ht_pitiny (nur wie interface) auch einem ESP8266 chip 
dirext anschliesen und doch den EMS-ESP software nutzen ?

Auf Seite 17 den Norbert HT3_Adaption.pdf sagt Norbert dan man die 
ht_pitiny auch ohne Raspberry Pi nutzen kann mit zb. ein USB adapter 
(nur 4 signale : RXD/TXD/GND/+3.3V)

Kann ich zb. ein NodeMCU oder Wemos D1 ESP8266 chip direct anschliesen 
an diese 4 signale ?

Also mein ESP8266 nimmt power (5V) über den USB port.

Ich verbinde den ESP 3.3V power pin an pin 1 auf den ST1 ht_pitiny 
header.
Ich verbinde den ESP GND pin an pin 6 auf den ST1 ht_pitiny header.
Ich verbinde den ESP TxD pin (D8 Wemos) an pin 8 (RxD) auf den ST1 
ht_pitiny header.
Ich verbinde den ESP RxD pin (D7 Wemos) an pin 10 (TxD) auf den ST1 
ht_pitiny header.

ESP8266:
Rx GPIO pin - Which pin the Rx is assigned to. On an ESP8266 this has to 
be 3 or 13. The default is 13 (D7 on a Wemos).
Tx GPIO pin - Which pin the Tx is assigned to. On an ESP8266 this has to 
be 1 or 15. The default is 15 (D8 on a Wemos).

Wird das funzen ? :-)

Wofür ist die ATiny441 chip dann eigentlich in den ht_pitiny ?
In die BBQKees EMS Bus HAT for Raspberry Pi siehe ich kein chip.

Vielen Danke im vorraus und ein gutes 2021.

Mfg,

Bert

[Bert (Gast)]

auf https://github.com/proddy/EMS-ESP/issues/456

lese ich:

both hardware can be connected in parallel to the same heater-Bus (EMSx 
or heatronic). They are using different device-ID's, so no 
traffic-collision is on the heater-bus.
EMS-ESP is using fixed device-ID: 0x0B (service-key).
ht_pitiny is using default device-ID: 0x0D (modem) but can be configured 
also to other once's if required.
I have checked this on my heater-system with EMS-ESP rev. 1.9.5 and 
ht_pitiny connected in parallel to the heater-bus.
The communication of them is done with MQTT for receiving decoded data 
and sending commands to the heater-system.
For the HA bindings on EMS-ESP see the wiki.
For that HT3/EMS pi_tiny-Adapter HA bindings are not yet available in 
the project, but I know some forum-members has already created that HA 
binding.
So, if you like you can run them in parallel on the same heater-bus.

und

the EMS-ESP can use a selection of deviceIDs. I'll close this now but 
feel free to re-open and share some feedback and how far you got.

Norbert sagt beide systemen können parallel arbeiten, aber kan den 
pi-tiny nur benutzt werden mit EMS-ESP durch den pi-tiny zu verbinden 
met ein EMS-ESP geflashte ESP8266 ?

von EMS-ESP site:

EMS Bus

    Tx Mode. 1 is default for EMS1.0 systems but also compatible with 
most other protocols. 2 is designed to work better for EMS2.0/EMS+ 
systems and 3 for Heatronics3 used by Junkers and Bosch. Choose the mode 
that works best for your system and watch for Tx errors in the Web 
Dashboard and show ems in the Console. Changing the value has immediate 
effect.
    Bus ID. The EMS-ESP can simulate one of 5 devices. Stick to the 
Service Key (0x0B) unless using multiple EMS gateways or interfaces.
    Rx GPIO pin - Which pin the Rx is assigned to. On an ESP8266 this 
has to be 3 or 13. The default is 13 (D7 on a Wemos). On an ESP32 it can 
be any pin.
    Tx GPIO pin - Which pin the Tx is assigned to. On an ESP8266 this 
has to be 1 or 15. The default is 15 (D8 on a Wemos). On an ESP32 it can 
be any pin.

Also EMS-ESP benutzt default 0x0B (service key) wie bus ID, vielleicht 
muss man diese dan auch änderen nach 0x0D (modem) wenn man ein ESP an 
pi-tiny verbind ?

[Norbert S. (junky-zs)]

Bert schrieb:
> Kann ich mit einem ht_pitiny (nur wie interface) auch einem ESP8266 chip
> dirext anschliesen und doch den EMS-ESP software nutzen ?
Ohne EMS-ESP Software-Anpassung geht dies nicht.

> Auf Seite 17 den Norbert HT3_Adaption.pdf sagt Norbert dan man die
> ht_pitiny auch ohne Raspberry Pi nutzen kann mit zb. ein USB adapter
> (nur 4 signale : RXD/TXD/GND/+3.3V)
> Kann ich zb. ein NodeMCU oder Wemos D1 ESP8266 chip direct anschliesen
> an diese 4 signale ?
> Also mein ESP8266 nimmt power (5V) über den USB port.
Ja, das geht mit jeder CPU die eine serielle Schnittstelle und 3.3V hat.
Allerdings fehlt dann noch die SPI-Schnittstelle, mit der man eine 
Software-Aktualisierung des ht_pitiny-Adapters machen kann. Da aber die 
Transceiver-Software bisher noch nicht geändert werden musste ist die 
nicht zwingend erforderlich.

> Wird das funzen ? :-)
Ja, nach Software-Anpassungen auf dem ESP8266.

> Wofür ist die ATiny441 chip dann eigentlich in den ht_pitiny ?
Auf dem ht_pitiny ist ein ATiny841 und kein ATiny441 (wegen der 
erforerlichen Flash-Groesse).
Die ht_pitiny- bzw. ht_piduino-Adapter machen 'nur' die wichtige 
serielle Telegramm-Anpassung zur korrekten 'Break'-Signal Erkennung bzw. 
Sendung.
Zusätzlich ist die 'galvanische Trennung' zwischen Heizung und RPi durch 
Optokoppler auf dem Adapter vorhanden.
Alle Heatronic-/EMS-Bussignale haben als Telegram-Endesignal das 
'Break'-Signal (>= 10 Bit low). Ohne diese Break-Signal-Generierung und 
-Erkennung kann keine korrekte Kommunikation auf den 
Heatronic-/EMS-Busleitungen erfolgen, da es dort keine Telegramme mit 
festen Längen gibt und auch nicht alle Telegramme ein CRC-Byte enthalten 
(Polling-Bytes z.B.).

> Also EMS-ESP benutzt default 0x0B (service key) wie bus ID, vielleicht
> muss man diese dan auch änderen nach 0x0D (modem) wenn man ein ESP an
> pi-tiny verbind ?
Nein, jede Device-/Bus-ID darf nur EINMAL am gleichen Heizungsbus 
vorhanden sein. Empfang der Heizungs-Daten ist mit jeder Device-ID 
möglich, Senden in den Heizungsbus mit den für diese Aufgabe 
vorgesehenen Device-ID's (0x0B:=service key; 0x0D:=Modem).
Gruß Norbert

[Peter (Gast)]

Hallo Norbert,
ich habe den HT_Pinity schon vor langer Zeit nachgebaut und er 
funktioniert auch gut. Musste jetzt den RPI3 neu installieren und wollte 
dann auch gleich MQTT konfigurieren.
Habe alles laut Anleitung installiert und konfiguriert. Wenn die Konfig 
auf ASYNC konfiguriert ist, werden die Graphiken erstellt. Wenn ich 
hingegen aus SOCKET umstelle (collgate._cfg.xml MQTT aktiviert; 
mqtt_client_cfg.xml broker konfiguriert) werden keine Graphiken erstellt 
und es wurden keine MQTT Daten an mein Homeassistant geschickt. Auf dem 
Homeassistant läuft das MQTT, da mein Shelly EM die aktuellen 
Verbrauchsdaten dort hin sendet.

Die ht3_db_cfg.xml schaut bei mir so aus:

    <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/serial0</serialdevice>
        <inputtestfilepath></inputtestfilepath>
        <baudrate>19200</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>


Hast du vielleicht einen Tipp wo ich den Fehler suchen kann?

Grüße
Peter

[Norbert S. (junky-zs)]

Peter schrieb:
> Hast du vielleicht einen Tipp wo ich den Fehler suchen kann?
Wahrscheinlich in der Konfiguration.
Damit die SOCKET-Einstellung funktioniert muss der ht_proxy.server 
laufen und 'NUR' dieser bemuckelt die serielle Schnittstelle.
(Einstellungen im Konfigurations-File:./etc/config/ht_proxy_cfg.xml )

Die empfangenen Heizungsdaten werden dann an die verbundenen ht_clients 
verteilt. In diesem Fall ist der ht_collgate.py ein Socket-client des 
ht_proxy.servers (siehe Bilder).
Dies ist übrigens die Default-Konfiguration im Projekt (unter github zu 
finden).
Es muss u.U. nur die Baudrate je nach Type des serielle Adapters und der 
<serialdevice>-name angepasst werden.
File:./etc/config/ht_proxy_cfg.xml:

  <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>

Details dazu sind in meiner Dokumentation ausführlich beschrieben.
PS:
Der ht_proxy.server muss laufen, wenn Du Deine Heizung mit dem 
ht_pitiny-Adapter steuern willst.
Gruß Norbert

[Peter (Gast)]

Hallo Norbert,
jetzt habe ich das Problem gefunden. Die Lösung war auf Seite 56 deiner 
Dokumentation. ;-) Musste bei der Proxy Config von /dev/ttyAMA0 auf 
deviceport="/dev/serial0 umstellen, jetzt funktioniert es einwandfrei. 
Habe alles einige male kontrolliert, aber diese Zeile habe ich nicht 
gesehen.

Hätte noch jetzt noch eine Frage frage zu MQTT, vielleicht kann mir ja 
jemand weiterhelfen.
MQTT läuft auf meinen Homeassistant, habe zwei Shelly's am laufen, die 
wurden automatische erkannt.
Wie kann ich den Pinity im Homeassistant konfigurieren? Muss das gesamte 
Konfigfile manuell erstellt werden? Hate jemand vielleicht ein Beispiel 
sodass ich sehe wie ich starten muss?
Möchte gerne alle Werte vom Pinity auslesen uns steuern.

Vielen Dank!!

Peter

[Norbert S. (junky-zs)]

Peter schrieb:
> Wie kann ich den Pinity im Homeassistant konfigurieren? Muss das gesamte
> Konfigfile manuell erstellt werden?
Hallo Peter, das TAR-File enthält einen MQTT-Konverter um die 
hometop_HT3-messages für den Homeassistant aufzubereiten.
Bitte das Tar-File in das Home-Verzeichnis des Pi-Users ablegen und 
entpacken mit:
 tar -xvf mqtt_ht2hassio.tar
Das Tool und das Konfiguration-File werden dann nach ~/HT3/sw und 
~/HT3/sw/etc/config geschrieben.
Wenn der MQTT-Broker ebenfalls auf dem gleichen RPi liegt, braucht das 
Konfigfile nicht angepasst zu werden.
Andernfalls muss die MQTT Broker-Serveradresse im Konfigfile: 
'mqtt_ht2hassio_cfg.xml' eingetragen werden.
Starten des Tools mit (Hintergrund-Prozess):
 cd ~/HT3/sw
 ./mqtt_ht2hassio.py &

Damit das MQTT-Discovery in Homeassistant gut funktioniert bitte das 
Konfigurationsfile des mqtt-clients anpassen, damit immer alle Log-Werte 
ausgegeben werden:
Konfigfile: ~/HT3/sw/etc/config/mqtt_client_cfg.xml
Anpassung : Publish_OnlyNewValues auf False

<mqtt_client>
 ....
 <Publish_OnlyNewValues>False</Publish_OnlyNewValues>

Nach der Anpassung den daemon 'ht_collgate.py' neu starten.

Die neu erkannten Parameter/Werte werden durch MQTT-Discovery 
automatisch in Homeassistant erkannt und unter 'Sensor' eingetragen.
Die einzelnen Parameter/Werte können dann einzelnen Bereichen in HA 
zugewiesen werden (siehe Beispiel-Bild)

Peter schrieb:
> Möchte gerne alle Werte vom Pinity auslesen uns steuern.
Auslesen der Werte ist mit diesem Tool möglich, steuern nicht.

Gruß Norbert

[Andreas (Gast)]

Danke Norbert!
Danach hatte ich schon gesucht :)

Funktioniert 1a

Falls jemand ein Autostart-Script benötigt, habe ich meins angehängt.
Habe ich mir bei Norbert geklaut und nur angepasst ;) Danke

Bitte nach
/etc/init.d kopieren
sudo chmod +x /etc/init.d/mqtt_ht2hassio
sudo systemctl enable mqtt_ht2hassio

Und schon bleibt es nach nem Neustart erhalten :)

Danke Norbert für deine Skills!

Ich hatte mir, zumindest die Außentemperatur so in HA geholt:

  - platform: mqtt
    state_topic: 'hometop/ht/ch_Toutside'
    name: 'Aussentemperatur'
    unit_of_measurement: '°C'

Andi

[Peter (Gast)]

VIELEN DANK für Eure Hilfe, werde heute Abend gleich probieren!!

[Andreas (Gast)]

Und hier auch noch meine schnell hingeschusterte Config:

  - title: Heizung und Solar
    path: heizung-und-solar
    badges: []
    cards:
      - entities:
          - entity: sensor.ch_tflow_measured
          - entity: sensor.ch_tflow_desired
          - entity: sensor.ch_pump_heating
          - entity: sensor.ch_burner_power
          - entity: sensor.ch_pump_heating_power
          - entity: sensor.ch_mode
          - entity: sensor.ch_burner_fan
          - entity: sensor.ch_burner_operation
          - entity: sensor.ch_thdrylic_switch
          - entity: sensor.ch_treturn
          - entity: sensor.ch_t3waymixer
          - entity: sensor.ch_causecode
          - entity: sensor.ch_errorcode
          - entity: sensor.ch_pump_circulation
          - entity: sensor.ch_pump_cylinder
          - entity: sensor.ch_runtime_ch
          - entity: sensor.ch_runtime_tot
          - entity: sensor.ch_starts_ch
          - entity: sensor.ch_runtime_tot
          - entity: sensor.ch_toutside
        title: Heizgerät
        type: entities
      - type: entities
        entities:
          - entity: sensor.hc1_tmeasured
          - entity: sensor.hc1_tflow_desired
          - entity: sensor.hc1_tdesired
          - entity: sensor.hc1_mixerposition
          - entity: sensor.hc1_tflow_mixer
          - entity: sensor.hc1_tniveau
          - entity: sensor.hc1_pump
          - entity: sensor.hc1_operationstatus
        title: Heizkreis
      - type: entities
        entities:
          - entity: sensor.sol_tcollector
          - entity: sensor.sol_tcylinder_bottom
          - entity: sensor.sol_yield_last_hour
          - entity: sensor.sol_yield_sum
          - entity: sensor.sol_pump
          - entity: sensor.sol_runtime
          - entity: sensor.sol_yield_last_day
          - entity: sensor.sol_buffer_full
          - entity: sensor.sol_collector_deactive
        title: Solar
      - type: entities
        entities:
          - entity: sensor.dhw_tcylinder
          - entity: sensor.dhw_tmeasured
          - entity: sensor.dhw_tok
          - entity: sensor.dhw_tdesired
          - entity: sensor.dhw_runtime_ch
          - entity: sensor.dhw_starts_ch
          - entity: sensor.dhw_charge_once
          - entity: sensor.dhw_thermal_desinfection
          - entity: sensor.dhw_generating
          - entity: sensor.dhw_boost_charge
        title: Warmwasser


Habe ich was vergessen? Bitte info

Danke

[Norbert S. (junky-zs)]

Andreas schrieb:
> Habe ich was vergessen? Bitte info
Sieht OK aus danke für die Arbeit, macht einiges einfacher bei der 
Konfiguration.
Allerdings müssen je nach Heizungssystem einige Werte aus der Liste 
entfernt oder hinzugefügt werden.
Einige Werte gibt es nicht in jedem Heizgerät z.B.: 
'sensor.ch_treturn':= Rücklauftemperatur oder 'sensor.ch_t3waymixer':= 
3Wege-Mischer Temperatur.
Auch gibt es Anlagen mit mehr als einem Heizkreis.
Dann ist Deine Liste halt entsprechend zu erweitern.

Noch eine wichtige Sache zu der 'InfluxDB' Datenbank in Homeassistant.

Diese Datenbank verwendet den Port 8086 als Default-Verbindung (siehe 
Bild).
Dieser Port wird z. Zeit jedoch vom httpd-daemon verwendet zur 
Kommunikation/Darstellung der rrdtool-Grafiken mit einem Browser.
Daher muss das Script 'httpd' auf eine andere Port-Nummer gesetzt 
werden.
Modul: ~/HT3/sw/etc/html/httpd.py
Anpassung: port# auf 48086 setzen

from http.server import HTTPServer, CGIHTTPRequestHandler
serveradresse =("", 48086)
server=HTTPServer(serveradresse, CGIHTTPRequestHandler)
server.serve_forever()

Aktionen:
Daemon stoppen und neu starten und die Browser-Abfragen mit der neuen 
Port-Nummer durchführen.
Gruß Norbert

[Markus L. (markus_l453)]

Guten Morgen,

ich bin über das tolle Projekt hier gestolpert und würde gerne an meine 
Junkers andocken.
Allerdings bin ich nicht so der Elektriker und daher etwas vorsichtig.

Ich bin über das HAT von Waveshare gestolpert.

Waveshare 2-Channel Isolated RS485 Expansion HAT for Raspberry Pi 
SC16IS752+SP3485 Solution with Multi Onboard Protection Circuits

Kann ich das hierfür verwenden?
Ich würde gerne einen Raspery PI Zero 2 verwenden und dann die Daten an
meinen IO Broker übergeben wollen.

Mfg.
Markus

[Josef (Gast)]

Hallo Markus,

ich hatte mich 2015 auch schon mal an dieses Projekt rangehängt.
Die Hardware hat mir dann aber auch zu schaffen gemacht.
Weiss nicht was du machen willst und inwieweit du dich schon mit 
ioBroker auskennst, aber wenn es darum geht Daten zu lesen, hast du mit 
deinem ioBroker nebst MBLAN schon alles was du brauchst.
Schau dir mal den KM200 Adapter an:
https://github.com/frankjoke/ioBroker.km200/blob/master/README.md
Läuft mit meiner Junkers seit Jahren Problemlos.
Gruß

[Norbert S. (junky-zs)]

Markus L. schrieb:
> Ich bin über das HAT von Waveshare gestolpert.
> Waveshare 2-Channel Isolated RS485 Expansion HAT for Raspberry Pi
> SC16IS752+SP3485 Solution with Multi Onboard Protection Circuits
>
> Kann ich das hierfür verwenden?
Nein, leider nicht. Auch nicht den Isolated RS232.
Dies liegt hauptsächlich an der nötigen Pegelanpassung auf der 
Empfangs-Seite und der Strom-Steuerung auf der Sende-Seite (in Richtung 
Heizungs-Bus).

Habe noch einen ht_pitiny-Adapter für den RPi falls Du kein MBlan2 hast.
Sende mir eine PM für weiteren IO.

Gruß Norbert

[Moritz M. (moritz2)]

Hallo zusammen,

ich habe eine Junkers Cerasmart ZSB 3-16 mit dem TA 211 E Steuermodul 
und auf der Suche nach einem Weg, den Gerätestatus zu protokollieren. 
Leider finde ich gar keine Informationen darüber, wo die Bus-Pins bei 
dem Gerät sind.

Hat da ggf. jemand ein Anschlusschema oder eine Info, welches 
Steuermodul dort nachgerüstet werden müsste?

Vielen Dank!

Moritz

[Norbert S. (junky-zs)]

Moritz M. schrieb:
> ich habe eine Junkers Cerasmart ZSB 3-16 mit dem TA 211 E Steuermodul.
> Hat da ggf. jemand ein Anschlusschema oder eine Info, welches
> Steuermodul dort nachgerüstet werden müsste?
Infos habe ich gefunden unter:
 https://manuall.de/junkers-ta-211-e-thermostat/
 https://www.manualslib.de/download/435629/Junkers-Zsb-3-16-A-21.html

Die Bedienungsanleitung ist von 2006 und Dein Gerät wahrscheinlich etwa 
eben so alt. Dort wird zwar von einer 'Heatronic' gesprochen, die jedoch 
wohl keinen Bus-Anschluss hat und eine analoge Steuerung ist.
Erst ab 'Heatronic3' (Ende 2008) sind die hier beschriebenen Soft- und 
Hardware-Schnittstellen nutzbar.
Ich kenne keinen Nachrüst-Set für deine Anlage um eine Bus-Anbindung zu 
erreichen.
Vielleicht hat jemand dazu noch weitere Infos?

Gruß Norbert

[Moritz M. (moritz2)]

Norbert S. schrieb:
> Die Bedienungsanleitung ist von 2006 und Dein Gerät wahrscheinlich etwa
> eben so alt. Dort wird zwar von einer 'Heatronic' gesprochen, die jedoch
> wohl keinen Bus-Anschluss hat und eine analoge Steuerung ist.
> Erst ab 'Heatronic3' (Ende 2008) sind die hier beschriebenen Soft- und
> Hardware-Schnittstellen nutzbar.

Jau, das scheint es zu sein.

Heatronic III: 
https://i.ebayimg.com/images/g/xDIAAOSwYrhhKSBm/s-l1600.jpg, erkennbar 
an SMD

Heatronic II: 
https://i.ebayimg.com/images/g/eD4AAOSwuMNd~Rh2/s-l1600.jpg, erkennbar 
an LED digit display.

Scheinbar gibt es für die Heatronic II einen CAN-BUS kompatiblen Regler 
(siehe 
https://wiki.volkszaehler.org/hardware/channels/heating_control/gastherme_junkers_can_bus, 
Beitrag "Junkers CAN-Bus Protokoll"), bedeutet dann aber wohl, 
dass auch nur die Reglerinformationen abgefragt werden können, und nicht 
der Brennerstatus oder ähnliches, und benötigt wohl ein extra Modul.

Ich schaue sonst mal mit nem einfachen Temperatursensor am Vorlauf und 
nem Strommessstecker ob ich einen ungefähren Status bekomme..

[Andreas (Gast)]

Hallo zusammen,
hat jemand von Euch noch eine Platine für den Raspi?

Ich habe den Thread durchgelesen verstehe es so, dass ich die Platine 
dann entsprechend der Pläne von Norbert auf GitHub bestücke und dann 
auch die Software von GitHub auf dem Raspi einrichte. Ist das richtig 
so?

Das ist echt ein tolles Projekt, vielen Dank! Bin mal gespannt, ob ich 
das hinbekomme. 😉

Viele Grüße!
Andreas

[Andreas L. (homeberg)]

Eine Zusatzfrage habe ich noch: Was ist einfacher umzusetzen? pitiny 
oder piduino?

[Peter (Gast)]

Hallo Moritz,

hier liegen deine Möglichkeiten -->
Beitrag "Junkers CAN-Bus Protokoll".

Aber Du benötigst mindestens noch den CAN-Bus Adapter BM1 bzw. evtl. das 
komplett Paket TA250 oder höher von Junkers. Die Schnittstelle HTII ist 
wesentlich einfacher zu handeln als III.

Über TA211 bekommst Du nur die Austemperatur bzw. die eigenen 
Einstellungen über eine sequentiellen Spannungs/Frequenzaustastung [VCO] 
über die beiden i2C-Anschlüsse.

Peter

[Michael G. (katzenschreck)]

Andreas schrieb:
> Hallo zusammen,
> hat jemand von Euch noch eine Platine für den Raspi?
>
>....
> Viele Grüße!
> Andreas

Hallo zusammen,
ich hätte noch eine unbestückte Platine für den piduino übrig.
Wer Interesse hat, einfach per Mail melden.

Ich würde sie für 3 Euro abgeben incl. Versand als Brief.

Frohe Ostern,
katzenschreck

[Markus B. (spektrum)]

Hallo,

da ich demnächst umziehe, habe ich einen bestückten und funktionsfähigen 
"ht_piduino" abzugeben, auf Wunsch auch mit einem Raspi incl. Netzteil 
und Gehäuse. Es handelt sich um einen Raspi Model B Rev 1, der lediglich 
als Proxy eingesetzt wurde. Dafür war er völlig ausreichend und hat 
bereits über Jahre einen treuen Dienst an einer Junkers Therme 
verrichtet. Lediglich die Fuses mussten einmal nachprogrammiert werden - 
warum auch immer.

Bei Interesse Nachricht per PN.

Grüße
Markus

[Tobias S. (herrgesangsverein)]

Hallo,
ich bin neu hier und stehe vor einem geradezu enzyklopädischen Thread.
Soweit ich verstanden habe, gibt es HW-Adapter, um den 2-Draht-Bus an 
einen Raspi anzuschließen. Dabei wird auch ein RS232-USB-Umsetzer 
verwendet.

Ich habe schon einen Nano-PI Neo im Einsatz, der noch einen freien UART 
und 5V hat, den ich gerne verwenden würde. Geht das? Wenn ja, welchen 
Adapter muss ich nehmen und wo muss ich abgreifen?
Ich gehe davon aus, dass die Python Software vom norberts1/hometop den 
Unterschied nicht merken würde?!

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Dabei wird auch ein RS232-USB-Umsetzer
> verwendet.
Ist nicht erforderlich.

> Geht das? Wenn ja, welchen Adapter muss ich nehmen und wo
> muss ich abgreifen?
Ja, geht wie folgt:
Nötige Verbindung zwischen ht_adapter und Nano-PI Neo

Funktion  Pin (ht_adpater)  Pin (Nano-PI Neo)
3.3 Volt    1               1 (SYS_3.3V)
UART TX    10 (TXD0)       10 (UART1_RX/GPIOG7)
UART RX     8 (RXD0)        8 (UART1_TX/GPIOG6)

Es sind für den Betrieb keine weiteren Verbindungen nötig.
Nur für einen Sw-Update der ht_pitiny-/ht_piduino-Adapter sind weitere 
Verbindungen erforderlich.
Ein Software-Update ist z.Zeit jedoch nicht vorgesehen.

Es können alle vorgestellten (passive-/aktive Adapter) mit dem Nano-PI 
Neo oder auch anderen Boards betrieben werden.
Erforderlich ist nur:
  Betriebsspannung 3.3 Volt
  UART-Anschlüsse müssen 3.3Volt tolerant sein.

Offensichtlich ist der GPIO des Nano-PI Neo pinkompatibel zum RaspPI.
Somit wird man wohl auch die hier vorgestellten ht_adapter direkt 
(gesteckt) an einem Nano-PI Neo betreiben können.
Allerdings habe ich keinen Nano-PI Neo und kann es somit nicht testen.

Die Projekt-Software von github/norberts1 wird auch funktionieren, da 
auf dem 'Nano-PI Neo' Board ubuntu-Linux eingesetzt wird und
ich das Projekt unter ubuntu auf meinem Laptop getestet habe.

Gruß Norbert

[Tobias S. (herrgesangsverein)]

Danke Norbert,
ich habe mich jetzt an die Schaltung anbei gehalten.
Ich muss eine eigene Leiterkarte machen, weil ich Sie zu einem NanoPI 
Gerät hinzufügen muss.

Dabei ist mir aufgefallen, dass diese ein AGND auf der Busseite und ein 
BGND auf der UART Seite hat. Wo schliesst man denn AGND an?

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Dabei ist mir aufgefallen, dass diese ein AGND auf der Busseite und ein
> BGND auf der UART Seite hat. Wo schliesst man denn AGND an?
AGND ist ja Teil des 2 Draht Heizungsbusses. AGND und BGND dürfen auf 
keinen Fall verbunden werden! Sonst ist die galvanische Trennung 
zwischen Heizungsbus und Datenerfassungseinheit (Adapter - CPU etc.) 
nicht mehr vorhanden.
2-Draht Heizungsbus-Anschluss wie folgt (für die ausgewählte Schaltung):
1. Pluspol des 2-Draht Busses an Pin1 Klemmenblock bzw Anode der Diode 
D1.
2. Minuspol des 2-Draht Busses an Pin2 bzw. AGND.
Polarität des 2-Draht Busses vorher ausmessen.

Wie gesagt, BGND wird nicht mit dem Heizungsbus verbunden, sondern ist 
ja die Betriebs-Masse Deines 'Nano-PI Neo' und bleibt durch den 
Optokoppler auch vom Heizungsbus galvanisch getrennt.

Gruß Norbert

[Markus B. (spektrum)]

Markus B. schrieb:
> Hallo,
>
> da ich demnächst umziehe, habe ich einen bestückten und funktionsfähigen
> "ht_piduino" abzugeben, auf Wunsch auch mit einem Raspi incl. Netzteil
> und Gehäuse. Es handelt sich um einen Raspi Model B Rev 1, der lediglich
> als Proxy eingesetzt wurde. Dafür war er völlig ausreichend und hat
> bereits über Jahre einen treuen Dienst an einer Junkers Therme
> verrichtet. Lediglich die Fuses mussten einmal nachprogrammiert werden -
> warum auch immer.
>
> Bei Interesse Nachricht per PN.
>
> Grüße
> Markus

Das Teil st nicht mehr da. Kann Beitrag leider nicht löschen. 
(Exception)

[Tobias S. (herrgesangsverein)]

Hallo Norbert,

ich kämpe noch. Ich habe jetzt die Schaltung umgesetzt und möchte sie 
testen. Ich verstehe Sie so: Unterhalb einer Schwellspannung sperren die 
Dioden und es fließt kein Strom. Der Optokoppler bleibt auf 0V, der 
Transistor sperrt, am "Ausgang" TX liegt HI an.
Wenn die Schwelle überschritten wird, fließt Strom durch die Diode am 
Optokoppler. Der Transistor schaltet durch und zieht den Ausgang auf Low

Nur: bei mir passiert das alles nicht. Schon auf der Eingangsseite: Ich 
habe ein Netzteil angeschlossen und die Spannung schrittweise erhöht. 
Ich erwarte, dass an irgendeinem Bauteil die Spannung abfällt, aber 
nicht am Optokoppler.
Ich messe überall nur mV.
Ich habe dann die Spannung bis auf 18V erhöht, das gleiche Bild.
An den äußersten Bauteilen (Kathode von BAT46 und vom H11L1) messe ich 
die Netzteilspannung.

Meine Fragen:
Wie prüfe ich die Schaltung?
Welche Schwellspannung ist vorgesehen (ich zähle ca. 
0,4V+9,1V+2V+0,7V=12,2V) ?
Was macht die Schottky-Diode da?

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Nur: bei mir passiert das alles nicht.
Nette kleine Platine.
Diode D1 ist offensichtlich falsch rum montiert. Kathode und Anode 
vertauscht.

> Meine Fragen:
> Wie prüfe ich die Schaltung?
Dazu bitte den zugehörigen Schaltplan posten.

Gruß Norbert

[Tobias S. (herrgesangsverein)]

Oh Mann, wie dumm! Wie kann man das übersehen. In der Tat habe ich im 
Schaltplan schon die Schottky-Diode falsch rum eingesetzt und nicht mehr 
verglichen. Ich bin nicht so der Analog-Elektroniker. Daher ist mir auch 
nicht klar, was die Schottky-Diode dort soll.

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Daher ist mir auch nicht klar, was die Schottky-Diode dort soll.
Die soll die Zenerdiode D2 und die LED D3 schützen falls man den 
Heizungsbus mit falscher Polarität anschließt. Eine Zenerdiode verhält 
sich ja wie eine Diode (0.6Volt Spannungsabfall,kein Zenereffekt) sobald 
man Plus an die Anode und Minus an die Kathode anschließt.
PS:
Widerstand R4 und LED D4 können entfallen bzw. brauchen nicht bestückt 
zu werden. Sind mal in der Entwicklungsphase als Indikatoren für die 
TX-Richtung  gedacht gewesen, sind aber überflüssig für die RX-Richtung.

Frage: Welches CAD-Programm hast Du für die PCB-Erstellung verwendet?

Gruß Norbert

[Tobias S. (herrgesangsverein)]

Ich benutze KiCAD 6.0. Passt für mich optimal.

Gegenfrage: Warum reicht denn nicht die LED gegen Verpolung. Die sperrt 
doch auch, oder?

[Norbert S. (junky-zs)]

Tobias S. schrieb:
> Gegenfrage: Warum reicht denn nicht die LED gegen Verpolung. Die sperrt
> doch auch, oder?
Die sperrt auch ja, aber nur bis zu einer Reverse-Spannung von ca. 5-6 
Volt.
Da jedoch auf dem Heizungsbus (Junkers/Bosch) bis zu 15Volt 
Gleichspannung liegen, wäre dies nicht gesund für die LED.
Gleiches gilt auch für den Optokoppler.

Gruß Norbert

[Renee (renee)]

Lieber Norbert S.,

ganz herzlichen Dank für Deine wunderbare Arbeit und den ausdauernden 
Support, den Du uns noch dazu gibst.

Ich habe eine Frage zum ht_transceiver-master: Kann ich den Empfangsweg 
betreiben ohne den Sender zu nutzen? Ich habe den HT_pitiny in Auszügen 
auf Lötpunktrasterkarte nachgebaut. Aber nur den Empfangsweg. Die 
Verriegelung mit HT Bus enable habe ich weggelassen. Programm und Fuses 
mit meinem alten JTAGICEmkII programmiert. Jetzt liefert der µC schön 
Daten mit 19200 ab, wie mein Terminalprogramm zeigt.

Bevor ich einen Computer bestimme, auf dem Deine Auswertung laufen soll, 
möchte ich fragen, ob es für das reine Mitlesen Nachteile hat, wenn der 
Sendeweg fehlt. Bekommt das HT_pityni Programm wichtige 
Initialisierungen vom
HT3 System?

Vielen Dank im voraus und nochmals großen Dank für die Arbeit!

Grüße, Renee

[Norbert S. (junky-zs)]

Renee schrieb:
> ...möchte ich fragen, ob es für das reine Mitlesen Nachteile hat, wenn der
> Sendeweg fehlt. Bekommt das HT_pityni Programm wichtige Initialisierungen
> vom HT3 System?
Nein, hat keine Nachteile. Die aktiven Adapter (ht_pitiny/ht_piduino) 
detektieren (RX) und generieren (TX) das Break-Signal und setzen die 
Kommunikation auf 19200Baud um, mehr nicht.
Es werden keine Daten von diesen aktiven Adaptern vom Heizungsbus 
angefordert. Der Heizungsbus selber generiert ohne Aufforderung die 
Telegramme, die nachgelagert ausgewertet werden.
Man kann zwar aktiv Daten vom Heizungsbus abfragen, dies habe ich jedoch 
vermieden damit der Betrieb auch mit den passiven Adaptern möglich ist.
Die Auswertung des Heizungsbus RX-Datenstroms erfolgt nur in der 
nachgelagerten Python-Software.
Dadurch sind auch mit der gleichen Software die passiven Adapter nutzbar 
(mit etwas eingeschränkter Break-Signal Detektionssicherheit).

Gruß Norbert

[Renee (renee)]

Danke Norbert. Alles klar!

Grüße, Renee

[Renee (renee)]

Hallo Norbert, hallo allerseits!

Nochmals ganz herzlichen Dank und weiter unten kommt noch eine Frage.

Seit gestern Abend läuft das System bei mir.

Hier arbeitet ein Junkers Cerapur Brennwertkessel mit einem eingebauten 
FW100. Es gibt einen Heizkreis und einen frei stehenden 
Warmwasserspeicher. Die Warmwasserbereitung wird im Sommer durch sechs 
Velux Flachkollektoren unterstützt. Die Solarthermie hat einen eigenen 
Regler und steht nicht unter Junkers Kontrolle.

Meine bisherige Hausdatenerfassung umfasst die Vor- und 
Rücklauftemperaturen von Heizung und Solar sowie die Temperaturen im 
Wasserkessel oben und unten. An den Wasser-, Gas- und 
Elektrizitätszählern habe ich Sensoren, die mir Impulse pro 
Verbrauchseinheit liefern. Ich zeichne mit ein paar Shellscripten auf 
einem kleinen Linux-Rechner auf. Die Temperatur- und Verbrauchskurven 
visualisiere ich mit gnuplot. Eine Webseite zeigt mir die Livewerte und 
ermöglicht die Anwahl der Grafiken.

Und jetzt kann ich dank Norbert besser nachvollziehen, was die 
Heizungssteuerung sich so "denkt". Gerade jetzt, wo wir Gas sparen 
möchten und unsere Heizkurven optimieren, empfinde ich das als sehr 
wertvoll. Wie schon geschrieben, habe ich den HT_pitiny abgewandelt 
(siehe Schaltplan) und betreibe ihn im Schaltschrank meiner Messtechnik. 
Die Auswertung läuft auf einem Raspberry Pi 3B, der schon da war und 
mein DNS-Filter (Pi-hole) hostet.

Das HT3 System ist jetzt die erste Nacht durchgelaufen und die Grafiken 
füllen sich langsam (siehe Bilder).

Und nun zu meiner Frage: Wie starte/nutze ich den HT3_Analyser oder 
HT3_Systemstatus?

Beste Grüße, Renee

[Norbert S. (junky-zs)]

Renee schrieb:
> Und nun zu meiner Frage: Wie starte/nutze ich den HT3_Analyser oder
> HT3_Systemstatus?
Startbeispiele:
1. auf RPi ins Verzeichnis ./HT3/sw und module: HT3_Analyser.py oder/und 
HT3_Systemstatus.py aufrufen/ausführen.
Können beide (wenn gewünscht) gleichzeitig laufen. Default-Konfiguration 
mit ht_proxy.py vorausgesetzt.
2. auf einem separaten Linux-Rechner mit der kompletten hometop_HT3 
Projektinstallation und der Anpassung des Moduls auf die RPi IP-Adresse: 
./HT3/sw/etc/config/ht_proxy_cfg.xml
  <proxy_client devicename="RX">
    <serveraddress>RPi IP-Adresse</serveraddress>
    <servername></servername>
    <portnumber>48088</portnumber>
    <logfilepath>./var/log/ht_client_rx.log</logfilepath>
    <devicetype>RX</devicetype>
  </proxy_client>

  <proxy_client devicename="MODEM">
    <serveraddress>RPi IP-Adresse</serveraddress>
    <servername></servername>
    <portnumber>48088</portnumber>
    <logfilepath>./var/log/ht_client_modem.log</logfilepath>
    <devicetype>MODEM</devicetype>
  </proxy_client>
</ht_proxy_cfg>
Die Heizungs RAW-Daten werden dann vom RPi über den dort laufenden 
ht_proxy.py an den/die verbundenen externen Linux-Rechner gesendet.
3. unter Windows und putty können auch alle python-Module (ohne GUI) 
ausgeführt werden.
z.B. Module:
  ht_binlogclient.py <<-- binäre Heizungsdaten-Aufzeichnung
  ht_netclient.py <<-- Steuerung der Heizung mit einem aktiven Adapter 
(ht_pitiny oder ht_piduino)

Nutzung:
Kontrolle und Anzeige der Heizungsdaten in Echtzeit.

> Wie schon geschrieben, habe ich den HT_pitiny abgewandelt (siehe Schaltplan)
Wozu hast Du den Spannungswandler LP2950-3.3 verwendet?
Der RaspberryPi hat ja schon 3.3Volt auf der Steckerleiste und der 
Optokoppler kann bis zu 3.0 Volt runter betrieben werden.

Gruß Norbert

[Renee (renee)]

Norbert S. schrieb:
> Wozu hast Du den Spannungswandler LP2950-3.3 verwendet?
> Der RaspberryPi hat ja schon 3.3Volt auf der Steckerleiste und der
> Optokoppler kann bis zu 3.0 Volt runter betrieben werden.

Ich wollte die 3.3 V vom Raspi nicht weiter belasten und 5 V habe ich da 
reichlich. Und meine pitiny Variante hängt an knapp 10 m Leitung. Da 
habe ich gerne einen Spannungsregler auf dem Board.

Ich bin übrigens über einen FTDI USB/Serial Wandler mit 3,3 V Logikpegel 
an den Raspi gegangen. Und der gibt mir auch gleich die +5V und GND 
raus.

Beim H11L1 werden mir die Kennlinien bei 3 V zu krumm. 5 V sind mir 
lieber. Vielleicht Geschmackssache :)

Danke für die Anleitung!

Grüße, Renee

[Max (Gast)]

Hallo.
Auf der Suche nach dem MB Lan2, der scheinbar ausgelaufen ist, bin ich 
auf diesen Beitrag gestoßen.
Leider bin ich nicht sehr bewandert im löten nach Schaltplan (und 
Linux).
Nach Anleitung arbeiten sollte ich aber irgendwie hinbekommen.
Wenn ich es richtig verstanden habe ist ht_pitiny der aktuellste 
Hardwarestand. Aber woher bekomme ich eine (vorbestückte?) Platine?
Ich bin entweder blind oder zu blöd die Quelle zu finden :)
Vielen Dank im voraus für Tipps oder Lösungen

[Philippe (Gast)]

Bitte nicht hauen... Bin auch nicht so der Harry Hirsch mit Platinen, 
aber weiß welches Ende vom Lötkolben heiß wird...

Hab jetzt die Heizung damit unter Kontrolle:

https://bbqkees-electronics.nl/?lang=de

Er hat auch noch ein kleines Modul wo man seriell ran gehen kann

[Philippe (Gast)]

Das hier meinte ich...

https://bbqkees-
electronics.nl/product/ems-schnittstelle-board-v3/?lang=de

[Michael W. (wemi2019)]

Hallo,
ich habe noch einen HT3-MiniAdapter kostenlos abzugeben. Der Adapter 
lief bei mir 4 Jahre problemlos an einer Junkers Gastherme. Da ich auf 
Wärmepumpe umgestellt habe, benötige ich den Adapter nicht mehr.
Bei Interesse bitte melden.
Gruß Michael

[Stefan B. (sbiermann)]

Hallo zusammen,
ich habe seit letzten Montag das Problem das ich nicht mehr über den 
Adapter (ht_pitiny) senden kann. Vorausgegangen war ein Stromausfall am 
Pi durch Stecker ziehen. Seit dem empfängt der Adapter alle Pakete und 
dekodiert die auch korrekt. Sprich das MQTT kommt mit validen Daten an, 
aber so bald ich ein Kommando senden will passiert nichts. Die grüne LED 
auf dem Adapter flackert im Tackt des HT Bus aber vor dem Stromausfall 
war immer mal wieder ein flackern von einer roten LED zu sehen. Was 
jetzt auch fehlt. Sprich die rote LED leuchtet nur noch wenn man den Pi 
aus schaltet und wieder einschaltet kurz auf.
An der Heizung selber habe ich den MB Lan Modus abgebrochen und auf das 
Automatik Programm geschaltet, damit die Heizung wieder funktioniert. 
Ich hätte erwartet das wenn ich neue Kommandos sende wie Heizung auf 
Frost oder so müsste sich die Anzeige wieder ändern und anzeigen das der 
MB Lan Modus aktiv ist. Das passiert aber leider nicht.
Weiß jemand woran das liegen kann?

Viele Grüße
Stefan

[Horst S. (h3aau)]

moin,
ich habe eine KSBR3-16 A leider ohne BM1.
hat schon wer einen ESp32 oder so als ersatz für die BM1 zusammen 
gezaubert?
ich würde meine anlage gern in hausnetz sehen können. steuern ist nicht 
nötig.

[Norbert S. (junky-zs)]

Stefan B. schrieb:
> Hallo zusammen,
> ich habe seit letzten Montag das Problem das ich nicht mehr über den
> Adapter (ht_pitiny) senden kann. Vorausgegangen war ein Stromausfall am
> Pi durch Stecker ziehen.
Die Fuses im ATtiny841 müssen korrekt eingestellt sein damit bei 
Unterschreiten/Ausfall der Betriebs-Spannung das EEPROM und das Flash 
nicht mehr beschrieben werden. Eventuell war dies der Grund bei dem 
ht_pitiny.

Die ht_transceiver-Software (Flash, EEPROM und Fuses) kann inzwischen 
per Script in die Boards geschrieben werden.
Dazu muss das Board auf dem RPi installiert sein, weitere Details sind 
im Projekt-Verzeichnis im Readme unter 'Sofware Installation' 
beschrieben.
URL:
https://github.com/norberts1/hometop_ht_transceiver

Gruß Norbert

[Andreas W. (urbansunited)]

Hallo,

ich möchte meinen ht_pitiny verkaufen.
Er wird bei mir nicht mehr benötigt und funktionierte bis zum Abbau 
einwandfrei.
Wenn jemand Interesse hat, ich schicke gerne Bilder von der voll 
bestückten Platine vorab zu.
Gerne höre ich auch Preisvorschläge, weil ich keine Idee habe, was man 
dafür verlangen kann.

Vielen Dank

Andi

[Bernhard D. (boots)]

Hallo, hier bin ich noch auf ein interressantes Board gestoßen, das 
Daten über MQTT an den IOBroker schicken kann. Ich werde es mir mal 
bestellen und berichten.
VG Bernhard

https://emsesp.github.io/docs/
https://www.ebay.de/itm/276135335043?itmmeta=01HR2F3YJ1M1VCVKPF7J9TH1Y1&hash=item404af2d483:g:MEsAAOSwCHNlyNEv&itmprp=enc%3AAQAIAAAAwERhqJvri5SGyJVr7T%2FnbTN4iwikTfU9%2FRiXSW1%2FfOYJBuFkrFjFhEhfjweOM80PZNNcMDomE5iaj9d2T7h6Vq%2B4gDMSJn5ukotWrzKS8keC5K8y%2FGgVyJRCeONE9GJkQKHF7PjtoUd2mpDHYGiqufNG1zYZNaxFqJ6uyT9MkAkjpWyIsLWY6%2BB9jdhDyByAX04U89pnxKv8m3nPgjciKR%2BllT5sgM%2FFieV2jNnROEsVcVp6UN8%2BPp7U%2FXKdrk0jMQ%3D%3D%7Ctkp%3ABk9SR4zpj8_AYw

[Matthias M. (tubercel)]

Teurer aber fix und fertig inkl. der o.g. Software.

https://bbqkees-electronics.nl/

hat ich hier mir mit einer Buderus GB172 / RC35 an fhem in Betrieb.
Funktioniert problemlos. HT3 wird auch unterstützt.

Direktes steuern des Kessels GB172 funktioniert auch prinzipiell,
man arbeitet dann aber gegen das RC35 Steuergerät.

Das RC35 kann man auch beschreiben, z.B. Heizkurve ...
Aber nicht vollständig (Zeitpläne).

Das wird bei allen Kessel / Steurgerät Kombis ähnlich sein.

[Bernhard D. (boots)]

Hi
bei bbqkees liege ich mit Versand auch bei 42€, also nicht so weit weg. 
Aber ja, teurer.
Hiermit sollte ich aber auch mein CW100 überschreiben können. Ich muß 
die Heizung meines WW-Kreislauf darüber abschalten, wenn meine 
Röhrenkollektoren liefern und das WW die gewünschte Temperatur noch 
nicht erreicht hat.
Das Teil soll morgen kommen, dann werde ich es mal anschließen :-)

[Martin S. (matz666)]

Hallo an die Community.

Ich hatte am Donnerstag Abend einen direkten Blitzschlag.

Teile meiner Anlage und ich schätze auch mein Adapter für den Raspberry 
hat der Tot ereilt. Die Anlage läuft teilweise wieder und auch die 
Raspberry Dienst, nur leider kein Output.

Hat jemand einen Adapter übrig (natürlich gegen Entgelt) mit dem ich 
meinen HT3 Busgeräte auch steuern kann. Wenn ja bitte ein PM.

Bitte um Rückmeldung.

Und Danke schonmal.

LG

Matz.

[Stefan S. (kami)]

Hi,

sehe ich das richtig, dass dieses Board eine Alternative zum Heatronic 3 
Adapter für Junkers Thermen sein kann? Ist der Funktionsumfang der 
gleich oder mehr oder weniger?

Wie sieht das mit dem HT3 Bus aus, kann man auch irgendwie den 
HT3-Adapter mit einem ESP32 und der EMS-ESP32 Software nutzen?

Danke.

Gruß kami

[Bernhard D. (boots)]

Hallo zusammen,

das Board läuft problemlos an dem Bus. Es gibt auch einen Menüpunkt am 
CW100, Heizungkreislauf ausschalten. Muß nochmal nachschauen, wie der 
genau heisst.
Das kann das Board überschreiben, leider gibts mit dem Verkäufer keine 
weiteren Infos. Aber die Werte werden über MQTT ausgelsen und an eine DB 
verschickt.
durch einen Unfall bin ich aber da nicht weiter gekommen.

VG Bernhard

[Stefan S. (kami)]

Hi Bernhard,

vielen Dank.Kann man denn damit mehr machen als mit dem HT3 Adapter von 
hier?

Gruß kami

[Norbert S. (junky-zs)]

Martin S. schrieb:
> Teile meiner Anlage und ich schätze auch mein Adapter für den Raspberry
> hat der Tot ereilt.
Ich glaube nicht das der Adapter defekt ist, ist ja auch galvanisch von 
der Heizung getrennt und deine Heizung läuft ja wohl auch noch.
Es ist wahrscheinlich der Inhalt des Adapter-EEPROM's beeinflusst bzw. 
gelöscht worden.
Dies lässt sich aber wieder durch eine Neuinstallation der 
Adapter-Software korrigieren.
Dazu bitte die Hinweise und das Script auf der Projektseite ausführen:
URL:
https://github.com/norberts1/hometop_ht_transceiver?tab=readme-ov-file#softwareinstallation
Script(e):
prepare_pitiny_board.sh für den ht_pitiny - Adapter
prepare_piduino_board.sh für den ht_piduino - Adapter

Gruß Norbert

[Stefan S. (kami)]

Hey Norbert,

kann man deine Adapter denn auch mit dem EMS-ESP32 Modulen nutzen?

Würde mich nur mal interessieren, wie das mit der Software im Vergleich 
aussieht? Also ist die Hardware kompatibel?

Danke.

Gruß kami

[Norbert S. (junky-zs)]

Stefan S. schrieb:
> kann man deine Adapter denn auch mit dem EMS-ESP32 Modulen nutzen?

Ja, kann man.
Einzige Bedingung: Die Adapter müssen unterschiedliche Bus-Adressen 
haben wenn sie am gleichen Heizungsbus werkeln.
Per default ist dies auch so eingestellt:
Adapter  | Bus-Adresse (dez.)
------------------------------
ht_pitiny | 13 (Modem)
ht_piduino| 13 (Modem)
EMS-ESP32 | 11 (service-key)
(siehe Bild)
Kommandos an den Heizungsbus sind parallel auch möglich, beeinflussen 
sich aber natürlich gegenseitig.
Da der EMS-ESP recht geschwätzig am Heizungsbus ist und die 
ht_transceiver von Haus aus nur zuhören, kannst Du dir ja denken wer 
gewinnt -> Szenen einer Ehe :-)

> Würde mich nur mal interessieren, wie das mit der Software im Vergleich
> aussieht? Also ist die Hardware kompatibel?
Die Software des EMS-ESP ist weiterentwickelt und unterstützt auch 
Wärmepumpen soweit diese am EMSx-Bus hängen. Es werden neben Junkers 
auch Buderus-Geräte untersützt.
Die Hardware ist aus Sicht des Heizungsbus natürlich identisch.
Die ht_transceiver sind jedoch galvanisch vom Heizungsbus getrennt und 
die Dekodierung und Steuerung erfolgt auf dem Host (RPi, PC...) unter 
Python.
Die Darstellung der Daten (Historie) erfolgt direkt mit der 
Projekt-Software, Schnittstellen zu MQTT, sqlite, SPS und rrdtool sind 
vorhanden.
Gruß Norbert

[Martin S. (matz666)]

Norbert S. schrieb:
> Ich glaube nicht das der Adapter defekt ist, ist ja auch galvanisch von
> der Heizung getrennt und deine Heizung läuft ja wohl auch noch.

Hallo Norbert.
Ja nach Austausch der Platine am Heizgerät, den beiden IPM1 Modulen dem 
ISM2 und dem FB100 läuft die Heizung wieder. (einzig das FW200 hat 
überlebt)

Daher habe ich die Vermutung das auch die galvanische Trennung nur den 
Raspberry gerettet hat und nicht den ht_piduino.

Werde heute am Abend den Bus trennen und versuchen den EEPROM neu zu 
beschreiben.

lg

Martin

[Stefan S. (kami)]

Hey Norbert,

danke für die schnelle Antwort. Zu deiner Antwort auf Frage 1 das habe 
ich wohl etwas missverständlich ausgedrückt, kann man deine Hardware 
auch mit dem EMS-ESP32 nutzen, also nicht beide Geräte an dem Bus 
sondern den EMS-Bus mit deiner Hardware an einen ESP32 anschliessen und 
dann EMS-ESP32 nutzen?

Oder muss man sich das EMS-ESP32 Module kaufen.

Würde halt gerne relativ günstig mal umstellen und testen was mir besser 
gefällt.

Kann man per EMS-ESP32 an einer Junkers Therme mit Warmwasserspeicher 
mehr an Statusmeldungen sehen oder mehr steuern?

Danke.

Gruß Stefan

[Norbert S. (junky-zs)]

Stefan S. schrieb:
> ..., also nicht beide Geräte an dem Bus
> sondern den EMS-Bus mit deiner Hardware an einen ESP32 anschliessen und
> dann EMS-ESP32 nutzen?
Willst Du einen ht_transceiver als Hardware-Schnittstelle zum 
Heizungs-Bus nutzen und durch ein ESP32-Modul mit der EMS-ESP32 Software 
darauf steuern?

Ohne Hardware- und Software-Anpassungen geht dies erst mal nicht.
1. Die Schnittstelle zum/vom ht_transceiver ist seriell und es werden 
die Daten mit einem eigenen Protokoll übertragen.
2. Das EMS-ESP32 Modul will eine Hardware-Verbindung zum seriellen 
Heizungs-Bus haben, da ein Handshake auf dem Heizungs-Bus bedient werden 
muss.

> Kann man per EMS-ESP32 an einer Junkers Therme mit Warmwasserspeicher
> mehr an Statusmeldungen sehen oder mehr steuern?
Ja

> Oder muss man sich das EMS-ESP32 Module kaufen.
Ja, wenn mehr dann mehr.

Gruß Norbert

[Martin S. (matz666)]

Norbert S. schrieb:
> Martin S. schrieb:
>> Teile meiner Anlage und ich schätze auch mein Adapter für den Raspberry
>> hat der Tot ereilt.
> Ich glaube nicht das der Adapter defekt ist, ist ja auch galvanisch von
> der Heizung getrennt und deine Heizung läuft ja wohl auch noch.
> Es ist wahrscheinlich der Inhalt des Adapter-EEPROM's beeinflusst bzw.
> gelöscht worden.
> Dies lässt sich aber wieder durch eine Neuinstallation der
> Adapter-Software korrigieren.
> Dazu bitte die Hinweise und das Script auf der Projektseite ausführen:
> URL:
> 
https://github.com/norberts1/hometop_ht_transceiver?tab=readme-ov-file#softwareinstallation
> Script(e):
> prepare_pitiny_board.sh für den ht_pitiny - Adapter
> prepare_piduino_board.sh für den ht_piduino - Adapter
>
> Gruß Norbert

Hallo Norbert.

Leider sieht es doch nach Tot des Adapters aus.

Hier der Output des Script.
3. Write programm to flash

avrdude: Version 7.3-20240615 (41781bdd)
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is /usr/local/etc/avrdude.conf
         User configuration file is root.avrduderc
         User configuration file does not exist or is not a regular 
file, skipping
         additional configuration file is RPi_gpio.conf

         Using port            : /dev/parport0
         Using programmer      : linuxgpio
avrdude linuxgpio_sysfs_open() OS error: cannot export GPIO 8, already 
exported/busy?: Invalid argument
avrdude main() error: unable to open port /dev/parport0 for programmer 
linuxgpio

avrdude done.  Thank you.

  ------------------------------------------------------------------------ 
----------
  4. Write data to eeprom

avrdude: Version 7.3-20240615 (41781bdd)
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is /usr/local/etc/avrdude.conf
         User configuration file is root.avrduderc
         User configuration file does not exist or is not a regular 
file, skipping
         additional configuration file is RPi_gpio.conf

         Using port            : /dev/parport0
         Using programmer      : linuxgpio
avrdude linuxgpio_sysfs_open() OS error: cannot export GPIO 8, already 
exported/busy?: Invalid argument
avrdude main() error: unable to open port /dev/parport0 for programmer 
linuxgpio

avrdude done.  Thank you.

preparing of 'ht_pitiny-board' done

[Stefan S. (kami)]

Hey Norbert,

danke für die Antwort, dann werde ich mal im Vergleich den EMS-ESP32 
probieren.

Danke und schönen Abend noch.

Gruß Stefan

[Norbert S. (junky-zs)]

Martin S. schrieb:
> avrdude main() error: unable to open port /dev/parport0 for programmer
> linuxgpio
Der Aufruf von linuxgpio und Nutzung des Ports zur Programmierung 
funktioniert nicht mehr. Deshalb kann auch der ht_transceiver nicht neu 
programmiert werden.
Es gibt wohl Änderungen/Probleme bei der Nutzung der RaspberryPI-GPIO's, 
siehe auch Meldungen: https://github.com/avrdudes/avrdude/issues/1708.
Muss ich mit meinem RPi4 und Adapter überprüfen.

Welche RPi-Version nutzt Du?

> Leider sieht es doch nach Tot des Adapters aus.
Dies glaube ich weiterhin nicht, aber dies hilft Dir auch wenig.
Schicke Dir eine PM, werden da eine Lösung finden.

Gruß Norbert

[Norbert S. (junky-zs)]

Martin S. schrieb:
> Leider sieht es doch nach Tot des Adapters aus.
Die Programmierung war nicht korrekt. Siehe folgenden Kommentar.
>
> Hier der Output des Script.
> 3. Write programm to flash
>
> avrdude: Version 7.3-20240615 (41781bdd)
>          Copyright the AVRDUDE authors;
>          see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
>
>          System wide configuration file is /usr/local/etc/avrdude.conf
>          User configuration file is root.avrduderc
>          User configuration file does not exist or is not a regular
> file, skipping
>          additional configuration file is RPi_gpio.conf
>
>          Using port            : /dev/parport0
>          Using programmer      : linuxgpio
> avrdude linuxgpio_sysfs_open() OS error: cannot export GPIO 8, already
> exported/busy?: Invalid argument
> avrdude main() error: unable to open port /dev/parport0 for programmer
> linuxgpio
>
> avrdude done.  Thank you.
> ....

Für die Programmierung der ht_transceiver mit dem RPi ist es zwingend 
erforderlich das SPI-Interface auf dem RPi zu deaktivieren.
Dies wird auch so im Installations-Script gefordert.
Die obige Meldung zeigt, das das SPI-Interface noch aktiv ist und 
deshalb der ht_transceiver nicht programiert werden konnte.
Siehe Bilder für die erforderlichen Aktionen.

Gruß Norbert