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 einfachen Daten wie z.B. Warmwasser-Solltemperatur und so auch schon erprobt.
- In nicht all zu ferner Zukunft wird es eine einfache Windows Oberfläche zum Setzen der bisher den 'Fachpartnern' mit entsprechendem kostenpflichtigen Account vorbehaltenen Einstellungen wie zum Beispiel den "Energiespareinstellungen" bei den Gasgeräten geben.
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
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
Error Passive State:
- In the error passive state, the node remains connected to the bus but restricts its participation in communication.
- The node stops actively transmitting messages but continues to listen to the bus.
Dabei kann open3e nicht mehr funktionieren, weil es Anfragen rausschickt um zu funktionieren.
re-started bus-errors arbit-lost error-warn error-pass bus-off 0 0 0 102929 3138478 2950268
die error counter sind viel zu hoch. Davon kommt das auch, dass der Adapter in Error Passive State geht.
leider ohne Zeitstempel, aber ich vermute mal nicht lange später
re-started bus-errors arbit-lost error-warn error-pass bus-off 0 0 0 114977 3483140 3303651
die error counter schon wieder merklich angestiegen.
Da die Baudrate ok ist, und ich nicht annehme, dass du an den Timing Registern irgendwas geändert hast, bleibt nur noch ein Problem im Physical Layer. Ich bin mir nicht sicher, ob fehlerhafte Buswiderstandswerte das gleiche Bild hervorrufen, aber da passt was mit deiner Verdrahtung nicht.
Buswiderstände hast du doch genau 2 Stück draufgeschaltet (1 an VX3 und 1 am Adapter) richtig?
Wenn es das nicht ist, bleibt nur noch das Potential / GND Problem, oder an der Elektronik von deinem Adapter ist ein Teil kaputt (teilweise funktioniert er ja).
Wie gesagt - ein potentialfreier CAN Adapter braucht ein Bezugspotential. Es sieht für mich alles danach aus, dass genau das fehlende Bezugspotential das Problem ist. Das komplette Bild passt: Erst 'sieht' der Adapter dauernd geklippte Signale und ruft noch "Hilfe! Error! Hilfe!", danach läuft der Fehlerzähler so voll, dass er nicht mehr weiter schreien darf, weil er dadurch die ganze Kommunikation blockieren würde (Active Error Frames sind sehr dominant!) und er winselt nur noch 'passiv' vor sich hin... So funktioniert das bei CAN, seit über 30 Jahren...
Hol dir den CAN_GND von der VX3 und die Welt ist wieder in Ordnung. 🙂
Hab die Wartezeit gerade auf 2 sek hochgesetzt und nochmal depict laufen lassen - wieder exakt beim gleich did "ERROR max retry" und dann immer weiter so bis zum Abbruch. Der 2. Durchlauf dann wieder ohne Fehler.
Zur Präzisierung: Es war jetzt beide Male bei 0x684 : HMI. Der erste did 256 wurde noch korrekt gefunden, die nächsten paar wurden (da nicht vorhanden richtigerweise) nicht gefunden. Der nächste zu findende did ist auch korrekt 265, dort nun aber mit error. Der nächste zu findende did unter HMI wäre erst wieder 575. Hier mal ein screen:
Ich würde jetzt dann erst mal so laufen lassen und mich beim ersten TimeoutException melden was passiert ist - oder gibt es noch etwas was ich probieren kann?
Moin!
das sieht ja so aus als würde das HMI (0x684) irgendwann (?!) darauf verzichten, eine Negative Response zu geben wenn ein angefragter Datenpunkt nicht existiert. Das ist natürlich äusserst hinderlich, weil ich beim DID Scan den p2_timeout auf 3 Sekunden hochgesetzt habe, und das dann auch noch 4x versucht wird -> gut 12 Sekunden pro Datenpunkt - da dauert der Scan natürlich ne halbe Ewigkeit (3250*12sec = gut 10 Stunden). [edit] alles Blödsinn - eher wahrscheinlich dass sich die ISO-TP Geschichte weggehängt hat... Hast du zufällig einen candump mitlaufen lassen? das ist immer sehr hilfreich bei sowas!
Das hier hab ich von einer 250A10 0x684 bei uns aus der Gruppe:
Da wäre der nächste existierende DID nach 256 dann der 575. Bist du sicher, dass es bei dir die 256 (ErrorDtcList) im HMI gibt? Hast du schon mal versucht, die einzeln auszulesen?
Die Frage ist jetzt, was den 'Schalter umlegt', dass entweder keine Antwort mehr geschickt wird oder dass sich die Sache 'rechnerseitig' weghängt und wie man das dann wieder zurück gestellt bekommt. Im zweiteren Fall würde ich mal
ipconfig can0 down -> up
versuchen...
Aber klar ist, dass das so auch keine Lösung ist. Sollten die Software Gurus doch Recht haben?!?
ps. danke überhaupt für den Test mit den 2 Sekunden vorm Retry! Leider bringt es ja anscheinend alles nix...
Wenn ich versuche den 256 einzeln auszulesen kommt:
depict zeigt halt "found" an, deswegen dachte ich es gäbe ihn...
Bzgl. candump faszinierende, wenn auch wenig hilfreiche Ergebnisse. Während Candump parallel läuft hat er bei mir jetzt konsequent (3x probiert) mit folgendem error bei genau diesem did abgebrochen:
Nachdem candump beendet war lief depict dann wieder entweder sauber durch oder mit besagtem "error may retry" ab besagtem did.
can0 down=>up ist wie gesagt nicht notwendig damit es wieder funktioniert. Es läuft ja auch sofort nach Neustart von open3e wieder einwandfrei bis zum nächsten error, sofern open3e aber einmal im error "gelandet" ist kommt er halt nicht mehr raus.
Als depict dann nur noch den "error may retry" ausgeworfen hat habe ich ich sofort nach beenden den prozess wieder gestartet und dann lief es wieder. Gleiches mit TimeoutException - als ich open3e über try/except habe weiterlaufen lassen kamen keine Daten mehr. Nach process-kill und direktem Start von open3e ging alles wieder.
Insofern sieht es für mich als Ahnungsloser so aus als würde sich open3e (bzw. dessen Zugriff auf isotp o.ä.) verschlucken. Woran das nun aber liegt (bzw. welche Systembedingungen bei mir/uns dazu führen dass das passiert) ist mir leider ein Rätsel 😔
Workaround ist halt Neustart des scripts, aber die Ursache würde mich schon echt interessieren und in Anbetracht der Tatsache dass ich es mit verschiedenen älteren und neueren Kernels ausprobiert habe lässt mich vermuten dass es sich nicht alleine erledigt. Zur Erinnerung: mein aktueller Kernel ist vom 29.11.23 und die "klassischen" TimeoutErrors sind da bereits gefixt und treten nicht mehr auf.
Hier falls es jemandem hilft die Home Assistant YAML Sensor Config für den Aussentemperaturfühler bei der Vidodens (nur als Beispiel):
mqtt:
sensor:
- name: "Heizung_Aussentemperatur"
unique_id: "Heizung_Aussentemperatur"
state_topic: "open3e/OutsideTemperatureSensor/Actual"
unit_of_measurement: "°C"
state_class: measurement
device_class: temperature
Ergibt:
