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
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.
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
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?
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ß
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
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
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
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
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
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
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
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!
Hallo Jo, ich hätte Interesse an einem Pitiny Adapter. Wie können wir denn da zusammenkommen? Grüße Patrick
Hallo Patrick Habe mal eine temporäre Adresse erstellt: swhawking@aol.com Schreibe die Adresse an und ich werde mich mit meiner echten Adresse melden. Denke wir werden uns schon einig! Gruss Jo
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
Hat jemand noch ein piduino oder pitiny adapter über was er nimmer braucht
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
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
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
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
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
Hallo Da Ferdinand den Adapter nicht gebrauchen kann, ist er wieder zu haben.
Ich hätte Interesse am Pitiniy Adapter :-)
Zur Info: Beide Pitiny-Adapter sind nun verkauft. Viele Grüße und viel Bastelspass Jo
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
Angehängte Dateien:
-
ZSR18_Bustyp.png
58 KB
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
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.
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.
:
Bearbeitet durch User
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
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
Angehängte Dateien:
-
IMG_0541.jpg
840 KB -
IMG_0541.jpg
230 KB
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
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?
Angehängte Dateien:
-
image.jpg
220 KB
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.
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
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
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
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
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
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
:
Bearbeitet durch User
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
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
Angehängte Dateien:
-
Fkt_LEDs_ht_transceiver.png
21 KB -
ht_transceiver_RXdata.png
2,6 KB
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
Hi Norbert, alles gut inzwischen. Lag an einer losen Verbindung. Jetzt rennt alles wieder. Danke. Gruß Stefan
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
Angehängte Dateien:
-
USB_Seriel_Kabel.png
69 KB
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
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
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
:
Bearbeitet durch User
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
Braucht noch jemand einen ht_pitiny Adapter? Ich habe einen übrig, finde keine Zeit ihn zu integrieren. Bitte PN. Gruß
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
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
:
Bearbeitet durch User
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
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
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
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
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
:
Bearbeitet durch User
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
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
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
Moin zusammen, kann man einen Junkers FR 50 Raumregler zusammen am Bus mit dem HT3 und einem RPi verwenden? Vielen Dank. Gruß kami
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
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
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
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
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
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
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 $
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
:
Bearbeitet durch User
Angehängte Dateien:
-
Unbenannt.png
95 KB
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
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
:
Bearbeitet durch User
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
Angehängte Dateien:
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
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
Angehängte Dateien:
-
ht_running_moduls.png
22 KB
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
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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
Hi, habe es inzwischen durch eine Erweiterung der Ccollgate.py ergänzt und klappt super. Trotzdem Danke. Gruß kami
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
:
Bearbeitet durch User
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
Angehängte Dateien:
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
:
Bearbeitet durch User
Angehängte Dateien:
-
Uebersicht_Heizung.png
130 KB -
IMG_20181224_061159366.jpg
240 KB -
IMG_20181224_061210500.jpg
220 KB
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
Angehängte Dateien:
-
HT3_Heizgeraet_plott.png
54 KB
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
:
Bearbeitet durch User
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
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
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
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
:
Bearbeitet durch User
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
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
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
:
Bearbeitet durch User
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
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
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
:
Bearbeitet durch User
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
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
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
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
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
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.
1 | ./ht_netclient.py -tc2 22.0 -hc 2 |
2 | Is controller-type any of CTxyz/CRxyz/CWxyz y/n ?y |
3 | couldn't connect to server |
4 | Traceback (most recent call last): |
5 | File "./ht_netclient.py", line 239, in <module> |
6 | main(configfile, ems_bus) |
7 | File "./ht_netclient.py", line 106, in main |
8 | client= ht_proxy_if.cht_socket_client(configfile, devicetype = ht_proxy_if.DT_MODEM) |
9 | File "lib/ht_proxy_if.py", line 857, in __init__ |
10 | self._socket.connect((self._ip_address, self._port_number)) |
11 | ConnectionRefusedError: [Errno 111] Connection refused |
Im ht_proxy.log:
1 | 26.03.2019 09:04:35 INFO: Client-ID:2; ('127.0.0.1', 39742) connected
|
2 | 26.03.2019 09:04:35 INFO: Server :('0.0.0.0', 8088)
|
3 | 26.03.2019 09:04:35 INFO: Client-ID:2; register(); got devicetype:MODEM |
4 | 26.03.2019 09:04:35 INFO: csocketsendThread(); socket.send thread start |
5 | 26.03.2019 09:04:35 INFO: Client-ID:2; added; number of clients:2 |
6 | 26.03.2019 09:04:35 INFO: Client-ID:2; cht_RequestHandler(); socket.receive thread start |
7 | 26.03.2019 09:04:35 INFO: Client-ID:1;cportwrite();couldn't read from queue |
8 | 26.03.2019 09:04:45 INFO: Client-ID:2; ('127.0.0.1', 39742) disconnected
|
9 | 26.03.2019 09:04:45 INFO: Client-ID:2; removed; number of clients:1 |
10 | 26.03.2019 09:04:45 CRITICAL: csocketsendThread();Error on socket.send |
11 | 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
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
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
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
Hallo Norbert, danke für deine rasche Antwort. Neueste Softwareversion von github. Im Anhang gibt es eine log-Datei. Besten Dank Grunz.
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
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
Angehängte Dateien:
-
HT3_Heizgeraet.png
46 KB -
HT3_Heizkreis1.png
29 KB
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
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
:
Bearbeitet durch User
Angehängte Dateien:
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)
:
Bearbeitet durch User
Das Abschalten von Sqlite hat doch geholfen. Auslastung ist jetzt immer noch zwischen 1,6-1,9 aber Aufzeichnung geht wieder.
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
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" :-)
:
Bearbeitet durch User
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
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
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
:
Bearbeitet durch User
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
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 serial-getty@ttyAMA0.service $ sudo systemctl disable serial-getty@ttyAMA0.service 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
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
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
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
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
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
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
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
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
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
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
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
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
Angehängte Dateien:
-
ht_MQTT_Test_docpart.png
19 KB -
ht_MQTT_cmds_python.png
56 KB
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
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
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 ?
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
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
Angehängte Dateien:
-
ht_proxy_system_cfg.png
91 KB -
HT_KonfigurationsOptionen.png
76 KB
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:
1 | <proxy_server> |
2 | <serveraddress></serveraddress> |
3 | <servername></servername> |
4 | <portnumber>8088</portnumber> |
5 | <logfilepath>./var/log/ht_proxy.log</logfilepath> |
6 | <ht_transceiver_if devicename="RX"> |
7 | <parameter> |
8 | <serialdevice>/dev/ttyAMA0</serialdevice> |
9 | <baudrate>19200</baudrate> |
10 | <config>"8N1"</config> <!-- only 8N1 available --> |
11 | </parameter> |
12 | <devicetype>RX</devicetype> |
13 | </ht_transceiver_if> |
14 | <ht_transceiver_if devicename="MODEM"> |
15 | <parameter> |
16 | <serialdevice>/dev/ttyAMA0</serialdevice> |
17 | <baudrate>19200</baudrate> |
18 | <config>"8N1"</config> <!-- only 8N1 available --> |
19 | </parameter> |
20 | <devicetype>MODEM</devicetype> |
21 | <deviceaddress_hex>0D</deviceaddress_hex> <!-- currently unused value --> |
22 | </ht_transceiver_if> |
23 | </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
:
Bearbeitet durch User
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
Angehängte Dateien:
-
HA_DefaultView_home.png
120 KB
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
1 | <mqtt_client> |
2 | ....
|
3 | <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
:
Bearbeitet durch User
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
VIELEN DANK für Eure Hilfe, werde heute Abend gleich probieren!!
Angehängte Dateien:
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
Angehängte Dateien:
-
InfluxDB_usedPort.png
13 KB
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
1 | from http.server import HTTPServer, CGIHTTPRequestHandler |
2 | serveradresse =("", 48086) |
3 | server=HTTPServer(serveradresse, CGIHTTPRequestHandler) |
4 | server.serve_forever() |
Aktionen: Daemon stoppen und neu starten und die Browser-Abfragen mit der neuen Port-Nummer durchführen. Gruß Norbert
Beitrag #6945393 wurde vom Autor gelöscht.
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
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ß
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
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
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
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..
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
Eine Zusatzfrage habe ich noch: Was ist einfacher umzusetzen? pitiny oder piduino?
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
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
:
Bearbeitet durch User
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
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?!
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
:
Bearbeitet durch User
Angehängte Dateien:
-
ht_adapter.jpg
60 KB
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?
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. 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)
Angehängte Dateien:
-
20220911_210231.jpg
230 KB -
HT-Adapter.png
130 KB
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?
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
Angehängte Dateien:
-
HT-Adapter-Sch.jpg
380 KB -
ht_adapter.jpg
60 KB
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.
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
:
Bearbeitet durch User
Ich benutze KiCAD 6.0. Passt für mich optimal. Gegenfrage: Warum reicht denn nicht die LED gegen Verpolung. Die sperrt doch auch, oder?
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
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
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
Angehängte Dateien:
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
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
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
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
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
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
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
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.
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
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
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
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.
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 :-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.