Climate Solutions Community

gute Frage...   > wo ich das auf Git finden könnte guck mal hier @Fele  https://github.com/philippoo66/optolink-splitter/discussions/114#discussioncomment-12557897 ... Mehr anzeigen

> Ich habe es geschafft, erfolgreich die Strompreise per MQTT zu verändern.   den Trick muss du mal verraten, dann erübrigt sich auch die Diskussion um die Stromsteuer für Privathaushalte 😂🤑 ... Mehr anzeigen

ich meine zu erinnern dass zweiteres nötig ist. 'Status' spiegelt ja nur was wieder, was durch das Zeitengedöhns bestimmt wird. Selbst wenn du da was ändern könntest, würde das ja höchstwahrscheinlich beim nächsten Reglungszyklusdurchlauf wieder überschrieben....    Irgendwo hier im Thread oder auf github hatte da auch schon mal wer eine Lösung dafür gepostet, aber wahrscheinlich machst du's schneller selber, als dass du das findest 😉 ... Mehr anzeigen

hm, du meinst also vor dem Entkalkungsversuch den WW Anschluss losnehmen und gucken? Wobei das ja einfacher gesagt als getan ist, weil a) die Verrohrung wenig flexibel ist und b) heute oft erst geschraubt und dann verpresst wird, wodurch die Verschaubung praktisch unlösbar ist...   aber anscheinend interessiert das @yoyoyo alles ja doch nicht mehr, sonst hätte er vlt schon mal was von sich gegeben...  ... Mehr anzeigen

ja, die Benachrichtigungen scheinen sich mit der Zuverlässigkeit der Viessmann Cloud Geschichten zu solidarisieren... 🤣   der Unterstrich vor dem Funktionsnamen ist einfach Teil des Namens. Es gibt die Funktionen readByDid(..) und neuerdings (seit v0.5.x) _readByDid(..). Die, die jetzt _readByDid(..) ist, war die ursprüngliche readByDid(..).   den Unterstrich hab ich davorgeschrieben, als wir das mit dem Subs lesen und der 'namentlichen Adressierung' (und das neue Fehlerbehandlungskonzept) eingebaut haben. Die dementsprechende 'Behandlung' passiert jetzt in der neuen readByDid(..) und die ruft im einfachsten Falle einfach die alte _readByDid(..) auf.    Mit dieser 'Umbenennung' blieb der Rest vom Code, der readByDid() aufruft, nahezu unverändert.   In Python wird ein vorangestellter Unterstrich gewöhnlich dazu benutzt, um irgendwas als 'lokal' zu kennzeichnen (optisch), und ich fand, dass passte in diesem Zusammenhang ganz gut.   Das mit dem Unterstrich im Return hast du richtig erkannt, nur, dass es pro (unbenutztem) Rückgabewert einen Unterstrich braucht, aber in diesem Fall ist 'der Rest' ja nur ein zusätzlicher Rückgabewert, nämlich der DID als integer, für den Fall dass er als string (Klartext) in die Funktion reingegangen wäre.   Eigentlich machen wir diese Änderung ja nur wegen der Fehlerbehandlung, die es nur in der 'neuen' readByDid gibt. Den Rest (Behandlung von Klartext und Sub) brauchen wir hier im readAll eigentlich garnicht, deswegen hatte ich ursprünglich die 'alte' readByDid aufgerufen, dabei aber mal wieder 'zu sparsam' gedacht 😉   ... Mehr anzeigen

moin @yoyoyo !   wenn ich das Bildchen hier richtig deute     ist in dem Ding zur Trinkwassererwärmung tatsächlich eine Wärmetauscherwendel, die durchaus verkalken kann.     Was habt ihr denn für eine Wasserhärte und wie lange is die Anlage schon in Betrieb? (edit: ok oben steht 12 Jahre, da is schon einiges Wasser durchgeflossen)   Wenn die Wendel verkalkt ist (innen, das wäre ja das Problem bei zu geringem Duchfluss), müsstest du Kaltwasser Zulauf absperren, dahinter 'anzapfen' und mit einer kleinen Pumpe aus einer Wanne Entkalkerflüssigkeit einleiten und das aus einer nahen WW Entnahmestelle wieder zurück in die Wanne laufen lassen.   Ganz trivial ist das wahrscheinlich nicht, aber die Anlage wird auch nicht ganz billig grad mal auszutauschen sein, deswegen halte ich das schon für lohnend.   Vielleicht gibt es ja einen Ablasshahn am Kaltwassereinlass (M unten), das würde die Sache vereinfachen.      Oder sonst könnte man das Manometer abschrauben oder sowas.   Die Wärmetauscherwendel ist aus Edelstahl, da kannst du praktische jeden Entkalker nehmen, vorher das MAG (S) absperren! und auf Verträglichkeit mit dem Rest des einbezogenen Rohsystems achten.   Es kann allerdings auch ein Anschuss zugewachsen sein wegen irgendwelchen 'unglücklichen' Materialkombinationen (wie alt ist die Wasserinstallation? habt ihr vlt noch verzinktes Eisenrohr irgendwo im Haus?)   (Quelle: https://www.plumbingzone.com/threads/to-dielectric-union-or-not-to-dielectric-union.86790/ )   da hilft dann Entkalker auch nicht mehr....   Grüsse! ... Mehr anzeigen

moin @Pollux    > Ich kenne mich mit Python nicht aus, aber ich werde es mal versuchen   is ja eigentlich ganz einfach. nur die Zeile da einfügen. Wichtig ist die Einrückung, die muss bei der eingefügten Zeile identisch mit der der vorhergehenden Zeile sein (am besten kopieren, ich denke es sind 8 Leerzeichen)    > das man dem paho.mqtt.client irgendwie ein retry inklusive Re-Connect Versuchen mitgeben kann   nö, sowas kenn ich auch nicht. beim connect werden ja auch die call-back Funktionen übergeben und so, das kann paho 'alleine' ja kaum machen.   >  ob es empfohlen ist das automatische Update bei meinem VX3 zu erlauben oder eher nicht   wie gesagt, das hat ja (mindesten) 2 Aspekte. Zum einen eben dass open3e lustig weiter au dem CAN Bus kommuniziert, während der CAN Bus zu Updaten benutzt wird und ggf. dabei (auf der Anlage) auch mal runtergefahren und neu gestartet wird. Zum anderen den Aspekt, dass V mit einem Update alles verschlüsseln könnte (sehr unwahrscheinlich) oder so. Ich denke ich habe auf beides Bezug genommen.   > auf nem PiZero laufen. Geht auch gut, solange ich nicht zu viele IDs lese. Sobald ich das übertreibe geht die load sehr hoch und ich bekomme Timeout Meldungen vom CAN. Woher kommt diese hohe Last? Ist das UDS Protokoll so anspruchsvoll?   das UDS ist nicht sonderlich anspruchsvoll. Wahrscheinlich liegt es dadran, dass udsoncan dann anfängt, die CAN Frames auszuwerten in Bezug auf die Antwort. Es sind ne Menge CAN Frames die da ständig rumflitzenn (mach mal nen candump... 😉 ), und wenn die Filter nicht sehr selektiv gesetzt sind, bedeutet das ne ganze Menge Arbeit für den Prozessor. Schon ein PI 3 hat da ja merklich zu tun.   > dass die Daten vom CAN und aus der Gridbox eine gewisse Abweichung haben.   welche Daten vom CAN? Es gibt da ja Dutzende... wahrscheilich nusst du nur ein wenig suchen (und vlt noch irgendwelche Differenzen bilden), bis das 'konsistent' ist    ... Mehr anzeigen

Nachtrag: Wenn man eine Verrohrung aus Kupferrohren und Heizkörper aus Stahl hat (was ja in älteren Häusern durchaus üblich ist), sind 100uS/cm wahrscheinlich schon grenzwertig und vollentsalztes Wasser fördert die Korrosion im System! Besser mal einen guten Heizi fragen! ... Mehr anzeigen

@Sven73  danke für die Blumen! Sowas freut uns immer 🙂   die Bildchen für die 200-S stammen von unserem Urgestein abnoname, der ist aber inzwischen schwer zu erreichen. Sie wurden aber in gleicher Weise erstellt wie das da drunter für die 250, wo Jürgen ja eine Anleitung zu gemacht hat.   Im Prinzip ist das ziemlich einfach: Bild aus dem Handbuch kopieren und in HA in irgendsoeinem Editor öffnen und Labels reinpositionieren und die mit den Werten verknüpfen. ... Mehr anzeigen

Viessmann schickt mal wieder keine Benachrichtigungen... aber jetzt hab ich's grad gesehen   @Flopsing    > Macht es sinn die files aus dem depictSystem, die man mit python3 Open3E_depictSystem.py -s erstellt hat, an die devs zu schicken?   mit viel Aufwand würden wir dann die 0x90 in Zusammenhang mit utf wahrscheinlich finden, aber einfacher wäre, wenn du mal grad in Zeile 343 in Open3Eclass.py bitte den Unterstrich vor readByDid(...) wegnimmst und dafür bei den return vars einen anfügst, also     ändern in     ich hatte das beim readAll() ein wenig blöd gemacht. Bei dem 'kompletten' readByDid() ist eine Fehlerbehandlung mit Ausgabe des DID drin, bei dem 'Kern-' _readByDid() nicht...   Ich hab das grad im develop branch auch geändert und hochgeladen.   bitte auch Rückmeldung danach 🙂   danke!   ... Mehr anzeigen

hm, blöd immer, dass udsoncan nicht die DID Nummer angibt beim Fehler. Scheinbar liefert ein DID, wo irgendwas als uft-8 kodiert sein soll, ein in dieser Hinsicht unzulässiges Zeichen. vielleicht erfahren wir mehr zu welcher DID das ist mit einem -v im Aufruf? ... Mehr anzeigen

@GMeier  und hat es geklappt? es ist ein wenig doof, wenn ich mir die Mühe mache mich mit deinem Problem zu beschäftigen und durch deine diversen Anhänge zu wühlen und ausführlich die Lösung zu beschreiben und dann kommt nich mal ne Rückmeldung... ... Mehr anzeigen

je nach Setup möchte V ja glaubich mehrere E380 (einen vorm Netzzähler und einen vor der VX3 und ...). Je nachdem welchen du meinst vielleicht   1810 : O3EComplexType(4, "ElectricalEnergyInverterPowerAc", [O3EInt16(2, "ActivePower", scale=1.0, signed=True), O3EInt16(2, "ReactivePower", scale=1.0, signed=True)]),   3228 : O3EComplexType(73, "EnergyMeterOne", [O3EInt32(4, "PowerL1", scale=1, signed=True), O3EInt32(4, "ReactivePowerL1", scale=1, signed=True), O3EInt32(4, "PowerL2", scale=1, signed=True), O3EInt32(4, "ReactivePowerL2", scale=1, signed=True), O3EInt32(4, "PowerL3", scale=1, signed=True), O3EInt32(4, "ReactivePowerL3", scale=1, signed=True), O3EInt64(8, "EnergyImport", scale=100), O3EInt64(8, "EnergyExport", scale=100), O3EInt64(8, "Unknown1", scale=100), RawCodec(8, "Unknown2"), O3EInt16(2, "VoltageL1", scale=10), O3EInt16(2, "VoltageL2", scale=10), O3EInt16(2, "VoltageL3", scale=10), O3EInt16(2, "CurrentL1", scale=10), O3EInt16(2, "CurrentL2", scale=10), O3EInt16(2, "CurrentL3", scale=10), O3EInt16(2, "PowerFactor", scale=10), RawCodec(3, "Unknown3")]),   3229 : O3EComplexType(73, "EnergyMeterTwo", [O3EInt32(4, "PowerL1", scale=1, signed=True), O3EInt32(4, "ReactivePowerL1", scale=1, signed=True), O3EInt32(4, "PowerL2", scale=1, signed=True), O3EInt32(4, "ReactivePowerL2", scale=1, signed=True), O3EInt32(4, "PowerL3", scale=1, signed=True), O3EInt32(4, "ReactivePowerL3", scale=1, signed=True), O3EInt64(8, "EnergyImport", scale=100), O3EInt64(8, "EnergyExport", scale=100), O3EInt64(8, "Unknown1", scale=100), RawCodec(8, "Unknown2"), O3EInt16(2, "VoltageL1", scale=10), O3EInt16(2, "VoltageL2", scale=10), O3EInt16(2, "VoltageL3", scale=10), O3EInt16(2, "CurrentL1", scale=10), O3EInt16(2, "CurrentL2", scale=10), O3EInt16(2, "CurrentL3", scale=10), O3EInt16(2, "PowerFactor", scale=10), RawCodec(3, "Unknown3")]),   3230 : O3EComplexType(73, "EnergyMeterThree", [O3EInt32(4, "PowerL1", scale=1, signed=True), O3EInt32(4, "ReactivePowerL1", scale=1, signed=True), O3EInt32(4, "PowerL2", scale=1, signed=True), O3EInt32(4, "ReactivePowerL2", scale=1, signed=True), O3EInt32(4, "PowerL3", scale=1, signed=True), O3EInt32(4, "ReactivePowerL3", scale=1, signed=True), O3EInt64(8, "EnergyImport", scale=100), O3EInt64(8, "EnergyExport", scale=100), O3EInt64(8, "Unknown1", scale=100), RawCodec(8, "Unknown2"), O3EInt16(2, "VoltageL1", scale=10), O3EInt16(2, "VoltageL2", scale=10), O3EInt16(2, "VoltageL3", scale=10), O3EInt16(2, "CurrentL1", scale=10), O3EInt16(2, "CurrentL2", scale=10), O3EInt16(2, "CurrentL3", scale=10), O3EInt16(2, "PowerFactor", scale=10), RawCodec(3, "Unknown3")]),   3231 : O3EComplexType(73, "EnergyMeterFour", [O3EInt32(4, "PowerL1", scale=1, signed=True), O3EInt32(4, "ReactivePowerL1", scale=1, signed=True), O3EInt32(4, "PowerL2", scale=1, signed=True), O3EInt32(4, "ReactivePowerL2", scale=1, signed=True), O3EInt32(4, "PowerL3", scale=1, signed=True), O3EInt32(4, "ReactivePowerL3", scale=1, signed=True), O3EInt64(8, "EnergyImport", scale=100), O3EInt64(8, "EnergyExport", scale=100), O3EInt64(8, "Unknown1", scale=100), RawCodec(8, "Unknown2"), O3EInt16(2, "VoltageL1", scale=10), O3EInt16(2, "VoltageL2", scale=10), O3EInt16(2, "VoltageL3", scale=10), O3EInt16(2, "CurrentL1", scale=10), O3EInt16(2, "CurrentL2", scale=10), O3EInt16(2, "CurrentL3", scale=10), O3EInt16(2, "PowerFactor", scale=10), RawCodec(3, "Unknown3")]),   680 : RawCodec(123, "EnergyMeter"),   oder vlt irgendein anderer (es gibt 120 Treffer für 'Energy' in der datapoints).   vielleicht sagt ja einer was, der das im Einsatz hat!?     ... Mehr anzeigen

hai @Sven73    > es liegt leider daran   ich hatte jetzt nur auf das Formale geschaut. ERR = bad payload besagt ja, dass es mit dem Payload nix anfangen kann, wegen einer formalen Unverständlichkeit.   Ohne Angabe einer ECU liest read... immer von der 0x680, und da ist 592 ja MacAddressLan. Und du hast recht - der E380 ist keine ECU im Sinne von UDS, sondern nur irgendwie per CAN(open?) 'angeflanscht'. Es gibt aber glaubich auf der 0x680 (oder der VX3?) einen Datenpunkt, der die Infos vom E380 reflektiert. Den hab ich aber grad nicht parat... (ich hab nur eine Vitodens der Optolink Generation 😉 )   ... Mehr anzeigen

moin @Pollux !   das Problem ist ja, dass der MQTT Broker nach einem Neustart garnix mehr von open3e weiss. Wir machen ja ein mqtt_client.reconnect_delay_set() bei der Anmeldung, von daher denke ich, dass sich der client auch automatisch wiederverbindet, allerdings wird sich das nur auf Netzwerk-Aussetzer und sowas beziehen, nicht auf einen Neustart des Brokers.   Beim Anmelden an den Broker teilt ja der Client dem Broker mit, dass es ihn gibt, welche Topics er aboniert und allesowas. Das müsste er alles erneut tun. Das ist in der Struktur von open3e überhaupt nicht vorgesehen.   Was man ausprobieren könnte, wäre in der on_disconnect() Event-Prozedur eine (nicht abgefangene) Exception auszulösen, die open3e zum kontrollierten Absturz bringt und in der Folge systemd dazu, open3e neu zu starten. Vorraussetzung wäre natürlich, dass der Broker geordnet beendet wird und das disconnect überhaupt sendet.   Kennst du dich ein wenig mit Python aus? Könntest du in Open3Eclient.py eine Zeile einfügen?!     und das Ganze dann ausprobieren und Bescheid sagen, ob der Reconnect dann läuft wie geplant?!   und noch zu den Fragen:   wir 'verwenden' keinerlei Update von Viessmann in irgendeiner Weise. Wir reagieren höchsten mal drauf, indem wir neu hinzugekommene DIDs in die DidEnums.txt aufnehmen oder in der datapoints.py, wenn codecs bekannt werden. Wir empfehlen open3e vor einem Update auszuschalten, damit da nix durcheinander geht. Es sind aber auch schon Updates unbeeindruckt von open3e durchgelaufen. Ob und wieweit Viessmann unserer Lösung irgendwann mal "entgegenwirken" wird, steht in den Sternen. Ich hoffe aber, sie haben erkannt oder werden es, dass sie sich damit selber in's Knie scheissen würden, u.a. weil hier schon öfter zu lesen war, dass die Herstellerauswahl nur auf Viessmann fiel, weil es unsere Möglichkeit gibt, lokal und kostenlos auf die Anlage zuzugreifen. Mache haben sich aber auch für einen anderen Hersteller entschlossen, weil sie sich nicht auf eine vom Hersteller nicht offiziell bejahte open-source Lösung verlassen wollen (z.B. Victron geht hier ja einen ganz anderen Weg: sie machen in Teilen selber open-source, verweisen sogar auf externe open-source Projekte, sagen aber, dass sie dafür kein Support leisten können, und alles ist in Butter).   Aktuell lösen die Meisten das Nachladen aus dem Netz wohl (soweit ich das erinnere und verstanden habe), indem sie die Entladegrenze hoch setzen. Dann wird aus dem Netz geladen, allerdings nur langsam. Ob es dafür bald eine 'richtige' Möglichkeit geben wird, und ob die per open3e erreichbar seien wird, steht wieder in den Sternen. Wir haben Viessmann schon mehrfach eine Zusammenarbeit angeboten/nahegelegt, haben darauf aber noch nie auch nur irgendeine Antwort erhalten...   Grüsse! Phil ... Mehr anzeigen

moin @Sven73    > Wenn ich unter MQTT explorer folgendes absende {"mode": "read-json", "data":[0592]}   hm, das liegt wahrscheinlich da dran dass der Herr json mit der 0592 nix anfangen kann. versuch es bitte mal mit  {"mode": "read-json", "data":[592]} ... Mehr anzeigen

immer an's Ende (an jedes) des Busses, also dann auf dem Adapter. Der Widerstand ist ja zwischen CAN_hi und CAN_lo, nicht zu Gnd. Die Brücke beim E380 entfernen nicht vergessen ... Mehr anzeigen

moin @Dreman ! die Open3Edatapoints_writables.json ist nur ein 'Hilfsmittel' für Jürgens Adapter, weil er da Schreiben nur für in der writables.json aufgeführte DIDs 'anbietet' (soweit ich das verstanden hab). In open3e wird die Datei nirgends auch nur betrachtet.   Grüsse! ... Mehr anzeigen

moin @Sven73 !   in letzter Zeit gab es immer mehr Leute, die (erfolgreich) CAN aufgelegt haben ohne Gnd Anschluss. Ich bin da zwar (beim galvanisch getrenntem Adapter) kein Freund von, aber Probieren geht über Studieren.   du könntest auch bsw. den Gnd mit zum E380 führen und ihn da zwar nicht auflegen, aber von da aus weiter zum CAN Adapter führen und da anschliessen. Wichtig ist dass die Leiter möglichst verdrillt sind und auf jeden Fall nahe beieinander geführt werden, damit die Fläche für Einstrahlungen möglichst klein bleibt bzw aufhebend wirkt (bei verdrillt)   ... Mehr anzeigen

moin @GüntherR !   die Vorgehensweise ist genau richtig! obwohl es ja inzwischen auch die Möglichkeit gibt, einzelne Subs in Klartext zu schreiben...   das Problem ist, dass Viessmann den DID offensichtlich als schreibgeschützt ausgeführt hat, er sich also so einfach nicht per standard UDS Service schreiben lässt (obwohl es ja per Bedieneinheit geht).    service 77 bedeutet wir würden so tun als ob wie die Bedieneiheit wären - die schreibt nämlich die Werte ja, und natürlich auch über den CAN Bus, aber sie benutzt dabei nicht den normalen UDS write-did-Service Code, sondern einen proprietären Code 77h.    Das Blöde ist, dass sie das auf dem internen Bus tut, und dieser Service 77 nur auf dem internen Bus funktioniert. Es ist also die Frage, auf welchem CAN Bus du deinen CAN Adapter angeklemmt hast. Auf dem externen CAN Bus wird auch mit -f77 eine Rückweisung kommen, auf dem internen wirst du damit wahrscheinlich erfolgreich schreiben können.  ... Mehr anzeigen

@GüntherR    > aber das ist eh schon ein "alter Hut" und bekannt. mir war das jetzt nicht gegenwärtig und offensichtlich hat es ja auch noch niemand eingearbeitet. müssen wir mal machen. Ich hab es hier mal quick&dirty (vorm Duschen und Frühstück...) für dich zum reinkopieren gemacht:   3335 : O3EComplexType(8, "HeatingCoolingHysteresisHeatingCircuitOne", [O3EInt16(2, "TurnOnHysteresis_Heating", scale=10.0, signed=False), O3EInt16(2, "TurnOffHysteresis_Heating", scale=10.0, signed=False), O3EInt16(2, "TurnOnHysteresis_Cooling", scale=10.0, signed=False), O3EInt16(2, "TurnOffHysteresis_Cooling", scale=10.0, signed=False)]),   scale und signed kannst du auch weglassen, das ist default bei O3EInt16. signed=False ist doch richtig, oder? ... Mehr anzeigen

moin @Sven73 !   Allerdings habe ich ihn noch nicht zum laufen bekommen. den Odroid oder den CAN Adapter? auf https://github.com/open3e/open3e/wiki/020-Inbetriebnahme-CAN-Adapter-am-Raspberry  sind ja die Schritte zur Inbetriebnahme detailliert beschrieben. Wenn du nicht weiter kommen solltest, musst du ein paar mehr Details geben...    wo sollte ich den Adapter am besten anschließen, Vitocal oder VX3? Grundsätzlich würde ich sagen 'an das Führungsgerät'. Ich vermute das ist das Vitocal? Dann gibt es ja auch noch externen und internen Bus... Du kannst aber später einfach von einem auf einen anderen Bus wechseln.     ... Mehr anzeigen

moin @GMeier !   ööhhmm, könntest du noch mal kurz näher beschreiben, was du eigentlich machst und vorhast?!   Ich verstehe es so: Du möchtest die Datenpunkte wie in poll_list.py für die 222-F auf MQTT bekommen, richtig? Du benutzt dazu aber nicht einfach die poll_list.py in das olsplitter Verzeichnis kopiert mit dem optolinkvs_splitter, sondern hast versucht, mit Teilen aus dem Programm dein eigenes zu basteln, und das funktioniert nicht? Wenn ich das richtig verstanden habe, frage ich mich zuerst, warum du das Programm zerpflücken willst. Es funktioniert doch eigentlich gut. Oder ist es für den zero ohne 2 zu viel?   ok, das hier   pllen = inbuff[1] if len(inbuff) >= pllen + 3:     data = inbuff[7:pllen + 2]     return data   ist in deinem Kontext um eine Byteposition schief. schau mal hier:   da ist noch die 06 ('VS2_ACK)' vor und pllen wäre bei dir 41h=65 Bytes. Da kann man ewig drauf warten, und das and inbuff[0] == 0x41 aus dem if davor wird wahrscheinlich auch nie eintreten. Es hat also nix mit Timing zu tun.   Ich benutze ja das receive_vs2telegr() zum Empfang von Master (vom Viconnect) und Slave Telegrammen gleichermassen. Dir ist da der Kommentar "# ab hier Master Request und Slave Response identischer Aufbau ..." durch die Lappen gegangen.   ps. bei sowas hilft immer ein print() wenn der zero das noch hergibt 😉 inbuff += ser.read_all() print(utils.bbbstr(inbuff))   # oder vlt auch print(inbuff.hex()) if len(inbuff) >= 4 and inbuff[0] == 0x41:     ... damit hättest du es sofort gesehen.   pps: das eine oder andre hast du natürlich schöner gelöst als es in meinem Code ist. Vielleicht sollte ich da mal drüber gehen - der Splitter war mein zweites Python Projekt, und von daher... Aber selbst ein 2er Pi ist damit masslos unterfordert (~2% CPU Last), und so hatte ich da nie eine Notwendigkeit gesehn...  ... Mehr anzeigen

so, es ist bestätigt - direkt Anschliessen funktioniert:   am besten Diode und Transistor als SMD bestellen, dann passt das Ganze auch unter die Schiebeklappe... ... Mehr anzeigen

moin @GüntherR !   ich gehe davon aus, dass das Schreiben wirklich erstmal nicht geht, weil alles Schreiben auf der Verwendung von einem Codec basiert, der nicht existiert, wenn der Datenpunkt noch nicht angelegt ist.   Eigentlich sollte dann ein ValueError(f"No Codec specified for DID {idid}") kommen, aber Ich glaube da ist eine falsche Reihenfolge im Code. Ich geh dem mal nach (s. hier)   Was liefert denn das Auslesen für einen Raw Wert? Kannst du da dran die Codierung erkennen? Dann könntest du den Datenpunkt grad anlegen... (können wir auch zusammen machen und gleich einpflegen)    Grüsse! Phil ... Mehr anzeigen

ja,  - das mit dem OptoPi sollte gehen, wohlmöglich brauchst du die Transistoren nicht mal (die GPIOs sind ja schon Transistoren). Das hier   sollte auch am Raspi gehen (probiert hier grad jemand aus, vlt haben wir morgen oder so ein confirm)   - die Syntax der Lese- und Schreibbefehle bei TCP ist die gleiche wie bei MQTT, die ist hier beschrieben https://github.com/philippoo66/optolink-splitter/wiki/010-Command-Syntax#command-syntax-for-requests-via-mqtt-and-tcpip Is alles ASCII. Es gibt auch noch einen raw Modus, da kannst du Optolink Telegramme als $Hex schicken und empfangen, aber wer will das schon.    Bei deinem Vorhaben ist der Splitter natürlich etwas 'Kanonen auf Spatzen', weil ich den Splitter ja mal gemacht habe, um mehrere quasi-parallele Zugriffe zu realisieren (deswegen Splitter). Aber sei's drum, gehen tut es.   Wenn was unklar is immer gleich fragen.   ps. Hast du schon mal dran gedacht eine gewöhnliche Hausautomatisierung wie ioBroker, Home Assistant, ... zu benutzen oder bei einer B3HB auch Viessdata, statt das Rad neu zu erfinden und eine Oberfläche für deine per TCP geholten Daten zu bauen?! ... Mehr anzeigen

ich habe bei mir nur eine Teilmenge von dem was geht. Du kannst zugreifen auf 3 Jahre, 12 Monate, 52 Wochen, 7 Tage soweit ich erinnere. Für Heizen, Warmwasser, Strom. Also das, was du im Energiecockpit auch hast.   Die App habe ich nicht, hatte sie nie und werde sie auch nie haben, von daher weiss ich nicht, was die leifert 😉 ... Mehr anzeigen

moin ihr!   erstmal sorry, dass hier alles kaum beantwortet wurde! Viessmann hat die Domain geändert und folglich sind (zumin bei mir) die Benachrichtigungen im Spamfilter hänge geblieben.   @buec65  ja, Vitodens sollte genauso funktionieren wie die Wärmepupen. Sowohl aktiv lesen mit open3e wie auch lauschen mit CANcollect. Bei CANcollect muss sich allerdings ein Wert ändern, damit er angezeigt wird. Solange er sich nicht ändert, kommt er nicht.   @Thomas_MG  da müssen die WP Leute was zu sagen. Wahscheinlich dauert es bei vielen auch erstmal ein Weilchen, bis die Benachrichtigungen wieder durchkommen und sie sich melden...   @McDomsen2025  "die Frage welche Parameter sind steuerbar" lässt sich kaum pauschal beantworten. Das ist von Anlagentyp zu Anlagentyp verschieden und tw. auch von der Geräte-SoftwareVersion abhängig. Und es sind ne Menge, die hier aufzuzählen den Rahmen sprengen würde, und so einige sind ja auch noch garnicht geklärt. Jedenfalls findet sich für den Großteil der Begehrlichkeiten eine Lösung... 😉 ... Mehr anzeigen

@Fele  am Anfang der neuen Generation haben viele Heizis lieber noch die alte eingebaut, weil die neue am Anfang sehr viele Probleme hatte.   Grüsse! Phil ... Mehr anzeigen

moin @GMeier !   Sorry, Viessmann hat mir wohl die Benachrichtigungen gestrichen... edit: sie haben die Domain geändert und die Mails hingen im Spamfilter...   Ich würde vorschlagen du lädst noch mal das komplette Projekt runter / klonst es und ersetzt deine lokale Kopie (komplett). Gewöhnlich funktioniert das Projekt problemlos. Es gibt keine Datei mainloop.py im Projekt. Irgendwas ist bei dir schief gegangen. Versuch einfach mal    git clone https://github.com/philippoo66/optolink-splitter/ statt den Umweg über die zip Geschichte.   00f8 ist kein Messwert sondern die Device Id der Anlage. die ändert sich nicht und steht entsprechend auch nicht in der poll list. Wenn du die lesen willst, schickst du im MQTT Explorer (oder in sonst einem client) den raw string  r;0xf8;8 auf den Topic Vito/cmnd. dann bekommst du unter Vito/resp die 8 Bytes der device id. Da ist auch ein guter Test, um zu probieren, ob das Ganze funktioniert.   Die poll list musst du entsprechend einer Anlage anpassen. in   https://github.com/philippoo66/optolink-splitter/wiki/350-Poll-Configuration-Samples gibt es diverse Listen für diverse Anlagen als Vorschläge. Per se steht die poll list in der settings_ini.py, du kannst aber auch eine poll_list.py aus dem Wiki nehmen und in's Projektverzeichnis kopieren, dann wird die benutzt.   Sorry dass es so lange gedauert hat mit der Antwort!! ich werd mal schauen, was bei meinen Benachrichtigungen nicht mehr geht... Bei weiteren Fragen hier schreieben, ich guck jetzt mal explizit hier rein.   Grüsse! Phil      ... Mehr anzeigen