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

[har1]

Dreman Guru , 10hans Profi III ,

ich bekomme den Frostschutz nicht abgeschaltet.

Meine Parameter

HK1   2855     -9     01a6ff

HK2   2856     -9    01a6ff

HK1     2426         000a00000a00     auch bei   010a00000a00

HK2     2427         000a00000a00    auch bei   010a00000a00

Ich denke es muss noch einen relevanten Parameter geben.

Oder mache ich was falsch ?

Für mich ist das nicht so wichtig , ich habe das Problem Hardwaremäßig gelöst.

Ich wollte nur mal eine Rückmeldung geben.

Vielen Dank an alle , ihr macht eine sehr gute Arbeit !!!

[Dreman]

Der 'noch relevante Parameter' könnte 2426/2427 sein (ohne Gewähr 😉). Also zusätzlich zu 2855:

HK1  2426   01a6ff000a00 (für witterungsgeführten Betrieb ohne Raumtemperatur-Aufschaltung)

HK2  2427   01a6ff000a00 (für witterungsgeführten Betrieb ohne Raumtemperatur-Aufschaltung)

[Wwi]

Vielen Dank an @HerrP für dieses geniale Projekt.

Da ich bisher in diesem Beitrag noch nichts dazu gefunden habe, möchte ich von Euch gerne wissen, ob Ihr bei Euren Systemen auch schon unterschiedliche Antwortzeiten der ECU's beobachtet habt. Insbesondere die HPMU (0x680) benötigt extrem lange um zu antworten.

System: Vitocal 200s E.06 mit Softwarestand 2223, Rasperry Pi Zero W

@raspberrypi:~/open3e $ time python3 Open3Eclient.py -cnfg dev -r 0x680.[269,271,274],0x68c.[320,324],0x6cf.[268,1043] -v --raw

[udsoncan:read_data_by_identifier] total time: 2.3658292293548584

0x680 269 ReturnTemperatureSensor "19018400a302110100"

[udsoncan:read_data_by_identifier] total time: 2.391155958175659

0x680 271 DomesticHotWaterSensor "fd0142016302fd0100"

[udsoncan:read_data_by_identifier] total time: 2.4855570793151855

0x680 274 OutsideTemperatureSensor "20000000ffff1f0000"

[udsoncan:read_data_by_identifier] total time: 0.3289310932159424

0x68c 320 PrimaryHeatExchangerLiquidTemperatureSensor "06003efe1a04060000"

[udsoncan:read_data_by_identifier] total time: 0.38820672035217285

0x68c 324 CompressorOutletTemperatureSensor "54023efedc05540200"

[udsoncan:read_data_by_identifier] total time: 0.1858823299407959

0x6cf 268 FlowTemperatureSensor "260100000000000000"

[udsoncan:read_data_by_identifier] total time: 0.23324298858642578

0x6cf 1043 AllengraSensor "ee3e2a0100"

closing 0x680 - bye!

closing 0x684 - bye!

closing 0x68c - bye!

closing 0x6cf - bye!

real 0m13.000s

user 0m11.842s

sys 0m0.479s

@raspberrypi:/# ip -details -statistic link show can0

2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10

    link/can  promiscuity 0 minmtu 0 maxmtu 0 

    can state ERROR-ACTIVE restart-ms 0 

 bitrate 250000 sample-point 0.875 

 tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1

 gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1

 clock 48000000 

 re-started bus-errors arbit-lost error-warn error-pass bus-off

 0          0          0          0          0          0         numtxqueues 1 gso_max_size 65536 gso_max_segs 65535 

    RX: bytes  packets  errors  dropped missed  mcast   

    236877     68318    0       2014    0       0       

    TX: bytes  packets  errors  dropped carrier collsns 

    2496       312      0       0       0       0   

Beste Grüße 

Jens 

[Juergen-B]

@WwiHallo Jens, freut mich, wenn Dir das Projekt gefällt.

Mir ist nicht ganz klar, wie Du die Zahlenwerte ermittelt hast und was da alles drin steckt, außer der reinen Antwortzeit der ECU über den CAN Bus. Wenn Du nur diese Antwortzeit ermitteln willst, schaust Du am besten auf das, was auf dem Bus passiert. Evtl. musst Du zunächst die can-utils installieren, also

$ sudo apt install can-utils

Dann startest Du auf einem Terminal einen CAN Dump für die Adressen 0x680 und 0x690:

$ candump -tA can0 | grep " 6[89]0 "

Auf einem 2ten Terminal machst Du nun eine Abfrage mit open3e. Hier ein Beispiel-Dump für die did 0x680.269:

(2024-01-29 19:48:25.999890) can0 680 [8] 03 22 01 0D 00 00 00 00
(2024-01-29 19:48:26.000203) can0 690 [8] 10 0C 62 01 0D 80 01 D1
(2024-01-29 19:48:26.001155) can0 680 [8] 30 00 0A 00 00 00 00 00
(2024-01-29 19:48:26.011517) can0 690 [8] 21 00 58 02 71 01 00 55

Jetzt siehst Du an den Zeitstempeln genau, wie lange die Antwort der ECU dauert.

Ich habe ja einen Adapter für ioBroker geschrieben, der die Funktionalität von open3e direkt in ioBroker integriert, siehe z.B. hier. Da messe ich diese Antwortzeit bei jeder Abfrage. Typische Werte von "Start der Abfrage auf dem Bus" bis "Antwort vollständig erhalten" liegen da im Bereich 10 bis 50 ms. Auch bei der HPMU. Das hängt vor allem von der Daten-Länge der Anwort ab.

[HerrP]

Zu bedenken ist bei längeren Daten auch die Separation Time im Flow Control Frame. Die ist für die 'over all' Antwortzeit ggf. bestimmender als die eigentliche Antwortzeit der ECU. Ich weiss aktuell garnicht, wie die bei unserer neuen python-isotp Implementierung überhaupt gesetzt ist.

[Wwi]

Guten Morgen Juergen,

die Zeiten werden mittels time() vor und nach dem Aufruf der Methode read_data_by_identifier der Klasse udsonscan.client in der Klasse O3Eclass ermittelt:

start_time = time.time()
response = self.uds_client.read_data_by_identifier([did])
# return value and idstr
end_time = time.time()
print(f"[udsoncan:read_data_by_identifier] total time: {end_time-start_time}")

 Die Idee mit candump war auch gut, da kann man gut sehen, dass die Zeiten auf dem Bus bei ca. 30ms liegen: 

@raspberrypi:~ $ candump -tA can0 | grep " 6[89CD][0F] "
(2024-01-30 07:46:16.433214) can0 680 [8] 03 22 01 0C 00 00 00 00
(2024-01-30 07:46:16.435172) can0 690 [8] 10 0C 62 01 0C 2C 01 85
(2024-01-30 07:46:16.452517) can0 680 [8] 30 00 0A 00 00 00 00 00
(2024-01-30 07:46:16.465353) can0 690 [8] 21 00 D5 02 1E 01 00 55
(2024-01-30 07:46:17.669447) can0 6CF [8] 03 22 01 0C 00 00 00 00
(2024-01-30 07:46:17.672819) can0 6DF [8] 10 0C 62 01 0C 2C 01 00
(2024-01-30 07:46:17.687733) can0 6CF [8] 30 00 0A 00 00 00 00 00
(2024-01-30 07:46:17.700151) can0 6DF [8] 21 00 00 00 00 00 00 55

und das obwohl die User-Zeiten bei 2,3s bzw. 0,2s für den Methodenaufruf liegen:

@raspberrypi:~/open3e $ time python3 Open3Eclient.py -cnfg dev -r 0x680.[268],0x6cf.[268] -v --raw

[udsoncan:read_data_by_identifier] total time: 2.308736801147461

0x680 268 FlowTemperatureSensor "2c018500d5021e0100"

[udsoncan:read_data_by_identifier] total time: 0.1911451816558838

0x6cf 268 FlowTemperatureSensor "2c0100000000000000"

closing 0x680 - bye!

closing 0x684 - bye!

closing 0x68c - bye!

closing 0x6cf - bye!

real 0m7.313s

user 0m6.736s

sys 0m0.262s

und somit die "Ursache" aus meiner Sicht nicht im CAN-Bus, sondern in den Bibliotheken udsoncan und isotop zu suchen ist, oder?

Beste Grüße 

Jens 

[Wwi]

Guten Morgen @HerrP ,

naja DID 268 ist ja nicht "lang" ... zum Vergleich habe ich ECU x680 und x6cf mit der gleichen DID auf dem develop-Branch abgefragt:

~/devBranch/open3e $ time python3 Open3Eclient.py -cnfg dev -r 0x680.[268],0x6cf.[268],0x680.[268],0x6cf.[268] -v 

[udsoncan:read_data_by_identifier] total time: 2.466827392578125

0x680 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 13.3, "Maximum": 72.5, "Average": 28.6, "Unknown": 0}

[udsoncan:read_data_by_identifier] total time: 0.2308192253112793

0x6cf 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 0.0, "Maximum": 0.0, "Average": 0.0, "Unknown": 0}

[udsoncan:read_data_by_identifier] total time: 2.3276524543762207

0x680 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 13.3, "Maximum": 72.5, "Average": 28.6, "Unknown": 0}

[udsoncan:read_data_by_identifier] total time: 0.20518827438354492

0x6cf 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 0.0, "Maximum": 0.0, "Average": 0.0, "Unknown": 0}

closing 0x680 - bye!

closing 0x684 - bye!

closing 0x68c - bye!

closing 0x6cf - bye!

real 0m9.959s

user 0m8.915s

sys 0m0.389s

Wieso jetzt x680 gegenüber x6cf zehnmal langsamer ist, obwohl die Datenstruktur dieselbe sein sollte … ist "interessant".

[Juergen-B]

@Wwi Ich habe die Messung eingebaut und ein wenig mit den Abfragen rumgespielt. Ich sehe die gleichen Effekte, wenn ich die Abfrage genau nach Deinem Beispiel mache.

Wenn ich das -cnfg dev weglasse, sind die Zeiten immer so groß wie bei 0x680. Ich vermute deshalb, dass es an der Auswertung der Datenpunktlisten liegt, die bei diesem Vorgang stattfindet. 0x680 hat eine sehr lange Liste, bei 0x6cf ist sie sehr kurz.

@HerrPIst das aus Deiner Sicht plausibel?

Ich habe es mit einem Pi 4 getestet, da ist die längste Zeit etwa 0,2 Sekunden. Ein Pi Zero ist halt kein Rennpferd.

[Wwi]

@Juergen-B du hast die Antwort gefunden. Es ist abhängig von der Länge der Datenpunktliste. Ich habe einfach mal die Liste von x680 auf 4 Einträge reduziert und komme damit auf eine Zeit von 100ms. Damit gilt es jetzt aus meiner Sicht zu prüfen, ob ein Dictionary oder ein Array für die Datenpunktliste in udsoncan verwendet wird, und wieso ein eventueller Zugriff auf den Key nicht innerhalb von O(1) durchgeführt werden kann. Ansonsten könnte man natürlich nur die relevanten Datenpunkte innerhalb des Konstruktors von Open3Eclass als Config-Liste übergeben, z. B. in dem man die Schnittmenge aus den existierenden und den angefragten DID's erstellt. Schaue ich mir heute Abend mal an.

Update: Ursache ist ein deepcopy der Datenpunktliste in der Funktion def check_did_config (python-udsoncan/udsoncan/common/dids.py) Zeile 179, welcher bei jedem make_request und interpret_response durchgeführt wird … da braucht man sich dann auch nicht mehr wundern und der arme kleine Pi Zero kommt für eine triviale Operation an seine Grenzen

[TSG]

@tec Hallo, sieht echt super aus. Sieht nach Grafana aus!

Möchtest du dein Dashboard mit der community teilen?

Wäre ggf. auch ein Beitrag im Wiki wert. Man könnte hierfür eine eigene Seite Anlegen...

Gruß Benedikt

[HerrP]

Moin ihr!

Dass das Einlesen und Verarbeiten ('overlay') der Liste Zeit kostet klingt sehr plausibel. Ich wette aber, dass diese Zeit verglichen mit der Zeit, die Kommandozeile einzugeben, nahezu gegen Null geht 😁

Im automatisierten Zusammenhang (sowohl zyklisches Auslesen als auch der MQTT Listener Mode) wird ja die Datenpunktliste nur ein mal eingelesen und verarbeitet ('Overlay' pro ECU). Die folgende 'Auswertung' des Codecs im Rahmen des udsoncan Read/WriteDataByIdentifier fällt mit Mikrosekunden in's Gewicht und lässt sich in diesem Zusammenhang auch nicht vermeiden/abkürzen.

beste Grüsse!

Phil

[HerrP]

ps. MOOOMENT....

ich sehe gerade, dass die Versuche ja wirklich mit einem Aufruf gemacht werden, also die Listen auch nur ein mal eingelesen und verarbeitet werden.

Ich muss mir das mal angucken. @Juergen-B  du bist da wahrscheinlich auch bei oder hast das schon. vlt telefonieren wir dazu noch mal...

[Stoker]

Hallo ihr lieben!
Kein klasse Projekt habt ihr da, großes Lof ab alle die sich an so etwas beteiligen.

Vielleicht hat jemand einen Hinweis für mich. Ich betreibe einen Server mit Unraid. Darauf läuft Home Assistant als VM. Mein Server steht direkt im Nebenraum. Ich habe hier zwar auch noch zwei Raspis liegen, aber ich denke für mich würde es mehr Sinn ergeben open3e direkt auf meinem Server zu betreiben. Hat schon jemand von euch versucht das Ganze in einem Docker Container zu betreiben oder sogar direkt im Home Assistant?

[HerrP]

@Wwi @Juergen-B  das Problem liegt in der Architektur von udsoncan:

config['data_identifiers'] = self.dataIdentifiers
...
self.uds_client = Client(conn, config=config)

dementsprechend wäre das ein interessanter Aspekt, mit dem wir Pier Yves konfrontieren sollten/könnten.

@Wwi  die dataidentifiers sind ein Dictionary, der Zugriff erfolgt ja per Key DID. Ein Array an sich wäre vielleicht schneller, aber man müsste das ja dann 'von Hand' durchsuchen um den passenden Eintrag zu finden - das wäre glaubich noch langwieriger?

ps./edit: grade erst gesehen - sorry

"Update: Ursache ist ein deepcopy der Datenpunktliste in der Funktion def check_did_config (python-udsoncan/udsoncan/common/dids.py) Zeile 179, welcher bei jedem make_request und interpret_response durchgeführt wird … da braucht man sich dann auch nicht mehr wundern und der arme kleine Pi Zero kommt für eine triviale Operation an seine Grenzen"

dann können wir Pier Yves ja gleich den Lösungsansatz an die Hand geben 😉 danke!! @Wwi 

[HerrP]

Moin @Stoker !

danke für's Lob! und danke für dein Interesse 🙂

Docker Container ist keine gute Idee, weil dann das CAN Interface nur in einer einzigen 'Instanz' zur Verfügung steht. Das haben schon Leute ausprobiert, es aber ziemlich zügig wieder verworfen.

Direkt in Home Assistant weiss ich nicht, kann ich nix zu sagen, weil ich überhaupt keine Ahnung habe, wie man einen Python Task/Thread in Home Assistant betreibt.

Auf deinem Server sollte kein Problem sein - einfach eine Linux VM und open3e mit Abhängigkeiten da drin und abdafür. Die MQTT Geschichte läuft ja über TCP/IP. Es gibt mehrere Leute, die open3e schon so betreiben. Es gibt da ein paar Sächelchen zu beachten (die ich grad nicht erinnere), aber das bekommen wir ruck-zuck gelöst, falls du da drüber 'stolpern' solltest.

Grüsse!

Phil 

[Stoker]

Danke für die Infos @HerrP 

Ich denke, dann werde ich sobald ich mal Langeweile habe doch eher einen meiner Raspis nutzen. Für so eine Anwendung will ich nicht wieder Ram und CPU Kerne zuweisen da das bei Unraid meiner Erfahrung nach nicht gut dynamisch funktioniert und dauerhaft Ressourcen bindet.

[galegro]

Seit fünf Tagen bin ich mein WAGO-Gateway (endlich) wieder los. Wie vereinbart hat mein Heizungsbauer es zurückgenommen.

Nun geht‘s noch diese Woche an die Umsetzung eures Projektes. Da der von mir erworbene USB2CAN-Konverter mein produktives System total durcheinander bringt, habe ich mir eigens ein Testsystem vorbereitet, auf dem ich Jürgens ioBroker-Adapter verwenden will.

Vielen Dank für euer großartiges Projekt.👍 

[HerrP]

@Stoker  ja, die VMs... So schön sie sind gilt auch für sie "kein Vorteil ohne Nachteil" 😁 Schade bei einem Raspi sind immer die 5 Watt 24/365... -> 40..45kWh - das is schon ne Woche Warmwasser 😉

Du hast nich zufällig schon eine Linux VM am laufen auf dem Server? der könntest du open3e dann ja noch 'mit unterschieben' - braucht ja nicht viel...

[galegro]

Und hier meine ersten Erfahrungen mit openE3 und ioBroker Adapter ..

Mein Fazit : Es funktioniert auf Anhieb! Wer ioBroker verwendet und eine E3 Anlage besitzt, sollte sich unbedingt das Ganze einmal anschauen. Einen USB2CAN-Konverter (ca. 35€) anschließen, Adapter installieren und schon kann man sich über unzählige Datenpunkte freuen, wobei auf viele nützliche bereits sogar schreibend zugegriffen werden kann.

Es ist äußerst beeindruckend, was Jürgen da auf die Beine gestellt hat. Die Nutzung des openE3 Projektes im ioBroker wird durch seinen Adapter enorm vereinfacht. Weder wird nunmehr MQTT benötigt noch muss eine spezielle Python Software installiert werden; die Datenpunkte (aufwendige JSON-Objekte) werden bis auf skalare Werte herunter gebrochen und stehen somit sowohl als komplexe (JSON)Objekte als auch einzelne (skalare) Werte zur Verfügung. Einfach großartig!👍👏

[FrankSteiner]

Moin moin,

bevor ich versuche, mich in die ganze Thematik dieses mehr als beeindruckenden Projekts einzuarbeiten, wollte ich sicherheitshalber mal fragen, ob mein Anliegen ueberhaupt funktionieren wuerde: Es gibt nur eine Funktion, die ich  braeuchte, und zwar wuerde ich von meiner witterungsgefuehrten Vitodens 300 W (Einbau 2023) gerne entweder die Temperatur des Aussenfuehlers oder die Soll-Vorlauftemperatur auslesen. Und in Abhaengigkeit von den Werten (z.B. Aussentemperatur hoeher oder niedriger als 10°) den Parameter "1503.0 Minimale Heizleistung" veraendern, Konkret bei AT > 10 Grad den Parameter 1503 auf 13% setzen, bei ≤10 Grad auf 5%.

Sind diese Funktionen (AT oder Soll-Vorlauf lesen, Parameter 1503.0 schreiben) bei der Vitodens 300 W moeglich?

Vielen Dank!

cu,

Frank

[Dreman]

Aussentemperatur (Parameter 274) und Soll-Vorlauftemperatur (Parameter 987) können ausgelesen werden und der Parameter 1503 (Minimale Heizleistung) kann beschrieben werden. Da jedoch bei der Vitodens die minimale Wärmeleistung laut Datenblatt nicht kleiner als 1,9 kW sein kann, ist es durchaus möglich, dass Prozent-Werte, die einen Wert < 1,9 kW ergeben, nicht akzeptiert werden bzw. akzeptiert werden, aber keine praktische Auswirkung haben. Was bezweckst du denn mit dieser 'Regelung'?

[FrankSteiner]

Super, dass das geht, vielen Dank! Das Problem bei uns ist ein nachträglich gedämmtes Haus mit großen Heizkörperflächen. Bei AT über 10 Grad sinkt die Soll-Vorlauftemperatur unter 29 Grad, und dann geben die Heizkörper keine Wärme mehr ab. Hat mir auch mal jemand hier im Forum erklärt, wieso das mit der Konvektion und klassischen Heizkörpern ab ≤29 Grad nicht mehr klappt. Tatsächlich kühlen die Zimmer in so einer Situation auch immer weiter aus, obwohl der Kessel durchläuft.

Also stelle ich bei AT von ≥ 10 Grad von 5% (10% Modulation = 1.9kw) auf 13% um (entspricht dann 26% Modulation), dann werden immer mind. 30 Grad Vorlauf erreicht und aufgrund der Integralsteuerung werden die Heizintervalle verkürzt. D.h. statt dauerhaft mit 10% Modulation läuft der Kessel mit 26% z.B. eine Stunde durch und schaltet dann für eine Stunde ab. Ich erzwinge also Taktungen, was ja eigentlich nicht gut ist, aber mit dem Wechsel "1 Stunde mind. 30 Grad Vorlauf, 1 Stunde Pause" wird die Temperatur in den Räumen gehalten, mit "dauerhaft 29 Grad Vorlauf oder weniger" kühlen sie aus. Würde ich alternativ die Raumtemperatur anheben, bis der Soll-Vorlauf bei 30 Grad liegt, dann würde es insgesamt zu warm.

Natürlich wechsele ich diese Einstellung nicht jeden Tag, sondern schalte auf 13% wenn es mehrere Tage über 10 Grad werden soll. Bei manchen Wetterlagen kann es aber sein, dass man es alle 2-3 Tage ändern müsste, um nicht unnötig die 13% laufen zu haben an Tagen, wo es gar nicht nötig ist. Daher wäre ein automatischer Wechsel je nach Außentemperatur extrem praktisch (natürlich mit flip-flop-Schutz, d.h. ich würde z.B. bei 10 Grad umschalten, aber erst ab unter 8 wieder zurück).

[HerrP]

moin Frank!

>> Hat mir auch mal jemand hier im Forum erklärt, wieso das mit der Konvektion und klassischen Heizkörpern ab ≤29 Grad nicht mehr klappt.

Kannst du da bitte mal den Link posten?! Also wenn der Brenner brennt, müssen die Heizkörper auch Wärme abgeben - irgendwie muss die Energie ja auch wieder 'weg' kommen. Dazu braucht es nicht zwangsweise Konvektion.

Es gibt übrigens auch noch den hier:

1084 : RawCodec(4, "FlowTemperatureMinimumMaximumLimit") [wieso ist der eigentlich immer noch RawCodec?]

Aber ich weiss nicht, ob du damit hinbekommst, was du willst. Wahrscheinlich haut dann der 'Intervallbetrieb' nicht hin.

>> Das Problem bei uns ist ein nachträglich gedämmtes Haus mit großen Heizkörperflächen.

So ein 'Problem' würde sich mancheiner glaubich wünschen... 😁

Grüsse!

Phil

[Dreman]

@FrankSteiner  Also stelle ich bei AT von ≥ 10 Grad von 5% (10% Modulation = 1.9kw) auf 13% um (entspricht dann 26% Modulation).....

Bei meiner 19 kW 300-W-B3HG entspricht eine Heizleistung von 1,9 kW (10%) auch einer Modulation von 10% und eine Heizleistung von 13% (etwa 2,5 kW) entspricht einer Modulation von 13%. Aktuell liegt die Heizleistung z.B. bei 4 kW (21%) und als Modulationswert wird mir 21,4% angezeigt. Der Parameter 1503 (Minimale Heizleistung) steht zwar auf 5% (Werkseinstellung), die minimale Heizleistung geht trotzdem nie unter 1,9 kW, d.h. Werte unter 10% im Parameter 1503 werden nach meinem Verständnis ignoriert.

[galegro]

Da schließe ich mich doch gleich mal an.🙂

Ich habe Jürgens ioBroker Adapter installiert und möchte unsere Visualisierung um unsere Hybridheizung (Vitodens 300 + Vitocal 252) erweitern. Hierzu quäle ich mich derzeit mehr schlecht als recht durch die Fülle der Datenpunkte.

Meine Frage ..

Unsere Vitodens 300 hat (doch) gar keinen CAN-Bus. Kann ich sie dennoch über Datenpunkte aus dem ioBroker Adapter steuern? Welche sind ggf. hierzu vergügbar?