Climate Solutions Community

das ist ja jetzt ganz frisch nach dem Kernel Update a la Jörg. Ich fürchte, das Update war nicht mit dem System kompatibel.... ... Mehr anzeigen

oh 😳 was für ein System hast du am laufen? (bzw. jetzt am bocken...) ... Mehr anzeigen

wobei ich sehe grad... wir fangen "TimeoutError" ab, kommen tut aber "TimeoutException". wird so also nicht funktionieren...   @Juergen-B  ich glaub du warst da näher dran - was wollen wir machen?!   Grundsätzlich wäre das Beste, ihr (die wo das Timeout kommt) macht das Kernel Update - dann braucht's keine 'Krücken' mehr!   ich kann das leider nicht einfach nachstellen - bei mir läuft es fehlerfrei dank altem Buster 😎 ... Mehr anzeigen

danke!   ich habe habe im develop grade das Trapping des Fehlers wieder 'aktiviert'. https://github.com/abnoname/open3e/blob/develop/Open3Eclient.py  Aber wie gesagt: Es gibt dann keine Meldung, nur kein Ergebnis (glaubich) ... Mehr anzeigen

wie oben (06.12.2023 13:54) schon zu GW3 gesagt, ist das kein Timeout sondern ein Kernel Bug, der mal auftritt und mal nicht. Da kannst du das Timeout auf 3 Stunden stellen, es dauert dann nur länger bis die Exception kommt 😁 Aber sie kommt.   Scroll mal hoch und folge dem Link, damit solltest du der Sache Herr werden.   Eigentlich hatten wir diese Exception aber abgefangen. Der Wert kommt dann zwar nicht, aber das Skript sollte weiter laufen.   es gibt eine Datei "udsoncan.log" oder so - könnt ihr bitte mal schauen, was da bei dem Fehler genau reingeschrieben wird!?   ... Mehr anzeigen

seitdem es depictSystem gibt, sollte eigentlich überhaupt nicht mehr mit -dev irgwas gearbeitet werden, sondern nur noch mit -cnfg devices.json (oder kurz -cnfg dev geht auch).   Die datapointsVdens, Vcal, VX3, ... sind nicht mehr auf Stand (oder auf einem ganz bestimmten) und passen in vielen Fällen nicht zur Anlage. @GW3 du hast doch überhaupt keine Vitodens, oder? ... Mehr anzeigen

bei -dev vdens wird die Open3EdatapointsVdens.py benutzt - da steht der 269 garnicht drin. Offensichtlich wird der DP dann 'pure' ausgelesen und liefert magels weiterer Infos den Raw Wert (9 Bytes).   Was mich wundert ist, dass Open3Eclient.py -c can0 -dev vdens -r 268 überhaupt funktioniert. Wenn du nicht irgendwas 'verbogen' hast, wird in dem Fall von 0x680 gelesen. Laut depict Scan gibt es aber auf 680 den Datenpunkt 268 garnicht (ich hab deine Dateien bekommen - danke!). Seltsam!   mach mal   python3 Open3Eclient.py -c can0 -cnfg devices.json -r 0x680.269,0x6cf.268     eigentlich müsste auch   python3 Open3Eclient.py -c can0 -r 0x680.269,0x6cf.268   funktionieren, das sollte aber nicht mit -a kombiniert werden... 😉 ... Mehr anzeigen

moin Joe!   da wo du zwischen "nur Warmwasser" und "Heizen und Warmwasser" umschaltest gibt es auch einen Abschaltbetrieb. Der schaltet auch die Pumpe aus, wenn die Therme nicht meint, sie müsse Frostschutz machen. Wenn nichts hilft gibt es den Netzschalter neben dem Manometer 😉 Vorgehen: Pumpe aus (damit ist auch Heizung aus) Schlauch an Therme anschliessen, aber noch nicht festdrehen Luft aus dem Schlauch verdrängen indem du den Wasserhahn etwas aufdrehst bis an dem noch nicht festgezogenen Anschluss Wasser austritt. Dann Anschluss festdrehen Vierkant 90° drehen dass Schlitz längs steht jetzt vorsichtig Wasserhahn aufdrehen, Manometer beobachten, zudrehen wenn genug Druck drauf. Vierkannt 90° zurückdrehen dass Schlitz quer steht. Schlauch abbauen und Heizung wieder anmachen. Steht das echt nicht in der Bedienungsanleitung?   Grüsse! Phil ... Mehr anzeigen

@GW3  >> Wie kann ich das zip-File schicken? ich schick dir meine eMail per PM. Persönliche Anlagendaten besser nirgends öffentlich hochladen, weil wenn da Seriennummern drin stehen, könnte das von Viessmann als Schwarz-auf-Weiss Beleg benutzt werden, irgendwelche Gewährleistung zu verweigern.   >> Manchmal bekomme ich valide Werte, manchmal eine Fehlermeldung (ich vermute timeout) Das hat nix mit echtem timeout zu tun, das ist ein Kernel Bug. Der ist schon beseitigt, allerdings muss sich das erst in die Distributionen 'durchmigrieren'... Es gibt ein Kernel Update, das man ggf. 'zwischendurch' schon mal ausführen kann. Das ist alles hier beschrieben: https://github.com/abnoname/open3e/issues/10#issuecomment-1807693946 Da drüber ist ein kompletter Thread zu dem Timeout Issue...       ... Mehr anzeigen

@ghNeandr  >> etliches an Hintergrund fehlt, was die verschiedenen Parameter und Datenpunkte etc zu bedeuten haben, wie diese mit den Open3e Funktionen zusammenhängen.   die command line Optionen/Parameter von open3e könnten wir noch etwas umfangreicher dokumentieren. Wohlmöglich wäre das noch was für das Wiki von @TSG ?!   Was die Datenpunkte der Geräte anbetrifft würde ich mir auch mehr Hintergrund/Dokumentation wünschen. Das ist natürlich eindeutig ein Viessmann Task. Vielleicht wäre auch eine Link-Sammlung oder evtl. sogar eine Dokumente-Sammlung der Handbücher, die hier das Entsprechende zumindest zum Teil leisten, auch was für das Wiki. Allerdings gehe ich davon aus, dass die Handbücher auch ständigen Updates unterliegen, von daher könnte das schon 'pflegeintensiv' werden...   Open3E macht ja nichts andres als Daten auszulesen und ggf. an den MQTT Broker zu schicken (abgesehen von den noch etwas experimentellen Schreib-Funktionen).   ... Mehr anzeigen

@TSG  >> Ich gebe mein bestest. Bin mit GitHub nur meher in der Theorie vertaut.   ich bin auch blutiger git Anfänger 🙂 So wie ich das verstehe machst du einen Fork von abnoname/open3e in dein Account. Da kannst du dann drin arbeiten, was du ja im abnoname/open3e nicht kannst, weil du kein colaborator bist.   Arbeite bei dir dann bitte im develop branch, NICHT im master. Der develop soll develop bleiben, und irgendwann holen wir den hoch in den master. Wenn aber vorher der master mit irgendeiner Fork gemerged wurde, ist der dann in gewissen Aspekten ahead develop und es wird kompliziert......   Wenn du mit Bearbeiten erstmal fertig bist, wähle unter 'Contribute' -> 'Open Pull Request'     Dann erscheint das bei uns und wir sollten es ein-mergen können.   Zwischendurch / vor dem Pull Request vlt ein 'Sync Fork' machen...   Vielleicht klappt das mit dem Wiki auf die Art auch?!   Vielleicht kann hier noch wer Tips zu git Vorgehen geben, der/die sich besser auskennet?! ... Mehr anzeigen

@ghNeandr  >> Kann jemand dabei helfen wie typischerweise der Befehl für Open3Eclient with -mqtt and -a aussehen sollte.   eigentlich wie in der README beschrieben: python3 Open3Eclient.py -c can0 -cnfg devices.json -m 192.168.0.5:1883:open3e -mfstr "{ecuAddr:03X}_{didNumber}_{didName}" -a Wenn dein MQTT Broker auf der gleichen 'Maschine' läuft wie open3e kannst du auch 127.0.0.1 (local host) statt 192.168.0.5 benutzen (die 192.168.0.5 ist natürlich auch nur beispielhaft, genau wie das can0). Ich habe eine argsscanallmqtt gemacht, die du einfach mit python3 Open3Eclient.py @argsscanallmqtt aufrufen kannst statt der ganzen einzelnen cl Optionen.   Wenn du User und Passwort auf dem Broker benutzt, musst du noch -muser ichuser:meinpwd hinzufügen.   Ggf. musst du in dener MQTT App noch alle open3e Topics abonieren, im MQTT Explorer tauchen sie eigentlich von selber auf.     >> Quatscht der Open3e dann permanent über MQTT?   Nein. der Client macht in diesem Fall nur einen --scanall Durchlauf und beendet sich dann wieder.   Wenn du möchtest, dass er dauerhaft/zyklisch Werte postet, musst du die Optionen -r 123,234,456 -t 10 verwenden, gewöhnlich anstatt dem -a     >> Bei der Durchsicht des Open3E_depictSystem.py scans sehe ich nur Datenelemente die wohl mit der PV Anlage und dem Batteriespeicher zu tun haben. Die Wärmepumpen Installation wird auf diesem Weg wohl nicht angesprochen/ abgefragt. D.h. der CAN Bus gilt nicht für die WP. Geht da noch was, oder muss ich zusätzliche HW / SW haben um ein komplettes Abbild der Installation WP/PV zu bekommen?   Das klingt als wären WP und PV nicht über CAN Bus miteinander verbunden?!? In dem Falle bräuchtest du einen zweiten CAN Adapter und zweite Instanz open3e usw. wie bei @Thomas_MG 😞    Ich würde aber den Fachbetrieb, der die Anlage/n bei dir installiert hat, höflich darauf hin weisen, dass er bitte die beiden Anlagen per CAN miteinander verlinkt. Das gehört sich eigentlich so.   Einfach Kabel dran reicht nicht, weil im Inbetriebnahmeassistenten dann auch das Führungsgerät als solches konfiguriert wird und so. Mindestens den Inbetriebnahmeassistenten muss man also noch mal durchlaufen lassen.     >> depict ist sehr zeitaufwendig, sollte in den Hinweisen gesagt werden. ist erledigt in develop. danke! >> Vielleicht ist es sinnvoll das py-Listing nicht auf die Console zu schreiben, sonst in eine Datei umzuleiten. Eigentlich ist das nicht nötig/sinnvoll, dann weiss man ja noch weniger, dass überhaupt etwas passiert und bricht evtl sogar vorzeitig ab. Die devices/ECUs stehen mit zusätzlichen Angaben in der devices.json, die man ja anschauen kann. Man kann sich dann mit python3 printdatapoints.py -dev _6yz die gefundenen Datenpunkte pro ECU sogar mit Codecs ausgeben lassen.  Also besser die 'Lebenszeichen' on Screen lassen 😉  ... Mehr anzeigen

@Thomas_MG  >> Ich musste aber auch die datapoint Dateien umbenennen und die Dateinamen in der devises.json anpassen.  ja, du hast Recht, das hatte ich heute morgen kurz nach dem Aufstehen noch nicht auf dem Schirm - sorry 😉 ... Mehr anzeigen

@GW3  >> found 268:9:FlowTemperatureSensor >> in dem File Open3Edatapoints_680.py steht >> 268 : None,   Wenn in einer Open3Edatapoints_6yz.py bei einem Datenpunkt : None steht heisst das, dass es bei dem Codec (die Interpretation der Daten) keine Änderung gegenüber der (generellen) Open3Edatapoints.py gibt, also es so aussieht wie in Open3Edatapoints.py verzeichnet. Auf dein Beispiel bezogen steht da  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")]),  und so ist es dann auch bei deinem gescannten Device.   Dass der Datenpunkt trotzdem in der Open3Edatapoints_680.py aufgeführt ist, hat den Zweck, anzuzeigen, dass der Datenpunkt bei ECU 0x680 existiert (in der Open3Edatapoints.py stehen ja auch noch ganz viele Datenpunkte, die auf der 0x680 nicht existieren). Das ist wichtig für ein --scanall.   Jörg hat die treffende Bezeichnung 'Overlay' für die datapoints_6yz kreiert: Die 6yz Tabelle wird über die generelle datapoints drüber gelegt, da wo in der 6yz nix steht, ist auch nix. da wo in der 6yz None steht, schimmert der Eintrag aus der generellen datapoints durch, da wo in der 6yz etwas Explizites steht, gilt das Expizite. Wenn etwas Explizites da steht, kann das zwei Gründe haben:. Es gibt schlicht noch keinen Eintrag in der generellen Open3Edatapoints.py Die Länge der ausgelesenen Daten unterscheidet sich von der in der Open3Edatapoints.py und folglich kann der Codec dort nicht 'unfallfrei' angewendet werden. Dann schreiben wir den RawCodec hin, weil wir gewöhnlich nichts Tiefergehendes wissen. Bei 1. wäre es sinnvoll, den Eintrag in die generelle offizielle Open3Edatapoints.py zu übernehmen, damit eine einmal gefundene Decodierung dann automatisch für alle anderen Geräte angewendet wird. Bei 2. lohnt es nachzusehen, ob es sich in der generellen Tabelle um einen 'einfachen' Codec handelt. Ist es bsw. dort ein O3EUtf8, so liegt die Vermutung nahe, dass es auch ein Utf8 String ist, lediglich mit einer anderen Länge. Dann kann man das in seiner lokalen datapoints_6yz auch so reinschreiben und hat dann die Klartext/de/codierung mit passender Länge. Wenn es etwas complex/er/es ist, muss man gucken...   Für 1. wäre es schön, wenn auf Dauer mal alle Leute entweder ihre _6yx.py's bei uns 'einschicken' oder selber die entsprechenden Datenpunkte in der Open3Edatapoints.py im abnoname/open3e develop branch ergänzen (per Fork -> einpflegen -> zum Mergen pushen). ... Mehr anzeigen

@Thomas_MG  >> weil komischer weise er vorher weiter bis auf 3700 zählen wollte und nach 1371 für jeden did nach 3 Sekunden ein Timeout bekam. Hat mir zu lange gedauert.   Ich habe das p2_timeout von 1 auf 3 Sekunden erhöht, weil 1 Sekunde zumin auf dem virtuellen Bus bei ganz langen Datenpunkten nicht gereicht hatte und es dann zu 'Verschiebungen' bei erkannten DIDs gekommen ist. Das fiel dann auf, indem das Scan-all mit Fehler abgebrochen war.   Ich werde es wieder auf 2 Sekunden reduzieren (oder auf 1,5? - es ist halt nicht immer sicher und auch nicht vorhersagbar, weil keiner weiss, was sonst noch mit welcher Prio auf dem Bus los ist. Es ist eben ein Kompromiss zwischen 'Komfort' (Schnelligkeit) und Sicherheit...).   Der Scan läuft gewöhnlich bis 3500, und in dem Bereich liegen auch die bekannten DIDs. Es kann sein, dass zwischendurch lange keine für das Gerät sind und vlt auch am Ende nicht, aber sicher kann man nur sein, wenn man es versucht hat. ... Mehr anzeigen

>> Kann man via Open3E auch direkt auf die am CAN-Bus angeschlossenen E/A-Geräte zugreifen?   @Bu-Na  du kannst mit Open3E auf alle (UDS-sprechenden) Geräte zugreifen, die von dem Bus, an dem Open3E 'hängt', direkt erreichbar sind. Es gibt aber mehrere CAN Busse in so einem Viessmann System - den externen Bus (Klemme 91), den internen Bus, ggf. den Batterie-Bus, evtl. einen 'Master-Bus' (Own Bus?), ...   Wir haben es bsw noch nicht geschafft, vom Externen Bus an die Batterie Management Systeme zu kommen. Evlt bekommen wir das noch mittels irgendwelcher Gateways hin, aber so weit sind wir noch nicht.   Es gibt also definitiv 'Steuergeräte', an die man aktuell mit Open3E an Klemme 91 nicht dran kommt.   ... Mehr anzeigen

@ghNeandr  der Ansatz Shield mit Signal-Ground zu verbinden folgt dem Konzept, das gesamte Potential einer Schaltung bei einwirkenden Störungen mit der Störung 'mitgehen zu lassen'. Wenn du also ein Signal von 3 Volt gegen Masse hast, und es wirkt eine Störung ein, die sowohl die Masse als auch das Signal um 1 Volt anhebt, hast du immer noch 3 Volt Signalpegel, obwohl das Signal (meinetwegen gegen Erde gemessen) gerade 4 Volt hat (weil die Signal-Masse eben auch um 1 Volt bsw. gegenüber Erde angehoben wurde).   Dieses Konzept ist durchaus sinnvoll, allerdings eher bei räumlich begrenzten Dimensionen. So ein CAN Bus ist aber eher etwas 'längliches'.   Bei der Seite, die du anführst, wird die Versorgungspannung an einer Stelle erzeugt und auch im Bus mitgeführt. Es wird davon ausgegangen, dass auch die Versorgungsspannung im Störungsfall genauso angehoben wird, wie die Signale und der Schirm.   Bei deiner Applikation hast du aber jeden CAN Transceiver mit einer eigenen Spannungsversorgung versorgt. Dazu hatte ich ja oben schon kurz was gesagt.   Man kann das jetzt unendlich weiter auswalzen, es bringt nix. Es gibt bei einem Ground-Konzept nicht eins, das richtig ist und alles andere falsch, richtig und wichtig hingegen ist, dass man ein Ground Konzept ausarbeitet und diesem strikt folgt und nicht mehrere 'Strategien' durcheinander mischt.   Da du das, was Viessmann gemacht oder hinzugekauft hat (E380 - schlecht designed) nicht beeinflussen kannst, hast du nur die Möglichkeit, mit deinem CAN-USB Adapter 'das Richtige' zu machen. Da der (abgebildete) Bus-seitig isoliert, also potentialfrei, ist (sowohl der Transceiver als auch dessen Spannungsversorgung!), solltest du das Potential an das auf dem Bus herrschende anbinden. Zumindest auf der Vitocal gibt es einen CAN_Gnd, und diesen solltest du mit dem CAN_Gnd deines Adapters verbinden. Ich denke, bei der PT2 wird es nicht anders sein.   Wenn du dir die Transceiverschaltung anguckst, werden dir die beiden 25k Widerstände an CAN_Hi/CAN_Lo auffallen. Der Transceiver 'zentriert' sich (im rezessiven Zustand) also sozusagen selber um 0,5V über GND. Das funktioniert so lange, wie nicht von der anderen (dem Bus 'abgewandten') Seite etwas mit weniger Impedanz das Potential verschieben will.   Da es nicht in deiner Hand liegt, das gesamt System gleichförmig floaten zu lassen, solltest du Störungen, die der Schirm einfängt, nicht auf das Gnd-Potential des (Signal-)Busses leiten.   Wie gesagt - das ist eine Wissenschaft für sich und es gibt dabei nicht eine allgemeingültig richtige Lösung, ausser dass das Konzept stimmen und durchgängig beachtet werden muss. Häufig wird der Schirm mit einem RC Netzwerk irgendwohin gekoppelt, ob an PE oder Gnd ist dabei die Frage des Konzepts.   Was schreibt Viessmann zur Schirmanbindung?   >> Der in der Diskussion gezeigte Steckeradapter hat eine galvanische Verbindung vom 9-poligen Steckergehäuse zum GND-Schraubanschluß Richtig! Der GND Schraubanschluss hätte aber mit 'Shield' oder 'Cover' bezeichnet werden sollen und hat eben keine Verbindung zum CAN-Bus GND, welcher auf Pin 3 geführt wird!   Viel wichtiger als der blöde Schirm ist das Verdrillen der CAN_Hi und CAN_Lo Signalleitungen. Und dabei drauf achten, dass sich Gnd nicht um mehr als die oben gelb markieren Spannungen von diesem verdrillten Leistungspaar entfernt. Das erreichst du am besten, indem du nichts von aussen auf Gnd einkoppelst. ... Mehr anzeigen

@ghNeandr, @ alle >> Frage: kein GND anschließen? Wenn ja, wo? Denn am E380CA sehe ich keinen Anschluß!  >> GND ist für die Schirmung gedacht, ...   Die Antwort von Jürgen ist nicht gaaaanz vollständig richtig. Beim Studium der Datenblätter von CAN Transceivern (hier TJA1015) findet sich Folgendes:   Diese Spannungsangaben sind auf GND bezogen, und wenn man mit einem isolierten CAN Adapter (oder sonsteinem 'Node') völlig ohne irgendeinen GND Bezug arbeitet, der Node also völlig frei floatend ist, kann es passieren, dass durch irgendwelche Einflüsse (häufig Ableitkondensatoren von Schaltnetzteilen oder irgendwelche Einkopplungen) der Transceiver auf ein Potential floated, bei dem die oben gelb markierten Grenzen nicht mehr eingehalten werden. Dann gerät der Receiver in's Clippen und sieht die Signale nicht mehr. Ich habe viel in industriellen Umgebungen mit CAN gearbeitet und weiss aus Erfahrung, dass das durchaus ein Thema ist. Auch in CAN Implementation Guidelines wird immer die GND Verbindung empfohlen (3-Draht Verkabelung).   Der CAN Gnd vom E380 ist wahrscheinlich irgendwie impedant auf PE oder so bezogen, und in den meisten Fällen funktioniert es damit dann ohne ein CAN Gnd. Ein vollkommen isolierter CAN-USB Adapter sollte dann aber auch auf dieses Potential bezogen werden, damit er nicht irgendwohin floated (jenseits der -27/+40V gegenüber den Signalen). Die sauberste Lösung ist eben, sämtliche Transceiver isoliert auszuführen und CAN-Bus-seitig GND auf einem Potential zu verbinden - die 3-Draht Verkabelung eben. 🙂   Dabei zu beachten ist, das CAN GND auch Gnd von Vcc ist, bei unterschiedlichen Spannungsversorgungen der unterschiedlichen Transceiver also auch hier auf eine Isolierung oder eben Bezug auf ein einheitliches Potential zu achten ist.   Lasst euch jetzt keine grauen Haare wachsen, CAN ist gewöhnlich recht betriebssicher. Aber definitiv führen in der Praxis Potential 'Issues' sehr viel häufiger zu Kommunikationsproblemen, als irgendwelche Störungen durch Einstreuungen (Stichworte Verdrillen, Abschirmung) oder sowas (da ist CAN nämlich wirklich sehr unempfindlich).   Grüsse!    ps. jetzt noch ein letzter Klugschiss: Eine Abschirmung sollte gewöhnlich NICHT auf CAN_Gnd geführt werden, sondern die Störungen nach PE abgeleitet werden. Wenn man Störungen auf ein Signal-Ground ableitet, bringt man ein gesamtes System zum 'tanzen'. Es gibt Ground-Konzepte, bei denen das gewollt ist, bei einem räumlich ausgedehnten Bus sollte das aber möglichst vermieden werden.   Deswegen ist dieser GND auch NICHT CAN_GND (= Pin 3) sondern das ist der GND für die Schirmung und der liegt gewöhnlich am Gehäuse und das an PE 😉 ... Mehr anzeigen

@TSG  top Sache dein Wiki!! konnte bisher nur kurz reinschauen, aber was ich gesehen habe ist super! Haben wir deine Zustimmung, das bei uns im open3e zu verlinken?! ... Mehr anzeigen

bist du der, der uns auf github bezgl. der Datenpunkte für die PT2 angefunkt hat? Es wäre super, wenn du bei der PT2 das depictSystem mit Option -s laufen lassen könntest und mir die ganzen Dateien devices.json, Open3Edatapoints_*.py und virtdata_*.txt schicken könntest (nicht öffentlich, da stehen Seriennummer etc drin, die sollen nicht in's Netz. Ich schick dir meine eMail Adresse per PM).   Die Option -s (--simul) bewirkt, dass die eh ausgelesenen Daten in die virtdata_*.txt geschrieben werden. Damit kann ich dann meine virtualE3 Simulation füttern und habe praktisch ein Abbild deiner PT2 Anlage. Vielleicht gewinnen wir damit weitere Erkenntnisse, eine PT2 haben wir noch nicht 😉     ... Mehr anzeigen

Moin Thomas!   >> Wie starte ich eine zweite Instanz? Einfach ein zweites mal aufrufen mit dem Parameter -c can1 Ja, du kannst es einfach ein zweites Mal starten (in einem neuen Terminalfenster oder sonstwie).   >> Depict (mit Parameter -c can1) ... Es hat die Dateien devices.json neu geschrieben, Den Aspekt hatte ich tatsächlich nicht bedacht, es ist aber kein Problem:   Benenne devices.json einfach um in devices1.json und starte die Open3Eclient Instanz auf -c can1 mit -cnfg devices1.json Dann depictSystem noch mal auf can0 laufen lassen, die resultierende devices.json in devices0.json umbenennen, und starte die Open3Eclient Instanz auf -c can0 mit -cnfg devices0.json   ... Mehr anzeigen

@Hotzen-Plotz  BCU steht für 'Burner Control Unit'. Das ist die Brennersteuerung. Damit besser keine Schreib-Experimente machen 😉   @Dreman  komischerweise gab es auch schon früher bei Vitodens einen Datenpunkt für die Rücklauf-Sensor-Temperatur. Anscheinend gibt es Modelle, die einen Rücklaufsensor haben. Meine hat die Rücklauftemperatur aber auch nur als berechneten Wert, obwohl es eine 300er ist. ... Mehr anzeigen

ps. zumindest besteht dann begründete Hoffnung. ich glaube früher gab es irgendeine Optolink-Platine (wird zumin ab und zu auf ebay angeboten), ggf. war die nicht immer verbaut... ... Mehr anzeigen

@UlrichC  guck mal ob du das V mit den beiden LEDs links und rechts daneben findest. Bei den alten Steuerungen könnte das auch 'auf weissem Grund' sein.     das wäre die Optolink Schnittstelle. das ist zwar nix für open3e, aber mit den openv Tools kommst du da dann dran.   Grüsse! Phil ... Mehr anzeigen

oder des Zeitfaktors wegen mit den Leuten von heiz24.de telefonieren, ob bei dem von ihnen angebotenen die Lager erneuert sind und dann das nehmen. Ich glaube, das kannst du selber einbauen, wahrscheinlich musst du da an nix ran was kritisch wäre wie Gasleitung, Gaskombiregler oder Berennraum(dichtung), ... oder wie ist das @Franky  @Fiedel ?! (ich kenn die alten Dinger nicht...) ... Mehr anzeigen

na dann ran an den Lagertausch und 1.000 EUR sparen. Aber Beeilung - es wird schon kalt draussen... 😉 ... Mehr anzeigen

>> Für die VX3 noch -dev vx3. die VX3 sollte beim depictSystem mit erfasst werden und dann in der devices.json stehen, wahrscheinlich mit Adresse 0x6A1 oder so. das -dev wird ignoriert, wenn ein -cnfg <Datei> angegeben ist.   Das wo die Buswiderstände sitzen ist nur bei weiter räumlicher Ausdehnung relevant. Wenn du nur ein paar Meter hast, ist das egal. Bei sehr langen Leitungen sollten die beiden Widerstände jeweils am 'räumlichen Ende' sitzen. Die ziehen ja nur eine rezessive 'Situation' zu 0V_diff, und wenn zu viel Kabel dazwischen ist, funktioniert das möglicherweise nicht zuverlässig (bei 1/4 MBd sollte das einigermassen zügig passieren).   ... Mehr anzeigen

vielleicht würde es bei der betagten Therme auch ein generalüberholter zum halben Preis mit 2 Jahren Garantie bei Einsendung des Altteiles tun (wenn der Heizi den einbaut - is ja immer so eine Sache mit der Gewährleistung - zumindest die Arbeit bliebe ja auf ihm hängen).... https://www.heiz24.de/ebm-RLS154/1600-55667-02065-Geblaese?gad_source=1&gclid=EAIaIQobChMI6-jq-ffrggMVIRqiAx30DgzXEAQYBiABEgIhzvD_BwE   Das scheint ein hochwertiger ebm Lüfter zu sein - vielleicht reicht auch ein Lagertausch oder so. Hat das Gebläse vorm Ausfallen Geräusche gemacht?   ... Mehr anzeigen

Willkommen Neandr!   Der Adapter den du verlinkt hast ist ein anderer als der von Hotzi erwähnte, sollte aber grundsätzlich auch gehen. Deiner ist nicht galvanisch getrennt, du müsstest also mit Masseschleifen/Potentialbezügen aufpassen. Ich empfehle immer isolierte Adapter wie den bei Hotzi im Bericht. Ausser dem Adapter brauchst du ggf. noch einen Stecker, wenn du nicht eine Klemmleiste hast. Die Adern vom Klingeldraht verdrillen/verpflechten wenn die Leitung etwas länger wird. Wenn sie noch länger wird vlt ein altes LAN Kabel nehmen (verdrilltes Paar für hi/lo). Positionierung der beiden 'Abschluss'widerstände am Bus beachten.   Der Raspi ist schön wenn noch ein kleines bischen Speicher übrig ist, Bullseye könnte das sporadische Timeoutproblem mit dem ISO-TP Kernel haben, sollte sich dann aber mit dem Kernel Update a la @JörgWende beseitigen lassen (erstmal abwarten).   Bis auf die 'Zusammenlegung' von MQTT user:password hat sich nix gegenüber Hotzis Anleitung geändert meine ich. Statt -dev vcal vielleicht besser ein depictSystem machen und dann mit Option -cnfg devices.json starten (steht im args schon drin, wenn du statt der ganzen cl Agumente einfach @args benutzt), dann hast du die VX3 gleich auch mit drin. Der E380 spricht kein UDS, wird aber glaubich von der VX3 abgebildet. Sonst noch Schwesterprojekt E3onCAN mitlaufen lassen (vielleicht eh ne gute Idee, weil was du davon bekommst, brauchst du nicht extra anfordernd auslesen).   bei Fragen einfach hier rein 😉   Grüsse & gutes Gelingen! Phil ... Mehr anzeigen

Moin! Es wäre gut gewesen, wenn du das Modell oder noch besser die Herstellernummer (erste 7 Ziffern reichen) angegeben hättest. Ich habe über 20 333er (auch 300er) durchprobiert, aber die haben alle ein anderes Bedienteil. Jetzt musst du wohl selber tätig werden, wenn du es bis morgen wissen willst: Gebe auf https://www.viessmann.com/etapp/search/de/0500 die Herstellernummer deiner 333 ein, gehe auf 'Ersatzteile', such das Gebläse, nimm die Nummer und suche in Googel... Grüsse! Phil   ... Mehr anzeigen