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
Wer es ausprobieren möchte: Hier gibt es eine Anleitung.
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
Super, danke fürs Ausprobieren. Ich kann das einbauen, aber erst Ende nächster Woche (bin grade im Urlaub).
Gruß, Jürgen
Ich bekam auch heute nachmittag eine Nachricht ueber einen neuen Beitrag von 15:40 von Dir, aber beim Klick auf den Link kam auf der Viessmann-Seite die Meldung, dass es die Seite nicht gebe...
>> Ich finde, dazu sollten wir im Readme auch nochmal ein oder zwei Sätze schreiben.…
Hallo Jürgen,
völlig richtiger und wichtiger Hinweis, mein Problem „negative response“ ist genau dadurch entstanden.
Habe mich unbemerkt in zwei verschiedenen Verzeichnissen bewegt.
Gruß Bu_Na
>> eine Nachricht ueber einen neuen Beitrag von 15:40 von Dir, aber beim Klick auf den Link kam auf der Viessmann-Seite die Meldung, dass es die Seite nicht gebe...
inzwischen ist es 3x aufgetaucht. ich hab die doppelten gelöscht. danke für die Info @FrankSteiner
@Bu-Na, @Juergen-B die Sache mit dem Hinweis auf die Verzeichnisse im ReadMe ist dringend angesagt, das ist wohl wahr. Mein Problem dabei ist, dass ich da selber nicht richtig durchblicke (jetzt ist ja auch noch Docker dazu gekommen), deswegen wäre es schön, wenn du @Juergen-B das dann auch machen würdest, wenn du wieder Gelegenheit hast!
Die Sache mit dem 2546 (und ...7/8/9) wahrscheinlich auch) könnte ich machen, ist ja wahrscheinlich nur ändern der strings/Bezeichnungen @Pillow ?
ich hab das mal gemacht mit den 2546/7/8/9. bitte schauen, ob die Reihenfolge passt, die scheint unterschiedlich zwischen o3e und vicare.
ich war auch so mutig, das letzte Byte als O3EEnum(1, "State", "OpStates") zu deklarieren - es wäre gut, wenn das jemand verifizieren könnte! Es könnte auch ein "RefrigerationCircuitOperationModes" sein...
Ich habe auch gleich die Erkenntnisse von wesch eingearbeitet, bitte auch testen.
Ist (aktuell noch) alles im develop branch.
danke schon mal!
ist das wirklich so einfach? mit "to use same working directory" könnte man ja auf die Idee kommen, man packt alles in ein Verzeichnis und gut is. Aber mit pip install und open3e als Aufruf wäre man dann ja immer noch auf dem Holzweg, oder? Wo installiert pip das nochmal hin?
@Bu-Na könntest du bitte noch mal beschreiben, wie du in die Falle getappt bist?!
Grüsse & schönen Urlaub weiter! 🙂
@HerrPJa, ich meine, es ist so einfach. pip install sorgt dafür, dass der Befehl open3e funktioniert, egal in welchem Verzeichnis man grade ist. Dann wird zuerst im aktuellen Arbeitsverzeichnis nach weiteren Dateien geschaut. Wo die von pip insallierten Dateien liegen, hängt davon ab, ob man mit venv arbeitet oder nicht. Ist aber auch egal, pip sorgt dafür, dass open3e und depictSystrm gefunden wird.
Ich frage sicherheitshalber bei Michael nach - gut möglich, dass ich's nicht richtig verstanden habe.
ich dachte pip installiert das irgendwo, und wenn man open3e aufruft, wird es da (im Installationsverzeichnis) ausgeführt, egal von wo man es aufruft? Wenn man jetzt grad die neuen Sachen irgendwo hin kopiert/geclont hat und da auch depictSystem ausgeführt hat (müsste ja eigentlich gehen?) wird trotzdem die 'alte' Version mit den alten datapoints_6xy im Installationsverzeichnis benutzt? Wie gesagt - ich blick da kaum noch durch...
@Bu-Na hier noch schnell die Bezeichnungen zu deinen neu gefundenen DIDs:
DomesticHotWaterCirculationPumpStatistical(3134),
TelemetryControlUnitTargetOperationMode(3188),
RefrigerantCircuitFourWayValvePosition(3190)
ExtendedEventLoggingHistory(3191),
CascadeSystemDomainRole(3194),
ThermalBufferDemand(3195),
DiagnosticSecondaryWaterPressureCheck(3198),
DiagnosticSecondaryWaterFlowDetection(3199),
HydraulicMatrixConfigurationTwo(3201),
RuntimeBalancingCounter(3211),
BivalentMixerDomesticHotWaterTemperatureOffset(3212),
ExternalHeaterTemperatureSensor(3213),
ExternalHeaterSeparatorTemperatureSensor(3215),
ThirdPartyDeviceName(3216),
EnergyMeterOne(3228),
EnergyMeterTwo(3229),
EnergyMeterThree(3230),
EnergyMeterFour(3231),
DomesticHotWaterBufferTopTemperatureSensor(3234),
DomesticHotWaterPumpMode(3237),
CompressorInverterOutputStatus(3285),
werden wir beizeiten einbauen. Wenn du Ideen zu der Kodierung hast - her damlt 😊
Alle neuen DIDs 3207..3293 in DidEnums.txt (wird von depictSystem benutzt) im develop Branch .
Grüsse! 🖖
@HerrPHabe es nochmal mit einer frischen Installation ausprobiert. open3e sucht die Datei devices.json definitiv im aktuellen Arbeitsverzeichnis. Wenn man einen Pfad mit angibt, z.B. ~/open3e/devices.json, wird dort gesucht. Das gleiche gilt für die Dateien, die innerhalb von devices.json angegeben werden (datapoints_6xy.py).
Aus meiner Sicht stimmt die Beschreibung im Readme und wir können develop nach master mergen. Wie sieht es mit der Datenpunktliste aus? Muss da vor dem Mergen noch was gemacht oder getestet werden?
ich hab die Datenpunkt-Bezeichnungen aus der neuen viguide in die datapoints.txt geschrieben. wir könnten von Bu_Nas Auslesung die Länge nehmen und das in die generelle datapoints schreiben. bringt aber auch nicht viel, weil wir eh die Codierung noch nicht kennen, läuft also so oder so auf RawCodec raus, nur dass es einmal in der generellen datapoints steht, oder anders eben in den datapoints_6yz. Hat also meiner Meinung nach keine Eile, wir können so mergen.
@HerrPMerge ist erfolgt.
hab ich gesehen, danke!
sh..., die Sache mit den Zeilenumbrüchen (jetz in develop reingemacht) habe ich erst in der Merge Vergleichsansicht gesehen. Aber du hattest das ja ohne Probleme gestartet, oder? vlt war es auch nur eine Lf/CrLf Angelegenheit...
Was meinst Du genau? Ich habe nur die Auswertung der devices.json getestet. Datenpunkte habe ich dabei nicht abgerufen (habe nur geschaut, an welcher Stelle mit welcher Meldung abgebrichen wird). Was muss konkret getestet werden? Ein bestimmter Datenpunkt?
vor 2942 und 3107 fehlte der Zeilenumbruch
https://github.com/open3e/open3e/commit/0ffa6eff982666134ac25f10c3583f8041fbd196
getestet werden müsste ob die trotzdem richtig erkannt wurden (wobei der Zeilenumbruch jetzt ja drin ist und das ja ein List ist, wo eigentlich das Komma zählt).
Getestet werden sollte eigentlich auch noch, ob die 2940 und 3106 jetzt richtig decodiert sind, aber das geht ja nur mit @Bu-Na 's Firmwareversion
Sieht aus meiner Sicht gut aus…
Gruß Bu-Na
schön, danke!
@HerrP Hier noch sechs Vcal-DID-Definitionen zum Einpflegen:
1842 : O3EComplexType(2, "SecondaryCircuitFourThreeWayValve", [O3EInt8(1, "Setpoint", signed=True), O3EInt8(1, "CurrentPosition", signed=True)]), #250-xH Unit: %
3098 : O3EInt8(2, "ExternalHeaterTemperatureOffset", scale=10), #250-xH Unit: K
3212 : O3EInt8(2, "BivalentMixerDomesticHotWaterTemperatureOffset", scale=10), #250-xH Unit: K
3213 : O3EComplexType(9, "ExternalHeaterTemperatureSensor", [O3EInt16(2, "Actual", signed=True), O3EInt16(2, "Minimum", signed=True), O3EInt16(2, "Maximum", signed=True), O3EInt16(2, "Average", signed=True), O3EByteVal(1, "Unknown")]), # Unit °C
3215 : O3EComplexType(9, "ExternalHeaterSeparatorTemperatureSensor", [O3EInt16(2, "Actual", signed=True), O3EInt16(2, "Minimum", signed=True), O3EInt16(2, "Maximum", signed=True), O3EInt16(2, "Average", signed=True), O3EByteVal(1, "Unknown")]), # Unit °C
3234 : O3EComplexType(9, "DomesticHotWaterBufferTopTemperatureSensor", [O3EInt16(2, "Actual", signed=True), O3EInt16(2, "Minimum", signed=True), O3EInt16(2, "Maximum", signed=True), O3EInt16(2, "Average", signed=True), O3EByteVal(1, "Unknown")]), # Unit °C
Gruß Bu-Na
supi, danke! mach ich.
@HerrP und nochmal zwei DIDs:
2580 : O3EInt8(2, "CompressorSetpointRps", signed=True), #250xH Unit RpS
3019 : O3EComplexType(9, "CompressorOutletTargetTemperature", [O3EInt16(2, "Actual", signed=True), O3EInt16(2, "Minimum", signed=True), O3EInt16(2, "Maximum", signed=True), O3EInt16(2, "Average", signed=True), O3EByteVal(1, "Unknown")]), # 250xH Unit °C
Leider nur über die VCMU abrufbar.
Macht es Sinn, bei der Scanall Option von Open3e alle ECUs abzufragen?
Gruß Bu-Na
danke! ich arbeite die neuen DIDs auch noch ein.
> Macht es Sinn, bei der Scanall Option von Open3e alle ECUs abzufragen?
du meinst man sollte noch die Möglichkeit einbauen, alle DIDs von nur einer bestimmten ECU zu lesen? das wäre bestimmt ohne grossen Aufwand möglich...
ps. streng genommen müsste es eigentlich schon gehen, wenn man mit
open3e -a --ecuaddr 0x68c -dev open3Edatapoints_68c.py
oder
open3e -a -tx 0x68c -dev open3Edatapoints_68c.py
aufruft? aber es geht auch einfacher... (wenn man es einbaut) 😉
Hallo alle! Ich versuche ja immer noch den VX3 dazu zu bringen forciert (und schnell) zu laden. Hat eigentlich vielleicht noch jemand hier eine GridBox aktiv und kann da mal das prognosebasierte laden einschalten und dann schauen was im VX3 sich in allen Registern ändert? Eventuell findet man so die passenden DIDs um eine externe Steuerung zu ermöglichen... Nur eine Idee 😊
aber dann müsste es ja auch ein 'günstige' Prognose haben, oder? @Juergen-B hast du das nicht schon im Griff mit dem Laden?
@cafe88Das ist eine sehr gute Idee. Da ich keine GridBox habe, kann ich das leider nicht ausprobieren.
@HerrPHabe das Thema im Zusammenhang mit der BackupBox angeschaut, die Ergebnisse habe ich hier bereits kommuniziert. Andere Ansatzpunkte sehe ich aktuell nicht. Gibt es da Ideen (außer über die GridBox)?