CAN Bus, Home Automation E3 Generation lokal und kostenlos

[HerrP]

hier noch mal mein Beitrag aus 'Internet der Dinge', dem Offenen Brief an Max Viessmann, als neuer Thread - Diskussionen, Fragen etc. bitte hier 🙂

Moin Freunde!

Da Viessmann zwar ein wunderschöne Schnittstelle (UDS, ISO-TP oder DoIP) eingebaut hat, das aber nur eingeschränkt und für eine 4-stellige Summe (per WAGO Gateway) zur Verfügung stellt, haben wir uns bekanntlich dran gemacht, das selber offen zu legen. 🙂

Stand der Dinge ist:

- Wir haben eine MQTT fähige Lösung zum Anschluss an den externen CAN Bus ("Stecker 91"), die es erlaubt, E3 Geräte (Wärmepumpen, Gasgeräte, (PV Speicher gerade in der Testphase, BSZ brauchen wir noch Kandidaten)) in Home Automation Systeme einzubinden. ioBroker, mosquitto, Home Assistant, Node-RED und so weiter also alles einfach machbar und bei uns schon im dauerhaften Einsatz.

- Das Ganze läuft lokal, also ohne irgendeine Hersteller oder sonstwelche Cloud, ohne Internet! Bei der CAN Bus Kopplung kann die gleichzeitige Verbindung mit dem Viessmann Server zwecks Wahrung der Gewährleistungs- und Garantieansprüche aufrechterhalten bleiben.

Eine Anbindung über den WLAN Access Point ist auch möglich, damit aber keine parallele Viesmann-Server-Verbindung mehr.

- Aktuell ist nur das Auslesen von Daten weitergehend erprobt. Bei den wichtigen Daten haben wir auch schon die Formate zur Interpretation geklärt, wir arbeiten an einer vollständigen Klärung.

Das Schreiben ist bei einfachen Daten wie z.B. Warmwasser-Solltemperatur und so auch schon erprobt.

- In nicht all zu ferner Zukunft wird es eine einfache Windows Oberfläche zum Setzen der bisher den 'Fachpartnern' mit entsprechendem kostenpflichtigen Account vorbehaltenen Einstellungen wie zum Beispiel den "Energiespareinstellungen" bei den Gasgeräten geben.

und last not least: das Ganze ist natürlich kostenfrei und open source! im Sinne eins besseren Miteinanders 😉

Der laufend aktualisiert werdende Stand der Linux Lösung ist auf

https://github.com/open3e/open3e

verfügbar. Einen guten 'Leitfaden' für den Einstieg hat @Hotzen-Plotz hier zur Verfügung gestellt:

https://github.com/open3e/open3e/discussions/5

Eine Sammlung von nützlichen Informationen hat @TSG initiert:

https://github.com/TheSmartGerman/open3e/wiki

(werden wir bald auch unter das open3e Projekt migrieren) 

beste Grüße!

Phil

zur Beachtung: Der Zugriff auf das Zielgerät mittels dieser durch Viessmann nicht vorgesehenen Lösung zieht möglicherweise den Verlust von Gewährleistungs-/Garantieansprüchen nach sich und kann unter Umständen zu GEFAHREN FÜR LEIBLICHE UNVERSEHRTHEIT ODER SACHWERTE führen! Die Autoren schliessen jegliche Haftung aus.

Beispiele aktueller Home Assistant Integrationen von Wärmepumpen:

Vitocal 250 Kältekreisübersicht: View und Installationsanleitung gibt's hier: https://github.com/MyHomeMyData/iob.vis.vitocal250.git

Jürgen hat auch noch weitere schöne Sachen abgeleitet.

Einen Adapter für ioBroker:

https://github.com/MyHomeMyData/ioBroker.e3oncan

und noch ein paar andre Sachen, die aber in dem Adapter integriert sind. Schaut einfach mal sein Repo an...

https://github.com/MyHomeMyData

ps. wer uns unterstützen will und kann ist herzlich willkommen!

pps. und wir freuen uns über jedes 'like' (👍) - damit zeigt ihr deutlich, dass ihr eine offene und lokale Kommunikation mit den 'One Base' Geräten eigentlich von Viessmann erwartet

[GW3]

Hallo @HerrP 

danke für deine Antwort mitten in der Nacht.

Hier meine Rückmeldungen zu deinen Fragen

Passwort: Danke für deinen Hinweis, war ein Versehen, ich hab mein Passwort geändert

Der Wert 268 steht nicht in ..._680.py sondern in ..._6cf.py

264 : None,
268 : None,
381 : None,

Da hab ich aber nichts daran geändert.

Ich hatte zuerst nur meine datalist geändert, einen Reboot gemacht und

python3 Open3Eclient.py @genargs @datalist

aufgerufen.

Im MQTT Explorer werden manche Werte manchmal mit time_out und manchmal mit

none angezeigt.

Als nächstes habe ich mir das aktuellste Open3Eclient.py (von yesterday) geholt, hat aber nicht geändert.

Als nächste hab ich versucht

python3 Open3E_depictSystem.py  laufen zu lassen.

Da bekomme ich aber den Fehlermeldung (siehe unten).

An der HW hab ich nichts geändert, die sehe ich aber unkritisch, sind nur ca. 50cm Kabel, verdrillt und GND auf beiden Seiten aufgelegt.

Ein update  / upgrade hab ich nicht gemacht.

Würde es was helfen einen Canalyster parallel mitlaufen zu lassen?

Könnte ich evtl. heute abend machen.

[HerrP]

Moin @GW3 !

Wir haben es also mit dem Timeout zu tun. Dagegen bin ich erstmal machtlos 😕 Die Ursachen sind bekannt, und es wird (im Normalbetrieb, nicht beim ECU Scan von depictSystem) zumindest bis zu 3x wiederholt versucht, den Datenpunkt auszulesen.

Noch mal zur Sicherheit nachgefragt: Du hast genau 2 (zwei) Buswiderstände angeschaltet? (weil es da schon mal Unklarheiten gab: Jumper auf dem CAN2USB Adapter gesteckt bedeutet Widerstand 'aktiviert', Brücke am E380 eingebaut bedeutet Widerstand 'aktiviert', an den A250 wird der Widerstand glaubich direkt an den Stecker zwischen hi und lo geschraubt)

Die ganzen Datenpunkte von der -r Liste möchtest du von der HPMUMASTER ECU (Adr. 680h) lesen, richtig? Du hast ja bei keinem eine andre ECU Adresse davor gesetzt.

Dann mach den 'Trick' und lass das Overlay weg. Ich glaube, bei der A250 stimmen die Datenpunktlängen ganz überwiegend mit denen in der generellen datapoints überein, also brauchen wir das Overlay nicht, solange wir kein scanall machen wollen. Sollten wir einen Datenpunkt mit anderer Länge erwischen, werden wir das dann schon merken (und können das dann ggf. zurechtbiegen).

Hierzu bitte die beiden Zeilen mit dem -cnfg devices.json aus der genargs löschen.

Ich hab jetzt nicht im Einzelnen geschaut, aber die Datenpunkte deiner -r Liste stehen ja alle in der Open3Edatapoints.py, oder? Dann hast du zumindest die Codecs zu Interpretation in der dataIdentifiers und sie sollten dann auch vernünftig dargestellt werden, wenn sie ausgelesen werden und nicht der Timeout zuschlägt. Wenn (wiederholt!) keine Daten kommen, hilft das natürlich auch nix, open3e beherrscht keine Telepathie 😁

Bitte schau auch mal, ob Open3Eclient zwischendurch mal "ERROR max retry" ausgibt.

Was mich allerdings wundert, ist, dass das Auslesen von 268 von ECU 680 jemals geklappt hat. Gemäss den Daten, die du mir geschickt hattest, und auch entsprechend deiner Aussage, dass 268 garnicht in der  datapoints_680 steht, hätte das nie richtig funktionieren 'dürfen'...

Grüsse!

ps. ach ja, und lass ruhig einen candump mitlaufen. den möglichst in eine Datei speichern (die wird groß, wenn es länger läuft, also auf genug Speicherplatz achten). Mach das bitte ungefiltert mit Time Stamp, also

candump can0 -tA > dump.txt

und schick mir die dann (zip!). meine eMail hast du ja noch, oder? sonst an open3e/at/web.de

Solltest du knapp mit Speicherplatz sein, filtere auf die 6** Frames:

candump can0,600:700 -tA > dump.txt

[Thomas_MG]

@HerrP 

Hab die neue geladen und war anfangs vielversprechend. Ist wieder in einen Timeout gelaufen und dann hab ich die zweite Instanz mit einem systemd laufen und überwachen lassen. bis jetzt läuft es einmal am Tag in den Timeout.

Die erste Instanz läuft fröhlich weiter mit 109h auf dem Buckel  und wurde manuell gestartet.

Ich kann jetzt so damit leben und hoffe dass ich irgendwann upgraden kann auf die neuste Version und alles läuft. Ich verstehe nur nicht warum Buster bei manchen keine Probleme verursacht. Werde aber noch weitere Datenpunkte am PA2 einfügen nach und nach.

Nur zur Vollständigkeit:

2 Canbus Adapter am PI3 mit Buster

VCAL ist an interner Klemme 91 angeschlossen mit GND

PA2 ist an E380 angeschlossen mit GND auf dem Terminal Anschluss.

[HerrP]

moin @Thomas_MG !

spät, aber es war Weihnachten... Hm, das ist mal ziemlich frustrierend mit diesen Timeouts. Die TimeoutException kommt aus udsoncan. Da sind 20 Sekunden für alle Timeouts eingestellt, und die neue open3e macht 3 wiederholte Versuche bei Timeout. Ich glaube, das Wiederholen bringt nix. Wenn sich das einmal weggehangen hat, geht nix mehr, das hab ich auch schon beim TimeoutError gesehen (der kommt vom System).

Etwas ist seltsam an deinem Screenshot: Gewöhnlich sollte mittlerweise auftauchen "during handling the Exception another Exception occured...", weil der Fehler zunächst abgefangen wird und erst beim vierten Mal dann im Exception Handler ge-raise-t wird. Bist du sicher, dass du auch bei der Instanz die neue Version von open3e hast?

Ich überlege, ob ich die CAN Kommunikation auf can-utils (das wo auch cansend, candump, ... herkommt) umprogrammieren soll. Mit udsoncan/isopt scheinen wir die Geschichte irgendwie nicht so richtig los zu werden 😕 Aber das ist ein tierischer Aufwand, auch weil die ganze Codec Geschichte im udsoncan steckt. Und es weiss niemand, ob man damit das Problem dann wirklich los ist und ob man sich nicht ein möglicherweise ein anderes einhandelt. Und mit DoIP wär es dann auch vorbei.

Es ist natürlich auch so, dass wir nicht wirklich viele Fälle haben, in denen open3e mit 2 Adaptern / in 2 Instanzen läuft. Einen Tag nach deinem Post hatte ghNeandr (der hatte ja auch richtig Probleme mit dem Timeout Mist) berichtet, dass bei ihm mit 64bit Buster jetzt alles problemlos läuft. Hast du auch das 64bit? Auf Raspi4 wissen wir von Problemen mit 32bit Bullseye, aber irgendwie scheint es da auch keine Regelmässigkeit zu geben. 

Mir gehen langsam die Ideen aus. 😢

>> mit GND auf dem Terminal Anschluss.

Was meinst du mit 'Terminal Anschluss'?

Grüsse!

Phil

[Juergen-B]

---

Ich überlege, ob ich die CAN Kommunikation auf can-utils (das wo auch cansend, candump, ... herkommt) umprogrammieren soll. Mit udsoncan/isopt scheinen wir die Geschichte irgendwie nicht so richtig los zu werden 😕 Aber das ist ein tierischer Aufwand, auch weil die ganze Codec Geschichte im udsoncan steckt. Und es weiss niemand, ob man damit das Problem dann wirklich los ist und ob man sich nicht ein möglicherweise ein anderes einhandelt. Und mit DoIP wär es dann auch vorbei.

---

Hallo Phil, wenn man die CAN-Kommunikation ohne udsoncan abwickeln möchte, muss man ReadByDid und WriteByDid nachbauen. Ersteres habe ich für den ioBroker-Adapter bereits umgesetzt, das sollte sich zügig in Python umsetzen lassen. WriteByDid sollte auch kein großer Aufwand sein.

Die Codecs können trotzdem aus udsoncan direkt weiterverwendet werden, da reicht eine Zeile:

from udsoncan.common.DidCodec import DidCodec

Das verwende ich in E3onCAN. Funktioniert problemlos.

Und jetzt kommt das große ABER: Ich habe erhebliche Zweifel, dass wir die Timeout-Thematik dadurch loswerden. Denn die Pseudo-Timeouts kommen aus iso-tp und eben nicht aus udsoncan. Die Timeouts aus udsoncan sind reale Fehler, d.h. die angefragte ECU antwortet nicht, trotz korrekter CAN-Kommunikation. Die iso-tp Timeouts werden durch einen Bug im Linux-Kernel verursacht. Der dürfte weiterhin zuschlagen, wenn wir udsoncan umgehen.

Deshalb mein Fazit: Wäre machbar, ist aber nicht sinnvoll.

[HerrP]

Moin Jürgen!

Das mit dem 'Nachbauen' ist schon klar, hab ich ja in der virtualE3 auch schon gemacht, allerdings als Server, nicht als Client, aber sogesehen kein (grosses) Ding. Das mit den Codecs ist ein guter Hinweis, ich würde es evtl auch einfach rüberkopieren, um die Abhängigkeit zu udsoncan los zu werden.

isotp kommt aus der gleichen Schmiede (Pier-Yves Lessard) wie udsoncan und udsoncan benutzt isotp und da kommen die Probleme her denke ich. can-utils und python-can haben damit nix zu tun.

Wir haben ja 2 Phänomene:

1. (udsoncan.Exceptions.)TimeoutException: In dem Fall funktioniert die Kommunikation auf dem CAN Bus völlig korrekt, nur isotp/udsoncan 'realisiert' die Antwort nicht.

2. (System.)TimeoutError: In diesem Fall gelangt der Request (Frame) garnicht auf den CAN Bus, sondern es wird nahezu unmittelbar (innerhalb ca. 100ms) ein 'timed out' vom System gemeldet.

(100ms time.sleep vor einem Retry, 5 'Cycles' pro Sekunde)

Fall 1 würden wir mit dem Umbau mit sehr hoher Wahrscheinlichkeit in den Griff bekommen. can-utils.candump sieht ja schliesslich die Antwort.

Bei Fall 2 bin ich mir nicht unbedingt sicher, aber ich wäre einigermassen zuversichtlich...

Grüsse!

Phil

[Juergen-B]

Für E3onCAN nutze ich diese CAN-Bilbiothek: https://pypi.org/project/python-can/

Du denkst, die ist nicht von Problem 2 betroffen? Dann würde es sich vielleicht wirklich lohnen, mal einen Prototypen zu stricken.

[HerrP]

lass uns mal beizeiten ein Online Meeting machen, dieseswegen und auch wegen der 'Windowsanbindung'!

[JWolke]

Hallo in die Runde und vielen Dank, dass ihr in eurer Freizeit die Dinge fertig programmiert und uns allen die Möglichkeit geschenkt habt, Dinge gerade zu biegen! Und zumindest mit Zugang über WLAN funktioniert für die fixe, manuelle Durchsicht auch Windows. (Leider ohne open3e_depictsystem - Windows not supportet)

Seit November 2023 darf ich mich nun auch mit den "umfangreichen" Einstellmöglichkeiten rumärgern und die Standardeinstellungen bestaunen (Vitocal 250-A).

Ein paar Fragen hätte ich noch:

Habt ihr zufällig schon eine Möglichkeit gefunden, die Art der Abtauung umzuschalten? Also anstatt den internen Puffer aufheizen und damit abtauen, ohne Nachheizung den Puffer/Heizkreise zu "kühlen"?

Könnt ihr schon sagen, welches Format der Parameter 2256 : O3EInt16(2, "DesiredThermalEnergyDefrost") hat? kJ wäre ja recht passend (Abfrage kommt bei mir mit 2050.0)

Gibt es einen Parameter für die Limitierung der Lüfter der Außeneinheit? Derzeit max bei 65/60%

Dankeschön und ein angenehmes Wochenende
Grüße
JWolke

[HerrP]

@JWolkehast du bei depict_system die -d Option mit IP Adresse hinter gehängt? In der aktuellen Version habe ich das ergänzt und ich meine zu erinnern, dass auch schon jemand bestätigt hat, dass es geht. Der Kommunikationsweg ist dann identisch mit dem von dem Rest von open3e.

Das mit dem Puffer umschalten hat schon wer gemacht (auch wieder aus der Erinnerung gesprochen). Du musst mal im Thread zurückblättern (ich weiss, der is inzwischen recht lang...) oder in den Issues/Discussions auf github gucken - irgendwo steht das. Wenn du es gefunden hast, vielleicht eine Notiz in das Wiki schreiben, scheint ja öfter gefragt zu sein... (oder zur Not noch mal grad hier rein, dann übertrag ich das).

Für Details zu den Wärmepunpen bin ich der Falsche, ich hab noch ne alte Gastherme 😉

Grüsse!

Phil

[JWolke]

Ich werd‘ verrückt; ein kleines -d und es läuft! Dankeschön!

Dann werd ich mich mal auf die Suche machen, wie man der WP andere Abtauoptionen anbieten kann.

Grüße

Jwolke

[HerrP]

das freut mich dass es geht, danke für die Rückmeldung!

Wie gesagt, wenn du irgendwas Nützliches auch bezüglich der 'Anwendung' rausfindest, bitte gern in das Wiki schreiben!

Grüsse!

[jokermic]

@JWolke Was für Vorteile erhoffst du dir von anderen Abtauoptionen? Ich habe seit kurzem auch meine Vitocal 252-A mit der open3e angebunden und beschäftige mich auch gerade mit den Möglichkeiten

[JWolke]

Hallo jokermic

Kurzfassung:

Es sind zweierlei Vorteile, die eventuell dabei rausspringen:

1) kürzere Abtauzeiten

und

2) verbesserte JAZ

Langfassung:

U.a. nach der Serviceanleitung gibt es neben dem Verlassen des Kennfeldes noch eine Zeitkonstante, die einen Abtauprozess auslösen kann. Das diese auch reichlich genutzt wird zeigt sich am Bild Abtauvorgang_unnoetig (die dunkelgrüne Linie ist der gerechnet COP aus Wärmeleistung im Heizkreis und einem virtuellem Zählpunkt mittels Modbus aus der Hausinstallation) im Vergleich zu einem nötigen Abtauvorgang, bei welchem vor dem Abtauprozess der COP recht zügig kleiner wird.

Neben der naheliegenden Lösung diese auszuschalten (wobei ich glaube, dass dies nur durch ein Softwareupdate umgesetzt werden kann?), bleibt mir nur den eigentlichen Abtauvorgang zu optimieren.

Derzeit ist dieser jedoch recht simpel implementiert (unabhängig von den Witterungsverhältnissen oder tatsächlicher Vereisung):

a) heize den internen Puffer auf eine Temperatur X

(nach Nutzung open3E wahrscheinlich auf 2050 J Energieinhalt; 2050 = 4,19kJ/(kg*K)*18 kg interner Puffer*28 K (minimale Abtautemperatur 20°C, Aufheizung auf SOLL_VL 46°C und Beendigung Aufheizung bei SOLL_VL+2K = 48°C)

b) schalte den Kältkreis um und taue ab, bis theta_Verdampfer=40°C

Das Problem dabei ist, dass auch wenn kein Eis am Verdampfer vorhanden war, im Laufe des unnötigen Abtauprozesses auf jeden Fall welches entsteht, was dann wiederrum geschmnolzen werden muss. Zugleich sinkt beim Aufheizprozess des internen Pufferspeichers der Wirkungsgrad des Verdichters massiv ab, da das Druckverhältnis von gesunden 3 auf ungemütliche runde 10 erhöht wird, der Verdampfer auf ca. -20 °C abgekühlt werden muss, ebenso die Lüfter und deren Rahmen, damit vermehrt Eis am Rahmen des Lüfters gebildet wird (wenn der Abtauprozess beendet (Dampfentwicklung) wird und die Rahmen noch -15 °C haben) und der Verdampfer somit deutlich stärker erwärmt werden muss, als ohne den ganzen Aufwärmprozess.

Zusätzlich kommt es durch die Umschaltung des Vierwegeventils in der Außeneinheit zu Druckschlägen und recht beeindruckend Heizraten (Kondensation 95°C Heißgas an -20 °C Saugseite) der Kältemittelleitungen, die mir auf Dauer einfach nicht zusagen.

Bei den unnötigen Abtauvorgängen kommt erschwerend hinzu, dass anscheinend das Heizungsintegral nicht zurückgesetzt wird. Zumindest war dies eine Erklärung bei anderen Einträgen im Forum bzgl. des Abtauverhaltens einer Vitocal 222. Daraus resultiert eine erhöhte Vorlauftemperatur, inkl. Schwingungsverhalten (Verdichter moduliert zwischen 100% aufgrund Schnellaufheizungsanforderung und 19% wegen Überschreitung SOLL_VL - die zwei Zustände liegen allerdings gute 10 m auseinander und beeinflussen sich somit im 15 Sekundentakt), schlechterem COP aufgrund der höheren VL, Erreichen der Abschalthysterese und damit sinnlose Verdichterstarts. Als besonderes Gimmick wird dadurch der Hausakku gerne ungeplanter Weise genüsslich geleert, wodurch alle Prognosen durcheinander geraten.

Daher:

Sollte ich es nicht schaffen, die unnötigen Abtauvorgänge zu vermeiden, so gewinne ich immerhin ein wenig Zeit wodurch sich das Heizungsintegral nicht so stark aufstaut und damit die VL-Erhöhung geringer ausfällt.

Es entfällt ja die Dauer der Pufferaufheizung.

In beiden Fällen lässt sich so vermeiden, dass der Verdampfer auf <-20 °C (natürlich nur bei entsprechenden Außenbedingungen) abgekühlt wird, dass Druckverhältnis so massiv verschlechtert wird und die Abtauenergie statt bei einem COP von 1,X eher bei 3,5 liegt (Heizbetrieb).

Jedoch muss ich rechnerisch für die Dauer des eigentlichen Abtauprozessen (ca. 4 min) eine Leistung von 15 kW aus dem Heizkreis bereitstellen können, ohne dass mir der Rücklauf zur Außeneinheit unter 20°C fällt. Sonst bricht der Abtauprozess ab oder der Heizstab springt an und heizt erst mal das Haus.

So; das war lang genug;) Außer es sind noch Fragen offen, dann gerne.

Grüße
Jwolke

Edit:

Eventuell kommt auch noch eine Antwort von Viessmann in einem gesonderten Thread? (https://www.viessmann-community.com/t5/Waermepumpe-Hybridsysteme/unnoetiges-Abtauen-Vitocal-250-A/m-...)

[Awot252]

Endlich mal ein User, der genau das gleiche Problem hat. Unnötige Abtauvorgänge bei eisfreiem Verdampfer.

Fällt das sonst niemand auf, das gibts doch nicht.

https://www.viessmann-community.com/t5/Waermepumpe-Hybridsysteme/Vitocal-252-A-Infos-zum-Abtauvorgan...

[HerrP]

@JWolke  ich hab wirklich keinerlei Ahnung, ob dir dass irgendwas hilft, aber weil ich "Puffer umschalten" im Kopf hatte und grad drüber gestolpert bin, schnell das hier:

3070 BufferTargetOperationMode (heizen/kühlen)
3106 BufferMinimumMaximumSetTemperature

beides schreibbar...

[JWolke]

Danke für die Info, jedoch glaube ich, dass die beiden Werte den "klassischen" Puffer beschreiben. Der Grundgedanke meinerseits war, sobald ich während der Inbetriebnahme der Pumpe mitteile, dass ich einen Puffer/hydraulische Weiche habe, dass dann die auch zur Enteisung genutzt wird.

Jedoch war dies ein Trugschluss.

Der 3070 beschreibt nur die Verwendung eines externen Temperatursensors und die 3106 die Spanne, von wann bis wann die Pumpe heizen/kühlen soll um den Puffer zu laden. Könnte mir vorstellen, dass die Maximaltemperatur auf 95°C (Materialgrenze) und Minimaltemperatur auf 15°C (Kondenswasservermeidung) standardmäßig eingestellt ist.

Werde aber erst zum Wochenende hin mich dahinter klemmen können

Grüße

JWolke

[Bu-Na]

Hallo JWolke,

sehr interessante Anmerkungen, kann das Problem aus eigenen Beobachtungen heraus nur bestätigen.

Stammen die Einblicke aus dem Viessmann-Dokument "Systemkonfiguration und Diagnose für Wärmepumpen mit Viessmann One Base", oder gibt es noch andere Quellen?

Sollte man hier wirklich via Open3E eingreifen können wäre das eine wirklich coole Sache.

Gut wäre auch, die Abtauung gezielt initiieren zu können (erspart bei eingefrorener Außeneinheit viel Arbeit).

Gruß Bu_Na

[Pillow]

Hallo JWolke,

in der Serviceanleitung Fachkraft OneBase steht wie du schon meintest, dass Anlagen ohne Heizungspuffer zuerst den internen Speicher heizen zur Speicherung der Abtauenergie. Zusätzlich steht dort noch, dass falls der interne Puffer nicht zur Abtauung reichen sollte, mit dem Wasser aus dem Heizkreis nachgeholfen wird.

Eventuell könnte man als Workaround den Wert 2256 : O3EInt16(2, "DesiredThermalEnergyDefrost") verringern. Dadurch würde der Puffer nur kurz aufgeheizt, eventuell sogar garnicht. Dann wird hoffentlich direkt aus dem Heizkreis "nachgeholfen". Bei Fußbodenheizung könnte man so eventuell die Energie aus dem Estrich ziehen, welche mit besserem COP erzeugt wurde.

Es müsste sich nur jemand trauen, das zu verstellen.

Viele Grüße
Philip

[HerrP]

Worin siehst du die 'Herausforderung' den Wert zu schreiben? Lässt er sich denn einfach schreiben?

Wir sind ja auf ein paar Datenpunkte gestossen, die sich so ohne Weiteres erstmal dagegen wehren, geschrieben zu werden (bsw. die Ruhestellung des Umschaltventils bei Gasthermen, wo mir der Sinn eines 'Schreibschutzes' wirklich nicht einleuchten will). Aber in diesen Fällen sagt dir der Datenpunkt das, in dem er '0x22 - Conditions not correct' auf einen Schreibversuch hin zurückgibt, weiter passiert nix. Wir arbeiten noch dran, diese Datenpunkte auch geschrieben zu bekommen...

Wenn er sich schreiben lässt, sollte er sich auch jederzeit wieder auf den ursprünglichen Wert zurückschreiben lassen.

[JWolke]

Genau das ist Plan;)

Der Wert steht anscheinend Fix auf 2050. Dazu nehme ich an, dass damit kJ gemeint sein könnten. (4,19*28*18=2112 kJ würde zumindest in die Richtung gehen)

Mein Problem ist jedoch, dass ich nicht genau weiß, wie ich den Wert eingebe. Mein erster Versuch die Dämpfung einzustellen brachte mir statt der gewünschten 2 den lustigen Wert 65310 beim wieder auslesen. Nur durch das Beispiel im Wiki, worin zufällig der Wert 3 angeführt war, konnte ich diesen wieder in eine vernüftige Dimension bringen. (-raw Format ist so gar nicht meine Stärke).

Daher ist erst fürs Wochenende geplant, dazu etwas einzustellen. Auch da ich gerne in der Nähe bleiben möchte, selbst wenn der Wert bspw. auf 1000 zu ändern gewesen ist, ob die Beschreibung "dass falls der interne Puffer nicht zur Abtauung reichen sollte, mit dem Wasser aus dem Heizkreis nachgeholfen wird" auch tatsächlich funktioniert - zur Not werde ich es dann erstmal wieder erhöhen müssen. Ebenfalls wird es notwendig sein zu prüfen, ob die 15 kW tatsächlich aus dem heizkreis bereitgestellt werden können, ohne dass mir der Rücklauf bzw. dann ja Vorlauf zur ODU unter die magische 20°C-Grenze rutscht

[JWolke]

Hallo Bu-Na,

genau daher stammen sie (https://static.viessmann.com/resources/product_media/6199883VSA00004_1.PDF).

Grüße

JWolke

[JWolke]

Zugleich wird auf Seite 17 des verlinkten Dokuments noch der Hinweis gegeben: "Hinweis
Bei Anlagen mit externem Heiz-/Kühlwasser-Pufferspeicher wird die Wärmeenergie aus dem externen
Pufferspeicher verwendet."

Und genau das müsste man ja freigeben können. Der Pumpe während der Inbetriebnahme zu sagen es ist ein Heizungspuffer vorhanden reicht dazu leider nicht aus - wäre wohl zu simpel?

[Pillow]

Soweit ich das verstehe, müsste der Anlage zu sagen, es ist ein Heizungspuffer verbaut, Auswirkungen auf die Regelstrategie haben. Anlagen mit Puffer für die Heizung regeln unter Messung der Puffertemperatur. Dieser Sensor fehlt dann ja bei Anlagen ohne Puffer?

Dieser Umweg ist also leider nicht möglich denke ich. Mal sehen, ob wir die Umrechnung für 2256 hinbekommen.

[JWolke]

So verstehe ich es auch. Während der IBN ist auszuwählen, ob ein Puffer/hydraulische Weiche vorhanden ist und ob dieser für Heizen, kühlen oder beides genutzt wird. Wird darin "Ja" angegeben wird ein externer Temperaturfühler an der Klemmleiste 5 (?) erwartet. Ist dieser nicht vorhanden, geht die Anlage auf Störung. Allerdings scheint dieser nur Auswirkungen auf die VL-Temperaturregelung zu haben. Pumpeneinstellungenbetriebsparameter, Pumpen Nach- und Vorlaufzeiten, Abtauprozesse scheinen davon nicht betroffen zu sein.

Ebenfalls wäre es möglich, dass der Wert unter 2256 tatsächlich bei jedem Abtauvorgang neu geschrieben wird. ("Bevor der Abtauvorgang starten kann, wird die erforderliche Abtauenergie von der Wärmepumpenregelung anhand der Betriebsdaten und des hierfür nutzbaren Heizwasservolumens ermittelt.")

Demnach müsste man auch das Heizwasservolumen anpassen können, sollte die Änderung des 2256 nicht ausreichen.