Hallo Henrik, Henrik schrieb: > was bedeuten die einzelnen Stati in der Variable "hc1_operationstatus"? > 3 steht für? Heizen? was gibt es dort noch? Gibt es eine Mappingtabelle > oder ähnliches? Diese Mapping-Funktion (GetStrOperationStatus) ist enthalten im SW-Modul: lib/gui_worker.py. (Anzeige im HT3_Analyser -> ' Betriebsstatus') Fuer 'Fxyz' - Regler: ivalue rtnstr 0 "---" 1 "Manuell" 2 "Auto" 3 "Urlaub" 4/5 "E-Trocknung" Fuer 'Cxyz' - Regler: ivalue rtnstr 0 "Off" 1 "Summer" 2 "Manual" 3 "Comfort" 4 "Eco" ---------------- GetStrOperationNiveau() (Anzeige im HT3_Analyser -> ' Temperatur-Niveau') Fuer 'Fxyz' - Regler: ivalue rtnstr 0 "---" 1 "Frost" 2 "Sparen" 3 "Heizen" Fuer 'Cxyz' - Regler: ivalue rtnstr 1 "Eco" 2 "Comfort1" 3 "Comfort2" 4 "Comfort3" =============================== Hallo Rob, Rob schrieb: > mal ne Frage an alle, hättet Ihr auch ein Modul von AK-Nord > (https://www.ak-nord.de/) genommen um die Heizungs-Datenerfassung über > Ethernet zu realisieren oder seid Ihr alle der Meinung doch lieber ein > RaspberryPI?? Es muss nicht unbedingt ein RaspPi sein, die vorgestellten ht-Adapter funktionieren auch mit einem UART-USB Adapter. Die ht-Adapter haben jedoch noch zusätzlich eine galvanische Trennung zwischen dem Heizung-Bus und der Aussenwelt und die aktiven Adapter (ht_pitiny/ht_piduino) können kontrolliert Daten zur Heizung senden. Somit funktionieren diese als Gateway, welches die Module von ak-nord nicht können. Ausserdem sind die Module von ak-nord zu teuer. Gruß Norbert
Hi! Hat schon einer Erfahrungen mit der Installation unter Raspbian Buster gesammelt? Wie löse ich zB sudo insserv httpd? insserv fehlt, muss installiert werden. Bekomme beim Installieren: Setting up insserv (1.18.0-2) ... insserv: FATAL: service mountkernfs has to exists for service udev insserv: FATAL: service urandom has to exists for service networking insserv: FATAL: service mountdevsubfs has to exists for service hwclock insserv: FATAL: service udev is missed in the runlevels 2 3 4 5 to use service raspi-config insserv: exiting now! Hat einer eine Lösung? Danke Andi
Hi! Ich beantwortet meine Frage selber: Insserv scripts mit Buster? Es geht, sogar ganz einfach: Copy script in /etc/init.d sudo chmod +x /etc/init.d/your_script sudo systemctl enable your_script Nach dem Neustart werden unsere Scripts dann automatisch ausgeführt. Gestern selbst auf Buster erfolgreich installiert. Problem gelöst :) Cheers Andi
Hallo Andreas, Andreas Wülbern schrieb: > Insserv scripts mit Buster? Es geht, sogar ganz einfach:... Danke für Deine Bemühungen. Kommt bei Gelegenheit mit in die Doku. PS: Eins ist uns gewiss: Linux-Software altert auch, aber es vergilbt fast nichts schneller als Doku, eventuell sogar noch gedruckt auf Papier. Deshalb wird uns die Arbeit nicht ausgehen und bei uns kommt somit keine Langeweile auf:-). Gruß Norbert
Ich muss mal wieder Norbert einen Dank aussprechen, die Software läuft bei mir seit Jahren ohne Probleme. In einem Anfall von Spieltrieb habe ich jetzt auf die nächste Version mit collgate aktualisiert und lasse jetzt alle Daten über den MQTT-Kanal in meine kürzlich installierte influxDB wandern. Ich bin noch am Basteln des Grafana-Dashboards, anbei der aktuelle Stand. Sobald ich zufrieden bin, werde ich das Dashboard auch bei Grafana verfügbar machen.
Hallo Mario, sehr schön! Ich habe auch Grafana bei mir laufen, habe aber bisher meine Heizung dort noch nicht eingebunden. Das sollte später passieren. Von daher nehme ich dein Dashboard natürlich sehr gerne. Spart mir jede Menge an Arbeit :D Ich würde aber auch schon mal einen Zwischenstand bei mir installieren ;) Danke und Gruß Andi
Hi Andi, anbei mal der aktuelle Stand, wie gesagt, ich importiere über MQTT/Telegraf und habe an den topic-Namen nix geändert. Hier ist nur ein HK plus Solar in Betrieb, mehr habe ich also auch nicht eingebunden. Kann aber auch die Telegraf-Konfig dann nochmal posten ... Die Solarertragswerte sind nicht 100% identisch und bei den Pumpenläufen bin ich mir auch nicht sicher, ob er das zuverlässig erkennt.
Hallo Die Heizperiode ist angebrochen und leider hat meines Raspi SD das Zeitliche gesegnet. Ich habe das System neu aufgesetzt und leider kann ich nicht so genau sagen wo das eigentliche Problem liegt. Ich denke ich habe alle Packete eingespielt. und über raspi-config die login shell über serial deaktiviert. Ich starte den proxy und den ht_collgate. Keine Fehler, aber es werden offebar auch keine Daten gelesen/geschrieben. Das Debug log ist ziemlich leer. Den einzigen Fehler den ich provozieren kann ist, wenn ich den MQTT client aktiviere: Dann bekomme ich beim start von ht_collateccollgate().run();Error;could not start 'mqtt-interface' with file:'./etc/config/HT3_db_cfg.xml'
im ht_client_rx.log steht etwas das mich wundert: 12.10.2019 09:41:07 INFO: ---------------------- 12.10.2019 09:41:07 INFO: cht_socket_client init 12.10.2019 09:41:07 INFO: connected to server:'localhost';port:'8088' 12.10.2019 09:41:07 INFO: logfile:'./var/log/ht_client_rx.log' 12.10.2019 09:41:07 INFO: Client-ID:1; registered with devicetype:'RX' Ich nutze den pitiny und ich denke ich sollte im MODEM modus arbeiten. Offenbar habe ich da wohl noch was nicht richtig konfiguriert
Vermutlich ist es bei dir was anderes, aber ich habe neulich ein Update von Stretch auf Buster gemacht und danach die gleiche Fehlermeldung. Irgendein Python mqtt Modul wurde beim Upgrade Event und ich musste es mittels pip wieder nachinstallieren. Im Übrigen kann ich jedem nur Raspibackup empfehlen: https://www.linux-tips-and-tricks.de/de/raspibackup/ Habe das hier schon so oft benötigt ....
> Irgendein Python mqtt Modul wurde beim Upgrade Event und ich musste es > mittels pip wieder nachinstallieren. Das kann ja eeigentlich nur Paho sein... das hatte ich installiert mit pip3 install paho-mqtt. ABER nach ein wenig debugging hat sich genau das als falsch herausgestellt. Ich habe es nochmal installiert und jetzt gibt es den Fehler nicht mehr. Leider bekomme ich immer noch keine Daten von HZ Bus.
Hallo Bernd, da Du einen ht_pitiny-Adapter hast, kannst Du dessen LED-Anzeigen kontrollieren. Grüne LED muss flackern -> Signal vom Heizungsbus vorhanden. Rote LED muss aufblitzen -> Adapter antwortet dem Heizungsbus auf Anfragen. -->> Wenn soweit OK, dann bitte die Konfiguration kontrollieren! Die Baud-Rate für den ht_pitiny-Adapter muss auf 19200 stehen! Konfig-File: ht-proxy_cfg.xml Bernd B. schrieb: > 12.10.2019 09:41:07 INFO: Client-ID:1; registered with devicetype:'RX' > Ich nutze den pitiny und ich denke ich sollte im MODEM modus arbeiten. Ist OK auch für den ht_pitiny-Adapter. Ist nicht der Grund für die fehlenden Daten vom Bus. Dies zeigt aber, das der ht_proxy.server korrekt arbeitet. Ob dieser allerdings Daten vom ht_pitiny-Adapter erhält kannst Du prüfen mit Browseraufruf: http://<IP-Adresse des RPi>:8088 Soll-Ausgabe von Sequenzen wie: #HR�.... Zum Test kannst Du auch die python-Module (ht_proxy.py, ht_collgate.py) ohne die Start-scripte von Hand aufrufen, dann bekommst Du im Fehlerfall mehr Informationen. Ich nehme mal an Du benutzt den aktuellen SW-Stand (Rev. 0.3.1) von github und Linux 'stretch' oder 'buster'? Gruss Norbert
Hallo Norbert Ich habe des Rätsels Lösung gefunden. spi_clk_off.py hat geholfen. Ist vielleicht auch für andere interessant. Ich habe einen Raspberry Pi Model B Rev 2 und das aktuelle (oct. 19) Image von Raspbian (minimal) in Verwendung.
Hallo Bernd, prima das es wieder läuft! Bernd B. schrieb: > Ich habe des Rätsels Lösung gefunden. spi_clk_off.py hat geholfen. Dieses Script wird normalerweise von den Start-Scripten: 'ht_proxy' und 'ht_collgate' beim Systemboot aufgerufen: ... $APPLICATION_FOLDER/etc/sysconfig/spi_clk_off.py ... Nur wenn man einen Daemon von Hand startet, ist dieser manuelle Aufruf von 'spi_clk_off.py' erforderlich. Gruß Norbert
:
Bearbeitet durch User
:D ja das habe ich dann später bemerkt. Aber Du weist ja wie es läuft... erst mal versucht man es "zu Fuss" bevor man das ganze automatisch laufen lässt. Ich habe noch eine Frage: Ich steuere die Heizung via MQTT-> Für den Heizmodus gibt es ja das Topic: hc1_Tniveau. Das kann man mit den Werten "auto, frost, sparen, heizen" in den entsprechenden Modus setzen. Aber wie kann man erkennen, ob man aktuell im "Auto" Modus ist oder "manuell" auf einem der Modi sitzt? hc1_Tniveau gibt einem soweit ich das sehe ja nur (1, 2, 3) an. Tolles Projekt Norbert, noch mal vielen Dank für die harte Areit.
Hallo Bernd, Bernd B. schrieb: > Aber wie kann man erkennen, ob man aktuell im "Auto" Modus ist oder > "manuell" auf einem der Modi sitzt? Bei aktiviertem MQTT erhält man ja alle Informationen beim Start des MQTT-Clients (sofern der Broker entsprechend eingestellt ist) und danach jeweils wenn eine Änderung für ein Item aufgetreten ist. Allerdings gibt es z.Zeit noch keine Abfrage-Möglichkeit eines Wertes über die MQTT-Schnittstelle. Ich denke dies wäre eine nützliche Erweiterung dieser Schnittstelle. In Analogie zum 'Set'-Befehl dann eben einen 'Get'-Befehl für die Items. Diese Abfrage-Möglichkeit gibt es allerdings schon mit dem SPS-Interface. Diese Schnittstelle muss aber erst aktiviert werden, da default deaktiv. Konfigurations-File 'collgate_cfg.xml' anpassen und dort SPS auf 'on' stellen. Danach den ht_collgate-daemon neu starten. Über dies Schnittstelle können dann Werte abgefragt werden. Details siehe auch Doku im Kapitel 2.3.3 SPS ht_Server. Das Testprogramm ~/HT3/sw/test/sps_testclient.py kann als Grundlage für solche Abfragen dienen (siehe Ausgaben in den Bildern). Allerdings werden die Werte nicht als Strings sondern wie in den Telegrammen gesendet zurückgegeben. Die Interpretation ist dann separat noch nötig z.B.: send -> :hc1_operationstatus response <- :hc1_operationstatus:=1 Die '1' steht dann für aktuellen Betriebsstatus:= 'Manuell' bzw '2' := 'Auto'. (Diese Werte gelten allerdings nur für die Fxyz-Regler-Serie) Gruß Norbert
:
Bearbeitet durch User
Hallo, beeindruckende Software. Und ich habe mich beim Aufbauen des Adapters schon auf die reichhaltige Datenanzeige gefreut. Bisher nutze ich eigene Sensoren, die per MySensors an Domoticz gesendet werden. Da habe ich aber bisher nur wenige Sensoren/Parameter verfügbar. Leider werden im HT3_Analyzer nur wenige Daten angezeigt. Dafür aber einige unbekannte Nachrichten. Zwei Screenshots sind angehängt. Exemplarisch habe ich noch ein putty.log der seriellen Schnittstelle und die Datei Heizung.log angehängt. In Heizung.log sind aufgezeichnete Daten im Klartext enthalten. Die erste Spalte sind Mikrosekunden Wartezeit zwischen den empfangenen Bytes. Die zweite Spalte die Anzahl Bytes pro read() (immer 1;) Die ...-Zeilen sind Wartezeiten in 2000 Mikrosekunden pro '.', wenn gerade keine Bytes ankommen. Damit hatte ich gehofft, die Genzen von Messages erkennen zu können. Z.B: bei Zeile 407-437 funktioniert das ganz gut. An anderen Stellen ist es eher verwirrend. Meine Anlage: Kessel ZSBE 28-3 FW200 (JF12.10) IPM2 (JF20.06) ISM2 (JF23.02) Heizkreis1 mit externem Mischer Kombinierter Solar- und Warmwasserspeicher Hydraulische Weiche Nun meine Fragen: hat es ggf eine einfache Ursache, warum die Messages im HT3_Analyser nicht angezeigt werden, eine Konfiguration o.ä.? Oder verwendet meine Anlage Messages, die der HT3_Analyzer nicht unterstützt? Schon mal vielen Dank für die Hilfe. Gruß, rooky
_rooky_ schrieb: > Und ich habe mich beim Aufbauen des Adapters schon auf > die reichhaltige Datenanzeige gefreut. Welchen der Adapter-Typen hast Du gebaut? Wichtig sind die richtigen Optokoppler, da nicht alle die erforderlichen Daten haben(Flankensteilheit, Ansprechstrom etc.) > In Heizung.log sind aufgezeichnete Daten im Klartext enthalten. Dieses Logfile zeigt einige seltsame Sequenzen, die in dieser Form nicht gesendet werden, z.B.: 211147 1 22 1053 1 00 . 2509 1 A2 1250 1 A2 <=== Fehler, ist doppelt 1200 1 00 1146 1 00 ........... 23963 1 0E 1064 1 00 ............... 30076 1 30 1061 1 00 ... 7084 1 B0 1236 1 B0 <=== Fehler, ist doppelt 1213 1 00 1134 1 00 Wie bzw. womit wurde dieses Logfile erstellt? Sicher nicht mit dem vorhandenen Tool: ht_binlogclient.py. Es sieht nach Auslesefehlern der UART-RX Werte aus oder dein Adapter hat Probleme mit den Signalen auf dem Bus. > Nun meine Fragen: hat es ggf eine einfache Ursache, warum die Messages > im HT3_Analyser nicht angezeigt werden, Wenn die serielle Schnittstelle (Baudrate etc.) richtig eingestellt ist würde ich noch als Ursache deinen Adapter vermuten. > Oder verwendet meine Anlage Messages, die der HT3_Analyzer nicht unterstützt? Die Messages Deiner Anlagen-Module werden dekodiert und erkannt wenn die Sequenzen richtig sind (CRC muss korrekt sein). Aus den aufgezeichneten Telegrammen kann ich folgendes entnehmen: Modul IPM2 steuert 1. den Heizkreis1 (Device-ID 20hex.) und ist 2. für die Steuerung der Warmwassererzeugung zuständig (Device-ID 22hex.) Dein Heizgerät ist eingestellt auf 'Interne Warmwassererzeugung deaktiv'. Modul ISM2 kontrolliert 1. Solar-Kollektor (Device-ID 30hex.) und 2. wohl auch die Warmwasser-Erzeugung. Mein Tipp, deinen Adapter noch einmal checken und eventuell ein Logfile erzeugen nur mit dem Aufruf: cd ~/HT3/sw ./ht_binlogclient.py <irgendeinenlogfilenamen.log> Das Logfile kann ich dann checken wenn Du es hier veröffentlichst. Gruß Norbert
Hallo Norbert, vielen Dank für die schnelle Antwort und Analyse. Ich habe einen HT3-Miniadapter mit H11L1M aufgebaut. Ja, die A2 A2, B0 B0 und 90 90 sind mir auch aufgefallen. Das Textlog habe ich mit einem eigenen C++ Programm erstellt. 'binlogclient.log' habe ich angehängt. Dort sehe ich auch die Doppelbytes. Ich habe in der Zwischenzeit hp_discode.py mit einigen Traces bestückt, um die Dekodierung besser verstehen zu können. Das Logfile dazu habe ich auch angehängt ('ht_analyser.log'). Dort sieht es zumindest so aus, als wenn die Doppelbytes nicht ankommen. Einen Screenshot des HT3_Analyzer derselben Session habe ich auch angehängt. Die HT3_db_cfg.xml ist auch angehängt. Gruß rooky
Hallo Norbert, ich habe jetzt einen ATmega328 zwischen den HT3 Miniadapter und den Raspberry Pi geschaltet. Dieser erkennt BREAK (Frameerror mit Empfangsbyte=0x00, Register UCSRnA, Bit FEn). Damit ermittle ich das Message-Ende. Tatsächlich kommen die Nachrichten mit Source A0, A2, B0, 90 mit duplizierten Bytes an. Source 88 dagegen kommt normal. Ich habe probeweise ht_discode.py so angepasst, dass die duplizierten Bytes entfernt werden (if ...: del self._rawdata[:message_size:2]) --> diese Nachrichten werden dann tatsächlich erkannt und dekodiert! Im Anhang ein Screenshot. Es gibt noch einen Fehler in meiner Nachrichtenaufbereitung, der gelegentlich eine fehlerhafte Nahricht durchlässt. Daran muss ich noch arbeiten. Die Doppelbytes scheinen so auf dem Bus anzuliegen, da ja am gleichen Draht für 88 keine Doppelbytes ankommen, aber für A0, A2, B0, 90 schon. Ich habe den HT3 Miniadapter am freien Busausgang des ISM2 angeklemmt. Ich könnte mal probieren an anderer Stelle (HG, FW200) anzuklemmen, ob da was anderes passiert. Ggf. werde ich noch mal den Bus mit einem Speicheroszi aufzeichnen und so bestätigen - oder auch nicht -, dass es die Doppelbytes tatsächlich gibt. Wie auch immer sich das alles erklären lässt, Im HT3_Analyzer sind jetzt deutlich mehr Daten zu sehen ;) Gruß, rooky
Hallo rooky,
prima das Du eine Lösung für das Problem gefunden hast.
> Ich habe den HT3 Miniadapter am freien Busausgang des ISM2 angeklemmt.
Schliesse den ht_Adapter direkt am Bus an, also parallel zu den Modulen
an die Klemmen (BB bzw. ESM2).
Dabei ist es egal welches Modul Du nimmst, die hängen alle parallel am
gleichen Bus. Du kannst also auch das ISM2 nehmen.
Offensichtlich wird am zweiten Anschluss des ISM2 das Bus-Signal
modifiziert ausgegeben und ist somit ungeeignet für die korrekte
Dekodierung.
Gruß Norbert
Hallo Nobert, ich habe auch seit kurzem nach deiner Anleitung auch deinen super Datenlogger am Laufen. Primär um die Einstellungen der Anblage nach einer Analysephase ggf. zu optimieren. Leider stimmt irgendetwas mit den WW-Daten nicht, es kommt nur sehr selten ein Wert und wenn, dann sind die Temparaturwerte im Speicher viel zu gering. Vor allem die Warmwasserspeichertemperatur interessiert. Anlagedaten: ------------------ - ZSB 24-4 C 23 - FW200 Regler - IPM1: Hydraulische Weiche (HW), Speicherladepumpe, Speichertemperaturfühler (SP) - IPM2: Heizkreis 1 Radiatoren, Heizkreis 2 Fußbodenheizung - ISM2: Warmwasser Schichtspeicher, Solarkreispumpe, Ventil Rücklaufanhebung (DWU1), NTCxxx - Raspi3 mit HT3-Miniadapter, hometop 0.3.3 Vielen Dank im Voraus Gruß, Fred
Fred schrieb: > Leider stimmt irgendetwas mit den WW-Daten nicht... Dank des Logfiles und Deiner Beschreibung konnte ich das Problem nachvollziehen und auch eine Lösung finden. Grund ist eine in Deinem System verwendete DeviceID:0x41, die von einem der IPM2 Module (für Warmwasser) verwendet wird. Damit die Dekodierung auch dafür funktioniert ist eine kleine Anpassung in der Software nötig. Diese kannst Du zum Test bei Deiner Software selber durchführen wie folgt: Modul : ~/HT3/sw/lib/ht_discode.py Zeile : 3224 ff Aktion: 0x41 im array:'deviceaddress_white_list[]' hinzufügen.
1 | # 2021-02-12: 0x41 added in deviceaddress_white_list[]
|
2 | deviceaddress_white_list = [ |
3 | 0x08, 0x0a, 0x0b, 0x0c, 0x0d, 0x10, 0x18, 0x19, 0x1a, |
4 | 0x20, 0x21, 0x22, 0x23, 0x28, 0x29, |
5 | 0x30, 0x31, 0x41, 0x48] |
Damit ist dann die Dekodierung auch für WW möglich (siehe Bilder) Diese Änderung und die Auswirkungen muss ich im Detail noch einmal kontrollieren und werde dann ein neues Release auf github veröffentlichen. Für mich sind diese IPM2 Module und deren Einstellungen sehr wichtig, da ich in meiner Anlage die Module nicht habe. Deshalb ist Dein Logfile für mich Gold wert! Welche Schalter-Stellungen haben diese IPM1/IPM2 Module bei Dir im System? Gruß Norbert
Hallo Norbert, vielen Dank für deinen Tip! Ich habe die Änderungen wie beschrieben durchgeführt und es sieht jetzt viel besser aus (siehe HT4_WW_Graph.png). > Für mich sind diese IPM2 Module und deren Einstellungen sehr wichtig, da > ich in meiner Anlage die Module nicht habe. Deshalb ist Dein Logfile für > mich Gold wert! > Welche Schalter-Stellungen haben diese IPM1/IPM2 Module bei Dir im > System? Freut mich :-) Falls du noch mehr brauchst gib bescheid. --------------------------------- IPM 1 - WW Speicherladekreis --------------------------------- Speicherladekreis nach der hydraulischen Weiche muss Kodierung 3 oder höher erhalten. In meinem Fall ist die Kodierung vom Heizungsinstallateur auf **10** (Device ID 0x41) gesetzt worden. **Anschlüsse:** - VF = Gemeinsamer Vorlauffühler der Hydraulische Weiche (HW) - SF1 = Speichertemperaturfühler SF (NTC) des Warmwasserspeichers - P1 = Speicherladepumpe LP --------------------------------- IPM 2 - Modul für zwei Heizkreise --------------------------------- - Heizkreis 1 (HK1) = Kodierschalter I auf **1** (Device ID 0x20) - Heizkreis 2 (HK2) = Kodierschalter II auf **2** (Device ID 0x21) **Anschlüsse:** - MF2 = Vorlauftemperaturfühler gemischter Heizkreis (Fußbodenheizung HK2) - P1 = Heizkreispumpe (Heizkreis HK1, Radiatoren) - M2 = Mischerstellmotor Heizkreis HK2 (Fußbodenheizung) - P2 = Heizkreispumpe (Heizkreis HK2, Fußbodenheizung) - TB2 = Temperaturwächter HK2 (Fußbodenheizung) Meine Anlage scheint doch etwas spezieller zu sein. Im HT_Analyzer sehe ich noch einige Telegramme mit Fragezeichen dargestellt (siehe HT4_Unknown_Telegrams.png), es scheint noch nicht alles zu passen, ich versuch gerade noch deinen Code besser zu verstehen um auch selbst analysieren zu können. Gruß Fred
Fred schrieb: > Meine Anlage scheint doch etwas spezieller zu sein. Im HT_Analyzer sehe > ich noch einige Telegramme mit Fragezeichen dargestellt... Deine Anlage ist zwar speziell, das Problem liegt jedoch mehr in der Art wie Bosch (Junkers/Buderus) die Telegramme auf dem seriellen Bus senden. Besonders das Ende-Kennzeichen eines Telegramms wird durch das BREAK-Signal angezeigt (mehr als 10Bit Bus auf low). Dieses Signal wird leider vom seriellen Treiber in eine Null übersetzt und somit kann man das Ende eines Telegrams nicht mehr eindeutig erkennen. Bei langen Telegrammen ist eine CRC am Ende enthalten. Diese kann man prüfen und somit das Telegramm dekodieren. Leider gibt es viel häufiger kurze Telegramme die keine CRC enthalten. Insbesondere das Polling der Steuerelektronik im Heizgerät (Master) und die kurzen Antworten der Module (Clients) führt oft zu Fehldecodierungen. z.B. aus Deinem Bild:
1 | C1 00 14 00 09 00 89 00 15 00 09 00 89 00 09 00 89 00 ... |
2 | PA Br DP Br DP Br PA Br DP Br DP Br PA Br DP Br PA Br ... |
3 | PA:= Polling-Antwort des angesprochenen Moduls (hier immer keine Daten) |
4 | DP:= DevicePolling von Steuerelektronik |
5 | Br:= Breaksignal vom seriellen Treiber zu Null uebergeben |
Die Dekodierung der Telegramme mit den passiven Adaptern: HT3_Mini/Micro_Adapter ist daher ohne korrekte Break-Signalerkennung erschwert. Die aktiven ht_transiver-Adapter (ht_pitiny/ht_piduino) erkennen das Break-Signal korrekt und übergeben die Telegramme mit Längenangabe zur weiteren Dekodierung. Werde trotzdem versuchen die Dekodierung für die passiven Adapter zu verbessern. Gruß Norbert
:
Bearbeitet durch User
Hallo zusammen, vorab vielen Dank für die super Arbeit! habe einen Raspberry Zero mit einem ht-tranceiver am laufen und die Daten per MQTT in unser IP Symcon System eingebunden. Funktioniert bislang perfekt. Ich hätte eine Frage zum dem Errorcode. Gibt es hier eine Übersetzung? Den bzw. die Causecodes habe ich in der Anleitung gefunden, zum Errocode (z.B. 17461) aber rein gar nichts. Kann dieser entschlüsselt werden? Würde gern die Codes in Symcon hinterlegen und die Fehler im Klartext auf dem Tablet anzeigen. Haben eine einfache Therme ZSB 14-4C... mit Warmwasserspeicher, Solarthermieanlage und ein C 400 Bedienelement. Gruß Micha
micha schrieb: > Den bzw. die Causecodes habe ich in der Anleitung gefunden, zum Errocode > (z.B. 17461) aber rein gar nichts. Diesen Errorcode habe ich ebenfalls nicht in meinen Unterlagen gefunden. Was ich für die Cx400/800 Reglerserie finden konnte sind alles Codes wie: Störungs-Code : Axy | z.B.: A41 und Zusatz-Codes: 811, 4051, usw. Die dezimale Zahl:17461 in Hex: 4435 ergäben die ASCII-Zeichen: D5 Allerdings ist auch dieser Error-/Cause-Code nicht in meinen Unterlagen. Mit dem HT3_Analyser kannst Du die Telegramme auswerten, insbesondere das Telegramm: MsgID 24_0. Im Telegramm sind die Bytes: 22/23 für den Display-Code und die Bytes: 24/25 für den CauseCode reserviert (siehe markierten Bereich im Bild, Wert dort 00cc hex := 204dez.) Falls in Deiner Anlage Fehler vorhanden sind, so sollten diese auch im Regler Cx400 angezeigt werden. Vergleiche bitte mal beide Angaben. Eventuell kannst Du auch noch ein binäres Logfile (ca. 1/2 Std.) deiner Anlagentelegramme erzeugen und mir zusenden oder hier veröffentlichen. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, danke für die Antwort. Das passt dann aber zusammen. Die Anlage zeigt ein D5 331 an, was nach Anleitung auf einen defekt des externen Vorlauftemperaturfühlers hindeutet. Der Angezeigte Fehler setzt sich dann immer aus Errorcode und Causecode zusammen?! Gruß micha, allen schöne Ostern!
Micha schrieb: > Der Angezeigte Fehler setzt sich dann immer aus Errorcode und Causecode > zusammen?! Ja. Es gibt mehrere Telegramme für Fehlermeldungen, aber Error- und Cause-Code werden zusammen gesendet. Eventuell kann einer der beiden Werte Null sein (nicht gesetzt). Ist kein Fehler vorhanden sind beide Werte Null. Telegramme mit Error-/Cause-Code sind: MesId's (dezimal): 24, 162, 190, 191; teilweise allerdings mit unterschiedlicher Byte-Anzahl und von verschiedenen Quellen. Dies macht die Auswertung schwieriger. Am Heizungs-Regler angezeigte Fehlermeldungen stammen wohl vom Telegramm MesID:24. Micha schrieb: > Die Anlage zeigt ein D5 331 an, was nach Anleitung auf einen defekt des externen > Vorlauftemperaturfühlers hindeutet Da Du nur eine Zahl (17461) mitgeteilt bekommst, ist wohl noch eine Dekodierung des Wertes von 17461 nach D5 erforderlich oder? Wird denn die Zahl: 331 korrekt übermittelt? Welche Werte werden im HT3_Analyser.py für Error-/Cause-Code angezeigt? Gruß Norbert
:
Bearbeitet durch User
Beitrag #6878610 wurde von einem Moderator gelöscht.
Beitrag #6878984 wurde von einem Moderator gelöscht.
Hallo, ich musste letzte Woche meine SD-Karte begraben und versuche nun die Datenerfassung neu zu installieren. Dies habe ich eigentlich schon öfter gemacht, angefangen damals mit einem PI 1 und einem Miniadapter. Bis ungefähr Weihnachten lief es nun auf einem PI3B+ mit einem pitiny. Aber nun will es einfach nicht gelingen. LED's auf dem pitiny blinken und ich habe mich an die aktuelle Anleitung gehalten und bin nur den kürzensten Standardweg gegangen. Aber es kommt einfach kein Paket an. Es werden keine Datenbankeinträge geschrieben, Logeinträge kommen nach dem Start keine dazu und auch Grafiken werden keine erstellt. Hat jemand eine Idee? Danke und Gruß Stephan
Stephan schrieb: > Aber nun will es einfach nicht gelingen. LED's auf dem pitiny blinken > und ich habe mich an die aktuelle Anleitung gehalten und bin nur den > kürzensten Standardweg gegangen. Aber es kommt einfach kein Paket an. Es > werden keine Datenbankeinträge geschrieben, Logeinträge kommen nach dem > Start keine dazu und auch Grafiken werden keine erstellt. > > Hat jemand eine Idee? Hallo Stephan, da Dein(e) Adapter schon einmal an der Heizung Daten erfasst hatten ist wohl die Hardware und die Verbindung zum Heizungsbus in Ordnung. Da Du auch die Standardkonfiguration (Default-Einstellung von github) verwendet hast betreibst Du das Projekt lokal als user 'pi' auf Deinem RPi. Wenn trotz allem keine Daten kommen bleibt als Grund wohl nur noch die serielle Schnittstelle vom/zum Adapter (ht_pitiny) über. Bitte die Einstellungen in den Konfigurationsfiles kontrollieren. Erforderlich sind ja für den aktiven ht_pitiny-Adapter: 19200 Baud und 8N1. Dies muss im Konfigfile ~/HT3/sw/etc/config/ht_proxy_cfg.xml eingestellt werden. Beispiel von meinem RPi4:
1 | <ht_transceiver_if devicename="RX"> |
2 | <parameter> |
3 | <serialdevice>/dev/serial0</serialdevice> |
4 | <baudrate>19200</baudrate> |
5 | <config>"8N1"</config> <!-- only 8N1 available --> |
6 | </parameter> |
7 | <devicetype>RX</devicetype> |
8 | </ht_transceiver_if> |
9 | <ht_transceiver_if devicename="MODEM"> |
10 | <parameter> |
11 | <serialdevice>/dev/serial0</serialdevice> |
12 | <baudrate>19200</baudrate> |
13 | <config>"8N1"</config> <!-- only 8N1 available --> |
14 | </parameter> |
15 | <devicetype>MODEM</devicetype> |
16 | <deviceaddress_hex>0D</deviceaddress_hex> |
17 | </ht_transceiver_if> |
Bitte den Namen der Seriellen Schnittstelle beachten! Die ist hier geändert auf: /dev/serial0 Es kann sein, dass die serielle Schnittstelle Deines RPi eben nicht mehr als /dev/ttyAMA0 bezeichnet wird sondern eben als /dev/serial0 etc. Die bitte auf Deinem RPi kontrollieren (siehe Bilder für RPi3 und RPi4). Gruß Norbert
:
Bearbeitet durch User
Norbert S. schrieb: > Es kann sein, dass die serielle Schnittstelle Deines RPi eben nicht mehr > als /dev/ttyAMA0 bezeichnet wird sondern eben als /dev/serial0 etc. Hallo Norbert, wie immer gilt: kaum macht man es richtig, schon geht es... Ja, genau das war es! Ich wähnte mich auf der sicheren Seite weil die Anleitung bei der Unterscheidung zwischen ttyAMA0 und Serial0 ja klar von einen PI 4 spricht und ich ja "nur" einen PI 3 B+ habe. Und ich hätte schwören können, dass es beim "ersten" Mal mit diesem Pi noch ttyAMA0 war (aber das war auch noch nicht mit Buster). Also vielen Dank für die Hilfe und die langjährige Arbeit am Projekt. Gruß Stephan
:
Bearbeitet durch User
Stephan T. schrieb: > Und ich hätte schwören können, dass es beim "ersten" Mal mit diesem Pi > noch ttyAMA0 war (aber das war auch noch nicht mit Buster). Ja, wahr auch so. Deswegen hatte ich dies in der Doku auch so für den RPi3 beschrieben und beim RPi4 war dann eben /dev/serial0 nötig. Aber dies hat man wohl jetzt für RPi3/4 und Buster geändert und hängt mehr oder weniger mit der Bluetooth-Schnittstelle zusammen. Siehe dazu: https://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3-pizerow-pi4-or-later-models/45571#45571 Werde deshalb die Default-Konfiguration im Projekt auf github.com anpassen müssen. PS: Allerdings warum man ausgerechnet den Namen: '/dev/serial*' verwendet hat ist mir schleierhaft. Die Schnittstellen: SPI, I²C, USB usw. arbeiten auch seriell, werden aber sicher nicht mit diesem Namen anzusprechen sein (oder doch in Zukunft!!???) Noch ein Hinweis zur fehlerhaften SD-Karte. Hatte selber Probleme mit SD-Karten. Zu häufiges Schreiben bekommt denen wohl nicht so gut (bei Dauerbetrieb und über Jahre). Habe deshalb die Datenbanken auf einem USBStick generiert und schreibe die Heizungsdaten auch nur noch auf diesen Stick. Dazu ist die Konfigurationdatei anzupassen auf den absoluten Pfad des USBSticks. Dies läuft nun schon seit Jahren. Gruß Norbert
Hallo Norbert, ich betreibe seit ca. 3 Jahren Deine Software auf einem Raspberry Pi 3B mit dem HT3-Miniadapter ohne große Probleme. Dafür erst einmal vielen Dank. Nun habe ich vor das Raspbian auf Bullseye zu aktualisieren und auch Deine neueste Softwareversion einzusetzen. Dabei habe ich folgende Vorgehensweise gewählt: - Erstellung des Raspian Bullseye auf einem anderen Raspberry Pi 3B+ - Installation Deiner aktuellen Software nach Anleitung - Erster Test auf dem Raspberry Pi 3B+ ohne HT3-Miniadapter, keine Fehlermeldungen, aber auch ohne Daten. - Alten Raspberry Pi 3B herunterfahren und die SD-Karte mit dem neuen Bullsey einlegen. Raspberry wieder hoch fahren. - Ich bekomme keine Fehlermeldungen in den Log-Dateien, aber auch keine Daten. - Darauf hin habe ich die SD-Karten wieder getauscht und das alte System läuft wieder ohen Probleme. Hast Du eine Idee, was und wie ich weiter prüfen kann? Gruß Michael
Hallo Michael, Guck Mal die letzten 4 Posts. Sieht so aus als hättest du dasselbe Problem wie ich... Gruß Stephan
Hallo Stephan, vielen Dank für den Hinweis. Genau das war es. In der vorhergehenden Version habe ich noch /dev/ttyAMA0 benutzt. Und ich bin mir fast sicher, dass ich da bereits Buster am laufen hatte. Aber jetzt, mit /dev/serial0, läuft wieder alles. Gruß Michael
Hallo Norbert Ich nutze deine Software schon seit nun über 4 Jahren und musste schon seit längerem nichts mehr ändern. Vielen Dank für die ganze Mühe die Du dir gemacht hast - das ist echt bewundernswert! Die aktuellen Gaspreise haben mich aber motiviert noch mal nach Optimierungspotentials zu suchen. Ich habe eine Solarthermie und unterstütze die Heizung durch Rücklauf anhebung. Leider führt das dazu, dass meine Heizung ziemlich ins Takten kommt und ich würde eigentlich viel lieber die Heizkreispumpe ohne Brenner nutzen. Leider habe ich keine Möglichkeit gefunden nur die Pumpe ein/aus zu schalten. Kann die Heizung bzw. das Interface das einfach nicht?
Ich glaube die Antwort kann ich mir selbst geben. Tatsächlich reicht es aus, die Solltemperatur zu senken. Dann schafft es die Gastherme - ohne zu zünden - in regelmäßigen Abständen die Heizkreispumpe zu starten.
Hallo Zusammen, ich durch die HT3-Soft- und Hardware jetzt erstmals eine Idee über die Aktivitäten meiner Heizung bekommen, ZWSB 22/28-3 mit FW120 aus 2014 in einem EFH von 1997. Aus meiner Sicht ist da ziemlich was los (siehe Bilder) Ich versuche aktuell, dass etwas zu entwirren. Wenn mir jemand spontan Hinweise geben kann, was komisch ist, oder verbessert werden kann, freue ich mich über Hinweise. Die Heizungsfragen will ich im auch im Heizungsforum stellen https://www.heizungsforum.de/forums/junkers-bosch.14/, (falls nicht jemand bessere Adressen hat). Das Gerät steht praktisch noch auf den Einstellungen von Inbetriebnahme und läuft aus meiner Sicht viel zu oft an. Ich habe allerdings noch eine ganz spezielle Frage: Ich beobachte, dass der Wert `hc1_Tflow_desired`, also T-Soll (Regelung) vom Heizgerät bei mir ständig, aber ohne für mich erkennbare Frequenz, auf 85 °C hochgeht. Kann mir jemand erklären, was da passiert und warum das passiert? Wie kann ich das verhindern, oder will ich das vielleicht gar nicht verhindern? Viele Grüße Martin PS: Grandioses Gesamtpaket, Respekt an Norbert!
Martin G. schrieb: > Ich habe allerdings noch eine ganz spezielle Frage: Ich beobachte, dass > der Wert `hc1_Tflow_desired`, also T-Soll (Regelung) vom Heizgerät bei > mir ständig, aber ohne für mich erkennbare Frequenz, auf 85 °C hochgeht. Wird immer bei Warmwasser-Erwärmung auf diesen Wert gesetzt. Soll ja schnell erwärmt werden. > Kann mir jemand erklären, was da passiert und warum das passiert? Wie > kann ich das verhindern, oder will ich das vielleicht gar nicht > verhindern? Warmwasser wird zu häufig erzeugt. Liegt wohl hauptsächlich an der aktiven Zirkulations-Pumpe. Wasser ist dann zwar immer sofort heiß am Hahn, aber dafür zahlt man dann auch. Versuchsweise mal die Zirkulations-Pumpe deaktivieren (wenn der Chef des Hauses dann flucht hat Man(n) schlechte Karten :-). Die WW-Speicher Temperatur ist fast immer (ca. 3 Grad) unterhalb des Soll-Wertes. Kann ich mir z.Zeit nicht erklären. Vielleicht hat noch jemand ein paar Tipps. Gruß Norbert
:
Bearbeitet durch User
Das hat mir schon sehr geholfen. Meine Anlage hat auch eine externe Wilo Pumpe (die nicht in Betrieb ist). Dass die Heizung selbst umwälzt, war mir nicht (mehr?) klar. Damit verstehe ich dann auch die Pumpenaktivität, die im Diagramm auftaucht ist. Da hat meine Heizung etwas gemacht, das ich eigentlich so nicht wollte. Die Umwälzung ist jetzt abgestellt bzw. sehr punktgenau eingestellt. Das zeigt sich auch schon in der aktualisierten Darstellung.Danke schon einmal dafür. Als nächstes würde ich ja gerne die Anzahl der Zündungen reduzieren. Könnte ich da mit der Taktsperre Erfolg haben? Oder ist das herumdoktern an Symptomen? Grüße Martin
Martin G. schrieb: > Als nächstes würde ich ja gerne die Anzahl der Zündungen reduzieren. > Könnte ich da mit der Taktsperre Erfolg haben? Oder ist das herumdoktern > an Symptomen? Bin kein Heizungsfachmann, jedoch probieren geht über studieren. Du kannst die Automatische Taktsperre oder auch die Schaltdifferenz einstellen. Den richtigen Wert kannst Du nur durch Probieren herausfinden und der ist ein Kompromiss zwischen Komfort und zugelassener Regelabweichung. Einstell-Möglichkeiten siehe Bild. Gruß Norbert
Hallo Norbert, habe heute morgen einen Ausfall meiner HT3-Software. Nach einem Neustart läuft zunächst ein paar Minuten alles. Danach stürzt der Prozess ht_collgate mit folgenden Fehlermeldungen ab: 30.08.2022 10:10:33 INFO: Starting 'Ccollgate.run() 30.08.2022 10:10:33 INFO: cht_if_worker(); Start ---------------------- 30.08.2022 10:10:33 INFO: cht_if_worker(); Loglevel :INFO 30.08.2022 10:10:33 INFO: cht_if_worker(); Datainput-Mode:SOCKET 30.08.2022 10:10:33 INFO: cht_discode.discoder() --> common CRC-detection procedure <-- 30.08.2022 10:12:44 CRITICAL: cstore2db.run();Error; on ht_if.decoded_data_4_DBs().get() 30.08.2022 10:12:45 CRITICAL: ccollgate().run();Error;cstore2db_if-thread terminated. 30.08.2022 10:12:45 CRITICAL: ccollgate().run();Error; terminated Ich kann mit dem Fehler nichts anfangen. Das System lief bisher 2-3 Jahre reibungslos. Gruß Michael
Michael W. schrieb: > Ich kann mit dem Fehler nichts anfangen. Das System lief bisher 2-3 > Jahre reibungslos. Der Prozess wird beendet, weil offensichtlich keine Daten decodiert werden konnten. Details dazu in sw/lib/Ccollgate.py # read values from queue, wait if empty or stop if (None, None) (nickname, value) = self._ht_if.decoded_data_4_DBs().get() # terminate thread if both values are None, else process them if (nickname, value) == (None, None): self.stop() break Einen Grund kann ich allerdings auch nicht erkennen. > Das System lief bisher 2-3 Jahre reibungslos. Ich nehme deshalb an Du nutzt ein älteres Release der Software. Ich kann Dir da nur empfehlen auf das letztgültige Release: 0.5 des github.com repositories zu aktualisieren. Grund: Falls man linux aktualisiert (update/upgrade) kommen einige Änderungen (Namensänderungen serielle Schnittstelle etc.) mit in das Betriebssystem die vorher nicht enthalten waren. Dann werden halt keine Daten mehr von der Schnittstelle empfangen und decodiert. Gruß Norbert
Hallo Norbert, ich nutze zur Zeit die Version 0.4.2 Mittlerweile habe ich herausgefunden, dass der Fehler beim Schreiben in die SQLite-DB auftritt. Hatte vor ein paar Monaten die SQLite-DB in Betrieb genommen, weil ich einige Datensätze analysieren wollte und danach nicht wieder außer Betrieb genommen. Ich habe jetzt das Speichern in der SQLite-DB unterbunden und dann läuft wieder alles wie gewohnt. Ich werde jetzt nicht mehr weiter suchen und auch nicht mehr updaten, da ich das System vermutlich nur noch ein halbes Jahr betreibe. Vielen Dank für Deine Unterstützung. Gruß Michael
Hi, ich hab gerade HT3 neu installiert mit der Datenbank auf einem USB Stick. Leider generiert er die HTML Bilder nicht, obwohl er Daten abspeichert und die RRD Datenbanken modifiziert werden. Jemand eine Idee dazu wo ich schauen sollte? Viele Grüße, Nils nils@ht3:~ $ /home/nils/HT3/sw/etc/rrdtool_draw.pl /media/usbstick /home/nils 2 1 0 1 1 0 0 1 0 rrdtool info /media/usbstick//HT3/sw/var/databases/HT3_db_rrd_solar.rrd failed: could not lock RRD at /usr/share/perl5/RRDTool/OO.pm line 444 24.09.2022 15:13:54 DEBUG: 35_0 ;TSoll:24;Leistung:100;Drehzahl:0 24.09.2022 15:13:54 DEBUG: 35_0 ;TSoll:24;Leistung:100;Drehzahl:0 24.09.2022 15:13:54 DEBUG: 35_0 ;TSoll:21;Leistung:100;Drehzahl:0 24.09.2022 15:13:58 DEBUG: 24_0 ;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 7:0;Byte28:0 24.09.2022 15:14:02 DEBUG: 259_0 ;Optim.Faktor_WW:16;Optim.Faktor_HG:0;Ertrag letzte Std.:0;Tkollektor:31.8;Tspeicher:36.6;pump status:0;Kollektor aus:0; Speicher voll:0;> 24.09.2022 15:14:03 DEBUG: 30_0 :HG;T_HydraulicDevice:21.7 24.09.2022 15:14:06 DEBUG: 268_0 ;status_mixer:1 24.09.2022 15:14:07 DEBUG: 268_0 ;status_mixer:2 24.09.2022 15:14:07 DEBUG: 2_0 ;Bus-Request Source:10(h) to Target:08(h) 24.09.2022 15:14:07 DEBUG: 2_0 ;Bus-Response Source:08(h) to Target:10(h) ;1.Busteilnehmer:95;Typ:Heatronic3;Softwarefamilie:18;Softwareversion:8 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:0 ;Markenzeichen:None 24.09.2022 15:14:08 DEBUG: 24_0 ;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 7:0;Byte28:0 24.09.2022 15:14:09 DEBUG: 2_0 ;Bus-Request Source:10(h) to Target:20(h) 24.09.2022 15:14:09 DEBUG: 2_0 ;Bus-Response Source:20(h) to Target:10(h) ;1.Busteilnehmer:102;Typ:IPM2;Softwarefamilie:20;Softwareversion:7 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:100 ;Markenzeichen:Junkers 24.09.2022 15:14:09 DEBUG: 2_0 ;Bus-Request Source:10(h) to Target:21(h) 24.09.2022 15:14:09 DEBUG: 2_0 ;Bus-Response Source:21(h) to Target:10(h) ;1.Busteilnehmer:102;Typ:IPM2;Softwarefamilie:20;Softwareversion:7 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:100 ;Markenzeichen:Junkers 24.09.2022 15:14:09 DEBUG: 2_0 ;Bus-Request Source:10(h) to Target:30(h) 24.09.2022 15:14:09 DEBUG: 2_0 ;Bus-Response Source:30(h) to Target:10(h) ;1.Busteilnehmer:101;Typ:ISM1;Softwarefamilie:23;Softwareversion:3 ;2.Busteilnehmer:0;2.Major Version:0;2.Minor Version:0 ;3.Busteilnehmer:0;3.Major Version:0;3.Minor Version:101 ;Markenzeichen:Junkers 24.09.2022 15:14:18 DEBUG: 24_0 ;Byte10:19;T2-buffer:3276.8;I-current:6553.5;pressure:20;WW-flow:0;Byte2 7:0;Byte28:0 24.09.2022 15:14:18 DEBUG: 22_0 :HG;heat_enable:On;TargetDevice(dez.):16;MaxT_Vorlauf:61 24.09.2022 15:14:18 DEBUG: 30_0 :HG;T_HydraulicDevice:21.7
Bitte meine Frage ignorieren. Nach 1 Stunde sieht man nun aktuelle Messwerte und auch die erste Historie. Anscheinend war ich einfach nur zu ungeduldig... Super Software übrigens.
Hi. Ich würde gerne eine Frage von mir aus 2015 wieder aufgreifen. Unterstützung von Fehlermeldungen aus der Therme, dass diese z.B. ein Programm aufrufen welches einen Alert verschickt. Ich habe hier eine wahrscheinlich bekannte Doku gefunden welche für den EMS Bus (ähnlich zum EMS2?) die Fehlerprotokolle auslistet, wenn auch nicht den Fehlercode. Für eine erste Benachrichtigung einfach den Fehlercode rauszusenden wäre direkt auf dem Niveau vom MB-LAN2, mehr kann dies auch nicht. https://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme Viele Grüße, Nils
Nils R. schrieb: > Unterstützung von Fehlermeldungen aus der Therme, dass diese z.B. ein > Programm aufrufen welches einen Alert verschickt. Hallo Nils, ich hoffe Dein System läuft noch und erzeugt keine Fehler :-) Es macht auf jeden Fall Sinn so etwas zu haben. Den nicht jeder hat oder will ein teuer MBLan2, wenn man Fehlermeldungen auch billiger senden kann. Es ist z.Zeit nur eine Anzeige in den GUI's (HT3_Analyser und HT3_Systemstatus) enthalten, gesendet wird an die Schnittstellen noch nichts. Daher habe ich auf github.com ein neues 'issue:21' aufgemacht, in dem man Fakten, Wünsche und Bemerkungen reinschmeissen kann. https://github.com/norberts1/hometop_HT3/issues/21 Zum Anfang werde ich dort auch eine Mapping-Liste (Errorcode <--> Text) reinstellen, damit jeder diese Errorcodes mit seinem Anlagenhandbuch vergleichen und eventuell auf github.com 'issue:21' oder hier ergänzen kann. Wie die Software im einzelnen ergänzt/erweitert werden soll muss noch festgelegt werden. Gruß Norbert
Das klingt ja sehr gut. Dann trag ich mal was zusammen. Bei mir tritt immer mal wieder das Problem auf, dass zu wenig Druck anliegt. Den Messwert dazu hab ich übrigens auf Seite 39 nicht gefunden, ist aber in MB-LAN2 vorhanden. Ggf. kann man diesen noch ergänzen. Ticket in Github? Übrigens hat man mir nun mitgeteilt, dass die EasyControl App nicht mehr supportet wird. Leider funktioniert diese nicht im WLAN und stürzt direkt ab. Macht das ganze noch sinnloser...muss immer WLAN abschalten, um diese benutzen zu können.
Hi, ich hab mal eine Frage zu meiner Heizung, die ich aufgrund der HT3 Daten bekommen habe (echt super nochmal das zu haben... :-) ). Hardware: ZSBE 28-3 A23 FW200 IPM2 ISM1 Speicher SK400-1 3x FKT-1S Solarkollektoren Anscheinend speichert meine Heizung schön Solarenergie, nutzt diese aber nicht oder die Abflachung der Warmwasserkurve ist die Solarnutzung, aber irgendwie hätte ich da mehr erwartet... Zudem steht T-Ist (Raum) immer auf über 30Grad, das ist aber auch im MB-LAN2 so, liegt somit eher an der Heizung. Die FW200 ist witterungsgeführt, aber der Wert ist schon komisch. Viele Grüße, Nils
:
Bearbeitet durch User
Nils R. schrieb: > ...Zudem steht T-Ist (Raum) immer auf über 30Grad Der Regler FW200 ist bei Dir sicher im Heizgerät eingebaut. Somit misst dieser die interne Temperatur des Heizgerätes. Sieht man auch an der T-Ist Kurve im Heizkreis, immer dann wenn der Brenner läuft geht diese Temperatur schlagartig hoch. Leider wird in den Telegrammen nicht mitgeteilt ob der Regler im Heizgerät eingebaut ist. PS: Jeder Junkers/Bosch Regler Fxyz und auch Cxzy hat einen internen Temperatursensor. Somit könnte man diesen auch direkt in einen zu kontrollierenden Raum installieren wenn man die Heizungs-Busleitung dahin verlegen kann. Dazu gibt es Wandbefestigungen von Junkers/Bosch. Genau dieses habe ich bei meinem Heizungssystem gemacht und den CW400 in meinem Wohnzimmer installiert. Kann dadurch auf eine Fernbedienung verzichten und erhalte die korrekte T-Ist Temperatur des Raumes. > Anscheinend speichert meine Heizung schön Solarenergie, nutzt diese aber > nicht oder die Abflachung der Warmwasserkurve ist die Solarnutzung, aber > irgendwie hätte ich da mehr erwartet... Für die Warmwasserunterstützung reicht die Solar-Temperatur nicht mehr aus, da der Warmwasser Soll-Wert ja auf 50Grad steht, die Solarspeichertemperatur diesen Wert aber nicht mehr erreicht. Daher wird diese Solarenergie für die Heizkreise genutzt werden. Allerdings sieht man dies nicht im Heizgeräte-Bild. Da ist auch fast immer die Rücklauftemperatur höher als die Vorlauftemperatur, nur wenn geheizt oder das Heizgerät in Standby steht ist dies nicht so. Leider sieht man in Deinem rrdtool-plot nicht wann die Heizungs- bzw. Heizkreis-Pumpen laufen, weil Du eine ältere Software-Revision nutzt. Bitte die Software aktualisieren, damit diese Infos zur Verfügung stehen. Angefügte Bilder zeigen mein System und wann die Solarenergie aus dem Solarspeicher für den Heizkreis genutzt wird (10:00 bis 12:15 und 16:00 bis 18:30). Auch sieht man wann die Heizungspumpe läuft (Heizungspumpenleistung %). Die Solartemperatur reicht aber auch hier nicht mehr für die WW-Erwärmung. Gruß Norbert
:
Bearbeitet durch User
Moin, solange die Regelung den Raumwert nicht nutzt. :-) Dann blende ich mal die Werte aus. Ich hab die aktuelle Software, aber das rrd angepasst damit es für mich etwas übersichtlicher ist. Hab es nun wieder eingeblendet. Anscheinend wird die Solarenergie nicht für die Heizung genutzt, auch sinkt die Temperatur des Speichers nicht so schnell wie bei dir. Ich hab auch nur einen Warmwasserspeicher und keinen Kombispeicher laut meinen Recherchen, den mal wohl bräuchte für beides. Das ist ein Punkte wo ich ansetzen möchte zur Optimierung, dass die Solarenergie dann für die Heizung genutzt werden kann und nicht einfach im Speicher verpufft. So hab ich es jedenfalls verstanden. Viele Grüße, Nils
Was hast du für ein Heizungssetup und ist es möglich wann der Solarspeicher angezapft wird für Warmwasser oder Heizung in dem Solardiagramm zu ergänzen? Der Ertrag ist bei mir etwas zwiespältig, wenn dieser eigentlich nicht genutzt wird…
Falls jemand Interesse hat, hab meine Zirkulationspumpe automatisiert (war nur eine mechanische Uhr dran) und anstatt einem weiteren IPM es mit Relais, ESP32 und einer MQTT Anbindung zusammen mit der HT3-MQTT Anbindung gelöst. Mit so einem Standard wie MQTT ist schon cool, was da alles geht. https://github.com/NilsRo/HotWaterRecirculatingPump
:
Bearbeitet durch User
Nils R. schrieb: > solange die Regelung den Raumwert nicht nutzt. :-) Wird nicht, da am Regler FW200 ja reine Außentemperatur-Führung eingestellt ist. > Was hast du für ein Heizungssetup Mehr oder weniger die Default-Einstellungen. - Automatische Taktsperre: Aus - Taktsperre auf 3 Minuten - Schaltdifferenz 10 K - Gebläsenachlaufzeit 30 Sekunden - Minimale Nennwärmeleistung 36 % Die Einstellungen Deiner Heizung solltest Du noch mal prüfen bzw. optimieren. Was mir an dem letzten Heizgeräte-Plot (https://www.mikrocontroller.net/attachment/572109/Bild_2022-10-01_175742006.png) negativ aufgefallen ist: die Heizungspumpe läuft sehr häufig und dann nur kurz. Diese kurze Taktung ist nicht besonders effektiv wenn man einen Brennwert-Kessel hat. Bessere wäre eine längere Laufzeit auf niedrigem Niveau. Vielleicht kannst Du da noch etwas verbessern. > ist es möglich wann der Solarspeicher angezapft wird für > Warmwasser oder Heizung in dem Solardiagramm zu ergänzen? Die Telegramme auf dem Heizungsbus sind da nicht sehr detailfreudig. Habe zu Versuchszwecken das Solardiagramm ergänzt um die beiden Faktoren: - Optimierungsfaktor Heizung - Optimierungsfaktor Warmwasser Diese Daten werden vom ISM/MS - Modul bereitgestellt. Diese sind jedoch nur reine Faktoren und keine Temperatur-Werte. Was,wie und wann die Regler (FW200 etc.) diese Werte nutzen, kann ich aus den anderen Telegrammen und Grafen nicht erkennen. Siehe Beispiel: Solargraf mit der Optimierungsfaktor-Ergänzung. Wenn dir dies weiterhilft kommt es mit ins nächste SW-Release. Gruß Norbert
Hallo, meine Junkers-Therme ist leider nicht HT3-fähig (24V Stetigregelung über 1-2-4 Anschluss), aber der nachträglich installierte Raumtemperaturregler FR50 kann beides. Ist zufällig bekannt, inwiefern und ob der FR 50 z.B. Raumtemperatur und Schaltverhalten parallel über den HT3 Anschluss publiziert oder ob da der Bus mangels "geschwätziger" Therme automatisch abgeschaltet ist? Gruß Mike
Moin, ich möchte zusätzlich zur RRD Datenbank auch die HTML Erzeugung auf einen USB-Stick umziehen was soweit auch geklappt hat. Leider bekomme ich aber die automatische PNG Erzeugung nicht abgeschaltet, dies macht er immer noch im Standardverzeichnis. Die Erzeugung mit off oder 0 abzuschalten bringt leider nichts...kann ich irgendwo schauen welchen Wert er ermittelt hat? Die neue Erzeugung mache ich mit einem Crontab-Eintrag selber. (*/5 /home/nils/HT3/sw/etc/rrdtool_draw.pl /media/usbstick/ /media/usbstick/) <rrdtool-db> <enable>on</enable> <step_seconds>60</step_seconds> <starttime_utc>1344000000</starttime_utc> <!-- autocreate_draw: parameter used for auto-creating the png-draws from rrdtool-database content. (value is defined in 'minutes' (> 0) or disabled (== 0)) if set to:0 or off autocreating is disabled. if set to:> 0 autocreating is enabled (enabled only if database is also set to:<enable>on</enable>) --> <autocreate_draw>0</autocreate_draw> </rrdtool-db> Viele Grüße, Nils
:
Bearbeitet durch User
Nils R. schrieb: > Die Erzeugung mit off oder 0 abzuschalten bringt leider nichts... Nach einer Konfigurations-Änderung ist ein Restart des ht_collgate.py erforderlich. Nils R. schrieb: > Die neue Erzeugung mache ich mit einem Crontab-Eintrag selber. Kann man machen, jedoch muss man die nötigen Parameter ebenfalls übergeben. Diese werden dynamisch aus den dekodierten Heizungsdaten ermittelt und als Darstellungs-Eigenschaften dem perl-script übergeben. Im Crontab-Eintrag ist dies dann statisch mit einzutragen, sonst kommt u.U. eine falsche grafische Darstellung der Heizungsanlagen-Werte. Parameter sind: rrdtooldb.create_draw( db_path, html_path, --> Pfade auf db und html heatercircuits_amount(), --> Anzahl Heizkreise controller_type_nr(), --> Controller-Typ (Fxyz, Cxyz) GetAllMixerFlags(), --> gemischte /ungemischte Heizkreise (array) IsTempSensor_Hydrlic_Switch()), --> hydraulische Anpassung 0/1 IsSolarAvailable()), --> Solar vorhanden oder nicht 1/0 IsSecondCollectorValue_SO())) --> zweiter SO-Kollektor da oder nicht 1/0 Zusätzlich muss der httpd.py-daemon als html-server im gleichen Verzeichnis wie unter 'html_path' angegeben vorhanden sein und laufen. Gruß Norbert
Hab zur Sicherheit den Raspi durchgestartet, aber er ignoriert den Parameter weiterhin. Aufgrund deiner Beschreibung hab ich nun einen Symlink auf den USBStick angelegt und lasse die Automatik die Dateien erzeugen, funktioniert reibungslos und sicher auch etwas einfacher fürs aktualisieren...danke dir.
:
Bearbeitet durch User
Moin. Ich beschäftige mich gerade damit meinen Raspi auf ein Readonly-Filesystem umzustellen, da mir immer die SD und der USB Stick abrauchen. Läuft soweit auch und nutze nur MQTT für die zentrale Speicherung. Dabei kam mir nun die Frage ob der rsyslog Deamon nicht zum loggen genutzt werden könnte. Damit sind die Logs im zentralen Verzeichnis und landen bei mir auch auf dem zentralen Syslogserver. https://gist.github.com/danielkraic/a1657f19bad9c158cbf9532e1ed1503b Ähnliches gilt übrigens auch für das run Verzeichnis der pids, obwohl die Logs persistent zu haben wichtiger wäre. Hattest du dich schonmal damit beschäftigt Norbert? Viele Grüße Nils
Nils R. schrieb: > Dabei kam mir nun die Frage ob der rsyslog Deamon nicht zum loggen genutzt > werden könnte. Damit sind die Logs im zentralen Verzeichnis und landen > bei mir auch auf dem zentralen Syslogserver. Habe mich bisher noch nicht mit 'rsyslog' beschäftigt aber danke für den Link zu github. Da das Logging ohnehin im Projekt vorhanden ist sieht der Aufwand dazu erst einmal gering aus. Schaue ich mir an. Allerdings wenn alles zentral auf dem syslog Server gespeichert wird und das Format (Payload) nicht standardisiert ist, sehe ich viel Kraut und Rüben in den syslogfiles, den man wieder mit grep oder anderen Tools (SigNoz etc.) wieder für das jeweilige Server/Projekt/Prozess/Applikation sortieren muss. Das Logging-Format in meinem Projekt (im Debug-Modus) ist mit ';'-Trennern aufgebaut und kann damit DIREKT als csv-file in Excel bzw. LibreOffice ausgewertet werden. > Ähnliches gilt übrigens auch für das run Verzeichnis der pids. Nach Anpassung der systemd startscripte ist dieses Verzeichnis ohnehin nicht mehr nötig. Gruß Norbert
Hallo Norbert, erst einmal vielen Dank für Deine bisherige Arbeit + Mühe die Du in dieses Projekt investiert hast. Danke dessen konnte ich seit 2017 ohne Probleme die Daten meiner Heizung anzeigen und über MQTT auch steuern. Mit Erweiterung der Anlage um Solar wurde nun die FW100 Regelung gegen eine CW400 + MS200 ausgetauscht. Da ich einen 2. Pufferspeicher mit 3 Wege Ventil im Ladekreis habe, wollte ich Fragen ob die Daten des 2. Pufferspeicher ebenfalls angezeigt werden könnten ? In der CW400 werden die Daten des 2. Pufferspeicher + Ventilstellung anzeigt. Werden diese Daten aktuell nicht dekodiert oder muß die Konfiguration angepasst werden ? Gruß, Jürgen
Jürgen schrieb: > Da ich einen 2. Pufferspeicher mit 3 > Wege Ventil im Ladekreis habe, wollte ich Fragen ob die Daten des 2. > Pufferspeicher ebenfalls angezeigt werden könnten ? Die Daten werden mit dem rrdtool als zweite Solar Grafik angezeigt. Dies wird automatisch erzeugt sobald die zugehörigen Telegramme erkannt werden. Diese Daten werden auch mit MQTT ausgegeben. Allerdings habe ich selber keinen 2. Solarspeicher und 'nur' das MS100 Modul mit dem CW400. Deshalb habe ich nicht alle Informationen über die Telegramme und Inhalte. Du kannst mir aber Deine Anlagendaten in ein Binarfile mitprotokollieren und hier veröffentlichen. Ich kann dann die Auswertung verbessern. Dazu folgenden Aktion auf dem RPi starten:
1 | |
2 | cd ~/HT3/sw |
3 | ./ht_binlogclient.py irgendeinName1.log |
Das/die Logfiles sollten nicht zu groß werden (ca. 1Std.) damit die Auswertung besser/schneller geht. Wichtig ist dabei auch die Anlage zu beobachten und Aktionen (z.B. Ladepumpe an/aus, 3Wege-Ventil Veränderung etc.) zeitlich zu erfassen und den Logfiles zuzuordnen. Ich weiß allerdings nicht wie man solche Aktionen für den 2. Solarspeicher erzwingen kann. Da kennst Du dich besser aus. Gruß Norbert
Hallo Norbert, entsprechend den anderen Beiträgen hier hatte ich mit der Frage nach den bin-logfites schon gerechnet und mal 1 Stunde zum Test mitlaufen lassen. Ich mache das heute Abend nochmals und notiere mit dabei die Zeitpunkte der Ventil Umschaltung ( lässt sich mit der Diagnose Funktion am CW400 steuern ) Gruß, Jürgen
Jürgen schrieb: > entsprechend den anderen Beiträgen hier hatte ich mit der Frage nach den > bin-logfites schon gerechnet und mal 1 Stunde zum Test mitlaufen lassen. Danke für das Logfile. Bei der ersten Auswertung habe ich in meinem Analyser Fehlercodes Deiner Anlage angezeigt bekommen. Displaycode: A11 Causecode: 3061 Laut meinen Unterlagen bedeutet dies: "Keine Kommunikation mit Mischermodul für Heizkreis1" Vorgeschlagene Aktionen: - Konfiguration prüfen (Adresseinstellung am Modul). - Mit der gewählten Einstellung ist ein Mischermodul erforderlich. Offensichtlich ist irgend eine Einstellung Deines Systems noch zu korrigieren. Gruß Norbert
Norbert S. schrieb: > Offensichtlich ist irgend eine Einstellung Deines Systems noch zu > korrigieren Die Fehlermeldungen hatte ich provoziert da das MM200 zu diesem Zeitpunkt stromlos war. Ich hatte den Außenfühler abgebaut, das hat die Regelung in eine Art "Notlauf" versetzt und beide Heizungspumpen laufen lassen .... Ist aber jetzt beseitigt da die Fassade an dieser Stelle fertig ist und der Fühler wieder dran .. Ich habe die Temperatur des 2.Speicher mal beobachtet und jeweils ein kurzes log generiert. Wenn ich nicht falsch liege wird die Temperatur mit Telegramm 938_0 übertragen. In den 3 Logs habe ich versucht folgendes einzufangen: - 21:12:05 Wechsel von 63,1 nach 63,0 ºC - 21:18:10 Wechsel von 63,0 nach 62,9 ºC - 21:23:16 Wechsel von 62,9 nach 62,9 ºC des Temperatur Fühler im Solar Speicher 2 unten. In den beiden anderen Logs habe ich versucht - 21:27:19 Umschaltung des Ventil nach SP2 - 21:29:20 Umschaltung des Ventil nach SP1 einzufangen. Vermute mal das wird mit Telegramm 986_5 übertragen. Hoffe das hilft erst einmal ... Gruß, Jürgen
Jürgen schrieb: > Ich habe die Temperatur des 2.Speicher mal beobachtet und jeweils ein > kurzes log generiert. Wenn ich nicht falsch liege wird die Temperatur > mit Telegramm 938_0 übertragen. Wird mit Telegramm 866_0_0 übertragen (siehe LibOfficeCal-Datei im tar-file). Habe die Werte/Bytes kommentiert und die Solar Temperatur-Sensornamen (TSxy) hinzugefügt. > Umschaltung des Ventil nach SP1 > Vermute mal das wird mit Telegramm 986_5 übertragen. Ja, sieht so aus. Wert ist:0 bei SP1 und (64)hex->100 bei SP2. Bitte kontrollierte mal die Anschlüsse im MS200 oder poste ein Foto. Daraus könnte ich die SolarOption Deines System extrahieren, mit den Infos der Telegramme vergleichen und die Temperatur-Sensoren zuordnen. Entnehmen kann ich aus den Telegrammen z.Zeit: Solaroption: BDI ist: B := Umschaltung 2.Speicher mit Umschaltventil D := Heizungsunterstützung Speicher2 I := Umladesystem bei Speicher-Reihenschaltung Ob dies so stimmt wäre zu klären. Die Projekt-Software ist noch nicht für die vielen Solar-Konfigurationen eines MS200 ausgelegt. Es wird zwar z.Zeit eine 2. Solargrafik mit dem rrdtool angezeigt, aber nur wenn ein zweiter Solar-Kollektor mit Sensor TS7 vorhanden ist. Dies ist aber in Deinem System nicht vorhanden. Die Dekodierung der Solar-Telegramme für die Cxyz-Regler muss ich erweitern. Deine Log-Files sind da Gold wert :-) Über die Darstellung als rrdtool-Grafik muss ich mir noch Gedanken machen. Auf jeden Fall kommen die zusätzlichen Infos auf der MQTT-Schnittstelle raus. Bitte poste auch die Systemkonfiguration, es sind ein MM200 und MS200 vorhanden mit einem ungemischten und einem gemischten Heizkreis laut Analyser. Ob dies richtig ist kannst nur Du beurteilen. Das Bild: Solar_Option_D_Sp2.png zeigt die vermutlich bei Dir vorhandene Solar-Konfiguration. Ich habe zusätzlich im github Projekt-Verzeichnis ein neues Issue:28 angelegt. Siehe URL:https://github.com/norberts1/hometop_HT3/issues/28 Kommentare, Logfiles etc. können auch da abgelegt werden. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, ich nutze aktuell die Option 1ABJ und genau so angeschlossen wie im angefügten Bild ersichtlich. Zur Verwirrung trägt offensichtlich bei das mit dieser Option der Fühler TS11 (unten SP3) am Anschluss TS8 des MS200 sowie TS10 (oben SP1) am TS7 des MS200 angeschlossen wird. Die Option K und P nutze ich nicht. Somit werden: - TS1, TS2, TS5 mit VS2 für die Solar Ladung, - TS3, TS4 mit VS1 für die Heizungsunterstützung, - TS10, TS11 und PS7 für die Umladung genutzt. Das sollte auch so in den logs so zu sehen sein. Das der Wert des TS5 im Telegram 866_0_0 Byte22+23 steht kann ich so bestätigen. Hatte den Ananlyzer laufen als die Anzeige im CW400 für Sp2 von 80,0 auf 79,9 Grad gefallen ist. Siehe Bild 866_0_0: Byte 22/23 = hex 031f, ist dez 799 und geteilt durch 10 = 79,9 Grad. Gruß, Jürgen
Hallo, kann man die Uhrzeit synchronisieren? Also die Uhr/Datum der Heizung mit dem RPI einstellen?
Markus J. schrieb: > kann man die Uhrzeit synchronisieren? > Also die Uhr/Datum der Heizung mit dem RPI einstellen? Dies funktioniert natürlich nur mit den aktiven Adaptern (ht_pitiny/ht_piduino), ist aber z.Zeit nicht in der Software enthalten. Das Einstellen der Uhrzeit mit EMS Bus-Telegrammen teste ich alsbald. Eine Synchronisierung der Uhrzeit könnte mit der lokal auf dem RPi vorhandenen Zeit erfolgen, die dann mit ntp synchronisiert ist. Eine manuell eingegebene Zeit halte ich für die Synchronisation ungeeignet. Die kann man dann ja auch am Systemregler (Fxzy / Cxyz) eingeben. Gruß Norbert
Hi Norbert, ich habe die aktuelle Version neu augesetzt. Incl Debian 12 (bookworm) Mit MQTT eingeschaltet war die Fehlermeldung, das die Config-Datei nicht passt. Damit konnte ich nichts anfangen. Habe den Fehler gefunden: (für die falsche Fehlermeldung) Zeile 987 ( https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/sw/lib/Ccollgate.py#L987 ) läuft auf Fehler. Daher wird Zeile 988 nicht ausgeführt. Und die Fehlermeldung in Zeile 995 ist falsch https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/sw/lib/Ccollgate.py#L995 Grund war, das ich kein paho-mqtt verfügbar hatte. mit apt install python3-paho-mqtt lief es dann. Keine Ahnung wieso ( sudo pip3 install paho-mqtt;) https://github.com/norberts1/hometop_HT3/blob/016b1899661b3414089c5d4799c0c6f46e4153d1/HT3/.mqtt_setup.sh#L69 nicht ausgereicht hat.
Markus J. schrieb: > ich habe die aktuelle Version neu aufgesetzt. Incl Debian 12 (bookworm) > Mit MQTT eingeschaltet war die Fehlermeldung, das die Config-Datei nicht > passt... Danke für die Fehlersuche und die Lösung. Ursache ist sicher nicht Debian 12 sondern wahrscheinlich die Verwendung von pip3 im Installation-Script. Habe dazu im Projekt einen neuen issue:29 aufgemacht und Details hinzugefügt. Siehe: https://github.com/norberts1/hometop_HT3/issues/29 Bearbeitung und Korrektur erfolgt alsbald. Gruß Norbert
Norbert S. schrieb: > Bearbeitung und Korrektur erfolgt alsbald. Habe ein neues Release: 0.7.2 erzeugt. Das Tool: pip3 wird nicht mehr für die Installation verwendet und das Modul: Ccollgate.py enthält verbesserte Fehlermelde-Ausgaben. Projektfiles siehe: https://github.com/norberts1/hometop_HT3/ Gruß Norbert
Hallo Norbert. Ich benötige wieder einmal deine Hilfe. Ich habe meinen Raspberry an der Heizung ausgetauscht da die Netzwerkschnittstelle defekt war. Nur bekomme ich aber mit der neuen Hardware (Rpi3) keine Daten. Ich habe die alte SD Karte versucht, sowie eine Neuinstallation. Beide male bekomme ich keine Daten. Hier kurz der Aufbau: RPI3 als Socket Server mit deinem ht_piduino unter 192.168.x.6 VM als Socket Client der die Datenbank, RRD und MQTT erledigt unter 192.168.x.137. Leider bekomme ich schon keine Ausgabe wenn ich im Browser 192.168.x.6:48008 aufrufe. Ebenso finde ich es komisch das die Ausgabe von ls /dev/tty* kein /dev/serial0 enthält. Ich bitte um einen Denkanstoß. lg Martin
Martin S. schrieb: > Ebenso finde ich es komisch das die Ausgabe von ls /dev/tty* kein > /dev/serial0 enthält. wie kommst du darauf mit ls /dev/tty* irgendwas mit serial0 zu finden? Ich würde etwas in der Richtung /dev/ttyAMA0 erwarten. Gruß Peter
> > wie kommst du darauf mit ls /dev/tty* irgendwas mit serial0 zu finden? > Ich würde etwas in der Richtung /dev/ttyAMA0 erwarten. > Ja das ist ein Schreibfehler. Du hast vollkommen recht, ich wollte mich auf ttyAMA0 beziehen. Martin
:
Bearbeitet durch User
Neuer Versuch mit neuem OS auf der SD Karte: .) nach der Installation --> kein ttyAMA0 kein serial0 .) Script ht_project_setup.sh ausgeführt --> kein ttyAMA0 kein serial0 Fehlersuche: Nach dem deaktivieren des BT Modules in der /boot/firmware/config.txt --> ttyAMA0 und serial 0 vorhanden nun folgender Fehler im ht_proxy: Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: self.RequestHandlerClass(request, client_address, self) Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: File "/usr/lib/python3.11/socketserver.py", line 757, in _init_ Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: self.finish() Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: File "/home/pi/HT3/sw/lib/ht_proxy_if.py", line 843, in finish Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: _ClientHandler.remove_client(self._myownID) Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: File "/home/pi/HT3/sw/lib/ht_proxy_if.py", line 733, in remove_client Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: txThread=self._thread.pop(clientID) Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: ^^^^^^^^^^^^^^^^^^^^^^^^^^ Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: KeyError: 5 Jan 14 18:32:29 heatpi3 ht_proxy.py[1005]: ---------------------------------------- es ist zum Verzweifeln. weiter Fehlersuche: User Pi in die gruppe tty hinzugefügt --> sudo adduser pi tty Reboot. aktuell kommen Daten !!!! noch ein Frage an Norbert, da ich das weder im Forum noch im Git gefunden habe. Sollte der Adapter für den Bus bei der Ausführung des Scripts schon aufgebaut und angeschlossen sein, oder macht es keinen Unterschied wenn nicht. Gruß Martin
Hallo Martin, es liegen offensichtlich zwei Fehler vor: 1. serial port nicht richtig konfiguriert. 2. Starten des proxy-servers 'ht_proxy.py' und Bind auf 'localhost' nicht erfolgreich. Folgendes hast Du sicher durchgeführt: - Neuinstallation des OS auf einem RPi3. - Neuestes HT3-Projekt Release installiert als user: 'pi'. - Aufruf des Installations-Scripts aus dem Release. Zu 1: Martin S. schrieb: > weiter Fehlersuche: > User Pi in die gruppe tty hinzugefügt --> sudo adduser pi tty > Reboot. Richtig ist: sudo adduser pi dialout Dies wird automatisch im Installations-Script gemacht. User pi sollte daher in der Gruppe 'dialout' sein. Die zugehörige(n) Schnittstelle(n) sind dann ebenfalls in dieser Gruppe. Dazu bitte auch 'sudo raspi-config' aufrufen und die serielle Schnittstelle prüfen bzw. richtig konfigurieren (siehe Bilder). Siehe auch URL: https://www.raspberrypi.com/documentation/computers/configuration.html#uarts-and-device-tree Zu 2: Das Starten des ht_proxy - Servers sollte auf die lokale Adresse 'localhost' immer möglich sein, wenn die serielle Schnittstelle richtig konfiguriert ist. Das bei Deinem System beim 'Bind' auf 'localhost' eine Exception geworfen wird kann ich mir nicht erklären, es sei denn das Du die default-Konfiguration verändert hast. > Sollte der Adapter für den Bus bei der Ausführung des Scripts schon > aufgebaut und angeschlossen sein, oder macht es keinen Unterschied wenn > nicht. Für eine Erstinstallation nicht erforderlich, für jede weitere ist dies jedoch besser weil eventuell noch die Prozesse laufen und noch die Datenerfassung läuft. Gruß Norbert
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.