Junkers CAN-Bus Protokoll

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

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

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.

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.

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

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

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

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.

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:

1	uint8_t Tx = 12; // Sende_LED_D03
2	uint8_t Rx = 14; // Empfangs_LED_D02

unter Setup:

1	pinMode(Tx, OUTPUT); digitalWrite(Tx, HIGH); // Ausgang; Tx_Led out,
2	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)

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

Das hat offensichtlich funktioniert. freu

Wie geht es nun weiter? ;-)

Gruß, Bernd

Erledigt. In meinen Augen macht das Ding das gleiche wie vorher. Es sendet und empfängt. ;-)

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.

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

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

@Peter: In meinen Augen arbeitet alles wie es soll... Was meinst du?

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

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?

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.

moin, mal ne frage an die profis. ich habe eine ksbr3-16a21 ohne busmodul. wie kann ich aus der daten abgreifen?

moin peter, danke für die antwort. wo finde ich da infos zum "textmodul"?

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?

Welches filesystem? In der Anleitung steht nur die beiden bin files.

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

Letzte Hürde war die Checksumme - aber die hab ich ja nun geknackt.

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.

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.

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.

Peter* schrieb:

und ich lasse mich gerne überraschen und zieh mein Hut.

Prepare to be amazed ;-).

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.

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.

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.

Das Peterle eiert ja immer noch hier rum :-)

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.

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.

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

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]

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.