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

[HerrP]

@jokermic  du sagst du schaltest über die API die Heizung aus und nur bei Bedarf an; d.h. du wechselt nicht zwischen Reduced und Normal (was durch die Heizzeiteinstellungen gleich wieder überschrieben wird), richtig?

Das hiesse du muss für aus den Mode auf 00 setzen und für an dann auf 01. Das müsste eigentlich funktionieren.

Die Meldung "Writing not allowed on this did" kommt davon, dass der DID nicht in der white list steht. du musst ihn da einfach rein schreiben und dann kannst du ihn auch mit dem ioBroker Adapter schreiben.

[HerrP]

@har1  'das ging nicht' - was heisst das? der Wert wurde aber übernommen, oder? sonst dürfte eigentlich nicht "success: True, code: 0" kommen. Wenn es doch kommt und der Wert trotzdem nicht geschrieben wird, müssen wir da noch mal gucken!

000a00000a00 und 010a00000a00 sind ja unterschiedliche Werte, von daher Unterschied im Verhalten schon erklärbar (ich hab jetzt grad die Bedeutung der Bytes nicht im Kopf...)?!

[jokermic]

@HerrP  genau. ich schalte die Nachts komplett aus und dann ein. Ein Wechsel der Betriebsarten nutze ich noch nicht. 

Ja, das umstellen über Mode hat halt noch nicht funktioniert. 

Wo meinst du das mit der Whiteliste einstellen? Direkt im iobroker oder github?

[har1]

HerrP

Meister III

der Wert wurde nicht übernommen , weder  00a6ff00ecff    noch  000a00000a00   wurden übernommen.

Die orginal  Parameter   waren   2426  = 01a6ff00ecff   und   2427 =  010a00000a00 

.

                     die Ausgabe war :

write 1664.2426 = 000a00000a00    success: True, code: 0.     

die Ausgabe     .......success: True, code: 0.   hatte ich auch, als ich beim Parameter 919  einen kleineren Wert als   b400       180 min  versucht hatte. Die Werte wurden nicht übernommen.
                                   

Der Parameter  2426 hat aber den Wert vom Parameter 2427 angernommen. 

Damit hat der Parameter  2426 keine große  Relevanz mehr.  Das reicht mir vollkommen.

Seitdem ich Viessmann habe , bin ich bescheiden und schnell zufrieden geworden. 

[jokermic]

@HerrP ah, du meinst sicherlich in der lokalen Datei unter /lib/didsE3Writables.json.

Das habe ich hinzugefügt, aber es klappt leider noch nicht. Muss ich da außer einem Neustart noch was machen?

[Dreman]

@HerrP  Nur zur Info: die oben von @har1  genannten Werte für Parameter 2426 lassen sich schreiben und werden auch übernommen (getestet durch nachfolgendes auslesen).

[Dreman]

@har1  Kleinere Werte als 180 Minuten (b4 00) für Parameter 919 werden nicht übernommen (ohne jede Fehlermeldung). Der Grund dafür ist bisher unbekannt.

[Juergen-B]

@jokermicBitte schau mal in den Objektbaum in ioBroker. Da gibt es einen State "e3oncan.0.VC252A_HPMUMASTER_0x680.info.udsDidsWritable". Du musst den Datenpunkt 1415 in diesem State ergänzen. Beim Speichern darauf achten, dass das Kästchen bei "Bestätigt" **nicht** angehakt ist.

Nach dem Speichern des Statest sollte das Schreiben auf 1415 funktionieren.

[jokermic]

@Juergen-B ah, hier macht man das. Hab ich eingetragen und klappt jetzt auch. Danke für den schnellen Support!

[har1]

Dreman

Guru

                                                   

du hast Recht,  die Werte 00  beim Parameter 2426 (000a00000a00) werden übernommen. 

Das sind meine ersten Schritte mit Linux und  leider schleichen sich da noch einige Anfängerfehler ein.

Ich konnte aber  die  Werte ändern und auch kontrollieren.

        

[HerrP]

@jokermic  @ alle >> Wenn du noch mehr Infos brauchst, dann melde dich einfach.

ich hab jetzt die Codecs für DIDs 1415-1422 angepasst. Es gibt aber noch weitere:

531 : O3EComplexType(2, "DomesticHotWaterOperationState",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
537 : O3EComplexType(2, "ExternalMixerOneCircuitTargetOperationMode",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
538 : O3EComplexType(2, "ExternalDomesticHotWaterTargetOperationMode",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
921 : O3EComplexType(2, "ExternalAccessInProgress",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
1605 : O3EComplexType(2, "GatewayExternalHeatEngineTargetOperationMode",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
1612 : O3EComplexType(2, "ExternalMixerTwoCircuitTargetOperationMode",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
1613 : O3EComplexType(2, "ExternalMixerThreeCircuitTargetOperationMode",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
1614 : O3EComplexType(2, "ExternalMixerFourCircuitTargetOperationMode",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),
2806 : O3EComplexType(2, "RefrigerationCircuitOperationMode",[O3EByteVal(1,"Mode"),O3EByteVal(1,"State")]),

könntet ihr bitte mal ausprobieren (falls die External... bei irgendwem überhaupt 'funktional' sind), ob da auch die Listenwerte anzuwenden sind?!

"OpModes" : {
0: "Off",
1: "Heating",
2: "Parallel Operation: Heating HotWater",
3: "Parallel Operation: Heating Cooling",
4: "TestMode",
5: "Cooling",
255: "Automatic",
},

"OpStates" : {
0: "Current", <-- ?? Wert doppelt vergeben?
0: "ShutDown",
1: "Reduced",
2: "Normal",
3: "Comfort",
5: "Fixed Value",
6: "Antifreeze protection",
7: "Energy Save: reduced",
8: "Energy Save: normal",
9: "Energy Save: comfort",
10: "Cooling: normal",
11: "Cooling: comfort",
12: "No request",
},

danke & Grüsse!

[MarcelW]

Hallo @HerrP,

kurzes Feedback zum "develop"-Branch: Vielen Dank an euch! Mit der Umstellung auf python-can habe ich open3e jetzt bei mir zum Laufen gebracht (nach dieser Anleitung).

Umgebung: Raspberry Pi 4 mit OpenMoko, Inc. Geschwister Schneider CAN adapter und Vitocal 252. Nichts weiter installiert; nur open3e ausgecheckt und Python-Module installiert.

Was genau vorher (im "master"-Branch) das Problem war, kann ich nicht ganz nachvollziehen. Auf jeden Fall funktioniert jetzt alles. 👍

Hier mal das Vorher-Nachher-Log am Beispiel Außentemperatursensor:

(open3e-venv) marcel@vitocal:~/open3e $ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
(open3e-venv) marcel@vitocal:~/open3e $ python3 Open3Eclient.py -dev vcal -v -r 274
Traceback (most recent call last):
File "/home/marcel/open3e/Open3Eclient.py", line 320, in <module>
ecu = Open3Eclass.O3Eclass(ecutx=deftx, doip=args.doip, can=args.can, dev=args.dev)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/marcel/open3e/Open3Eclass.py", line 104, in __init__
self.uds_client.open()
File "/home/marcel/open3e-venv/lib/python3.11/site-packages/udsoncan/client.py", line 134, in open
self.conn.open()
File "/home/marcel/open3e-venv/lib/python3.11/site-packages/udsoncan/connections.py", line 329, in open
self.tpsock.bind(self.interface, rxid=self.rxid, txid=self.txid, *self.tpsock_bind_args, **self.tpsock_bind_kwargs)
TypeError: socket.bind() got an unexpected keyword argument 'rxid'
(open3e-venv) marcel@vitocal:~/open3e $ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
(open3e-venv) marcel@vitocal:~/open3e $ python3 Open3Eclient.py -dev vcal -v -r 274
vcal 274 OutsideTemperatureSensor {"Actual": 5.9, "Minimum": 0.0, "Maximum": -0.1, "Average": 5.9, "Unknown": 0}
closing 0x680 - bye!

[HerrP]

top, danke auch dir für die Rückmeldung!

Die Probleme, die mit der 'alten' Lösung bestehen, sind abhängig von Kombinationen von Versionen des Kernels und gewisser Bibliotheken. 'Am Anfang' hatte das ja auch alles funktioniert. Dann kam ein Update des IsoTP Kernels, und das Unheil hat seinen Lauf genommen - Versuche, mit Updates auf das Update zu reagieren, was weitere Rattenschwänze von Inkompatibilitäten in unterschiedlichen Kombinationen nach sich gezogen hat...

Wir haben jetzt eine Abhängigkeit 'ausgeschaltet', in dem die Kommunikation den IsoTP Kernel nicht mehr benutzt. Dadurch ist es unmerklich langsamer geworden, aber es funktioniert jetzt offensichtlich wieder zuverlässig. Die meisten beteiligten Abhängigkeiten sind jetzt 'durchsichtiger' (interpretierter...) Python Code.

Es kann jedoch niemand ausschliessen, dass durch ein zukünftiges Update irgendeines weiterhin oder neuerdings  beteiligten 'Teil des Ganzen' wieder irgendwas nicht mehr funktioniert.

Nicht umsonst wird immer wieder empfohlen, ein (Linux) System nicht ohne trefflichen Grund upzudaten - never touch a running system.

Dummerweise hängen die Systeme ganz überwiegend am Netz (sonst geht ja das ganze pip install und so nicht), und wenn es da eine Schwachstelle gibt, die nur durch ein Update geschlossen werden kann, ist guter Rat teuer. Genauso wenn man noch irgend was andres auf das System bringen will, was ein Update einer bestimmten Komponente benötigt um zu funktionieren.

Es gibt da glaubich irgendwelche 'Container Lösungen' oder virtuelle Maschinen, wo alle Abhängigkeiten mit der Anwendung in einem 'eigenen, geschlossenen Bereich' laufen, aber die bringen wieder andere Nachteile mit sich. Ich kenn mich da leider nicht genügend aus, vielleicht kann da jemand mehr zu sagen. Was ich aber aus dem Ganzen gelernt habe ist, dass ich nicht ohne Grund und die Möglichkeit zum Roll-back irgend ein Update mache, bei dem ich die Konsequenzen nicht überblicken kann.

[HerrP]

ps.

"Actual": 5.9, "Minimum": 0.0, "Maximum": -0.1, "Average": 5.9

sieht mir irgendwie komisch aus - haben wir da was vertauscht?!?

logisch wäre ja

"Actual": 5.9, "Average": 0.0, "Minimum": -0.1, "Maximum": 5.9

ist das bei anderen auch so komisch?

[tec]

Das kann ich bestätigen, ist für mich aber relativ irrelevant, da ich nur die "Actual" Werte alle 5s auslese.

[Juergen-B]

@tec @HerrP Ist bei mir bei 274 auch so. Einige andere Dids, z.B. 282, 284, sehen aber plausibel aus. Anscheinend kommen bei 274 die Werte in einer anderen Reihenfolge als bei den anderen Dids.

Sollen wir bei Viessmann ein Issue einstellen?

[tec]

@Juergen-B Es scheint ein Fehler zu sein, der bei Viessman wohl noch niemandem aufgefallen ist?

Mach das gerne, ich bin gespannt wie Viessmann darauf reagiert. 😅

[Dreman]

@HerrP.....ist das bei anderen auch so komisch?....

Kommt wahrscheinlich von der Vitodens-Reihenfolge, denn die liefert die Werte in der Byte-Reihung: Actual, Minimum, Maximum, Average.

[Juergen-B]

War nicht ernst gemeint 😎

Wenn ich eine Idee hätte, wo man bei Viessmann Issues zu diesem Thema einspeisen kann, wäre es aber schon eine spannende Sache. Vermutlich ist aber z.B. in den Wago Gateways bereits eine Ausnahme dafür implementiert 😂

[tec]

Das dachte ich mir schon 😅

Ein Issue Tracker wäre ja mal fortschrittlich! 🙈

Man stelle sich mal vor, das ein Hersteller, wenn er für offene Schnittstellen steht, alle Daten aus den Anlagen

darüber bereit stellt und dadurch hervorragend integrierbar ist auch davon profitieren könnte...

Ich hoffe ja inständig, dass Viessmann hier aufmerksam mitliest und das Potential erkennt.

Ich visualisiere die Daten und bin momentan dabei eine automatische Datenanalyse zu schreiben, die z.B. vor abweichenden Anlagenparametern/Sensorwerten, zum Beispiel zu vielen Kompressorstarts in $Zeit warnt.

[HerrP]

>>  Ein Issue Tracker wäre ja mal fortschrittlich!

Könnte es sein, dass der möglicherweise ziemlich schnell überlaufen würde?

>> Man stelle sich mal vor, das ein Hersteller, wenn er für offene Schnittstellen steht, alle Daten aus den Anlagen darüber bereit stellt und dadurch hervorragend integrierbar ist auch davon profitieren könnte...

Unser Reden! Und das hätte uns Mann-Monate oder vlt sogar -Jahre an Arbeit erspart. Aber dann würden wahrscheinlich wenigere Kunden* ihre Daten freiwillig rausrücken, und die Masse an Daten is echtes Gold wert! Man muss ja auch zugeben, dass Viessmann auf dieser Grundlage auch Problem-Früherkennung und sowas macht.

>> Ich hoffe ja inständig, dass Viessmann hier aufmerksam mitliest und das Potential erkennt.

Dein Wort in Viessmanns Ohr! Ein wenig Unterstützung könnten wir gut brauchen...

Grüsse!

Phil

ps: Reactive Power sind VA, nicht Watt 🤓 

[tec]

>> Könnte es sein, dass der möglicherweise ziemlich schnell überlaufen würde?

Gut möglich 😅

>> Unser Reden! Und das hätte uns Mann-Monate oder vlt sogar -Jahre an Arbeit erspart. Aber dann würden wahrscheinlich wenigere Kunden* ihre Daten freiwillig rausrücken, und die Masse an Daten is echtes Gold wert! Man muss ja auch zugeben, dass Viessmann auf dieser Grundlage auch Problem-Früherkennung und sowas macht.

Das auf jeden Fall, und das ist eben das Problem, das unsere Daten wertvoller werden als ein zufriedener Kunde mit dem Produkt wie einer Heizung.

>> Dein Wort in Viessmanns Ohr! Ein wenig Unterstützung könnten wir gut brauchen...

Das denke ich mir auch immer wieder. ^^

Technisch ist Viessmann ja wirklich qualitativ weit vorne, und sicherlich wird sich $normaler Kunde auch kein HomeAssistant, Grafana oder sonst welche offenen SmartHome Systeme installieren.

Der möchte einfach das es warm wird und bleibt.

Für unsere Zielgruppe, größere Projekte wie Mehrfamilienhäuser/Gewerbe, wo eine gute Integration in völlig andere (und oft nicht kompatible Systeme) entscheidend ist könnte sich Viessmann daher durchaus mit geringem Aufwand ein weiteres Alleinstellungsmerkmal schaffen.

Das sollten eben nicht vom Internet/Cloud abhängige Dienste und Anbieter spezifische APIs sein, insbesondere bei so grundlegenden Systemen wie Heizungsanlagen, welche bitte auch im Fall von Ausfällen der Internetanbindung weiter (mit Integrationen) funtionieren sollten.

Ebenso der Weg dem Kunden fast keine Einstellungsmöglichkeiten/Zugriffsmöglichkeiten auf >seine< Anlage zu geben, sondern ihn zwangsläufig von einem akkreditierten Installationsbetrieb und Viessmann abhängig zu machen.

Selbst mein (relativ großer) Heizungsbauer im Berliner Umfeld beschwert sich fortwährend über das Tooling das ihm von Viessman an die Hand gegeben wird...
Ein weiterer meinte, er rät seinen Kunden mittlerweile nicht mehr zu Viessmann sondern zu Vaillant, da er die Firmenpolitik und die Kommunikation sowie Dokumentation, Hotline katastrophal findet.

Das wird für Viessmann mit der Zeit sicherlich nicht zu mehr Verkäufen des Kernprodukts führen..

Vorreiter mit Offenheit und gutem Support zu sein ist meist einfacher als seine Entwicklungszeit in das zunageln von Produkten zu stecken.

-> Danke, das hatte ich noch übersehen! 😁

[10hans]

ich habe eine frage

bei der vitodens 300 w.

gibt es eine Adresse, mit der man die Frostgrenze auf - 9 oder noch weniger einstellen kann?

natürlich auf eigene Gefahr, aber das ist das Leben.

ich habe die liste durchgesehen, aber ich konnte es nicht eindeutig  identifizieren.

[Dreman]

Den Einstell-Bereich für die Parameter 2855 bis 2858 (Frostschutzkonfiguration HK1 bis HK4) findest du in der aktuellen Service- und Montageanleitung. Zusätzlich spukt wahrscheinlich der Parameter 2426 bis 2429 (HK1 bis HK4) auch noch in die Funktion rein, da es in beiden Parametern um das Ein-/Ausschalten der HK-Pumpe geht. Wahrscheinlich sind beide Parameter auf identische Werte einzustellen (z.B. -9 °C). Die Werkseinstellung ist jeweils +1 °C. Praktische Erfahrungen zu der Einstellung liegen m.W. nicht vor.

[10hans]

Vielen Dank