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
Denke, die args passen schon. Die erste Fehlermeldung besagt, dass eine ungültige Payload empfangen wurde. Sieht so aus, als wäre die Payload leer.
Wie sieht das MQTT-Kommando aus, das Du mit dem Topic open3e/cmnd sendest?
@Hotzen-Plotz ich würde auch auf ein falsches MQTT Kommando tippen. Btw: mit dem o.a. Formatstring sollte das Empfangstopic open3e/2457_CalculatedOutsideTemperature sein - oder?
@Juergen-B schrieb:Wie sieht das MQTT-Kommando aus, das Du mit dem Topic open3e/cmnd sendest?
Ich versteh Deine Frage sprachlich nicht. Was meinst Du damit? Was ist ein MQTT-Kommando?
Ich habe jetzt auch einen anderen Fehler.
Zutaten:
args:
--can
can0
--dev
vdens
--mqtt
127.0.0.1:1883:open3e
--mqttformatstring
{didNumber}_{didName}
--listen
open3e/cmnd
--config
devices.json
-v
Kommandozeile:
python Open3Eclient.py @args -r 268 -m 127.0.0.1:1883:open3e -t 60 -muser xxx:xxx
usage: Open3Eclient.py [-h] [-c CAN] [-d DOIP] [-dev DEV] [-tx ECUADDR] [-cnfg CONFIG] [-a] [-r READ] [-w WRITE] [-raw] [-t TIMESTEP] [-l LISTEN] [-m MQTT]
[-mfstr MQTTFORMATSTRING] [-muser MQTTUSER] [-j] [-v]
Open3Eclient.py: error: unrecognized arguments:
@Hotzen-Plotz ich schau mal rein ...
so geht es bei mir:
python3 Open3Eclient.py -c can0 -dev vcal -m 192.168.2.203:1884:open3e -mfstr "{didNumber}_{didName}" -v -l open3e/cmnd
du hast kein Leerzeichen zwischen -t 60 und dem -mfstr ...
Mir ist nicht klar, was Du machen möchtest. Wenn Du die Option -listen verwendest, gehe ich davon aus, dass Du Kommandos per MQTT nutzen möchtest. Z.B. topic="open3e/cmnd", payload="{"mode":"read","addr":"0x680","data":[268]}"
Falls Du nur Daten über die Kommandozeile abfragen möchtest, lass -listen bitte weg.
Zur Kommandozeile: Bitte die Daten aus args nicht wiederholen. Als Kommandozeile würde reichen:
python Open3Eclient.py @args -r 268
Und vermutlich solltest Du aus den args
--listen
open3e/cmnd
löschen.
Danke, ich will ja nur, dass die MQTT-Daten im iobroker ankommen wie bisher. Ich lass' jetzt erstmal dem Mumpitz mit der args Datei weg, bis ich weiss, was geht.
Mitlerweile bin ich soweit gekommen, dass der Befehl:
python Open3Eclient.py -c can0 -dev vdens -r 268 -t 60 -muser xxx:xxx
auf der Kommdaozeile erstmal wieder funktioniert ohne Fehler.
Dann bin ich jetzt auch soweit, dass der Syntaxfehler verursacht wurde dadurch, dass in den args "--listen" steht, aber es auf der Kommandozeile "-l" heissen muss. Für Deppen wie mich ein echter Stolperdraht.
Dann hatte ich attsächlich was doppelt in der Kommandozeile versus args, wie Du schriebst und mir fiel später auf, dass mir noch das -dev vdens fehlte. Lauter Feinheiten. Daher jetzt erstmal alles ohne args.
So schön es ist, dass die Kommandozeile zunächst keine Fehler wirft, kommt jetzt aber im iobroker nach wie vor nix mehr an. Ihr habt da irgendwas geändert, was da Einfluss hat.
Sobald ich nun das "-l open3e/cmnd" auf der Kommadozeile eingebe in der Hoffung, dass dies hilft, bekomme ich nun:
Traceback (most recent call last):
File "/opt/git/open3e/Open3Eclient.py", line 345, in <module>
listen(args.read, args.timestep)
File "/opt/git/open3e/Open3Eclient.py", line 129, in listen
raise Exception('mqtt option is mandatory for listener mode')
Exception: mqtt option is mandatory for listener mode
Tips hierfür?
Und noch zwei Varianten, die auf Fehler laufen. Ich habe jetzt die Option "-m MQTT" dazugeschrieben, die es vorher nicht gab/brauchte und von der ich auch keine Ahnung habe, was sie soll, aber es klang im vorherigen Fehler so, als ob das vielleicht verlangt würde.
python Open3Eclient.py -c can0 -dev vdens -r 268 -t 60 -l open3e/cmnd -m MQTT -mfstr {didNumber}_{didName} -muser x:x
Traceback (most recent call last):
File "/opt/git/open3e/Open3Eclient.py", line 332, in <module>
mqttTopic = mlst[2]
IndexError: list index out of range
python Open3Eclient.py -c can0 -dev vdens -r 268 -t 60 -m MQTT -muser x:x
Traceback (most recent call last):
File "/opt/git/open3e/Open3Eclient.py", line 332, in <module>
mqttTopic = mlst[2]
IndexError: list index out of range
Da es vorher klappte, wüsste ich auch nicht, was ich sinnvoll auf iobroker Seite ändern sollte:
Moin Hotzi!
Och Mensch, das tut mir leid, dass du jetzt wieder 'Terror' mit irgendwelchen Stolpersteinen hast! Aber du wirst das wie gehabt auch wieder hinbekommen, da bin ich mir sicher. 🙂
Das "-l" und "--listen" ist gleichbedeutend. Es gibt da immer ein kurze und eine lange Version des 'Kommandozeilenargument-Identifiziers'. Die lange hat 2x das 'Minus' davor, die kurze nur eins.
Das mit dem "bad payload" bekomme ich auch schon mal, z.B. wenn ich 'alles Löschen' im MQTT Explorer drücke. Das ist nicht schlimm, mehr informativ, dass da irgendwas war, was open3e nicht interpretieren konnte (und wahrscheinlich auch nicht sollte).
Wie soll das bei dir funktionieren? soll
a) open3e Werte zyklisch auslesen und die tauchen im MQTT Broker / der App dann auf
- oder -
b) die App schickt zyklische Anfragen über MQTT und open3e reagiert da drauf?
ps. und guck bitte zuerst unten wo das mit "ACHTUNG! ... Python Version 3 ..." steht! das wird einige Fallen schon mal umgehen
@Hotzen-Plotz die Option ist -m <ip addr>:<port>:<topicname> also zB -m 127.0.0.1:1883:open3e
oder?
bei a)
musst du (bezogen auf MQTT nur) die Option "-m" bzw. "--mqtt" angeben, damit die Daten im MQTT Broker ankommen können. Also z.B.
-m 127.0.0.1:1883:open3e
du kannst dann auch noch den Format String angeben, damit die Sachen so dargestellt werden, wie du das möchtest. für '2457_CalculatedOutsideTemperature' wäre das
-mfstr {didNumber}_{didName}
(das ist aber default und sollte dann eigentlich auch weggelassen werden können)
alles zusammen dann
-c can0 -dev vdens -muser ichuser:meinpwd -m 127.0.0.1:1883:open3e -mfstr {didNumber}_{didName} -t 60 -r 268,396
oder kürzer
-c can0 -dev vdens -muser ichuser:meinpwd -m 127.0.0.1:1883:open3e -t 60 -r 268,396
damit sollte es funktionieren.
ps. wenn du beim MQTT Broker kein Benutzer mit passwort angelegt hast, das "-muser ichuser:meinpwd" ganz rauslassen
@HerrP schrieb:Wie soll das bei dir funktionieren? soll
a) open3e Werte zyklisch auslesen und die tauchen im MQTT Broker / der App dann auf
- oder -
b) die App schickt zyklische Anfragen über MQTT und open3e reagiert da drauf?
Ich bin nicht mit einem Skillset ausgestattet, dass ich sagen könnte, was "soll"... Es soll einfach so funktionieren wie gestern noch.
Meine These (!) bisher war, dass open3e zyklisch per MQTT Daten sendet und der iobroker-MQTT-Adapter diese als Client annimmt, also Dein (a). Das ist aber nur die These von jemandem, der die Funktionsweise nicht sicher versteht.
wenn du b) benutzen wolltest, also open3e auch auf 'Kommandos' von deiner MQTT App (dem iobroker?) reagieren soll, musst du noch den Kommando-Topic, den der iobroker zum Verschicken von Nachrichten an open3e benutzt und auf dem open3e 'lauschen' soll ("listen"), hinzufügen:
z.B.
-l open3e/cmnd
ACHTUNG!! Ganz wichtig ist, dass du Python Version 3 aufrufts, also
python3 Open3E_depictSystem.py -c can0 ....
NICHT
python Open3E_depictSystem.py -c can0 ....
wenn das dann endlich funktioniert, kannst du das ganze Gebamsel aus der Kommandozeile
z.B. die von oben
-c can0 -dev vdens -muser ichuser:meinpwd -m 127.0.0.1:1883:open3e -t 60 -r 268,396
in Zeilen umbrechen und in die Datei 'args' (oder sonsteine) speichern
-c
can0
-dev
vdens
-muser
ichuser:meinpwd
-m
127.0.0.1:1883:open3e
-t
60
-r
268,396
und den Aufruf dann einfach so machen:
python3 Open3Eclient.py @args
Dabei muss die Datei (hier 'args') im gleichen Verzeichnis wie Open3Eclient.py stehen (oder du müsstest hinter dem '@' den ganzen absoluten Pfad angeben, aber das lassen wir besser)
ps. das mit dem in Zeilen Umbrechen ist nicht von uns sondern von der argsparser Library. ich hätte einfach eine Zeile auch 'handlicher' gefunden. Achte vorsichtshalber da drauf, dass am Ende der Zeilen keine Leerzeichen stehen (k.A. ob das wichtig ist, muss ich ausprobieren, aber nicht jetzt)
@HerrP schrieb:oder kürzer
-c can0 -dev vdens -muser ichuser:meinpwd -m 127.0.0.1:1883:open3e -t 60 -r 268,396damit sollte es funktionieren.
Leider nicht:
python Open3Eclient.py -c can0 -dev vdens -r 268 -t 60 -m 127.0.0.1:1883:open3e -muser x:x
Traceback (most recent call last):
File "/opt/git/open3e/Open3Eclient.py", line 358, in <module>
showread(addr=ecudid[0], value=val, idstr=idstr, did=ecudid[1])
File "/opt/git/open3e/Open3Eclient.py", line 239, in showread
publishStr = args.mqttformatstring.format(
AttributeError: 'NoneType' object has no attribute 'format'
Nur die längere Version scheint zu gehen:
"python Open3Eclient.py -c can0 -dev vdens -r 268 -t 60 -m 127.0.0.1:1883:open3e -mfstr {didNumber}_{didName} -muser x:x"
Glaube ich zumindest. Früher wurde das noch mit dem Text "Read dids and publish to mqtt..." quittiert, jetzt steht da wohl nur der Wert.
du kannst natürlich jederzeit das '-v' noch hinten dran hängen....
So, wenn es jetzt hoffentlich wieder läuft, läuft es so wie früher, und du hast noch keinen Nutzen von dem ganzen Aufwand gehabt (ausser vielleicht das mit dem @ args).
Das 'Tolle' an der neuen Version ist ja das Abbilden des ganzen Systems, also aller vom externen Bus erreichbarer Steuergerät. Nebenbei werden ja noch ggf. in der Open3EdatapointsVdens.py nicht oder 'unzulänglich' aufgeführte Datenpunkte erfasst und in der Open3Edatapoints_680.py hinterlegt. Das macht alles Open3E_depictSystem.py.
Aber wenn du das willst, sag Bescheid, und wir machen das dann, weil dich das jetzt wahrscheinlich eher verwirrt als belustigt 🙂
beste Grüsse & du bist echt klasse, dass du dabei bleibst, trotz der ganzen Widrigkeiten!!
Phil
ps. wir haben wirklich (wissentlich) nix bezüglich der Anwendung / des Aufrufens geändert ausser der user:password Sache...
So, die Kommandozeile scheint grundsätzlich zu funktionieren mit:
python Open3Eclient.py -c can0 -dev vdens -r 268,271,274,284,318,331,334,360 -t 60 -m 127.0.0.1:1883:open3e -mfstr {didNumber}_{didName} -muser x:x -v
Das python3 braucht es nicht (das ging vorher auch ohne).
Was Ihr definitiv auch geändert habt, ist die neue zwingende Notwendigkeit zu dem -mfstr.
Wenn ich das nicht angebe wirft es einen Fehler:
Traceback (most recent call last):
File "/opt/git/open3e/Open3Eclient.py", line 358, in <module>
showread(addr=ecudid[0], value=val, idstr=idstr, did=ecudid[1])
File "/opt/git/open3e/Open3Eclient.py", line 239, in showread
publishStr = args.mqttformatstring.format(
AttributeError: 'NoneType' object has no attribute 'format'
Leider stecke ich immer noch auf halber Strecke fest.
Denn zwar erkennt jetzt der Adapter im iobroker eine Verbindung:
Das hilft aber gar nix, denn die Daten tauchen nicht wie früher in der Objektliste auf, sind also nicht verfügbar. Da stehen noch die letzten Stände die mit dem alten Open3e angeliefert wurden.
Das wirkt auf mich so, als wäre die Struktur/das Format der ausgelieferten daten nicht mehr so wie früher, vor dem Scan und der neuen Version.
Vielleicht zeigt ioBroker die Daten auch bloß nicht an. Den Effekt hatte ich schon. Versuch mal, die Objekt-Seite in ioBroker im Browser komplett neu zu laden. Evtl. sogar Tab schließen und neues Tab öffnen.
Ansonsten empfehle ich den MQTT Explorer. Damit sieht man, was so alles an MQTT-Nachrichten unterwegs ist.
>> So, die Kommandozeile scheint grundsätzlich zu funktionieren mit:
python Open3Eclient.py -c can0 -dev vdens -r 268,271,274,284,318,331,334,360 -t 60 -m 127.0.0.1:1883:open3e -mfstr {didNumber}_{didName} -muser x:x -v
ACHTUNG! da steht immer noch python und nicht python3 !!
damit sind manche Sachen anders und nicht so wie gedacht! Es sieht erstmal so aus als würde es gehen, aber wie gesagt, es kommt dann zu so 'Unpässlichkeiten', es sei denn du hättest python als Alias für python3 definiert. Ich bin da auch schon 'gestolpert'...
>> File "/opt/git/open3e/Open3Eclient.py", line 239, in showread
publishStr = args.mqttformatstring.format(
AttributeError: 'NoneType' object has no attribute 'format'
da gucken wir noch mal, sollte aber eigentlich das benannte Default haben
>> Früher wurde das noch mit dem Text "Read dids and publish to mqtt..." quittiert,
das ist eigentlich auch heute noch so (wenn -l / --listen eingestellt wurde)
Danke für den Anstoss. Es ist der Wahnsinn in Tüten.
iobroker Objektseite neu laden hat nix gebracht.
iobroker Adapter neu starten hat nix gebracht.
Tab neu laden hat nix gebracht.
Iobroker komplett durchstarten hat nix gebracht.
Immer nix in der Objektliste. Objekte nicht in Charts verwendbar.
Dann habe ich in der Visualisierung mal ein Objekt eingefügt nur für die Anzeige eines Wertes. Dies verwendet anscheinend ein anderes Objektauswahl-Element als die Charts und da sind die Daten plötzlich wählbar. Also kommt der Kram irgendwo an. Nur nicht in der Objektlistenseite (was nicht hilfreich ist).
Jetzt: Browser zugemacht, in einem alternativen Browser aufgerufen: Alles da! 😁
Guter Ausgang. Alle Haare ausgerissen und Tischplatte zernagt.
Danke Euch für Eure tolle Hilfe und grundsätzlich für alles was Ihr hier auf die Beine stellt! 👍
Zur Doku: Letztlich läuft die Vitodens jetzt mit:
"nohup python Open3Eclient.py -c can0 -dev vdens -r 268,271,274,284,318,331,334,360,364,365,381,386,392,396,401,424,475,526,527,531,534,544,545,548,565,691,692,693,694,695,696,697,726,727,728,729,730,731,732,761,762,763,764,765,766,767,874,880,896,919,987,1008,1024,1087,1240,1395,1415,1503,1538,1539,1555,1643,1659,1667,2257,2320,2426,2457,2855,2937,2938 -t 60 -m 127.0.0.1:1883:open3e -mfstr {didNumber}_{didName} -muser xxx:yyy"
Ich muss dann jetzt im iobroker in den Grafiken und Skripten die ganzen Datenobjekte gegen die neuen austauschen. Das wird noch mal Aufwand bedeuten, aber ok.
juhuuu! 🙂
aber nach bestem Wissen und Gewissen - am Ausgabeformat und dem ganzen Topic Händling und so hat sich nix geändert. Irgendwo war da was mit irgendeiner Identifikation im Zusammenhang ich glaube mit dem Listener (wo jetzt ein Zeitstempel angefügt wird für Eindeutigkeit - nicht dass das uns 'den Hals gebrochen' hat?!?)
grad nachgeschaut - das Default von dem mqttformatstring ist tatsächlich irgendwo auf der Strecke geblieben. kommt wieder rein.
Hi,
es hat funktioniert. Habe meine IP eingetragen und das depictsystem lief durch und hat mir wohl von jedem busteilnehmer eine datapoint datei angelegt.
aber was ich damit jetzt mache und was das -cnfg devices.json dann bewirkt, das muss ich noch rausbekommen 🙂
benötigst du irgendwelche dateien die da jetzt erstellt wurden?
gruß bb