CAN Bus, Home Automation E3 Generation lokal und kostenlos

[HerrP]

hier noch mal mein Beitrag aus 'Internet der Dinge', dem Offenen Brief an Max Viessmann, als neuer Thread - Diskussionen, Fragen etc. bitte hier 🙂

Moin Freunde*!

Da Viessmann zwar ein wunderschöne Schnittstelle (UDS, ISO-TP oder DoIP) eingebaut hat, das aber nur eingeschränkt und für eine 4-stellige Summe (per WAGO Gateway) zur Verfügung stellt, haben wir uns bekanntlich dran gemacht, das selber offen zu legen. 🙂

Stand der Dinge ist:

- Wir haben eine MQTT fähige Lösung zum Anschluss an den externen CAN Bus ("Stecker 91"), die es erlaubt, E3 Geräte (Wärmepumpen, Gasgeräte, (PV Speicher gerade in der Testphase, BSZ brauchen wir noch Kandidaten)) in Home Automation Systeme einzubinden. ioBroker, Home Assistant, Node-RED und so weiter also alles einfach machbar und bei uns schon im dauerhaften Einsatz.

- Das Ganze läuft lokal, also ohne irgendeine Hersteller oder sonstwelche Cloud, ohne Internet! Bei der CAN Bus Kopplung kann die gleichzeitige Verbindung mit dem Viessmann Server zwecks Wahrung der Gewährleistungs- und Garantieansprüche aufrechterhalten bleiben.

Eine Anbindung über den WLAN Access Point ist auch möglich, damit aber keine parallele Viesmann-Server-Verbindung mehr.

und last not least: das Ganze ist natürlich kostenfrei und open source! im Sinne eins besseren Miteinanders 😉

Der laufend aktualisiert werdende Stand der Linux Lösung ist auf

https://github.com/open3e/open3e

verfügbar.

Eine Sammlung von nützlichen Informationen hat @TSG initiert:

https://github.com/open3e/open3e/wiki

beste Grüße!

Phil

zur Beachtung: Der Zugriff auf das Zielgerät mittels dieser durch Viessmann nicht vorgesehenen Lösung zieht möglicherweise den Verlust von Gewährleistungs-/Garantieansprüchen nach sich und kann unter Umständen zu GEFAHREN FÜR LEIBLICHE UNVERSEHRTHEIT ODER SACHWERTE führen! Die Autoren schliessen jegliche Haftung aus.

Beispiele aktueller Home Assistant Integrationen von Wärmepumpen:

Vitocal 250 Kältekreisübersicht: View und Installationsanleitung gibt's hier: https://github.com/MyHomeMyData/iob.vis.vitocal250.git

Visualisierung der Vitocal Energiematrizen zur monatlichen Energiebilanz für ioBroker:

Wer es ausprobieren möchte: Hier gibt es eine Anleitung.

Jürgen hat auch noch weitere schöne Sachen abgeleitet.

Einen Adapter für ioBroker:

https://github.com/MyHomeMyData/ioBroker.e3oncan

und noch ein paar andre Sachen, die aber in dem Adapter integriert sind. Schaut einfach mal sein Repo an...

https://github.com/MyHomeMyData

ps. wer uns unterstützen will und kann ist herzlich willkommen!

pps. und wir freuen uns über jedes 'like' (👍) - damit zeigt ihr deutlich, dass ihr eine offene und lokale Kommunikation mit den 'One Base' Geräten eigentlich von Viessmann erwartet

[Marc_O]

@Juergen-B

Nein, den genauen Hardware-Aufbau kenne ich nicht. Ich lasse mich bei meinen Logiken durch die KI unterstützen und hatte dort mal den Hinweis bekommen, mit dem Speicher vorsichtig zu sein.

Es ist ja Tatsache, dass dort Werte abgelegt werden, die auch nach einer Stromunterbrechung erhalten bleiben müssen. Wahrscheinlich sind ein paar Schreibvorgänge am Tag kein Thema, aber durch Logikfehler oder zu viele Parameteränderungen kommt schnell einiges zusammen, was dann zum Problem werden könnte.

Ob das nun technisch über ein EEPROM, eine SSD oder einen anderen Flash-Speicher gelöst ist, der diese Masse an Schreibvorgängen mitmacht, weiß ich eben nicht – deshalb meine Frage an euch Experten.

[KoGo]

Die erlaubten Schreibzyklen hängen stark von der Technologie (EEProm, externer Flash-Speicher, Microcontroller interner Flash-Speicher, ... ) sowie von der eingesetzten Software ab. Eine smarte Software verhindert, dass immer die gleichen Zellen häufig beschrieben werden, indem sie die Schreibzugriffe auf die physikalischen Zellen verteilt.
Man kann das also ohne internes Wissen über die HW und SW-Architektur nicht abschätzen, wann die Grenze erreicht ist.
Der schlechteste Fall wäre ein EEProm in relativ alter Technologie oder ein Microcontroller-internes EEProm bzw. Flash in etwas älterer Technologie. Diese konnten ca. 10.000 Schreibzugriffe pro Zelle. Auf moderne Flashspeicher kann man durchaus 1 Million mal schreibend zugreifen.

[Marc_O]

Top, danke für die ausführliche Erklärung! Das hilft extrem weiter, um das Risiko besser einzuschätzen.

Da man nicht genau reinschauen kann, ist es wohl schlauer, auf Nummer sicher zu gehen und den Speicher nicht unnötig zu stressen. Auch wenn moderne Chips ordentlich was wegstecken, muss man es ja nicht drauf ankommen lassen. Es macht definitiv Sinn, die Logiken so zu bauen, dass mit den Schreibzyklen eher sparsam gehaushaltet wird – sicher ist sicher. Danke für den fachlichen Input!

[HomeAssistantCG]

Danke, ist dir bekannt ob und wie ich die Vitocal 060 mit der 25x ohne weitere Geräte verbinden kann? Ohne das beide sich als Master blockieren? 

[Juergen-B]

Ich bin ziemlich sicher, dass das nur zusammen mit dem Viessmann-Support geht. Das ist ein neuer Inbetriebnahme-Ablauf.

[Juergen-B]

@Steffen007 Die Version siehst Du in der Adapteransicht oder in der Instanzansicht, wenn Du die Instanz aufklappst.

[Juergen-B]

@Marc_O @KoGo Ich habe das mal bei Claude eingetütet. Hier die Antwort:

Das ist ein interessanter Fall, der einige Aspekte beleuchtet.

Zur technischen Frage selbst:

Das Risiko ist real als allgemeines Konzept — EEPROM hat begrenzte Schreibzyklen (typisch 100.000–1.000.000 pro Speicherstelle). Aber ob das auf Viessmann-E3-Geräte zutrifft, ist unklar:

• Moderne Embedded-Systeme verwenden oft Flash mit Wear-Leveling, FRAM oder emuliertes EEPROM — alles deutlich robuster als klassisches EEPROM
• Der UDS-Standard (ISO 14229, ein Automotive-Standard) ist für gelegentliche Parameterschreibvorgänge ausgelegt, nicht für Streaming
• Viessmanns eigene Service-Tools (ViCare, Vitotrode) schreiben ebenfalls Parameter — wenn das Risiko erheblich wäre, hätte Viessmann das selbst zu lösen
• Typische open3e-Nutzung liest überwiegend Daten; Schreibvorgänge sind selten und benutzerinitiiert

Zur KI-Warnung:

Das ist ein Lehrbuchbeispiel für KI-Halluzination durch Übergeneralisierung. Die KI hat wahrscheinlich korrekt gewusst: (1) EEPROM hat Schreibzyklen-Limits, (2) Embedded-Systeme nutzen manchmal EEPROM — und daraus eine spezifische Warnung für Viessmann-Hardware konstruiert, ohne dafür konkrete Grundlage zu haben.

Fazit: Die Sorge des Anwenders ist nachvollziehbar, aber die Grundannahme ("da ist ein EEPROM verbaut, das durch open3e verschlissen wird") ist spekulativ. Bei normaler Nutzung — also kein Skript, das denselben Parameter hundertmal täglich schreibt — ist das Risiko praktisch vernachlässigbar.

[grabu]

Dass die Werte, die du über die ViCare App oder auch den CanBus schreibst, auf ein EEPROM geflasht werden, halte ich für ziemlich unwahrscheinlich. Firmware-Updates kommen vielleicht in das EEPROM, aber normale Einstellungen? Das wäre eine etwas seltsame Implementierung. Dass Viessmann das seltsam und blöd gebaut hat, kann man natürlich nicht mit letzter Sicherheit ausschließen, ohne die Hardware genau zu kennen, aber ich würde (und werde) es drauf ankommen lassen. 

[HerrP]

es würde mich wirklich wundern, wenn es in den Viessmann Elektroniken noch EEPROMs gäbe. Sowas macht man schon seit Jahrzehnten mit Flash. Wie gesagt - auch das ist nicht unendlich beschreibbar, aber die 'Verschleissgrenze' liegt doch in einer anderen Größenordnung. Denkt mal an eure SSD Platten - auch die sind Flash Speicher...

Ich würde jetzt keinen nicht-flüchtigen Parameter in einer Regelschleife schreiben, die im 1-Sekundenzyklus läuft. Und bei einer Regelschleife achte ich darauf, dass solche Parameter nur geschrieben werden, wenn sie sich relevant verändert haben, und nicht jedes 'Rauschen'.

Empfehlenswert ist hier ein Integralverfahren: Die Abweichung zwischen aktuellem Wert und neuem Wert wird aufintegriert (mit Vorzeichen). Wenn das Integral einen Schwellenwert überscheitet, wird der Wert geschrieben und das Integral zurückgesetzt. So erreicht man, dass große Änderungen schnell bzw. sofort zum Tragen kommen, kleine Abweichungen in eine Richtung nur, wenn sie sich 'manifestieren', und Schwingungen oder Rauschen sich wieder egalisieren und folglich garnicht geschrieben werden. 

[HerrP]

Grundsätzlich ist es natürlich gut und richtig, dass das Thema mal angesprochen wurde - nicht jeder denkt da dran. @Juergen-B  vielleicht sollten wir mal einen entsprechenden Hinweis in's Readme aufnehmen?

[Marc_O]

Danke an alle, die zu meinem Thema geantwortet haben. Ich denke, man kann es jetzt sehr gut einordnen. Mein Fazit: Parameter schreiben bzw. ändern ja, aber sparsam. Hierzu die genannten Logiken bzw. Verfahren zum Schutz anwenden. Ich würde es gut finden, wenn ein entsprechender Hinweis in der Readme auftauchen würde. Vor der „KI-Warnung” hatte ich mir auch keine Gedanken über zu viele Schreibvorgänge gemacht.