Climate Solutions Community

open3e ist umgezogen!   open3e steht jetzt unter dem Dach der Organisation open3e. Das hat den Hintergrund, dass es ja schon länger nicht mehr nur einen Autor hat, sondern viele, unter anderem ja auch welche von euch. Ich habe davon keine Ahnung, aber der gute abnoname sagt, es wäre so eine gute und faire Sache. Hintergründe können nachgelesen werden u.a. unter About Organizations. Keine Angst: Es bleibt natürlich alles Open Source und nicht-kommerziell, und so wird es auch immer bleiben.   Der neue Link zum Projekt ist https://github.com/open3e/open3e   Alle, die mitmachen per push/pull mögen bitte ihren Arbeits-Clone neu clonen von dem neuen Repo, damit ein push dann auch auf das richtige Ziel läuft. Falls ihr zwischendurch was gemacht habt, was noch nicht synchronisiert ist, vorher ein Backup machen, damit ihr eure Änderungen / geänderte Files dann wieder in den neuen Clone schieben könnt.   In diesem Zug möchten wir dann auch das Wiki rüberholen. @TSG  können wir uns dazu bitte kurzschliessen!? Ich muss mal nachlesen und ggf. nachfragen, wie wir das am besten gemanaged bekommen. Eventuell wäre es einfacher gewesen, es vor dem Umzug rüberzuholen, aber nun ist es so, wie es ist...   und jetzt erst mal wieder viel Spass an dem Projekt und beim Mitmachen! beste Grüsse! Phil     ... Mehr anzeigen

ps. Mietwohnung? dann ist doch eh der Vermieter zuständig?!? ... Mehr anzeigen

Das MAG kann irgendwo im Kreislauf sitzen, es muss halt nur gewährleistet sein, dass es nicht abgesperrt wird. Es heisst, es gehört in den Rücklauf, weil da die Temperaturen geringer sind, aber das MAG wird ja nicht durchflossen. Bei mir ist es vom Fachbetrieb mit einem Panzerschlauch am Vorlauf fast direkt hinter dem Kessel montiert, wohl weil es das einfachste war. Eigentlich sollte es kein Problem sein, es in einer Abstellkammer statt des Verschlussstopfens an den Heizkörper anzuschrauben (wenn du ne Abstellkammer mit Heizung hast).   Bei der Bestimmung der Größe spielen diverse Faktoren rein, da gibt es massenweise Anleitungen im Netz, aber in den meisten Fällen fehlen dir Angaben wie das Wasservolumen deiner Heizungsanlage. Ich sage mal wenn du bis jetzt mit 10 Litern gefahren bist, liegst du mit einem 25 Liter Gefäß wahrscheinlich nicht falsch (hört sich viel an, ist als Kugel aber nicht so groß. Großartig da drunter würde ich nicht unbedingt gehen, wenn man sich Berechnungsbeispiele so anschaut, aber auch hier ist @divanc  wieder der bessere Ratgeber). Zu groß gibt es beim MAG nicht.   Das da ist ein 35 Liter für ein 140m2 Haus Keller/EG/1OG mit Kupferleitungen und 10 Flachheizkörpern. Zugegeben - wenn man es in die Wohnung stellt, ist es nicht sonderlich dekorativ...   HerrP_0-1702457732730.png   Grüsse! ... Mehr anzeigen

@Andy13  hast du noch ein externes MAG? Gewöhnlich ist das interne mehr zu Schutz der Therme als als echtes Ausdehnungsgefäß gedacht. Das hängt natürlich von der Größe deines gesamten Systems ab, aber meist empfiehlt sich der zusätzliche Anbau eines externen MAG. Das ist auch viel billiger als das interne und du kannst es gleich ausreichend dimensionieren. Zudem hast du es dann bei einem erneuten Austausch viel einfacher, und der kommt mit ziemlicher Wahrscheinlichkeit (gewöhnlich leben die Dinger glaubich bei so 7..10 Jahren, manchmal auch kürzer). Das interne kannst du einfach so lassen wie es ist, solange es nicht durchgerostet ist. @divanc  kann dir bestimmt sagen, ob/wann so ein externes MAG Sinn macht und ob er meine Ansicht bezüglich des Ersatzes (oder eben nicht) des internen teilt. Grüsse! Phil ... Mehr anzeigen

>> Werte, wie z. B. VL Temperatur, .... 268 : O3EComplexType(9, "FlowTemperatureSensor", [   O3EInt16(2, "Actual", signed=True),   O3EInt16(2, "Minimum", signed=True),   O3EInt16(2, "Maximum", signed=True),   O3EInt16(2, "Average", signed=True),   O3EByteVal(1, "Unknown")]),   Die Open3Edatapoints ist ja die Ansammlung aller Datenpunkte, die uns bisher 'über den Weg gelaufen' sind. Relevant für die 300-W wäre eher die Liste, die du per   printdatapoints.py -dev vdens bekommst.   Die aber wirklich auf deine Anlage zutreffenden Datenpunkte erhälst du mit depictSystem und dann   printdatapoints.py -dev _680 und das Gleiche mit allen _6yz, die bei dem depict erzeugt wurden.   Welche davon dann wirklich relevant sind - da steht hier die Bitte um eine umfassende Dokumentation an Viessmann im Raum... Wobei die vielleicht auch nicht ganz zu Unrecht sagen werden "Viele Datenpunkte sollen euch eigentlich garnicht interessieren" - aber um das abgrenzen zu können, braucht es zumindest eine Dokumentation der Datenpunkte, die die Betreiber* interessieren.   Grüsse! Phil ... Mehr anzeigen

wenn du --config (-cnfg) benutzt wird --dev (-dev) ignoriert, es reicht also definitiv eine der beiden Angaben.   -dev kommt noch aus den Anfängen, wo wir mit 'unseren' Anlagen geprobt hatten und gesehen, dass es bei einer vcal anders aussieht als bei einer vdens.   Du kannst sogar beide Angaben weglassen, dann wird in open3e ein device (oder streng genommen erstmal eins für die default-ECU Adresse und später gegebenenfalls für jede andere angesprochene ECU Adresse ein weiteres) angelegt, was den kompletten 'Datensatz' der Open3Edatapoints.py hat. Dann darf man aber kein --scanall machen, weil dann zwangsläufig Datenpunkte ausgelesen werden wollen, die auf dem realen Gerät nicht existieren (kein Open Base Gerät hat alle Datenpunkte). Ausserdem gibt es Probleme, wenn du einen Datenpunkt 'anfasst', bei dem die Datenlänge auf dem realen Gerät anders ist als in der Open3Edatapoints hinterlegt (es gibt ein paar wenige Datenpunkte, die auf verschiedenen Geräten unterschiedliche Längen und damit unterschiedliche Codec-Definitionen haben).     ... Mehr anzeigen

Moin @ghNeandr !   So eine VX3 schaltet man natürlich nicht mal eben aus und wieder an wie einen Fernseher...   HerrP_1-1702201255289.png   Möglicherweise reicht Schritt 1 zum Zurücksetzen des Fehlers / der Fehlerzähler schon. Schritt 2 wäre dann sozusagen der 'Hauptschalter'. Wenn der CAN Controller dann weiter von der Batterie am Leben gehalten wird, drohen Schritte 3 und 4.   Einschalten muss man danach dann ja auch wieder - möglichst ohne erneuten Inbetriebnahmeassistenten...   Weiss jemand, wie man einen Fehler Reset an der Vitocharge macht ohne sie auszuschalten?     @TSG  ich würde nach dieser Erfahrung gern im Wiki das Bild mit 2-adrigen Anschluss des galvanisch getrennten CAN2USB an den Energiezähler dick durchstreichen! Wäre das ok für dich? Das Bild steht als erstes da, und wer nicht weiter liest, denkt dann wohlmöglich man solle es so machen. Ich kann mir auch gut vorstellen, dass viele der Timeout Probleme nicht vom ISO-TP Kernel kommen, sondern von dieser 'bodenlosen' Verdrahtung...   ... Mehr anzeigen

@ghNeandr  HerrP_0-1702172787433.png   Wiederstände hast du doch einen an der VX3 und einen an dem Adapter (da den Jumper gesteckt) und keinen auf dem E380, richtig? Dann mach mal einen Hauptschalter Reset, ich denke bei der VX3 ist auch schon 'Eskalationsstatus' erreicht. Es gibt auch ein NMT Command zum communication reset, aber wer weiss ob die überhaupt noch zuhört...   ... Mehr anzeigen

Moin Jürgen @Juergen-B ! Das freut mich, dass noch jemand was von der virtualE3 hat und ich sie nicht nur für mich gebaut habe 🙂 Sie ist an manchen Stellen noch nicht 100%ig, aber das hängt eher damit zusammen, dass sie mal auf alles und mal nur auf die datapoints oder aus den virtdata oder beidem oder oder oder antworten soll... Aber mit -cnfg dev und einem sauber abgebildetem Set ist eigentlich alles rund.   Ich bin gespannt was du da wieder baust! Hoffentlich verstehe ich das! 😉 ... Mehr anzeigen

@ghNeandr  zumindest stehen die Fehlerzähler von deinem USB Adapter jetzt schon mal auf 0 und nicht bei ein paar Hunderttausend oder Millionen wie gestern. So gehört sich das. Auf dieser Grundlage kann man aufbauen.   Hast du ne Ahnung was die Fehlernummer bedeutet? depict liest ja blos, das sollte zu keinem Fehler führen, erst recht zu keinem, der auch noch später periodisch wieder kommt. So ein CAN Protokoll ist sehr sicher, es ist also auch nahezu ausgeschlossen, dass wegen der Floaterei irgendein Frame 'missinterpretiert' worden wär.   Hast du schon mal einen 'Hauptschalter-Reset' der ganzen Anlage gemacht? Es kann sein, dass wegen den Busstörungen auch noch bei andren Teilnehmern die Fehlerzähler hochgelaufen sind.   Bevor wir mit depictSystem anfangen, sollten wir erstmal sicher sein, dass das System jetzt stabil läuft. Wenn da weiter Timeouts drin sind, nutzt depict nix, weil es dann warscheinlich ein falsches Bild zeichnet, was nicht zu gebrauchen ist.   Lieber erstmal mit Open3Eclient mittels -dev vx3 (datapointsVx3) ein paar bekannte weit verbreitete Datenpunkt zyklisch auslesen und schauen was passiert. Du sagtest ja auch, dass das ohne 'Bufferhunger' startet (wobei das intern die gleichen Funktionen von udsoncan benutzt...). Allerdings glaube ich, dass man mit dem Retry Mechanismus Timeouts garnicht mehr unbedingt bemerken würde... da müssen wir noch mal schauen.     ... Mehr anzeigen

@Sebliner  jap, hier gibt's PNs. schauen wir mal. Dass in dem uds log nix drin stand wundert mich nicht, weil der Fehler eben was mit Zeichendarstellung zu tun hat, womit aber weder udsoncan noch depictSystem irgendwas am Hut haben, erst recht keine ausgefallenen Zeichen. Es werden ja einfach nur Bytes ausgelesen und die noch nichtmal dargestellt. Und der Fehler kam ja aus den Tiefen von udsoncan, genauso wie der seltsame unstillbare Bufferhunger bei ghN. Heute scheint ein seltsamer Tag zu sein...   Wir müssen erstmal klar bekommen, was wir eigentlich erreichen wollen und wie wir da hin kommen wollen. Das ist zuindest mir aktuell nicht mehr ganz klar.     ... Mehr anzeigen

ich kenn mich doch mit dem ganzen HA Zeugs nich aus. 'Unser' @Juergen-B  alias MyHomeMyData oder auch @JörgWende sind da viel bessere Ansprechpartner (wir ham da bestimmt noch andre). Die verstehen dann auch, wodrüber ihr redet 🙂 ... Mehr anzeigen

@SanMiggel  so ein MQTT Command kann man doch eigentlich 'von überall her' absetzen, oder? ... Mehr anzeigen

ups war die neue Seite voll an mir vorbei gegangen... @ghNeandr  der E380 hat ja offensichtlich seinen Potentialbezug. Hauptsache dein CAN Adapter hat jetzt auch einen 🙂 Aber mit dem Buffer vom Raspi kann das ja wirklich nix zu tun haben. Irgendwie is heute echt der Wurm drin. Bei Sebliner stürzt depict ab wegen der Darstellung irgendwelcher Multibyte-Zeichen, dabei macht das ja einiges, aber eigentlich nix Ausgefallenes und erst recht nix Unbekanntes mit unvollständigen oder unzulässigen Zeichen darstellen, bei dir braucht udsoncan plötzlich irgendwelchen dubiosen Buffer.... ich hab keine Ahnung was los ist. ... Mehr anzeigen

sehr seltsam! startet Open3Eclient denn? ... Mehr anzeigen

unten unter Main und den Args # peparations dataIdentifiers = dict(Open3Edatapoints.dataIdentifiers["dids"]) e3Devices = Open3Eenums.E3Enums['Devices'] dicDidEnums = read_didenums("DidEnums.txt")   die dataidentifiers sind die Open3Edatatpoints.py. aber sooo groß ist die ja nun auch nicht. Die Enums hat auch nur bei 100kB. Die DidEnums 118k. alles in allem nicht mal n halbes MB. und bis zur DidEnums kommt er ja nicht mal     ... Mehr anzeigen

bei mir is eher noch weniger frei. bekommst du nicht mal die allererste Ausgabe "read DID enums ..."?   ... Mehr anzeigen

sehen die Fehlerzähler denn wieder gut aus? ... Mehr anzeigen

interessant! 😎 öfter mal was neues... ... Mehr anzeigen

[edit] ups, gh's Beitrag verschwunden? eben war hier doch noch einer....   welchen Fehler? (Screenshot vergessen?) oben haben wir ja auch grad nen ganz seltsamen...   aber deine Fehlerzähler sind wieder im normalen Bereich und 'stabil'? ... Mehr anzeigen

vielleicht was für's Wiki - danke!   @Sebliner  ich hab gegoogelt und gefunden, dass der Fehler "Invalid or incomplete multibyte or wide character" garnix mit Kommunikation, sondern mit der Darstellung von 'wide chracters' (sowas wie UTF und so) zu tun hat. Wie der sich jetzt da reinschleicht ist mit ziemlich schleierhaft. Wir wenden ja bei depictSystem überhauft keine Codecs wie O3EUtf8 oder so an!?! ... Mehr anzeigen

moin Stefan! kann es sein, dass du ein wenig im Thread 'verrutscht' bist? Aber vielleicht 'erwischst' du ja trotzdem wen, der da weiterhelfen kann... Evtl. schickst du mal @Juergen-B  ne PM, der kennt sich da glaubich ziemlich gut aus. ... Mehr anzeigen

wir wissen ja so garnicht, bei welchem did (Parameter) der Fehler aufgetreten ist. birgt der udsoncan.log weitere Infos? Komischerweise finde ich Errno 84 nicht in den udsoncan Sourcen.   Hast du vlt grad Langeweile und einen online-meeting fähigen Rechner? ... Mehr anzeigen

@Sebliner  du musst zuerst unterscheiden zwischen 0x680 und bsw. 0x684. Auf 0x680 gibt es den did 265 und den liest du auch aus wenn du einfach -r 265 machst. Wenn du keine explizite ECU Adresse angibst, wird immer die 0x680 ('Main Control Unit') genommen.   Wenn du die 265 von 0x684 auslesen willst, musst du das hinschreiben: -r 0x684.265   Da oben steht (in Zusammenhang mit 0x684) 265 ERROR max retry. Die Meldung wird ausgegeben nachdem 4x versucht wurde, den Datenpunkt zu lesen, und anschliessend wird weiter gegangen zum nächsten DID (das wäre hier dann 266).   Die Meldung links ist sehr interessanrt. Sowas hatten wir noch nicht. Bei diesem Fehler (bzw. bei allen anderen ausser den beiden Timeouts) soll depictSystem aussteigen, und es ist ja auch so gemacht, dass dann der zuvor abgefangene Fehler innerhalb der Fehlerbehandlung ge-raise-t wird. Deswegen auch das "During handling of the above exception another exception occured" - in Wirklichkeit ist es kein anderer, sondern eben genau der Fehler. Und depict steigt dann aus und muss neu gestartet werden, dass ist alles richtig so und gewollt.   Leider hat dein Dump auf der rechten Seite nichts mit dem Fehler zu tun. Links waren wir ja beim Scannen von 0x684, rechst ist aber nur 0x680 Kommunikation zu sehen (Ausleseversuche von dids 3484 bis 3500, die aber alle nicht existieren und folglich ganz korrekt mit Negative Response (7F), Code 22 (Conditions not correct) auf Attempt ReadDataByIdentifier, SID 22 beantwortet werden).   wir müssen mal strukturieren. 'bin gleich zurück... ... Mehr anzeigen

schon mal danke für die Info! @Thomas_MG    die Statistik sagt ja nur dass 'nachrichtentechnisch' alles ok ist, also auch die Physik. Wenn jetzt noch ein Timeout auftritt siehst du den glaubich garnicht mehr, es sei denn, es kommen 4 nacheinander. sollte man vlt zumin im -v Mode was einbauen... obwohl - im udsoncan.log sollten sie noch stehen ... Mehr anzeigen

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:   HerrP_0-1702120674598.png 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... ... Mehr anzeigen

gute Sache!! extra Kabel für GND ist in meinen Augen eh besser als einen Schirm mit GND zu verbinden, aber das Thema hatten wir ja schon und es ist wahrscheinlich sowieso eher philosphischer Natur... Hauptsache irgend was Leitendes! 😁     @Sebliner  >> beim 2. did "ERROR max retry" und ab da wurde das bei jedem did angezeigt bis ich abgebrochen habe    hmm... vielleicht ist es doch ein Versuch wert, die Wartezeit vor dem retry mal hochzusetzen (testweise 1..2 Sekunden um sicher zu gehen)?   das bekommst du wahrscheinlich selbst gemacht?! würde mich interessieren ob das was ändert! (ich kann's ja nicht ausprobieren... 😁 ) ... Mehr anzeigen

  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...   HerrP_0-1702078312714.png   Hol dir den CAN_GND von der VX3 und die Welt ist wieder in Ordnung. 🙂         ... Mehr anzeigen

TimeoutError, TimeoutException - ich hab jetzt die Faxen dicke 😎 und es ist mir jetzt auch egal, ob 'man das macht' oder nicht, ich habe es jetzt eingebaut:   TimeoutError und TimeoutException werden jetzt direkt in der class getrapt und im Falle eines Falles werden bis zu 3 Retries gemacht.   HerrP_0-1702074797608.png   Wenn es auch beim 4. Mal immer noch nicht geklappt hat, erfolgt eine Meldung in der Console und es kommt eben kein Wert, aber das Skript läuft unbeeindruckt weiter.   Die Fehlerbehandlung muss so kompliziert sein, weil das eine ein generischer Fehler ist und der andre aus der usdoncan Lib kommt.   Negative Response Exception und so sind damit nicht unterdrückt, die führen weiterhin zum Fehler und sollen das auch.   Ich habe das auch für den DID Scan in depictSystem eingebaut, für den COB Scan geht es leider nicht (so einfach), weil da Timeout die normale Reaktion ist, wenn eine ECU nicht reagiert weil sie nicht da ist. Man könnte natürlich bei jeder ECU fragen "bist du echt nicht da? wirklich nicht? auch gaaaanz sicher nicht??" aber dann dauert das Ganze nochmal dreimal so lang und selbst dann ist es nicht wirklich sicher... Ich werde mal bei den Car Hacking Tools gucken, ob es noch eine andre Möglichkeit gibt, die Anwesenheit einer ECU festzustellen, aber ich fürchte ein bugy System ist und bleibt eine unsichere Sache, da kann man programmieren so viel man will 😕   @Sebliner  dass es bei E3onCAN nicht passiert, hängt mit dem eigentlichen Problem zusammen. Beim nur 'Mithören' gerät der ISO-TP Kern nicht in Gefahr, in diese Race Condition zu geraten, weil es da kein Race gibt, das mal so und mal so ausgeht und eben mal diesen oder jenen Timeout verursacht. Wegen der Race Condition ist es auch sinnlos, vorm Retry länger zu warten, weil das Race schon vorbei ist, wenn der Fehler kommt (eigentlich bräuchte man garnicht warten). Das ist alles schon genau erforscht, geklärt und eben gefixt. In dem Issue Thread https://github.com/pylessard/python-can-isotp/issues/92 bei dem Autor gibt es ausgiebig Info und Links dazu, da kann man das alles haargenau nachlesen. Es nutzt aber nichts, davon kommt der Fix auch nicht schneller in den Distributionen an.   Ich hoffe, jetzt ist aber soweit zumindest erstmal Ruhe 🙂   ist online im develop branch. alpha geteste von mir mit provozierten Timeouts (bei mir gibt es ja keinen bugy Kernel), bitte testet es auch und gebt Rückmeldung falls noch was hakt (oder auch wenn alles perfekt ist 😉 )   Grüsse & viel Spass damit!   ... Mehr anzeigen

@ghNeandr  kannst du denn den Adapter nicht einfach an die Klemme von der VX3 machen, wo jetzt der Widerstand dran sitzt, und die T-Brücke am E380 wieder rein machen?   Ich weiss nicht, wie ich es noch anders erklären soll - ein isolierter Adapter ist potentialfrei, braucht aber einen Potentialbezug, damit die -27..40V aus dem Datenblatt eingehalten werden. Ohne ein Kabel ist das eine äusserst wackelige Angelegenheit...   Hast du ein Multimeter oder im besten Fall ein Oszilloskop? dann könntest du mal messen, ob das Bezugspotential vom E380 die PE/N Klemme links ist.     @Flopsing  aber deine Anlage hat einen CAN Bus oder? Dann den Adapter dran und depictSystem laufen lassen (und bitte ein Systen ohne den Timeout Kernel Issue nehmen). Es kann gut sein, dass bei den Werten dann L2 und L3 eben 0 sind aber der Rest funktioniert.   1824 : O3EComplexType(16, "ThreePhaseInverterCurrentPower", [   O3EInt32(string_len=4, idStr="cumulated", scale=1),   O3EInt32(string_len=4, idStr="L1", scale=1),   O3EInt32(string_len=4, idStr="L2", scale=1),   O3EInt32(string_len=4, idStr="L3", scale=1)]), 1825 : O3EComplexType(16, "ThreePhaseInverterCurrentApparentPower", [   O3EInt32(string_len=4, idStr="cumulated", scale=1),   O3EInt32(string_len=4, idStr="L1", scale=1),   O3EInt32(string_len=4, idStr="L2", scale=1),   O3EInt32(string_len=4, idStr="L3", scale=1)]),   Es gibt zwar schon wieder ein paar neue Datenpunkte, aber die 1-phasigen wären wohl eher älter, und wenn es sie gäbe, ständen sie dabei...   Den Energiezähler kannst du allerhöchstwahrscheinlich mit E3onCAN mitlesen. ... Mehr anzeigen