Hallo, mit den letzten Änderungen Sieht es schon besser aus. Ich habe es allerdings nur im Analyser angeschaut – d.h. noch keine grafischen Auswertungen gemacht. 2 Norbert: Danke für die schnellen Anpassungen. Sage mir Bescheid, falls ich weitere Logs aufnehmen soll. Werde versuchen am Wochenende den Außenfühler anzuschließen, danach gibt es evtl. noch etwas Interessantes auszulesen. Gruß Juri
Hallo Stephan,
> Ist die DB zerschossen und ich muss sie neu aufbauen?
Nein, ich glaube nicht.
Es kann an den mehrfachen HK-Einträgen innerhalb 1 Sekunde liegen. Dies
mag das rrdtool für die gleichen Werte nicht.
Dieses Verhalten hattest Du ja weiter oben beschrieben und ist im
nächsten Release (0.1.8.1) beseitigt.
Kontrolliere mal den /tmp-Ordner. Eventuell sind dort einige xyz*.pl
Perl-scripte enthalten die genau auf diesen Fehler hindeuten.
Gruß Norbert
Hallo Norbert, ich versuche mich mit dem Format auseinander zu setzen, um eine openhab Binding zu programmieren. Dazu habe ich erst mal ein Paar grundlegende Fragen: *die 4 Bytes "0x23 0x48 0x52 0x11" (#HRDC1STX) scheint eine Trennsequenz zu sein - Stimmt es? *danach kommt ein Byte - weiß Du, was das ist? *danach kommt ein 4 bis X Bytes langes header, danach payload *die CRC, was danach kommt - wird es über das ganze Telegramm berechnet, inklusive Header oder nur über Inhalt? *Was ist ein Trennzeichen? Wieso ist es unterschiedlich? Wenn Du mir die Fragen beantworten kannst, komme ich ein gutes Stückchen weiter (Wahrscheinlich zu den komplizierteren Fragen) Gruß Juri P.S. Oder soll ich bei solchen Fragen lieber zu PM greifen?
Hallo Juri, die Telegramm-Struktur ist beschrieben in der ht_transceiver - Dokumentation. Doku und Sw erhälts Du mit: git clone https://github.com/norberts1/hometop_ht_transceiver.git Die Doku ist dann unter: ~/hometop_ht_transceiver/docu/ht_transceiver_messages.html Siehe dort Pkt.: 5.x für Heatronic. Der Header des ht_transceivers ist 5 Byte lang, danach die Payload und ein abschliessendes CRC-Byte über alles. Beispiel: #HR(11)h<laengenbyte><Payload><CRC> wobei: # := Tag als Header-Anfang (mehr oder weniger eindeutig) H := Heatronic Telegramm R := Received (11)hex ist Option-Byte und z.Zeit fest gesetzt. Wird jedoch noch geändert. Somit dies nicht auswerten. <laengenbyte> := Länge der im Telegramm enthaltenen Payload-Bytes. Dies ist die wohl wichtigste Angabe für Deine Auswertung. <Payload> := sind die Roh-Daten der Heizung. <CRC> := CRC über das gesamte Telegramm (Header+Payload) Dieser Header ist natürlich nur vorhanden wenn man einen ht_transceiver-Adapter hat (ht_pitiny oder ht_piduino). Ansonsten kommen natürlich nur die Roh-Daten der Heizung. Gruß Norbert
Hallo, @Alle Habe die Software auf github.com aktualisiert auf Version: 0.1.8.1 Fehlerhafte Dekodierungen für CWxyz Telegramme und doppelte Commits sind behoben. Entweder alles von github holen oder die betroffenen Module: ~/HT3/sw/lib/gui_worker.py Version-Nummer auf 0.1.8.1; Auto/Manuell ~/HT3/sw/lib/ht3_decode.py Dekodierung korrigiert ~/HT3/sw/lib/ht3_dispatch.py Doppelte Commits beseitigt Die Datenbanken müssen nicht neu angelegt werden falls schon vorhanden. Gruß Norbert
Hallo Norbert, good news and bad news: Die HK1-Daten kommen jetzt eindeutig, also keine mehr doppelt. Es kommen vergleichsweise wenig und unregelmäßig, aber es kommen schon einige pro Stunde. HG und WW nach wie vor einwandfrei, auch in den Grafiken Aber: In der Grafik absolut keine Anzeige. Ich habe sogar mal die heizkreis1.rrd neu erstellen lassen aber der (angehängte) Dump zeigt zwar immer aktuelle Werte als lastupdate, aber die Statistikdaten nur "NaN". - Lohnt es sich hier noch weiter zu gucken oder soll ich Image neu machen und HT3 neu installieren? - Falls ich noch gucken soll: Welches Programm überträgt die Daten von sqlite in rrdtool und kann ich das auch manuell ausführen um evtl. Fehlerausgaben sehen zu können? Danke und Gruß, Stephan
Hallo Stephan, aus Deinem sqlite-db Dump sehe ich nur 0 in den Spalten 'T_Soll_HK' und 'V_betriebs_art' und im Hexdump sind dort die Werte ebenfalls Null. Allein dies ist schon ein wenig seltsam. Relevante Werte sind: Byte: 6/7 --> T_Ist Ist ja soweit OK. Byte:12 --> T_Soll Ist nur NULL !!!!??????????? Byte:27 --> V_betriebs_art Nur NULL !!!!!!???????? Im test2.xml File sind dann diese Werte natürlich auch Null. Es liegt also gar kein Fehler der Datenbanken vor, sondern im Telegramm sind die Werte einfach Null. Warum ?. Hast Du eine Einstellung verändert am CW400 für diesen Heizkreis? In Deinem Binär-logfile sind diese Werte noch gesetzt und enthalten. Werde dies aber zum x-mal noch laufen lassen. Bitte kontrolliere also die Einstellungen für die Heizkreise am CW400. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, anscheinend sind die Werte in der Tagabsenkung tatsächlich 0. Laut Zeitprogramm müsste tagsüber der Zielwert der Raumtemperatur bei 19 liegen. Also insofern keine Ahnung warum das 0 ist. Ich habe nur etwas geändert an der Absenkart und dem Frpstschutz, aber das Zeitprogramm und seine Temperaturen hab ich nicht angefasst. Blöderweise bin ich tagsüber nicht da, um die Ausgaben zu kontrollieren. Aber egal ob die 0 korrekt ist oder nicht, er zeigt ja nicht mal die 0 an. Aktuell ist T_Soll 21 und Betriebsart 3, also sind die Bytes anscheinend korrekt. Ich habe Dir mal auch den aktuellen rrd-Dump angehängt. Da zeigt er bei "last_ds" tatsächlich den aktuellen Wert, aber "value" ist immer NaN. Gruß, Stephan
Noch etwas: Vielleicht ist die Betriebsart gar nicht Byte 27, sondern 17. Denn da passt es mit 1 für Sparen (oder Frost) und ab 15 Uhr dann 3 für Heizen.
Hallo Stephan, das zugehörige Telegramm (33Byte Länge) kommt bei Deinem System sehr selten (15 bis ca. 30 Minuten). Somit wird auch nur sehr selten ein Wert in die rrdtool-db eingetragen. Da diese mit 60 Sekunden Timing eingestellt ist und in der Zeit kein Wert gekommen ist wird dort dann automatisch der Default Wert Null eingetragen. Die paar gültigen Werte innerhalb von 30 Minuten kann man dann in der Grafik nicht mal mehr als Pixel wiederfinden. Somit hast Du eine schöne bunte Null-Linie in der HK-Grafikanzeige. Es hilft Dir nicht viel einen Dump der rrdtool-db zu irgend einem Zeitpunkt zu machen, Du wirst zu 96.66% dort dann den Nix-Wert finden. Bei Juri kommen diese Telegramme etwas häufiger. Mal sehen was sein Test bringt. Allerdings gibt es von diesem Telegramm-Typ kürzere Exemplare mit einer Untermenge der Informationen die häufiger gesendet werden. Bitte mach deshalb noch einmal ein binär-logfile über ca. 2 Stunden in der dieser Heizkreis nicht gerade im Schlaf-/Urlaub- etc. Modus ist. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, anbei das Log. Ich hoffe, es ist ok. Ich habe extra etwas länger gemacht, damit der Wechsel von Tag auf Nacht um 23 Uhr mit dabei ist. Im übrigen zeigt der Regler nach 23 Uhr sowohl als Soll-Raumtemperatur als auch als Betriebsstatus "Aus" an. Insofern würde hier eine 0 tatsächlich passen. Vor 23 Uhr war es 21 Grad und Heizen. Aber so wie Du schreibst sind die Werte egal, denn mit so seltenen Werten kann rrdtool nicht arbeiten. Wer sendet eigentlich die Telegramme? Die Heizung oder der Regler? Denn vor dem Reglerwechsel hatte ich ja einwandfreie Daten vom Heizkreis... Gibt es ein Tool, mit dem man das Log in "lesbare" Form bringen kann? Also z.B. 1 Zeile Pro Telegramm und alle Werte in Hex? Danke und Gruß, Stephan
Hallo Stephan, danke für das Logfile. Werde es analysieren. > Wer sendet eigentlich die Telegramme? Die Heizung oder der Regler? Beide, wobei die Heizung bzw. Steuerung der Taktschläger ist und die angeschlossene Perpherie taktvoll darauf antworten darf. Wobei Telegramme mit Struktur: GA 00 xy zw ... die Echo-Telegramme der Heizung von Telegrammen der Periperie sind, wobei hier: GA:='Geräteadresse mit MSB aktiv' und anschliessende 00 := 'An Alle' bedeuten. > Gibt es ein Tool, mit dem man das Log in "lesbare" Form bringen kann? Ja, heisst: HT3_Analyser.py :-) Um dies zu aktivieren musst Du im Konfigurationsfile ./sw/etc/config/HT3_db_cfg_.xml den Eintrag: <inputtestfilepath> anpassen auf absoluten Pfad mit Logfilename. Beispiel: <parameter name="ASYNC"> <serialdevice>/dev/ttyAMA0</serialdevice> <inputtestfilepath>/meinPfad/meinlogfile.log</inputtestfilepath> <baudrate>9600</baudrate> <config>"8N1"</config> <!-- only 8N1 available --> </parameter> Weitere Änderungen sind nicht erforderlich. Die Datenbanken werden damit natürlich nicht in Echtzeit sondern so schnell als möglich gefüllt. Somit sind die grafischen Ausgaben des rrdtool nicht wirklich nutzbar und es wird alles komprimiert dargestellt. Rückgängig machst Du dies wieder indem Du den Pfad/logfile-Eintrag wieder löscht, also: <inputtestfilepath></inputtestfilepath> Gruß Norbert
Hallo, ich habe in meiner Konfiguration mit FW200 ein Problem mit dem Telegramm 0xA1 0x00 0x34... Die Daten werden fälschlicherweise dem Warmwasser zugeordnet was zu den Peaks in der Grafik führt. (siehe Anhang). Im Augeblick ist mir noch nicht klar um welche Daten es sich handelt. Gruß Klaus
Hallo Klaus, > 0xA1 0x00 0x34... Die Daten werden fälschlicherweise dem Warmwasser > zugeordnet Die Zuordnung ist schon richtig, die Werte im Telegramm sind falsch warum auch immer. Die korrekten Werte kommen bei Deinem System vom Telegramm: 0x88 x00 0x34 0x00... Aber auch das Telegramm 0xA1 0x00 0x34 ist für Warmwasser-Meldungen vorgesehen. In diesem Fall kommt die Meldung vom Schaltmodul IPM2 für den Warmwasser-Betrieb. Wie ist Dein System aufgebaut? Ich nehme mal an das Du neben dem FW200-Regler noch ein Schaltmodul IPM2 eingebaut hast welches den einen Kanal für den Heizkreis und den anderen Kanal für Warmwasser-Erzeugung verwendet. Auf jeden Fall sind die Werte im Telegramm falsch. Ein Binär-logfile wird da weiterhelfen. Wie Du Logfiles erstellen kannst findest Du unter: Beitrag "Re: Heizungs-Datenerfassung (HT3)" ff Gruß Norbert
Hallo Norbert, ich hatte das mit dem Logfile schon versucht. Ich bekomme allerdings eine Fehlermeldung wenn ich einen zweiten Client (binlogclient) starte. Bin noch am Testen woran das Problem liegt. Gruß Klaus
Hallo Klaus,
> Ich bekomme allerdings eine Fehlermeldung
wie lautet die Fehlermeldung?
Ich nehme mal an das Du den ht_proxy.server auf dem Raspberry laufen
hast.
Dann kannst Du das Tool: ht_binlogclient.py direkt auf dem Raspberry
aufrufen. Dies läuft dann mit der Host-adresse: 'localhost'.
Oder Du rufst dieses Tool von einem anderen Rechner auf, dann bitte die
Server-Adresse im Config-File auf dem anderen Rechners anpassen:
./sw/etc/config/ht_proxy_cfg.xml.
<serveraddress>192.168.xxx.yyy</serveraddress>
Hast Du überhaupt ein IPM Schaltmodul in Deinem Heizungssystem?
Falls nicht ist das Telegramm ohnehin eine Fehldetektion.
Gruß Norbert
Norbert S. schrieb: > Ja, heisst: HT3_Analyser.py :-) Hallo Norbert, was ich eigentlich meinte: Die HK-Telegramme kommen ja von der Heizung und nicht vom Regler und vor dem Reglerwechsel hatte ich immer einwandfreie Daten vom HK mit der Version vom Jan 15. Also gibt es für mich nur 3 Möglichkeiten: - Durch den neuen Regler ist die Steuerung der Heizung umgestellt, so dass sie jetzt andere Telegramme unbekannter Art sendet - Für die neuen Scripte musste ich ja auch auf die aktuelle Software mit ht_proxy aktualisieren. Entweder hab ich dabei etwas falsch gemacht oder vergessen und deswegen kann die Software nicht alle Telegramme erkennen - Die Telegramme kommen tatsächlich so selten, aber mit dem alten Regler und der alten Software lief es Da der HT_Analyser ja doch nur wieder die Daten darstellen kann, die er kennt, dürfte es doch egal sein, ob ich ihn anstelle des Loggers laufen lasse oder ein Logfile einlese, oder? Unbekannte Daten könnte er nicht anzeigen, denn beim normalen Mitlaufen lassen sehe ich nur die Daten, die auch in der DB ankommen. Was ich deshalb wollte: Das Binärlog so formatieren, dass es jeweils die Hexdumps eines Telegramms auf einer Zeile darstellt, ohne dass ich auf irgendeine Dekodierung angewiesen bin. Dann könnte ich sortieren und gucken, welche Telegrammart denn wie oft kommt und die bekannten rausfiltern. Gruß, Stephan
Hallo Stephan, > Die HK-Telegramme kommen ja von der Heizung und nicht vom Regler. Ja und Nein. Die meisten der dekodierten Telegramme sind Echo's VON der HEIZUNG aus Telegrammen der PERIPHERIE (zumindest die Telegramme 'An Alle'). Wenn Du also einen neuen Regler mit NEUEN Telegramm-Eigenschaften hast erhälst Du auch neue Telegramme. Die Heizung erkennt ohnehin den Reglertyp aus separaten anderen Telegrammen und stellt sich drauf ein. > Da der HT_Analyser ja doch nur wieder die Daten darstellen kann, die er > kennt ... Stimmt, liegt an der Dekodierung die aber erweiterbar ist. Und genau darum geht es ja. > Was ich deshalb wollte: Das Binärlog so formatieren dass es jeweils die > Hexdumps eines Telegramms auf einer Zeile darstellt Ich habe eine Tool (Pre-Version) in Arbeit die aus dem Binälog-File ein CSV-File generiert. Dann kann man die Telegramme mit LibreOffice oder Excel bearbeiten (filtern etc.) Dies läuft noch nicht ganz rund, kann es hier aber alsbald bereitstellen. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, jetzt hat sich der binlog starten lassen. Allerdings ist der logger daraufhin abgebrochen und lies sich nicht mehr nachstarten. 12.02.2016 16:11:38 CRITICAL: ht3_cworker();Error;couldn't open requested socket; cfg-file:/home/pi/HT3/sw/etc/config/ht_proxy_cfg.xml Ich musste dann 2x !!! neu booten, bevor proxy und logger wieder liefen. Ich habe nicht weiter analysiert, ob der Port nicht geöffnet war. Die Meldung deutet ja darauf hin. Früher hatte ich schon mal folgende Meldung, wenn ich einen zweiten Client am Proxy anmelden wollte: "Client-ID:{0};cportwrite();couldn't read from queue" Ich muss mal bei Gelegenheit prüfen, ob mein Softwarestand richtig ist. Wenn man nur den proxy mit logger laufen lässt dann funktioniert das seit 2 Monaten ohne Probleme. Anbei noch ein Logfile und die Anlagenkonfiguration. BTW: das 0xA1 0x00 0x34 scheint auch länger zu sein als es im dispatcher erwartet wird. Gruß Klaus
Hallo Klaus, das Telegramm: 0xA1 0x00 0x34 ist eine Fehldetektion da Dein IPM2 Modul nichts mit der Warmwasser-Erzeugung zu tun hat. Zufällig stimmt bei diesem 'Telegramm' in Deinem System die CRC am Ende und deshalb werden die Werte auch verwendet. Der Inhalt ist aber falsch und hat rein gar nichts mit WW zu tun. Deshalb ist folgende Anpassung an der Software erforderlich: Modul: ht3_decode.py Fkt : IPM_LastschaltmodulWWModeMsg() Zeile: 547 Ist: if self.crc_testen(buffer,length) == True: Soll: if((self.crc_testen(buffer,length)==True) and (buffer[length-1]==0)): Probier es aus, ich hoffe dies beseitigt diesen Fehler in Deinem System. Ein Test bei mir mit Deinem Logfile hat jedenfalls Wirkung gezeigt. Gruß Norbert
Hallo Norbert, danke für deine Antwort. Ich hatte die Auswertung für das Telegramm einfach auskommentiert. Inzwischen tendiere ich dazu, dass es sich bei den Werten um die Rücklauf Temperaturen handeln könnte, da diese in der jetzigen Konfiguration immer 0 ist. Allerdings kommt das Telegramm relativ selten. Gruß Klaus
Hallo Klaus, > Inzwischen tendiere ich dazu, dass es sich bei den Werten um die Rücklauf > Temperaturen handeln könnte,... Sicher nicht, es ist eine Fehldetektion die ich mit dieser Anpassung hoffentlich behoben habe. Es sind im Telegramm Polling-Bytes des Masters mit Antworten eines Slaves (Peripherie) enthalten: 09 89 ... die dort in ein gültiges Telegramm nicht hingehören. Bitte probiere es aus, weil ich im Gutfall dies mit in das nächste Release übernehme. Du bist in diesem Fall der Problemmelder und der Softwaretester weil Du ein System mit IPM-Schaltmodul hast. Ein IPM-Modul habe ich selber nicht, deshalb kann ich dies auch nicht wirklich überprüfen. Andere die auch ein IPM-Modul haben wären Dir also recht dankbar wenn Du noch den letzten Schritt (ein kleiner für Klaus) machen würdest. Danke im Voraus! Gruß Norbert
Hallo Norbert, Ich habe mir für die Zeit bis zum nächsten Release ein kleines php Script geschrieben, was jede Minute aufgerufen wird und den jeweils letzten wert mit aktuellem timestamp in die DB schreibt. Und schon hab ich grafische Ausgaben. Damit wäre bewiesen, dass es tatsächlich nur zu wenige werte sind und sonst alles okay ist. Zusätzlich habe ich den betriebszustand 0 in -1 geändert, damit nicht 2 Werte auf der nulllinie rumlungern. Ist zwar so jetzt möglicherweise nicht zeitlich exakt, aber man kann damit arbeiten und ich kann mit den verschiedenen Absenkmodi experimentieren. Was die machen, machen die ja immer dann, wenn man außer Haus ist oder im bett. Gruß, Stephan
Hallo Norbert, deine Änderung scheint zu funktionieren. Wenn es nicht die Rücklauftemperaturen sind, dann muss es noch ein weiteres Telegramm geben, da diese Werte im FW200 angezeigt werden. Gruß Klaus
Klaus schrieb: > Hallo Norbert, > > deine Änderung scheint zu funktionieren. > > Wenn es nicht die Rücklauftemperaturen sind, dann muss es noch ein > weiteres Telegramm geben, da diese Werte im FW200 angezeigt werden. > > Gruß > Klaus Einige Telegramme scheinen doch noch durchzukommen. Sieht aber aus, als ob es weniger sind.
Hallo Klaus, danke für die Info und den Test. Werde es somit in das nächste Release mit aufnehmen. Trotzdem werde ich noch weiter den Dekoder verbessern und möglichst robust machen. Dafür sind die Logfiles Gold wert! Gruß Norbert
Hallo Norbert, hast Du schon eine Idee, wann Du eine neue Version herausbringen möchtest, so dass die HK-Daten auch bei den CW's wieder zeitnah erfasst werden können? Das "Füllen" der Lücken ist ja doch keine wirkliche Lösung. Gerne würde ich auch das Tool nutzen, um Logfiles in csv umzusetzen. Dann kann ich ja mal besser sehen, welche Arten von Daten wie oft kommen. Herzlichen Dank, Stephan
Hi. Hat von euch schon jemand es hinbekommen Kommandos mit ht_netclient.py über PHP anzusteuern. Bei mir will es einfach nicht klappen und ich würde gerne über einen Webservice im Apache die Modus umschalten. Viele Grüße, Nils
Hallo, @Stephan > hast Du schon eine Idee, wann Du eine neue Version herausbringen möchtest? Nicht vor Ostern. > Gerne würde ich auch das Tool nutzen, um Logfiles in csv umzusetzen. Ist in Arbeit. @Nils > Hat von euch schon jemand es hinbekommen Kommandos mit ht_netclient.py > über PHP anzusteuern ? Wenn Du ht_netclient.py von php aufrufst ist das Environment (Pfade) wichtig. 'ht_netclient.py' findet sonst u.U. die verwendeten Libraries nicht. Diese liegen ja im Verzeichnis ~/HT3/sw/lib. Siehe Aufrufe im script 'ht_netclient.py': ... sys.path.append('lib') import ht_proxy_if, ht_transceiver, ht_yanetcom ... Gruß Norbert
Hallo,
@Stephan
> Gerne würde ich auch das Tool nutzen, um Logfiles in csv umzusetzen.
Dies Tool: 'ht_bin2csv.py' habe ich als Tar-file angehängt.
Es extrahiert die binären Heatronic-Telegramme so gut es geht und
schreibt es formatiert in ein separates CSV-File.
Dies funktioniert mit Logfiles vom ht_transceiver-Adatper (mit eigenem
Header) aber ebenso mit reinem binären HT-Telegrammen.
Eine 100% korrekte Detektion und Formatierung wird jedoch mit reinem
binären HT-Telegrammen nicht erreicht. Da ist noch Nacharbeit
erforderlich.
Im Modulkopf ist eine kurze Beschreibung enthalten.
Gruß Norbert
:
Bearbeitet durch User
Norbert S. schrieb: > Wenn Du ht_netclient.py von php aufrufst ist das Environment (Pfade) > wichtig. > 'ht_netclient.py' findet sonst u.U. die verwendeten Libraries nicht. > Diese liegen ja im Verzeichnis ~/HT3/sw/lib. > Siehe Aufrufe im script 'ht_netclient.py': > ... > sys.path.append('lib') > import ht_proxy_if, ht_transceiver, ht_yanetcom > ... > > Gruß Norbert Hi, ich hab die Pfade nun angepasst und auch noch im Skript einen Verweis auf die Konfiguration (... ./etc/..) angepasst. Leider stehen an mehreren anderen stellen noch relative Pfade, sodass ich noch den angehängten Fehler bekomme. Kann ich die Pfade ggf. an einer Stelle anpassen? Viele Grüße, Nils
Hallo Nils, beim Überfliegen der Ausgabe ist mir aufgefallen, dass er wohl Probleme beim Logging hat. Du startest das Script in /home/pi/HT3/sw, das Log soll aber angelegt werden in /home/pi/var/log (ohne HT3). Gibt es das Verzeichnis so überhaupt? Gruß, Stephan
Norbert S. schrieb: > Es extrahiert die binären Heatronic-Telegramme so gut es geht und > schreibt es formatiert in ein separates CSV-File. Hallo Norbert, ich habe das Tool mal genommen und mein am 11.2. hochgeladenes cw400.log durchlaufen lassen. Für die Daten, die laut HT_Analyzer Daten für den Heizkreis 1 sind, nämlich 90 00 FF 00 01 A5, zeigt er im csv aber statt einem 33-Byte-Telegramm eines mit der Länge 10: 10.02.2016;19:49:43;10;90;00;ff;00;01;a5;00;d4;4a;00; Alle Telegramme mit diesen ersten 6 Bytes haben nur 10 Bytes Länge. Die 88 00 18 Telegramme hingegen haben die Solllänge von 31 Bytes. Mach ich was falsch oder liegt es einfach daran, dass das Tool nicht 100% dekodieren kann? Gruß, Stephan
Hallo, @Nils > Leider stehen an mehreren anderen stellen noch relative Pfade, sodass > ich noch den angehängten Fehler bekomme. Kann ich die Pfade ggf. an > einer Stelle anpassen? Die Pfade in den Python-scripten sind relativ und werden auch so bleiben damit man die gesamte Applikation in einen Pfad seiner Wahl legen kann. Damit der Aufruf der Scripts von PHP klappt musst Du VOR dem Aufruf des scripts:'ht_netclient.py' in den ABSOLUTEN Pfad wechseln in dem dieses Script steht. Eine Anpassung der scripte auf absolute Pfade würde ich tunlichst vermeiden zumal dies nach jedem SW-Update wieder erforderlich ist. @Stephan > ... oder liegt es einfach daran, dass das Tool nicht 100% dekodieren kann? Ja, hatte ich erwähnt. Gruß Norbert
Norbert S. schrieb: > Du VOR dem Aufruf des > scripts:'ht_netclient.py' in den ABSOLUTEN Pfad wechseln in dem dieses > Script steht. Das hatte ich schon mal drinnen, aber dort hatte er die Bibliotheken trotzdem nicht gefunden. Ich hab die Pfadänderung wieder ergänzt und es funktioniert. :-) Also folgende Sachen waren zu tun für andere: - sys.path.append('/home/pi/HT3/sw/lib') <- absoluter Pfad eintragen - Folgenden Code im PHP aufrufen: function setzeModus2($modus) { chdir("/home/pi/HT3/sw/"); // Modi: auto, heizen, sparen frost $command = "sudo /home/pi/HT3/sw/ht_netclient.py -b " . $modus; $read = exec($command); echo $command; echo $read; } Kann ich den aktuellen Modus eigentlich auch live auslesen, um im Web den Status anzuzeigen oder müsste ich dafür auf die SQLite Datenbank abfragen? Viele Grüße, Nils
:
Bearbeitet durch User
Hallo Nils, prima das es jetzt läuft. Es ist zwar ein absoluter Pfad drin aber wohl nur in diesem Modul. Ich werde jedoch diese Pfadangabe weiterhin relativ belassen und somit muss jeder selber manuell den Pfad in dem Modul auf seine Installations-Pfade anpassen. > Kann ich den aktuellen Modus eigentlich auch live auslesen, um im Web > den Status anzuzeigen oder müsste ich dafür auf die SQLite Datenbank > abfragen? Zur Zeit geht eine Abfrage einzelner Werte nicht und man muss die RAW-Daten selber dekodieren und den benötigten Wert rausfischen. Es ist jedoch ein Zusatzmodul in Arbeit welches genau dies realisiert. Die Dekodierung ist dann nur einmal zentral nötig. Dies und noch mehr muss jedoch noch in ein neues SW-Release hinein. Kurzfristig ist daher eine Abfrage der Datenbank die schnellere Lösung um an den Wert zu kommen. Gruß Norbert
Hallo, habe jetzt noch den Außentemperatur Sensor installiert und damit ein wenig geloggt - evtl. kann es verwendet werden. Dabei sind auch meine Versuche, die Parameter über ht_netclient zu setzen - Temperatur auf 25 Grad und Betriebsart auf Frost. Leider erfolgslos, aber evtl. ist etwas in dem Log zu sehen? Gruß Juri
Hallo, ich habe die HTML Datei (index.html) so erweitert, dass sich die Anzeige jede Minute aktualisiert. D.h. man muß nicht mehr explizit nachladen. Das ist z.B. dann praktisch, wenn man den raspi zur Anzeige an einen TV anschliesst, ohne dass eine Tastatur angeschlossen ist. Hier die Änderung: <HTML> <HEAD> <TITLE>Heizungs-Historie</TITLE> <script type="text/javascript"> window.onload = function() { // reload images function updateImage() { var images = document.getElementsByTagName('img'); for(var i=0; i < images.length ;i++){ var source = images[i].attributes.src.nodeValue.split("?")[0]; images[i].src = source+"?"+Date.now(); } } // reload every minute setInterval(updateImage, 60*1000); } </script> </HEAD> .... Gruß Klaus
Hallo, @Alle Habe die Software auf github.com aktualisiert auf die Version: 0.1.9 Grund sind ein paar Korrekturen für die Telegramm-Auswertung der Cxzy-Regler. Wer es komplett mag bekommt alles mit: git clone https://github.com/norberts1/hometop_HT3.git Wer keinen CW100/400 bzw. CR100... Regler hat braucht dieses Update nicht. @Stephan (Gast) Bitte probiere dieses Release aus, die Auswertung ist verbessert. Habe mit Deinem Binaerfile getestet und die Telegramme (auch mit 10 Byte Länge) Deines CW400 werden besser ausgewertet. @Klaus (Gast) > habe die HTML Datei (index.html) so erweitert, dass sich die Anzeige > jede Minute aktualisiert. Danke für die Erweiterung. Die klappt gut und ich habe diese mit in das Release 0.1.9 übernommen. Gruß Norbert
Hallo Norbert, schön wieder von Dir zu hören. Ich werde das in den nächsten Tagen mal probieren. Etwas knapp an Zeit. Oder reicht es, ein paar Dateien auszutauschen? Wenn ja, welche? Danke und Gruß, Stephan
Hallo Stephan T., lass Dir mit dem Testen Zeit. Ich habe ja Deine Logfiles und brauche auch keine Neuen. Es kommt auch so schon keine Langeweile bei mir auf :-) Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, habe nur die 3 ht3_*.py in lib ausgetauscht, denn alles andere sieht ja laut GIT unverändert aus. Meine HK-Meldungen kommen jetzt alle 1-2 Minuten, manchmal aber auch 3 Minuten Pause, was dann im Graphen kleine Lücken produziert. Insofern bleibe ich erstmal bei meinem Workaround, alle Minute den jeweils letzten Wert nochmal in die DB zu schreiben. Aber zumindestens sehe ich Statusänderungen jetzt sofort. Weiterhin ist mir aufgefallen, dass jetzt wieder fast alle Werte doppelt kommen. Das war doch schon mal gefixt, oder? Mich stört es jetzt nicht so, denn RRD kommt damit anscheinend klar und die Werte werden sowieso nach 3 Tagen gelöscht. Aber bei anderen könnte die DB unnötig wachsen. Eine kleine Sache noch: Bei Betriebsart Sparen kommt beim CW als Betriebsart eine 0 und auch als Solltemperatur eine 0. Wo kann man es so anpassen, dass er Betriebsart 0 als 2 schreibt, damit einerseits nicht 2 Werte denselben Graphen schreiben und dann auch noch die Legende stimmt? Danke und Gruß, Stephan
Hallo Stephan, > Wo kann man es so anpassen, dass er Betriebsart 0 als 2 schreibt, damit > einerseits nicht 2 Werte denselben Graphen schreiben und dann auch noch > die Legende stimmt? Die Anpassung kannst Du im perl-script:rrdtool_draw.pl machen wie folgt: In Heizkreis1: Zeilen 403 ff folgendes anpassen ########test fuer Forum ################## draw => { dsname => 'V_betriebs_art', ## name => 'Betriebsart', name => 'betriebs_art_fkt', type => 'hidden', ## legend => 'Betriebsart (3=Heizen 2=Sparen 1=Frost)\l', ## thickness => 2, ## color => '808080' }, draw => { legend => 'Betriebsart (9=Eco 8=Comfort 7=Manual 6=Summer 5=Off)\l', thickness => 2, color => '808080', cdef => "betriebs_art_fkt,5,+" }, Kurze Erklärung: 1. Der draw fuer dsname => 'V_betriebs_art' wird hidden und erhält einen neuen Namen name=>'betriebs_art_fkt' 2. Es wird ein Neuer draw angelegt der jetzt die Arbeit macht: 2.1 legende schreiben (hier ist der Offset mit 5 schon eingerechnet) 2.2 zum Datenbankwert 'V_betriebs_art' wird der Wert 5 addiert. Nach meien Unterlagen sind die Betriebsart-Werte bei den CR/CW/CTxyz Reglern wie folgt: 0 := Off 1 := Summer 2 := Manual 3 := Comfort 4 := Eco Somit ist Dein angezeigter Wert nicht 'Sparen' sondern 'Off' gewesen. Bei 'Off' spart man ja auch besonders viel :-) > Weiterhin ist mir aufgefallen, dass jetzt wieder fast alle Werte doppelt > kommen. Dies schau ich mir noch an. Die Software ist sowieso in Arbeit und die Baustellen werden nur langsam weniger. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, habe das eingebaut und es ist besser als vorher. Aber kann ich es so machen, dass er tatsächlich nur den Betriebsart-Wert 0 auf -1 setzt, aber keinen anderen ändert? Denn momentan zeigt die Grafik den Wert 0 der Temperatur nicht an, denn er liegt auf der unteren Linie. Das war in meinem temporären Workaround besser sichtbar, als ich einen Wert bei -1 hatte. Danke und Gruß, Stephan
:
Bearbeitet durch User
Moin Norbert und alle anderen, bin gestern auch mal dazu gekommen deine Software endlich in Betrieb zu nehmen. Bis auf zwei Dinge klappt auch alles soweit super, vielen Dank dafür! Zum einen bekomme ich keinerlei Daten zur Solarthermie. Ich habe eine einfache ZSB 14-4 mit einem Heizkreis und integriertem Mischer, dazu den MS100 für einen einfachen Solarkreis und den CW400 als Regler. Wird davon etwas nicht richtig decodiert? Kann ich evtl. mit Logfiles aushelfen? Zum anderen ist die kleinste Auflösung in den Graphen ein Schritt von 5 Minuten, obwohl zumindest in der SQL-Datenbank deutlich mehr Daten vorliegen. Der Graph im Anhang zeigt zum Beispiel in der Zeit von 0710 bis 0725 nur drei Schritte, obwohl in der Datenbank ganze 9 Schritte in über 60 erfassten Werten vorliegen (siehe unten). Ist das eine Einstellungssache oder läuft da bei mir was nicht ganz rund? Vielen Dank schonmal und schönen Gruß, Lasse
1 | 14.06.2016 07:09:55 26.2 |
2 | 14.06.2016 07:10:04 26.2 |
3 | 14.06.2016 07:10:24 26.2 |
4 | 14.06.2016 07:10:34 26.1 |
5 | 14.06.2016 07:10:45 26.1 |
6 | 14.06.2016 07:11:04 26.1 |
7 | 14.06.2016 07:11:34 25.9 |
8 | 14.06.2016 07:12:04 25.9 |
9 | 14.06.2016 07:12:14 25.9 |
10 | 14.06.2016 07:12:34 25.8 |
11 | 14.06.2016 07:12:54 25.8 |
12 | 14.06.2016 07:13:04 25.6 |
13 | 14.06.2016 07:13:14 25.6 |
14 | 14.06.2016 07:13:23 25.6 |
15 | 14.06.2016 07:13:44 25.6 |
16 | 14.06.2016 07:13:55 25.5 |
17 | 14.06.2016 07:14:04 25.5 |
18 | 14.06.2016 07:14:14 25.5 |
19 | 14.06.2016 07:14:33 25.5 |
20 | 14.06.2016 07:15:03 25.4 |
21 | 14.06.2016 07:15:13 25.4 |
22 | 14.06.2016 07:15:33 25.4 |
23 | 14.06.2016 07:15:43 25.4 |
24 | 14.06.2016 07:15:55 25.4 |
25 | 14.06.2016 07:16:03 25.4 |
26 | 14.06.2016 07:16:13 25.4 |
27 | 14.06.2016 07:16:43 25.4 |
28 | 14.06.2016 07:17:33 25.2 |
29 | 14.06.2016 07:17:43 25.2 |
30 | 14.06.2016 07:18:13 25.2 |
31 | 14.06.2016 07:18:22 25.2 |
32 | 14.06.2016 07:18:43 25.2 |
33 | 14.06.2016 07:19:02 25.2 |
34 | 14.06.2016 07:19:13 25.2 |
35 | 14.06.2016 07:19:55 25.2 |
36 | 14.06.2016 07:20:02 25.2 |
37 | 14.06.2016 07:20:13 25.2 |
38 | 14.06.2016 07:20:22 25.2 |
39 | 14.06.2016 07:20:32 25.2 |
40 | 14.06.2016 07:20:53 25.2 |
41 | 14.06.2016 07:21:02 25.2 |
42 | 14.06.2016 07:21:12 25.2 |
43 | 14.06.2016 07:21:21 25.2 |
44 | 14.06.2016 07:21:32 25.2 |
45 | 14.06.2016 07:21:55 25.2 |
46 | 14.06.2016 07:21:55 25.2 |
47 | 14.06.2016 07:22:02 25.2 |
48 | 14.06.2016 07:22:31 25.2 |
49 | 14.06.2016 07:22:53 25.2 |
50 | 14.06.2016 07:22:53 25.2 |
51 | 14.06.2016 07:23:01 25.2 |
52 | 14.06.2016 07:23:12 25.2 |
53 | 14.06.2016 07:23:31 25.2 |
54 | 14.06.2016 07:23:41 25.2 |
55 | 14.06.2016 07:23:55 25.2 |
56 | 14.06.2016 07:24:11 25.2 |
57 | 14.06.2016 07:24:21 25.1 |
58 | 14.06.2016 07:24:31 25.1 |
59 | 14.06.2016 07:24:41 25.1 |
60 | 14.06.2016 07:24:53 25.1 |
61 | 14.06.2016 07:25:11 25.1 |
62 | 14.06.2016 07:25:31 25.1 |
63 | 14.06.2016 07:25:41 25.1 |
Hallo Lasse, das mit den 5 Minuten ist ok, denn RRD arbeitet fest mit diesem Intervall. Es gibt einige Anleitungen, wie man das öfter laufen lassen kann, aber ich glaube nicht, dass das hier nötig ist. Schließlich geht es ja eher um eine Übersicht/Tendenz als um eine minutengenaue Anzeige. Gruß, Stephan
Stephan, danke für den Hinweis. Dann muss ich mir bei Bedarf was einfallen lassen und die SQL-Daten mit Excel darstellen oder so. Meine Heizung ist nämlich vom "Fachmann" so eingestellt worden, dass sie durchaus mal Brennerlaufzeiten von unter einer Minute produziert, was ich persönlich für nicht akzeptabel halte und mit den aufgezeichneten Daten darstellen wollte. Gruss, Lasse
Hallo Lasse, das mit den Brennerlaufzeiten von 1 min ist wirklich nicht akzeptabel. Im Moment könnte es zwar vorkommen, da manchmal die Soll-Vorlauf-Temperatur nur wenig höher liegt als die Ist-Temperatur, aber wenn es wieder kälter wird dann darf das nicht mehr sein. Meine Anlage (auch eine 14-4) schafft es bei kälteren Temperaturen locker 1 Stunde die Temperatur zu halten und eben nur soviel Leistung zu erzeugen wie benötigt wird. Brennwerteffekt stellt sich laut meinem Monteur erst nach 10-15 Minuten ein. Gruß, Stephan
Hallo Lasse, noch etwas: die Datenerfassung solltest Du NICHT verwenden, um deinem "Fachmann" oder Junkers etwas beweisen zu wollen. Es ist unklar, wie die reagieren, wenn Nicht-Junkers-Geräte am Bus hängen. Es könnte die Garantie gefährden... Gruß, Stephan
Hallo Lasse, > Zum anderen ist die kleinste Auflösung in den Graphen ein Schritt von 5 > Minuten, obwohl ... Für das Timing der Grafen ist der cron-job zuständig, dort kannst Du die Zeit reduzieren auf z.B. 2 Minuten. Hinweis: Es werden alle 60 Sekunden neue Daten in die rrd-db geschrieben, schneller macht keinen Sinn, da einige Telegramme nur 1mal pro Minute kommen und der Raspberry (je nach Version) dann gut zu tun hat. Beispiel: Den Aufruf im cron-job ändern auf 2 Minuten */2 * * pi /usr/bin/perl -S rrdtool_draw.pl /home/pi /home/pi 1 > Zum einen bekomme ich keinerlei Daten zur Solarthermie. Ich habe eine > einfache ZSB 14-4 mit einem Heizkreis und integriertem Mischer, dazu den > MS100 für einen einfachen Solarkreis und den CW400 als Regler. Ja, Junkers war fleissig und hat Dir und anderen neue Regler mit neuen Telegrammen gegönnt. Aber ich war auch nicht faul und habe die Software für die neuen C-Regler und den Basisfunktionen angepasst. Allerdings ist diese Anpassung noch nicht auf github.com vorhanden und ich arbeite noch am nächsten Release. Sende mir eine PM und ich kann Dir im Voraus diese Software als Testversion zusenden. Und ja, logfiles kann ich immer gebrauchen zumal Du den HT4i-Heizungsbus eingebaut hast. Gruß Norbert
> Für das Timing der Grafen ist der cron-job zuständig, dort kannst Du die > Zeit reduzieren auf z.B. 2 Minuten. Das habe ich auch schon probiert, aber ohne Erfolg. Zumal die Daten in der rrd-Datenbank ja unabhängig vom cron sein müssten, d.h. wenn ich das Script manuell aufrufe, sollten die Schritte im Minutentakt auftreten? > Hinweis: Es werden alle 60 Sekunden neue Daten in die rrd-db > geschrieben, schneller macht keinen Sinn, da einige Telegramme nur 1mal > pro Minute kommen und der Raspberry (je nach Version) dann gut zu tun > hat. Minutentakt gefällt mir besser, aber das muss doch auch gehen wenn ich nicht jede Minute das Script per cron starte... > Und ja, logfiles kann ich immer gebrauchen zumal Du den HT4i-Heizungsbus > eingebaut hast. Okay, dann werde ich demnächst mal welche aufzeichnen wenn die Sonne scheint und der Solarregler was zu tun hat. Heute morgen wollte das nicht so ganz klappen; hab' den ht3_logger gestoppt und "cat /dev/ttyAMA0" ausprobiert, ist aber nix passiert. Auch mit einem ">> /tmp/log.hex" dahinter entstand nur eine 0kB-Datei... Lasse
Hallo Lasse, > Zumal die Daten in der rrd-Datenbank ja unabhängig vom cron sein müssten, > d.h. wenn ich das Script manuell aufrufe, sollten die Schritte im > Minutentakt auftreten? Das script holt sich die Daten aus der rrdtool-db. Wenn also keine Daten innerhalb eines Intervalls vorhanden sind (warum auch immer) wirst Du dort auch nur den Default-Wert (meistens 0) aus der rrdtool-db erhalten. Da hilft auch der X-malige script-Aufruf nichts. Das Script ist auch manuell ausführbar und Du kannst es ausprobieren. Logfiles aufzeichnen ist recht einfach wenn der ht_proxy.server läuft: ~/HT3/sw/ht_binlogclient.py <meinlogfilename.log> Das Logfile ist dann im Verzeichnis: ~/HT3/sw/var/log zu finden. Dieser Logclient nutzt die IP-Adresse aus dem ht_proxy_cfg.xml Konfigurationsfile 'localhost'. Falls der ht_proxy.server auf einer anderen Hardware läuft ist dies entsprechend anzupassen. Gruß Norbert
Alles klar, danke. Ich werde dann mal mitloggen wenn ich den proxy am laufen habe :o). Eine Idee ist mir gestern noch durch den Kopf gegangen: Wo müsste ich ansetzen, wenn ich sämtliche Daten in nur einer einzigen rrd-Datenbank haben will? Dann könnte ich die darzustellenden Werte frei kombinieren und mit mehreren draw-Scripts entsprechende PNGs erzeugen... Lasse
Anbei schonmal ein kurzes Logfile aus der Mittagspause. Solarpumpe ist aktiv, Kollektortemperatur ca. 55-60°C, Speicher unten ca. 50°C. Solarregler MS 100, Wahlschalter am Regler auf "1", Pumpe PWM-gesteuert; ansonsten ein Heizkreis am Kessel ohne externen Mischer. Die Testsoftware läuft soweit, auch mit Proxy, zeigt aber leider immer noch keinerlei Solardaten an (im Graph steht 'nan', also keine Werte in der DB). Ich logge heute den Nachmittag mit; in 2 Stunden sollte die Solarpumpe ausgehen, dann hast du nochmal einen Wert mehr :).
Hallo Lasse, habe Dein logfile mal durch den Analyser gejagt. Resultat siehe Bild. Es werden u.A. Solarwerte im Analyser angezeigt. Was mir nicht gefällt ist der angezeigte CauseCode:203. Kontrolliere mal am Regler CW400 ob dort Fehler angezeigt werden oder in der Historie vorhanden sind. Das Handbuch sollte Details dazu hergeben. Denke bitte daran das Deine Testsoftware ein erweitertes Konfigurationsfile hat und Du die Datenbank damit NEU anlegen musst. Auch muss der cronjob jetzt die rrdtool-db Daten aus dem Test-Verzeichnis nehmen und daraus die Grafen erzeugen! > Wo müsste ich ansetzen, wenn ich sämtliche Daten in nur einer einzigen > rrd-Datenbank haben will? Das wäre eine grundlegende Anpassung der Software, da die interne Struktur darauf ausgelegt ist mehrere rrdtool-dbs zu nutzen(jeder Systempart eine). Grund ist hauptsächlich die Grösse der rrdtool-db. Die habe ich für eine Datenhaltung von 10 Jahren ausgelegt bevor alte Daten überschrieben werden. Wenn alles in einer Datenbank ist wird die einfach zu riesig und nicht mehr effektiv für den Raspberry. Gruß Norbert
:
Bearbeitet durch User
Moin auch, das sieht ja schonmal gut aus. Den Analyser hab ich gar nicht ausprobiert, weil der mit der aktuellen Software auch keinerlei Solardaten angezeigt hat. Ich habe die alten Datenbanken komplett eingestampft und deine Testversion als einzige Software komplett neu nach Anleitung installiert. Beim durchgehen der Logfiles ist mir allerdings aufgefallen, dass da teilweise einzelne Bytes zu fehlen scheinen... Wenn dein Analyser aber gute Werte anzeigen kann, muss der Fehler ja in meiner Softwarekonfiguration liegen? Welche Telegramme hat die Solargeschichte vom MS100? Irgendwas in dieser Richtung?
1 | B0 00 FF 00 02 62 |
2 | 02 63 |
3 | 09 64 |
4 | 18 66 |
5 | 68 |
6 | |
7 | B0 00 00 |
8 | B0 00 09 |
Wobei B0 00 FF 02 02 64, B0 00 FF 09 02 64 und B0 00 FF 00 02 62 am ehesten nach was interessantem aussehen, bei mir allerdings ab und an mal etwas in der Länge variieren. Ja, in der Historie sind noch die ersten Fehler von der Installation vorhanden. Die wollte ich noch drin lassen bis der Junkers Service da war, weil der Heizungsbauer die nur mit einem Achselzucken quittiert hat. Das mit der Datenbankgröße klingt einleuchtend. Alternativ könnte man ja 'die eine' Datenbank auf 1 Jahr begrenzen und für jedes Jahr ein Backup anlegen? Egal, erstmal muss die Software bei mir überhaupt richtig laufen :). Lasse
So, hab' noch mal eben schnell den Analyser ausprobiert. Der zeigt tatsächlich die Solarwerte an, wobei mir der Ertrag der letzten Stunde mit über 11kW etwas zu viel erscheint ;). Jedenfalls sind die Grafiken für den Solarbereich immer noch leer und alle anderen Werte sind immer noch nur im 5-Minuten-Raster. Wie kann ich am einfachsten überprüfen ob die SQL-Daten regelmäßig und korrekt in der RRD-Datenbank ankommen?
Okay, jetzt bin ich verwirrt. Habe mit ls -l die Datenbanken beobachtet: Die für Heizung und Warmwasser werden jede Minute aktualisiert, sysdate-irgendwas ist seit der Installation gestern unberührt und die Solar-DB wird nur jede Stunde aktualisiert, immer um 2 Minuten nach Voll. Und dann der Knaller: Um nochmal nach dem 5er-Intervall zu gucken habe ich das Script unter /usr/local/bin auf 60 Minuten (statt 2 Stunden) eingestellt. Jetzt war es so, dass beim Aufruf vom cron die Auflösung tatsächlich bei einer Minute lag, aber wenn ich das Script manuell starte (im Ordner /usr/local/bin mit ./rrdtool_draw.pl [...]), sind wieder nur 5m-Schritte zu sehen! Wie kann das denn angehen?
Hallo Lasse,
kontrolliere noch einmal den cronjob, da ist sicher der Fehler zu
suchen.
Hier noch einmal ein Beispiel mit einem absoluten Pfad auf das Script
(Achtung: Anzahl der '*' wichtig, siehe Beispiele im cronjob und doku !)
*/2 **** pi /usr/bin/perl /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi/
/home/pi/ 1
Die drei script-Parameter geben an:
1. Pfad aus dem die Daten kommen (rrdtool-datenbank).
2. Pfad wohin die PNG-Files geschrieben werden.
3. Anzahl der Heizkreise
Bei der Pfad-Angabe (2.) ist zu beachten das diese PNG-Files vom
'httpd'-daemon auch in seinem Verzeichnis gefunden werden.
In dem Beispiel wird die Pfadangabe im Script ergänzt zu:
/home/pi/ + ./HT3/sw/etc/html
Der 'httpd'-daemon läuft im Verzeichnis: /home/pi/HT3/sw/etc/html und
dort müssen auch die PNG-Files stehen und aktualisiert werden.
Dies wird durch die Default-Configuration in den Scripten erreicht.
Bei Änderungen in den Pfaden müssen die Scripte angepasst werden.
Offensichtlich siehst Du Dir mit dem Browser immer alte, nicht
aktualisierte PNG-Files an.
> sysdate-irgendwas ist seit der Installation gestern unberührt
Richtig, die System-Zeitinformation wird nicht in die DB geschrieben,
alle Einträge erhalten ja ohnehin Timestamps.
Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, vielen Dank für deine Geduld :). Ich habe den cron-Eintrag jetzt auch nochmal mit absoluten Pfadangaben gemacht, die Anzahl der Sterne stimmte auch vorher schon. Habe auch mithilfe von find sichergestellt dass ich nur ein draw-Script habe und auch nur im richtigen Verzeichnis die PNGs geschrieben werden. Das stimmt alles soweit, da läuft nix doppelt oder im falschen Ordner. Habe dann das draw-Script testweise so angepasst, dass nur die erste Grafik für 60 Minuten erstellt wird und alle anderen normal für 2 Tage. Dann noch den cron-Eintrag auf 1 Minute geändert und mir die Grafiken auf einem anderen Rechner per httpd im Firefox angesehen. Da habe ich dann für eine halbe Stunde jede Minute die erste Grafik per Speichern unter... gesichert. Dabei sind 9 Grafiken mit 1min Auflösung, allerdings in recht unregelmäßigen Abständen. 5 Grafiken zeigen stattdessen sogar nur eine gerade Linie - entweder werden die Daten da anders gerundet (?) oder tatsächlich 30 Werte zu einem zusammengequetscht. Die übrigen Grafiken liegen bei 5min, allerdings sehen auch diese nicht so aus wie ich erwartet hätte. Die Solargrafik war bis auf wenige Ausnahmen immer leer. Vier mal waren jedoch zwei kleine Spikes zu sehen, die möglicherweise zu dem geringen aktualisierungsintervall der entsprechenden rrd-Datenbank passen. Den Test habe ich ab 19:33 gemacht, letzter Zugriff auf die Solardatenbank war 19:01, bis ca. halb 9 kam auch kein Weiterer dazu. Irgendwas ist da doch faul... Ich habe mit einem brandneuen Jessie-Image auf einer neuen SD-Karte angefangen, der Raspi wird ansonsten für nix anderes gebraucht. Vielleicht versuche ich es nochmal mit einem Wheezy-Image. Problem ist nur dass ich zuhause noch auf meinen Internetanschluss warte :(.
Habe jetzt nochmal mit einem Wheezy-Image von vorne angefangen. Die Grafiken bisher zeigten alle eine einminütige Auflösung, was schonmal besser aussieht als vorher. Allerdings werden immer noch keine Solardaten aufgezeichnet und die Solar-Datenbank wird höchstens 1x pro Stunde aktualisiert. Beim Durchstöbern des Quellcodes ist mir aufgefallen, dass in der Datei 'ht3_decode.py' gar kein Abschnitt á là "if buffer[4] == 2 and buffer[5] == 0x62:" vorkommt, was die fehlenden Grafiken begründen könnte. Die im Analyser angezeigten Telegramme fangen nämlich mit B0 00 FF 00 02 62 an. Dort werden sie ja auch mit den korrekten Temperaturen angezeigt. In der Datei 'ht_discode.py' kommt dieser Abschnitt vor und bedient scheinbar den Analyser, nicht jedoch den Logger...
Hallo Lasse, die Module HT3_decoder.py und HT3_dispatcher.py sind in Deiner Testsoftware zwar noch enthalten, werden aber komplett ersetzt durch das Modul: ht_discoder.py Hinweis: Beim nächsten Release werden diese alten Module auch entfallen. > Allerdings werden immer noch keine Solardaten aufgezeichnet und die > Solar-Datenbank wird höchstens 1x pro Stunde aktualisiert. Habe die Testsoftware angepasst und Dir per E-Mail zugesendet. Mit Deinem Logfile als binärer Input wird jetzt auch der Solaranteil in der Grafik angezeigt. > Welche Telegramme hat die Solargeschichte vom MS100? Irgendwas in dieser > Richtung? > B0 00 FF 00 02 62 > 02 63 > 09 64 > 18 66 > 68 Ja korrekt, ist aber noch nicht alles dekodiert. Wie war das noch mit dem Eichhörnchen? (mühsam!) Gruß Norbert
> die Module HT3_decoder.py und HT3_dispatcher.py sind in Deiner > Testsoftware zwar noch enthalten, werden aber komplett ersetzt durch das > Modul: ht_discoder.py Das habe ich gestern abend rausgefunden ;). Bin letztlich mit dem Logger angefangen und habe den Weg zurückverfolgt, soweit dass die Kollektortemperatur jetzt korrekt ins Logfile geschrieben wird. Wenn man am Tag nur ca. eine Stunde Zeit dafür hat ist es in der Tat mühsam... > Habe die Testsoftware angepasst und Dir per E-Mail zugesendet. Vielen Dank! Werde ich nachher mal testen. > Ja korrekt, ist aber noch nicht alles dekodiert. > Wie war das noch mit dem Eichhörnchen? (mühsam!) Spätestens im Herbst, wenn ich nicht mehr so viel im Garten machen muss, helfe ich dir gerne dabei. Wenn ich am Wochenende mal ein paar Stunden habe natürlich auch, aber der WAF ist beim Reverse Engineering nicht besonders groß... Ich habe ansonsten auch ein Gästezimmer, falls du selber mal ein paar Daten loggen möchtest ;D! Gruß, Lasse
Die Solarerfassung funktioniert jetzt weitestgehend, vielen Dank nochmal! Bei den Ertragsdaten musste ich ein bisschen nachhelfen, weil die Werte um eine Zehnerpotenz zu hoch waren. Ein Problem habe ich allerdings weiterhin. Das Telegramm für die Solarpumpenlaufzeit fängt an mit B0 10 FF 00 02 91. Das Problem ist die 10. Die wird nämlich vom discoder nicht erkannt. Der Proxy kann alles problemlos vom UART lesen, sonst hätte ich das Telegramm ja nicht vollständig im Logfile. Im discoder jedoch taucht die 10 nicht auf. Ich habe direkt nach der firstbyte-Erkennung "buffer[0]==0xb0" den buffer[1] ins logfile schreiben lassen (mit der Bedingung :=0) und dort überwiegend die 8 wiedergefunden, aber keine einzige 16 alias 0x10. Das Telegramm mit B0 08 35 kommt regelmäßig alle 2 Minuten und alle 14-16 Minuten (also immer nach 7 bzw. 8 Telegrammen) kommen dann drei B0 10 FF Telegramme. Im Logfile ist das sehr gut zu sehen, aber nicht im discoder. Als letzten Versuch habe ich bei __read() die Ausgabe von self.port.read() in eine Variable gepackt und zusätzlich mit ord() ins Logfile schreiben lassen. Dabei sind definitiv mehrere 16er pro Sekunde zu Stande gekommen. Allerdings habe ich das nicht über einen Zeitraum von 16 Minuten gemacht um zu sehen ob auch ein vollständiges Telegramm dabei rauskommt. Ideen? :) Gruss, Lasse
Hallo Lasse, > Bei den Ertragsdaten musste ich ein bisschen nachhelfen, weil die Werte > um eine Zehnerpotenz zu hoch waren. Ok, bring ich mit in das nächste Release ein. Danke für die Info! > Das Telegramm für die Solarpumpenlaufzeit fängt an mit B0 10 FF 00 02 91. > Das Problem ist die 10. Die wird nämlich vom discoder nicht erkannt. Das stimmt, es werden in der Software z.Zeit nur Telegramme: <An Alle>:=0 ausgewertet. Das Byte1 (von Null an gezählt) ist dabei dann 00. z.B.: B0 00 FF 00 02 91 würde erkannt werden können wenn es denn im Dispatcher/Dedocder enthalten wäre. Da Dispatcher und Dekoder nicht mehr zu den neuen Telegrammen passen und eine Erweiterung in der alten Form grottig wird habe ich mich entschlossen den kompletten Dispatcher und Dekoder (discoder) neu zu schreiben. Dies ist jedoch noch gar nicht in Deiner Testsoftware enthalten. Hinweis: Junkers behandelt die Telegramme anders. Jedes Telegramm hat eine eindeutige Kennung die im neuen 'discoder.py' ausgewertet werden wird. Dazu ist es allerdings nötig die ersten 6 bis 7 Byte eines Telegramms auszuwerten. Dein Beispiel liest sich also so: B0 10 FF 00 02 91 B0 -> Source:(30 + 80)hex Solar 10 -> Target:(10)hex Hier Dein Regler angesprochen FF -> EMS - typed Message (MSG-Erweiterung) 00 -> Message-Offset 02 91 -> MessageID := (2+1)*256 + 145d := 913 dezimal Mit diesem Telegramm sendet das Solarmodul ein Telegramm 913 an den Regler des Heizungssystems. In Zukunft wird der Dispatcher die MessageID verwenden und ist dann unabhängig von Target- und Source-Bytes. Allerdings ist dies noch in Arbeit und sobald eine brauchbare Version vorhanden ist bist Du der Erste der diese zum Testen erhält! Schau auch mal auf die EMS-Infos der Buderus-Liga (auch hier im Forum). URL: http://emswiki.thefischer.net/doku.php Viele Details sind ähnlich oder auch gleich. Klar beides Bosch. Trotz allem gibt es Unterschiede die eben die Dekodierung anders machen. Gruß Norbert
:
Bearbeitet durch User
Höchst interessant! Dann warte ich mal dein nächstes Release ab und schaue mir gelegentlich das Wiki an :). Hier nochmal ein paar Solartelegramme die ich ausfindig machen konnte. B0 00 FF 00 02 8E *20: [6]-[9] Ertrag letzte Stunde *10 (also durch 10 teilen für Wattstunden), [10]-[13] Ertrag Tag in Wattstunden, [14]-[17] Ertrag gesamt *10 (/10 = kWh, *100 = Wh) B0 00 FF 02 02 64 *19: [13] Solarpumpenleistung in %, [14]*255 entspricht grob dem Ertrag der letzten Stunde ([15] variiert, ist auch schon >0 wenn noch kein Ertrag vorhanden ist), [7] Nachts 0, Tagsüber 4 => Kollektortemperatur OK? B0 00 FF 02 02 6A *17: [14] 03=Solarpumpe aus, 04=Solarpumpe an B0 00 FF 03 02 64 *9: [6] Nachts 0, Tagsüber 4 => Kollektortemperatur OK? B0 00 FF 09 02 64 *9: [6] Solarpumpenleistung in % B0 00 FF 0A 02 6A *9: [6] 03=Solarpumpe aus, 04=Solarpumpe an B0 10 FF 00 02 8A *32: Ertrag der aktuellen Woche. [6]-[9] Gestern oder Samstag, [10]-[13] Vorgestern oder Freitag, usw. Hab die Daten an einem Sonntag gesammelt... B0 10 FF 18 02 8A *32: Ertrag der letzten Woche. [6]-[9] Sonntag, [10]-[13] Samstag, usw. B0 10 FF 00 02 91 *32: [6]-[9] Solarpumpenlaufzeit in Minuten Gruß, Lasse
Hallo, @Alle die Software zum Projekt ist auf github.com aktualisiert zu Rev.: 0.2.1 Da die Decodierung sich mit diesem Release grundlegend geändert hat kann ich nur empfehlen das ganze Projekt zu aktualisieren. Komplett wie gehabt mit: git clone https://github.com/norberts1/hometop_HT3.git Auf der Web-Seite wird im README.md im Detail angegeben was sich geändert hat, deshalb will ich dies hier nicht wiederholen. Grundlegend ist die Dekodierung jetzt umgestellt auf MessageIDs und das Handling der Cxyz - Regler ist hinzugekommen. Danke an alle die in irgend einer Weise dazu beigetragen haben! Noch eine wichtige Bemerkung zu den Datenbanken: 1. Die sqlite-datenbank unbedingt neu anlegen da neue Logitems dazugekommen sind. 2. Falls die Daten der rrdtool-datenbank weiter genutzt werden sollen so ist ein upgrade erforderlich. Dies ist ebenfalls im Release enthalten unter: ~HT3/sw/etc/upgrade_rrdtool_db Dort unbedingt das darin enthaltene 'readme'-file lesen, es sind perl CPAN-Module zu installieren die von Haus aus nicht vorhanden sind. Allerdings muss man sehr viel Speicherplatz frei haben (>1GB in /tmp) damit dieses upgrade der rrdtool-datenbank auch fehlerfrei durchläuft. Auf meiner virtuellen Maschine ist dieses upgrade durchgelaufen, allerdings auf meinem RaspberryPi B aus Platzmangel nicht. Falls ähnliche Probleme auftreten bleibt leider eine Neugenerierung der rrdtool-datenbank nicht erspart (./create_databases.py). Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, vielen Dank für die viele Arbeit!!! Habe es bei mir gleich ausprobiert, da ich ja nur die Dateien austauschen musste (DB war ja schon neu erstellt). Eine kleine Frage: Was für eine Load sollte ein Raspi 1 B haben, wenn nur diese Software läuft? Aktuell habe ich rund 1,5 dauerhaft. Gruß, Stephan
Hallo Stephan, > Was für eine Load sollte ein Raspi 1 B haben, wenn nur diese Software > läuft? Aktuell habe ich rund 1,5 dauerhaft. Der Durchschnitt sollte unter 10% für ht_proxy und HT3_logger sein. Diese Zahlen sind aber stark abhängig von äusseren Faktoren wie: Anzahl der Heizkreise, Art des Adapters, Anzahl der ht_clients am ht_proxy.server und Heizungs-Regler im System. Insbesondere die neuen Regler der Cxyz-Serie machen einen grösseren Traffic auf dem Heizungsbus. Deshalb kann ich Dir da auch nur Hausnummern und keine feste Werte angeben. Siehe Bild, wie es bei mir als Schnappschuss aussieht. Deine 1,5% sind da ja recht wenig und Dein RaspberryPi langweilt sich :-) Gruß Norbert
Norbert S. schrieb: > Deine 1,5% sind da ja recht wenig und Dein RaspberryPi langweilt sich Hallo Norbert, leider reden wir nicht über % CPU sondern über die Linux Load. Und die sollte bei einem Single-Core wie dem Raspi 1 B eigentlich nicht dauerhaft über 1 (=100 % CPU) sein. Bei mir ist es aber im meist zwischen 1,5 und 2. Schau mal auf die Bilder erste Zeile oben. Der Proxy und der Logger selbst sind unauffällig, aber manchmal sehe ich "perl" oder "rrdtool_draw.pl" für bis zu 20s oben in der Top-Liste stehen mit jeweils 60-70% CPU. Von hier kommt meine im Schnitt zu hohe Load, besonders weil diese temporäre Last so lange dauert. Siehe die 3 Bilder. Mal zu den Eckdaten. Ich habe nur 1 Heizkreis, kein Solar. Regler ist der CW400. Aus der rrdtool_draw.pl habe ich Solar und HK2-4 gelöscht. Auf dem Raspi 1 B läuft nur HT3 mit einem Tiny-Adapter, RPI-Monitor und phpliteAdmin. Die SQlite-DB habe ich aktuell auf 13MB, da ich alle Werte älter als 2 Tage schon immer lösche. Es greift ausser mit http niemand zu, auch kein FHEM oder externer Logger. Danke und Gruß, Stephan
:
Bearbeitet durch User
Hallo Norbert, noch etwas: Das neue Autocreate! Ich habe ja meine rrdtool_draw etwas angepasst, da ich manche Sachen weglasse, die Grafiken etwas breiter mache und auch noch andere Zeiträume sehen will. Und heute such ich mir nen Wolf, warum meine Bilder mal halbe Seitenbreite und mal ganze Seitenbreite haben und warum rrdtool_draw eigentlich so oft ausgeführt wird, obwohl laut cron nur alle 5 Minuten. Anscheinend rufst Du das jetzt aus dem Worker auf? Damit müsste dann doch auch der Cron-Eintrag wegfallen, denn der zeigt ja auf eine ganz andere Datei...
Hallo Stephan, > Anscheinend rufst Du das jetzt aus dem Worker auf? Damit müsste dann > doch auch der Cron-Eintrag wegfallen, denn der zeigt ja auf eine ganz > andere Datei... Ja und Ja! Die durchgeführten Änderungen habe ich ja im Readme.md auf github.com beschrieben! Also: Aufruf des scripts: 'rrdtool_draw.pl' im cronjob deaktivieren oder das Autocreate-Draw im Konfigurations-File abschalten mit: ... <autocreate_draw>off</autocreate_draw> Dies würde auch ein wenig die hohe Last bei Deinem RaspberryPi erklären da ja von zwei Stellen das Perl-script aufgerufen wird. Gruß Norbert
Hallo Norbert, in der Readme steht nur was drin mit dem autocreate. Dass man nun allerdings den cronjob löschen muss ist nicht klar ersichtlich, zumal er in der PDF Doku immer noch drin ist. Wie lange dauert bei dir das Ausführen von rrdtool_draw? Bei mir 6-7 Sekunden. Gruß Stephan
Hallo Stephan, >Wie lange dauert bei dir das Ausführen von rrdtool_draw? Ja, auch so 7-8 Sekunden. > ..., zumal er in der PDF Doku immer noch drin ist. Ja ich weiss, ich bin in Lieferverzug :-( Aber es kommt ja ein Wochenende, und da mach ich blau! und vielleicht auch noch die Doku. Gruß Norbert
Moin zusammen, mein ISM1 zeigt mir heute an, dass die Solarpumpe bisher nur 9.5h gelaufen ist. In mehr als 5 Jahren. Nicht schlecht. da hat wohl jemand heimlich eine neue eingebaut :-) Hatte das vielleicht schon mal jemand? BG Mario
Hallo Mario, > mein ISM1 zeigt mir heute an, dass die Solarpumpe bisher nur 9.5h > gelaufen ist. In mehr als 5 Jahren. Dieses Verhalten hatte ich mit meinem Regler FW100/ISM1 ebenfalls beobachten können. Den zu geringen Wert hatte ich am 'HT3_Analyser' abgelesen und im FW100 bestätigt gefunden. Für dieses merkwürdige Verhalten kenne ich zwei Gründe: 1. Die Heizung war mehr als 6 Stunden ausgeschaltet (stromlos). Der Regler FWxyz vergisst die dann bis dato erfassten Daten, da dieser keine Batterie sondern 'nur' einen 'Super-Cap' enthält. Dies gilt dann auch für das Solar-Regelverhalten, Zählerstände usw. 2. Das Telegramm: MsgID-259 enthält zwar 3Byte für die Pumpenlaufzeit (Byte 16,17,18), es werden jedoch offensichtlich nur 2Byte (Byte17,18) im Regler ausgewertet (siehe Bild). Somit kommt es beim Wert 65535 := ca. 1093 Stunden zu einem Überlauf ohne einen Übertrag in Byte 16 durchzuführen. Der Zähler fängt somit wieder bei 0 an. Bei Dir kommt sicher Fall2 in Frage, da Du die Heizung bzw. Solar sicher nicht abgeschaltet hast. Vergleiche mal das Telegramm:MsgID259 im HT3_Analyser mit dem im Bild dargestellten. Der erneute Zähler-Überlauf wird bei Deiner Heizung aber sicher erst im nächsten Jahr erfolgen. Hinweis: Diesen Überlauf habe ich schon mindestens zweimal beobachten können. Gruß Norbert
Hallo Norbert, sorry für die späte Antwort aber ich habe jetzt bei mir doch nochmal geschaut und augenscheinlich werden bei mir alle 3 Bytes ausgewertet. Der Wert ist bei mir momentan 02 09 7c, was umgerechnet 2.225h entspricht. Dieser Wert steht auch in meinem FW200 aber eben nicht in den vom rrdtool erzeugten Bildchen oder im Rest der SW (Analyser, Systemstatus). Also doch ein Bug in der SW? duckundwech Danke + Gruß, Mario
Hallo Mario,
> Also doch ein Bug in der SW?
Ja, es werden z.Z. nur 2Byte ausgewertet.
Die Anpassung ist jedoch einfach und die kannst Du auch selber
durchführen.
Modul: ht_discode.py (aktuelles Release 0.2.1)
Funktion: msgID_259_Solar()
Zeilen: 2047 ff
Änderungen:
if raw_index == 16 and msg_bytecount >= 3:
i_laufzeit_minuten = int(buffer[buffer_index] * 65536 +
buffer[buffer_index + 1] * 256 + buffer[buffer_index + 2])
(Auf korrektes Einrücken achten)
Wenn dies bei Dir funkt kommt es in das nächste Release.
Gruß Norbert
Hi Norbert, erstmal danke für die Rückmeldung und den Code, ich habe die Änderung eingebracht (Zeilennummer in meinem vi war allerdings anders). Also jetzt werden 3 Bytes ausgewertet aber es wird merkwürdig, der Hex-Wert ist momentan 020940, also umgerechnet 2224 Stunden. Das zeigt auch der/die FW200 an: 1h weniger als gestern um die Uhrzeit? Aber auf jeden Fall realistischer als als vorher und zumindest mit der Anzeige an der Heizung konsistent :) Danke!
Irgendwas passt im rrdtool noch nicht, also der Analyser hat 2224h angezeigt. Die Angabe der Laufzeit im Bild "Solar Ertrag" schwankt, momentan zeigt er 731.2 Stunden an.
Hallo Mario, bitte erzeuge ein binäres Logfile Deiner Anlage. Laufzeit ca. 1 bis 2 Stunden. Wird wohl nicht mehr so viel Sonne dabeisein aber ein paar Daten werden schon kommen. Mit dem Logfile kann ich nachvollziehen was dort passiert. Gruß Norbert
Moin Norbert, ich will Dir ja nun nicht mehr Arbeit machen als unbedingt notwendig ;-) Um sicher zu gehen, dass sich jetzt nichts verbogen hat, habe ich gestern vor dem Schlafengehen mal alle DBs neu angelegt und heute morgen sieht's gut aus: 2224h auch per rrdtool. Ich lasse es jetzt erstmal s und beobachte weiter. Danke für Deinen Support!
Hi Norbert, kannst Du mir mal bitte verraten, wie ich am besten HEX bzw binär mitloggen kann? Meine rrdtool-Grafiken haben Spikes bei der WW-Soll-Temperatur, jetzt habe ich mal in die DB geschaut und ja, da tauchen so alle 2 Minuten komische Werte auf, mal 56, mal 60 Grad o.ä. Soll ist momentan auf 50 Grad eingestellt. Im Analyser sehe ich rechts auch immer mal eine andere Soll-Temperatur, nur werde ich aus den Telegrammen nicht so schlau. In 88 00 34 00 steht in Byte 4 eine 32h, das passt. Der Temperatur-Wert scheint sich immer dann zu ändern, wenn im Anschluss an das obige Telegramm noch das Telegramm 90 08 35 01 kommt, das im Analyser auch mit WW gekennzeichnet ist. Aber darüber kann ich in der Info nichts finden. Aber ich kann mich auch täuschen. Danke und sorry für die ganzen Nachfragen.
Hallo Mario, > kannst Du mir mal bitte verraten, wie ich am besten HEX bzw binär > mitloggen kann? Wenn Du den ht_proxy.server im/am Rennen hast ist dies ganz einfach: ht_binlogclient.py <logfilename deiner wahl.log> Dies zeichnet die ht_busdaten in ein Binär-File auf (unter: ~/sw/var/log) und nutzt die URL: 'localhost'. Falls Dein ht_proxy.server auf einem anderen Rechner läuft ist die 'serveraddress' des 'proxy_client' im Konfigurationsfile: ht_proxy_cfg.xml entsprechend anzupassen. > Der Temperatur-Wert scheint sich immer dann zu ändern, wenn im Anschluss > an das obige Telegramm noch das Telegramm 90 08 35 01 kommt Im aktuellen Release wird Byte7 als 'Sollwert für Warmwassertemperatur' genommen. Dies ist aber auch schon im Telegramm: 88 00 34 00 enthalten. Warum diese Werte sich unterscheiden obwohl diese zumindest namentlich gleich sind weiss ich nicht. Deshalb die Dekodierung für Telegramm: 90 08 35 01 deaktivieren wie folgt: Modul: ~/sw/lib/ht_discode.py Fkt: msgID_53_DomesticHotWater() Zeile 1547 deaktivieren: # self.__gdata.update(nickname, "Tsoll", self.__Check..... > Aber darüber kann ich in der Info nichts finden. Aber ich kann mich > auch täuschen. Nein, Du täuscht Dich nicht. Die Doku hinkt der SW weit hinterher und ist immer noch eine offene Baustelle. > Danke und sorry für die ganzen Nachfragen. Ist genau richtig, nur so kommt man weiter. Gut für alle. Gruß Norbert
Danke, ich habe das jetzt auskommentiert und schaue mal. Schönes Rest-WoE!
Hallo Norbert, da in Kürze die Heizungssaison wieder beginnen wird: Hast Du schon geplant, die aktuellen Möglichkeiten zur Steuerung der CW-Reihe auch in das FHEM-Modul zu integrieren? Ich habe bereits eine recht brauchbare Anwesenheitssimulation (WLAN-MAC's der Handy's von der Fritzbox abfragen) am Laufen und würde somit gern die Temp runterfahren, wenn keiner mehr da ist. Und bislang ist die Temp ja das einzigste, was man bei den CW wirklich steuern kann. Danke und Gruß, Stephan
Hallo Stephan, > Hast Du schon geplant, die aktuellen Möglichkeiten zur Steuerung der > CW-Reihe auch in das FHEM-Modul zu integrieren? Ja geplant schon, jedoch bin ich noch dabei die anderen Baustellen (Doku...) zu bearbeiten. Auch muss das FHEM-Modul insgesamt überarbeitet werden damit die neuen Telegramme (Cxyz - Regler) dekodiert werden. Ebenso werden die Telegramme der Lastschaltmodule (IPM) noch nicht behandelt. Somit kommt auch weiterhin keine Langeweile auf :-) Gruß Norbert
Hallo zusammen, ich möchte Norbert hier mal einen sehr großen Dank aussprechen, der ständige Support und vor allen Dingen das ganze Projekt an sich sind einfach großartig. Um der Community mal etwas zurückzugeben und um mich selbst ein bissel unter Druck zu setzen: Ich habe begonnen, an einer HighCharts-Umsetzung der Visualisierung von HT3 zu arbeiten, eigentlich nur deswegen, weil ich kein Freund der statischen rrdtool-Grafiken bin. Jetzt muss ich allerdings sagen, dass ich weder Javascript noch PHP spreche (ich bin kein Programmierer) und bei mir alles per C&P und Trial&Error funktioniert. Soll heißen, es dauert. Grundlage war ein Projekt aus einem anderen Forum, das ich momentan an meine Bedürfnisse anpasse, u.a. von mySQL auf SQlite3 umstellen etc. Also, falls Interesse besteht, kann ich das Ganze am Ende gern zugänglich machen - aber Achtung: Interessierter Laie am Werk. Und wenn ich im jetzigen Tempo weitermache, gibt es die erste Version vermutlich erst zu Weihnachten ;-) Ein Warmwasser-Diagramm funktioniert aber schon (inkl. Zoom), so dass die Grundlagen eigentlich da sind und ich jetzt ans nächste Diagramm gehe. 2 Screenshots anbei.
Norbert S. schrieb: > Auch muss das FHEM-Modul insgesamt überarbeitet werden damit die neuen > Telegramme (Cxyz - Regler) dekodiert werden. Hallo Norbert, danke, dass Du an dem Thema weiter dran bist und uns teilhaben lässt. Ich habe mittlerweile herausgefunden, dass man am CW400 mit TC2 die Voreinstellung für "Heizen" setzen kann und mit TECO die für "Sparen". Wenn man einfach die Temperatur setzt, dann bleibt diese bis zum nächsten Programmwechsel. Insofern wäre eine Angabe der "Netcom-Bytes" nur zum Setzen der Temperatur erstmal hilfreich, damit wenigstens die Heizung beim Verlassen herunterfährt. Wenn es noch länger dauern würde, dann würd ich mir behelfen, indem mit PHP die ht_netclient-Befehle aufgerufen werden, denn FHEM und HT3 laufen nicht auf denselben Raspis. Gesucht wird allerdings weiterhin auch noch eine Möglichkeit zur direkten Umschaltung zwischen "Heizen" und "Sparen" ohne mit der Temperatur jonglieren zu müssen. Denn dann hätte ich Hoffnung, damit auch Zirkulation und WW beeinflussen zu können Danke und Gruß, Stephan
Hallo, @Stephan > Wenn es noch länger dauern würde, dann würd ich mir behelfen, indem mit > PHP die ht_netclient-Befehle aufgerufen werden... Es wird länger dauern mit einer FHEM-Modulanpassung. Dieses Jahr wird wohl nichts mehr draus. Für die Empfangsrichtung von Cxyz-Reglerdaten hast Du ja eine Testversion im Rennen jedoch für die Senderichtung ist da noch was zu tun. @Mario R. Grosses Lob an Mario, sieht klasse aus und ist auf jeden Fall mehr Wert als die rrdtool Drawanzeige. Bleib dran und gib uns mehr davon. Vielleicht kann jemand Dich bei der Anpassung unterstützen. Gruß Norbert
:
Bearbeitet durch User
Hallo, ich habe nach einigen Tagen immer wieder das Problem, dass die HTML-Seite nicht mehr aufrufbar ist. Der normale Apache läuft noch und nach einem "sudo /etc/init.d/httpd restart" ist auch die HT3-Indexseite wieder lesbar. In /var/log finde ich nirgendwo eine Logdatei, die dazu irgendwas hilfreiches liefert. Wo könnte ich noch gucken? Passiert ungefähr nach 6-7 Tagen und die Seite ist auf meinem Arbeits-PC ständig geöffnet. Danke und Gruß, Stephan
Warum nimmst Du nicht den Apache? Also ich habe zwar keine Probleme mit dem httpd gehabt, aber da ich bei mir für die neuen Grafiken auch einen Web-Server installieren musste (hier nginx und PHP), habe ich auch den Pfad für die rrdtool-Grafiken angepasst. Das geht sicherlich eleganter, aber ich habe einfach den Pfad in der ht3_worker.py hart auf /var/www/html umgesetzt. Müsste so ca, Zeile 285 sein (laut vim).
1 | 285 # Draw-Path hart gesetzt |
2 | 286 # strsystemcmd = AbsPathandFilename + ' ' + Abspath2_db + ' ' + Abspath_2_draw + ' ' + str(hc_count) |
3 | 287 strsystemcmd = AbsPathandFilename + ' ' + Abspath2_db + ' /var/www/html ' + str(hc_count) |
Nicht vergessen, die index.html auch dorthin zu kopieren. httpd habe ich hier komplett gestoppt. Nur als Anregung.
Mal kurz ein Update zu meiner HighCharts-Visualisierung. Das hier ist Stand 1.0. Im Großen und Ganzen bin ich schon zufrieden, gibt aber noch ein paar ToDos. - eindeutschen (muss nicht unbedingt Englisch sein bei mir) - momentan kann man nur x Stunden/Tage von "jetzt" in die Vergangenheit schauen (siehe Menü oben), ich hätte gern einen Zeitraum zum Auswählen Anmerkungen: Ich habe alles umgesetzt, was für mich wichtig ist. Das ist nicht zwangsläufig das gleiche wie in den rrdtool-Grafiken jetzt. Der ein oder andere mag also was vermissen. Es ist zwar dynamisch, aber alles über 24 Stunden kann im Browser schon sehr zäh werden, schließlich sind da Tausende Datenpunkte, die HighCharts darstellen muss und die er sich prinzipbedingt auch wirklich in den Speicher lädt. 7 Tage wie im Menü funktionieren technisch nach dem Hochsetzen von PHP-Speicherlimits und Timeouts, 10 Tage eher nicht mehr. Alles läuft auf einem Pi2 Model B. Getestet nur unter Chrome. Muss mal schauen, wie ich das zum Download bereitstelle, falls Interesse besteht.
Hallo, sei ca. 2 Wochen durch paar Sekunden habe ich falsche Daten bei Heizkreis, durch paar Sekunden richtige Daten. Datenbase habe ich gelöscht und neu angelegt. Warmwasser und HK1 zeigt richtige Werte. Ich habe sogar eine Kopie von Herbst auf die SD-Karte noch mall überspielt. Was kann da sein?
Hallo Adam, was hat sich denn an Deinem Heizungssystem und der Datenerfassung in den letzten 2 Wochen geändert? Welchen Adapter-Typ und welche Software-Version setzt Du ein und wie sieht Dein Heizungssystem (Heizgeräte- und Regler-Typ) aus ? Gruß Norbert
Hallo Norbi, danke für Rückmeldung. In letzter Zeit hat sich bei mir gar nichts geändert. Plötzlich falsche Daten. S. Bilder. Miniadapter für Raspi, SW 0.2.2, Heizgerät ZSB14-3C mit neue variable Pumpe, 1 Heizkreis. Grüße Adam
Hallo Norbi, heute habe ich ganzen System und HT3 neu installiert -> gleiche Probleme :( Muss was in Hardware liegen. Was meinst Du? Was soll ich prüfen? Grüße
Hallo Adam, eine Neuinstallation ist nicht nötig und die Hardware ist auch in Ordnung. Grund ist wohl eine Fehldetektion bei der MessageID 24 und der Geräteadresse (10)hex -->> Regler. Falsch ist die Sequenz: 90 00 18 00 18 ... CRC 00 Richtig ist: 88 00 18 00 27 ... CRC 00 Bei der falschen Sequenz stimmen zufällig die MsgID und die CRC und deshalb wird dieses Telegramm auch dekodiert. Um das zu vermeiden mache bitte folgende Änderung im SW-Modul: ~/HT3/sw/lib/ht_discode.py Zeile: 2580 deviceadr_2msgid_blacklist = { 0x10: [11, 12, 24, 46, 47, 64, 100, 106], Es wird damit die MessageID 24 (18)hex für Gereäteadresse:(10)hex in die Blacklist übernommen und dieses falsche Telegramm unterdrückt. Probiere es aus und gib Bescheid ob es funktioniert. Wenn Du Zeit hast kannst Du auch noch ein binäres Logfile (<1Std.) erzeugen und hier im Forum reinstellen oder mir an meine PM senden. Dann kann ich dieses Fehlverhalten bei mir analysieren. Hinweis: Diese SW-Anpassung ist 'nur' für passive HT-Adapter nötig (Mini-/ Micro-Adapter) Für die ht_pitiny und ht_piduino-Adapter ist dies nicht erforderlich da diese das Telegramm-Ende korrekt erkennen können. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbi, in Verzweiflung habe ich Heizkessel ausgeschaltet (vom Netz getrennt) und wieder eingeschaltet und ... HT3 wieder funktioniert richtig !! Geht mein Regler langsam kaputt ? Wenn das wieder passiert, probiere Dein Vorschlag. Seit gestern klappt alles. Danke für Deine Hilfe und grüße Adam
Hallo zusammen, danke an alle für ihren Einsatz die Heatronic-Schnittstelle zu analysieren! Mit den zusammengetragenen Informationen habe ich mir einen HT3-USB Adapter auf Basis eines Arduino M0 Pro gebaut und verarbeite die Empfangsdaten mit einem Python-Skript. Gespeichert werden die Messwerte in einer InfluxDB-Instanz. System: Junkers CerapurACU ZWSB 22/28-3 mit CW400-Regler Ich habe jetzt noch ein paar HT3-Telegramme, die unbekannt sind (die mit *):
1 | 90 00 06 00 11 01 11 05 2D 31 03 00 10 FF 00 A7 00 |
2 | ** 90 08 23 00 41 64 64 C5 00 |
3 | 88 00 18 00 41 02 2A 32 00 01 23 20 C0 80 00 80 00 80 00 FF FF FF 00 00 00 00 00 00 00 E3 00 |
4 | 88 00 34 00 28 00 75 01 BD 81 00 00 03 00 00 07 3D 00 03 EA 00 63 00 |
5 | ** 90 08 1A 00 41 64 64 7E 00 |
6 | ** 90 00 FF 00 01 67 00 00 BD 00 |
7 | ** 90 00 FF 00 02 1D 00 00 09 07 5C 00 |
8 | ** 90 08 35 00 11 01 A9 00 |
9 | ** 90 08 35 03 28 6B 00 |
Vorab, so nenne ich die Bestandteile eines Telegramms:
1 | HT3 Message-Frame |
2 | ----------------- |
3 | |
4 | Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 |
5 | +--------+--------+--------+--------+------------+-------+-------+ |
6 | ! Source ! Target ! MsgID ! SubID ! (Data ...) ! CRC ! Break ! |
7 | +--------+--------+--------+--------+------------+-------+-------+ |
Byte 0 bis 3 bilden den Header. Und ein Telegramm hab ich "entschlüsselt", mit dem Header 90 00 FF 08. Die 2 Bytes an Position 6 und 7 bilden einen 24h-Zähler (Rückwärts)
1 | [Fri Jan 13 21:29:29.460 2017] 90 00 FF 08 01 A5 00 5B 45 00 |
2 | [Fri Jan 13 21:29:51.487 2017] 90 00 FF 08 01 A5 05 A0 B4 00 |
3 | [Fri Jan 13 21:30:06.603 2017] 90 00 FF 08 01 A5 00 5B 45 00 |
4 | [Fri Jan 13 21:30:21.548 2017] 90 00 FF 08 01 A5 05 A0 B4 00 |
5 | ** [Fri Jan 13 23:05:29.130 2017] 90 00 FF 08 01 A5 05 9B 8F 00 |
6 | [Fri Jan 13 23:10:27.200 2017] 90 00 FF 08 01 A5 05 96 82 00 |
7 | [Fri Jan 13 23:15:28.608 2017] 90 00 FF 08 01 A5 05 91 85 00 |
8 | [Fri Jan 13 23:20:26.584 2017] 90 00 FF 08 01 A5 05 8C 98 00 |
9 | [Fri Jan 13 23:25:28.024 2017] 90 00 FF 08 01 A5 05 87 93 00 |
10 | [Fri Jan 13 23:30:29.494 2017] 90 00 FF 08 01 A5 05 82 96 00 |
11 | [Fri Jan 13 23:35:27.704 2017] 90 00 FF 08 01 A5 05 7D 69 00 |
12 | [Fri Jan 13 23:40:28.925 2017] 90 00 FF 08 01 A5 05 78 6C 00 |
13 | [Fri Jan 13 23:45:26.917 2017] 90 00 FF 08 01 A5 05 73 67 00 |
14 | [Fri Jan 13 23:50:28.387 2017] 90 00 FF 08 01 A5 05 6E 7A 00 |
15 | [Fri Jan 13 23:55:29.811 2017] 90 00 FF 08 01 A5 05 69 7D 00 |
16 | [Sat Jan 14 00:00:27.787 2017] 90 00 FF 08 01 A5 05 64 70 00 |
Der Zähler startet bei 05A0 == 1440 Minuten. Bei ** bedeutet 059B == 1435 Minuten ... Die Frage ist nun welchem Zweck dieser Rückwärtszähler dienen könnte?
Hallo Philippe, Deine Entschlüsselung des HT-Messagesframes ist nicht ganz korrekt. Es gibt im Prinzip zwei bzw. drei Messageklassen: 1. Byte2 kleiner als (F0)hex Dann sind die ersten 4 Byte als Telegramm-Header wichtig. 2. Byte2 grösser als (F0)hex Dann sind die ersten 6 Byte als Telegramm-Header wichtig. 3. Request-Telegramme Bei diesen sind die ersten 7 Byte wichtig. Diese werden jedoch nur für Sonderzwecke benötigt. Dann ergibt sich folgendes Bild: Zu1. Byte0 Byte1 Byte2 Byte3 Byte 4 +------+------+-----+------+----------+---+-----+ !Source!Target!MsgID!Offset!(Data ...)!CRC!Break! +------+------+-----+------+----------+---+-----+ Zu2. Byte0 Byte1 Byte2 Byte3 Byte4 Byte5 Byte6 +------+------+------+------+-------+------+----------+---+-----+ !Source!Target!Marker!Offset!ID High!ID Low!(Data ...)!CRC!Break! +------+------+------+------+-------+------+----------+---+-----+ Zu3. Sonderfall, hier nicht gezeigt. Die HTML-Doku habe ich mit beigefügt. Diese ist ja ohnehin Bestandteil des git-Projektes. Deine Telegramme wirst Du damit besser analysieren können. Gruß Norbert
Hallo Norbert, die erweiterten Telegramme mit einer 'MsgID' grösser/gleich 0xF0 sind mir bekannt. Mir geht es darum, dass ich die Bezeichnung 'Offset' im Header nicht mag, weil sie impliziert, dass die Nutzdaten erst weiter hinten im Telegramm zu finden sind. Diese 'Offset' Bezeichnung habe ich in alten Dokumenten von Buderus gefunden (ca. von 2001). Es ging dort aber um die 3964R Prozedur, wo direkt der Speicher beschrieben wurde. Da wurde der Offset benutzt, um anzugeben wo die Daten einzusortieren sind. Bei meiner Heizung gibt es 2 Telegramme mit der 'MsgID' 0x35 aber unterschiedlicher 'SubID':
1 | [Fri Jan 13 21:28:23.674 2017] 90 08 35 00 11 01 A9 00 |
2 | [Fri Jan 13 21:28:23.690 2017] 90 08 35 03 37 74 00 |
Die erweiterten Telegramme werte ich noch nicht aus, da sie andere Längen haben als in deiner Übersicht. Anbei noch ein Screenshot meiner Lösung mit Influx/Grafana. Gruß Philippe
Hallo Norbert, In deiner Doku hast du ja die Message-IDs 677...684 - Heizkreis: Systemwerte... Da dreht meine Heizung etwas am Rad (oder ist es mein Hamster, der im Schleudergang ist ?!?)
1 | [Fri Jan 13 21:28:29.977 2017] 90 00 FF 0F 01 A5 01 0C 60 00 |
2 | [Fri Jan 13 21:29:29.210 2017] 90 00 FF 0D 01 A5 00 5B 03 A1 F3 00 |
3 | [Fri Jan 13 21:29:29.460 2017] 90 00 FF 08 01 A5 00 5B 45 00 |
4 | [Fri Jan 13 21:29:30.614 2017] 90 00 FF 03 01 A5 2A 7D 00 |
5 | [Fri Jan 13 21:29:30.801 2017] 90 00 FF 06 01 A5 2A 1E B4 00 |
6 | [Fri Jan 13 21:29:40.785 2017] 90 00 FF 00 01 A5 00 D0 23 2A 3F 00 2A 1E 00 5B 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00 |
7 | [Fri Jan 13 21:29:41.066 2017] 90 00 FF 19 01 A5 06 04 00 00 00 00 FF 64 41 00 3C 01 FF 01 02 AB 00 |
Das längste Telegramm 'FF 00 01 A5' ist mit 33 Bytes zu kurz (soll 39 Bytes), aber die CRC stimmt ... Die Raum-Soll- und Ist-Temperatur stimmt schon mal :o) Gruß Philippe
Hallo Philippe, >Mir geht es darum, dass ich die Bezeichnung 'Offset' im Header nicht >mag, weil sie impliziert, dass die Nutzdaten erst weiter hinten im >Telegramm zu finden sind. Genau so ist es aber. Allerdings muss man beachten das dieser Offset vom ersten Datenbyte (:= 0) an gezählt wird und nicht vom Telegramm-Anfang. Und dieser Offset ist bezogen auf das erste Datenbyte im kompletten Telegramm (Offset:=0). Somit kann ein Modul auch Teilmengen an Informationen an die Steuerung senden. Zu sehen ist genau dies auch bei Deinen erfassten Telegrammen: Die Detail-Telegramme mit Offset:=03 und :=08 sind z.B.:
1 | 90 00 FF 03 01 A5 ->2A<- CRC Break |
2 | 90 00 FF 08 01 A5 ->00 5B<- CRC Break |
3 | Das sind die makierten Detail-Werte im kompletten Telegramm: |
4 | 90 00 FF 00 01 A5 00 D0 23 ->2A<- 3F 00 2A 1E ->00 5B<- 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00 |
Ich habe dies hoffentlich ins rechte Licht/Spalte gerückt damit der
Durchblick besser wird :-)
>Die Frage ist nun welchem Zweck dieser Rückwärtszähler dienen könnte?
In der Message '01 A5' bedeuten diese Zähler die Zeit bis zum nächsten
Programmwechsel und es sind noch weitere Programminformationen
enthalten.
Diese Informationen habe ich bisher noch nicht genutzt und die gibt es
auch so nur bei EMS2 bzw. Cxyz-Regler).
Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, Danke, Danke, Danke! Irgendwie hatte ich das im ganzen Thread bisher nicht verstanden (schäm) Mit deiner Erklärung kann ich die Bezeichnung 'Offset' doch noch lieb gewinnen! Witzig wird es aber bei diesen 2 Telegrammen:
1 | [Fri Jan 13 21:29:40.785 2017] 90 00 FF 00 01 A5 00 D0 23 2A 3F 00 2A 1E 00 5B 03 03 01 00 5B 03 A1 00 00 11 01 03 08 22 00 68 00 |
2 | [Fri Jan 13 21:29:41.066 2017] 90 00 FF 19 01 A5 06 04 00 00 00 00 FF 64 41 00 3C 01 FF 01 02 AB 00 |
Offset '0x19' kommt genau auf dem CRC '0x68' zu liegen ... Hmmm, in der alten Doku stand ja, dass der Offset zum einsortieren der Daten diene ... Könnte es sein, dass das 2. Telegramm eine 'Fortsetzung' darstellt? So, frei nach:
1 | 'Offset == 0': Schreibe die Daten an den Anfang des 'Array' |
2 | 'Offset > 0': Füge die Daten ab Index 'Offset' ins 'Array' |
'Array' im Sinne von Pointer (o.ä.) auf reservierten Speicherbereich für bestimmtes Telegramm ... Gruß Philippe
Hallo Philippe,
>Könnte es sein, dass das 2. Telegramm eine 'Fortsetzung' darstellt?
Ja, das sehe ich auch so.
Die maximale von mir bisher gesehene Telegrammlänge bei den Fxyz-Reglern
war 33 Byte (Header,Daten,CRC und Break zusammen).
Diese Längenbegrenzung macht ja auch Sinn, da für die Zeit der
Telegramm-Übertragung keine anderen Telegramme gesendet werden können
und die CRC(8Bit) auch mehrdeutig wird.
Jetzt hat man wohl bei den Cxyz-Reglern mehr Informationen übertragen
müssen/wollen und hat eine Art: 'Fortsetzung folgt sogleich' erzeugt.
Somit ergibt sich bei weiterhin gleicher maximaler Länge von 33 Byte pro
Telegramm ein Offset von 25 := 19(hex) im folgenden Telegramm mit der
gleichen MessageID.
Wenn ich allerdings die Anzahl der Bytes Deiner Telegramme mit meiner
Beschreibung der MsgID:677-684 vergleiche so passt da was noch nicht.
Ich habe mich auch bisher ein wenig gesträubt die restlichen Werte im
Telegramm in der Doku zu beschreiben, da mir der Nähr-/Mehr-Wert noch
ein wenig fehlt zumal ich auch 'nur' einen Fxyz-Regler habe.
Es sind Informationen wie: Zeit bis zum nächsten Temperaturwert; Zeit
seit letztem Temperaturwert f. Eco,Comfort...; Estrichtrocknung ect.
enthalten.
Kein Wunder das so ein Krebsgeschwür von Telegramm da rauskommt.
Kannst Du die erfassten Daten binär in ein File schreiben und mir
zukommen lassen?
Für eine weitere Analyse und Verbesserung der SW wäre dies hilfreich.
Gruß Norbert
Guten Abend miteinander. Nach langer Abstinenz bin ich wieder da. Hier ein kurzer Überblick über meinen momentanen Stand. Der Raspberry hat nun einen Apache2. Die Daten der Sqlite Datenbank werden über PHP aus der Datenbank ausgelesen. --> d.H. Somit immer aktuell. Solarertrag gesamt wird von Openhab errechnet und auch auf der Seite angezeigt. Für den mobilen Zugriff wurde eine jquery gestaltet die aufklappbare Spalten hat und beinhaltet auch die Grafiken. Bei Interesse kann der Code zur Verfügung gestellt werden. Gruß Martin
:
Bearbeitet durch User
Hallo Norbert, anbei ein 24h-Log meiner Heizung im 7Zip-Paket, einmal als Hex-Dump mit 1 Telegramm je Zeile und einmal in Binär. Geht von Mo, 30.01.17 21:10 bis Di, 31.01.17 21:53, also müsste auch eine therm. Desinfektion drinn sein. System: Junkers CerapurACU ZWSB 22/28-3 mit CW400-Regler Daten/Einstellungen: Wärmeerzeuger Typ Steuereinheit: HT3 SW-Vers. Steuereinheit: 20.13 HCM/BCI-Nummer: 1604 Bedieneinheit Typ: CW400 SW-Version: NF33.04 Heizungsprogramm Mo-Fr ab 00:00 Heizen ab 07:30 Absenken ab 17:00 Heizen Temperatureinstellungen Heizen: 23°C Absenken: 19°C Sommer/Winter-Umschalt: Temp. Sommerbetr.ab: 17°C Warmwasser-Temperatureinstellungen Warmwasser: 56°C Warmwasser reduziert: 40°C Warmwasser-Zeitprogramm Mo-Fr ab 00:00 Aus ab 05:30 Warmwasser ab 08:00 Aus ab 15:00 Reduziert ab 18:00 Warmwasser Thermische Desinfektion: Automatisch Am Dienstag 11:45 bei 72°C
Guten Morgen allerseits. Für all jene die ihre Daten gerne über MQTT weitergeben würden hab ich nun gestern am Abend quick and dirty ein paar Bash Scripte geschrieben. Der Raspberry benötigt das Packet mousqitto-clients mit dem er per Kommandozeile mit dem Broker kommunizieren kann. Hier der Inhalt
1 | #!/bin/bash
|
2 | mqttserver="AdressedesServers" |
3 | #Solar
|
4 | S_solar=$(sqlite3 /pfad/zur/Datenbank/HT3/sw/var/databases/HT3_db.sqlite "SELECT T_kollektor, T_speicher_unten, V_ertrag_stunde, C_laufzeit, V_solar_pumpe FROM solar ORDER BY rowid DESC LIMIT 1"); |
5 | IFS="|"; declare -a solar=($S_solar) |
6 | mosquitto_pub -h $mqttserver -t /heizung/solar/T_kollektor -m "${solar[0]}" |
7 | mosquitto_pub -h $mqttserver -t /heizung/solar/T_speicher_unten -m "${solar[1]}" |
8 | mosquitto_pub -h $mqttserver -t /heizung/solar/V_ertrag_stunde -m "${solar[2]}" |
9 | mosquitto_pub -h $mqttserver -t /heizung/solar/C_laufzeit -m "${solar[3]}" |
10 | mosquitto_pub -h $mqttserver -t /heizung/solar/V_solar_pumpe -m "${solar[4]}" |
Das Script dann mit chmod +x lauffähig machen und im Crontab (crontab -e) alle Minuten oder 2 ausführen lassen. Das ganze läuft bei mir mit mehreren Dateien jeweils für HK und Solar und Heizgerät auf einem Raspberry B ohne Probleme. lg Martin
Hallo Norbert, Adam schrieb: > Hallo Norbi, > > in Verzweiflung habe ich Heizkessel ausgeschaltet (vom Netz getrennt) > und wieder eingeschaltet und ... HT3 wieder funktioniert richtig !! > > Geht mein Regler langsam kaputt ? > > Wenn das wieder passiert, probiere Dein Vorschlag. Seit gestern klappt > alles. > > Danke für Deine Hilfe und grüße > Adam Hallo Norbert, ein oder zwei mall täglich durch 1 bis 6 Stunden kriege ich keine Msg 24_0. D.h. ich kriege keine Infos über wichtigste Infos: Tsoll, Tist, Pumpenleistung, VLeistung. Wo kann das liegen? Grüße Adam
Hallo Adam, hattest Du schon die empfohlene SW-Anpassung eingebracht? Falls nicht dann den markierten Wert einbringen. ~/HT3/sw/lib/ht_discode.py Zeile: 2580 deviceadr_2msgid_blacklist = { 0x10: [11, 12, 24, 46, 47, 64, 100, 106], Damit wird dann die Meldung 24 (18)hex vom Regler unterdrückt. Vom Heizgerät (Adr: 08) wird die dann immer noch ausgewertet. Gruß Norbert
Hallo Norbert, bist Du denn schon mit Deinem Projekt weitergekommen, den FWxxx durch einen CWxxx bei Dir auszutauschen? Aktuell kann man bei den CWxxx nämlich nur die Temperatur steuern und sonst nix. Ich würde aber gern die Zirkulation hierüber starten, da der CW ja keine Rücksicht darauf nimmt, ob jemand da ist. Und da wir wechselnde Schichten haben, macht es nicht wirklich Sinn, morgens um 7 die Zirkulation zu starten, wenn keiner mehr da ist. Wenn ich zu den Zeiten, wo aktuell der CW die Zirkulation startet, die Daten in der DB prüfe, sollte ich dann den Befehl sehen können? Danke und Gruß, Stephan
Hallo Stephan, >bist Du denn schon mit Deinem Projekt weitergekommen, den FWxxx durch >einen CWxxx bei Dir auszutauschen? Dies habe ich auf Eis gelegt. Leider reicht es nicht nur den Regler auszutauschen, auch das Solarmodul muss ausgetauscht werden. Und deshalb verzichte ich drauf weil dies keinen Vorteil bringt (nur für Junkers :-) >Ich würde aber gern die Zirkulation hierüber starten, da der >CW ja keine Rücksicht darauf nimmt, ob jemand da ist. Du kannst doch sicherlich die Zirkulationspumpe per Zirkulationsprogramm steuern. Damit ist eine wenn auch kleine Anpassung möglich. >Wenn ich zu den Zeiten, wo aktuell der CW die Zirkulation startet, die >Daten in der DB prüfe, sollte ich dann den Befehl sehen können? Die Daten werden in die sqlite-DB geschrieben wenn sie auftreten. Somit könntest Du diese Telegramme dort auch wiederfinden. Da diese vom Regler kommen werden die Daten in der Heizkreis-Tabelle zu finden sein. Das wird irgendwas mit Source:=(90)hex oder (98)hex und Target:=(08)hex am Telegrammanfang sein, also: 90 08 .. .. oder 98 08 .. .. Gruß Norbert
Norbert S. schrieb: > Hallo Adam, > > hattest Du schon die empfohlene SW-Anpassung eingebracht? > Falls nicht dann den markierten Wert einbringen. > > ~/HT3/sw/lib/ht_discode.py Zeile: 2580 > deviceadr_2msgid_blacklist = { > 0x10: [11, 12, 24, 46, 47, 64, 100, 106], > > Damit wird dann die Meldung 24 (18)hex vom Regler unterdrückt. > Vom Heizgerät (Adr: 08) wird die dann immer noch ausgewertet. > > Gruß Norbert Hallo Norbert, nach die SW-Anpassung läuft wieder alles richtig. Besten Dank und grüße Adam
Martin S. schrieb: > ... > #Solar > S_solar=$(sqlite3 /pfad/zur/Datenbank/HT3/sw/var/databases/HT3_db.sqlite > "SELECT T_kollektor, T_speicher_unten, V_ertrag_stunde, C_laufzeit, > V_solar_pumpe FROM solar ORDER BY rowid DESC LIMIT 1"); > IFS="|"; declare -a solar=($S_solar) > ... > > Das Script dann mit chmod +x lauffähig machen und im Crontab (crontab > -e) alle Minuten oder 2 ausführen lassen. > > Das ganze läuft bei mir mit mehreren Dateien jeweils für HK und Solar > und Heizgerät auf einem Raspberry B ohne Probleme. > > lg > > Martin Hallo Martin, ich habe versucht dein Script zu übernehmen, da ich so die ausgelesenen Daten per REST-API an OpenHAB übergeben kann. Das funktioniert auch soweit, allerdings bekomme ich beim wiederholten Aufruf des Scripts immer die folgende Meldung: Error Code SQLITE_LOCKED (6): Database Is Locked Hattest du das Problem auch schon mal und konntest es irgendwie lösen? Muss man vielleicht die aufgebaute Verbindung irgendwie wieder sauber trennen? Viele Grüße Thomas
Hallo Thomas Tut mir leid, hab erst jetzt gelesen das du Hilfe brauchst. Jahatte das Problem hatte ich auch, hab mir dann einen netclient gebastelt der die daten über das Netzwerk vom Raspberry zieht. Er ist nur für den mqtt export zuständig. Auch hab ich festgestellt das ein großteile der usb sticks zu langsam ist. Ich hab das Script nochmals angepasst um zu Überprüfen ob der Arry leer ist denn das verursacht Fehlermeldungen in Openhab. Also wenn noch Interesse besteht melden.
Hallo, es gibt ein neues Release: 0.3 zum Projekt auf github. Wie gehabt zu erhalten mit : git clone https://github.com/norberts1/hometop_HT3.git oder Download des ZIP-Files. Neu ist der Daemon: ht_collgate der den HT3_Logger komplett ersetzt. Die zusätzliche Schnittstellen: MQTT-Client und SPS-Interface können jetzt durch diesen neuen Daemon gestartet werden. Die vorhandenen Datenbanken können weiter verwendet werden da sich diese Schnittstellen (sqlite und rrdtool) seit der Version: 0.2.2 nicht geändert haben. Allerdings ist jetzt die Datenbank: sqlite per Default ausgeschaltet und nur die rrdtool-Datenbank ist aktiv. Folgende Konfigurations-Werte sind per default gegeben: sqlite-Datenbank : Aus rrdtool-Datenbank: Ein MQTT-Client : Aus SPS-Client : Aus Die Dokumentation gibt u.A. Auskunft über diese Konfiguration, die Installation des MQTT-Broker und pyhton-paho Library sowie über die Eigenschaften der SPS-Schnittstelle. Die Steuerung der Heizung über MQTT-Befehle ist für die Fxyz- und die Cxyz- Regler enthalten und wenn man einen ht_transceiver (ht_piduino oder ht_pitiny) hat auch möglich. Der ht_collgate verbindet sich mit dem ht_proxy.server, holt sich dort die RAW-Daten ab und dekodiert diese. Die dekodierten Daten werden zu den Clients gesendet (MQTT) bzw. sind durch einen SPS-Client abfragbar. Es werden weiterhin alle Adapter-Typen unterstützt. Details gehen aus der Dokumentation hervor. Gruß Norbert
Hallo Norbert. Erst mal herzlichen Dank das du nun auch MQTT Transport integriert hast. Nun zu meiner Frage. Ich habe den Ht-pitiny auf meinem Raspi2 hängen der als Ht-Proxy läuft. Auf meinem Webserver läuft eine Instanz die die Daten aus der Datenbank zieht und für die Webseite aufbereitet. Hier läuft jetzt ein Bash Script das die Daten an den MQTT Broker sendet. Dieser soll nun durch die neue Version 0.3 ersetzt werden. Kann ich auf dem Pi die alte Version belassen oder sollte ich auf dem PI auch auf 0.3 updaten??? Danke Martin
Hallo Martin, der ht_proxy hat sich gegenüber der SW-Vorgängerversion (0.2.x) nicht geändert. Ebenso das ht_proxy_cfg.xml Konfigurationsfile nicht. Somit brauchst Du diesen Anteil auf dem RPI2 nicht zu aktualisieren. Aber alle ht_clients die RAW-Daten vom ht_proxy.server bekommen, müssen die neueste SW-Version 0.3 erhalten. Es ist z.B. der HT3_Logger.py daemon durch den ht_collgate.py daemon ersetzt und im Konfigurationsfile: HT3_db_cfg.xml sind set-Parameter dazugekommen. Daher sind auch viele der lib-Module angepasst und laufen nur noch korrekt in der 0.3 SW-Version. Aber das Beste zum Schluss. Die vorhandenen Datenbanken (aus Versionen 0.2.x) können weiter genutzt werden und werden auch nicht durch die neue SW-Version 0.3 gelöscht. Neue Daten werden an die vorhandenen angehängt. Einzig die sqlite-Datenbank ist jetzt per default deaktiviert. Aber diese brauchst Du ja in Zukunft eh nicht mehr da der ht_collgate.py daemon mit aktiviertem MQTT-Interface die Daten an den MQTT-Broker sendet. Gruß Norbert
:
Bearbeitet durch User
Kurze Info. Da ich nur einige Zeit damit verbracht habe möchte ich den anderen die Suche ersparen. In der aktuellen Version auf Git ist der ht_collgate nichtausführbar. Bitte mit chmod +x ./ht_collgate.py nachholen. @Norbert könntest du das beheben. Danke
Hallo Martin, danke für die Info. Allerdings tritt dieser Fehler bei mir nicht auf. Habe mir mehrmals mit 'git clone' und auch mit dem Download des Zip-Files das ganze Projekt von github geholt und jedesmal sind die nötigen executable-Flags bei den Files gesetzt. Ebenso wird mir im Browser angezeigt das es sich um ein 'Executable File' handelt (siehe Bild). Daher weiss ich jetzt nicht was bei Deiner Installation anders sein soll als bei mir. Du hast Dir sicher auch das ganze Projekt mit git clone .... vom github-server geholt oder? Gruß Norbert
Morgen Norbert. Ich hab das Projekt als ZIP gezogen. Kann es sein das es hier einen Unterschied gibt???
Noch eine Frage. Steig bei den MQTT Befehlen zum steuern nicht ganz durch. Habe topic root namen auf /ht3 geändert. Um bei Heizkreis 1 die Betriebsart zu verstellen schicke ich. Topic: /ht3/hc1_Tniveau Message: Tniveau,2,1,heizen Richtig so???
Hallo Martin, dein Topic-rootname: '/ht3' ist ungünstig bzw. falsch. Das Slash vorne sollte weg, also 'ht3'. Der Topic-rootname bei MQTT hat nichts mit einer root-Pfadangabe zu tun. Es wird in der Regel kein führendes '/' angegeben. Aber dies ist nicht der Fehler, sondern vor dem Kommando kommt noch die 'set'-Angabe. Somit wäre richtig: Topic: set/ht3/hc1_Tdesired Message: 22.5,heizen Funktion: Es wird für den Heizkreis1 das Temperaturniveau:Heizen auf 22.5 Grad eingestellt. Hinweis: Die Topic-Namen für die Kommandos an die Heizung sind die gleichen wie die 'Empfangs-Topic Namen' haben jedoch noch das 'set/' davor. Im Konfigurationsfile: HT3_db_cfg.xml sind die set-Befehle bei den Logitems eingetragen bei denen eine Kommandierung z.Zeit möglich ist. Für hc1_Tdesired steht da z.B.: <set_param>Tdesired,3,1,T,heizen|sparen|frost||..... bedeutet: Tdesired mit drei Parametern. 1. Heizkreisnummer:= hier 1 <<-- Parser intern genutzt 2. T:= gewünschter Temperaturwert <<-- 1. Befehlsparameter 3. ein Wert aus Liste für zugehöriges Temperaturniveau <<--2.Befehlsparameter Achtung: Die Werte für die Temperaturniveaus unterscheiden sich je nach Reglertyp: 1. Fxyz-Regler oder 2. Cxyz-Regler. Diese Angaben sind für den Parser wichtig, für die Befehle eines MQTT-Client ist die Anzahl der Parameter einen Zähler weniger siehe Beispiel oben. Bitte dringend dazu auch die Dokumentation lesen: §2.3.2 MQTT-Client und $2.2 Konfiguration und Tabellen 7 und 8. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert. Leider funktionieren die MQTT Befehle noch immer nicht. Darum meine Frage. Welcher Teil wertet die Befehle aus? Kann es sein das ich auf dem Pi die Version 0.3 aufspielen muss damit es funktioniert.
Hallo Martin, wie weiter oben beschrieben ist eine Aktualisierung des PI nicht zwingend erforderlich wenn da NUR der ht_proxy.server läuft und dort der ht_pitiny-Adapter angeschlossen ist. Dein Web-Sever ist ja wohl mit diesem RPI verbunden und hat die aktuelle Software erhalten, richtig? Aktualisierung auf 0.3 ist allerdings immer die bessere Lösung. Jetzt habe ich aber auch an Dich noch ein paar Fragen: 1. Wie hast Du erkannt das die Befehle keine Wirkung zeigen? (mit HT3_Analyser.py oder mosquitto??) 2. Hast Du jemals Deine Heizung mit dem Tool: ht_netclient.py gesteuert? 3. Welchen Reglertyp hast Du (Fxyz oder Cxyz)? 4. Ist der Empfang von Heizungsdaten mit MQTT-Messages erfolgreich? 5. Läuft der MQTT-Broker? (sonst auch kein Empfang/Senden). 6. Womit sendest Du die MQTT-Befehle? 7. Welche Tests hast Du durchgeführt? Ein paar Tipps dazu: 1. Empfang: mosquitto_sub -d -h <server-IP> -t hometop/ht/# -q 1 oder mosquitto_sub -d -h <server-IP> -t set/hometop/ht/# -q 1 2. Senden mit : mosquitto_pub -d -h <server-IP> -t set/hometop/ht/hc1_Tniveau -m "heizen" oder mosquitto_pub -d -h <server-IP> -t set/hometop/ht/hc1_Tdesired -m "22.0,heizen" Die Dekodierung der MQTT-Befehle macht lib/mqtt_client_if.py welches vom ht_collgate gestartet wird. Gruß Norbert
Martin S. schrieb: > Topic: /ht3/hc1_Tniveau > Message: Tniveau,2,1,heizen hier liegt der Fehler Norbert. hatte in der Message zu viel drinnen. mit "heizen" "sparen" "frost" "auto" ist auf einmal alles ok. Topic: /set/ht3/hc1_Tniveau Message: sparen Danke für deine Geduld und deine schnelle Antwort. lg Martin
Hallo Norbert, Hallo zusammen, ich bin schon seit langer Zeit begeisterter Nutzer Deiner Software und des piTiny Adapters - bisher habe ich die Daten allerdings aus reiner Neugier protokolliert. Aktuell habe ich allerdings ein Problem mit meiner Heizung (bzw. mit dem Warmwasser), welches in den Plots auch wunderbar visualisiert wird (siehe Anhang). Das Problem trat vor einem Jahr schon einmal auf, verschwand aber von selbst nach 2 Tagen. Mein Warmwasser an der Zapfstelle ist derzeit nur noch lauwarm. Konkret kann ich maximal 40° messen. Wenn ich dusche, fällt die Temperatur relativ schnell ab. Wenn ich mir die Plots so anschaue, entspricht das mehr oder weniger der Speichertemperatur, aber nicht der Ist Temperatur. Generell sieht der Plot aus meiner Sicht seltsam aus: T-Ist ist im Plot konstant bei ~70° (!) (das ist nirgends so konfiguriert), T-Soll bei ~52° (so soll es sein). T-Speicher ist bei ~40° (das entspricht dem Wasser an der Zapfstelle und passt komischerweise relativ gut zur Vorlauftemperatur der Heizung). Um das ganze besser zu verstehen habe ich ein paar Fragen zu den angegebenen Werten. Welche Temperaturen werden mit "T-Ist", "T-Speicher" und "T-Speicher Unten (Solar)" genau angezeigt und wo werden sie gemessen. Sollte T-Ist tatsächlich so irgendwo im System vorhanden sein, müsste ja ein Ventil / Mischer defekt sein und das Wasser nicht in den Kreislauf geben. Sollte die Temperatur nicht korrekt sein, würde ich auf einen NTC tippen. Letztes Jahr war ein Heizungsbauer vor Ort, der wollte so auf Verdacht einen NTC austauschen, er war sich aber auch nicht sicher. Da nach 2 Tagen der Selbstheilungsprozess eingesetzt hat, haben wir es damals gelassen. Hat einer eine Meinung dazu? Besten Dank für Deine / eure Ideen! Gruß André
Hallo André, da ich auch ein CerapurSolar-Heizgerät (CSW) habe kann ich Dir hoffentlich einige Fragen beantworten. > Welche Temperaturen werden mit "T-Ist", "T-Speicher" und "T-Speicher > Unten (Solar)" genau angezeigt ? "T-Speicher" ist der Temperatur-Wert des WW-Pufferspeichers und wird mit einem WW-Telegramm gesendet. "T-Speicher unten" (Solar) ist der Temperatur-Wert des TS2 - Temperatursensors am Systempufferspeicher SP400 (Details siehe Bilder). Dieser Wert wird mit einem Solar-Telegramm gesendet. "T-Ist" (WW) kommt vom Temperatursensor im Mischventil (MV) des CSW. Dieses Ventil ist speziell im CSW eingebaut, andere Junkers-Heizgeräte haben dies meines Wissens nicht (siehe Beschreibung im Bild). T-Ist (WW) wird mit einem WW-Telegramm gesendet und aufgezeichnet. Allerdings wird dieser Temperaturwert des Mischventils (MV) auch in einem Heizgerät-Telegramm verwendet, Anzeige im Systemstatus als Wert: "T-3Wege Mischer". Hinweis: Da diese Telegramme nicht zeitgleich gesendet werden sind die angezeigten Werte u.U. leicht unterschiedlich (in den Nachkomma-Stellen), gleichen sich aber wieder an. Wird durch das Heizgerät kein WW erzeugt, so steht das Mischventil (MV) und das 3-Wege Umsteuerventil (DWU) auf Stellung "Heizen". Der Temperaturfühler im Mischventil (MV) misst also die Temperatur im Vorlauf in der Nähe der Heizungspumpe (HP). Somit passt die angezeigte Temperatur von ca. 75Grad durchaus zu Deinem Heizungssystem (Vorlauf), da Du ja neben der Fussbodenheizung auch Radiatoren hast. Die Verwendung der Mischventil-Temperatur im WW-Telegramm als "T-Ist" beim CSW-Heizgerät ist also denkbar ungünstig von Junkers gelöst. Dies ist also kein Fehler in Deinem Heizungssystem und der NTC funktioniert ja auch. Allerdings fällt mir in Deinem WW-Plot auf, das die Warmwasser-Erzeugung (hellblau) sehr häufig ausgelöst wird und das die WW-Speichertemperatur (hellgrün) nicht mal in die Nähe des Soll-Wertes gelangt. Bei meiner Anlage ist dies sichtbar anders (siehe Bild). Wenn die WW-Speichertemperatur unterhalb des Grenzwertes fällt wird das Heizgerät auf Warmwasser-Erzeugung umgeschaltet und solange geheizt bis der Sollwert erreicht ist. Der Wert "Speichertemperatur OK" wird dann angezeigt wenn die Speichertemperatur nicht unter den Grenzwert absinkt. Hinweis: Dieser Grenzwert hängt von der ECO-Taste aktiv/inaktiv ab. Mein Tipp um der Sache näher zu kommen: 1. HT3_Analyser starten und die Werte (Temperatur / Flags) kontrollieren, insbesondere für "T-3Wege Mischer (HG)", "3-Weg -> WW-Speicher (HG)", "Betriebsmodus (HG)", "Warmwasser-Erzeugung" und "Speichertemperatur OK". 2. WW Sollwert mal zum Test auf 60 Grad erhöhen. Dann muss "Speichertemperatur OK" auf "Nein" stehen, der "Betriebsmodus (HG)" auf Warmwassererzeugung umschalten und sich die WW T-Speichertemperatur erhöhen. Eventuell dann noch die Taste "Warmwasser-Sofort" am Regler drücken. 3. Kontrollieren ob Störungsmeldungen in HT3_Analyser und Regler vorhanden sind. 4. Alte Plots aus rrdtool-db auswerten, bei denen das System in Ordnung war. Vielleicht funktioniert das Mischventil im CSW-Heizgerät nicht mehr so wie es soll, aber dies ist nur meine laienhafte Vermutung. Gruß Norbert
:
Bearbeitet durch User
Guten Morgen, was läuft bei mir denn falsch? Die RRDTools Grafiken werden nicht generiert auf Grund folgenden Fehlers:
1 | pi@heattronic-pi:~/HT3/sw/var/log $ /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi /home/pi 1 |
2 | rrdtool graph /home/pi//HT3/sw/etc/html/HT3_Heizgeraet.png --vertical-label Temperaturen (Celsius) --width 740 --right-axis-label Temperaturen (Celsius) --title Heizgerät (07:46:28 04.10. - 07:45:28 06.10.2017) --right-axis 1:0 --start 1507095988 --end 1507268728 --height 310 DEF:modusfkt=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_modus:MAX CDEF:draw2=modusfkt,45,* AREA:draw2#e9ddaf DEF:Brennerleistung=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_leistung:MAX AREA:Brennerleistung#cccccc:Brennerleistung (%) VDEF:Brennerleistung_last=Brennerleistung,LAST COMMENT: last\: GPRINT:Brennerleistung_last:%2.lf\l DEF:TSoll=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_vorlauf_soll:MAX LINE1:TSoll#ff0000:T-Soll (Regelung) VDEF:TSoll_last=TSoll,LAST COMMENT: last\: GPRINT:TSoll_last:%2.lf\l DEF:TIst=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_vorlauf_ist:MAX LINE1:TIst#0000ff:T-Ist (Vorlauf) VDEF:TIst_last=TIst,LAST COMMENT: last\: GPRINT:TIst_last:%2.1lf\l DEF:TRueck=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_ruecklauf:MAX LINE1:TRueck#00ff00:Rücklauf VDEF:TRueck_last=TRueck,LAST COMMENT: last\: GPRINT:TRueck_last:%2.1lf\l DEF:zirkula_pumpe=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_zirkula_pumpe:MAX CDEF:draw12=zirkula_pumpe,10,* AREA:draw12#d45500:Zirkulations-Pumpe\l DEF:Heizungspumpenleistung=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:V_spare_1:MAX LINE1:Heizungspumpenleistung#008d00:Heizungspumpenleistung (%) VDEF:HP_Leistung_last=Heizungspumpenleistung,LAST COMMENT: last\: GPRINT:HP_Leistung_last:%2.lf\l DEF:Aussentemperatur=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:T_aussen:MAX LINE2:Aussentemperatur#000055:Aussentemperatur min\: VDEF:Aussentemperatur_min=Aussentemperatur,MINIMUM GPRINT:Aussentemperatur_min:%3.1lf VDEF:Aussentemperatur_max=Aussentemperatur,MAXIMUM COMMENT:max\: GPRINT:Aussentemperatur_max:%3.1lf VDEF:Aussentemperatur_last=Aussentemperatur,LAST COMMENT: last\: GPRINT:Aussentemperatur_last:%3.1lf\l DEF:BZeitg=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:C_betrieb_gesamt:LAST VDEF:BZeitg_average=BZeitg,LAST GPRINT:BZeitg_average: Betriebszeit gesamt \: %6.1lf Stunden\l DEF:brennereinheiz=/home/pi//HT3/sw/var/databases/HT3_db_rrd_heizgeraet.rrd:C_brenner_heizung:LAST VDEF:brennereinheiz_last=brennereinheiz,LAST GPRINT:brennereinheiz_last: Brenner ein \: %6.lf Zähler COMMENT: \s COMMENT: \s --color CANVAS#fff6d5 --color BACK#ffdd55 failed: invalid format string '%2.lf\l' (should match '^(?:[^%]+|%%)*%[-+ 0#]?[0-9]*(?:[.][0-9]+)?l[eEfFgG](?:[^%]+|%%)*(?:%s)?(?:[^%]+|%%)*$') at /usr/share/perl5/RRDTool/OO.pm line 444 |
Dieser Fehler kommt: failed: invalid format string '%2.lf\l' (should match '^(?:[^%]+|%%)*%[-+ 0#]?[0-9]*(?:[.][0-9]+)?l[eEfFgG](?:[^%]+|%%)*(?:%s)?(?:[^%]+|%%)*$') at /usr/share/perl5/RRDTool/OO.pm line 444 Danke schon mal...
Hallo, ich habe noch eine Frage. Ich besitze eine CSW 14/75-3 A mit 3 Solar Kollektoren, dem 415 Liter Pufferspeicher mit Fußbodenheizung. Müsste bei mir nicht auch der T-3Wege Mischer im Heizgerät-Telegramm auftauchen? Ich finde aber in der SQLite DB keinen Eintrag dazu. Grüße Marc
Hallo Marc,
der Anzeige-Wert: "T-3Wege Mischer" steht als logitem-name: "T_mischer"
in den Datenbanken.
Die Datenbank-Spalten werden nur mit den logitem-Namen generiert.
Den Zusammenhang zu den Anzeigenamen sieht man im Konfigurationsfile:
...
<logitem name="T_mischer">
<datatype>REAL</datatype>
<datause>GAUGE</datause>
<maxvalue>100.0</maxvalue>
<default>0.0</default>
<unit>Grad</unit>
<displayname>T-3Wege Mischer</displayname>
<accessname>ch_T3waymixer</accessname>
</logitem>
Der Wert für T_mischer wird mit Msg_ID:24 gesendet.
sqlite-Einträge siehe Bilder.
> failed: invalid format string '%2.lf\l' (should match...
Die Fehlermeldung muss ich noch auswerten. Dir hilft es ja nicht wenn
ich sage das der bei mir nicht auftritt.
Allerdings hatte ich vor kurzem einen vergleichbaren Fehler auch schon
von einem anderen Forumsteilnehmer erhalten.
Letztendlich hat er dann das Raspbian Linux installiert und der Fehler
war weg. Bis dato hatte ich angenommen das dies ein Einzelfall sei.
Tritt dieser Fehler sporadisch auf oder ständig?
Gruß Norbert
Hallo Norbert, danke für deine Antworten. Bzgl. des Fehlers, ja der tritt immer auf, also immer dann, wenn neue Grafiken generiert werden sollen. Ich habe erstmal den Heizgeräte Part auskommentiert um die restlichen Grafiken zu sehen (die funktionieren einwandfrei). Aber sobald ich die rrdtool_draw.pl durch die original Version wieder ersetze, rasselt das Script sofort in den Fehler. Mein Raspbian läuft mit: Linux ht-pi 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux rrdtool in der Version: 1.6.0-1+b1 librrdtool-oo-perl: 0.36-1 --- Mir ist noch eine kuriose Sache in der DB aufgefallen. Mein T-Soll Wert beim WW rutscht manchmal auf 0 für einige Telegramme um anschließend wieder auf den normalen Wert von 60 zu kommen. Ich habe die Grafik mal angehängt. Nicht wundern, die Zeitspanne habe ich auf 6 Stunden reduziert. Deutlich zu sehen sind die Ausbrecher gen 0. Da dieser 0 Wert nur für ein paar Sekunden (maximal 10-15) in den DBs existiert, erreicht die T-Soll Linie nicht 0. Ich habe mal die SQLite DB für mit der WW Tabelle angehängt.
Hallo Marc, > failed: invalid format string '%2.lf\l' (should match... Folgendes habe ich dazu gefunden: Das Problem ist rrdtool versionsabhängig. rrdtool- version script-run linux-release 1.4.7___OK_______wheezy 1.4.8___OK_______jessie 1.6.x___Fehler___stretch, buster, sid Was genau die Ursache ist kann ich nicht sagen, da ich nur wheezy und jessie einsetze. Wahrscheinlich ist im rrdtool die Integer/Float-Typprüfung verändert/verbessert worden. Vorschlag: Deaktiviere zum Test die Zeilen/Blocks im rrdtool_draw.pl script in denen '%2.lf\l' vorkommt. Nur im Heizgeräte-draw werden an den Stellen Integer-Werte eingetragen. > Mein T-Soll Wert beim WW rutscht manchmal auf 0 Werde Deine sqlite-db noch auswerten. Welchen Adapter setzt Du ein? Ich nehme mal an einen HT3_Mini- oder HT3_Micro-Adapter? Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, >> failed: invalid format string '%2.lf\l' (should match... > Folgendes habe ich dazu gefunden: > Das Problem ist rrdtool versionsabhängig. > rrdtool- > version script-run linux-release > 1.4.7___OK_______wheezy > 1.4.8___OK_______jessie > 1.6.x___Fehler___stretch, buster, sid > Was genau die Ursache ist kann ich nicht sagen, da ich nur wheezy und > jessie einsetze. > Wahrscheinlich ist im rrdtool die Integer/Float-Typprüfung > verändert/verbessert worden. > Vorschlag: > Deaktiviere zum Test die Zeilen/Blocks im rrdtool_draw.pl script in > denen '%2.lf\l' vorkommt. Nur im Heizgeräte-draw werden an den Stellen > Integer-Werte eingetragen. Alles klar, das versuche ich mal. Möglich das der Versionssprung die Ursache ist. >> Mein T-Soll Wert beim WW rutscht manchmal auf 0 > Werde Deine sqlite-db noch auswerten. Danke. > Welchen Adapter setzt Du ein? Ich nehme mal an einen HT3_Mini- oder > HT3_Micro-Adapter? Ich habe den HT3 Mini zusammengelötet. Gruß Marc
Hi Norbert, leider gibt es nach 2 Tagen Betrieb Probleme mit ht_tiny Adapter. Auf dem Adapter flackern zwar beide LEDs wie sie sollen, aber es scheint keine Kommunikation mit dem PI mehr zu geben. Ich habe das System gerade komplett neu auf einem PI-3 mit Debian Jessie aufgesetzt, leider ohne Erfolg. Irgendeine Idee, wie ich weiter testen kann? Update: wenn ich ht_collgate und ht_proxy stoppe, blinkt nur noch die grüne LED. D.h. kein Bussignal vorhanden. Der CW100 läuft allerdings normal. Danke und Gruß Michael
:
Bearbeitet durch User
Hallo Michael, > wenn ich ht_collgate und ht_proxy stoppe, blinkt nur noch > die grüne LED. D.h. kein Bussignal vorhanden. Dies ist 'normal' und kein Fehler. Im start-script wird bei Eingabe von 'stop' der spi-Port wieder aktiviert und der spi-Treiber meint: 'Jetzt bin ich Herr im Haus und blockiert das HTBus-Empfangssignal :-(. Beim Start des collgate-daemon wird dieser SPI-Port deaktiviert und für den HT-Bus genutzt :-) Du kannst also zum Test einmal folgendes als user 'pi' eingeben: sudo ~/HT3/sw/etc/sysconfig/spi_clk_off.py Die grüne und rote LED müssen dann wieder wie gewohnt blinken wenn der HT-Bus angeschlossen ist. Du hast einen PI3 und der hat netterweise ein Bluetooth an Board. Leider wird der serielle Port dafür verballert den wir aber nutzen wollen. Deshalb meine Frage ob Du die nötige Deaktivierung dieser Schnittstelle durchgeführt hast? Siehe auch Doku Seite 51ff oder unter URL: https://forum.fhem.de/index.php/topic,50340.0.html Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, die Heizgeräte Grafik funktioniert nun. Ich habe %2.lf\l durch %2.0lf\l ersetzt, bzw. %6.lf durch %6.0lf. Vielleicht erwartet die neue Version da genauere Angaben zu den Nachkommastellen. In der Heizgeräte Grafik habe ich das gleiche Phänomen wie bei dem T-Soll Wert. Ich werde das Kabel von dem HT-Mini Adapter zum Bus mal etwas kürzen. Aktuell ist dies, weil ich es erstmal nur testen wollte ob es überhaupt geht, ein altes Lautsprecherkabel welches 2 Meter oder so lang ist. Ein bisschen wundere ich mich allerdings über die Zirkulationspumpe. Ist eine solche Pumpe nicht normalerweise dafür da um an den Warmwassserzapfstellen das warme Wasser zirkulieren zu lassen? Also damit man immer flott warmes Wasser zur Verfügung hat? Einen solchen Kreislauf bzw. eine solche Pumpe besitze ich nicht. Oder wird der Wert von einer anderen Pumpe genommen? Gibt es vielleicht irgendwo eine Grafik in der eingezeichnet ist, welcher Wert wo abgegriffen wird? Das wäre für einen Noob wie mich sehr hilfreich ;) Grüße Marc
Hallo Marc,
prima das das Script rrdtool_draw.pl jetzt geht und die Ursache
eingegrenzt ist!
> Mein T-Soll Wert beim WW rutscht manchmal auf 0 ...
Ursache ist eine Fehldetektion des Telegramms: MsgID 51_0.
In Deinem sqlite-Datenbank-File ist dies z.B. beim Eintrag#: 4808 zu
sehen (siehe Bild).
Dort startet das Telegramm mit a0 00 33 00 30 00 b0 00 ...
Der Wert 'b0' wird der Soll-Temperatur zugeordnet (ist richtig) jedoch
der Wert an sich ist als Temperatur zu hoch (176 Grad). Deshalb wird in
die Datenbank der default-Wert -> 0 eingetragen.
Eine Fehldetektion kann immer mal bei den Adaptertypen HT3_Mini- und
HT3-Micro vorkommen, weil die Break-Erkennung als Telegramm-Endekennung
damit nicht möglich ist.
In Deinem System hast Du mindestens einen gemischten Heizkreis mit dem
Modul IPM(x). Deshalb kann diese Sequenz: a0 00 33 00 ... durchaus
vorkommen wenn dieses IPM-Modul auch die Warmwasser-Regelung (Heizgeräte
externe Warmwassererzeugung) macht.
Ich nehme mal an das dies bei Dir nicht der Fall ist.
Deshalb trage den Wert '51' in das python-Modul: lib/ht_discode.py für
Geräteadr (20)hex bis (23)hex ein:
Zeilen: 2607 ff
# device-adr mapped with not valid message-IDs for detailed message
- searching
deviceadr_2msgid_blacklist = {
0x10: [11, 12, 24, 46, 47, 64, 100, 106],
0x1b: [17, 56, 74, 89],
0x20: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
0x21: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
0x22: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
0x23: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
}
Damit wird Telegramm MsgID_51 für Module (20...23)hex unterdrückt.
Bitte erzeuge noch ein binäres Logfile von Deiner Anlage und lass es
mir zukommen. Dann kann ich mir dies noch zusätzlich ansehen und
auswerten.
Der Regler aktiviert die Zirkulationspumpe und teilt dies in einem
Telegramm mit. Dem Regler ist es egal ob wirklich eine Pumpe da
vorhanden ist oder nicht. Er hat jedenfalls das Relay dafür angesteuert
und seine Pflicht getan. Dies kann man wohl auch ruhigstellen, must mal
im Handbuch des Reglers nachlesen.
Die Telegramme sind dokumentiert unter:
~/HT3/sw/etc/html/HT3-Bus_Telegramme.html
Gruß Norbert
:
Bearbeitet durch User
Hi Norbert, viele Dank, das scheint zu funktionieren. Allerdings erst, nachdem das Teil 2 Tage lang ausgeschaltet in der Ecke lag. Nach erneutem Start bekomme ich jetzt wieder Daten. Viele Grüße Michael
Hallo Norbert, ich habe das BINLOG-File mal hier hochgeladen. Ich suche in den DB Werten noch den Wert der geforderten Vorlauftemperatur. In dem FW120 Bedienterminal unter Info -> Heizkreis steht etwas von 25,7 Grad. Dieser müsste auch in der Binlog Datei unter den neusten Werten zu finden sein (falls vorhanden). Den Wert T_soll_HK von 21.0 Grad in Heizkreis Tabelle kann ich nicht ganz nachvollziehen. Gruß Marc
Moin, Marc S. schrieb: > Den Wert T_soll_HK > von 21.0 Grad in Heizkreis Tabelle kann ich nicht ganz nachvollziehen. Ich habe den Wert mitlerweile gefunden. Man setzt diesen ja als Wert für den jeweiligen Modus (in meinem Fall bei Heizen) ein. Jetzt interessiert es mich aber doch ob ich solche Werte wie: Geforderte Vorlauftemperatur (beim HK) oder so sehen kann. Oder sind Werte wie: Maximale Vorlauf- bzw. Warmwassertemperatur auch in irgendwelchen Telegrammen logbar? Grüße Marc
Hallo Marc, >Jetzt interessiert es mich aber doch ob ich solche Werte wie: Geforderte >Vorlauftemperatur (beim HK) oder so sehen kann. Du kannst den HT3_Analyser.py dazu verwenden. Die Bilder zeigen die WW -Telegramme so wie diese in Deinem bin-Logfile enthalten sind. Bei Deinem System ist ein gemischter Heizkreis mit dem Modul IPM1 vorhanden. Diese Telegramme beginnen mit: a0... Die Telegramme mit: 90...sind vom Regler Fxyz. Im Analyser werden die MessageID's für den jeweiligen Systempart in Kurzform erklärt. Details sind dokumentiert unter: ~/HT3/sw/etc/html/HT3-Bus_Telegramme.html Die empfohlene Änderung in 'deviceadr_2msgid_blacklist' (siehe oben) habe ich testet und die funktioniert auch. Deshalb kannst Du diese Änderung ohne weiteres übernehmen. Die Fehldetektionen der WW-Solltemperatur werden damit dann unterdrückt. Gruß Norbert
Hallo Norbert, manchmal kommen kurzfristig falsche Werte. Schau bitte Zeile 305 - das macht Message: 25_0 :HG :90 00 19 00 10 00 90 00 21 00 29 00 10 00 90 88 16 00 02 af 00 88 10 16 00 ff 43 9d 00 90 00 31 00 39 00 10 00 Wie kann ich die Message unterdrücken? FW120, nur Heizkörper. Danke und grüße
Hallo adam,
>Wie kann ich die Message unterdrücken?
Trage den Wert '25' (dezimal) in das python-Modul: lib/ht_discode.py für
Geräteadr (10)hex ein:
Zeilen: 2607 ff
# device-adr mapped with not valid message-IDs for detailed message
- searching
deviceadr_2msgid_blacklist = {
0x10: [11, 12, 24, 25, 46, 47, 64, 100, 106],
0x1b: [17, 56, 74, 89],
0x20: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
0x21: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
0x22: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
0x23: [13, 14, 15, 21, 23, 25, 29, 45, 49, 51, 61, 81, 88, 92,
95, 97, 101, 104, 107],
}
Damit wird dann das Telegramm 90 00 19... (hex) unterdrückt.
Der ht_collgate - daemon muss natürlich nach dieser Änderung neu
gestartet werden.
Gruß Norbert
:
Bearbeitet durch User
Guten abend zusammen, habe nun einige Zeit diesen Thread und auch noch einen anderen zum Thema Junkers und HT3-Bus gelesen. Selbst bin ich sehr am Projekt interessiert (vorab danke für diese tolle Arbeit!). Allerdings habe ich einige Unklarheiten bzw. Unsicherheiten: 1. Ich besitze eine Junkers Cerasmart Heizung mit TA211E und DT-2. Wenn ich das richtig lese, wird das HT3-protokoll unterstützt (in den anleitungen liest man zwar immer von Heatronic, aber nie von HT3 - gibt es hier möglicherweise noch Unterschiede?). Aber habe ich das auch richtig verstanden? Kann ich die hier vorgestellte Lösung einsetzen? 2. Linux und Python ist für mich ok, aber löten... das ist immer etwas haarig bei mir. Würde mir jemand einen Adapter gegen einen entsprechenden Obulus bauen? Das Modul soll dann an meinem rasppi zero w arbeiten. 3. Gelesen habe ich, dass das Modul verpolungssicher gebaut ist - d.h. also, wenn ich die korrekten Anschlüsse verwende, kann ich nicht wirklich was kaputt machen? 4. Ich würde auch gerne die Heizung darüber steuern können. Im Vorfeld hatte ich als Idee, den Außenfühler "abzugreifen". Den Wert kann ich dann weiterreichen, oder aber bei Bedarf beeinflussen. Lässt sich diese Idee realisieren? Idealerweise mit Funktion bei Ausfall des Zwischenmoduls (kann z.b. rpi besimmte gpios im ausgeschalteten zustand durchschleifen?)... Ein hohes Ziel, dessen bin ich mir bewusst... gruß in die Runde und angenehme Resttage vor der Weihnachtszeit!
Hallo Andre G, > Ich besitze eine Junkers Cerasmart Heizung mit TA211E und DT-2... Deine Heizung und der Regler hat wohl keinen Heatronic -Bus. Dies entnehme ich den Unterlagen von Junkers für Deine Heizung. Junkers hat eine Kompatibilitätsliste auf der Web-Seite und auch dort ist die 'Cerasmart' Heizung nicht enthalten. URL mit PDF-File: https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/waermepumpen_neu_/kompatibilitaetslisten/home_und_multi_home__kompatible_junkers_geraete.pdf HT3 steht als Abkürzung für: Heatronic in Version 3. Es gibt da noch Heatronic 4i und für die neuen Heizsysteme mit den Cxyz-Reglern und den EMS2 - Bus. Es muss also ein Bus vorhanden sein, der zumindest Heatronic 3 entspricht. Heatronic2 geht da also auch nicht. Die hier vorgestellte Datenerfassung mit den zugehörigen Adaptern funktioniert also für alle Heatronic3, Heatronic4i und EMS2-Bussysteme. Dies sind wohl alle Systeme ab Baujahr 2008. Leider entspricht Deine Heizung und der zugehörige Regler nicht dem Profil. Zumindest die Junkers-Unterlagen zu Deiner Heizung machen mir da keine Hoffnung. Gruß Norbert
Vielen Dank für dine Mühe. Interessanterweise spricht zumindest die Anleitung der Steuerung der Anlage (TA211e) von Heatronic: http://www.manderfeld.de/downloads/ta_211e.pdf die Version des HT-Protokolls ist natürlich nicht angegeben. Ich glaube, ich schraube das Teil mal auf uznd schaue nach. Denn wenn ich das richtig sehe, dann müsste das Modul bei 2-adriger Anbindung auf HT3 hinweisen, bei analoger Anbindung wäre es 3-adrig angebunden... Hab ich denn eine Chance, über Messungen an den Polen herauszufinden, ob meine Heizung schon HT3 "spricht"? gruß und danke schonmal. andre
Hi, gibt es eigentlich eine Möglichkeit die Betriebsart "Auto" zu erkennen als aktuellen Status eines Heizkreises? Ich würde gerne für die Integration in eine Haussteuerung den "Wunschstatus" mit dem echten abgleichen und diesen dann versuchen zu setzen. Jedoch gibt es die Betriebsart Auto ja nicht in der Statusausgabe. Viele Grüße, Nils
Hallo Nils, >gibt es eigentlich eine Möglichkeit die Betriebsart "Auto" zu erkennen? Ja, z.B. mit dem HT3_Analyser und HT3_Systemstatus wird dieser Wert als 'Betriebsstatus' angezeigt (siehe Bild). In den zugehörigen Telegrammen wird dieser Wert gesetzt (siehe Bild für Fxyz-Regler). >Ich würde gerne für die Integration in eine Haussteuerung den "Wunschstatus" mit >dem echten abgleichen und diesen dann versuchen zu setzen. Ja, dies geht z.B. mit dem Tool:'~/HT3/sw/ht_netclient.py'. Der Aufruf: ./ht_netclient.py -h zeigt Dir welche Parameter nötig sind. Der Aufruf: ./ht_netclient.py -b heizen bringt die Heizung in den 'Manuellen'-Mode. Der Aufruf: ./ht_netclient.py -b auto bringt die Heizung wieder in den 'Auto'-Mode. Du solltest dafür die aktuelle Software Rel. 0.3 verwenden. Gruß Norbert @Moderator Im Bearbeitungsmode lassen sich Bilder (z.B. doppelte) nicht mehr löschen. Sicher lässt sich dies noch verbessern :-)
:
Bearbeitet durch User
Hi Norbert, danke für die Beschreibung. Die Umschaltung habe ich schon am Laufen nur aufgrund der Anbindung des PI mit Wlan manchmal das Problem, dass die Verbindung nicht klappt. Daher würde ich gerne den gewünschten Modus mit dem aktuellen in der Heizung vergleichen. Derzeit lese ich die aktuellen Parameter aus der SQLite DB aus, aber dort konnte ich den Status für "Auto" nicht finden. Es wird nur der aktuelle Status in meiner eingesetzten Version gespeichert (wenn ich den nicht übersehen habe). Kannst du mir sagen, wie ich den Status inkl. "Auto" auslesen kann? Viele Grüße, Nils
Hallo Nils, der Wert für den Betriebstatus (u.A. 'Auto') steht in der sqlite-DB unter 'V_operation_status'. 'Auto' hat für den Fxyz-Regler den Wert: 2. Diese Namen sind im Konfigurations-File als 'logitem name' festgelegt und die Datenbanken werden mit diesem Namen erzeugt. Der Zusammenhang zum angezeigten GUI-Namen ergibt sich ja aus dem logitem. Somit kannst Du auch andere Daten zuordnen. Auszug aus dem Konfig-File: <logitem name="V_operation_status"> <datatype>INT</datatype> <datause>GAUGE</datause> <maxvalue>10</maxvalue> <default>0</default> <unit></unit> <displayname>Betriebsstatus</displayname> <accessname>hc1_operationstatus</accessname> </logitem> Bei der Abfrage des Betriebsstatus nach einer Änderung musst Du Dir Zeit lassen, weil leider das zugehörige Telegramm nicht sofort nach einer Änderung sondern schlimmstenfalls nach 1 Minute gesendet wird. Gruß Norbert
:
Bearbeitet durch User
Norbert S. schrieb: > Junkers hat eine Kompatibilitätsliste auf der Web-Seite und auch dort > ist die 'Cerasmart' Heizung nicht enthalten. > URL mit PDF-File: > https://junkers-de.resource.bosch.com/media/de_nj/endkunde/03_produkte/waermepumpen_neu_/kompatibilitaetslisten/home_und_multi_home__kompatible_junkers_geraete.pdf Der Link läuft leider ins Leere. Kann jemand die Datei zur Verfügung stellen? Ich wüsste gerne, ob meine Heizung unterstützt wird.
Norbert S. schrieb: > der Wert für den Betriebstatus (u.A. 'Auto') steht in der sqlite-DB > unter 'V_operation_status'. > 'Auto' hat für den Fxyz-Regler den Wert: 2. Aha, das hab ich wohl übersehen. Eigentlich gebe ich mir alle Spalten der Datenbank als Webservice aus, um diese in eine Oberfläche einzulesen. Bin derzeit immer vom Betriebsart ausgegangen, dass es dort drinnen stehen muss. Danke dafür, das probiere ich aus. Viele Grüße, Nils
Hallo Zusammen, ist etwas OffTopic, zur Analyse habe ich aber HT3 eingesetzt :-) Die Heizungspumpe UPM 15-70 die in der Heizung verbaut ist bleibt unregelmäßig stehen. Meistens direkt nach der Warmwasserladung. Danach geht die Heizung auf über 100 Grad, da die Wärme nicht abtransportiert wird. Nach dem Abkühlen geht es wieder auf 100 Grad, usw. Ausschalten und neu Einschalten der ganzen Heizung hat die Pumpe dann für Tage/Wochen wieder zum Leben erweckt. Beim letzten Ausfall habe ich die Spannung an der Pumpe gemessen. Spannung war da. Stecker im Betrieb bei der Pumpe abgezogen und neu aufgesteckt. Pumpe läuft wieder an. Der Heizungsmonteur hatte noch die Idee die Steuerung an der Pumpe abzuziehen. Damit läuft die Pumpe auf 100%, hat aber weiterhin die sporadischen Ausfälle. Ich gehe momentan davon aus, das die Pumpe eine Blockierung feststellt, obwohl da keine ist. Wer hat eine bessere Idee? 1. kann ich mit dem ht_netclient.py auch einen Reset durchführen? Eventuell kurz in den frost-Modus gehen? Die Pumpe gibt den aktuellen Betriebszustand an die Heizung zurück. http://net.grundfos.com/Appl/WebCAPS/Grundfosliterature-4927111.pdf (seite 10.) Kann man das irgendwo abfragen? Oder muss ich da mit einer eigenen Schaltung dran? Im Display der Buderus sehe ich keine Fehlermeldung. Grüße
Hallo zusammen, ich habe ein Problem mit meiner HT3-Datenerfassung. In unregelmäßigen Abständen (gefühlsmäßig nach einem viertel Jahr) friert die Datenerfassung einfach ein. Es werden keine aktuellen Daten mehr angezeigt. Im Browser werden zwar noch die Diagramme geöffnet, leider ohne Historie und aktuellen Daten (siehe Anhang). Das Datum steht dann auch in der Vergangenheit. Per SSH kann ich noch auf den Pi zugreifen und einen Reboot durchführen. Aber leider funktioniert die Datenerfassung danach auch nicht. Bisher habe ich dann schon zwei Mal den Pi komplett neu aufgesetzt. Das ist auf Dauer ein klein wenig nervig. Habe nur ich das oben geschilderte Problem? Wie kann ich die HT3-Erfassung wieder zum Leben erwecken? Wie sichert bzw. Werte Ihr die Daten auf dem PI aus ? Wünsche Allen frohe Ostern Hans
@Hans Ich habe von Anfang an ein ähnliches Problem. Nach einer gewissen Laufzeit von ein paar Monaten bekommt die Aufzeichnung immer mehr Lücken. Ich muss dann immer die sqlite DB wegkopieren bzw. löschen. Nach einem Neustart wird die DB wieder leer angelegt und es läuft wieder ein paar Monate. Ob es sich um denselben Effekt handelt kann ich dir leider nicht sagen. Müssten eigentlich alle haben dieses Problem. Oder es liegt an einer bestimmten Version. Vielleicht meldet sich ja der Norbert noch. Klaus
Hi Klaus, Dankeschön für die Info. Werde ich am Wochenende mal ausprobieren. Viele Grüße Hans
Hallo Hans, bin mir nicht sicher ob Du die sqlite-DB aktiviert hast (per default ist diese aus). Falls ja dann würde ich wie von Klaus beschrieben die sqlite-DB neu aufsetzen (erzeugen). Ich gehe auch davon aus, das Du das letztgültige Software-Releae: 0.3 installiert hast. Nach längerer Zeit kann die DB doch recht gross werden und der Pi hat damit dann mächtig zu tun. Wenn die sqlite-DB aktiviert wurde so werden Daten älter als 30 Tage normalerweise aus der DB gelöscht, Eintrag: (<autoerase_olddata>30</autoerase_olddata>) im Konfigurationsfile. Ich vermute jedoch das Du die sqlite-DB nicht aktiv hast. Wenn dem so ist liegt wohl noch ein anderes Problem vor. Bitte kontolliere im Fehlerfall mal das /tmp Verzeichnis. Wenn dort sehr viele perl-scripte (*.pl) liegen bleiben so werden die Daten nicht in die rrdtool-db eingetragen. Diesen Fall hatte ich schon mal, der aber nach einem reboot des PI wieder behoben war. Eine Neuinstallation war nicht nötig gewesen. Beachte bitte auch das nach einem reboot die Datenerfassung erst neu aufgesetzt wird und erst nach ca. 5 -10 Minuten wieder Daten in den Anzeigen zu sehen sind. Gruß Norbert
Beitrag #5379175 wurde von einem Moderator gelöscht.
Hallo Markus (Gast), > kann ich mit dem ht_netclient.py auch einen Reset durchführen? > Eventuell kurz in den frost-Modus gehen? Einen Reset kann man nur auf den ht_pitiny-Adapter ausführen jedoch nicht auf die Heizung und deren Module. > Die Pumpe gibt den aktuellen Betriebszustand an die Heizung zurück. > Kann man das irgendwo abfragen? In den 'normalen' Betriebstelegrammen habe ich dafür noch keinen Platzhalter gefunden. > Im Display der Buderus sehe ich keine Fehlermeldung. Wenn der Fehler weg ist findet man diesen in der Historie. Je nach Regler wird dieser Wert abgespeichert und sichtbar (in der Fachman-Ebene). Es sollte ein Fehler angezeigt werden wenn die Steuerung der Pumpe abgezogen ist. Zumindest gibt es dafür einen Fehlertext. Dies wird je nach Heizgerät in der Heizungssteuerung gemacht. Falls also doch kein Fehler zu finden ist erkennt die Heizung auch das Blockieren der Pumpe nicht. Wie in Deinem Bild zu sehen hast Du ja schon mehrfach die Rotor Abdeck-Schraube gelöst. Ist im Fehlerfall der Pumpen-Rotor leicht zu drehen oder sitzt der mechanisch fest? Hat der Heizungsfachmann auch schon mal das 3-Wege Umschaltventil kontrolliert? (Dies sollte allerdings funktionieren, sonst hättest Du schon lange kalte Füsse oder kaltes Wasser erhalten :-) Wenn alle Stricke reissen so würde ich die Pumpe ersetzen. Diese ist billiger als ein neuer Wärmetauscher. Gruß Norbert
Hallo, zum Thema: Blockieren von Heizungspumpen nach längerer Stillstand-Zeit noch ein Hinweis: Es ist sinnvoll das Heizgerät im Sommer nicht auszuschalten, da viele der Junkers-Heizgeräte einen Blockierschutz in der Steuerung haben. Diese sorgt dafür das die Pumpen und das 3-Wege Ventil ab und zu betrieben werden und sich dann nicht festsetzen. Gruß Norbert
Moin, ich hab mal mein Raspi aktualisiert und das Problem, dass ich mit ht_netclient nicht mehr auf den Bus schreiben kann. Ich erhalte die Meldung csocketsendThread();Error on socket.send Das Aufzeichnen von Werten klappt einwandfrei. Ich habe auch alles als Modem konfiguriert, anbei ein Screenshot eines neuen Logs. Hab keine Idee mehr woran es liegen könnte. Viele Grüße, Nils
Hallo Nils,
> Ich erhalte die Meldung csocketsendThread();Error on socket.send
Diese Meldung ist vom 'ht_proxy.server'. Der Grund der Meldung ist aber
daraus nicht ersichtlich.
Da sich die Software des 'ht_proxy.servers' seit ca. 3 Jahren nicht
geändert hat muss ein Zusammenhang mit den anderen 'Aktualisierungen' da
sein.
Welche Aktualisierungen hast Du durchgeführt (neues OS, Raspi etc.)?
Gruß Norbert
Hi Norbert, ich hatte noch eine uralte Version der Software (frühe Version mit Proxy) am laufen auf einem Wheezy. Am Jahresanfang hab alles mal aktualisiert und die Konfiguration neu gemacht und dann liegen gelassen, weil ich noch die DB auf einen USB Stick ziehen wollte. Seitdem bekomme ich das Schreiben auf den Bus nicht mehr hin. Die Hardware ist aber gleich geblieben. Dachte eigentlich es liegt an der Konfiguration, aber ich denke die müsste stimmen. Viele Grüße, Nils
Hallo Nils, >ich hatte noch eine uralte Version der Software. >Am Jahresanfang hab alles mal aktualisiert und ... Dann hast Du wahrscheinlich jetzt folgende Software im Einsatz ?: OS: 'Stretch' HT3: Rev.: 0.3 von github In diesem letztgültigen Release hat sich zwar der 'ht_proxy.server' nicht geändert aber viele andere Module in der Library sind angepasst worden. Einige ältere SW-Module sind entfallen. Dazu bitte auf github das readme und die Projekt-Doku lesen. Dort sind die Änderungen beschrieben. URL: https://github.com/norberts1/hometop_HT3 Gruß Norbert
:
Bearbeitet durch User
Hallo! Ich habe würde meine Junkerstherme gerne mit Openhab verbinden. Hat jemand vielleicht schon das ganze in Openhab inplementiert? Musste dazu ein Modul programmiert werden? LG Peter
Hallo Peter, ja, ich habe es gemacht - das geht ganz normal über die MQTT Anbindung. Hier sind ein Paar Beispiele: Number ht3_ch_Treturn "T. Ist (Rücklauf) [%.1f°C]" <dryer> (Junkers) { mqtt="<[broker:hometop/ht/ch_Treturn:state:default]"} Number ht3_ch_Tflow_measured "T. Ist (Vorlauf) [%.1f°C]" <dryer> (Junkers,PersistHT3) { mqtt="<[broker:hometop/ht/ch_Tflow_measured:state:default]"} Number ht3_ch_Tflow_desired "T. Soll (Regelung). [%.1f°C]" <dryer> (Junkers,PersistHT3) { mqtt="<[broker:hometop/ht/ch_Tflow_desired:state:default]"} Number ht3_ch_Toutside "T. Aussen [%.1f°C]" <dryer> (Junkers,PersistHT3) { mqtt="<[broker:hometop/ht/ch_Toutside:state:default]"} Number ht3_ch_T3waymixer "T. 3Wege Mischer [%.1f°C]" <dryer> (Junkers,PersistHT3) { mqtt="<[broker:hometop/ht/ch_T3waymixer:state:default]"} Gruß Juri
Das ganze funktioniert bei mir über die MQTT Schnittstelle. Items entsprechend programieren. Schaltvorgänge über eine Rule. Mfg Martin
Hier noch die Rule. Z.B zum Modus HK verstellen. rule "HK1 Modus" when Item hk1modi changed then if (hk1modi.state ==0) publish ("mosquitto","set/ht3/hc1_Tniveau","auto") if (hk1modi.state ==1) publish ("mosquitto","set/ht3/hc1_Tniveau","frost") if (hk1modi.state ==2) publish ("mosquitto","set/ht3/hc1_Tniveau","sparen") if (hk1modi.state ==3) publish ("mosquitto","set/ht3/hc1_Tniveau","heizen") end Viel Spaß!!! Bei Fragen melde. Lg Matz
Norbert S. schrieb: > Dann hast Du wahrscheinlich jetzt folgende Software im Einsatz ?: > OS: 'Stretch' > HT3: Rev.: 0.3 von github Hi, hab jetzt alles neu installiert und bis auf den blöden Terminal-Service auf dem Interface alles direkt zum Laufen bekommen. Da hat wohl was mit dem update nicht geklappt, jetzt hab ich eine schöne neue Umgebung. :-) Viele Grüße, Nils
Hallo Norbert, ich nutze jetzt seit längerem deine Software mit einem passiven Selbstbauadapter zum Auslesen meiner Heizung. Klappt prima - seit 2 Tagen auch mit MQTT und FHEM. Eine Frage habe ich dennoch - kann das Intervall in dem die Werte kommen irgendwie angepasst werden? Gruß, Thorsten
Norbert S. schrieb: > In diesem letztgültigen Release hat sich zwar der 'ht_proxy.server' > nicht geändert aber viele andere Module in der Library sind angepasst > worden. Hi, habe alles neu Aufgesetzt und leider kann ich noch immer nicht auf den Bus schreiben. Ich hab hier auch davon gelesen, dass andere auch mal das Problem hatten wenn 2 Clients angemeldet waren. Hast du noch eine Idee dazu, ich komme nicht mehr weiter. Viele Grüße, Nils 12.11.2018 22:44:08 INFO: cht_proxy_daemon init 12.11.2018 22:44:08 INFO: cht_proxy_daemon(); common serveraddress used 12.11.2018 22:44:08 INFO: cht_proxy_daemon start as proxy-server:'';port:'8088' 12.11.2018 22:44:08 INFO: logfile:'./var/log/ht_proxy.log' 12.11.2018 22:44:08 INFO: cportwrite();thread start; devicetype:MODEM 12.11.2018 22:44:08 INFO: cportread() ;thread start; devicetype:MODEM 12.11.2018 22:44:10 INFO: Client-ID:1; ('127.0.0.1', 56166) connected 12.11.2018 22:44:10 INFO: Server :('0.0.0.0', 8088) 12.11.2018 22:44:10 INFO: Client-ID:1; register(); got devicetype:RX 12.11.2018 22:44:10 INFO: csocketsendThread(); socket.send thread start 12.11.2018 22:44:10 INFO: Client-ID:1; added; number of clients:1 12.11.2018 22:44:10 INFO: Client-ID:1; cht_RequestHandler(); socket.receive thread start 17.11.2018 09:56:00 INFO: Client-ID:2; ('127.0.0.1', 56332) connected 17.11.2018 09:56:00 INFO: Server :('0.0.0.0', 8088) 17.11.2018 09:56:00 INFO: Client-ID:2; register(); got devicetype:MODEM 17.11.2018 09:56:01 INFO: csocketsendThread(); socket.send thread start 17.11.2018 09:56:01 CRITICAL: csocketsendThread();Error on socket.send 17.11.2018 09:56:01 INFO: Client-ID:2; added; number of clients:2 17.11.2018 09:56:01 INFO: Client-ID:2; cht_RequestHandler(); socket.receive thread start 17.11.2018 09:56:01 INFO: Client-ID:2; ('127.0.0.1', 56332) disconnected 17.11.2018 09:56:01 INFO: Client-ID:2; removed; number of clients:1 17.11.2018 09:56:01 INFO: Client-ID:1;cportwrite();couldn't read from queue 17.11.2018 10:00:49 INFO: Client-ID:3; ('127.0.0.1', 56334) connected 17.11.2018 10:00:49 INFO: Server :('0.0.0.0', 8088) 17.11.2018 10:00:49 INFO: Client-ID:3; register(); got devicetype:MODEM 17.11.2018 10:00:49 INFO: csocketsendThread(); socket.send thread start 17.11.2018 10:00:49 INFO: Client-ID:3; added; number of clients:2 17.11.2018 10:00:49 INFO: Client-ID:3; cht_RequestHandler(); socket.receive thread start 17.11.2018 10:00:49 INFO: Client-ID:1;cportwrite();couldn't read from queue 17.11.2018 10:01:01 INFO: Client-ID:3; ('127.0.0.1', 56334) disconnected 17.11.2018 10:01:01 INFO: Client-ID:3; removed; number of clients:1 17.11.2018 10:01:01 INFO: Client-ID:1;cportwrite();couldn't read from queue 17.11.2018 10:02:20 INFO: Client-ID:4; ('127.0.0.1', 56336) connected
Hallo Thorsten, Thorsten W. schrieb: > Klappt prima - seit 2 Tagen auch mit MQTT und FHEM. > > Eine Frage habe ich dennoch - kann das Intervall in dem die Werte kommen > irgendwie angepasst werden? Ein Intervall kann nur für die rrdtool-db Daten konfiguriert werden. <rrdtool-db> <enable>on</enable> <step_seconds>60</step_seconds> Bei der MQTT-Schnittstelle werden nur die sich ändernden Werte gesendet. Bei FHEM muss man das Notify konfigurieren. Wie das geht bitte im FHEM-Thread nachsehen. Gruß Norbert
Hallo Nils, Nils schrieb: > Ich hab hier auch davon gelesen, dass andere auch mal das > Problem hatten wenn 2 Clients angemeldet waren. Module mit gleicher Geräte-Adresse am gleichen Heizungs-Bus machen Probleme. Dies betrifft alle Module am Bus: MBLan2 und ht_pitiny/ht_piduino haben per Default die gleiche Geräte-Adresse. Diese kann man jedoch beim ht_pitiny/ht_piduino ändern. Siehe die Doku dazu. Wer kein MBLan2 am Bus hat braucht nichts zu ändern! Jedoch wer zwei ht_pitiny / ht_piduinos am gleichen Bus betreibt muss einen davon auf eine andere Adresse einstellen. Wer 'nur' einen passiven Adapter (HT3_Mini- / HT3_Micro-Adapter) hat braucht sich darum keine Gedanken machen. Nils schrieb: > habe alles neu Aufgesetzt und leider kann ich noch immer nicht auf den > Bus schreiben. Der Empfang geht ja wohl jetzt wieder !? Es werden sicher auch Grafiken der rrdtool-db angezeigt? Da Du ja einen 'aktiven' Adapter hast (ht_pitiny/ht_piduino) kontrolliere mal die LED's, insbesondere die Rote LED. Die muss kurzzeitig aufblitzen (auch ohne Befehle zum Bus). Du kannst auch die Debug-Ausgaben des ht_proxy.servers aktivieren im ht_proxy.py File: -->> ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile, loglevel=logging.DEBUG) # ht_proxy=ht_proxy_if.cht_proxy_daemon(configfile) Wichtiger Hinweis: Der ht_proxy.Server muss VOR allen anderen ht_applikationen gestartet werden wenn manuelle Eingriffe gemacht werden. Beim reboot wird dies automatisch durch die Scripte erzielt. Nils schrieb: > Hab hier das gleiche Problem gefunden: > https://forum.fhem.de/index.php/topic,19445.255.html Die von mir dort gemachten Hinweise / Empfehlungen hast Du durchgeführt? Gruß Norbert
Hi Norbert. Ja, das hab ich durch. Die Adresse ist es nicht, da es ja schon mal lange reibungslos lief, bis ich an der Software gefummelt habe. Hab aber alles mal geprüft und diese auch neu gesetzt. Die rote Led blickt vereinzelt. Anbei mal ein Debuglog, vielleicht siehst du was. Ich versuch es auch mal weiter. Viele Grüße, Nils
Hallo Nils, die im Debuglog des ht_proxy (ht_proxy.log) enthaltenen Sendebytes sind OK. Siehe dazu auch: Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi" Die Sequence ist also nicht der Grund warum Du die Heizung nicht steuern kannst. Es sei den Du hast einen Neuen Heizungs-Regler, aber dem ist ja wohl nicht so. Kontrolliere bitte mal ob der alte Prozess 'HT3_logger.py' noch durch den init gestartet wird. Es ist ein Logfile dazu in Deinem ZIP-File (ht_logger.log) enthalten. Das wäre dann nicht gut, weil der alte überflüssige Prozess dann auch zusätzlich die gleichen Daten in die Datenbanken schreibt. Es wird ja nur noch der ht_collgate.py benötigt. Falls nötig in /etc/init.d deaktivieren. Gruß Norbert
Norbert S. schrieb: > Es sei den Du hast einen Neuen Heizungs-Regler, aber dem ist ja > wohl nicht so. > > Kontrolliere bitte mal ob der alte Prozess 'HT3_logger.py' noch durch > den init gestartet wird. Es ist ein Logfile dazu in Deinem ZIP-File > (ht_logger.log) enthalten. Hi, der HT3_logger läuft nicht. Den hatte ich testweise nur mal gestartet. Der Heizungsregler ist auch schon Jahre drinnen. Vielleicht mach ich den einfach mal aus... :-) Das probiere ich mal stumpf. Viele Grüße, Nils
Hi, hab mal so viel wie möglich an Services abgeschaltet und konnte ein interessantes Verhalten feststellen. Wenn ich den ht_proxy neustarte wird das erste Kommando mit ht_netclient korrekt übertragen. Alle weiteren scheitern. Wenn ich also vor jeder Modusänderung den ht_proxy neustarte funktioniert es. Kannst du damit was anfangen? M.E. sollte es damit nicht direkt an der Konfiguration oder Verkabelung liegen, oder? Viele Grüße, Nils
Hallo Nils, Nils schrieb: > M.E. sollte es > damit nicht direkt an der Konfiguration oder Verkabelung liegen, oder? An der Hardware (Verkabelung, Rapsi, ht_Adapter) hast Du ja nichts geändert nehme ich mal an und somit wird wohl eine andere Ursache vorliegen. > Wenn ich den ht_proxy neustarte wird das erste Kommando mit ht_netclient > korrekt übertragen. Alle weiteren scheitern. Kontrolliere bitte die LED's auf dem ht_pitiny-Adapter. Wenn die rote-LED nach dem Senden ständig/konstant leuchtet liegt ein Fehler vor. Siehe dazu auch die Beschreibung unter: Beitrag "Re: Heatronic 3 Adapter (Junkers Heizung) fuer Raspberry Pi" Ich glaube Du hast noch ein MBlan2 parallel am Bus. Klemm das mal bitte testehalber ab und prüf dann die Sendefunktion mit dem ht-Adapter. Welche HW/SW verwendest Du?: 1. Raspi A/B/B3 mit Linux 'stretch'? 2. Junkers Regler Fxyz und Fertigungsdatum (wird sich wohl nicht geändert haben) 3. MBLan2 parallel am Heizungsbus und verbunden mit Cloud? 4. ht-Adapter muss auf andere Adresse als MBLan eingestellt sein (ist aber ja wohl schon so, siehe oben) Hast Du das Software-Release 0.3.1 komplett neu installiert und die Datenbanken neu erzeugt? Gruß Norbert
:
Bearbeitet durch User
Welche HW/SW verwendest Du?: 1. Raspi A/B/B3 mit Linux 'stretch'? Ja, Raspi B 2. Junkers Regler Fxyz und Fertigungsdatum (wird sich wohl nicht geändert haben) FW200 - ist gleich 3. MBLan2 parallel am Heizungsbus und verbunden mit Cloud? Ja, geht aber auch nicht ohne 4. ht-Adapter muss auf andere Adresse als MBLan eingestellt sein (ist aber ja wohl schon so, siehe oben) - Ja, ist er Hast Du das Software-Release 0.3.1 komplett neu installiert und die Datenbanken neu erzeugt? Ja Kontrolliere bitte die LED's auf dem ht_pitiny-Adapter. Wenn die rote-LED nach dem Senden ständig/konstant leuchtet liegt ein Fehler vor. Leuchtet nicht konstant...hab aber gerade am Kabel rumgebastelt, um den Bus zu verkürzen, da ist sie auf rot gegangen und der FW200 hat gemeckert. Aktueller Stand: Ich musste ein Backup einspielen, weil die SD Karte irgendwie aufgegeben hat und nun funktioniert auch die Aufzeichnung nicht mehr. :-(
:
Bearbeitet durch User
Hallo Zusammen, ich möchte um Eure Hilfe bitten. (Sorry, mein Deutsch ist nicht so schön :() Ich versuche meine Bosch EMS2 system zu loggebn. Zuerst möchte ich an Norber S. für die riesige Arbeit eine große Danke sagen! Ich Möchte HT3 logger nur für meine Heizungsoptimalization verwenden. Ich brauche keine Sendefunktion, keine Datenbank, keine IP Netzwerk, usw. Requirement: Botschaft-> Temperaturwerten (soll, ist), Pumpenstatus, Gasverbrauch zu konvertieren. Um es einfacher zu machen, ich probierte die KomplettSW-Umgebung zu verwenden. Mein Problem ist: ich besitze kein Raspberry Pi, und ich möchte auch mich nicht in Linux Einarbeiten. (mein Schuld) Ich möchte aber das ganze Zeug irgendwie unten Windows in betrieb nehmen. Positiv: HW habe ich gebaut, mit USB-COM schnittstelle ich bekomme mit Terminal SW die EMS Daten richtig. Von SWher: ich habe Perl Python, SQlite installiert, und hoffentlich auch RRDtool richtig installiert. Bei create_dtebase.py ich kann RRD Datebase nicht erzeugen lassen. Es wird kein perl script erzeugt. (str: \\tmp\\rrdtool_dbcreate.pl) sonst kommt Exception, db_rrdtool.createdb_rrdtool();Error;<2> Warum kann es potentiell so sein? Ich möchte mal fragen: kann ich irgendwie eine Übersetzungstabelle in dem Projekt finden, womit ich einfach Serielldaten direkt nach Physikalische Werten umrechnen kann? Es wäre für mich ganz genug, und einfach in Excel csv zu schreiben. (wie DBC für CAN oder LDF für LIN bus in Automotiv) Mein Hintergrund: ich arbeite in Automotivbereich als SW Expert, mit mehr als 20 Jahren Embedded SW, HW Erfahrung (C, C++). Ich habe aber kein Erfahrung (noch :)) mit Python, und auch kein mit dem Linux. Also Danke im Voraus! Gruß, Tamas
Hallo Tamas, Tamas B. schrieb: > Bei create_dtebase.py ich kann RRD Datebase nicht erzeugen lassen. Es > wird kein perl script erzeugt. (str: \\tmp\\rrdtool_dbcreate.pl) sonst > kommt Exception, db_rrdtool.createdb_rrdtool();Error;<2> > Warum kann es potentiell so sein? Der Fehler:Error;<2> bedeutet: ERROR_FILE_NOT_FOUND -> The system cannot find the file specified. Dies deutet auf falsche Pfade zum Filesystem hin, leidige Thema: '\' und ’/'. Das aktuelle SW-Release ist noch NICHT für Windows angepasst. Vorhandene Software für Windows / Linux (python) unter: Beitrag "Re: Heatronic 3 Adapter und Analysesoftware" Dies ist allerdings eine ältere Version mit einer GUI-Ausgabe. Software für Windows und Junkers-Heizung gibt es auch unter: www.fhem.de und der zugehörige Beitrag unter: https://forum.fhem.de/index.php/topic,19445.msg883929.html?PHPSESSID=4kitu415rj51blpplt28emsfq2#msg883929 Tamas B. schrieb: > Ich versuche meine Bosch EMS2 system zu loggebn. Die hier vorhandene Software arbeitet mit 'Junkers Heatronic/EMS2(c)' Telegrammen und passt nicht zu Buderus (Bosch) EMS2. Es ist beides mal zwar EMS2, aber die Telegramme zwischen Junkers- und Buderus-Heizungen sind unterschiedlich. Damit die Verwirrung noch optimaler wird, heissen ab 2017 die ehemals Junkers Cxyz-Regler auch Bosch Cxyz-Regler. Bitte kläre also welche Heizung von welchem Hersteller Du betreibst. Die Telegramme und die Auswertung hängen davon ab. Tamas B. schrieb: > Positiv: HW habe ich gebaut, mit USB-COM schnittstelle ich bekomme mit > Terminal SW die EMS Daten richtig. Du kannst ja diese empfangenen Daten binär in ein File schreiben und hier posten. Das kann ich dann auswerten. Gruß Norbert
:
Bearbeitet durch User
Hallo, vielen Dank zunächst einmal an diesem tollen Projekt. Ich habe es Dank der guten Dokumentation hingekriegt das alles mit dem Raspberry pi3 b+ und dem selbstgebauten Miniadapter ans Laufen zu kriegen, obwohl ich kaum Linux und Programmierkenntnisse habe. Was mir jetzt noch fehlt, ist die Anzeige für meinen wassergeführten Kaminofen, also die Kesseltemperatur und Pumpe ein bzw aus. Mein Heizungssystem: Junkers mit FW200, ISM2 UND IPM1. Auf der FW200 wird die Kesseltemperatur des Kaminofens unter Solar - 2. Kollektorfeld angezeigt. Meine Frage ist nun, wie ich das am besten machen könnte? Habe gedacht, ob ich vielleicht die bei mir ungenutzte Anzeige für den 2. Herzkreislauf nehmen könnte? Also quasi nur etwas modifizieren und es zeigt bei mir da den Kaminofen an. Währe nett, wenn mir da jemand Tipps geben könnte. Ich habe da etwas Angst alles kaputt zu machen, so dass nichts mehr läuft. Liebe Grüße Daniel
Hallo Daniel, leinado schrieb: > Was mir jetzt noch fehlt, ist die Anzeige für meinen wassergeführten > Kaminofen,... > Habe gedacht, ob ich vielleicht die bei mir ungenutzte Anzeige für den > 2. Herzkreislauf nehmen könnte? Dies würde ich nicht empfehlen, da die Heizkreise ja Wärme-Senken sind und der Kessel ja eine Wärme-Quelle. Daher wird ja an Deinem Regler dieser auch unter Solar angezeigt (was auch immer sich Junkers dabei gedacht hat). Daher mein Vorschlag dies ebenfalls als zweite bzw. n'te Wärmequelle unter Solar anzeigen lassen, zumal es dort noch freie 'Spare' Logitems gibt. Die Anzeige ist also kein Problem. Bleibt noch die Dekodierung der richtigen Daten aus dem richtigen Telegramm(en). Es wird wahrscheinlich ein Telegramm vom ISM2 Modul sein (B0 00 FF 00 ...). Dies kannst Du dir im HT3_Analyser ansehen oder besser wäre es wenn Du ein Binärfile von den Telegrammen erstellst (<= 1 Std. mit Angaben der Kesseltemperatur/Zeitpunkt). Binär-Logfile erstellen mit z.B.: cd ~/HT3/sw ./ht_binlogclient.py <meinlogfile.log> Kannst Du an meine PM senden oder hier posten. Gruß Norbert
Hallo Norbert, vielen Dank für deine Hilfe! Ich habe gerade mal ein Logfile erstellt. Ich hoffe ich habe das richtig gemacht, sonst mache ich das gerne nochmal. Logfile habe ich als Datei angehängt. Zeitstempel: Zeit Temperatur Pumpe 0:00 72,7 an 0:01 72,6 an 0:03 72,4 an 0:05 72,2 an 0:06 72,1 an 0:06 72,4 an 0:09 72,5 an 0:10 72,6 an 0:12 72,6 aus 0:13 74,6 aus 0:13 74,8 aus 0:13 75,9 an 0:14 76,8 an 0:14 77,7 an 0:14 78,8 an 0:15 79,7 an 0:15 79,3 an 0:15 78,2 an 0:16 77,0 an 0:16 75,9 an 0:16 74,9 aus Ich hoffe 16 Minuten sind ausreichend, sonst mache ich das gerne länger. Damit die Pumpe für den Kreislauf zwischendurch auch mal ausgeht, habe ich den Temperatursensor vom Pufferspeicher unten mal kurz oben am Speicher reingesteckt. Vielleicht kannst du so auch die Pumpe finden. Gruß Daniel
Hallo Daniel, leinado schrieb: > Ich hoffe 16 Minuten sind ausreichend, sonst mache ich das gerne länger. Das reicht völlig, danke für das Logfile und die gute Beschreibung der Werte :-) Hinweis: Die Systemzeit der Heizung ist um ca. 14Minuten anders als Deine Angaben. Die Auswertung beeinflusst dies aber nicht. Habe die Anpassungen in die Dekodierung eingebracht und auch die rrdtool-Grafik Anzeige erweitert. Es wird jetzt ein weiterer Graph für '2.Waermequelle' angezeigt wenn die zugehörigen Telegramme und Werte von der Heizung gesendet werden. Die Software ist noch nicht ganz rund, werde diese aber zeitnah auf github als neues Release veröffentlichen. Will damit weitere Test-Releases mit verschiedenen Zwischenständen hier im Forum vermeiden. Wenn das Release soweit fertig ist kannst Du es ja auf Deine spezielle coole (heisse) Heizung hetzen :-) Gruß Norbert
Hallo Norbert, vielen vielen Dank. :-) Da bin ich schon sehr gespannt. Gruß Daniel
Hallo @all, eine neues Release (0.3.1) ist auf github vorhanden. Dies am besten als komplettes Paket laden mit: git clone https://github.com/norberts1/hometop_HT3.git Es sind im Wesentlichen weitere Dekodierungen für die Cxyz-Regler hinzugekommen und zusätzliche Anzeigen für die Temperatur an der Hydraulischen Weiche (falls vorhanden) und eine zusätzliche grafische Ausgabe für Werte der Solaranlage (2.Kollektor-Anlage). Diese Anzeigen sind so weit als möglich dynamisch gehalten und wer diese Systemanteile nicht hat wird diese Anzeigen auch nicht erhalten bzw. sind diese Werte auf 0 gesetzt. Vorhandene Datenbanken aus dem Release 0.3 können weiterhin verwendet und müssen nicht neu erzeugt werden. leinado schrieb: > Da bin ich schon sehr gespannt. Gruß Daniel Bitte teste dieses Release an Deiner Anlage, die Werte für Deinen wassergeführten Kaminofen (Temperatur und Pumpe) sollten in der Zusatzgrafik (2.Waermequelle) angezeigt werden. Gruß Norbert
:
Bearbeitet durch User
Hallo Norbert, vielen Dank für deine Mühe. Es funktioniert leider bei mir noch nicht so richtig. Wahrscheinlich habe ich irgendwo einen Fehler gemacht. Deswegen erkläre ich mal Schritt für Schritt was ich gemacht habe. 1. Ich habe das komplette Paket geladen. Der Ordner hometop_HT3 lag dann in /home/pi 2. Ich habe den Order /home/pi/hometop_HT3/HT3 kopiert und in /home/pi/HT3 eingefügt und dabei alle Dateien überschrieben. 3. ich habe HT3_Analyser.py aus /home/pi/HT3/sw gestartet und mich riesig über das Ergebnins gefreut. Jetzt wurde 2. T-Kollektor und 2. Pumpe angezeigt. 4. die *.png in /home/pi/HT3/sw/etc/html wurden regelmäßig aktualisiert und Heizkreis 1 zeigte nun zusätslich die Mischertemperatur an :-) Leider fehlte noch das png für den 2. Kollektor bis hierhin also alles fast gut 5. Nach einem Reboot kamen bei dem HT3_Analyser.py nun leider aber keine Daten mehr rein. Und auch die *.png wurden nicht mehr aktualisiert. mit sudo minicom -b 9600 -o -D /dev/ttyAMA0 konnte ich aber sehen, dass weiterhin Daten rein kamen. 6. Ich habe dann alle Dateien aus einer Sicherungskopie wieder in /home/pi/HT3 geschrieben und nach einem Reboot funktionierte wieder alles auf Anhieb wie vorher. 7.Habe alle oben genannten Punkte 3 mal wiederholt mit identischem Ergebnis. Jetzt habe ich gerade beim Schreiben dieses Textes gemerkt, dass ich ja noch die Baudrate in der ht_proxy_cfg.xml anpassen muss. Und endlich jetzt funktioniert der HT3_Analyser.py auch nach einem Reboot in der neuen Version und zeigt 2. T-Kollektor und 2. Pumpe :-) Auch die *.png werden nun fleißig aktualisiert. Es fehlt leider noch das HT3_Solar_second.png Aber da habe ich wahrscheinlich auch noch irgendwo einen Fehler gemacht. Mir ist aufgefallen, dass es manchmal ca 5 Minuten dauert, bis 2. T-Kollektor und 2. Pumpe in dem HT3_Analyser.py angezeigt werden. Alle anderen Werte kommen viel eher. Liebe Grüße Daniel
Hallo Daniel, leinado schrieb: > Es fehlt leider noch das HT3_Solar_second.png Um dem auf die Spur zu kommen aktiviere mal die Debugausgaben im Konfigfile: HT3_db_cfg.xml und starte den ht_collgate.py neu. <loglevel>DEBUG</loglevel> Nach > 5 Minuten solltest Du eine Debugausgabe für den rrdtool.draw sehen etwa so: DEBUG: cdb_rrdtool.create_draw(); path2db :/home/pi/HT3/sw/var/databases; path2draw:/home/pi/HT3/sw; hc_count:2; Contr.type:2; mixer_flags:[1, 1, 1, 0]; hydrlic_sw:0; solar_flag:1; second_source:1 DEBUG: /home/pi/HT3/sw/etc/rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 0 1 1 Wichtig sind ja dabei für Dich die Flags: 'solar_flag:1' und 'second_sorce:1'. Beide müssen auf 1 sein, damit HT3_Solar_second.png geschrieben wird. Du kannst dieses Perl-Sript auch direkt mit den nötigen Parametern manuell aufrufen. Wichtig sind die richtigen Pfade und das die Anzahl und die Werte der Parameter korrekt sind (siehe oben). Also z.B.: cd ~/HT3/sw/etc ./rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 0 1 1 Je nach vorhandenem Controller-Type musst Du da dann halt eingeben: 1 := Fxyz Controller 2 := Cxyz Controller > Mir ist aufgefallen, dass es manchmal ca 5 Minuten dauert, bis 2. > T-Kollektor und 2. Pumpe in dem HT3_Analyser.py angezeigt werden. Alle > anderen Werte kommen viel eher. Ja, einige der Telegramme kommen seltener. Ganz extrem ist z.B.: der Solarertrag (Tag/Summe bei Cxyz-Controllern). Der kommt wirklich nur einmal die Stunde. Gruß Norbert
:
Bearbeitet durch User
Norbert schrieb:
>Nach > 5 Minuten solltest Du eine Debugausgabe für den rrdtool.draw sehen
Wo genau sehe ich die Debugausgabe? Unter /home/pi/HT3/sw/var/log
vielleicht? Da habe ich aber nirgendwo etwas entsprechendes gefunden.
Ich habe es heute nochmal versucht aber das mit der Debugausgabe funktioniert bei mir nicht. In der HT3_db_cfg.xml habe ich das logging auf DEBUG gestellt und den Raspberry neu gestartet, damit der ht_collgate.py neu gestartet wird. In der HT3_db_cfg.xml steht ja drin, dass das Logfile in ./var/log/ht_default.log geschrieben werden soll. Da gibt es bei mir dieses Logfile aber nicht. Was aber bei mir funktioniert : cd ~/HT3/sw/etc ./rrdtool_draw.pl /home/pi /home/pi 2 2 1 1 1 0 0 1 1 Bei mir (111110011) Da wird dann ein HT3_Solar_second.png erstellt. ?? Müsste jetzt nur noch automatisch aktualisiert werden, so wie die anderen *.png Liebe Grüße Daniel
Ich habe es jetzt bei mir erstmal so gemacht, dass ich das rrdtool_draw.pl umgeändert habe: # solar ertrag draw solar_yield_draw($mypath, $mytargetpath, $controller_type); if ($second_collector == 0) { solar_draw_second_field($mypath, $mytargetpath, $controller_type); } vorher: if ($second_collector > 0) ist zwar nicht so ganz Sinn der Sache aber bei mir funktioniert es erstmal so :-) Liebe Grüsse Daniel
Moin allerseits, 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? Gruß Henrik
Moin Leute, 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?? Laut deren Homepage bzw. den Datenblätter der Produkte ist dies deren Fokus, die Netzwerkkommunikation zu realisieren. Was meint Ihr? MfG Rob
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.