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

- Aktuell ist nur das Auslesen von Daten weitergehend erprobt. Bei den wichtigen Daten haben wir auch schon die Formate zur Interpretation geklärt, wir arbeiten an einer vollständigen Klärung.

Das Schreiben ist bei vielen Daten auch schon erprobt.

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. Einen guten 'Leitfaden' für den Einstieg hat @Hotzen-Plotz hier zur Verfügung gestellt:

https://github.com/open3e/open3e/discussions/5

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

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

(werden wir bald auch unter das open3e Projekt migrieren) 

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

[ghNeandr]

>> Sieht nach einem Hardware-Problem aus. Denke, Du solltest mal die Verkabelung anschauen, bzw. Deinen Adapter abklemmen und schauen, ob der Fehler in ViCare verschwindet.

Bin ganz zuversichtlich, dass hier "kein" nachhaltiger Fehler ist. Die Meldung in ViCare ist verschwunden. Auch hatte bei mehrmaligem Aufruf jeweils eine ViCare Meldung, so die war nach kurzer Zeit jeweils weg.
Werde es beobachten.

[HerrP]

liefert candump denn wieder was?

[GW3]

Ich stehe gerade vor der Entscheidung, für meinen Pi 4B das Upgrade zu versuchen oder das System gleich neu aufzustetzen.

Was ist das die Empfehlung?

Wenn ich das richtig gelesen habe, bräuchte man für das Upgrade nur

sudo rpi-update rpi-6.2.y

aufzurufen?

[HerrP]

ich würd's mal versuchen. komplett neu aufsetzen kannst du immer noch....

[HerrP]

der 4er braucht dringend das 64bit System - hast du das drauf? (wobei wir auch schon 4er mit 64bit hatten, die Timeout Problem hatten...)

[ghNeandr]

Vielleicht ist ja auch alles richtig .. was da in devices.json steht:
-rw-r--r-- 1 pi pi 2 Dec 6 18:16 devices.json

Der CAN-BUS ist ja für die PV-Anlage, das Kabel/der Adapter am E380 angeklemmt. Sind denn die (Datenpunkte ?)-Dateien für PV Anlage aufgesetzt?

PS Offtopic
Wie bekomme ich beim Erstellen eines Posts direkt die 2. Formatierungszeile, um zB cmdline Details sauber zu formatieren. Über den Umweg der Editierung des "neuen" Beitrags ist das ziemlich doof 😟

[ghNeandr]

>> liefert candump denn wieder was?

tote Hose

[HerrP]

also nochmal zum Verständnis: Du hast nix geändert ausser das Kernel Update gemacht? und vorher ging alles (ausser dem Timeout ab und an) und jetzt geht nix mehr - richtig? auch nach einem update upgrade nicht?

>> Wie bekomme ich beim Erstellen eines Posts direkt die 2. Formatierungszeile,

das hab ich auch noch nicht raus 😕

[GW3]

Ich hab gerade das Update mit

sudo rpi-update rpi-6.2.y versucht und bekomme die Meldung:

*** Invalid hash given

Kann es sein, dass es dieses Update nicht mehr gibt. Könnte mir jemand das genau Commando geben mit dem ich es versuchen kann! Danke

[HerrP]

hm ich bin absoluter Linux Banause (keine Ahnung...) ich würde es mit

sudo apt-get dist-upgrade

(hierher geholt: https://www.elektronik-kompendium.de/sites/raspberry-pi/2002041.htm  wahrscheinlich uralt  )

STOP! Das dist-upgrade upgraded auf dei neueste Betriebssystemgeneration. das würde ich dann doch lassen.

[HerrP]

was hast du denn eigentlich jetzt für ein System am laufen? Bullseye? Bookworm? 32bit? 64bit?

[GW3]

Ist das Standard 64Bit System für den Raspberry 4b. Bin gerade für 2h im Meeting danach kann ich genauer schauen. Danke schon mal

[HerrP]

hast du noch ein reboot gemacht? Chat GPT sagt manchmal repariert sich das System damit selber auf den letzten stabilen Zustand...

ansonsten

sudo apt-get update
sudo apt-get upgrade

versuchen und wenn das nicht hilft eben doch neu aufsetzen...

[HerrP]

hilfe jetzt bin ich auch noch durcheinander. @GW3  lass das bitte erstmal mit dem Kernel Update. das hat bei @ghNeandr erstmal alles 'abgeschaltet'....

[HerrP]

@ghNeandr  hier noch was von Chat GPT:

Der Befehl rpi-update wird normalerweise verwendet, um den Kernel deines Raspberry Pi zu aktualisieren. Es wird nicht von Raspbian (bzw. Raspberry Pi OS) empfohlen, diesen Befehl ohne spezifische Gründe oder Anleitung zu verwenden, da er auf nicht stabilen oder experimentellen Kernel-Versionen basieren kann. In der Regel reicht es aus, die regulären Systemaktualisierungsbefehle wie apt-get update und apt-get upgrade zu verwenden.

[ghNeandr]

>>was hast du denn eigentlich jetzt für ein System am laufen? Bullseye? Bookworm? 32bit? 64bit?

__ uname / os / firmware ________________
Linux rpixyz 6.1.65-v7+ #1703 SMP Tue Dec 5 16:20:29 GMT 2023 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
Raspberry Pi 2 Model B Rev 1.1

[ghNeandr]

Alle Versuche scheitern im Moment.
Leider habe ich den Fehler gemacht diese CAN Story auf meinem Produktivsystem zu machen. Und es zeigt sich einmal mehr "Never touch ... "  😖
Werde für heute mal Schluß machen und morgen auf einem anderen RPI/SDCard neu anfangen. Dann wird sich herausstellen ob's an CAN-BUS HW/Adapter etc liegt.

See you 👋

[GW3]

Ich habe folgendes:

Debian GNU/Linux 12 (bookworm)

Linux raspberrypi 6.1.0-rpi4-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.54-1+rpt2 (2023-10-05) aarch64 GNU/Linux

[Thomas_MG]

Hatte danach die Posts danach gelesen die gleiches Problem haben. Habe natürlich auch rpi update gemacht und danach alles zerschossen. Hab mich dann kurz entschlossen den PI neu aufzusetzen. Gibt ja Übung 🙂

Alles lief und dann kam das timeout wieder. Aber bei nur auf dem 2. Adapter (der an der PT2). Zum Schluss sogar alle paar Minuten. Daraufhin habe ich in den args den timestep rausgenommen (cmnd listened ja nur bei Änderungen - mein Verständnis). Jetzt läuft der durch (seit 1h). Der erste Adapter (vcal) läuft auch mit dem timestep und cmnd durch. Vielleicht hilft das ja bei der Fehlersuche.

Achse: eins noch: Habe mir die Version aus der develop branch geholt.

[Juergen-B]

Der Listener-Mode (z.B. -l open3e/cmnd) lauscht auf Kommandos, die auf dem MQTT-Topic open3e/cmnd hereinkommen. Falls da nichts kommt, macht der Mode: nichts.

Es kann also keine Timeouts geben, wenn Du nur den Listener-Mode startest und keine Kommados per MQTT schickts.

[Thomas_MG]

🙈Sorry. War mir nicht klar. Hab jetzt den listener mode raus genommen und den timestep wieder eingefügt. Jetzt läuft es schon seit 10 Minuten. Ich verstehe es nicht....

[HerrP]

wie gesagt, ich habe eben (ca. 19/19:30h) die abgefangenen Exception von nur TimeoutError auf (TimeoutError, TimeoutException) erweitert. Etwa ne halbe Stunde vorher hatte ich das Exception Abfangen auf die -r Geschichte erweitert, vorher war das nur bei Listener Mode Reads der Fall.

Die Hoffnung ist also berechtigt, das das Skript jetzt nicht mehr 'abstürzt', sondern einfach garnix passiert wo vorher der Absturz kam. Aber es kommt dann eben auch kein Wert, aber dann hoffentlich beim nächsten mal (wenn mit timestep / zyklischer Abfrage gearbeitet wird).

Das alles betrifft nur die Open3Eclient.py im develop branch, sich die zu holen reicht also.

Eine Fehlersuche ist hinfällig, da die Ursache des Fehlers längst geklärt ist und nichts mit Open3e zu tun hat. Es handelt sich um einen Bug im ISO-TP Kernel, der etwa April dieses Jahres 'eingezogen' ist und zu einer Race Condition führt, die mal so, mal so ausgeht (und wenn sie so ausgeht kommt es zu dem Timeout). Der Bug wurde kurz nach der Entdeckung beseitigt (keine Ahnung wann), aber dieser Fix muss in den Distributionen ankommen um wirksam zu werden, was regulär scheinbar bei den aktuellen Raspbians noch nicht der Fall ist.

Ein relativ sicherer Weg zur Vermeidung des Timeout Problems ist es, ein altes System (also von vor April dieses Jahres) zu benutzen. Buster zum Beispiel ist alt genug 😁 Allerdings muss man bei Buster auch ein update-upgrade machen, damit Open3E überhaupt damit läuft. Dazu muss man auch irgendwie eingreifen, da das per Default auf einem 'outdatet' System gesperrt ist. Leider habe ich die genauen Schitte hierzu nicht aufgeschrieben, aber wenn man nach der Meldung googelt, bekommt man die Lösung.

Eine weitere Lösung soll in der 'out-of-tree isotp driver' Implementierung bestehen, was hier beschrieben ist. Allerdings möchte ich nicht meine Hand dafür in's Feuer legen, dass das mit Bullseye oder Bookworm funktioniert.

Was eventuell funktionieren könnte, wäre ein Kernel Update per

sudo rpi-update

oder noch experimenteller per

sudo rpi-update next

Hierbei werden "in der Entwicklung befindliche Kernel-Versionen" installiert, die noch nicht das Siegel 'stable' tragen, aber hoffentlich schon den ISO-TP Bug Fix enthalten.

Wie gesagt - ich bin mit Buster rundum glücklich. Gibt's aber glaubich nur in 32bit, also nix für 8GB RAM

[Thomas_MG]

Danke für die Erläuterung. Ich habe mir jetzt einfach ein Script geschrieben das denn Open3Eclient immer wieder startet wenn er abstürzt. Komischerweise stürzt nur die 2.instanz immer ab. Die erste läuft durch. Vielleicht läuft sie auch noch nicht lange genug. Ich beobachte und berichte. 

[HerrP]

gute Sache 😉  keine Ahnung, warum es nur in der 2. Instanz auftritt. Aber um ehrlich zu sein, haben wir mit zwei Instanzen auch noch nicht so viel Erfahrung. Vielleicht ist das ja ein anderes Problem....

ich hab die Open3Eclient.py nochmal upgedatet, weil die udsoncan Exception "TimeoutException" im client nicht bekannt ist und ein Fehler im exception handler verursachte. 😣

jetzt wird alles getrappt, was ein "timeout' im Namen hat... noch größerer Pfusch als alles vorher, aber ist getestet und funktioniert jetzt hoffentlich auch bei euch.

[Thomas_MG]

Danke. Hab die neue Open3Eclient.py aus dem develop branch geholt und sie läuft. Liefert in der 2. Instanz alle 20s eine timeout, läuft aber weiter und liefert Daten. Damit kann ich leben bis die Kernel aktualisiert sind.

Danke nochmal. LG