Climate Solutions Community

@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:   HerrP_1-1701771920618.png 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. HerrP_0-1701771583376.png 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) HerrP_3-1701774582163.png 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.   HerrP_0-1701468860495.png   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

Moin! Hast du mal die Zeiten direkt an der Therme kontrolliert und nicht nur in der App? Grüsse! Phil ... Mehr anzeigen

>> angezeigte Wert ist in Wirklichkeit die 'Aussentemperatur gemischt' oh, ok, dann hat sich das beständig gehalten 😁 Diesen Fehler oder diese Durcheinander gab es früher auch schon 😉   ... Mehr anzeigen

ps. >> Für meinen Geschmack war das "Versteck" dieses Parameters bei der alten Vitotronic völlig ausreichend  zumindest zu Zeiten dieser Gas-Notstandsverordnung (oder wie die heisst) könnte man es sogar als gesetzeswidrig bezeichenen, diese Einstellung nur gegen einen Obolus freizuschalten. Schliesslich verbraucht eine nicht richtig 'folgende' Vorlauftemperatur unnötig Gas, und zu Gasmangelzeiten ist jeder verpflichtet, Gas nicht zu verschwenden. Das darf nicht durch kostenpflichtige Abos verwehrt werden....   ... Mehr anzeigen

danke für die Info zu wie wer an die Möglichkeiten der 'Pro-Version' dran kommt! Ist die grundsätzliche Nutzung des Tools (das Account für den Log-in) eigentlich auch noch mal kostenpflichtig für den Fachhandwerker?   hihi, ja, Viessmanns Kontinuität und Aktualität bei den übermittelten Daten ist ja nicht nur einmal ein Thema (von Kritik) in diversen Threads gewesen.... Ich vermute mal, da war die Übertragung abgebrochen (oder es wurden irgendwelche Wartungsarbeiten in der Cloud durchgeführt oder sonstwas) und die letzten eingesammelten Werte wurden einfach als weiter gültig angenommen. Beim Lüfter zuckt ja auch nichts mehr.   Was mir noch einfällt... Was im Eröffnungsbeitrag steht ist nicht gaaanz richtig. Die Berechnung des Vorlauftemperatursollwertes geschieht nicht anhand der gedämpften Aussentemperatur, sondern anhand der gemischten Aussentemperatur (jedenfalls bei den 'alten' Thermen und ich wüsste nicht, warum man das ändern sollte). Die wiederum setzt sich zusammen aus 70% gedämpfter und 30% aktueller Aussentemperatur, also ATgem = ATged * 0,7 + AT * 0,3 Mit dieser gemischten Aussentemperatur kann man zu jedem Zeitpunkt in die Formel gehen und es passt bis hinter's Komma. Wenn man genau hinschaut, steht das da auch   HerrP_0-1701290695818.png   Grüsse! ... Mehr anzeigen

@MacVito  >> Eigentlich geht es mir nur um die Parameter 2426.1 und 2427.1 die kannst du mit open3e ändern   ... Mehr anzeigen

Moin @Erwin !   Ja, das mit der 'thermischen Konstante' des Hauses ist so eine Sache, und sie wird ja auch von vielen Leuten nicht richtig verstanden, und ist deshalb ja nicht ganz unberechtigt ein 'etwas geschützter' Parameter. Nichts deto Trotz ist es ein wichtiger Parameter, der auch einstallbar sein muss, damit die Regelung richtig funktioniert.   Die Sache verhält sich ja so (du weisst das, aber vielen Leuten ist das eben nicht bewusst, deswegen hier nochmal):   HerrP_0-1701256657631.png   Links ist die Aussentemperatur, rechts ist der zu temperierende Wohnraum und dazwischen ist die Aussenwand mit Isolierung. Das Ganze verhält sich (angenähert) wie ein Tiefpass 1. Ordnung (Physik, Exponentialfunktion, die Zeile unten ist die Realsierung eines solchen in einem digitalen System (witterungsgeführte Heizungssteuerung)). Der Faktor ist das, was man mit dem Parameter für die Dämpfung einstellt.   Ich nehme immer gern das Beispiel Bauwagen mit Wellblechwand gegenüber Styropor-Beton-Bunker Neubau.   Wellblech-Bauwagen: Der Faktor ist sehr klein. Wenn sich draussen die Temperatur ändert, muss drinnen die Vorlauftemperatur nahezu unmittelbar reagieren.      Styropor-Beton-Bunker Neubau: Der Faktor ist sehr groß. Wenn sich draussen die Temperatur ändert, passiert an der Innenseite der Aussenwand zunächst einmal nahezu garnichts. Das liegt zum einen an der dicken Isolierung, die die Temperaturänderung kaum durchlässt, und zum anderen an der großen thermischen Masse der dicken Betonwand, die sehr träge auf eine sich ändernde Temperatureinwirkung reagiert. Die meisten unserer realen Häuser liegen irgendwo dazwischen. Bei einem Altbau mit Fassadendämmung liegt der Faktor schon höher als bei einem Altbau ohne Fassadendämmung, bei einem Holzhaus liegt der Faktor neidriger als bei einem Steinhaus mit vergleichbarer Isolierung (-> thermische Masse).   Viele Leute haben jetzt die irrige Vorstellung, dass bei ihrem Haus bei sich ändernder Aussentemperatur die Vorlauftemperatur sofort proportional reagieren müsste, und um das zu erreichen, stellen sie den Faktor ein, als würden sie in einem Wellblech-Bauwagen wohnen.   Fakt ist, dass meiner Meinung nach die Default Einstellung 1280 Minuten = ~21 Stunden in vielen Fällen (bei vielen Häusern) zwar zu hoch ist, aber es sich bei den allermeisten Häusern trotzdem nicht um Gebilde mit Wellblech-Bauwagen Charakteristik handelt.   Ich habe für mein 1933 Wohnhaus mit doppelter Rotziegel(hohl)wand mit 7cm ausgeblasenem Zwischenraum nach längerem Experimentieren 960 Minuten eingestellt.   Zum Verständnis: Nach der Dauer von 1 Zeitkonstante ('Faktor') wäre die Innenseite der Aussenwand einer schlagartigen Temperaturänderung dieser zu 63% gefolgt (wenn nicht dagegen angeheizt wird).   Also angenommen, es war draussen im Sommer wochenlang Tag und Nacht 30°C, und plötzlich fällt die Temperatur auf konstant 20°C, dann ist meine Innenseite der Aussenwand nach 960 Mintuten = 16 Stunden um 6,3°C kühler geworden auf 23,7°C   Das ist natürlich alles Theorie, es hat nie konstant über Wochen eine gleiche Temperatur, die sich schlagartig um 10°C ändert, aber das Modell funktioniert trotzdem. Das ist ein Grundsatz bei Ausgleichsvorgängen. Darin nicht berücksichtigt ist, dass ein normales älteres Haus nich 'Blow-Door-dicht' ist, und sich die Aussentemperatur auch noch auf andere Weise (bsw undichte Fenster und Türen) nach innen schleicht.   Denkt bei der Einstellung der Dämpfung aber daran, dass ihr nicht in einem Bauwagen wohnt 🙂 ... Mehr anzeigen

moin ihr!   Erwin kann es genau sagen, aber da der noch fleissig bei den Leuten für ne warme Bude sorgt und wahrscheinlich mit Einbruch der winterlichen Kälte damit viel zu tun hat, gebe ich mal meinen 'Wissens'stand kund:   So weit ich weiss, ist Viguide = Viguide und es kann jeder (kostenfrei) installieren. Der Funktionsumfang hängt dabei vom Log-in ab. Wenn man sich mit einem Fachpartner Account (was auch nur ein bei Viessmann als solcher angemeldeter (professioneller) Fachpartner bekommt) einloggt, hat man den erweiterten Funktionsumfang.   Dieser ist dann auch noch abhängig davon, welche 'Lizenz' der Betreiber der Anlage ('Kunde') bei Viessmann gebucht hat. Hat der Kunde die 'Pro-Lizenz' erworben, kann der Fachpartner auf den vollen Parameter-Umfang etc zugreifen, sonst nur auf einen eingeschränkten.   So sieht das aus. Ihr werdet also als nicht 'eingetragener' professioneller Fachbetrieb nie in den Genuss der Viguide Pro Funktionalität kommen.   Ein kleiner Nebeneffekt ist ja auch, dass der Fachpartner auf alle Anlagen zugreifen kann, die auf ihn als 'Betreuer' angemeldet sind. Wenn ihr es also schaffen würdet, eurem Heizi seine Zugangsdaten aus den Rippen zu leiern, könntet ihr die Viessmann Anlagen im halben Dorf 'manipulieren', weswegen der Heizi einen Teufel tun wird, aber euch nicht seine Zugangsdaten verraten.... (mit guten Recht)     p.s. >> Ist das das besagte "Software-Tool", mit dem man z.B. ... mit dem Zusatz "nur mit Software-Tool einstellbar" gekennzeichnet  ja, das ist damit gemeint. mit open3e geht es aber auch 🙂 Es gibt ein paar wenige Parameter (wozu die Dämpfung nicht gehört), die sich noch wheren, aber auch das werden wir noch hinbekommen 😎 ... Mehr anzeigen

>> Der DID 424 verursacht bei mir auch ab und an Warnmeldungen weil der Bezeichner der vierten und fünften Werte da drin mit einem Fragezeichen beginnt.   danke für den Hinweis! Wir werden das durch "Unknown" wie gewöhnlich ersetzen (p.s. schon erledigt) ... Mehr anzeigen

>>> 4) Genauso fiel mir jetzt auf, dass ich die Übersichtsabfrage mit "-a" gemacht habe ohne den "-m 127.0.0.1:1883:open3e" Teil. Nach dem Scan stand da "run Open3Eclient with -mqtt and -a to get EVERYTHING on your MQTT app." Also sollte man mit dem "-m" was tun. Was für eine Auswirkung hat das?   das ist eigentlich egal, wenn du mit dem -a (vielleicht noch mit -v) eine Terminal Ausgabe bekommst. da steht dann auch alles drin, ist nur wenig übersichtlich... 😉 Auf der anderen Seite 'verdirbst' du dir damit nicht deine Anzeige in der MQTT App. ... Mehr anzeigen

ach ja... und > im Moment mit meiner Kommandozeile gar nix im Sinne einer "--config devices-json" schreibe. Was genau ist der Effekt, wenn ich diesen config Teil nicht sende?   Bei deiner Art der Benutzung wird das keinen Unterschied machen. Die Sache mit dem depictSystem hat folgenden Hintergrund:   Wir können nicht (vorher)sagen, in welcher Konfiguration und mit welchen Soft/Firmware Ständen eine Anlage vorliegt. Anstatt eine datapoints für eine Vcal X 200 mit Frimware 1.2.3.4 und eine für eine Vcal Y 250 mit Frimware 2.3.4.5 und eine für ... und eine für ...... (die wir garnicht genau kennen) zu machen, haben wir den 'Scanner' gemacht, der einfach ohne Kenntnis der vorhandenen Steuergeräte, Datenpunkte, Datenpunktlängen und Codecs das gesamte (erreichbare) System abscannt und in die Dateien schreibt, was er gefunden hat. Das passt dann definitiv zu der Anlage.   Gerade bei der Vitodens unterscheiden sich bsw. die Datenlängen von einigen Datenpunkten gegenüber der restlichen Viessmann Produktwelt, was dann (sonst) zu Problemen führt (allerdings haben wir das zur aktuellen Firmware auch in die datapointsVdens geschrieben, also kein Problem, solange sich nix ändert). Auch können wir auf diese Weise einfach bei einem Anlagen-Softwareupdate hinzugekommene oder weggefallene oder veränderte Datenpunkte 'erschlagen', ohne dafür neue datapointsVyz.py in's Netz stellen zu müssen.   Ein zusätzlicher Aspekt ist, dass du nach dem Scan nicht nur die Main Control Unit (Adresse 0x680) in deine Datenpunkten zur Verfügung hast, sondern auch bsw. die Brennersteuerung bei einer Vitodens oder den Kältekreisregler bei einer Vitocal. Was wir auf diese Weise noch nicht erreichen, sind solche Sachen wie die Batterie Management Systeme an der VX3. Die liegen auf einem Bus, der offensichtlich nicht 'direkt' mit dem externen CAN Bus 'verlinkt' ist. Wir sind noch am Tüfteln, ob man da mittels der Gateways drankommt und wenn ja wie...   Interessant wäre, ob diese 'Steuergeräte' bei einem depictSystem Scan per DoIP auftauchen, weil wir da ja die 'Tür' benutzen, die auch von den Inbetriebnahme-Tools und höchstwahrscheinlich auch vom Viessmann Serversystem benutzt wird...      ... Mehr anzeigen

ich glaube diese Modi (standard, comfor, reduced, ...) müssen wir noch in die Enums reinschreiben, damit die Klartext werden. Irgendwie bin ich dabe noch verwirrt, weil sie wohl ab und zu aus einem Byte bestehen und ab und zu noch ein zweites dabei steht, und das noch nicht final geklärt ist.   > 3) Kann ich den Lesenaufruf mit "-r" und all den Dutzenden DIDs auch irgendwie in einer "args" Datei unterbringen?   @Hotzen-Plotz  klar! du schreibst das '-r' in eine Zeile und die ganzen Parameternummern in die folgende. Dabei keine Leerzeichen oder weitere Zeilenumbrüche in die Reihe mit den Zahlen.   -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   ich würde eigentlich alles in die Datei schreiben, also auch die ganzen -m... Sachen. Das hat auch einen Sicherheitsaspekt, weil die ausgeführten Prompts (Kommandozeilen) auf mehrere Arten eingesehen werden können. Wenn du user und password in die Datei schreibst, sind die in der Kommandozeile nicht sichtbar.   Du kannst dir auch mehrere 'args' Dateien machen, z.B. eine, wo eben nur die grundlegenden Sachen drin sind, z.B. eine genargs: -c can0 -dev vdens -m 127.0.0.1:1883:open3e -muser xxx:yyy -mfstr {didNumber}_{didName} und die dann z.B. zum Schreiben oder Lesen einzelner Sachen oder sowas benutzen phython Open3eclient.py @genargs -raw -w 789=0123ABEF -v und deine andre args (inklusive der ganzen zyklisch zu lesenden Parameter und der Zykluszeit und so) für deinen 'normalen' Betrieb/Aufruf.   Allerbesten Dank auch noch mal für deinen beta-Test und die Geduld dabei!! ... Mehr anzeigen

Moin @Barny58 !   die Open3EdatapointsVx3.py ist nur ein 'Overlay' über die generelle Tabelle. Wenn da überall 'None' steht, heisst das, dass es so ist, wie in der Open3Edatapoints.py verzeichnet (None = nix anders). Die Datei ist trotzdem notwendig, weil damit beschrieben wird, welches Sub-Set von Datenpunkten für die VX3 gilt.   du kannst python3 printdatapoints.py -dev vx3 ausführen, das legt das Overlay Open3EdatapointsVx3 über die Open3Edatapoints und du bekommst die Datenpunktliste für die VX3 mit den entsprechenden Codecs.   zu 1. warte bitte noch grad, bis der develop zum master gemerged wurde, dann geht wieder alles (passiert in den nächsten 24 Stunden, bis dahin einfach den develop nehmen, der ist soweit 'perfekt' glaubich) ich habe es gerade gemerged, ich hoffe es hat alles richtig geklappt 😉   Der grundlegende Unterschied zwischen open3e und E3onCAN ist, dass open3e Werte explizit anfordert/ausliest und E3onCAN Daten 'aufschnappt', die vom System sowieso übertragen werden. Manche (viele?) Werte werden aber nur bei Änderung übertragen, d.h. du bekommst sie nicht zyklisch oder im 'schlimmsten' Fall nie. Es werden auch nicht alle Werte übertragen, und Einstellungen kannst du damit auch nicht ändern.   open3e arbeitet hierbei ausschliesslich mit UDS (Unified Diagnostic Services), was vom E380 so nicht wirklich unterstützt wird (der ist ein Zukaufprodukt und spricht mehr CANopen). E3onCAN schnappt aber auch die CANopen PDOs auf. Ich glaube, es gibt bei open3e Datenpunkte, mit denen die E380 Werte von einem anderen Steuergerät (was wiederum die Daten aufgeschnappt hat) ausgelesen werden können.   Lange Rede kurzer Sinn - du kannst open3e und E3onCAN gleichzeitig betreiben und dir von jedem das holen (bzw. auf deinen MQTT Broker holen), was du möchtest / was es bietet. E3onCAN belastet dabei nicht den Bus, weil es nur zuhört. Auf dem Bus ist aber jede Menge Platz, also ist open3e auch nicht problematisch. Ich glaube bei E3onCAN gibt es auch keinen Listener Modus, mit dem du per MQTT Message Informationen anfordern kannst (da bin ich mir aber nicht wirklich sicher, @Juergen-B hab ich was vergessen oder falsch beschrieben?)   Der Fork vom maxxberg ist einfach ein uralter Stand von open3e, da gab es das 'Overlay Prinzip' noch nicht. Soweit mir bekannt, hat er nix, was abnoname/open3e nicht hätte.   ich hoffe, ich hab eine einigermassen passende Erklärung gegeben, sonst sag bitte noch mal Bescheid!   Grüsse! Phil ... Mehr anzeigen

@bb77  danke für die Tests! und für die positive Rückmeldung! 🙂   Die Daten ohne die Simulationsdaten (virtdata_6yz.txt - per Default leider disabled) nutzen mir für meine virtuelle E3 leider nicht viel. Du könntest mal gucken, was für von 'None' abweichende Codecs in den datapoints_6xz.py stehen, ggf. können wir damit die general datapoints erweitern.   Was du mit dem Kram jetzt anfangen kannst, siehst du, wenn du mal ein -a bei MQTT Anbindung ausführst (allerdings besser nur, wenn du problemlos wieder Löschen kannst, das wird ne Menge...). Naja, so gaanz viel Nutzen hat man davon nicht, ausser, dass man sieht, was noch so erreichbar ist, und vielleicht fällt einem dabei ja irgendwas ein 😉   Was auf jeden Fall damit gegeben ist, ist dass die datapoints zu dem System passen (inkl. Modell und Softwarestand) und keine nicht vorhandenen oder nicht gelisteten DIDs da sind und dass die Datenlängen passen (also das -a auch fehlerfrei durchläuft).   ... Mehr anzeigen