Hallo und ich danke dir sehr für die Anleitung. Peter* schrieb: > oh Mann..., hoffe Du hast ein Lötkolben oder kennst ein mit Lötkolben. Selbstverständlich bin ich nicht ganz unbeleckt, was Elektronikbastelleien und Löten angeht, aber mit Arduino, bzw. dessen Derivate habe ich mich bisher noch nicht auseinandergesetzt. Peter* schrieb: > Level_Jumper mit SMD_Brücke von 5 V auf 3V3 um löten. Es ist etwas > Feinmotorig gefragt. Kein Problem, ich hoffe nur, dass ich die besagte Brücke erkenne, wenn das Board vor mir liegt. ;-) Peter* schrieb: > Halbdefektes Lan-Kabel defekten Stecker abschneiden und... > Kabelbelegung(GND nicht vergessen)) findest Du bei Watterott. Nicht nötig, ich crimpe einfach einen RJ45 Stecker auf die vorhandene Busleitung. ;-) Peter* schrieb: > Achtung!! Pin11...13 sind abhängig von der Wahl der Schnittstelle in der > SW SW heißt vermutlich Software... Wobei wir beim Thema wären: Wie geht es dann mit der SW weiter? Gibt es irgendwo ein Tutorial? Welche SW benötige ich? Bitte bedenke, dass ich vorrangig das Ding zum Laufen bekommen möchte und keinen Grundlagenkurs im Umgang mit Arduinos brauche. Das ist etwas womit ich mich vielleicht im Nachgang beschäftige. Peter* schrieb: > Natürlich alles ohne Gewähr!! Eigenverantwortung usw. Ist klar, dennoch bin ich bester Hoffnung, dass deine Anleitung korrekt ist. LG, Bernd
Hallo, Link https://github.com/watterott/CANdiy-Shield/blob/master/hardware/CANdiy-Shield_v21.pdf dort findest Du auch Logic_Level_JP. Bild etwas unscharf. SW [nur CAN-Bus Kommunikation] findest Du dort auch. ACAN2515 und MCP_Can ist das was an einfachsten funktioniert. Dave's Programm findest Du hier unter Github. Netzteilspannung sollte nicht höher als 9V sein. GND ist wichtig!! nicht vergessen auch bei CAN-Bus. Lesen vorletztes und letztes Jahr wichtig!!! Habe gesehen inzwischen gibt es die V2.1 Version, hoffe Du hast die bestellt. Hinweis: !!BM1!! und BM2! sind sehr teuer, unverschämt teuer.
Peter* schrieb: > Lesen vorletztes und letztes Jahr wichtig!!! > Irgendwas spezielles was du meinst? Lese eigentlich immer mit. > Habe gesehen inzwischen gibt es die V2.1 Version, hoffe Du hast die > bestellt. Bestellt v2, bekommen v2.1 Wo ist der Unterschied? Was muss ich beachten? > Hinweis: !!BM1!! und BM2! sind sehr teuer, unverschämt teuer. Ist klar. Verstehe den Hinweis nicht. Gruß, Bernd
Hallo, mit lesen ist immer gut.... das wurde schon mal behandelt. Ich meine der Treiber [FD] vom CAN-Bus wurde gewechselt, hat aber keine Auswirkung direkt bei 10k. Nun..., für 15 Jahre alte Hardware Unsummen zu bezahlen ist ein Unding. ...Du hast mitgelesen.... dann ist Dir das Problem doch bekannt. Fast jeder hat hier schon Probleme gehabt und durch eigene Fehler oder ???? die BM1 gewechselt. Einmal Überspannung , Masseversatz..... Noch ein kleiner Hinweis zur Verkabelung (bzw. der Software) die SPI_Pin Nr. sind nicht die Pin's des ESP_Platine bzw. zur Software. static const byte MCP2515_SCK = 18 ; // SCK input of MCP2515 static const byte MCP2515_MOSI = 23 ; // SDI input of MCP2515 static const byte MCP2515_MISO = 19 ; // SDO output of MCP2515 static const byte MCP2515_CS = 5 ; // CS Wie mitgeteilt zum erwähnten Aufbau.
Peter* schrieb: > Noch ein kleiner Hinweis zur Verkabelung (bzw. der Software) die SPI_Pin > Nr. sind nicht die Pin's des ESP_Platine bzw. zur Software. > > static const byte MCP2515_SCK = 18 ; // SCK input of MCP2515 > > static const byte MCP2515_MOSI = 23 ; // SDI input of MCP2515 > > static const byte MCP2515_MISO = 19 ; // SDO output of MCP2515 > > static const byte MCP2515_CS = 5 ; // CS Sondern? Sorry, aber das klingt wie chinesisch für mich.
Hallo, hast Du schon mal mit einem Arduino oder einem ESP32 herumgespielt?? Wenn nicht, dann solltest Du schnellstens damit anfangen ohne diese Kenntnisse wirst Du hiermit scheitern .... wie hast Du mit MQTT gearbeitet. Wichtig für die SW: Das ist ein Auszug aus der Definition vom ESP32 mit der SW ACAN2515. Die Deklaration der SPI Schnittstelle zur Hardware. Pin 18,23,19,5 wird bei diesem Aufbau benutzt. Vielleicht meldet sich noch ein SW Spez. zur Hilfe.
Peter* schrieb: > hast Du schon mal mit einem Arduino oder einem ESP32 herumgespielt?? Nein > Wenn nicht, dann solltest Du schnellstens damit anfangen ohne diese Kenntnisse wirst Du hiermit scheitern Wie gesagt, ich will das Ding jetzt primär erst einmal zum Laufen bringen und mich im Anschluss damit auseinandersetzen. Da es hier, dich eingeschlossen, Leute gibt, die das erfolgreich zum Laufen gebracht haben, war und bin ich der Hoffnung, dass ich ordentlich angeleitet werde, ohne dabei meine Heizung zu schrotten. > .... wie hast Du mit MQTT gearbeitet. Ich habe, wie bereits hier im Thread mehrfach erwähnt, einen kleinen Linux-Rechner und lasse dort can2mqtt (https://github.com/c3re/can2mqtt) laufen. Auf meinem HomeAssistant (PI4) läuft dann der MQTT-Broker > Vielleicht meldet sich noch ein SW Spez. zur Hilfe. Ich habe auch bereits Dave um Hilfe gebeten, der hat aber offensichtlich viel zu tun.
Hallo, sorry, sehe das bitte als konstruktive Kritik. aber die Definition von Hilfestellung sieht in meinen Augen etwas anders aus, man muss es selber wollen und tun und nicht einfach einen Auftrag vergeben. > ... dass "ich ordentlich angeleitet" werde, ohne dabei meine Heizung zu > schrotten..... abgesehen von der Aussage des Satzes besteht die Gefahr immer. Nun..., "Du" machst scheinbar keine Fehler mit Null_Wissen ! wenn Du nur ordentlich angeleitet wirst? Wissen vor lernen, wie geht das. Zum Lernen braucht man Zeit und die Zeit willst Du "Dir" erstmal gar nicht geben, sondern andere [wie gesagt Eigenverantwortung] sollen Dich blind leiten!! und diese Zeit für Dich investieren "." Löte die Can-Bus_Platine zusammen und mach Dich mit der Arduino IDE vertraut.
Peter* schrieb: > sorry, sehe das bitte als konstruktive Kritik. damit kann ich umgehen. ;-) > aber die Definition von Hilfestellung sieht in meinen Augen etwas anders > aus, man muss es selber wollen und tun und nicht einfach einen Auftrag > vergeben. offensichtlich hast du mich falsch verstanden. Ich werde hier keine Fragen stellen, wie ich die Platine zusammen löten muss oder das Ding flashen muss. Das werde ich mir schon anlesen. Wahrscheinlich werden sich mir dabei die einen oder anderen kryptischen Hinweise von dir erschließen. Ich erwarte lediglich Hilfestellung dahingehend, dass ich hier poste wie weit ich bin und dann frage, was ich als nächstes tun muss, um das Ding erfolgreich in Betrieb zu nehmen ohne dabei meine Heizung zu schrotten. Ich sehe nämlich keinen Sinn darin, Fehler, die bereits schon einmal von sonstwem gemacht wurden, noch einmal zu machen, nur damit ich es "selbst getan" habe. Das ist in meinen Augen Schwachsinn. > > Nun..., "Du" machst scheinbar keine Fehler mit Null_Wissen ! wenn Du nur > ordentlich angeleitet wirst? > > Wissen vor lernen, wie geht das. Nun, es gibt Wissen und Wissen. Ich brauche Wissen von denen, die genau das, was ich vorhabe und nicht weiß wie es geht, schon erfolgreich hin bekommmen haben. Was ist daran verwerflich und falsch? > Zum Lernen braucht man Zeit und die Zeit willst Du "Dir" erstmal gar > nicht geben, sondern andere [wie gesagt Eigenverantwortung] sollen Dich > blind leiten!! Es leuchtet mir eben einfach nicht ein, warum ich Zeit für "Experimente" mit einem Arduino inverstieren soll, wenn ich doch genau weiß, was es am Ende tun soll und ich weiß, das genau dieses Wissen hier im Forum abzuschöpfen ist. Zumal ich erst durch den Hinweis hier im Forum auf die Möglichkeit, das mit einem Arduino zu machen, hingewiesen wurde. > Löte die Can-Bus_Platine zusammen und mach Dich mit der Arduino IDE > vertraut. Das werde ich tun. Heute sind alle Teile mit der Post gekommen. ...und verstehe mich bitte nicht falsch: Ich bin bereits sehr dankbar dafür, dass du dich überhaupt so weit mit mir befasst hast und ich habe die Hoffnung, dass du die Lust an mir nicht verlierst. Ich verspreche auch ein gelehriger "Schüler" zu sein und keine Fragen zu stellen, die ich mir nicht auch durch etwas lesen selbst erarbeiten kann. ...aber gerade in der Hinsicht, dass die Junkers-Busmodule sehr fragil und teuer sind, wünsche ich mir absolute Sicherheit, bevor ich das Teil dann endgültig in Betrieb nehme. In diesem Sinne melde ich mich wieder, wenn ich alles zusammengelötet, den Jumper auf 3,3V umgelötet, die Verkabelung nach deinen Bildern vorgenommen und Daves Software auf den Arduino geflasht habe. Liebe Grüße, Bernd
Hallo, der Punkt wurde von mir gesetzt und damit ist die Sache erledigt. Soweit mir bekannt ist hat Dave ACAN2515 benutzt und hier würde ich raten nach der Fertigstellung einen Kommunikationstest auf unterster Ebene zu starten. Ob Daten empfangen oder gesendet werden können. Da gibt es Programme unter Github ACAN2515 und die Funktion vor dem Anschluss an deiner Heizung sicherstellen. Bei Dave's Programm bin ich leider bin nicht die Hilfe.
So, Platine ist zusammengelötet und gemäß deinen Anweisungen gejumpert und verdrahtet. Ich habe ein wenig mit Arduino IDE herumgespielt, habe aber das Problem, dass ich mit den mitgelieferten Beispielen keinerlei Ausgaben bekomme. Das Blinken der LED ging noch, aber beispielsweise der "WiFi-Scan" gibt nichts aus. @Dave: Ich werde leider aus deiner Software nicht ganz schlau. Muss ich da jetzt tatsächlich noch in PlatformIO einarbeiten? @Peter: Du sprachst den Masseversatz an, den ich (man) vermeiden soll. Wie gehe ich da bei der Verkabelung am besten vor? Laut Wetterott liegt an der RJ45-Buchse des CANdiy-Shield an Pin 3 und 7 jeweils Masse an. Was kommt an Pin 8 (V+) Muss ich beide benutzen? Reicht einer? Gruß, Bernd
Hallo, muss mich zeitlich bedingt etwas kurz halten. Zum Bild: Du musst die JP 1-3 einlöten die brauchst Du! Wenn Du Dir den Schaltplan in Pdf anschaust, siehst Du warum. Du kannst bzw. musst den GND Jumpern (JP3, Pin3,7)) bestücken und wenn Du zufällig Vin (JP2, Pin8), ungefähr 9V Gleichstrom außerhalb hast, kannst Du die auch freigeben. Mach es nicht, nicht notwendig. Versorgung besser über Stecker oder USB. JP1 ist der Abschlusswiderstand vielleicht ist der nötig für Test's oder anderen Geräten außerhalb deiner Heizung. Hast das Board "ESP32 DEV Module" eingestellt, richtige Port (COM)? Welche Datei hast Du geladen.
Peter* schrieb: > hast du inzwischen Erfolg gehabt? Konnte die Änderungen an der Platine noch nicht vornehmen. Bin gerade beruflich etwas eingespannt. Melde mich, wenn ich so weit bin. Gruß, Bernd
Peter* schrieb: > Hast das Board "ESP32 DEV Module" eingestellt, richtige Port (COM)? Ich habe sowohl "ESP32 Dev Module", als auch "ESP32vn IoT Uno" (letzteres wird in der Anleitung von az-delivery.de verwendet) --> https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/d1-r32 Der Port stimmt, das Hochladen zum Board funktioniert einwandfrei und ohne Fehler. Im Seriellen Monitor bekam ich zuerst nur kryptische Zeichen als Ausgabe. Erst als ich an der Übertragungsrate herumgespielt und diese auf 115200 baud eingestellt habe, bekam ich dann auch Klartext. > Welche Datei hast Du geladen. Was meinst du genau mit "Datei"? Gruß, Bernd
:
Bearbeitet durch User
Bernd R. schrieb: > @Dave: > Ich werde leider aus deiner Software nicht ganz schlau. > Muss ich da jetzt tatsächlich noch in PlatformIO einarbeiten? Eigentlich sollte das zwischenzeitlich auch ohne die PlatformIO gehen, indem man die beiden bin mit dem esptoolkit hochlädt wie unter https://github.com/Neuroquila-n8fall/JunkersControl#installation-quick-start beschrieben. Dann muss/kann man eben die Konfigurationsdaten (als JSON encodiert) über das web-Interface hochladen und vorher woanders editieren. Wenn noch ein anderer "Controller" (TA2xx) im Spiel ist, lauscht der ESP prinzipiell nur mit.
Hallo, unter Datei meinte ich eigentlich, welches Textprogramm (ACAN2515) Du benutzt. Ja..., die Baudprobleme hatte ich mir schon gedacht. Funktioniert jetzt das scannen? Bei den Board_Einstellungen schreibt jeder etwas anders, es müssen aber auch alle Port's funktionieren und ich meine ESP32vn IoT Uno ist dies nicht der Fall. Auf dem CAN-Bus Board sind zwei LED's, ich benutze die als Sende- bzw. Empfangs_Led die unabhängig vom Can-Controller arbeiten, leider, da funktionierten sie nicht. Auszug Programm: uint8_t Tx = 12; // Sende_LED_D03 uint8_t Rx = 14; // Empfangs_LED_D02 unter Setup: pinMode(Tx, OUTPUT); digitalWrite(Tx, HIGH); // Ausgang; Tx_Led out, pinMode(Rx, OUTPUT); digitalWrite(Rx, HIGH); // Ausgang; Rx_Led out, Hast Du schon den Can-Bus bzw. Platine getestet? Du schriebst Du hast noch einen USB Canbus zur Verfügung. Vielleicht nutzt Du diesen zum testen mit der Karte. Einer sendet der andere empfängt. Als Start der Testreihe, würde ich anfangen mit \LoopBackDemoESP32\LoopBackDemoESP32.ino. Dafür musst ACAN2515 "installieren". Das ein Test mit sich Selbst, ACAN2515 zeigt schon an ob grob, alles ok ist. Danach könntest Du auf "Normalmode" gehen und empfangen. Dafür gibt es allerdings kein Demo. Sicher kriegen wir das auch hin. Das sind Tests, die würde ich vor Dave's Programm absolvieren!!
Peter* schrieb: > Hallo, > > unter Datei meinte ich eigentlich, welches Textprogramm (ACAN2515) Du > benutzt. Ja..., die Baudprobleme hatte ich mir schon gedacht. > > Funktioniert jetzt das scannen? Mit der angepassten Baudrate funktioniert es. > Bei den Board_Einstellungen schreibt jeder etwas anders, es müssen aber > auch alle Port's funktionieren und ich meine ESP32vn IoT Uno ist dies > nicht der Fall. Okay, das kann ich (noch) nicht beurteilen. Du hast sicher Recht. > Auf dem CAN-Bus Board sind zwei LED's, ich benutze die als Sende- bzw. > Empfangs_Led die unabhängig vom Can-Controller arbeiten, leider, da > funktionierten sie nicht. > > Auszug Programm: > > uint8_t Tx = 12; // Sende_LED_D03 > uint8_t Rx = 14; // Empfangs_LED_D02 > > unter Setup: > > pinMode(Tx, OUTPUT); digitalWrite(Tx, HIGH); // Ausgang; Tx_Led out, > pinMode(Rx, OUTPUT); digitalWrite(Rx, HIGH); // Ausgang; Rx_Led out, > Das sagt mir leider noch gar nichts. .-( > Hast Du schon den Can-Bus bzw. Platine getestet? Nein, weil ich nicht weiß wie. Ich hatte gedacht, dass ich einfach das Teil an den vorhandenen BUS hänge und schaue was passiert. Mut zur Lücke. ;-) Kann ich eigentlich unendlich viele Geräte an den BUS hängen? > Du schriebst Du hast noch einen USB Canbus zur Verfügung. Vielleicht > nutzt Du diesen zum testen mit der Karte. Einer sendet der andere > empfängt. Verbinde ich die einfach miteinander und tue dann was? > Als Start der Testreihe, würde ich anfangen mit > \LoopBackDemoESP32\LoopBackDemoESP32.ino. Dafür musst ACAN2515 > "installieren". > Das ein Test mit sich Selbst, ACAN2515 zeigt schon an ob grob, alles ok > ist. ACAN2512 habe ich in Version 2.1.1 installiert Die Installation der Demo scheitert leider daran, dass ich eine Fehlermeldung bekomme: `error: 'LED_BUILTIN' was not declared in this scope` > Danach könntest Du auf "Normalmode" gehen und empfangen. Dafür gibt es > allerdings kein Demo. Sicher kriegen wir das auch hin. ich bin guter Dinge > Das sind Tests, die würde ich vor Dave's Programm absolvieren!! Bin dabei! (y)
:
Bearbeitet durch User
Peter* schrieb: > Noch ein kleiner Hinweis zur Verkabelung (bzw. der Software) die SPI_Pin > Nr. sind nicht die Pin's des ESP_Platine bzw. zur Software. > > static const byte MCP2515_SCK = 18 ; // SCK input of MCP2515 > static const byte MCP2515_MOSI = 23 ; // SDI input of MCP2515 > static const byte MCP2515_MISO = 19 ; // SDO output of MCP2515 > static const byte MCP2515_CS = 5 ; // CS > > Wie mitgeteilt zum erwähnten Aufbau. Ich nehme an, dass wir jetzt an diesem Punkt angekommen sind. Die vier Zeilen habe ich im LoopBackDemoESP32.ino (Zeilen 30-34) angepasst. Was ist aber mit diesen hier? static const byte MCP2515_INT = 23 ; // INT output of MCP2515 (adapt to your design) static const byte MCP2515_RESET = 27 ; // RESET input of MCP2515 (adapt to your design) 23 ist doch offensichtlich MOSI und nicht gleichzeitig INT. INT ist am MCP2515 an 13 RESET an 19 ...oder sehe ich da irgendetwas falsch? Ich bin verwirrt
Hallo, > Ich hatte gedacht, dass ich einfach das Teil an den vorhandenen BUS > hänge und schaue was passiert. > Mut zur Lücke. ;-) Neee..., Lücke zahlt sich nicht aus. >> pinMode(Tx, OUTPUT); digitalWrite(Tx, HIGH); // Ausgang; Tx_Led out, >> pinMode(Rx, OUTPUT); digitalWrite(Rx, HIGH); // Ausgang; Rx_Led out, > Das sagt mir leider noch gar nichts. .-( Das sind Feinheiten brauchen wir momentan noch nicht. >> Du schriebst Du hast noch einen USB Canbus zur Verfügung. Vielleicht >> nutzt Du diesen zum testen mit der Karte. Einer sendet der andere >> empfängt. > Verbinde ich die einfach miteinander und tue dann was? Nein. > Die Installation der Demo scheitert leider daran, dass ich eine > Fehlermeldung bekomme: > `error: 'LED_BUILTIN' was not declared in this scope` Richtig, die Led ist nicht definiert static const uint8_t LED_BUILTIN =2; setze den Satz über Setup. > static const byte MCP2515_INT = 23 ; keine Ahnung warum der Skript ohne Interrupt plötzlich hier einen Port für Interrupt bekommt. static const byte MCP2515_INT = 26 ; > static const byte MCP2515_RESET = 27 ; Es gibt kein bedienbaren Reset_Pin. Würde diesen Befehl erstmal ausklammern. // static const byte MCP2515_RESET = 27 ; /*--- RESET MCP2515 pinMode (MCP2515_RESET, OUTPUT) ; digitalWrite (MCP2515_RESET, LOW) ; delay (10) ; digitalWrite (MCP2515_RESET, HIGH) ; */ > Ich bin verwirrt..... das ist ESP!
Beitrag #7330449 wurde vom Autor gelöscht.
Das hat offensichtlich funktioniert. freu Wie geht es nun weiter? ;-) Gruß, Bernd
Hallo, erstmal ein kleinen Schritt noch. Du hast keine 20Mhz und die Datenrate von 125kbit/s! ist auch falsch. static const uint32_t QUARTZ_FREQUENCY = 20UL 1000UL 1000UL ; // 20 MHz ist falsch! Du hast ein 16MHz Quarz auf der Can-bus Platine. Eintrag ersetzen durch. static const uint32_t QUARTZ_FREQUENCY = 16UL 1000UL 1000UL ; Weiterhin: ACAN2515Settings settings (QUARTZ_FREQUENCY, 125UL * 1000UL) ; ersetzen durch: ACAN2515Settings settings (QUARTZ_FREQUENCY, 10UL * 1000UL) ; Dann sollte es klappen: Abspeichern unter anderen Namen.
Erledigt. In meinen Augen macht das Ding das gleiche wie vorher. Es sendet und empfängt. ;-)
Hallo, ja,... nur die werte haben sich geändert. Er sendet sich selbst~~. Hast Du Möglichkeit mit mit dem USB Can was senden.?
Hallo, der Anhang muss etwas verändert werden #include "ACAN2515.h" in #include <ACAN2515.h>, ich arbeite immer mit LIB Der Skript arbeitet bei mir mit Vorgängerversion ACAN2515 2.1.0 sollte aber auch mit der Neusten funktionieren. Er empfängt nur. Can_High mit Can_High Can_Low mit Can_Low GND mit GND (Jumper setzen) 10kbit/s evtl. muss Du zum USB_Can Abschlüsse setzen. 120 Ohm. Der Adressbereich ist momentan begrenzt auf Junkers_Ebene. 0xF9 bis 0x55F !!! Bei Verwendung an der Therme rate ich Dir dich zwischen BM1 und TA250 (oder höher), einzukoppeln (ohne Jumper). Dann sollte er alle Daten anzeigen.
Peter* schrieb: > Hast Du Möglichkeit mit mit dem USB Can was senden.? Eigentlich nicht, zumindest wüsste ich nicht wie. Das Ding lauscht nur. > Bei Verwendung an der Therme rate ich Dir dich zwischen BM1 und TA250 (oder höher) Mein Junkers-Bus sieht momentan so aus: BM1-TA2x-HSM-HMM-CANUSB Ich hatte jetzt vor, den ESP32 mit dem CANUSB zusammen an die Klemmen des HMM anzuschließen. Das sollte doch eigentlich kein Problem sein, oder? Wenn das neue Teil dann läuft, nehme ich den CANUSB außer Betrieb.
hallo,
> Das Ding lauscht nur
schlecht.
Ok, überspringen wir das.
Ist ok so.
Wenn es läuft sag bescheid, vielleicht scannen wir deinen Bus dann noch
mal um die Protokolle zu vervollständigen.
Peter* schrieb: > Wenn es läuft sag bescheid, vielleicht scannen wir deinen Bus dann noch > mal um die Protokolle zu vervollständigen. Leider ist es mir aus platztechnischen Umständen heraus nicht möglich an die Ausgabe des Moduls zu kommen, wenn es am CAN-Bus angeschlossen ist. Ich versuche daher direkt die Software von Dave zu verwenden, da diese dann per WiFi an den MQTT-Broker sendet und ich mir von dort aus die Ergebnisse anschauen kann. Die Anpassung der SPI-Schnittstelle und der Frequenzen habe ich bereits mit Daves Hilfe anpassen können. Die Software ist auch bereits auf dem Board und läuft. Lediglich mit der Konfiguration des Webinterfaces habe ich noch Probleme, habe aber auch da bereits eine Anfrage an Dave laufen. Ich melde mich, wenn ich Neuigkeiten habe. Gruß, Bernd
Hallo, > Leider ist es mir aus platztechnischen Umständen heraus nicht möglich an > die Ausgabe des Moduls zu kommen, wenn es am CAN-Bus angeschlossen ist. nun eine Arduino_Oberfläche hätte man auch mit einem Laptop gehabt. > Ich versuche daher direkt die Software von Dave zu verwenden, da diese > dann per WiFi an den MQTT-Broker sendet und ich mir von dort aus die > Ergebnisse anschauen kann. sind ja so weniger Hürden zu bewältigen um zu wissen ob der Aufbau wirklich funktioniert!!? ...nehme zwei Schritt und fall aufs M.... > Die Anpassung der SPI-Schnittstelle und der Frequenzen habe ich bereits > mit Daves Hilfe anpassen können Welche Abpassung der SPI Schnittstelle?, die funktioniert nur so wie ich sie Dir mitgeteilt habe? > Die Software ist auch bereits auf dem Board und läuft. ...und wie siehst Du das??? .
Peter* schrieb: > nun eine Arduino_Oberfläche hätte man auch mit einem Laptop gehabt. Auch wieder wahr. Melde mich. ;-) > Welche Abpassung der SPI Schnittstelle?, die funktioniert nur so wie ich sie Dir mitgeteilt habe? Ja, genau so habe ich sie konfiguriert. Hatte nicht gewusst, wo ich diese Einstellungen in Daves Software vornehmen muss. > ...und wie siehst Du das??? Nun, sie wurde erfolgreich auf das Board übertragen und gibt das aus, was sie zu diesem Zeitpunkt ausgeben soll.
Ich bin momentan etwas arg schwer beschäftigt und leiste daher Unterstützung via Discord, falls sich Leute wundern warum hier mein Name fällt aber keinerlei Reaktion erfolgt ;) Viele projektspezifische Dinge kläre ich nun auch dort um diesen Thread hier nicht unnötig mit Troubleshooting von meinem Code zuzumüllen...
Hallo, sieht so aus. Wenn Du noch deine Kommunikation einmal Scannen willst schicke ich Dir ein anders Programm. Das läuft einige Minuten und zeichnet innerhalb von 3 Minuten (reicht immer) alle Telegramme auf. Sortiert sie nach der Adressen, löscht doppelte Anträge, zeigt die Zykluszeit an und jeweils ein Daten Paket pro Adresse, Momentaufnahme. Diese Datei (*.txt) könntest Du dann hier hinterlegen mit deinem Anlagen (Ofen; Taxxx; BMx; HSM; HMM;...?) Hinweis. Für die Allgemeininformation.
Peter* schrieb: > Diese Datei (*.txt) könntest Du dann hier hinterlegen mit deinem Anlagen > (Ofen; Taxxx; BMx; HSM; HMM;...?) Hinweis. > Für die Allgemeininformation. Klar, warum nicht. Dann würde ich aber langfristig auf Daves Software umschwenken. Habe die zwar schon draufgebügelt und seltsamerweise empfängt die rein garnichts, aber umprogrammiert ist das Teil ja schnell. ;-) Liebe Grüße, Bernd
Seit gestern Abend, so gegen 23:00 Uhr lauscht mein ESP32-Modul an meiner Heizung. Erstaunlicherweise erscheinen jetzt an dem anderen Modul (Lawicel CANUSB), das parallel mithört und aktuell noch meinen HomeAssistant mit Daten versorgt, irgendwelche Störungen. (siehe Bild) Was könnte die Ursache hierfür sein und wie Stelle ich das ab? Gruß, Bernd
Peter* schrieb: > Diese Datei (*.txt) könntest Du dann hier hinterlegen mit deinem Anlagen > (Ofen; Taxxx; BMx; HSM; HMM;...?) Hinweis. > Für die Allgemeininformation. Hier übrigens meine Daten: Junkers ZSB 3-16 A 23 TA270 BM1 (vermutlich) HSM HMM
Hallo, bin erstaunt, das bei Dir doch noch einige Adressen mehr auftauchen. Vielleicht darf man hier mal eine Aufgabe / Anregung an alle Besitzer und interessierten vergeben zur Überprüfung der "Funktionen der Adressen" und Dave's Excels Datei zu erweitern und zu vervollständigen. Hierzu noch eine Info: Habe festgestellt das sich je nach Anlage (HSM;HMM bzw. TF20, HKx) die Daten_Länge (Heizkreis_Info) ändern kann. Vielleicht eine eigene Seite mit Info hinzufügen. Wenn man einen kleinen Beitrag ;-) leisten möchte bzw. zurückgegeben will. Habe inzwischen zwei Adressen im 0x600_Bereich ausgemacht. @Bernd bin etwas verwirrt, welche Fehler?... beschreibe diese doch etwas genauer. Für mich ist es schon ein Fehler ein Heizkreissoll von 10°C, das ist Frostschutz bzw. 90 °C ist wiederum max. VL oder WW_Zeitraum. Wahrscheinlich ist eher der rechte Raum im Bild zu bewerten?
Peter* schrieb: > bin etwas verwirrt, welche Fehler?... beschreibe diese doch etwas > genauer. Für mich ist es schon ein Fehler ein Heizkreissoll von 10°C, > das ist Frostschutz bzw. 90 °C ist wiederum max. VL oder WW_Zeitraum. > Wahrscheinlich ist eher der rechte Raum im Bild zu bewerten? Man sieht, dass die übermittelten Werte ab ca. 23:00 Uhr anfangen zu "schmieren". Für mich sieht das nach einer Störung im CANBUS-Protokoll aus. Vorher kommen saubere Werte rein, keine Ausreißer Um diese Zeit hatte ich Daves Software so weit, dass die Werte empfängt. Es muss also irgendetwas damit zu tun haben. Wie steuere ich nochmal alle eingebauten LED's auf diesen beiden Boards an? Gruß, Bernd
Eine der LED-Ausgaben von Daves Software zeigte auf GPIO 26. Ich glaube, dass das das "Schmieren" verursacht hat. GPIO 26 ist ja eigentlich INT ...oder täusche ich mich?
:
Bearbeitet durch User
Hallo, nein. Ihr solltet hier ein anderen LED Pin suchen bzw. benutzen( ~Pin17). Es ist der Ausgang vom MCP2515 Interrupt und ist direkt verbunden! INT wird doch benutzt. Vorsorglich nochmals durchsehen was Pierre über /INT schreibt evtl. R10K an 3,3V Pullup. can_processor.cpp: was habt Ihr denn hier eingetragen? müsste doch 26 sein und nicht 17.
Nachdem ich gegen 12:00 Uhr die Einstellungen für die LEDs verändert habe, ist das "Schmieren" zwar besser geworden, aber immernoch da. Habe jetzt 2, 12, 14 und 25 in den LED Einstellungen der configuration.json stehen.
Hallo, wenn ich das richtige sehe ist es WiFi Led die hier angeschlossen war oder ist die gewechselt werden muss. Versuche nicht die Rx Tx Pin's zu belegen. Könnte ja mal gut sein für ein Display. versuch der Analyse: Was sehen wir? Alles Aufzeichnungen von deinem CANUSB und was sieht das Gerät: alle Telegramme Hk_Soll auf dem Bus TA270/HMM (ausgewertete Adresse mir unbekannt) "und" die Vorgabe vom Programm. Oberflächlich sieht das eher wie eine widersprechende Vorgabe aus. Mal einen kürzeren Zeitraum aufnehmen. Was sagt den Dave's Programm dazu.
Hallo, Löschungsmöglichkeit: Telegramme aufzeichnen ESP_R32_REC_V01.ino -> Telegramme auf Sollvorgabe (ID) beschränken: und zwar diese Zeile if (frame.id>=0xF9 && frame.id<=0x55F) zu if (frame.id==0x252) // Sollwert Vorlauftemperatur !! 0x252 Heizkreislauf Sollwert Vorlauftemperatur
Kennt jemand den Error Code AC? Meine Steuerung funktioniert inzwischen ziemlich gut. Zur Zeit steuere ich Raumtemperatur geführt und fahre die Taktung so, dass auf eine maximale Raumtemperaturschwankung hingesteuert wird um Taktungsverluste zu minimieren. Gestern kam ich so ziemlich nah an einen Takt pro Stunde - sehr gute Ergebnisse. Allerdings bekomme ich von Zeit zu Zeit nicht von mir veranlasste Brennerstarts, die die Vorlauftemperatur hochschnellen lassen und an der Therme mit Fehlercode AC angezeigt werden (laut Anleitung "Keine Signalerkennung zwischen TA 211 E bzw. RAM und Leiterplatte. Kabel prüfen". Siehe 20:10 zweite Graphik. Kabel scheint soweit in Ordnung. Hat jemand das schon mal gesehen?
moin, mal ne frage an die profis. ich habe eine ksbr3-16a21 ohne busmodul. wie kann ich aus der daten abgreifen?
Hallo, Horst S. schrieb: > moin, > mal ne frage an die profis. ich habe eine ksbr3-16a21 ohne busmodul. wie > kann ich aus der daten abgreifen? Ohne Busmodul oder Schnittstelle dürfte Dir nur das Textmodul überbleiben. Könnte mir aber vorstellen, dass das Textmodul über I2C kommuniziert. BM1; TAxxx sind auch hier für vorgesehen.
moin peter, danke für die antwort. wo finde ich da infos zum "textmodul"?
Hallo, versuche es erst ein mal bei Junkers selbst. Bedienanleitung, Installation selbst, möglichst bei den Fachmännern... genaue Suchvorgaben sind nötig. https://www.bosch-thermotechnology.com/de/de/wohngebaeude/service-und-support/dokumente/bedienungsanleitungen/ Von Bosch selbst, wirst Du nichts bekommen. viel Suchen; selber messen; Bauteile auf der Platine..... der einfachere Weg ist Can-bus wie hier immer beschrieben.
Hallo, Joe Lucid schrieb: > Kennt jemand den Error Code AC? nun..., mit dem TA211 wird es ja wohl nichts zu tun haben... wenn Du weiter gelesen hast bzw. geprüft hast,.. steht als letztes Modul ... erneuern?? Als ich das erste mal deine Fehlermeldung gelesen habe, fiel mir der WW Heizprozess ein. Hier steigt bei mir auch die VL Temperatur extrem angeblich an. Das ist ein Fehler der Firma Junkers Bosch, das 3 Wegeventil ist noch geschlossen und die Wärme kann nicht abfließen, wenn der HK_Strang geschlossen ist. Öffnet man einen Heizkörper in der Nähe passiert das nicht. Kann dein Fehler sein,.. muss aber nicht... da wirst Du selber durch müssen.
Joe Lucid schrieb: > Allerdings bekomme ich von Zeit zu Zeit nicht von mir veranlasste > Brennerstarts So - den Fehler an der Therme sehe ich inzwischen nicht mehr. Scheint als wären die Spikes durch Fehler im Warmwasserspeicher Temp Sensor / Regelkreis begründet. Jedenfalls bekomme ich sie nicht, wenn ich die WW Soll Temp auf 0 setze. So steuere ich jetzt auch die WW Temp dynamisch. Hat auch den Vorteil, dass ich am Ende jeden Heiztaktes die WW Temp checke und falls zu kühl WW aufheize ohne den Brenner dazwischen abzuschalten. Spart eine Zündung und ein Auskühlvorgang.
Joe Lucid schrieb: > So - den Fehler an der Therme sehe ich inzwischen nicht mehr. Alles zurückgenommen. Nach ein paar Stunden kamen die AC Fehler zurück. Dieses Auftreten in Clustern brachte mich dann auf den wahrscheinlichen Grund: Die Therme mag es nicht, wenn zu viele Pakete zu Unzeiten ankommen. Da Dave's Code in Mehrfachen von 1000ms sendet und die Therme ihre Sendeslots auf Mehrfachen von 100ms hat - und die Uhr der Therme driftet - kommt es zu Problemen, wenn die Sendeslots überlappen. Ich habe jetzt die Periode zwischen Paketen auf 1013ms verlängert und ausserdem die Sendefrequenz untergedreht (zb nur Änderungen der Soll VL oder WW Temp alle 5s und sonst alle 15s) und bisher läufts den gesamten Tag ohne Spikes oder Error AC. Hoffentlich war es dann jetzt auch wirklich. Schöner wäre noch die esp32 Pakete genau zwischen den Paketen der Therme zu senden. Das versuche ich als nächstes falls wieder Probleme auftreten.
Peter* schrieb: > Hier steigt bei mir auch die VL Temperatur extrem > angeblich an. Das ist ein Fehler der Firma Junkers Bosch, das 3 > Wegeventil ist noch geschlossen und die Wärme kann nicht abfließen, wenn > der HK_Strang geschlossen ist. Meine Steuerung ist ja raumgeführt und insofern sind immer wenigstens zwei Heizkörper voll geöffnet. Trotzdem führt WW Bereitung zu Spikes -locker 20 C in 5 Sekunden. Viel mehr als die gleiche Leistung im Heizkreis bewirken würde. Meine Hypothese: der WW Wärmetauscher braucht sehr hohe Temperaturen um effizient Wärme übertragen zu können. Deswegen kocht die Therme bewusst den Brenner hoch bis das Wasser >70C hat - und pumpt erst dann durch den Tauscher. Auf jeden Fall stimmt, dass nach der WW Bereitung die Vorlauftemp im Heizkreis deutlich ansteigt - wahrscheinlich einfach durch den heissen Brenner. Wenn man hier keinen Abweg hätte, würde es wohl länger dauern bis die Vorlauftemp wieder notmal ist.
Beitrag #7354247 wurde von einem Moderator gelöscht.
BTW - wollte Euch mal den Einfluss meiner PC Lüfter auf den Heizkörpern zeigen (siehe Screenshot). Schaut Euch die Vorlauftemp im Rechteck an. Während dieser Zeit hat meine Frau die Lüfter abgeschaltet. Frappierend wie viel höher die Vorlauftemperatur geregelt werden musste. Grund für die Abschaltung ist dass der Luftzug als unangenehm empfunden wird, wenn die Lufttemperatur niedrig ist. So schalte ich die Ventilatoren seit heute nur noch an, wenn die Heizungstemp > 25.5 C ist.
Joe Lucid schrieb: > Ich habe jetzt die Periode zwischen Paketen auf 1013ms verlängert und > ausserdem die Sendefrequenz untergedreht (zb nur Änderungen der Soll VL > oder WW Temp alle 5s und sonst alle 15s) und bisher läufts den gesamten > Tag ohne Spikes oder Error AC. Wo genau hast du das verändert?
Bernd schrieb: > Wo genau hast du das verändert? Tja gestern Nacht ging's doch wieder los - und auch heute tagsüber wieder einer dabei (siehe Anhang). Habs also noch verfeinert: greife im interrupt handler des can busses die Systemzeit ab und bilde einen laufenden Mittelwert deren Offset von der vorherigen 100ms Grenze. Das ist relativ stabil (siehe letzte Spalte zweiter Anhang, Einheit uS). Pakete schicke ich etwa um 40ms versetzt (siehe Anhang 3, letzte Spalte in ms). Ausserdem halte ich mindestens 500ms nach Empfang eines Paketes Stille und lasse mindestens 450ms zwischen zwei Paketen die ich sende. Ich sag Euch morgen ob das funktioniert.
Hallo, sorry, aber versteht das noch jemand?? ich leider nicht. Du protokollierst Diagramme ohne Benennungen und ID'S die hier noch nie dargelegt wurden,... noch die der Therme zu zuordnen sind. WW ist TA... Nochmals ein Hinweis (wurde schon mal besprochen), jedes Telegramm das Du verschickst steht einem System_Telegramm gegenüber mit einem anderen Dateninhalt. Fakt, je länger Du wartest nach dem System Telegramm um so stärker wirkt sich evtl. die Störung aus. (z.B: Relais xy: an/aus) Wird während der Zykluszeit des System_Telegramms ( die zu berücksichtigen sind, 5s bis 60s) ein Feuerwerk an Telegrammen gestartet, um eine gewünschte Änderung zu erzielen, ist das nur eine unnötige Busbelastung und Störung des Bus's. Zumal wahrscheinlich alle Daten im I2C Ram im BM1 oder auch TextDisplay(falls vorhanden) zwischengespeichert werden, auch als zeitliche Schnittstelle. Die Überschreibung ist an sich schon ein Fehler, hier sollte eher eine Filterung stehen (Relais_Station); TA...trennung oder eine Fernbedienung evtl. TF20. Bin überzeugt das eine Überschreibung nur synchron ablaufen darf.
Jedenfalls scheint das Paket Timing doch nichts mit Error AC zu tun zu haben. Ich sehe nach wie vor diese spontanen WW Bereitungen mit Error AC. Während der Fehler angezeigt wird empfange ich weiterhin erfolgreich Pakete, allerdings nicht den Fehlercode AC auf dem CAN Bus. Also sieht es so aus dass Bus und BM1 in Ordnung sind, aber während der Störung die Therme nicht auf den BM1 zugreifen kann. Vielleicht liegt es auf der elektrischen Seite? Vielleicht ist das Netzteil, welches den esp32 speist zu verrauscht und die GND Verbindung bringt das auf den BM1? Werde mal versuchen das ganze batteriegespeist zu betreiben.
Hallo, schlage Dir vor dein System mit einfachster Einstellung ein paar Tage laufen zu lassen und zwar ohne ESP32 Anbindung. Eine ganz normale Heizungs- und Warmwassereinstellung ohne null oder sonstige besonderen Parameter aber mit Außenfühler. Auf dieser Grundlage kannst Du dann aufbauen. Wenn dann noch immer ein Fehler auftritt hast Du ein Problem.
Ich glaub ich habs jetzt - warte jetzt bis 800 ms seit letztem Paket von der Therme vergangen sind. Bei meiner 18-5 habe ich dann immer mindestens 700 ms bis das nächste von der Therme kommt. In der Zeit kann ich locker alle Parameter schicken - also kein round robin oder definierter Sekunden Takt pro Paket Typ. Schicke jetzt alle 5s alles. Und zumindest heute gab es keinen AC Fall mehr seit der Änderung.
Hallo, zur Anmeldung gezwungen, Gründe Spam wer es glaubt! Nun, was verstehst Du unter Paket? Sieht man sich die Zykluszeiten der einzelnen Telegramme an kann der ESP schlafen gehen bei 10K. Frage wieviel Telegramme willst Du denn eigentlich verändern?? Warum, nicht so, Filter setzen und Interrupt oder halt per normaler SW :if Id==xx dann sende Meine_Daten, evtl. mit einer kleinen Verzögerung. Statt den Bus zu blockieren und wieder AC (keine Verbindung -> evtl. Timeout) zu bekommen. Joe L. > Schicke jetzt alle 5s alles. Und zumindest heute gab es keinen AC Fall > mehr seit der Änderung. Das ist eine Bestätigung, Ihr füllt den Can-Bus mit Daten
War wieder mal eine Ente. 10h funktionierte es ohne Fehler AC - dann kam der wieder dazu. Scheint überhaupt nichts mit der Sendefrequenz der Telegramme zu tun zu haben. Ich werde wohl nicht drum rum kommen mal den i2c Datenverkehr aufzuzeichnen. Vermutlich ist das als Multi-Master System ausgelegt und Therme sowie BM1 fungieren beide als Master. Vielleicht behandelt eine Seite Kollisionen nicht korrekt. Ich habe hier noch ein paar Moteinos (https://lowpowerlab.com/shop/product/99) rumliegen. Den BM1 durch einen solchen zu ersetzen und dann über 433mhz kommunizieren - das wäre traumhaft. Aber so wie ich sehe war bisher niemand erfolgreich beim reverse Engineering des i2c Austauschs, richtig?
Hallo, Du weißt aber, das Du nur herumstocherst. Den Fehler finden heißt auch wirklich die Grenzen woher der Fehler kommt immer enger zu ziehen. Und der erste Schritt währe nun, ob Du ein HW_Fehler wirklich vorliegt. > Scheint überhaupt nichts mit der Sendefrequenz der > Telegramme zu tun zu haben. Woraus schließt Du das? > Ich werde wohl nicht drum rum kommen mal den i2c Datenverkehr > aufzuzeichnen. Vermutlich ist das als Multi-Master System ausgelegt und > Therme sowie BM1 fungieren beide als Master. Vielleicht behandelt eine > Seite Kollisionen nicht korrekt. Ganz sicher nicht! Die Therme ist der Master, fügst Du zum Textdisplay (i2C) ein BM1 hinzu bekommst Du keine Möglichkeit der Eingabe durch das Textdisplay. (so die Beschreibung, ..noch nicht nachgeprüft). Daten fließen dann zum BM1. Therme <--> Bedienteil(TA...) Dieser I2C hat etwa 25 bis 30KHz? (wird immer wieder von mir gemessen ??) warum SCL auch nicht symmetrische ausgelegt ist auch noch eine offene Frage. Würde Dir auch empfehlen nicht ohne optische Trennung I2C. (glaube bei Reichelt habe ich sie neulich gesehen) Bin mir ganz sicher das Du hier mehr Fragen stellen wirst, die weder jemand beantworten kann, noch das man die Zeit hat dem nach zugehen. Die Übergabe dann an eine unsichere 433 MHz Kommunikation muss man dann,... erst mal verstehen. Mein Stromzähler läuft auch über 2,4 MHz (Kanal 101) und mindestens einmal am Tag ist hier ein Fehler dabei, der nicht abgefangen wird. Ärgerlich...
Peter* schrieb: > Hallo, > > Du weißt aber, das Du nur herumstocherst. Den Fehler finden heißt auch > wirklich die Grenzen woher der Fehler kommt immer enger zu ziehen. > Und der erste Schritt währe nun, ob Du ein HW_Fehler wirklich vorliegt. Meine Möglichkeiten sind da etwas beschränkt, weil ich kein Bedienteil TA??? habe. Es funktioniert ja alles prima bis auf die AC Fehler, die bedeuten dass die Therme sporadisch nicht auf das i2c ram zugreifen kann. Von daher sollte ich mir sowieso mal die i2c Signale anschauen. Kabel und Connector sind es nicht - Kabel hab ich getauscht und Connector gereinigt. > >> Scheint überhaupt nichts mit der Sendefrequenz der >> Telegramme zu tun zu haben. > > Woraus schließt Du das? Daraus dass die Fehler unabhängig von vielen unterschiedlichen Sendealgorithmen auftreten. Sie sind zb nicht häufiger wenn ich Datum, F9, WW temp, Vorlauf Soll, Heizbetrieb, Witterungssteuerung alle zusammen in 500ms sende. Und treten auch auf wenn ich den Rhythmus der TA??? verwende. > >> Ich werde wohl nicht drum rum kommen mal den i2c Datenverkehr >> aufzuzeichnen. Vermutlich ist das als Multi-Master System ausgelegt und >> Therme sowie BM1 fungieren beide als Master. Vielleicht behandelt eine >> Seite Kollisionen nicht korrekt. > > Ganz sicher nicht! > > Die Therme ist der Master, fügst Du zum Textdisplay (i2C) ein BM1 hinzu > bekommst Du keine Möglichkeit der Eingabe durch das Textdisplay. (so die > Beschreibung, ..noch nicht nachgeprüft). Daten fließen dann zum BM1. > > Therme <--> Bedienteil(TA...) Ich denke Therme und BM1 sind Master und das i2c ram ist der Slave. I2C unterstützt das und es ist die einzige vernünftige Möglichkeit die ich sehe ein geteiltes I2C Ram zu implementieren. Ich meine auch Du hast nur eine I2C Adresse gesehen - das passt auch, weil beide Master unter der gleichen Adresse auf das Ram zugreifen. > Dieser I2C hat etwa 25 bis 30KHz? (wird immer wieder von mir gemessen > ??) warum SCL auch nicht symmetrische ausgelegt ist auch noch eine > offene Frage. I2C bietet die Möglichkeit für Slaves, den Takt zu verlangsamen indem der Slave die untere Flanke verlängert. Das könnte der Grund sein. Zwei Master könnten mit unterschiedlichen Frequenzen arbeiten. > Würde Dir auch empfehlen nicht ohne optische Trennung I2C. (glaube bei > Reichelt habe ich sie neulich gesehen) Ich würde das ganze von der Stromversorgung der Therme her betreiben um mit gleichem GND zu arbeiten. Aber als erstes kommt einfach mal mein logic analyzer dran. > Bin mir ganz sicher das Du hier mehr Fragen stellen wirst, die weder > jemand beantworten kann, noch das man die Zeit hat dem nach zugehen. Die > Übergabe dann an eine unsichere 433 MHz Kommunikation muss man dann,... > erst mal verstehen. In meiner Wohnung ist leider 2.4mhz wifi super unzuverlässig und ich habe mit dem esp32 häufig Probleme damit. Setze 433 MHz für home automation mit sehr hoher Zuverlässigkeit ein. Z.b sind die Thermometer für die Raumsteuerung alle basiert auf dieser Technologie. Das ganze wird dann über einen esp8266 nach wifi geroutet. Ich würde die Steuerung dann in diesen esp8266 mit einbauen. Damit wäre die Heizungssteuerung komplett unabhängig vom Internet/Wifi - ein grosses plus. Und die Heizungsventile können dann am gleichen 433mhz Netz teilnehmen.
Wahrscheinlich wäre es am einfachsten, den atmega 328p im Moteino einfach als i2c slave zu betreiben und das Ram zu simulieren. Der PCF8570 hat 256 byte RAM - das würde passen. 5V haben wir auch. Es ist also im Bereich des Möglichen dass ein Moteino für ~10 Euro den BM1 vollwertig für unsere Zwecke ersetzen könnte.
Peter* schrieb: > warum SCL auch nicht symmetrische ausgelegt ist auch noch eine > offene Frage. Ich kann die CPU auf der Hauptleiterplatte leider nicht identifizieren - ausser dass sie von NEC ist (siehe foto). Auch möglich dass i2c per bitbang implementiert ist da nicht nativ unterstützt. Das externe RAM vermutlich, da die CPUs so wenig Speicher haben. Die grosse auf dem BM1 hat 512 byte total.
Hallo, ich habe die Software von Dave auf den ESP32 geflascht (die beiden BIN-Files per ESPTool) und komme nicht auf den Access Point Cerasmarter 192.168.4.1. Mit dem Access Point kann ich mich verbinden aber wie komme ich auf das WebUI? Hardware ist ESP32 mit CANdiy-Shield 2.1, Jumper 1-3 sind eigelötet, Jumper ist auf 3,3V umgelötet. CAN-Bus wurde erfolgreich mit LoopBackDemoESP32 getestet. VG Xander
Hallo, > Meine Möglichkeiten sind da etwas beschränkt,.... sorry, aber ich werde mir die einzelnen Aufbauten nicht merken können, auch wenn momentan nur noch Bernd ab und zu auftaucht. Das ist momentan hier nur "eben mal draufschauen". Die Zeit habe ich gar nicht zur Verfügung. ... das ändert doch die Problematik, Du hast keinen Mischer in der Anlage, also Pur und woher kommen dann die 500ter und sogar 600 Id's her in deiner Aufzeichnung die Du neulich dargelegt hast? > Es funktioniert ja alles prima bis auf die AC Fehler,... ja, genau deshalb.... dein System meldet Dir,...mir fehlt was oder es kommt nicht in der richtigen Reihenfolge oder nicht zum richtigen Zeitpunkt. Das ist auf dem Can-Bus durchaus üblich. Du schickst ein Telegramm das evtl. die Anwesenheit eines HMM oder HSM meldet und dann sind sie nicht mehr da. > dass die Therme sporadisch nicht auf das i2c ram zugreifen Glaube mir, das hat nichts damit zutun, es ist jetzt ungefähr 1 1/2 Jahre her das ich den i2C aufgegriffen habe und zeitlich war das ein Fass ohne Boden. > Sendefrequenz die Sendefrequenz ist 10k vom Can-Bus, du meinst die Zykluszeit der Telegramme > Ich würde das ganze von der Stromversorgung der Therme her betreiben um > mit gleichem GND zu arbeiten. Am Stecker des zum BM1 sind 5 V vorhanden am Textdisplay nur 24V. Ich rate Dir aber trotzdem ab, modifiziere lieber deine Anlage mit dem Can-Bus und vereinfache deine Kommunikation auf das nötige und zeitliche korrekte Telegramm. Simuliere hier das TA... das ist einfacher als Du glaubst vom zeitlichen und erst recht mit einem ESP32 (....240Mhz)
> ... das ändert doch die Problematik, Du hast keinen Mischer in der > Anlage, also Pur und woher kommen dann die 500ter und sogar 600 Id's her > in deiner Aufzeichnung die Du neulich dargelegt hast? Das war mit dem BM2 - mit dem BM1 sieht alles genau so aus wie es soll. > Ich rate Dir aber trotzdem ab, modifiziere lieber deine Anlage mit dem > Can-Bus und vereinfache deine Kommunikation auf das nötige und zeitliche > korrekte Telegramm. Simuliere hier das TA... das ist einfacher als Du > glaubst vom zeitlichen und erst recht mit einem ESP32 (....240Mhz) Na das habe ich jetzt bis ins Extreme getan. Ich habe genau wie die TA's gesendet und auf viele anderen Weisen. Das ist nicht das Problem. > es ist jetzt ungefähr 1 1/2 > Jahre her das ich den i2C aufgegriffen habe und zeitlich war das ein > Fass ohne Boden. Du hast nur relativ wenig zu dem Thema hier geschrieben und das war nicht so recht klar (für mich). Hast Du den I2c Bus belauscht während die Hauptplatine mit BM1 verbunden war? Waren alle Daten auf dem BM1/Hauptplatine Bus I2c Packete an die Adresse 0x50 oder gab es noch anderen Austausch (möglicherweise direkt zwischen BM1 und Platine)? Mir scheint die Architektur mit dem geteilten i2c RAM darauf hinzudeuten, dass die Prozessoren durch den asynchronen Austausch über das RAM entlastet werden sollten. Wenn das eine Motivation ist, würde man wohl alles darüber laufen lassen. Aber dann hätte ich erwartet, dass man Lese- und Schreizugriffe auf Adresse 0x50 sehen würde, die die Informationen auf dem Can Bus reflektieren. Der Prozessor auf dem BM1 kann übrigens DMA von Can Bus direkt ins RAM - ein Grund zu spekulieren, dass das Timing der Can Bus Pakete keine Rolle spielt. Wie es sich in allen meinen Versuchen bisher gezeigt hat.
Auch interessant (https://www.nxp.com/docs/en/data-sheet/P8XC592.pdf): The main differences between P8xC592 and P8xC552 are: • 16 kbytes programmable ROM (P8xC552 has 8 kbytes) • Additional 256 bytes RAM • A CAN-controller instead of the I2C-serial interface. Mit anderen Worten die I2C Implementierung auf dem BM1 erfolgt in Software. Wie oben erwähnt ist das wahrscheinlich der Grund für das von Dir beobachtete asymmetrische SCL.
Hallo, > Na das habe ich jetzt bis ins Extreme getan. Ich habe genau wie die TA's > gesendet und auf viele anderen Weisen. Das ist nicht das Problem. Hast du nicht geschrieben das Du alle Telegramme hintereinander verschickst? Ich habe hier ein Programm hinterlegt das die Zykluszeiten ans Telegramm heftet. Baust Du Dir hieraus ein Array mit Struktur und sendest deine Telegramme zur Zykluszeit ist es richtig. > Hast Du den I2c Bus belauscht... Das war ein Schreibtischtest ohne Hauptplatine, eher TA250 <--> Speicher, des halb habe ich es auch nicht weiter veröffentlicht. Meine Vermutung war das alle Daten (notwendige) vom TA.. in den Speicher geschrieben werden sowie Umgekehrt und das der Speicher als Bindeglied benutzt wird zur zeitlich Entkopplung. Das konnte ich nicht belegen, aber es gab besondere Zellen die wohl von der Platine als Daten gültig benutzt werden. Handshake. Vom BM1 oder Speicher gingen keine anderen Adressen ab. > dass > man Lese- und Schreizugriffe auf Adresse 0x50 sehen würde Das ist auch der Fall, nur die Zellen ändern sich zum Teil? Der Versuch einer Analyse war mehr als schwierig. Hier mal ein Versuch Datei. ohne Anspruch das es wirklich so war, im Schreibtischtest.
> Ich habe hier ein Programm hinterlegt das die Zykluszeiten ans Telegramm > heftet. Baust Du Dir hieraus ein Array mit Struktur und sendest deine > Telegramme zur Zykluszeit ist es richtig. Das habe ich alles schon versucht. Dave's Timing, Timing nach Deiner Analyse, alles zusammen, sogar in zu festen Offsets in ms von empfangenen Paketen. >> Hast Du den I2c Bus belauscht... > Das war ein Schreibtischtest ohne Hauptplatine, eher TA250 <--> > Speicher, des halb habe ich es auch nicht weiter veröffentlicht. > > Meine Vermutung war das alle Daten (notwendige) vom TA.. in den Speicher > geschrieben werden sowie Umgekehrt und das der Speicher als Bindeglied > benutzt wird zur zeitlich Entkopplung. Das konnte ich nicht belegen, > aber es gab besondere Zellen die wohl von der Platine als Daten gültig > benutzt werden. Handshake. Vom BM1 oder Speicher gingen keine anderen > Adressen ab. > >> dass >> man Lese- und Schreizugriffe auf Adresse 0x50 sehen würde > > Das ist auch der Fall, nur die Zellen ändern sich zum Teil? Der Versuch > einer Analyse war mehr als schwierig. Hier mal ein Versuch Datei. Ah ok, danke. Ich vermute man muss schon mit der Hauptplatine testen. Kann gut sein dass der BM1 sich beim Beschreiben des RAMs auf die Therme einstellen muss und deswegen drauf wartet eine Kennung der Therme im RAM zu finden. Der BM1 mag Teile des RAMs für eigene Zwecke nutzen - dann würden die sich ändern aber ohne offensichtliche Relation zu Can Bus Paketen. Naja wenn ich etwas Zeit habe probiere ich es mal aus. Funktioniert so auch schon gut genug aber die gelegentlichen Spikes stören mich gewaltig auch wenn die Energieverschwendung gering ist und mehr als überkompensiert wird durch mein ~45 minütiges Takten. Ich habe ziemlich frappierende Einsparungen dieses Jahr - siehe Anhang. Da kann man zufrieden sein.
Marco schrieb: > Hallo, > ich habe die Software von Dave auf den ESP32 geflascht (die beiden > BIN-Files per ESPTool) und komme nicht auf den Access Point Cerasmarter > 192.168.4.1. > Mit dem Access Point kann ich mich verbinden aber wie komme ich auf das > WebUI? > Hardware ist ESP32 mit CANdiy-Shield 2.1, Jumper 1-3 sind eigelötet, > Jumper ist auf 3,3V umgelötet. > CAN-Bus wurde erfolgreich mit LoopBackDemoESP32 getestet. Hast du vorher auch ein Filesystem geflasht?
Hallo, abschließend I2C. Joe L. > Der BM1 mag Teile des RAMs für eigene Zwecke nutzen - dann würden die > sich ändern aber ohne offensichtliche Relation zu Can Bus Paketen. nein, reine Kommunikation,...bei 256 Byte? die Excel_Datei zeigt ja das Soll Daten vom TA.. abgelegt wurden. Ist_Daten werden von der Therme... dort abgelegt. So ist jeder zeitlich unabhängig im Rahmen der zyklischen Protokolle. Könnte mir vorstellen das hier ein ALive_byte oder Bits existiert die hochgezählt werden und zum Fehler führen... Spekulation Der Beitrag Junkers TA270 CAN-Fehler 1 von crazyhorse bestätigt die Annahme der Kommunikation. > Ich habe ziemlich frappierende Einsparungen dieses Jahr - siehe Anhang nun gewagte Durchschnittsberechnung. 365Tage?
Peter* schrieb: > Hallo, > > abschließend I2C. > > nein, reine Kommunikation,...bei 256 Byte? die Excel_Datei zeigt ja das > Soll Daten vom TA.. abgelegt wurden. Ist_Daten werden von der Therme... > dort abgelegt. > So ist jeder zeitlich unabhängig im Rahmen der zyklischen Protokolle. Na dann scheint doch alles ganz einfach zu sein - sorry hatte Dein spreadsheet nicht ganz richtig gelesen. Dann müssen wir doch lediglich ein i2c ram slave auf der Adresse 0x50 simulieren und unsere soll Werte an den richtigen Stellen ablegen uns sind fertig. > > Könnte mir vorstellen das hier ein ALive_byte oder Bits existiert die > hochgezählt werden und zum Fehler führen... Spekulation Da die Fehler so selten sind und in Clustern auftauchen vermute ich dass es sich um Kollisionen handelt. Multi Master i2c ist ja etwas tricky falls beide Master gleichzeitig auf den Slave zugreifen und gerade da der BM1 i2c offenbar in Software implementiert kann man sich leicht vorstellen dass dieser Spezialfall gelegentlich in die Hose geht. Dieses Problem wäre mit einem simulierten i2c RAM gelöst weil der BM1 Master wegfällt. > > Der Beitrag Junkers TA270 CAN-Fehler 1 von crazyhorse bestätigt die > Annahme der Kommunikation. Ja - danke für den Pointer. >> Ich habe ziemlich frappierende Einsparungen dieses Jahr - siehe Anhang > nun gewagte Durchschnittsberechnung. 365Tage? Keine Ahnung wie die das schätzen. Ich denke das Resultat wird noch besser sein. Wenn wir aus der Heizsaison raus sind brauche ich nicht mehr als vielleicht 12 kWh pro Tag für WW. Jedesmal wenn ich einen neuen Zählerstand hoch lade sinkt die Schätzung. Ich hatte den WW Speicher früher auf 60 C für das Baden. Jetzt halte ich den auf um die 37 C und habe ein Frontend über das sich Mitbewohner 45 C zum Duschen oder 60 C zum Baden anfordern können. Das spart locker 10 kWh am Tag. Und die raumgeführte Steuerung wird gerade jetzt in der Übergangszeit die Solargewinne (wir wohnen 4. Stock und Dachgeschoss) optimal nutzen. Du kannst es am heutigen Tag schön sehen (angehängt). Die Taktfrequenz zwischen 13 und 15 Uhr lag bei < 1 Takt pro Stunde und es gab so gut wie kein Ueberschiessen der Temperatur.
Hier ein Mitschnitt von i2c bei laufender Therme. Es könnte simpler nicht sein. Wie vermutet ist es ein Multimaster setup - dh Therme und BM1 sind master und schreiben/lesen das RAM unter i2c Adresse 0x50. Es gib Lese- und Schreibzugriffe. Zum lesen wird erst in einem write an 0x50 die RAM Adresse geschrieben und dann mit einem 2. read request an 0x50 der Inhalt ausgelesen. Zum Schreiben ist es nur ein i2c write an 0x50 mit einer folge von Bytes - erstes ist die RAM Adresse und dann folgen die Daten. Die Therme schreibt an 0x20 ... und liest von 0x90 ... . An den Adressen 0x10 und 0x11 wird handshake betrieben: 0x10 == 1 bedeutet es liegen Daten von der Therme für den BM1 vor. 0x11 = 1 bedeutet es liegen Daten vom BM1 für die Therme vor. 0x91 ist Vorlauf soll - mehr hab ich noch nicht abgeglichen. Zusätzlich wird RAM Adresse 0xfe-0xff noch gelesen und beinhaltet immer 0xfc 0x03. Habe nicht gesehen dass das je geschrieben würde. Keine Ahnung was das ist. Pull-ups ziehen auf 5v. Zusätzlich zum Moteino braucht man also eine Level shifter. Ansonsten ist das ganze trivial.
Ok - Anfang der Kommunikation war abgeschnitten. 0xfe und noch ein paar andere werden am Anfang geschrieben. Muss ich nochmal im Detail anschauen.
Hallo,
na super!
Bestätigt ja sogar meine Excel_Liste 10/11 und 90 Adressen im Bereich
TA... und Speicherende dazu hatte ich auch eine Ahnung, aber zu lange
her und noch nix schriftlich.
Vielleicht parallel, noch das Can Bus Protokoll und direkt im 16ner
block darlegen um feste Adressen zu bestätigen.
Habe leider keine Zeit hier mit fest einzusteigen, zumal mir nur ein
Saleae logic Analyzer zur Verfügung steht. Ein Hauptplatine und ein
Textdisplay liegen bei mir schon ein Jahr herum, um hier eine
aussagefähige Lösungen zu finden.
> Ansonsten ist das ganze trivial..
Sorry, aber so würde ich es noch nicht sehen. Der Beitrag hier ist von
2007 und eine optimale Lösung ist noch nicht auf dem Tisch, teils
funktioniert es, dann gibt es wieder Probleme. Die Schnittstelle nutzen
zu können heißt nicht das dein Problem gelöst ist, aber eine Kostenfrage
währe gelöst, aber auch wieder gefährlich. Optische Trennung ist ein
muss.
Vielleicht kann Marco jemand mit Dave's Programm weiterhelfen, einer
mehr im Boot.
Peter* schrieb: > Optische Trennung ist ein > muss. Warum das denn? Pegelwandler auf die i2c Leitungen auf die 5V vom Board und Moteino mit den 5v vom Board betreiben. Dann ist das super safe. Was soll denn bei i2c passieren, wo der output aller pins immer aktiv 0 oder floating ist.
Hallo, Sicher, es ist jeder selbst verantwortlich! Aber man muss drauf hinweisen. Die Hauptplatine kostet "noch(lieferbar)" 300 bis 500Euro plus, deine I2C Platine kostet ~10Euro. Ein HW defekt ist eher bei der I2C Platine möglich als bei der Hauptplatine unter der Einbaubedingung, aber zerstört evtl. auch die Hauptplatine. Nimm ein Oszilloskop und messe mal an deiner Therme und Du wirst beim schalten der Ventil(Gas)usw. Spannungsspitzen sehen die sehr bedenklich sind. Viele haben hier schon HW ersetzt und hier war auch nur Can-Bus Aktivität vorhanden. Natürlich geht es einfacher, aber sicher ist sicher.
Hallo, habe mir die Daten mal angeschaut. Kannst Du die Beschriftung ändern in TA lesen /schreiben und Therme lesen/ schreiben währe einfacher und wie Du schon erwähntes die Start Sequenz ist sehr wichtig. Währe einfacher zu analysieren.
Kommt leider so aus Logic 2, was ich auch benutze. Hier ist eine andere Ansicht mit Startsequenz. Der ziemlich letzte Knackpunkt für mich ist das letzte Byte der Schreibsequenzen auf 0x90. Das ist eine Checksumme, die ich noch nicht erkenne. Hatte gehofft dass wir der Therme vielleicht noch die Nachlauftemperatur entlocken können - aber so sieht es nicht aus. Dafür verändern sich einige flags wenn der Brenner anläuft. Ich schätze, Ventilation, Zündung und vielleicht sogar Zustand des 3-wege Ventil sind abgreifbar.
Marco ist mittlerweile bei Dave und mir auf Discord. Ich kümmere mich um ihn. ;-)
Joe L. schrieb: > Das ist eine Checksumme, > die ich noch nicht erkenne. Done: laux@macbook-14 reveng-3.0.5 % ./reveng -w 8 -s FF00100100010200000000000000FFEE FF02120100010200000000000000FF17 FF04140100010200000000000000FF25 FF04140100010300000000000000FF35 FFB4000100010200000000000000FF1D FFB4000100010300000000000000FF0D FFB4020100010200000000000000FF15 FFB4020100010300000000000000FF05 FFB4040100010200000000000000FF0D FFB4040100010300000000000000FF1D FFB4060100010200000000000000FF05 FFB4080100010200000000000000FF3D FFB4080100010300000000000000FF2D FFB40A0100010200000000000000FF35 FFB40A0100010300000000000000FF25 FFB40C0100010200000000000000FF2D FFB40C0100010300000000000000FF3D FFB40E0100010200000000000000FF25 FFB40E0100010300000000000000FF35 FFB4060100010200000000000000FF05 FFB4080100010200000000000000FF3D FFB40A0100010200000000000000FF35 FFB40C0100010200000000000000FF2D FFB40E0100010200000000000000FF25 FFB4100100010200000000000000FF5D FFB4120100010200000000000000FF55 FFB4140100010200000000000000FF4D FFB4160100010200000000000000FF45 FFB4160100010300000000000000FF55 width=8 poly=0x39 init=0x00 refin=false refout=false xorout=0x00 check=0x8f residue=0x00 name=(none)
Hallo, nun so viele Daten benötigen wir erstmal nicht, es reichen die normalen Sequenzen zu interpretieren. Das sind zwei, die Start- und die Daten Austausch_Sequenz.(ohne TA... mit neue Daten) die letzte Datei bringt wohl die Pause als auch eine i2C Adresse 49 aber ist eher ungeeignet. Hast Du die Sw von der vorherigen Datei, müsste ja Arduino sein.
Hallo, Joe L. schrieb: > Hatte gehofft dass wir der Therme vielleicht noch die Nachlauftemperatur > entlocken können - aber so sieht es nicht aus. Dafür verändern sich > einige flags wenn der Brenner anläuft. Ich schätze, Ventilation, Zündung > und vielleicht sogar Zustand des 3-wege Ventil sind abgreifbar. Nachlauftemperatur? -->Rücklauftemperatur, woher soll die kommen meine Heizung hat kein Fühler hierfür. Nun hatte in einer Information zum Textdisplay gelesen das hier, auch die Einstellung und Service dargestellt wird.??
Peter* schrieb: > Hallo, > > nun so viele Daten benötigen wir erstmal nicht, es reichen die normalen > Sequenzen zu interpretieren. Das sind zwei, die Start- und die Daten > Austausch_Sequenz.(ohne TA... mit neue Daten) > > die letzte Datei bringt wohl die Pause als auch eine i2C Adresse 49 aber > ist eher ungeeignet. Die letzte Datei hat die start Sequenz und dann den laufenden traffic. Es ist eigentlich wirklich alles banal einfach. Am Anfang schreibt einer von beiden die zwei bytes an 0xfe und eine Sequenz an 0xe0 (die nie wieder gelesen wird). Dann läuft der Austausch wie vorher beschrieben. Dabei testet die Therme die zwei bytes an 0xfe ab bevor sie liest/schreibt. Die Implementierung des neuen Adapters braucht nichts anderes zu tun als alle writes von der Therme zu speichern und bei Anfrage zurückzuliefern. Und periodisch den 0x90 ... Bereich intern (nicht über i2c) gemäss der Vorgaben der Steuerung updaten und die Handshake bytes checken/updaten. Ausserdem sendet sie einfach periodisch die Infos in 0x20 ... an die Steuerung. Das ist wirklich nicht mehr als 50 Zeilen Code. > > Hast Du die Sw von der vorherigen Datei, müsste ja Arduino sein. Das war auch Logic 2 Saleae mit i2c Analyzer. Aber da hatte ich aus dem Terminal output per cut&paste kopiert. Das sind leider nur die Daten der letzten paar Minuten.
Peter* schrieb: > Nachlauftemperatur? -->Rücklauftemperatur, woher soll die kommen meine > Heizung hat kein Fühler hierfür. Tomeito - Tomahto ja ich meinte Rücklauf. Hab gerade nochmal das Manual angeschaut und es gibt noch einen Brennertemp Fühler. Aber Du hast Recht es ist kein Rücklaufsensor drin. > > Nun hatte in einer Information zum Textdisplay gelesen das hier, auch > die Einstellung und Service dargestellt wird.?? Da bin ich aussen vor. Ich bin noch eine Generation vor Textdisplay (18-5).
spannend...das sollte doch auch alles problemlos mit der integrierten Schnittstelle von den Arduinos und ESPs funktionieren...?
Dave G. schrieb: > spannend...das sollte doch auch alles problemlos mit der integrierten > Schnittstelle von den Arduinos und ESPs funktionieren...? Ja - Du brauchst nur einen Pegelwandler wie die hier: https://www.amazon.de/dp/B082F6BSB5?psc=1&ref=ppx_yo2ov_dt_b_product_details
Hallo, ich dachte Du hast mit deiner Schaltung die SW ausgewertet. Es gibt kaum wirklich funktionierende SW für Arduino, zu langsam? Nun, wenn Du SW hast zur Auswertung bitte ich Dich diese darzulegen. > Ich bin noch eine Generation vor Textdisplay Habe ich auch nicht, aber der Stecker passt auch dort. Uhrstecker hat mehrere Kodierungen und die Endabnahme von Bosch/Junkers wird sicher über I2C durchgeführt. > Brennertemp Fühler Ist ein Sicherungsschalter. > Letzte Hürde war die Checksumme - aber die hab ich ja nun geknackt. Habe ich leider nicht verstanden, noch gesehen.
Am Anfang schreibt einer > von beiden die zwei bytes an 0xfe und eine Sequenz an 0xe0 (die nie > wieder gelesen wird). Btw man kann an SCL sehen welcher Master schreibt. Die erste Initialisierung kommt vom BM1. BM1 ist daran erkennbar dass SCL asymmetrischer und unregelmässiger ist und die low Seite länger. All das liegt daran dass wie oben gesagt der BM1 keine i2c Funktionalität in HW hat und das in SW simulieren muss. Siehe Anhang.
Peter* schrieb: > Nun, wenn Du SW hast zur Auswertung bitte ich Dich diese darzulegen. Ich habe das alles mit Saleae Logic 2 und einem Logic Pro 16 gemacht. Das Ding ist super - kann ich nur jedem empfehlen.
Peter* schrieb: > Habe ich leider nicht verstanden, noch gesehen. Es ist ein 8 bit CRC mit folgenden Parametern: width=8 poly=0x39 init=0x00 refin=false refout=false xorout=0x00 check=0x8f residue=0x00
Peter* schrieb: > Nun, wenn Du SW hast zur Auswertung bitte ich Dich diese darzulegen. Ich kann Dir die Logic Capture Datei schicken - Du hast doch auch Logic? Dann kannst Du das wie ich in der Applikation analysieren.
Joe L. schrieb: > BM1 ist daran erkennbar dass SCL > asymmetrischer und unregelmässiger ist und die low Seite länger. So sieht ein Zugriff von der Therme aus. Das ist im Gegensatz zum BM1 i2c in HW.
Und hier sieht man mal wie lange der BM1 den I2C Bus belegt. Volle 80 ms - SCL bleibt zwischen den einzelnen Sequenzen low. Zweiter screenshot zeigt die Kollision zwischen beiden Mastern. Das verursacht denke ich die Fehler AC. Und da es mit dem neuen Ansatz nur noch einen Master gibt wird das AC Problem wahrscheinlich gelöst sein.
Ach sieh an: https://www.qworqs.com/2021/05/19/are-the-esp32-and-esp8266-5v-tolerant-yes-they-officially-are/ Wir brauchen noch nicht einmal die Pegelwandler mit den Esps.
Hallo, bin kein I2C Spezi, aber ich sehe kein CRC, aber erstmal egal. Erstaunlicherweise ist in der letzten Datei I2C.csv, 3 Zeile Speicheradresse 0xE0 identisch mit meiner Excel_Liste 0xE0...0xE7. Hier wird scheinbar etwas beschrieben, Aufbau... > Zweiter screenshot zeigt die Kollision zwischen beiden Mastern. Das > verursacht denke ich die Fehler AC. Und da es mit dem neuen Ansatz nur > noch einen Master gibt wird das AC Problem wahrscheinlich gelöst sein. ? willst auf den Speicher verzichten oder wie soll das funktionieren.
Letztes Byte in der 0x90 … Sequenz ist ein CRC der vorangehenden Bytes. Und ja klar - wozu ein RAM? Deswegen schreibe ich doch immer wir simulieren das RAM für die Therme auf dem Arduino.
Hallo, na klar, Bosch/Junker hat mal wieder übertrieben und baut mal eben einen Speicher ein, der ja gar nicht benötigt wird. Da bist Du aber sehr weit von der Realität weg, auch wenn sich die Frequenz der Controller in laufe der Jahre geändert hat. Für ein Cent/Pfennig hätten die auch vor 20 Jahre das Bauteil gewechselt oder mit nc gekennzeichnet. Und welche Aufgabe hatte der Speicher noch? und diese ist nicht mehr vorhanden? Weitergedacht, ganz grob nach deiner Aufzeichnung hast Du etwa 20ms zeit deine anderen geplanten Aufgaben zu erfüllen. Vorschlag, CRC über Tabelle ist schneller. Hauptsache, der dein AC-Fehler ist nicht mehr da.
Peter* schrieb: > Da bist Du aber sehr weit von der Realität weg, auch wenn sich die > Frequenz der Controller in laufe der Jahre geändert hat. Für ein > Cent/Pfennig hätten die auch vor 20 Jahre das Bauteil gewechselt oder > mit nc gekennzeichnet. > > Und welche Aufgabe hatte der Speicher noch? und diese ist nicht mehr > vorhanden? > > Weitergedacht, ganz grob nach deiner Aufzeichnung hast Du etwa 20ms zeit > deine anderen geplanten Aufgaben zu erfüllen. Da sehe ich nicht das geringste Problem. Daten werden natürlich vorbereitet und CRC vorher berechnet. Am besten mit double buffering - d.h. die Bereiche im RAM die der BM1 schreibt gibt es zweimal: einmal aktuell zum Zugriff per i2c. Und ein 2. mal zur Aufbereitung der neuen Daten. Sind die Daten fertig und der Bus frei werden die Sektionen getauscht. 30khz is super lahm. So um die 0.3 ms per byte - das sind 2400 Taktzyklen eines 8 MHz Arduino. In der Zeit schaffe ich es schon ein Byte vom RAM in den i2c buffer zu schreiben :-). Sinn des Speichers ist es die alten langsamen Prozessoren vor exzessiver Kommunikation zu bewahren. Die Therme ist weiter bewahrt. Aber der Arduino muss davor nicht bewahrt werden.
Bedenke auch dass sich durch diesen Ansatz jegliches Schreiben der Soll Daten per I2C ins Ram erübrigt. Was der BM1 ja per software bitbang macht. Da Arduinos HW I2C haben muss nur der Buffer per interrupt byteweise gefüttert werden, den Rest erledigt der 328p (oder was auch immer). Und 3khz interrupt load traue ich dem 328p allemal zu. Ansonsten könnte man beim Senden auch pollen - die 10 bytes oder so die maximal übertragen werden dauern 3ms. Kein Problem aber wahrscheinlich nicht notwendig da keine exzessive Interrupt load. Und Can Bus fällt auch noch weg. Wie gesagt - das ganze ist äusserst banal und simpel.
:
Bearbeitet durch User
Joe L. schrieb: > Für ein >> Cent/Pfennig hätten die auch vor 20 Jahre das Bauteil gewechselt oder >> mit nc gekennzeichnet. Ich kann nur vermuten dass es damals keine Microcontroller mit integriertem Can bus und I2C gab. Jedenfalls - wenn ich mir die Kollisionen anschaue zweifle ich doch ein bisschen an der Expertise der damaligen Entwickler. Möglicherweise ist genau das der Grund für die Aufgabe des Can Bus. Dass es keine HW gab die i2c & Can konnte und sie nicht in der Lage waren das ordentlich in SW hinzubekommen.
:
Bearbeitet durch User
Hallo, > Ich kann nur vermuten dass es damals keine Microcontroller mit > integriertem Can bus und I2C gab. suche,...so wirst Du finden und es gibt Leute in der Entwicklung die Schreiben Dir das in Maschinensprache und erst recht damals da gab es noch keine großartigen Speicher IC. Du amputierst ein System und beschwerst Dich dann über Kollisionen...? Hast schon mal überlegt ob Du ohne eine Beschreibung der HW das System verstehst. Simulieren heißt nicht vergewaltigen... > Was der BM1 ja per software bitbang > macht. Da Arduinos HW I2C haben muss nur der Buffer per interrupt > byteweise gefüttert werden, den Rest erledigt der 328p Das scheint immer in aller Munde zu sein um eine Abwertung der SW zu rechtfertigen. Sicher beim Arduino laden sich alle Register durch eine Ki. Die SW ist offengelegt. > wenn ich mir die > Kollisionen anschaue zweifle ich doch ein bisschen an der Expertise der > damaligen Entwickler. Es gibt sicher einige Unschönheiten, aber solche Aussagen sind ganz sicher nicht tragfähig...Dann müsste ich es besser können. und ich lasse mich gerne überraschen und zieh mein Hut.
Joe L. schrieb: > Peter* schrieb: >> und ich lasse mich gerne überraschen und zieh mein Hut. > > Prepare to be amazed ;-). So - den esp32 konnte ich tatsächlich ohne Pegelwandler anschliessen und er hat auch empfangen. Allerdings hat der chip i2c-slave Limitationen, die ihn für unsere Zwecke untauglich machen. Jedenfalls so der Stand nach ein paar Stunden hacken. Also hab ich den Moteino mit Pegelwandler angeschlossen und siehe da - funktioniert hervorragend. Angehängt ist ein Schreibvorgang der Therme auf 0x10 und 0x11 mit nachfolgendem Lesen. Jetzt das ganze nur noch per 433mhz network zum esp8266 gateway schicken, dort die Steuerung machen und die Soll Daten zurückschicken.
:
Bearbeitet durch User
Hallo, nun...wie immer provokant und "über selbst bewusst" und nichts ist nachvollziehbar , schade..! Joe L. > Allerdings hat der chip i2c-slave Limitationen, > die ihn für unsere Zwecke untauglich machen. Und... die sind!!! > ein paar Stunden hacken. ? Daten | im Garten Das Ausspähen von Daten ist gemäß § 202a dem deutschen Strafgesetzbuch (StGB) ein Vergehen, welches mit Freiheitsstrafe bis zu drei Jahren oder Geldstrafe bestraft wird. sorry. > Also hab ich den Moteino mit Pegelwandler angeschlossen und siehe da - > funktioniert hervorragend. Angehängt ist ein Schreibvorgang der Therme > auf 0x10 und 0x11 mit nachfolgendem Lesen. ohne SW, einfach so? Was hat denn funktioniert, der Pegel? Zitatauszug Google: "In der Kommunikationswissenschaft wird Kommunikation als der Austausch von Informationen zwischen einem Sender und einem oder mehreren Empfängern bezeichnet"... und nicht deinem Scanner an der Therme! Sorry, ich sehe hier nicht einmal... eine Vorbereitung zum Kommunikationsaustausch. Noch, die Antwort eines Empfängers wäre doch einfach gewesen. Kommuniziere doch einfach erstmal mit dem BM1, !!Achtung 5V!! ISO1540 bzw. AVUM1250 sind sowohl Pegelwandler als auch Isolatoren. Vor allem würde mich interessieren, wie das zeitliche Problem (I2C) angeblich von Dir gelöst wurde ...? besonders beim ESP.
So - ich habs jetzt komplett am Laufen. Moteino (= Arduino mit rfm69hw 433mhz transceiver) über Pegelwandler direkt am Thermenstecker. BM1 ist nicht mehr mit im Spiel. Moteino simuliert das I2C RAM und schickt die Thermeninformationen (i2c Adresse 0x20 ...) über den rfm69hw weiter. Auf der Rückrichtung schickt die Steuerung wieder über 433mhz die Solldaten zurück und der Moteino schreibt sie ins RAM (i2c Adresse 0x90 ...). Weiterhin managed der Moteino das Handshaking mit der Therme über das i2c RAM (Adressen 0x10 - 0x11). Mal sehen ob damit die AC Fehler ausgemerzt sind. Peter - sorry ich verstehe nicht ganz was Dein Problem ist. Ich hätte gedacht dass Du in der Lage bist ein i2c trace zu lesen - wo Du doch anscheinend seit Jahren da dran bist. Die Graphik zeigte einen erfolgreichen Schreib- und Lesevorgang der Therme auf den simulierten i2c Speicher. Jedenfalls wäre jetzt in Tagen erreicht, was Du hier immer als unmöglich dargestellt hast weil Du Dir jahrelang die Zähne dran ausgebissen hast. Sei es drum - schönen Abend allerseits!
Angehängt ist der Aufbau. Ignoriert das Steckbrett - das ist Teil des alten Can Bus Aufbaus. Es ist in der Tat nicht mehr als ein Arduino und ein Pegelwandler.
Peter* schrieb: >> Allerdings hat der chip i2c-slave Limitationen, >> die ihn für unsere Zwecke untauglich machen. > > Und... die sind!!! Der esp32 unterstützt kein i2c clock stretching - dh wenn er als Slave betrieben wird, kann er den Master nicht drosseln während er Daten bearbeitet. Angeblich ist das bei neueren Versionen des esp32 gelöst. Ich bin nicht ganz überzeugt, dass es nicht auch mit der ursprünglichen Version möglich ist, da ich vermute dass der Chip schnell genug ist, dass kein stretching erforderlich ist. Aber nach ein paar Stunden hatte ich keine Lust mehr - da ich sowieso den Moteino einsetzen wollte und die esp32 Arbeit nur für Dave's Projekt geplant hatte. Das nervige an den esp???? Chips ist die schlechte Dokumentation. Ein atmega 328p ist zwar Grössenordnungen langsamer - aber immerhin weiss man was man hat und die Doku ist gut. Auch mit dem Moteino hatte ich zunächst Probleme bei einem Lesevorgang, der i2c technisch durch ein Schreiben der Adresse mit folgendem Lesen der Daten realisiert wird. Beim Übergang zwischen dem Schreib- und Lesezugriff unterstützt die Therme kein Clock Stretching (genauer vor dem Start bit des Lesezugriffs). Deswegen muss ich für diesen Übergang im interrupt pollen. Wer es nochmal mit esp32 probieren möchte: beste Chance ist ohne jeglichen Fifo, so dass die Datenaufbereitung byteweise erfolgt. Und möglicherweise auch hier pollen.
Was natürlich verloren geht ist das Aussenthermometer. Aber das ist ohnehin nicht sehr wichtig für meine Anwendung. Behelfsweise ziehe ich die aktuelle Temp von openweathermap.com. Übrigens: die Therme weiss nichts von der aktuellen Zeit. Und die Aussentemperatur bekommt sie nur in ganzen C übermittelt. Soviel zum Thema die Therme steuert und die TA??? sind nur "Fernbedienungen".
Hallo, Nun.. keine Zähne verloren, ich kann Dich beruhigen. Vielleicht bleibst Du einfach mal bei der Wahrheit in allen Bezügen. Wer bitte wird das hier nachbauen wollen, mehr Bauteile als vorher, wenn es funktionieren würde. Danke
Joe L. schrieb: > Mal sehen ob damit die AC Fehler ausgemerzt sind. Erste Nacht ohne jegliche Datenprobleme! Es scheint gelöst. Ich hänge mal den source an falls jemand das auch probieren möchte. twi* sind aus der Wire library - modifiziert für das schnellere Timing und direktes Lesen/Schreiben ins RAM ohne callback. junkers.cpp hat die Logik - 182 Zeilen also waren 50 doch etwas untertrieben. Die Radio calls müssen natürlich ersetzt werden - zb. mit Serial. Esp32 + Arduino + Pegelwandler wäre ein Ansatz, die Klippen des esp32 i2c zu umschiffen. Schönen Sonntag!
Joe L. schrieb: > 182 Zeilen also waren 50 doch etwas untertrieben Es sind allerdings ein paar Zeilen Tiefpassfilter zum säubern der sehr verrauschten Daten aus der Therme drin:
1 | static uint16_t vlTempX; |
2 | static uint16_t wwTempX; |
3 | if (!vlTempX) vlTempX = pBoiler->vlTemp2 << 5; |
4 | if (!wwTempX) wwTempX = pBoiler->wwTemp2 << 9; |
5 | vlTempX -= (vlTempX + 16) >> 5; |
6 | vlTempX += pBoiler->vlTemp2; |
7 | wwTempX -= (wwTempX + 256) >> 9; |
8 | wwTempX += pBoiler->wwTemp2; |
9 | avgBoilerState = *pBoiler; |
10 | avgBoilerState.vlTemp2 = (vlTempX + 16) >> 5; |
11 | avgBoilerState.wwTemp2 = (wwTempX + 256) >> 9; |
Also eher 171 Zeilen. Jedenfalls bis auf die kleine Timingproblematik wie vorhergesehen ein banales Projekt.
Peter* schrieb: > Vielleicht bleibst Du einfach mal bei der Wahrheit in allen Bezügen. > > Wer bitte wird das hier nachbauen wollen, mehr Bauteile als vorher, wenn > es funktionieren würde. Darf ich Dich daran erinnern, dass dieser Ansatz genau Dein Ziel war? Bauteile: 1 Moteino für ca 12 Euro und ein Pegelwandler (https://www.amazon.de/dp/B082F6BSB5?psc=1&ref=ppx_yo2ov_dt_b_product_details) für 50c. Statt ein unzuverlässiger BM1 für > 100 Euro, ein CAN Bus Adapter und jede Menge Kopfschmerzen wegen Kommunikationsproblemen. Wenn jemand sich die Zeit nimmt, das auf dem esp32 zum laufen zu bringen, braucht man nur noch den, da er bei Open Drain Konfiguration 5v tolerant ist.
Joe L. schrieb: > Darf ich Dich daran erinnern, dass dieser Ansatz genau Dein Ziel war? Übrigens: Credit where credit is due, Peter ohne Deine Pionierarbeit bei der Analyse der Funktionsweise des BM1 und insbesondere der Nutzung eines geteilten i2c Rams wäre ich nie auf die Idee gekommen, das zu implementieren. Danke für Deine Arbeit!
Hier die fertige Montage klein und fein. Btw - nicht so stark auf das Plastik drücken. Unglaublich wie spröde das wird nach ein paar Jahrzehnten.
Angehängt ein Mitschnitt der Kommunikation zwischen Boiler und Steuerung. Eine ganze Menge habe ich noch nicht entschlüsselt. Das 8. und die letzten beiden Bytes des Boilers (0x20 ...) enthalten Flags, die sich verändern, wenn der Brenner startet oder stoppt. Im vorletzten Byte kann man zb beim Zünden sehen, wie einzelne bits nacheinander angehen. Ich vermute, dass man da noch Details wie Lüften, Zündung und evtl Zustand 3 Wege Ventil auslesen kann. Die beiden 0xff am Anfang und Ende des Controller Pakets (0x90 ...) könnten den angeforderten Leistungslevel des Brenners bedeuten. Ich habe meine Therme auf das Minimum (ca 10kw) fürs Heizen beschränkt, da das auch bei -10 Grad mehr als genug ist. Warmwasser ist anders - wir haben einen Speicher so dass auch niedrigere Leistungen zum Duschen möglich wären. Zum Baden braucht man aber 100%. 50% Leistung sind deutlich effizienter als 100% zum Heizen. Zum Warmwasser bin ich mir allerdings nicht sicher, weil der Wärmetauscher viel besser bei hohen Temperaturen funktioniert. Ich habe die 18-5 mit Warmwasserspeicher. Die Thermen mit Durchlauferhitzer benutzen scheinbar die bytes 3 und 4 des Boilers für max und ist Durchlauferhitzertemperatur. Mir ist noch nicht ganz klar, wie die Steuerung herausbekommt um welches System es sich handelt. Als es noch zu Überschreibungen des RAMs durch nicht erkannte Lese/Schreibübergänge kam habe ich gesehen, dass die Therme dann anfing statt auf 0x20 ... auf 0x30 ... und 0x40 ... zu schreiben. Da hat sich wohl der Kaskadenmodus ausgelöst.
Hallo, bin kein Sw_Werker, so das ich deine SW sofort verstehe noch möchte ich mich auf ein anderes System einschießen. Zumal ich den Speicher belassen möchte. Deshalb passe ich erstmal, da mir einfach die Zeit in diesem Monat ganz sicher fehlt. Was mir allerdings auffiel ist die fehlende CAN-Bus_karte BM1, na klar. Was wird denn als Gerät eingetragen, zu mal TA211 kein I2C mehr ist und die 5V evtl. auch als Kennung benutzt wird. ohne Gerät? > 50% Leistung sind deutlich effizienter als 100% zum Heizen.... Der Wärmetauscher verkalkt mit der Zeit und muss gereinigt oder ersetzt werden. > Ich habe die 18-5 mit Warmwasserspeicher Der Aufbau ist doch anders, zu mindestens bei mir.(SW) > dass die Therme dann anfing > statt auf 0x20 ... auf 0x30 ... und 0x40 ... zu schreiben. > Kaskadenmodus? Ähnliches Verhalten habe ich beim Schreibtischtest BM1/TA250 festgestellt? Dann müssten auch die Adresse 90 schwimmen. Glaube eher das hier der regelmäßige Handshake evtl. nicht stimmt.10/11 Datenmitschnitt, ungeachtet des Inhaltes herrscht hier eine sehr große Unregelmäßigkeit?
Peter* schrieb: > Was mir allerdings auffiel ist die fehlende CAN-Bus_karte BM1, na klar. > Was wird denn als Gerät eingetragen, zu mal TA211 kein I2C mehr ist und > die 5V evtl. auch als Kennung benutzt wird. ohne Gerät? Wenn die Therme anspringt dann probed sie auf den i2c Leitungen rum - erst versucht sie 0x48, dann 0x50. Und so wie sie da einen Speicher findet, der auf 0xfe - 0xff die richtigen Daten hat versucht sie den Handshake zu beginnen. Dann denkt die Therme sie hätte einen BM1 - auch wenn es statt dessen der Moteino ist. Peter* schrieb: > Datenmitschnitt, ungeachtet des Inhaltes herrscht hier eine sehr große > Unregelmäßigkeit? Ja - deswegen auch das Filtern: ich möchte nicht alle 200ms ein Paket senden, sondern nur wenn sich die Daten ändern. Also filtere ich die verrauschten Daten und sende nur wenn sich etwas ändert aber mindestens alle 30s. Die Unregelmässigkeit wird durch den schnellen Abfall des Vorlaufs nach ausschalten des Brenners verursacht (= häufige Pakete). Übrigens habe ich gerade gemerkt dass der Moteino sogar mit 8mhz statt der üblichen 16mhz läuft. Man braucht wirklich nicht viel CPU um den i2c bus zu bedienen - jedenfalls mit clock stretching.
Thorsten L. schrieb: > Ich vermute, dass man da noch Details wie Lüften, Zündung und evtl > Zustand 3 Wege Ventil auslesen kann.
1 | 19:09:40 - junkers/remote: FF 28 000100010000000000000000FF00 // VL Soll 20C |
2 | 19:10:14 - junkers/boiler: 8C3E7400784400 28 01 00 01 42 07 // VL Soll 20C |
3 | 19:10:31 - junkers/remote: FF B4 000100010000000000000000FF00 // VL Soll 90C |
4 | 19:10:32 - junkers/boiler: 8C3E7400784400 8C 01 00 01 42 07 // VL Soll 70C (8C) nach Max VL Limitierung |
5 | 19:10:32 - junkers/boiler: 8C3E7400784400 8C 01 00 01 62 07 // Gas? |
6 | 19:10:32 - junkers/boiler: 8C3E7400784400 8C 01 00 01 63 07 // Zündung? |
7 | 19:10:36 - junkers/boiler: 8C3E7400784400 8C 01 01 01 63 0F // Flamme |
Hier ist diese Sequenz. Habe jetzt das 8. Byte raus - das ist VL Soll von der Therme zurückgeliefert nach Begrenzung auf das eingestellte Maximum. Danach gibt es 3 Schritte bis die Flamme brennt. Was immer die sein mögen.
:
Bearbeitet durch User
https://github.com/Winkelkatze/ESP32-Bare-Metal-AppCPU Eine Core nur für i2c reservieren und dort die i2c Interrupt flags pollen statt mit der miserablen interrupt latency des standard frameworks zu arbeiten. Das könnte der 2x 240 MHz Core CPU helfen es mit einem alten atmega328p als i2c slave aufzunehmen.
So - also für mich sind mit dem i2c RAM Simulator tatsächlich alle Probleme behoben. Zur Feier des Tages habe ich mal eine schönere Graphik mit Legenden angefertigt (Anhang). Es gibt keine Spikes mehr und keine Fehler AC. Die Steuerung fährt manuell das Takten der Therme indem sie den Boiler durch Anforderung einer Vorlauftemperatur von 90 bzw. 20 Grad an- bzw. ausschaltet. Dabei wird auf eine Abweichung der gefühlten Temperatur von +- 0.15 C gegenüber der Solltemperatur von 19 C hingesteuert um die Taktfrequenz und damit die Auskühlungsverluste zu senken. Die Warmwasserbereitung wird ebenfalls manuell gesteuert: tagsüber wird die Temperatur um die 37 Grad gehalten. Dusch-/Badetemperaturen müssen über Handy angefordert werden. Weicht die Wassertemperatur nicht zu stark von der gewünschten Temperatur ab, so erfolgt die Erwärmung direkt um Anschluss an einen Heiztakt ohne die Flamme erlöschen zu lassen. Ebenso wird nach jeder Warmwasserbereitung ein Heiztakt gefahren. Diese Massnahmen dienen der Minimierung der Auskühlzeiten des Kessels. Ein Problem des Algorithmus ist, dass die Heizvorlauftemperatur während einer Warmwasserbereitung nicht gemessen werden kann. Hier wird die integrative Komponente der Steuerung pausiert, was zu Ungenauigkeiten führt. Das werde ich in Zukunft durch eine Modellierung der Vorlauftemperatur während der Warmwasserbereitung lösen. Insgesamt bin ich jetzt ziemlich zufrieden mit dem System. Nächster Schritt: Einbindung der digitalen Thermostate und automatische Übernahme der Vorlauftemperatursteuerung vom Raum mit dem derzeit höchsten Heizbedarf. Dabei soll auch der hydraulische Abgleich komplett aus dem Heizsystem genommen werden und durch einen dynamischen hydraulischen Abgleich mithilfe der digitalen Thermostate ersetzt werden. Leider kann die Heizleistung meiner Therme nicht direkt über i2c gesteuert werden. Das wäre von Vorteil für Schnellaufheizung selten genutzter Räume. Vielleicht ist das aber über die Sollvorlauftemperatur machbar.
H.Joachim S. schrieb: > Das Peterle eiert ja immer noch hier rum :-) Sonst leider wohl keiner mehr :). Naja die Thermen sind auch uralt. Das Plastik zerfällt zu Staub wenn man mal stärker drauf drückt.
Hallo, oh Mann..., das verrückte Pferd, wie eh.. und jeh.., ohne soziale Kompetenz. @Thorsten L. > Plastik zerfällt zu Staub kann ich nicht bestätigen. > keine > Fehler AC. du hast doch auch kein Gerät angeschlossen, oder ist im Service ein Gerät eingetragen. Übrigens, bitte nachlesen, in Deutschland nicht zulässig. > Dabei soll auch der hydraulische Abgleich komplett aus dem > Heizsystem genommen werden und durch einen dynamischen hydraulischen > Abgleich mithilfe der digitalen Thermostate ersetzt werden. Das, mit dem Hydraulischen Abgleich würde ich mir nochmals durchlesen. > Leider kann die Heizleistung meiner Therme nicht direkt über i2c > gesteuert werden. Du musst auch die Neugier entwickeln, diese Möglichkeit zu finden. Du hast die Adresse 0x48 gefunden, was steht da hinter??? Ein Textdisplay hat die Möglichkeit den Service einzustellen!!! Es hat die I2C Adresse 0x51 und hat ein doppelt so großen Speicher. !! Kennt deine Therme diese Adresse??? "Es gibt keine direkte Beschreibung des Textdisplay's, --->in Therme mit Display"
Peter* schrieb: >> keine >> Fehler AC. > > du hast doch auch kein Gerät angeschlossen, oder ist im Service ein > Gerät eingetragen. > > Übrigens, bitte nachlesen, in Deutschland nicht zulässig. Häh? Mein Problem war doch dass ich periodisch diese Fehler AC mit VL Temp Spikes bekam wenn ich die Therme per CAN Bus gesteuert habe. Die 18-5 kann einfach nicht zuverlässig mit meiner BM Version. Das ist jetzt gelöst mit dem I2C Ansatz. Peter* schrieb: > Das, mit dem Hydraulischen Abgleich würde ich mir nochmals durchlesen. Nee - das Konzept ist schon hinreichend bekannt. Der statische hydraulische Abgleich stellt ja die Durchflussmengen so ein, dass bei maximaler Heizlast alle Zimmer genau die Wassermengen bekommen, die die Zielzimmertemperatur herstellt. Das ist aber nicht das beste für den allgemeinen Fall. Sagen wir alle Zimmer sind abgeregelt und ich will nur mein Arbeitszimmer warm bekommen. Dann möchte ich den maximalen Wassertransport durch die Heizung dort damit die Therme ihre Wärme los wird (Stichwort Kuhschwanzheizung). Also muss die Drosselung überall raus und statt dessen über die Ventile gemacht werden. Peter* schrieb: > Du musst auch die Neugier entwickeln, diese Möglichkeit zu finden. > Du hast die Adresse 0x48 gefunden, was steht da hinter??? > > Ein Textdisplay hat die Möglichkeit den Service einzustellen!!! > Es hat die I2C Adresse 0x51 und hat ein doppelt so großen Speicher. > !! Kennt deine Therme diese Adresse??? Ich habe nur die i2c ram addressen 0x90 und 0x9e versucht. Die haben normalerweise 0xff und scheinen deshalb prädestiniert die Leistung zu übermitteln. Aber damit kann ich die Therme nicht regeln. 0x51 fordert meine Therme nicht an. 0x48 könnte natürlich was sein - aber ohne das Protokoll belauschen zu können habe ich da keine Chance.
Hallo, es ist schon lange her das ich mich mit dem Hydraulischen Abgleich auseinandergesetzt habe und zwar bei der Plan meiner Heizung. Bei Inbetriebnahme brauchte ich keinen Heizkörper drosseln und zwar habe ich 4 Stränge die alle druckgesteuert werden und bis heute fehlerfrei trotz Junkers Uraltpumpe funktionieren. > Nee - das Konzept ist schon hinreichend bekannt. Der statische > hydraulische Abgleich stellt ja die Durchflussmengen so ein, dass bei > maximaler Heizlast alle Zimmer genau die Wassermengen bekommen, die die > Zielzimmertemperatur herstellt. Nein, Zielzimmer (?)... woher kommt das denn, es muss heißen, die der einzelne Raum benötigt. Hier steht das Gesamtobjekt im Mittelpunkt. > Das ist aber nicht das beste für den allgemeinen Fall. Sagen wir alle > Zimmer sind abgeregelt und ich will nur mein Arbeitszimmer warm > bekommen. Wenn der Abgleich richtig durchgeführt wurde wird dieser Raum warm, das ist doch das Paradebeispiel des Abgleichs. Aber,... deine alte Heizungspumpe wird Dir evtl. den Strich durch die Rechnung machen, weil sie damit nicht klar kommt. Habe ich schon mal erwähnt.., es wird (es muss) eine Hocheffiziente Pumpe (300+) eingebaut werden, im Fehlerfall. Seit bei mir e_Ventile in den Heizkörpern verbaut sind findet auch bei mir eine ständige Taktung statt. Sowas kann man nur lösen mit Wassermenge und Mischkreis. Die VL Temperatur soweit herunterfahren, das das Ventil die eingestellte Temperatur nie erreicht und somit nie schließt ist doch nicht zielführend. Aber das haben wir schon mal durchgekaut. Zurück auf die Heizleistung, natürlich ist hiermit die max. Heizleistung gemeint und nicht Möglichkeit Einflussnahme auf die Regelung der Leistung zu nehmen (PWM). gottseidank Bei 10kW ist das nicht mehr FF, sondern evtl. max
Peter* schrieb: > Seit bei mir e_Ventile in den Heizkörpern verbaut sind findet auch bei > mir eine ständige Taktung statt. Sowas kann man nur lösen mit > Wassermenge und Mischkreis. Ja das ist doch der Punkt. Du willst die Wassermenge bei Betrieb nur einer Heizung in einem Raum nicht auf das gleich Mass beschränken, was nötig ist um gleichmässige Erwärmung aller Zimmer beim Betrieb aller Heizungen zu erreichen. Und mit digitalen Ventilen kann man das eben prinzipiell situationsabhängig steuern.
Hallo, doch,.. wo liegt das Problem, meinen Heizungkörper eine halbstunde vorher zu starten. Es können mehrere m3/h Heizungswasser fließen. Ich sehe nur meine Heizung, die Wassermenge ist der Pufferspeicher. Hiermit ist der kontinuierliche betrieb der Heizung gewährleistet und nicht das Takten. Das Mischen ist losgelöst vom erzeugen der Wärme. Je nach Größe des Puffers ist die Heizung dann 2mal in 24Stunden aktiv.~ Das ist kein Abgleich, sondern Du steuerst das Wasser in den Rohrleitungen. Der Hydraulische Abgleich ist der Versuch, der in Waage setzen.
Peter* schrieb: > Ich sehe nur meine Heizung, die Wassermenge ist der Pufferspeicher. > Hiermit ist der kontinuierliche betrieb der Heizung gewährleistet und > nicht das Takten. Das Mischen ist losgelöst vom erzeugen der Wärme. Je > nach Größe des Puffers ist die Heizung dann 2mal in 24Stunden aktiv.~ Klar ein Pufferspeicher hilft - hat aber den Nachteil dass Du Auskühlverluste hast. Und das viele keinen haben. Wenn ich meinen Warmwasserspeicher auf 60 C stelle statt auf 37 C ist es im Bad (wo der steht) schön warm aber das kostet mich ca 12 kWh am Tag. Die Frage ist was ist der beste Ansatz, wenn man wie viele keinen Speicher aber eine überdimensionierte Therme hat. Und ich denke die Lösung ist ein dynamischer hydraulischer Abgleich: so dass zum aktuellen Moment zum einen alle Zimmer die Wärmemenge bekommen, die sie gerade brauchen. Und das zweitens der Volumenstrom durch alle Heizungen bei Einhaltung dieses Gleichgewichts maximiert wird, so dass die Vorlauftemperatur und die Taktfrequenz minimiert werden kann. Unter diesen Umständen kann die Heizung dann mit niedriger Frequenz Takten und die Heizungsventile brauchen während des Taktes nicht verstellt zu werden. Meine Heizung taktet zur Zeit ungefähr 1x pro Stunde mit meiner raumgesteuerten Regelung. Peter* schrieb: > Das ist kein Abgleich, sondern Du steuerst das Wasser in den > Rohrleitungen. Der Hydraulische Abgleich ist der Versuch, der in Waage > setzen. Doch - es ist ein dynamischer Abgleich: die Waage halten unter den zur Zeit bestehenden Bedingungen.
Hallo, Thorsten L > Klar ein Pufferspeicher hilft... ja, der Wärmeverlust [Energieeffizienz A...D] ist ein Thema des Geldbeutels und der Größe, aber bei weitem kein Grund der Ablehnung. Außerdem die Möglichkeit der Hybridheizung und die [wird] kommt ja. > 60 C stelle statt auf 37 C... es ist eine Einstellungssache [ECO...gewollte Hysterese] oder ein Sensorfehler > schön warm aber das kostet mich ca 12 kWh am Tag... Hoffe nicht der Verlust und Du kannst auch kalt duschen, baden... dann weißt Du was 12KW wert sind.:-). Wärme...Verluste hast Du dadurch nicht, warme Luft im Bad ist immer gut für eine hohe Aufnahme von Feuchtigkeit [sonst Betauung], Lüften weg. 12KW ~1m3/24h Gas. Wir 120l Sommer 0,3 bis 0,5m3, Winter 0,7 bis 1m3, natürlich abhängig von der Wassermenge.[->Wärmerechner] > eine überdimensionierte Therme hat... Das ist das eigentliche Problem der alten Heizungen 10Kw ist bei mir Schluss. Ab da wird der Siphon ständige bewässert.--> also Pufferspeicher und dann aus. Auch in Wohnungen möglich. > dynamischer hydraulischer Abgleich... nun vielleicht nochmals wiki durchlesen. Was machst Du, wenn alle Heizkörper fordern? Dann ist dein System nicht abglichen! Wenn Räume Temperaturregelung benötigen. Dein Heizkörperventil ist doppelt belegt und woher bekommst du die Hydraulischen Werte zum Einstellen des Ventils. Hier geht es um Drücke Volumenströme und um Temperatur.
Peter* schrieb: >> 60 C stelle statt auf 37 C... > > es ist eine Einstellungssache [ECO...gewollte Hysterese] oder ein > Sensorfehler > >> schön warm aber das kostet mich ca 12 kWh am Tag... > > Hoffe nicht der Verlust und Du kannst auch kalt duschen, baden... dann > weißt Du was 12KW wert sind.:-). Wärme...Verluste hast Du dadurch nicht, > warme Luft im Bad ist immer gut für eine hohe Aufnahme von Feuchtigkeit > [sonst Betauung], Lüften weg. 12KW ~1m3/24h Gas. Wir 120l Sommer 0,3 bis > 0,5m3, Winter 0,7 bis 1m3, natürlich abhängig von der > Wassermenge.[->Wärmerechner] Na klar sind das Verluste. Mein Bad muss nicht den ganzen Tag >23 C warm sein. Und im Winter habe ich insgesamt eher zu wenig als zu viel Luftfeuchtigkeit. Schau Dir den unteren Chart in der angehängten Graphik an - da kannst Du sehen wie schnell der Speicher auskühlt. Bei 60 C noch viel schneller. > nun vielleicht nochmals wiki durchlesen. Was machst Du, wenn alle > Heizkörper fordern? Dann ist dein System nicht abglichen! Wenn Räume > Temperaturregelung benötigen. Dein Heizkörperventil ist doppelt belegt > und woher bekommst du die Hydraulischen Werte zum Einstellen des > Ventils. Hier geht es um Drücke Volumenströme und um Temperatur. Irgendwie geht Dir scheinbar der Wille zum lesen/verstehen ab. Der Wärmebedarf in unterschiedlichen Zimmern ist nicht immer relativ konstant - deswegen ist ein statischer Abgleich nicht optimal. Andere sind auch schon auf die Idee gekommen. Lies Dir vielleicht mal https://www.danfoss.com/de-de/markets/buildings-commercial/dhs/hydronic-balancing-and-control/hydronic-balancing-static-dynamic-automatic/#tab-automatic durch.
Peter* schrieb: > Hoffe nicht der Verlust Schau es Dir an. Das war der WW Verbrauch mit ww setpoint auf 60 C: 23-01-08, 30.89 23-01-09, 23.47 23-01-10, 46.38 23-01-11, 28.23 23-01-12, 43.25 23-01-13, 36.54 Angaben in kw. Hier ist mit ww setpoint auf 37 C und 45 C on demand zum Duschen, 60 C zum baden: 23-03-04, 34.30 23-03-05, 9.43 23-03-06, 10.15 23-03-07, 14.45 23-03-08, 10.98 Der Unterschied ist schon frappierend.
:
Bearbeitet durch User
Hallo,
nun, das die Heizung und der WW_Behälter nicht nur sehr teuer waren als
auch schlecht isoliert waren bzw. sind, brauchen wir nicht zu
diskutieren. Da stimme ich Dir voll zu.
> Irgendwie geht Dir scheinbar der Wille zum lesen/verstehen ab.
Ach...,
sorry, aber Blödsinn... "statischer" Abgleich mal weiterdenken und
suchen.
meine Heizung ist 15+Jahre alt und ich habe von Danfoss das damalige
"automatische" Strangregulierungssystem (diff-druck) eingebaut und
eingestellt. Wenn Du mal etwas mehr lesen würdest außer die Werbung über
das neue System, in dem alle anderen Systeme schlecht ja sogar falsch
beschrieben werden. Dann würdest Du, die Beurteilung meines
Nachfolge_Systems (gleicher Aufbau) finden mit "ausgezeichnet" und Du
würdest auch finden den Hinweis das dein bevorzugtes System nicht ohne
herkömmlichen Abgleich betrieb werden sollte und schaffe Dir alles
Pumpen mit Kommunikation und Sensoren an, die Dir die Daten senden.
Ich muss es wohl gelesen als auch verstanden haben!!
Ist auch egal - so werde ich es jedenfalls machen und die Ergebnisse werden dann wie bisher für sich sprechen.
Hallo, wenn deine Heizung so unwirtschaftlich ist, vielleicht solltest Du eher versuchen eine neuere Heizung (gebraucht) zu bekommen, die die Leistungs_Modellierung auf 2-3 kW beherrscht. Statt viel Geld in eine neue Pumpe z.B.: zu investieren die Junkers nicht gestattet usw. Aber Du hast recht, ist egal.
Peter* schrieb: > wenn deine Heizung so unwirtschaftlich ist Die Therme ist super und nicht unwirtschaftlich. Habe gar keine Probleme damit. Klar könnte ich evtl ein paar Prozent mit einer stärker modulierenden sparen. Aber ich miete und allein die Einbaukosten wären immens. Nee - es ist ideal: ich habe Probleme, die ein grosser Anteil von Leuten mit älteren (und auch teilweise neueren) Thermen haben. Neue Thermen dürfen bald nicht mehr eingebaut werden. Die Probleme lassen sich mit Software weitgehend lösen -> also für viele Leute interessant. Wenn's so gut wird wie ich denke, gibts also auch einen Markt dafür, falls ich darauf Lust hab. Übrigens: Wochenendhütte mit ATAG 5000 HR genau das gleiche Problem. Megaüberdimensioniert und taktet wie verrückt. 20kw und moduliert runter auf 6 meine ich. Aber startet immer auf voller Leistung und regelt dann runter - bei hohen Aussentemp zu spät und die Takte sind keine Minute lang. Die ist als nächstes dran.
Hallo, > Aber startet immer auf voller Leistung und regelt dann > runter Ob es die volle Leistung ist, ist mir nicht bekannt, aber das Vorgehen ist durch aus logisch, um eine sichere Zündung zu gewährleisten. > Neue Thermen > dürfen bald nicht mehr eingebaut werden Aber noch!, deshalb der Hinweis... und die Preise werden auch bei Klein... fallen. Ein Ventil aus Systemdaten zusteuern sagt nichts über die machbare Funktionsweise aus. Ich sehe aber schon ein Problem, die Batteriesteuerung. Die können gar nicht jede Betriebsänderung mit machen. Einmal im Monat Batteriewechsel? Es gab auch mal, vor Jahren eine Zukunftsplanung, die besagte das sich jeder Raum die erforderlich Wärme durch Kleinpumpen sich selbst holt. Nie wieder davon was gehört. Das wird auch nicht mein Thema.
Thorsten L. schrieb: > H.Joachim S. schrieb: >> Das Peterle eiert ja immer noch hier rum :-) > > Sonst leider wohl keiner mehr :). Doch doch, ich lese hier immer mal wieder interessiert mit, und die Therme via i2c anzusteuern klingt sehr interessant, v.a. nachdem es mit der (sw-) CAN-Lösung hakt, und ich sowieso vor dem "Problem" stehe, dass die Gesamtheizungsanlage demnächst noch ein paar Komponenten mehr hat wie nur die Therme (Pufferspeicher+Solarthermie, zwei Wärmetauscher für WW+Heizungsunterstützung und so weiter...). Dauert nur noch etwas, bis ich dazu kommen werde, das intensiver zu beleuchten!
Hallo, I2C ist eine Kommunikation über kurze Distanz. Über längere Distanz ist der Can-Bus um vieles besser. HSM und HMM haben kein I2C, sind also nur über Can-Bus ansteuerbar. Ein System mit Pufferspeicher usw. mit I2C ist wohl ~ eher nicht umsetzbar, noch zweckmäßig. Hier steht wohl noch die Suche nach dem direkten Einstieg ohne überschreiben der CAN-Bus Befehle im Vordergrund. Man muss schon nicht mehr Heizungsanlage sagen sondern Hausanlage. Inzwischen kommt bei mir sogar ein Pufferspeicher außerhalb des Hauses in Frage. Viel Arbeit und wenig Zeit.
Peter* schrieb: > Ein Ventil aus Systemdaten zusteuern sagt nichts über die machbare > Funktionsweise aus. Ich sehe aber schon ein Problem, die > Batteriesteuerung. Die können gar nicht jede Betriebsänderung mit > machen. Einmal im Monat Batteriewechsel? Na die hr20 stellen sich doch sowieso ständig aktiv ein. Batterielaufzeit soll trotzdem > 1 Jahr sein. Und mit dynamischem Abgleich wird es weniger: während des Taktens müssen die Ventile dann nicht geregelt werden - es sei denn der relative Wärmebedarf ändert sich. Hab noch ein neues Feature: Abschalten der Pumpe während der Brenner aus ist. Siehe Anhang. Das wird vor allem in der Übergangszeit was bringen wenn die Takte längere Auszeiten haben.
Peter* schrieb: > HSM und HMM haben kein I2C, sind also nur über Can-Bus ansteuerbar. Ein > System mit Pufferspeicher usw. mit I2C ist wohl ~ eher nicht umsetzbar, > noch zweckmäßig. Richtig. Wenn andere Can Bus Teilnehmer mitspielen wird der Can Bus benötigt. Man könnte trotzdem den BM1 ersetzen und i2c mit der Therme sprechen solange man zusätzlich ein Can Bus Modul am Mikrocontroller für Kommunikation mit der Peripherie hat. Aber dann ist es nicht mehr so schön simpel.
Peter* schrieb: > ja, der Wärmeverlust [Energieeffizienz A...D] ist ein Thema des > Geldbeutels und der Größe, aber bei weitem kein Grund der Ablehnung. Hast Du mal gemessen, wie gross die Bereitschaftsverluste Deines Speichers sind? Für die Wirtschaftlichkeit müsste man diese ja dem Auskühlverlust der Therme beim Takten gegenüberstellen (jedenfalls wenn der Speicher nicht sowieso zum Hybridheizen gebraucht wird). Mein WW Speicher verliert schon sehr viel. Vielleicht sollte ich da mal bessere Isolierung anbringen. Jetzt im Winter mit der Bedarfsanforderung ist es kein Problem, da der Speicher einfach das Bad heizt. Aber im Sommer ist das reine Verschwendung.
:
Bearbeitet durch User
Btw was ich in diesem Zusammenhang richtig cool finde ist http://www.rio12.com/rio9/programme/Book_of_Proceedings/9_ST_Buchholz.pdf. Mit chemischer Wärmespeicherung könnte man sogar Solarenergie vom Sommer in den Winter transportieren - ohne Verluste. Und die Freigabe der Wärme bindet Feuchtigkeit. Dh ideal um im Winter die Wochenendhütte vor Einfrieren und Schimmel in einem schützen.
Hallo, > Na die hr20 stellen sich doch sowieso ständig aktiv ein. > Batterielaufzeit soll trotzdem > 1 Jahr sein. Und mit dynamischem > Abgleich wird es weniger: während des Taktens müssen die Ventile dann > nicht geregelt werden - es sei denn der relative Wärmebedarf ändert > sich. Was ist denn HR20, nicht etwa der von Honeywell. Habe hier noch 5x HR40, nie eingebaut. Warum, weil sie die Temperatur (am | in der Nähe des Heizkörper) messen bzw. !sogar! über separates Messkabel (opt.) messen konnten. Habe mich damals, weil günstig (gleichen Preis HR40) für die von ELV / Conrad bzw. schließlich von Lifetec entschieden. Steuergerät/e-Ventil/Fenstersignal (20Euro) 868 MHz. heute Standard. Steuereinheit sendet alle 2 Minuten die Sollöffnung, aber bevor der Motor angesteuert wird vergehen (Diagramm 5->8%) z.B: 90min) natürlich je nach Temperatur und Raum (kältest beheizte Raum). Da ist nichts ständig aktiv!! > Abschalten der Pumpe während der Brenner aus > ist. Ja und... dein ganze System steht, die Zeit der Schwerkraftheizung kommt vielleicht wieder aber so nicht. Vielleicht sogar als grobfahrlässig einzustufen bei Schaden an der Heizung. -->Bosch/Junkers > Man könnte trotzdem den BM1 ersetzen und i2c mit der Therme > sprechen solange man zusätzlich ein Can Bus Modul am Mikrocontroller für > Kommunikation mit der Peripherie hat. Peter* > eher nicht umsetzbar, > noch zweckmäßig. > Hast Du mal gemessen, wie groß die Bereitschaftsverluste Deines > Speichers sind? Für die Wirtschaftlichkeit müsste man diese ja dem > Auskühlverlust der Therme beim Takten gegenüberstellen (jedenfalls wenn > der Speicher nicht sowieso zum Hybridheizen gebraucht wird). Nun, erstmal ist das eine Planung, ich hoffe dies in diesem Jahr umsetzen zu können. (Preis, Lieferzeiten sehen aber hier sehr schlecht aus.) Aber selbstverständlich, es kommt auf die Größe der Einheiten und die Isolierung an. Ein Beispiel Energie[B] 1000L ~90W/h; 300L [A] ~40-50W/h Das brauche ich nicht gegenüberstellen, ich weis es einfach das es anders unwirtschaftlich ist!! Es ist E-Solar als auch Wärmepumpe ... bzw. Hybrid in Zukunft geplant. > Mit chemischer Wärmespeicherung könnte man sogar Solarenergie vom Sommer > in den Winter transportieren - ohne Verluste Sicher..., wer es glaubt ohne Verlust.... Es werden schon riesige Wasserspeicher gebaut die ähnlich genutzt werden sollen. Es sollte auch mal eine Pipeline mit Flüssigkeit Metall errichtet werden...um Energie zu transportieren. Kann ich alles nicht nutzen, habe Strom 49 Cent/kW und Gas 19,15 Cent/KW.
> Was ist denn HR20, nicht etwa der von Honeywell. Habe hier noch 5x HR40, > nie eingebaut. Warum, weil sie die Temperatur (am | in der Nähe des > Heizkörper) messen bzw. !sogar! über separates Messkabel (opt.) messen > konnten. Genau die von Honeywell ja. Und zwar hauptsächlich weil die bereits komplett reverse engineered sind (https://github.com/OpenHR20/OpenHR20). Wie gesagt habe ich schon ein selbst entwickeltes Home automation System basierend auf dem atmega 328p mit rfm69 Radio. Komplett mit Wireless bootloader usw. Die hr20 benutzen den atmega 169p - da kommt dann ein rfm69 ran und ich kann dann meine Infrastruktur nutzen - wie auch schon beim BM1 Ersatz. Deswegen geht das dann bei mir alles so schnell. Natürlich bekommt jeder größere Raum zwei Thermometer: eins für Lufttemp und eins für Strahlungstemp. Aber auch die eingebauten Thermometer funktionieren nicht schlecht - die Arbeiten mit einem Offset um die Nähe zum Heizkörper auszugleichen. > > Habe mich damals, weil günstig (gleichen Preis HR40) für die von ELV / > Conrad bzw. schließlich von Lifetec entschieden. > Steuergerät/e-Ventil/Fenstersignal (20Euro) 868 MHz. heute Standard. > Steuereinheit sendet alle 2 Minuten die Sollöffnung, aber bevor der > Motor angesteuert wird vergehen (Diagramm 5->8%) z.B: 90min) natürlich > je nach Temperatur und Raum (kältest beheizte Raum). > > Da ist nichts ständig aktiv!! Genauso wird es bei mir auch funktionieren - aber besser: ich kenne ja die Vorlauftemperatur und das Taktverhalten und kann deswegen viel besser ansteuern. In meiner jetzigen Steuerung folgt die Lufttemperatur der Vorlauftemperatur mit vielleicht 4 Minuten Verzögerung. Es ist also viel zu spät wenn man es daran festmacht. > >> Abschalten der Pumpe während der Brenner aus >> ist. > > Ja und... dein ganze System steht, die Zeit der Schwerkraftheizung kommt > vielleicht wieder aber so nicht. Vielleicht sogar als grobfahrlässig > einzustufen bei Schaden an der Heizung. -->Bosch/Junkers Nee - ich zirkuliere noch 5 min nach dem ausschalten und hab dann 6 Minuten aus, 3 an usw. Das machen einige kommerzielle Regelungen auch so. Das ist schon ok. Stelle es Dir einfach wie eine geregelte Pumpe vor und sei nicht immer so negativ. > >> Man könnte trotzdem den BM1 ersetzen und i2c mit der Therme >> sprechen solange man zusätzlich ein Can Bus Modul am Mikrocontroller für >> Kommunikation mit der Peripherie hat. > > Peter* >> eher nicht umsetzbar, >> noch zweckmäßig. Umsetzbar: absolut ja. Zweckmäßig? Hängt eben davon ab ob der BM1 korrekt mit der eigenen Therme funktioniert. Bei mir war das nicht der Fall deswegen musste ich ihn ersetzen. > Aber selbstverständlich, es kommt auf die Größe der Einheiten und die > Isolierung an. Ein Beispiel Energie[B] 1000L ~90W/h; 300L [A] ~40-50W/h > > Das brauche ich nicht gegenüberstellen, ich weis es einfach das es > anders unwirtschaftlich ist!! > > Es ist E-Solar als auch Wärmepumpe ... bzw. Hybrid in Zukunft geplant. Hängt natürlich auch noch mit der Temperatur zusammen. Und was dann die realen Verluste sind ggü. dem versprochenen. Wie gesagt mit hybrider Heizung - klar da macht es Sinn. Aber nur um das Takten zu verringern - 20 Takte am Tag vs 2 mit Speicher plus Speicherverluste. Ich glaub nicht dass man da besser mit Speicher fährt. > >> Mit chemischer Wärmespeicherung könnte man sogar Solarenergie vom Sommer >> in den Winter transportieren - ohne Verluste > > Sicher..., wer es glaubt ohne Verlust.... Na das besondere ist dass die Speicherung chemisch durch die Entfernung von Wasser aus der Lösung passiert. Du hast also keine Abkühlverluste und kannst deutlich mehr pro Volumen speichern. > > Es werden schon riesige Wasserspeicher gebaut die ähnlich genutzt werden > sollen. > > Es sollte auch mal eine Pipeline mit Flüssigkeit Metall errichtet > werden...um Energie zu transportieren. Mann - Du bist aber auch echt der typische Neinsager. Ist Dir schon mal aufgefallen dass Du überall nur Probleme siehst und keine Chancen? Alles was von anderen kommt ist für Dich nicht machbar, fahrlässig, idiotisch und lächerlich. Versuch doch mal etwas positiver ans Leben ranzugehen! > > Kann ich alles nicht nutzen, habe Strom 49 Cent/kW und Gas 19,15 > Cent/KW. Ich empfehle neue Verträge abzuschließen. Habe gerade Gas mit 10.5 c/kWh auf zwei Jahre abgeschlossen.
Thorsten L. schrieb: > Warum, weil sie die Temperatur (am | in der Nähe des >> Heizkörper) messen bzw. !sogar! über separates Messkabel (opt.) messen >> konnten. Btw - ich denke Raumtemperatursensoren kombiniert mit den Sensoren in der Nähe der Heizung sind eigentlich optimal: die Thermometer in der Nähe der Heizung geben schnell Information über die Richtung der Veränderung (muss nicht erst auf Konvektion zum Raumthermometer warten) und das Raumthermometer gibt die korrekte absolute Temperatur. Ich plane beides einzusetzen - plus Vorlauftemperatur. Wenn alles so funktioniert wie ich plane dann wird an allen Ventilen der aktuell passende hydraulische Abgleich eingestellt und dann bei konstanter Ventilstellung getaktet. So hat man dann in allen Räumen die gleiche minimale Schwankung um das Ziel der gefühlten Zimmertemperatur.
Das grösste Problem bei standalone Thermostaten ist die Schnellaufheizung eines Zimmers. Dafür muss die Vorlauftemperatur stark angehoben werden. Und wenn die Raum/Thermostatsensoren in den anderen Zimmern das merken ist es bereits zu spât. Ich kann in einem Radiopaket neue Ventilstellungen gleichzeitig an alle Ventile schicken und die bereits richtig auf die neue Vorlauftemperatur einstellen bevor die Zimmertemperatur Überschiesst.
Hallo, > Mann - Du bist aber auch echt der typische Neinsager. Ist Dir schon mal > aufgefallen dass Du überall nur Probleme siehst und keine Chancen? Alles > was von anderen kommt ist für Dich nicht machbar, fahrlässig, idiotisch > und lächerlich. Versuch doch mal etwas positiver ans Leben ranzugehen! Ach....wie war das neulich mit der Danksagung I2C noch...das war lächerlich. Probleme wo Probleme sind und wo eine Möglichkeit existiert kann man sie auch erwähnen so lange sie einfach umsetzbar sind. Aber das Rad neu erfinden werde ich ganz sicher nicht. Auch zurück in 80er und hierum basteln obwohl es fertige Einzelteile zu kaufen sind, neee. Und ich bin noch jemand der Smart Home weit von sich schiebt bzw. geschoben hat!! HR20 und die neusten e-Ventil kein Vergleich neee. Ich habe fast 2 Jahrzehnte im Versuch bzw. der Produktvalidierung im Automotivbereich gearbeitet und ich glaube ein bisschen ist hängen geblieben. Und da wurde alles auf 15 Jahre getestet, sicher ist sicher. Beleidigungen sind ganz sicher nicht erstmalig aus meiner Feder, aber Leute die glauben sie haben die Weisheit mit Löffeln zu sich genommen gibt es überall und konstruktive Kritik sollte hilfreich sein. Aber ich denke dein Vorwurf ist unbegründet!!! Aber ich bin ehrlich, bin wirklich gespannt ob ich das noch verstehe was Du da baust bzw. wie Danfoss das aufgebaut hat? Ich kenne nicht mal das Prinzip. Eine Hydraulik ohne zu messen?
Wenn ich mal darauf zurückkommen darf: Thorsten L. schrieb: >>> Man könnte trotzdem den BM1 ersetzen und i2c mit der Therme >>> sprechen solange man zusätzlich ein Can Bus Modul am Mikrocontroller für >>> Kommunikation mit der Peripherie hat. >> >> Peter* >>> eher nicht umsetzbar, >>> noch zweckmäßig. > > Umsetzbar: absolut ja. Zweckmäßig? Hängt eben davon ab ob der BM1 > korrekt mit der eigenen Therme funktioniert. Bei mir war das nicht der > Fall deswegen musste ich ihn ersetzen. Der Gedanke, den BM1 zu ersetzen gefällt mir sehr gut. Meine BM1 (bzw. "2") funktionieren zwar, aber es gelingt mir nicht, die TA250 durch Dave's Code auf einem ESP32 zu ersetzen, _u.a._ weil die damit gelieferten Pegel nicht passen (evtl. ist was an der Hauptplatine kaputt). Aber selbst wenn: Für einen "Notbetrieb" mit TA250 müßte man umstöpseln, und das ist für meinen Anwendungsfall der Haken bei der Sache, da nicht (Familien-Mit-) Userfreundlich. Ein Setup, bei dem der TA250 für die "defaults" weiter aktiv bleibt, aber von einem BM1-Ersatz (befehlsmäßig) ignoriert wird, solange auf einer anderen Schnittstelle regelmäßig Anweisungen kommen, wäre mir im Moment sehr viel sympatischer. Das hätte auch den Vorteil, dass man ggf. unbekannte Telegramme "durchstellen" könnte. Der TA sollte zufrieden sein, wenn er regelmäßig Infos aus der Therme bekommt sowie eine Außentemperatur. Dafür einen DS18B20 vorzusehen, wäre aber wohl kein großes Ding, oder?
Hallo, Jörg R. schrieb: >>> >>> Peter* >>>> eher nicht umsetzbar, >>>> noch zweckmäßig. Hier, ist der "richtige" Zusammenhang und sicher ist es bei "nur" der Therme machbar, es ist ja aus meiner Feder und Thorsten hat sich die Arbeit gemacht und es umgesetzt. Peter* schrieb: > HSM und HMM haben keinen I2C, sind also nur über Can-Bus ansteuerbar. Ein > System mit Pufferspeicher usw. mit I2C ist wohl ~ eher nicht umsetzbar, > noch zweckmäßig. ein bisschen mehr lesen. > _u.a._ weil die damit > gelieferten Pegel nicht passen Nun, u.a ist ein weites Feld?...welcher Pegel? > Aber selbst wenn: Für einen "Notbetrieb" mit TA250 müßte man umstöpseln, > und das ist für meinen Anwendungsfall der Haken bei der Sache, da nicht > (Familien-Mit-) Userfreundlich. Dave's Programm fließt doch über den Can-Bus in das System ein und hebt den TA250 über die SW aus! Schalte ein Relais (2.facher Wechsler Can High/Low) über die Schließerkontakte vor deinem Can-bus Anschluss ESP32 und schalte es ein per SW, im Notfall bleibt es aus. ---> TA... ist im Notfall aktiv!! > Ein Setup, bei dem der TA250 für die "defaults" weiter aktiv bleibt,.... Sorry, nicht nur TA... Befehle ignorieren dann auch noch verschiedene Schnittstellen. Bosch/Junkers macht es über Kartenwechsel. z.B.: Ta211 /Ta250 /RAM. Wenn Du eine Lösung findest ich höre Dir ganz sicher zu..., aber wahrscheinlich kommt erst der Weltfrieden, sorry,... konnte mir jetzt nicht verkneifen und den! können wir gebrauchen!
Beim Weltfrieden sind wir uns einig, und zu meinen Pegeln hatte ich hier schon mal was geschrieben (Stichwort 30V statt 24V kommen von der Therme, den CAN-Teil spare ich mir, denn vermutlich ist einfach meine hauptplatine teilweise hinüber). Und ja, mag sein, dass mein Verständnis zum Ganzen - nennen wir es verbesserungsfähig - ist. Jedenfalls: Dave's firmware hatte mal bei mir funktioniert, aber wenn man da den CAN-Bus vom TA nicht wirklich wegschaltet, dominiert die TA und der ESP lauscht nur. Seit die 30V da sind, klappt es eben über (ESP-) CAN nicht mehr, mit der TA versteht sich die Hauptplatine weiter prächtig, warum auch immer. Vor diesem Hintergrund wäre mir ein BM-"neu" auf open-source-MCU-Basis eben sympatisch, v.a., wenn das dann (mangels anderer zeitnaher Anweisungen von woanders her) dann automatisch einfach die Anweisungen vom TA entgegennehmen würde und wie ein BM1 in den Speicher schreiben könnte. Mittelfristig wäre es dann wünschenswert, wenn ein BM-"neu" dann selbstredend "mit der ganzen Welt" reden könnte und die von HMS&Co kommenden Infos auch zutreffend in "Speicher-Aktionen" umschreiben könnte (also vermutlich dann auch Funktionen übernimmt, die heute eigentlich die TA übernimmt). Andererseits scheint mir der Bedarf dafür im Moment auch nicht eben groß zu sein... (im Unterschied zu einem gewissen Bedarf für BM1). 80/20 würde es für den Standardfall vermutlich ausreichen, wenn man das "übliche Duett" aus BM1 und TA250 durch was Intelligenteres ersetzen würde, das sich (über eine 2. MCU?) dann von einer Hausautomatisierungslösung fernsteuern ließe, und eben im Notfall auch im "Duett" BM-"neu"+TAxxx funktioniert... Nicht mehr, aber auch nicht weniger.
Hallo, Jörg R... > und zu meinen Pegeln hatte ich hier > schon mal was geschrieben (Stichwort 30V statt 24V kommen von der > Therme, den CAN-Teil spare ich mir, denn vermutlich ist einfach meine > hauptplatine teilweise hinüber). Sorry, erinnere mich und gefunden.. zur Sicherheit, denke Du hast die Möglichkeit des Fehlers in der Messung ausgeschlossen und festgestellt das es auch kein Wechselspannungsanteil in den 30V vorhanden ist [Multimeter ->DC AC Messung]?! keine Mischspannung. { Vermutung: Schaden durch Überlastung; Kondensator, Diode...} > Seit die 30V da sind, klappt es eben über > (ESP-) CAN nicht mehr, mit der TA versteht sich die Hauptplatine weiter > prächtig, warum auch immer. Das ist evtl. logisch, da BM1 mit 5V arbeitet. Auf der Platine BM1 ist ein Stabi 5V, der scheinbar hierfür auch benutzt wird. Das dürfte aber dem Can-Bus nicht stören. Ab einen Masseversatz über 1V kann es Schwierigkeiten geben. Messe mal beide Leitungen CAN-High und Can-Low zur Masse [GND].[0 bis 5v] Hast Du dein Can-Bus-Adapter mit GND vom BM1 verbunden? Wie wird der ESP versorgt, evtl. Fremdversorgung, mit.. auf jeden Fall GND Anschluss an BM1. > Mittelfristig wäre es dann wünschenswert... Von meiner Seite her, werde ich Dir leider sagen müssen, die Zeit habe ich bei weitem nicht. I2C Version ist nicht mehr in meinem Fokus und ein defekt der etwas aus dem Rahmen fällt wird jeden demnächst zwingen über eine Neuanschaffung nach zudenken. Zwangssanierung steht schon lange im Raum. I2C steht nur noch im Rahmen eines Textdisplay auf der Liste. Servicefunktionen. Um die SW zu verfeinern zu können, wird wohl Dave kaum noch zeit haben und wollen. Ich denke, das der Markt nicht mehr da ist und man kann sich evtl. bald mit Bm1 eindecken (gebrauchte) oder "f[w]indige Fachleute" werden die Preise hochhalten als Rarität.--- wie schon seit sehr lange Zeit.
> Der Gedanke, den BM1 zu ersetzen gefällt mir sehr gut. Meine BM1 (bzw. > "2") funktionieren zwar, aber es gelingt mir nicht, die TA250 durch > Dave's Code auf einem ESP32 zu ersetzen, _u.a._ weil die damit > gelieferten Pegel nicht passen (evtl. ist was an der Hauptplatine > kaputt). > Aber selbst wenn: Für einen "Notbetrieb" mit TA250 müßte man umstöpseln, > und das ist für meinen Anwendungsfall der Haken bei der Sache, da nicht > (Familien-Mit-) Userfreundlich. > > Ein Setup, bei dem der TA250 für die "defaults" weiter aktiv bleibt, > aber von einem BM1-Ersatz (befehlsmäßig) ignoriert wird, solange auf > einer anderen Schnittstelle regelmäßig Anweisungen kommen, wäre mir im > Moment sehr viel sympatischer. Das hätte auch den Vorteil, dass man ggf. > unbekannte Telegramme "durchstellen" könnte. Der TA sollte zufrieden > sein, wenn er regelmäßig Infos aus der Therme bekommt sowie eine > Außentemperatur. Dafür einen DS18B20 vorzusehen, wäre aber wohl kein > großes Ding, oder? Die Aussentemperatur hole ich mir inzwischen einfach von einem web service. Im Prinzip ist das alles machbar. Du brauchst nur einen Microcontroller mit CAN Bus Interface, der mit dem TA und dem Mischer spricht. Und der dann ein i2c RAM als I2c Slave simuliert und die über den Can Bus empfangenen Informationen dort reinschreibt bzw von I2c auf den Can Bus bringt. Da Dein Setup nicht identisch mit meinem ist, wirst Du einen I2c logic analyzer brauchen um mitzuprotokollieren, was im RAM landet. Jedenfalls ist das der einfachste Weg. Ich habe zum Glück diesen Saleae Analyzer, der wirklich gut ist, aber auch einiges kostet. Ich glaube man kann die Software (Logic 2) aber auch mit sehr billigen Clones verwenden (<50 Euro wenn ich mich richtig erinnere). Vielleicht mal Googeln.
Thorsten L. schrieb: > Ich glaube man kann die > Software (Logic 2) aber auch mit sehr billigen Clones verwenden (<50 > Euro wenn ich mich richtig erinnere). Vielleicht mal Googeln. Sowas in der Art: https://www.amazon.de/KeeYees-Logic-Analyzer-Farben-Arduino/dp/B07K6G55WG/ref=sr_1_1?__mk_de_DE=ÅMÅŽÕÑ&crid=20PF408I3Q35H&keywords=saleae+clone&qid=1678917616&sprefix=saleae+clone%2Caps%2C99&sr=8-1
Thorsten L. schrieb: > Mann - Du bist aber auch echt der typische Neinsager. Ist Dir schon mal > aufgefallen dass Du überall nur Probleme siehst und keine Chancen? Alles > was von anderen kommt ist für Dich nicht machbar, fahrlässig, idiotisch > und lächerlich. Versuch doch mal etwas positiver ans Leben ranzugehen! Psychoanalyse mit dem Skalpell, herrlich. Treffender geht's nicht. Vielleicht machen wir noch mal einen trööt zu dem Thema ohne Peter*nochgast auf. Aber wahrscheinlich hängt er sich dann in vermeintlicher Kompetenz auch wieder rein...
Hallo, es gibt Leute die haben was zu sagen und dann kommen die Leute, die !!nur rumpöbeln können. Herzlich Willkommen Verrücktes Pferd. H.Joachim S. > Vielleicht machen wir noch mal einen trööt zu dem Thema ohne > Peter*nochgast auf. Nicht reden machen!
Jörg R. schrieb: > Jedenfalls: Dave's firmware hatte mal bei mir funktioniert, aber wenn > man da den CAN-Bus vom TA nicht wirklich wegschaltet, dominiert die TA > und der ESP lauscht nur. Seit die 30V da sind, klappt es eben über > (ESP-) CAN nicht mehr, mit der TA versteht sich die Hauptplatine weiter > prächtig, warum auch immer. Eine Sache die mir aufgefallen war ist dass esp32 + can bus adapter nur ohne Terminierungsbrücke mit der Therme sprechen konnte. Bin der Sache nicht gross weiter nachgegangen aber komisch ists schon. Als wenn das mit 3.3v betriebene can bus Modul der Therme nicht genug Differenz zwischen Can H und Can L auf die Leitung bringt. Btw da schon zwei Leute ihre HW hier beim experimentieren zerlegt haben (oder die einem natürlichen Tod erlegen ist?): ich würde empfehlen den Mikrocontroller von der Therme mit Strom zu versorgen, damit GND auf gleichem Potential ist. Man weiss ja in einer Altbauwohnung nie ganz genau was passiert, wenn man gnd aus zwei Steckdosen mit separaten Netzteilen verbindet.
Hallo, Thorsten L. > Im Prinzip ist das alles machbar... Na Ja, nur den Fehler im CAN-Bus zu finden nicht.... man siehe unten > Du brauchst nur einen Microcontroller > mit CAN Bus Interface, der mit dem TA und dem Mischer spricht. Und der > dann ein i2c RAM als I2c Slave simuliert und die über den Can Bus > empfangenen Informationen dort reinschreibt bzw von I2c auf den Can Bus > bringt. Jörg, was funktioniert bei Dir nicht mehr? ... CAN-Bus?.... > Eine Sache die mir aufgefallen war ist dass esp32 + can bus adapter nur > ohne Terminierungsbrücke mit der Therme sprechen konnte. Bin der Sache > nicht gross weiter nachgegangen aber komisch ists schon. Als wenn das > mit 3.3v betriebene can bus Modul der Therme nicht genug Differenz > zwischen Can H und Can L auf die Leitung bringt. Alle 3 -4 Monate kommt das Thema auf [warum liest das keiner oder informiert sich selbst!!], wir haben einen 5V Can-Bus und das ist in der Praxis fast immer der Fall, auch wenn der CAN Controller mit 3,3V gespeist wird. Eine bessere Schaltung z.B.: Watterott unterstützt das. Link: CAN-Bus Pegel !!Ein Abschluss am CAN-Bus Adapter ist zu unterlassen!!, es wird nur an den Enden [TA2xx / BM1] terminiert, evtl. bei Stern neu berechnen, alle Abschlüsse. Es ist auch gängig ohne Abschluss zu arbeiten oder nur ein Abschluss zu setzen. Parameter sind immer hierbei Geschwindigkeit und Leitungslänge nur im Drill. > Man weiss ja in einer Altbauwohnung nie ganz genau was passiert, wenn > man gnd ""aus"" zwei Steckdosen mit separaten Netzteilen verbindet. Achtung!!: PE ist nicht GND Das ist der Anschluss der in Frage kommt. • 4 = GND Man schaue sich mal die "Aufgabe" des Moduls mit dem Namen RAM an und dann die kurzzeitige max. Belastung des ESP32 an. negativ ist nur die Sichtweise und nicht verstehen. Wenn es hilft...+
> Na Ja, nur den Fehler im CAN-Bus zu finden nicht.... man siehe unten Du - mein Ansatz ist da einfach etwas anders: wenn jemand etwas machen möchte und nach Details fragt dann gebe ich die. Meine Mission im Leben ist es nicht anderen vorzuschreiben was sie zu tun oder lassen haben. > !!Ein Abschluss am CAN-Bus Adapter ist zu unterlassen!!, es wird nur an > den Enden [TA2xx / BM1] terminiert, evtl. bei Stern neu berechnen, alle > Abschlüsse. Es ist auch gängig ohne Abschluss zu arbeiten oder nur ein > Abschluss zu setzen. Parameter sind immer hierbei Geschwindigkeit und > Leitungslänge nur im Drill. Ich hatte ja gar keinen TA dran (zum 20. mal). Aber das Setup funktionierte nicht mit Terminierung. Das ist schon erstaunlich. >> Man weiss ja in einer Altbauwohnung nie ganz genau was passiert, wenn >> man gnd ""aus"" zwei Steckdosen mit separaten Netzteilen verbindet. > > Achtung!!: PE ist nicht GND Ach nee. > > Das ist der Anschluss der in Frage kommt. > > • 4 = GND > > Man schaue sich mal die "Aufgabe" des Moduls mit dem Namen RAM an und > dann die kurzzeitige max. Belastung des ESP32 an. > > negativ ist nur die Sichtweise und nicht verstehen. Wenn es hilft...+ In der Tat - diesen Absatz kann ich rein semantisch/grammatisch nicht verstehen. Ungeachtet der Polarität der Sichtweise.
moin, ich habe eine KSBR 3-16 a21 mit DT1 und TA211e im keller. komme ich da auch ohne BM1 an die daten der heizung? beim lesen habe ich was von i2c gesehen. wo wäre der? bisher loge ich mit ds18b20 und einem teensy4.1. das läuft seit einigen jahren recht zufriedenstellend. mfg horst
:
Bearbeitet durch User
Hallo Horst, Du hattest ja schon mal angefragt, eine witterungsgeführte Heizung ist dein Eigen und Du hast die gleichen Möglichkeiten des Ausbaues wie hier mehrfach schon beschrieben. Ohne einen Schritt zu wagen wirst du nicht weiter kommen. Durch den TA211E verlierst Du zu mindestens den i2C Anschluss an der "Vorderseite" (TA211E). Ob der multicodierter Stecker bei der Uhr, auch noch bei der Installation des TA211E die I2C Funktion bei behält, ist mir nicht bekannt, noch ab wann das Textdisplay überhaupt möglich war. Hier müsste mal ein Scan durchgeführt werden bzw. vielleicht hat ja ein Mitleser einen ähnlichen Aufbau mit Textdisplay. FD daten sind wichtig. TA211E und Textdisplay eine Variante??? Die Frage was willst Du überhaupt mit lesen, Rechenleistung hast Du ja genug nur ob praktisch? Vom TA211E kannst Du nur die Einstelldaten und die Außentemperatur wandeln. Ich habe mich schon mal dazu geäußert, wie das funktioniert. ~Seiten[2]
:
Bearbeitet durch User
moin, danke für die antwort. wie ist die steckerbelegung am ta211e? wenn dort i2c drauf ist könnte ich doch dort mit einem sniffer die daten anbgreifen. da ich nicht steuern will würde mir das reichen. liege ich da richtig?
Thorsten L. schrieb: > Du - mein Ansatz ist da einfach etwas anders: wenn jemand etwas machen > möchte und nach Details fragt dann gebe ich die. Danke! Hast du irgendwo ein Repo, auf dem dein Code für "Funk-to-i2c" zu finden ist? Bzw. du scheinst dich ja intensiver auch mit Dave ausgetauscht zu haben. Discord? Wie bereits geschrieben, wird es noch etwas dauern, bis ich die Heizung dann wirklich mal auseinandernehme und dann auch mal versuchen will, ein paar aktuelle Messdaten zu meinen komischen Pegeln zu liefern. Im Moment läuft die eben möglichst ungestört, damit ich mir ggf. nicht zum falschen Zeitpunkt ein zusätzliches Problem einfange. Ansonsten kenne ich das Risiko... Es ist meins! Was diese ständige Gnd-Diskussion bei CAN angeht: Ich kenne das Thema, ja, und ich weiß v.a. auch, was passiert, wenn man was in die Richtung an der falschen Stelle versucht. Ob die Therme einen Hau davon hat, dass der ESP mal (mit verbundenem GND bzw. u.A. auch aus diesem Grund) über die Therme versorgt gewesen war - ich weiß es nicht, kann sein. Ist jedenfalls ein anderer Fehler auf dem Board, als das, was Dave hatte (wohl schon vor dem Kauf des Objekts!). Ansonsten kenne ich mich auch nicht allzugut aus, aber soweit ich den TA211E vor meinem geistigen Auge hatte, sind da einfach ein paar verstellbare Widerstände drin. Ob das dann wirklich über die i2c-Schnittstelle abfragbar ist: keine Ahnung, für mich sieht das ziemlich analog aus. Auch die Uhr scheint nur analoge Ein-/Aus-Infos zu liefern, so jedenfalls das, was mir aus der diesbezüglichen Diskussion (u.a.) mit Dave in Erinnerung geblieben ist (daher: alles ohne Gewähr). Mein Schluss: Der "Ofen" braucht ein paar (wenige!) Eckdaten, dann tut er, was er soll. Um ihm diese zu geben, paßt für mich die "standalone-Eigenbau-" i2c-Schnittstelle (mit TA250-Fallback über CAN) nach jetzigem Kenntnisstand deutlich besser in mein künftiges Gesamt-Setup wie BM1. Von daher würde ich das gerne dann angehen und mich freuen, wenn mich joelucid da etwas "an der Hand" nehmen könnte, und ich bin auch gern bereit, das so zu machen, dass andere auch was davon haben (und z.B. per serieller Schnittstelle einen Arduino aus jedweder Heimautomatisierungslösung (oder von mir aus auch Tasmota-scripting) raus mit den notwendigen Soll- und ist-Daten füttern könnten.
Hallo, nochmals.. da Du deine Anlage so wie sie ist,... beibehalten willst!!! Was bleibt Dir auch anders über. Also mit Ta211E und DT2 sind diese beiden Leitungen (I2C ->BM1) vom TA211E benutzt!! Kein I2C mehr!! Peter* > Ich habe mich schon mal dazu geäußert, wie > das funktioniert. ~Seiten 1[2]3 ja mehrfach--> suchen lesen! Horst S. > wenn dort i2c drauf ist könnte > ich doch dort mit einem sniffer die daten anbgreifen Ja...,aber nicht am TA211E Stecker, sondern evtl. am Hauptplatinen Stecker Umfeld DT2 und an einem evtl. Servicestecker neben den TA211E Stecker an Hauptplatine. Meine Urteilung: Es besteht nur eine geringe Möglichkeit hier noch I2C zu finden, da Du nicht das richtige Gerät [~BM1] angeschlossen hast. Selbst wenn, werden angeblich keine Datenwerte mehr geliefert sondern nur noch Text Info's. Das Textdisplay ist eine "evtl." Sonderausstattung Premium und ersetzt !TA211 und DT2! Benutzung Baujahrabhängig! Denke daran hier wird mit 24V gehandelt und jeder ist selbst verantwortlich! Vielleicht helfen Dir die Bilder noch, ansonsten lasse die Finger weg.
Hallo, Thorsten L. schrieb: > Du - mein Ansatz ist da einfach etwas anders: wenn jemand etwas machen > möchte und nach Details fragt dann gebe ich die. > Meine Mission wau! > im Leben > ist es nicht anderen vorzuschreiben was sie zu tun oder lassen haben. Na super. Es wird immer seltsamer hier. Wer bitte hilft hier nicht? und ich verbreite hier kein Unsinn. Wenn man hier auf Fehler hinweist und das dies schon so oft diskutiert wurde, wird behauptet man schreibt jemanden was vor. ... und plötzlich ist alles halb so schlimm und funktioniert wieder alles trotz des Fehlers??? Sorry...nee schau
moin peter, so recht verstehe ich das noch nicht. der 6polige stecker an dem der ta211e hängt ist doch der selbe wie für das bm1. wie redet den die hauptplatine mit dem bm1, geht das nicht per i2c? ich lese mich gerade durch die listen....... hut ab was ihr da schon alles gemacht habt. gilt das noch? BM1 -Stecker Pin1 VCC, Pin2 NC, Pin3 GND, Pin4 "5Volt", Pin5 "SDA", Pin6 "SCL" da könnte ich doch mit meinem sniffer ran gehen.
:
Bearbeitet durch User
Hallo Horst, weil Du es bist! Ja und Nein, der I2C wird abgeschaltet, aufgrund des Gerätes TA211E. Die Pinne 5 und 6 sind nun ein Takt/Freigabe_Signal [->] bzw. ein Daten Signal [<-] bestehend aus 8 Frequenzpakete hart umgeschaltet im Bereich von ~100 bis ~450Hz im Takt von wenigen Hz. Lass mich nicht Lügen 1 oder 2Hz. TA 211E ist nichts anders als ein VCO mit 8 Eingängen mit zyklischer codierter Umschaltung. Das was die Heizung (& DT2) nur braucht!! TA211E könnte man auch simulieren. Hier werden die Ports anders verwendet, ob eine generelle I2C Schnittstelle existiert ist mir noch nicht bekannt. Textdisplay, evtl. Serviceschnittstelle sind evtl. ein Indiz. hierfür. ...EOF
Jörg R. schrieb: > Danke! Hast du irgendwo ein Repo, auf dem dein Code für "Funk-to-i2c" zu > finden ist? Bzw. du scheinst dich ja intensiver auch mit Dave > ausgetauscht zu haben. Discord? Ich hab meinen Code weiter oben gepostet. Mit Dave habe ich mich nicht weiter ausgetauscht als hier und in dem Forum seines Projekts. Jörg R. schrieb: > Mein Schluss: Der "Ofen" braucht ein paar (wenige!) Eckdaten, dann tut > er, was er soll. Um ihm diese zu geben, paßt für mich die > "standalone-Eigenbau-" i2c-Schnittstelle (mit TA250-Fallback über CAN) > nach jetzigem Kenntnisstand deutlich besser in mein künftiges > Gesamt-Setup wie BM1. Genau so ist das. Im Grunde braucht die Therme nur Vorlauf soll, WW soll und Pumpe an/aus. Mehr ist da nicht einzustellen. Aber interessant ist natürlich das Auslesen der Infos der Therme. Sonst könntest Du es auch über die 1-2-4 Schnittstelle machen - da musst Du nur die passende Spannung für Vorlauf soll anlegen.
Tag zusammen, ich habe ein BM1 und einen TR220 (Raumtemperaturregler ohne Aussenfühler, ansonsten wie TA250), die Daten lese ich an einem Raspberry mit Can Modul mit. Seit Jahren bis vor ein paar Wochen war das Heizgerät eine Junkers -6 Therme, dabei kam es sehr selten zu falschen Werten, z.B. Hex 255 für den Parameter 209, also den Brennerstatus, wo ja nur 0 und 1 zulässige Werte sind. Jetzt habe ich dasselbe TM1, denselben Regler, den selben Raspberry an einer anderen Therme (ZWR 18-5), mit anderer Verkabelung. Nun bekomme ich häufig falsche Werte, entweder 255 oder ein Bruchteil davon, wie z.B. bei den Temperaturen 127.5, 65.5, 31.5. Der Großteil der Werte stimmt aber. Ich filtere das derzeit mit einem Programm am RPi raus... das sieht dann so aus: 10:09:59 - Vorlauf Max: Value 63.5, ignoring 10:13:34 - Vorlauf Ist: Value 127.5 larger than 90, ignoring 10:14:16 - Vorlauf Ist: Value 63.5, ignoring 10:18:01 - Brenner Ein: Value 255 larger than 90, ignoring 10:19:37 - Heizung Ein: Value 255 larger than 90, ignoring Die Temperaturwerte sind dabei schon umgerechnet. Jetzt frage ich mich natürlich, was die Ursache ist. Liegt es an der Kommunikation zwischen TM1 und Therme, oder können solche Werte durch fehlerhafte Verkabelung kommen? Es gibt keine Error-Frames auf dem Bus, nur eben regelmäßig falsche Werte. Hat jemand von Euch so etwas schon mal gesehen, oder eine Idee wo das herkommen könnte? Es betrifft ausschließlich Übertragungen vom BM1, die Werte vom TR220 sind 100% korrekt. Danke & Gruß, A.
Hmmm, die Verkabelung noch einmal komplett überprüft, den Raspi testweise direkt am BM1 angeschlossen ==> selbes Problem. BM1 erneuert (naja gegen eine ältere gebrauchte Version getauscht) ... selbes Problem. Fraglich ob der TR220 auch die falschen Werte bekommt und darauf reagiert... ich werde es im Auge behalten. Merkwürdig, sehr merkwürdig. Derselbe Aufbau hat an einer anderen Therme bislang fehlerfrei funktioniert... Gruss, A.
Ich bin am Verzeifeln. Ich dachte durch meinen Umbau hätte sich am Problem nichts geändert. In der Tat sind die regelmäßigen 255-Werte für 20A und 209 (Status Pumpe & Brenner) unverändert, die filtere ich raus. Zusätzlich habe ich jetzt noch mehr (quantitativ) und noch weniger vorauszusagende Ausreißer (qualitativ) bei den Werten für 200 und 201, also die Vorlauftemperaturen von Seiten der Therme. Es ist also schlimmer geworden... ich füge mal ein Bild bei... Für den Bus habe ich ein 2x2x0.25mm Datenkabel verwendet, verdrillte Adern, geschirmt. Durch das Ganze rumprobieren habe ich leider das ursprünglich verwendete BM1 (Junkers Version 0.3 mit FD von 2003) geschrottet, die 0.5A Feinsicherung der Therme war dann auch durch. Vermutlich einen Kurzschluss gebaut. Verdammt... Das was ich jetzt in Benutzung habe ist hat die Version 0.2 mit FD Mitte 2000. Ich wäre für jeden Input dankbar. A.
Hallo, traurig, das Du scheinbar keinen Vorname hast! Checke als erstes deine Heizung ohne zusätzlichen Can-Bus Anschlusses oder Versorgung deines Raspberry's über die Therme. Daten über den Service und dem Tr kontrollieren. Spannungen prüfen. Wenn Du hier Fehler aufgezeigt bekommst hat sich die Sache hier erledigt. Wie hast Du einen Kurzschluss verursacht mit einem Kabel mit codiertem Stecker.
Hallo Peter, der Name ist Alex... ich bin im Internet immer etwas vorsichtig... Den Raspberry habe ich nie über den Bus mit 12V versorgt, er hat ein eigenes Netzteil, nur GND, Bus-High und Bus-Low sind angeschlossen. Ohne den Raspberry sieht der Aufbau (nur BM1 un TR) erst einmal gut aus. Da die "Ausreisser" bei den Werten jedoch nicht ständig da sind, kann ich es ohne den Raspberry nicht gut überprüfen. Was ich sagen kann ist dass ich (mit Raspberry dran) zweimal am TR kurzzeitig eine rote Lampe und "Fehler FF" angezeigt bekam, das entsprechende 206 Telegram konnte ich dann auch im Can-Log des Pi finden. Die Therme "wusste" laut Service-Adresse .0 auch nichts von diesem Fehler, den es nach Liste auch nicht gibt. Ich habe, um das Problem etwas einzugrenzen, ein gebrauchtes BM1 0.3 bestellt, sowie ein neues PiCAN Board für den Raspberry. Anfang kommender Woche kann ich dann mehr sagen. Das mit dem (Can-seitigen) Kurzschluss war nur eine Vermutung. Das alte (ursprüngliche und definitiv defekte) BM1 hat dann (in einem weiteren Test ohne can-seitige Verdrahtung) die Feinsicherung auf der Hauptplatine umgehend noch einmal geschmolzen. Ich fürchte, dass durch diese Aktion die Hauptplatine einen Schaden haben könnte, auch wenn nach Sicherungstausch erst einmal alles gut aussieht. Die Therme läuft derzeit ohne Modul und TR. Grüße, Alex
Hallo Alex, der Fehler kann momentan ja überall sein. Die Wahrscheinlichkeit, das die Hauptplatine einen Schaden genommen hat ist leider sehr hoch. Auf der anderen Seite hast Du geschrieben das es schon früher zu vereinzelten Fehler kam, was ja auf die BM1 Karte bzw. dein Aufbau schon eher schließen lässt. Wiederum, kann ich den defekt der Sicherung (313 5V) noch nicht richtig einordnen. Einfach wäre es mit einem Schaltplan und so weit, bin ich nicht mehr im Thema, glaube der Bm1 hat eine eigene 5V Versorgung aus 24V (Bs7). Also woher kommt der Kurzschluss? ~~TA211 hat 5V. !! weitere Tests mit defekten Teilen in deiner Therme solltest Du vielleicht einstellen!! Falls die Möglichkeit besteht untersuche mal die defekte BM1 ohne Einbau. Ohne das Du weist was zum Kurzschluss führte bzw. der CAN-Bus Fehler würde ich kein "neues" BM1 einsetzen. Fehlersuche ist angesagt. Warum muss es ein Raspberry sein, ein Pi micro w würde ich noch verstehen aber.... je nach weiteren Einsatz ist Arduino, ESPxx angesagt und besser? Aufbau, So einfach wie möglich halten!! ohne weitere Aufgaben.
Hallo Peter, Peter* schrieb: > der Fehler kann momentan ja überall sein. Ja, leider. > Die Wahrscheinlichkeit, das die Hauptplatine einen Schaden genommen hat > ist leider sehr hoch. Auf der anderen Seite hast Du geschrieben das es > schon früher zu vereinzelten Fehler kam, was ja auf die BM1 Karte bzw. > dein Aufbau schon eher schließen lässt. Der Aufbau an sich hat bereits jahrelang so funktioniert, nur eben mit einer anderen Therme. Hier habe ich nach einem langen Tag (Can-Bus-Kabel quer durch die Wohnung neu verlegt, inkl. Entfernung von viel unschöner Altbau-Verkabelung und Renovierungsarbeiten) nicht mehr die nötige Sorgfalt walten lassen und alles schnell zusammengeklemmt. Soweit ich es noch nachvollziehen kann habe ich dabei 12V Versorgungsspannung von der Therme an GND vom Raspberry-Modul gelegt. Das Modul hat nachher auf den ersten Blick noch funktioniert, so dass ich keinen Sachschaden vermutet habe. Deshalb der bestellte Ersatz für dieses Modul. > Wiederum, kann ich den defekt der Sicherung (313 5V) noch nicht richtig > einordnen. Einfach wäre es mit einem Schaltplan und so weit, bin ich > nicht mehr im Thema, glaube der Bm1 hat eine eigene 5V Versorgung aus > 24V (Bs7). Also woher kommt der Kurzschluss? ~~TA211 hat 5V. Wie ich es geschafft habe, das BM1 zu zerstören, weiss ich wirklich nicht. Es ist klar, dass ich dieses Modul ganz gar keinesfalls wieder anschliesse. Ich habe einen Kurzschluss vermutet, deshalb die Can-Verkabelung entfernt und noch einmal ohne getestet. Vor dem Schmelzen der Feinsicherung fing das LED Display der Hauptplatine an zu flackern, vermutlich hängt es an derselben Versorgung. Schaltplan habe ich leider keinen. > Falls die Möglichkeit besteht untersuche mal die defekte BM1 ohne > Einbau. > Ohne das Du weist was zum Kurzschluss führte bzw. der CAN-Bus Fehler > würde ich kein "neues" BM1 einsetzen. Fehlersuche ist angesagt. Leider fehlt mir zu so einer Fehlersuche (Messen sowohl des BM1 als auch insbesondere des Grundmoduls) sowohl die Messtechnik, als auch - ehrlich gesagt - das Fachwissen. Da eine neue Hauptplatine über 300 Euro kostet, bleibt mir eigentlich nur im Ausschlussverfahren die anderen Komponenten zu ersetzen und zu hoffen... > Warum muss es ein Raspberry sein, ein Pi micro w würde ich noch > verstehen aber.... je nach weiteren Einsatz ist Arduino, ESPxx angesagt > und besser? Naja, die Software darauf (selbstverbrochener canlogger und Volkszähler DB) hat sich seit Jahren für mich bewährt. Ich möchte da das Rad nicht noch einmal erfinden, zumal ich ja weiss dass es grundsätzlich funktioniert. Ich habe das "neue" BM1 sowie das Raspberry Board frühestens kommende Woche beisammen und bin gerne offen für bessere Methoden der Fehlersuche... Grüße, Alex
:
Bearbeitet durch User
Hallo Alex, habe schon ähnliches vermutet. Zwei Dinge solltest Du wissen, es gibt keine 12 V Versorgung an der Therme nur 24V. An der Verbindungsleitung Hauptplatine/ BM1 "kann" auch 5V anliegen an einem PIN. GND Verbindungen ist auch bei Can-Bus ein muss, besser Pflicht. Keine Belastung der Therme durch äußere Schaltungen, nur GND Ein Schaltplan hat wohl keiner außerhalb von Bosch. Wünscht sich hier wohl jeder. Den Can-Bus wie schon oft gesagt kein zusätzlicher Abschluss. Obwohl lange Querleitungen auch bei 10k evtl. Störungen auftauchen können. Evtl. Can-Busfehler CRC... abfragen falls möglich. Nun gelegentlich kann man auch ein Hauptplatine als Schnäppchen für unter 100Euro bekommen. Alex @ SW > noch einmal erfinden, zumal ich ja weiss dass es grundsätzlich > funktioniert. Ja, aber evtl. auch nicht immer!! Dann kann ich Dir vielleicht noch raten einen Kabelbaum herzustellen, den Du nicht verändern musst, der funktioniert.
Peter* schrieb: > Zwei Dinge solltest Du wissen, es gibt keine 12 V Versorgung an der > Therme nur 24V. Ja, da hast Du Recht... eigentlich wusste ich das, ist mir aber irgendwie abhanden gekommen. Das macht die mögliche Zerstörung des PiCan noch wahrscheinlicher... > GND Verbindungen ist auch bei Can-Bus ein muss, besser Pflicht. > Keine Belastung der Therme durch äußere Schaltungen, nur GND [ ... ] > Den Can-Bus wie schon oft gesagt kein zusätzlicher Abschluss. Soweit klar. Eine Frage noch: Würdest Du die Abschirmung der Can-Leitungen a) erden? (möglich bei mir entweder über die Gasleitung oder PE/N) b) mit dem Bus/GND verbinden (habe ich gelesen fände ich aber riskant, da ja z.B. eine induktive Beeinflussung durch naheliegende 230V Leitungen stattfinden kann) c) nichts von beidem (habe ich bislang so und hat in der letzten Wohnung auch funktioniert) Ich glaube nicht dass das mit meinem Fehler zu tun hat, da ich ja testweise die Wohnungsverkabelung ausgelassen und alles vor Ort an der Therme angeschlossen habe... Peter* schrieb: > Alex @ SW >> noch einmal erfinden, zumal ich ja weiss dass es grundsätzlich >> funktioniert. > Ja, aber evtl. auch nicht immer!! Was die "Software" betrifft - es ist eigentlich nur ein Shellskript, das candump laufen lässt und in einer Dauerschleife die Pakete auswertet. Es ist nicht schön, aber funktional und seit 2019 - zum Umzug auch stabil ... Peter* schrieb: > Dann kann ich Dir vielleicht noch raten einen Kabelbaum herzustellen, > den Du nicht verändern musst, der funktioniert. Werde ich so machen. Ich melde mich wenn sich Neues ergibt. Grüße, Alex
Hallo, zur Stromversorgung älteren Junkers Thermen. Diese sind so ausgelegt, das sie nur die Therme versorgen. Wird mehr Strom benötigt werden hier spezielle Bausteine benötigt, selbst im analogen Bereich. Ein Pi gehört ganz sicher nicht an die Therme, dies bezüglich. Abschirmung des Can-Bus ist gar nicht notwendig, eine gute Verdrillung (kurzer Schlag, wenige Zentimeter pro Schlag) beider Leitungen reicht vollkommen aus. Erst recht bei 10k, hat aber nichts mit der GND Leitung selbst zu tun, ein muss. Wenn aber der Schirm da ist würde ich ihn evtl. einseitig anschließen. Auf keinen Fall an die PE Leitung. Wiederum würde ich ein mehradriges Kabel verlegen das alles beinhaltet, somit ein Netzwerkkabel bzw. Verlegekabel. Netzwerkkabel: Wie schon öfters beschrieben halte ich die Watterott Can-Bus Platine für die Bessere, nicht das man sie nicht verbessern kann, aber vieles ist berücksichtigt. Kommunikationsleitungen gehören nicht neben Wechselstromleitungen. Vielleicht machst Du mal ein Foto von deinem Aufbau PI Can-Bus. Gruß
Hallo Peter, mal wieder am verzweifeln... ich erzähle es jetzt einfach so wie es passiert ist, vielleicht übersehe ich hier irgendwas. Am Wochenende habe ich meine Bus-Leitungen überprüft. Multimeter mit Widerstandsmessung. Alle Adern auf Durchgängigkeit und auch Kurzschlüsse überprüft. Alles in Ordnung befunden. Nochmal zur Vollständigkeit - ich habe ein Kabel mit zwei 0.25mm verdrillten Adernpaaren, eines für Can-High/Low, eines für GND und 24V, sowie eine Schirmung die nirgends angeschlossen ist. Diese Leitung kreuzt ein einer Stelle im 90 Grad Winkel eine darunterliegende 230V Leitung. Heute dann mit "neuem" Busmodul (diesmal ein 0.4 mit dem großen IC drauf) sowie wirklich fabrikneuem PiCan 2 Board auf dem Raspberry. Der Raspberry wird nicht über den Bus versorgt. Am PiCan sind GND, Bus-High und Bus-Low angeschlossen. Erstmal schien alles zu laufen. Da ich aber weiß, dass der Fehler auch erst nach ein paar Minuten auftreten kann, ging ich außer Haus, Einkaufen. Als ich zurück kam: die üblichen Fehler in der Aufzeichnung (falsche Temperaturwerte, gelegentliche 255 für Brenner und Pumpe ein) sowie Fehlermeldung AC an der Therme (Fehler in der Kommunikation zwischen Leiterplatte und Busmodul). Aber das Busmodul sendete noch. Mit dem Busmodul hatte ich auch einen TA250 bekommen. Um auszuschliessen, dass mein TR220 einen Fehler hat, den TR gegen der TA getauscht. Therme an. Nur Datagramme vom TA auf dem Bus, nicht vom BM1. TA gegen TR zurückgetauscht - nur Datagramme vom TR, nicht vom BM1. Nochmal die Therme aus und eingeschaltet - Feinsicherung 0.5A wieder geschmolzen. Ich bin mir sicher, dieses Mal keine Fehlverdrahtung, keinen Kurzschluss verursacht zu haben. Also: Hauptplatine defekt? - oder übersehe ich hier irgendwas... Grüße, Alex
:
Bearbeitet durch User
Hallo Alex, schau erstmal hier, vielleicht Erste Hilfe https://www.fehlerhelfen.de/category/heizung/junkers/cerastarzwr246ke/ac mit deinem Service vergleichen Gruß
Hallo, nun... habe das Gefühl das Du die zweite oder sogar die dritte Runde eingeleitet hast und immer weniger vom Erfolg gekrönt bist. Was bleibt Dir noch anders übrig als die Hauptplatine zu wechseln. Wiederum spricht der Kurzschluss nicht unbedingt für ein Fehler auf der Platine. Das Schlimme, Du bist nicht ein Schritt weitergekommen, die neuen Teile sind alle nicht mehr vertrauenswürdig. Können geschädigt sein. Ich erlaube mir mal zu fragen, warum alle Neuteile auf einmal?? Mit viel Zeit dazwischen, ein Schritt nach dem Anderen, in deiner Situation. Ohne zu messen, wirst Du nicht weiter kommen, hol Dir direkte Hilfe. Gruß
Hallo Peter, ja, ich sehe dass ich nicht weiterkomme! Ich habe Aufbau und Anwendung eigentlich nur (aus meiner letzten Wohnung) übernommen, die ich 2019 auch mit Hilfe des Forums (damals habe ich als Gast unter dem Namen "trabant" geschrieben) zusammengestellt habe, und nachdem alles ein halbes Jahr stabil lief, auch via VZ-Wiki veröffentlicht habe. Das war lang bevor es quasi fertige und hochentwickelte Anwendungen wie z.B. die von Dave hier im Forum gab. Und ich weiß, dass einige Leute genau meinen Aufbau nachgebaut haben und Erfolg damit hatten. Mir wurde nie etwas zurückgemeldet, was auf einen grundsätzlichen Fehler im Aufbau hätte schließen lassen. -- Was nicht heißt, dass es nicht doch einen geben könnte... Ja, es ist die zweite oder dritte Runde. Das Raspberry Modul als Fehlerquelle schien mir wahrscheinlich, da ich es ja anfangs falsch angeschlossen hatte und nochmal ein Can-Modul anzuschließen, mit dem die Sicherung geschmolzen war, erschien mir fahrlässig. Wo sollte ich externe Hilfe holen, wenn nicht durch Inputs aus dem Forum? Ich könnte den Junkers Werkskundendienst beauftragen, der dann auf Verdacht vermutlich alles tauscht. Am Ende habe ich dann keine Kontroll- und Aufzeichnungsmöglichkeit mehr und wäre vermutlich > 1000 € ärmer. Ja, ich würde auf einen Fehler im Grundmodul tippen, aber ich sehe auch dass die geschmolzenen Sicherungen auf etwas Anderes deuten. Was könnte ich mit meinen beschränkten Möglichkeiten noch messen, will meinen mit Multimeter, kein Oszilloskop o.ä. vorhanden...? Ich überlege, um eine kostenmäßige Explosion zu vermeiden, das Can-Kabel wieder rauszureissen und wieder 3x0.75mm für einen vorhandenen 1-2-4-Regler (TR200) zu verlegen. Das wäre der Schritt zurück von der modernen Datenverarbeitung in die 70er Jahre. Und gäbe es regelungsttechnische Fehler aufgrund eines defekten Grundmoduls, würde ich sie nicht mehr sehen können. Wie würdest Du weiter vorgehen? Grüße, Alex
Hallo, was soll ich Dir noch raten, rette deine Heizung und schau ob sie noch funktioniert(das 2 mal!) und überprüfe nochmals bei der Deinstallation(can...) ob Du Fehler findest (nur registrieren). Ich glaub das Du da einen Fehler ständig wiederholst. Anschlussbelegung prüfen, nur im Bereich der Heizung ein kurzes Kabel zum TR220(TR200) legen, es sind 4 bzw. 3 Kabel!! nicht blind nur nach Plan. Es werden hier 2 Sicherungen zerstört, obwohl Du andere Teile benutzt hast.??? Die Grundfunktion der Heizung testen und sonst nichts. Kein Can, kein Pi kein Schnickschnack. Fertig. Was ich machen würde? Ich habe nie an meiner Heizung herum gespielt, sondern immer an separaten Aufbauten (Schreibtischtest) getestet usw. ...war nicht billig, aber billiger als eine defekte Heizung. Ein Multimeter sollte jeder besitzen, es brauch kein super teil sein. Ich finde deine Veröffentlichung in VZ-Wiki(?)nicht. Gruß
Hallo Peter, ich habe mich da falsch ausgedrückt, ich habe ein Multimeter, jedoch kein Oszi... der Aufbau ist dieser... https://wiki.volkszaehler.org/hardware/channels/heating_control/gastherme_junkers_can_bus Ja ich werde mir mal die Zeit nehmen das was ich kann an der Heizung zu überprüfen. Gruß, Alex
Hallo, ja,... hast eigentlich alles beschrieben damals. Die Pi_SW kann ich nicht beurteilen. messe bitte mal die Versorgungsspannung der Therme 24V zu GND, falls BM1 noch in der Therme ist an den Anschlussklemmen (24V Pin1--GND Pin4). Messe auch den Wechselspannungsanteil an den Punkten, die müssen null sein. Gruß
Peter* schrieb: > messe bitte mal die Versorgungsspannung der Therme 24V zu GND, falls BM1 > noch in der Therme ist an den Anschlussklemmen (24V Pin1--GND Pin4). > Messe auch den Wechselspannungsanteil an den Punkten, die müssen null > sein. Interessant. 24V zu GND am Anschluss für den Analogregler (1-2-4) sind 24V. Am BM1 v.04 etwa 34V. Etwas früher im Thread habe ich etwas über abweichende Versorgungsspannungen gelesen... Beitrag "Re: Junkers CAN-Bus Protokoll" - wie würdest Du das einschätzen? Mögliche Fehlerquelle? Wechselspannungsanteil in beiden Fällen knapp 2V, kann aber eine Ungenauigkeit meines Multimeters sein. Dann habe ich noch in meiner abgeklemmten Can-Wohnungsverkabelung die nach einer möglichen Induktionsspannung gemessen (gegen Erde/Gasleitung) - Stichwort 230V. Über 30V im Schirm, unterschiedliche Werte (zwischen 10 und 25V) in den einzelnen Adern. Nach Entfernung meiner einen Kreuzung (bzw. 230V Leitung stromlos gemacht) immer noch so. Nach Abschaltung der gesamten Stromversorgung war es weg. Ich habe dann leider herausgefunden (Leitungsfinder), dass quasi überall kreuz und quer irgendwelche Leitungen verlaufen. Altbau, original mit Gasbeleuchtung, nachträglich elektrifiziert. Kann ich also nicht ganz vermeiden. Wenn ich den Schirm erde (an der Gasleitung) ist logischerweise die induzierten Spannungen auch in den einzelnen Adern weg. Ob diese Induktionsspannung ursächlich sein kann, ggfs. auch was kaputtgemacht hat? Ich weiss nicht wie viel Strom in den Can-Bus Adern fließt, sprich was der "schlucken" kann...
:
Bearbeitet durch User
Hallo, Alex > Interessant. 24V zu GND am Anschluss für den Analogregler (1-2-4) sind > 24V. Am BM1 v.04 etwa 34V. Etwas früher im Thread habe ich etwas über > abweichende Versorgungsspannungen gelesen... > Beitrag "Re: Junkers CAN-Bus Protokoll" - wie > würdest Du das einschätzen? Mögliche Fehlerquelle? ja,..Das sollte ein und die selber Versorgung sein (unbelastet), also auch die Werte.~~ Am BM1_Stecker ST1 (Kabel vom BM1 zur HP) sollte Am Pin 1 (24V) bzw. Pin 3(GND) 24V sein... auch an der HP vorhanden, allerdings vorsichtig spiegelbildlich, nicht Pin identisch. Alex > Wechselspannungsanteil in beiden Fällen knapp 2V, kann aber eine > Ungenauigkeit meines Multimeters sein. habe kein gutes Gefühl bei 2V unbelastet. Alex > Dann habe ich noch in meiner abgeklemmten Can-Wohnungsverkabelung die > nach einer möglichen Induktionsspannung gemessen (gegen Erde/Gasleitung) > - Stichwort 230V. Über 30V im Schirm, unterschiedliche Werte (zwischen > 10 und 25V) in den einzelnen Adern. Nach Entfernung meiner einen > Kreuzung (bzw. 230V Leitung stromlos gemacht) immer noch so. Nach > Abschaltung der gesamten Stromversorgung war es weg. Das hört sich sehr abenteuerlich an, aber unbelastete Leitungen ist möglich. Mach Dich nicht unglücklich, die Gasleitung sollte mit PE verbunden sein, aber nicht als PE_Leitung missbraucht werden. Alex > Ich habe dann leider herausgefunden (Leitungsfinder), dass quasi überall... Sieht nach Jahresauftrag aus. Alex > Ob diese Induktionsspannung ursächlich sein kann, ggfs. auch was > kaputtgemacht hat? Ich weiss nicht wie viel Strom in den Can-Bus Adern > fließt, sprich was der "schlucken" kann.. Sicher ist das möglich ob es allerdings hier der Fall war...der CAN ist relative sicher. In den meisten CAN-Adaptern fehlen die Eingangssicherungsdioden hier. Ich tippe eher auf die Versorgungsspannung bzw. auf die Mischspannung. Alles nur wage Vermutungen, leider. Schau ob deine Heizung fehlerfrei funktioniert. Gruß
Gestern noch habe ich den TR220 direkt ans Busmodul angeschlossen, mit kurzem Kabel, ohne Raspi, erstmal sah es ok aus. WW hat an der Heizung immer funktioniert, dann habe ich noch ein paar Tests im Heizbetrieb gemacht. Prinzipiell läuft der auch. Kann modulieren, die Zieltemperatur erreichen, die Pumpe steuern. Aus irgendeinem Grund ignoriert die Heatronic teilweise die von mir eingestellten Werte zur Taktsperre und Schaltdifferenz und schaltet zu früh den den Brenner wieder ein. Leider kann ich nicht sagen, ob die Therme das Problem schon früher hatte, ich hatte sie ja im letzten Winter noch nicht. Es ist eine der ersten -5 Geräte aus dem Jahr 1998. Dann, gestern Abend noch Fehler AC an der Therme und heute morgen FF am TR - also ein fehlerhaftes 206 Datagramm. Ich habe dann die Therme ausgeschaltet, das Kabel vom Busmodul abgesteckt, um die Spannung zu messen. Therme wieder an, ein lautes Klacken wie von einem Relais oder einem platzenden Kondensator, Fehler E0. Ich war da noch nirgends mit dem Multimeter auch nur in der Nähe. Resetschalter gedrückt, Display dunkel. 0.5A Feinsicherung durch. Sicherung ersetzt, seitdem scheint es wieder zu laufen, zumindest ein paar Mal WW und ein kurzer Test im Heizbetrieb. Ich fürchte, ich komme da um eine neue Hauptplatine nicht herum. Ich könnte noch testen, ob die Analogregelung mit dem TR200 noch funktioniert. Die Busschnittstelle rühre ich bei dieser Platine nicht mehr an... Gruß, Alex
hallo Alex
> Es ist eine der ersten -5 Geräte aus dem Jahr 1998...
Ganz ehrlich... 25 Jahre, schau mal das Du eine "neue" gebrauchte billig
bei Klein... bekommst. Das würde sich eher lohnen als in deine alte noch
Geld zu pumpen.
Gruß
So, ich habe die Hauptplatine getauscht. Meine -5 ist in einem sehr guten, sauberen und gewarteten Zustand, so dass ich sie schon behalten will. Ähm, beim Wechsel des Mainboards wurde der Grund für die dauernden Kurzschlüsse offensichtlich. Murks von meiner Seite. Da hatte sich eine Ader des Abschirmgeflechts der Can-Leitung unter den Modul-Anschluss 314 verirrt. Und deshalb auch ohne BM1 die Sicherung fliegen lassen. Ich traue mich jetzt nicht, eines meiner beiden BM1 an das neue Board anzuschliessen, auch wenn sie vielleicht noch gingen. Zumindest Busmodul werde nochmal eins besorgen. Ich habe da jetzt also 2 Busmodule, einen TA250 (der mit einem Busmodul mitkam allerdings ziemliche Gebrauchsspuren aufweist) und 1 PiCan übrig. Theoretisch auch noch die alte Hauptplatine. @Peter - Kannst Du mit irgendwas davon was anfangen? Z.B. irgendwie herausfinden, ob die Busmodule defekt sind und sie ggfs. reparieren? Ich würde sie Dir schicken, wenn Du magst. Ich melde mich dann nochmal wenn das neue BM1 da ist, dann nochmal die Spannungen kontrollieren und sehen ob es das jetzt war. Grüße, Alex
Hallo Alex, Alex > So, ich habe die Hauptplatine getauscht. Meine -5 ist in einem sehr > guten, sauberen und gewarteten Zustand, so dass ich sie schon behalten > will. Verstehe ich, meine Heizung ist jetzt nicht ganz so alt, aber von innen fast wie neu. Allerdings nach 2008 sind die Heizungen schon besser geworden und vor allem regelbarer. Hast Du den Kodierstecker überprüft muss die gleiche "Nummer" haben. Es schon mal Gut, das Du einen Fehler gefunden hast der die Kurzschlüsse erklärt. Alex > Ich traue mich jetzt nicht, eines meiner beiden BM1 an das neue Board > anzuschließen, auch wenn sie vielleicht noch gingen. Zumindest Busmodul > werde nochmal eins besorgen. Das würde ich auch sein lassen, die Empfindlichkeit des BM1 hat jeder schon mal erfahren. Alex > @Peter - Kannst Du mit irgendwas davon was anfangen? Z.B. irgendwie > herausfinden, ob die Busmodule defekt sind und sie ggfs. reparieren? Ich > würde sie Dir schicken, wenn Du magst. Danke, aber zeitlich bekomme ich das momentan überhaupt nicht hin und eine Reparatur, nee sowas lohnt sich nicht (zur Zeit) und eine Verantwortung zu übernehmen für 10 bis 20 Jahre alte Teile ist eher ausgeschlossen. Wenn Du sie mir zuschicken willst ohne retour und der Option der Entsorgung, werde mal kurz drüber schauen und Du kannst dann evtl. den TR freisprechen nach einer Strommessung an einer separaten 24V Stromquelle. Hoffe es klappt alles. Gruß
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.