Climate Solutions Community

@nils2410  Mit open3e sollte es so gehen:   python3 Open3Eclient.py -c can0 -cnfg devices.json -w 0x680.491='{"State": 0, "Unknown": 0}'   "State":0 => Aus, "State":1 => Ein.   Bitte darauf achten, dass Hochkommata und Anführungszeichen genau so verwendet werden. ... Mehr anzeigen

Mit open3e können komplexe Datenpunkte als JSON geschrieben werden, also z.B.:   python3 Open3Eclient.py -c can0 -cnfg devices.json -w 0x680.691='{"Count": 1, "Schedules": [{"Start": "08:00 ", "Stop": "20:00", "Unknown": "0000", "Mode": 3}]}'   Wichtig ist, dass man ein korrektes JSON übergibt und dieses in einfache Hochkommata einschließt. Am besten liest man den Datenpunkt zuerst und ändert den Output passend ab. Es ist bei Zeitplänen auch möglich, weitere Einträge hinzuzufügen oder vorhandene zu entfernen. Auch hier gilt: Die Struktur muss stimmen, d.h. auch der Wert für Count muss korrekt angepasst werden.   Mit dem ioBroker Adapter kann man die Datenpunkte in allen Darstellungen schreiben, als JSON, raw und tree. In der tree-Darstellung können einzelne Elemente geändert werden, z.B. eine Anfangszeit. Beim Speichern des Elements wird der Datenpunkt passend geschrieben und nach 2,5 Sekunden in allen Formaten zurückgelesen. ... Mehr anzeigen

Mit open3e sollte sich die Ww-Zirkulationspumpe über den Datenpunkt "491 DomesticHotWaterCirculationPump" direkt schalten lassen. Durch ändern von Byte 0 ("State") lässt sich die Pumpe ein- (Wert 1) und ausschalten (Wert 0). Falls Du Raw-Format verwendest also "0100" ein- und "0000" für ausschalten. Bei mir funktioniert das.   Einen eins-zu-eins Zusammenhang zwischen API-Daten und open3e-Datenpunkten gibt es meines Wissens nicht.   ... Mehr anzeigen

Die thermische Systemleistung findest Du unter 2496_CurrentThermalCapacitySystem.   Gruß, Jürgen ... Mehr anzeigen

@Wwi Ich habe die Messung eingebaut und ein wenig mit den Abfragen rumgespielt. Ich sehe die gleichen Effekte, wenn ich die Abfrage genau nach Deinem Beispiel mache. Wenn ich das -cnfg dev weglasse, sind die Zeiten immer so groß wie bei 0x680. Ich vermute deshalb, dass es an der Auswertung der Datenpunktlisten liegt, die bei diesem Vorgang stattfindet. 0x680 hat eine sehr lange Liste, bei 0x6cf ist sie sehr kurz.   @HerrPIst das aus Deiner Sicht plausibel?   Ich habe es mit einem Pi 4 getestet, da ist die längste Zeit etwa 0,2 Sekunden. Ein Pi Zero ist halt kein Rennpferd. ... Mehr anzeigen

@WwiHallo Jens, freut mich, wenn Dir das Projekt gefällt.   Mir ist nicht ganz klar, wie Du die Zahlenwerte ermittelt hast und was da alles drin steckt, außer der reinen Antwortzeit der ECU über den CAN Bus. Wenn Du nur diese Antwortzeit ermitteln willst, schaust Du am besten auf das, was auf dem Bus passiert. Evtl. musst Du zunächst die can-utils installieren, also   $ sudo apt install can-utils   Dann startest Du auf einem Terminal einen CAN Dump für die Adressen 0x680 und 0x690:   $ candump -tA can0 | grep " 6[89]0 "   Auf einem 2ten Terminal machst Du nun eine Abfrage mit open3e. Hier ein Beispiel-Dump für die did 0x680.269: (2024-01-29 19:48:25.999890) can0 680 [8] 03 22 01 0D 00 00 00 00 (2024-01-29 19:48:26.000203) can0 690 [8] 10 0C 62 01 0D 80 01 D1 (2024-01-29 19:48:26.001155) can0 680 [8] 30 00 0A 00 00 00 00 00 (2024-01-29 19:48:26.011517) can0 690 [8] 21 00 58 02 71 01 00 55   Jetzt siehst Du an den Zeitstempeln genau, wie lange die Antwort der ECU dauert.   Ich habe ja einen Adapter für ioBroker geschrieben, der die Funktionalität von open3e direkt in ioBroker integriert, siehe z.B. hier. Da messe ich diese Antwortzeit bei jeder Abfrage. Typische Werte von "Start der Abfrage auf dem Bus" bis "Antwort vollständig erhalten" liegen da im Bereich 10 bis 50 ms. Auch bei der HPMU. Das hängt vor allem von der Daten-Länge der Anwort ab. ... Mehr anzeigen

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 😂 ... Mehr anzeigen

@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? ... Mehr anzeigen

@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. ... Mehr anzeigen

@jokermicWas meldet denn der Adapter beim Schreibversuch im Log? ... Mehr anzeigen

@har1Danke für den Link. Ich habe die Codec für 2426 bis 2429 angepasst. Verfügbar im Branch develop. Schreiben im JSON-Format ist auch möglich. Dabei darauf achten, dass die JSON-Daten in Hochkommata eingeschlossen sind, also did='{"json":"data"}'   Sieht nun z.B. für 2426 so aus (Lesen, Schreiben, Lesen):   open3e $ python3 Open3Eclient.py -c vcan0 -dev vdens -v -r 2426 vdens 2426 MixerOneCircuitRoomEcoFunctionSettings {"State": "on", "OutsideTemperatureLimit": -1.0, "Unkown": 0, "RoomTemperatureLimit": 1.0} closing 0x680 - bye! open3e $ python3 Open3Eclient.py -c vcan0 -dev vdens -v -w 2426='{"State": "on", "OutsideTemperatureLimit": 3.0, "U nkown": 0, "RoomTemperatureLimit": 1.0}' write: 1664.2426 = {'State': 'on', 'OutsideTemperatureLimit': 3.0, 'Unkown': 0, 'RoomTemperatureLimit': 1.0} success: True, code: 0 closing 0x680 - bye! open3e $ python3 Open3Eclient.py -c vcan0 -dev vdens -v -r 2426 vdens 2426 MixerOneCircuitRoomEcoFunctionSettings {"State": "on", "OutsideTemperatureLimit": 3.0, "Unkown": 0, "RoomTemperatureLimit": 1.0} closing 0x680 - bye! ... Mehr anzeigen

@har1Würdest Du bitte einen Link zu obiger Anleitung posten? Mit den Screenshots komme ich nicht klar und Google findet das pdf nicht. ... Mehr anzeigen

Danke für die Info. Ich baue die Datenpunktbeschreibung entsprechend um. Müsste ja so aussehen:   2426 : O3EComplexType(6, "MixerOneCircuitRoomEcoFunctionSettings",[O3EBool(1,"State1"), O3EInt16(2, "Temperature1", scale=10.0, signed=True),O3EBool(1,"State2"), O3EInt16(2, "Temperature2", scale=10.0, signed=True)]),   Was schreibe ich denn statt "State1/2" und "Temperature1/2" sinnvolerweise rein? ... Mehr anzeigen

Na gut, der (umgerechete) Wert hat also die Einheit "10 Minuten" und der interne Wert hat die Einheit "Minuten". Muss ich nicht verstehen, ist halt so. ... Mehr anzeigen

Lt. Datenpunktliste ist für   2426 : O3EInt16(6, "MixerOneCircuitRoomEcoFunctionSettings", signed=True, offset = 1), 2427 : O3EInt16(6, "MixerTwoCircuitRoomEcoFunctionSettings", signed=True, offset = 1),   die Struktur nicht (vollständig) geklärt.   Hat da jemand weitere Infos? ... Mehr anzeigen

Ok, aber wenn der Rohwert 1280 dem umgerechneten Wert 1280 Minuten entspricht, ist der Umrechnungsfaktor 1 und nicht 10, wie aktuell in der Datenpunktliste hinterlegt (es ist kein Faktor angegeben, dann gilt Defaultwert 10).   D.h. wir müssen das in der Datenpunktliste ändern auf   919 : O3EInt16(2, "OutsideTemperatureDampingFactor", scale=1.0)   Richtig? ... Mehr anzeigen

Ups, Umrechnungsfaktor nicht beachtet, sorry.   "b400" ist natürlich der korrekte Raw-Wert, um den umgerechneten Wert von 18 zu schreiben.   Bin jetzt aber erwas verwirrt, was die Einheit angeht. Ich wäre jetzt davon ausgegangen, dass der Raw-Wert von 180 einem umgerechneten Wert von 18,0 Minuten entspricht. So ist es jedenfalls bei anderen Werten, z.B. der Temperatur. Solltemperatur 21 Grad wird als Raw-Wert 210 übertragen, also 21,0 Grad.   Warum sollte das hier anders ein? Eine Werkseinstellung von 1280 Minuten erscheint mir auch wenig plausibel. 128,0 Minuten ist zwar auch ein bisschen seltsam, aber prinzipiell sinnvoll, oder?  ... Mehr anzeigen

Bitte hol den Wert mal im Raw-Format ab, also       python3 Open3Eclient.py -d 192.168.0.1 - dev vdens -raw -v -r 919   da müsste "8000" zurückkommen, also 128 als Hexwert mit LSB zuerst.   Wenn das so ist, kannst Du den Wert 18 (="1200" hex) schreiben mit       python3 Open3Eclient.py -d 192.168.0.1 - dev vdens -raw -w 919="1200"   Dann wieder lesen mit       python3 Open3Eclient.py -d 192.168.0.1 - dev vdens -v -r 919   Das sollte dann den Wert 18 liefern, den Du geschrieben hast.   Sollte bei der ersten Abfrage nicht "8000" zurückkommen, poste bitte erstmal den erhaltenen Wert. ... Mehr anzeigen

Hinweis zur "python-can" Version: Vor dem Start dieser Version unbedingt nochmals   pip3 install -r requirements.txt   ausführen, da diese Version zusätzliche Paket-Abhängigkeiten hat. ... Mehr anzeigen

Im Listener Mode wartet open3e auf Befehle mit dem in der Option -l definierten Topic, also normalerweise "open3e/cmnd".   Wenn mit diesem Topic ein Befehl empfangen wird, wird dieser ausgeführt und auf den nächsten Befehl gewartet.   Z.B. kannst Du Datenpunkte anfordern, wenn Du mit dem Topic "open3e/cmnd" die MQTT-Message "{"mode":"read", "data":[256,265]}" sendest. Dann liest open3e die Datenpunkte 256 und 265 und versendet sie per MQTT mit dem Topic, das mit der Option -m angegeben wurde. ... Mehr anzeigen

Ich meinte die 2te Übersicht. Danke. Bei mir erscheint tatsächlich nur ein weiteres Device, die VX3. ... Mehr anzeigen

@jokermicDanke für's Testen. Freut mich, dass es Dir gefällt. Bzgl. Collect muss ich Dich leider enttäuschen. Bei einer Stand-alone Konfiguration kommt da auf dem externen Bus gar nichts. Die Vitocal wird erst gesprächig, wenn mindestens ein weiteres E3-Gerät angeschlossen und als Slave konfiguriert wird, z.B. eine VX3. In Deinem Fall hilft nur UDSonCAN, also die gewüschten Daten gezielt abfragen.   Könntest Du mir einen Screenshot vom Device-Scan schicken?   Gruß, Jürgen ... Mehr anzeigen

@SanMiggel @HerrP @JWolke Ich habe den develop nach master gemerged. @SanMiggelDu kannst auf develop loslegen. Ich fände es gut, wenn Du dabei auch gleich die Formatierung als Paket angehen würdest. @HerrP Wie siehst Du das? Schlage vor, wir machen im open3e-Repository einen neuen Diskussions-Thread auf und führen diese Diskussion dort weiter. ... Mehr anzeigen

@SanMiggel @HerrP  Für den ioBroker Adapter habe ich bereits alle Encoder implementiert, allerdings in Javascript. Siehe ./lib/codecs.js. Die Encoder sind recht gründlich getestet. Ich würde dies in open3E migireren. Wir sollten aber vorher den develop Branch in den master Branch mergen. Vorschlag: Ich mache heute den Merge und wir gehen anschließend die Implementierung gemeinsam an. Da muss gründlich getestet werden, dann ist es gut, wenn mehre Leute dran arbeiten. Gruß, Jürgen ... Mehr anzeigen

Für E3onCAN nutze ich diese CAN-Bilbiothek: https://pypi.org/project/python-can/   Du denkst, die ist nicht von Problem 2 betroffen? Dann würde es sich vielleicht wirklich lohnen, mal einen Prototypen zu stricken. ... Mehr anzeigen

Ich überlege, ob ich die CAN Kommunikation auf can-utils (das wo auch cansend, candump, ... herkommt) umprogrammieren soll. Mit udsoncan/isopt scheinen wir die Geschichte irgendwie nicht so richtig los zu werden 😕 Aber das ist ein tierischer Aufwand, auch weil die ganze Codec Geschichte im udsoncan steckt. Und es weiss niemand, ob man damit das Problem dann wirklich los ist und ob man sich nicht ein möglicherweise ein anderes einhandelt. Und mit DoIP wär es dann auch vorbei. Hallo Phil, wenn man die CAN-Kommunikation ohne udsoncan abwickeln möchte, muss man ReadByDid und WriteByDid nachbauen. Ersteres habe ich für den ioBroker-Adapter bereits umgesetzt, das sollte sich zügig in Python umsetzen lassen. WriteByDid sollte auch kein großer Aufwand sein. Die Codecs können trotzdem aus udsoncan direkt weiterverwendet werden, da reicht eine Zeile:   from udsoncan.common.DidCodec import DidCodec   Das verwende ich in E3onCAN. Funktioniert problemlos.   Und jetzt kommt das große ABER: Ich habe erhebliche Zweifel, dass wir die Timeout-Thematik dadurch loswerden. Denn die Pseudo-Timeouts kommen aus iso-tp und eben nicht aus udsoncan. Die Timeouts aus udsoncan sind reale Fehler, d.h. die angefragte ECU antwortet nicht, trotz korrekter CAN-Kommunikation. Die iso-tp Timeouts werden durch einen Bug im Linux-Kernel verursacht. Der dürfte weiterhin zuschlagen, wenn wir udsoncan umgehen.   Deshalb mein Fazit: Wäre machbar, ist aber nicht sinnvoll. ... Mehr anzeigen

Bei meiner 13 KW Pumpe geht es thermisch bis 3,2 KW runter. Kleinere Werte habe ich noch nicht gesehen. ... Mehr anzeigen

Beta-Tester sind natürlich willkommen 🙂 open3e und meinen Adapter würde ich aber nicht parallel betreiben, sonst trommeln zwei Systeme unsynchronisiert auf dem Bus rum. Man könnte nach ECU-Adressen (0x680, 0x6a1, ..) aufteilen, das würde funktionieren. Sehe aber keinen Sinn darin.   Denke, die Diskussion können wir führen, wenn Du den Adapter  mal gesehen hast. ... Mehr anzeigen

@HerrPHallo Phil, ich würde ja bei HA gerne helfen, brauche da aber selbst immer mal wieder Unterstützung. Ich hab's nicht so mit den YAML-Dateien. Nutze HA fast nur für ESPHome.   Bei ioBroker kenne ich mich ganz gut aus. Bin im Moment dran, einen Adapter zu schreiben, der die Funktionalität von open3e und E3onCAN zusammenführen soll. Also UDS und Lauschen kombiniert, je nach Bedarf. Einiges tut schon. Wenn es läuft, hat man die Daten von allen gewünschten Geräte aus allen Quellen in einem Objektbaum, direkt als Raw, Tree und JSON. Man kann sich dann also aussuchen, was gerade am besten passt.   Wenn es mal einen Alpha-Stand erreicht hat, poste ich den Link zum Repository. Dann können Mutige mal damit rum probieren.   Nutze grade recht intensiv Deine virtuelle E3, damit ich meine UDS Gehversuche nicht am realem Systen ausprobieren muss. Ein echt super cooles Tool! Leider habe ich für Javascript keine UDSonCAN-Bibliothek gefunden. Also ist Selbermachen angesagt. ReadByDid tut schon. ... Mehr anzeigen

Das sieht gut aus. Und die Kommandozeile? ... Mehr anzeigen