Viessmann Heizungssteuerung mit vcontrold

[kvo1]

klar ist das nur die 2. beste Lösung , aber was genialeres fällt mir bisher auch nicht ein , zumal ich immer noch mit dem
Optolink-Adapter und RPi kämpfe  ......unter Windows läuft das Teil sofort .......

[salvadore]

die "genauere Lösung" hat man dann, wenn man über den Optolink die Brennerstunden, bei mir Stufe 1 + Stufe 2, ausliest und mit dem Verbrauch/h (steht bei mir in der Beschreibung zum Brenner) berechnet.
Gruß
salvadore

[Raven]

Danke. Sehr guter Hinweis.

Mit ein paar Umrechnungen i.V.m. der Anzahl der Brennerstarts pro Stunde (oder alternativ Zunahme der Brennerstunden) kann ich die Taktung ermitteln.
Hintergrund meines Anliegens: Ich hatte vor einigen Wochen gelesen, daß die Taktung Aufschluß geben kann, ob die eingesetzte Brennerdüse im Hinblick auf ihre Größe optimal ist. Ich bin erst seit einigen Wochen Besitzer eines Öl-Brenners, daher sind alle Infos über Optimierungspotentiale willkommen. (Morgen quetsche ich diesbzgl. die Wartungsfirma aus.)

[PeMue]

Hallo Raven,

was verstehst Du unter Taktung? Wie oft der Brenner an bzw. aus ist? Dann sind die Brennerstarts vermutlich der richtige Parameter. Meines Wissens kann man aber über die Regelung (den genauen Parameter habe ich leider nicht parat) auch Einfluss auf die Taktung (der Brenner läuft dann halt länger und die Temperatur wird dann höher) nehmen. Ich bin aber durchaus an der Aussage interessiert, ob die Düse passt bzw. wie man dies ermitteln kann. Wäre toll, wenn Du das posten könntest ...

Gruß PeMue

[Raven]

Hallo PeMue

Genau, in welchen zeitlichen Abständen der Brenner heizt bzw. ruht.

Ich muss nochmals googlen...da hatte jemand sehr umfassende Erfahrungsberichte veröffentlicht.
Klar, lassen sich seine Ergebnisse nicht 1:1 auf andere Anlage übertragen, aber ich bin grundsätzlich an weiteren Eckdaten interessiert.
Gerne, sobald ich verwertbare Infos habe, werde ich berichten.

[Joachim]

http://www.bosy-online.de/Kuhschwanzheizung.htm

Die ganze Seite ist interessant

Gruß Joachim

[salvadore]

ich bin nicht der große Heizungsguru aber hängt das nicht auch davon ab, welche Temperaturen der Aussenfühler übermittelt, wie oft der Brenner anspringt und welche Actuatorstellungen vorhanden sind?
Ich habe mal einen Screenausschnitt  von heute angefügt. Die Diff zwischen Vorlauf - Rücklauf liegt bei ca. 10° und ist  lt. Monteur o.K.
Im Betrieb ist ein sog. 2 Stufen Blaubrenner im Ölbrennwertkessel von Viessmann Vitoladens 300C. Als Düse wird verwendet Danfoss, Typ Gph 80°H LE V, die mit einem Ölduchsatz von 1,53 kg/h bei Stufe 1 und 1,92 kg/h bei Stufe 2 angegeben ist.
Tip: bei der letzten Wartung wurde eine Düse mit fast gleicher Bezeichnung 80°H LE verwendet, die aber wohl für Geräte mit einer Nennwärmeleistung von 19,3/28,9 gebraucht wird; und prompt kam es zu Störungen.
(//)

[Joachim]

Moin Salvatore,
ich bin auch kein Heizungsguru, aber ich weiß wo ich mich schlau lesen kann, und Bosy online ist eine sehr gute Adresse in diesem Zusammenhang.
Wie oft der Brenner anspringt, bzw. wie stark er taktet hängt von diversen Sachen ab, nicht nur von der Außentemperatur.
Sondern auch,
ob der Brenner modulierend arbeitet
ob die Heizung richtig dimensioniert ist
größe des Pufferspeichers uvm.
Hier noch einmal ein anderer Link
http://www.haustechnikdialog.de/Suche/kuhschwanzheizung
Wenn man seine Heizungsanlage von der Steuerung her optimieren will, kann es nicht schaden, sich mit den Grundlagen zu befassen, um zu verstehen, welche Auswirkungen die einzelnen Änderungen haben.

Gruß Joachim

[salvadore]

Hi Joachim,
wirst recht haben, werde dies mal meinem Freund Heizungsmonteur "auf`s Auge drücken" und sehen, was daraus  wird. Davon ausgehend eine Ölbrennwertheizung installiert zu haben, die dem Stand der derzeitigen Technik entspricht, somit z.B. modulierend arbeiteitet + richtig dimensioniert ist, sollte es passen. Aber wie schon in anderen Foren geschrieben, ist sicher ein Unterschied zu machen, ob ich eine Anlage ersetze (-n muss) oder kpl. neu installiere (Pufferspeicher braucht auch Platz).
Jedenfalls ist es so, das wir nach Umstellung der Heizungsanlage, Einsatz von FHT`s etc.  einen reduzierten Verbrauch von ca. vorher 2.800 ltr Jahresverbrauch zu 2.100 ltr p.a. haben

Gruss
salvadore

[Adam]

Hallo zusammen,

beschäftige mich seit etwas mehr als einem Jahr mit FHEM und mein Ziel war es auch,
nachdem ich die MAX Heizthermostate angebunden habe, auszulesen was meine Heizung
(Viessmann mit Vitotronic 200 KW2) so an Werten liefert.
Und die Möglichkeit zu haben von unterwegs (aus dem Urlaub zurück) schon mal das Warm Wasser wieder anzuschmeissen 

Durch eine PM von Klaus bin ich überhaupt erst gestern auf diesen Thread gekommen
und sehe, dass ich nicht der einzige bin, der diese Heizung an FHEM anbindet.

Aber so wie ich das lese bin ich zumindest in diesem Thread der einzige,
der FHEM auf einem Windows System betreibt. Linux ist nicht so meine Welt

Ich habe dann auch vcontrold und vlcient unter cygwin auf Windows ans laufen gebracht,
und die verschiedenen Kommandos aus der xml durchprobiert.

Mein erster Ansatz war dann, das vclient als "at" in Fhem zyklisch zu starten und die gelesenen Werte,
aus der Outputdatei zu parsen und dann selber ein FHEM konformes Log zu schreiben.

Dies hatte jedoch den Nachteil, da das lesen über vclient mehr als 20 Sekunden dauert,
dass mein FHEM so lange blockiert war.
Ganz schlecht wenn man noch auf andere Events reagieren möchte!!

Ich habe mich dann entschlossen eine neue Srache (perl) zu sprechen und habe ein eigenes Modul geschrieben.
In diesem wollte ich das Lesen mit vclient in ein Child-Prozess mit fork auslagern, damit FHEM weiter reagiert.
Das geht unter Windows mit Active Perl nicht 

Ich habe dann ein Windows konformes "fork" das sich "Win32::Process::Create" nennt gefunden und damit funktioniert es.
Hat nur den Nachteil, dass der neue Prozess nicht mehr per Perl mit dem Eltern Prozess kommunizieren kann.
(Dies ist wohl mit einem "fork" in der Linux Welt schöner und einfacher!)

Ich starte also in meinem Modul zyklisch (konfigurierbar) einen neuen Prozess zum Lesen (Ein Batch File auf Windows, dass vclient aufruft).
Ist der Prozess mit dem Lesen fertig sendet er per c:\fhem-5.3\fhem.pl port "set Heizung data-ready" einen Befehl an mein Fhem,
dass es die Daten auswerten kann. (das geht so schnell da merkt man nichts von!)

Vorteil von dem Modul ist noch, dass ich jetzt so ein FHEM konformes Device konfigurieren kann,
dass auf alle Events wie gewohnt konfiguriert werden kann.
Somit kann ich das normale FileLog und SVG-Plots von Fhem nutzen.
Oder aber auch notifys auf die Readings der Heizung Konfigurieren.
Und auch ein webcmd definieren, um die Betriebsarten einfach Umzuschalten (ABSCHALT,H+WW,WW und PARTY_ON, SPAR_ON)

Habe dann als letztes auch ein Lesen und Setzen der Timer Werte,
an welchem Tag zur welcher Zeit die Heizung WarmWasser aufbereitet
oder aber die Heizung selber läuft. (Ist aber noch in der Testphase)

Naja ich wollte meine Ergebnisse einfach mal weiter geben, bekomme auch immer wieder Unterstützung aus dem Forum.
Vielleicht kann der eine oder andere was mit in die Linux Welt übernehmen.
Die Batchfiles müssten dann sicherlich Shell Skripte werden und das "Win32::Process::Create" ein "fork".
(Dazu habe ich aber nicht das nötige Know How und Zeit,  es warten zu viel weitere Projekte  in Fhem )

Im Anhang dann mal mein Modul (ohne Gewähr auf fehlerfreiheit ), ein paar Snapshots, die cfg und die Windows batchfiles.

Also fröhliches weiter Basteln 

Adam

[kvo1]

Hallo Adam,
danke für die tollen Infos, so ähnlich habe ich mir das unter LINUX auf dem RPi vorgestellt, wenn´s denn mal
an Laufen kommt.

Gruß
Klaus (der ziemlich Frustrierte  )

[PeMue]

Hallo Klaus,

*tröst* das kriegen wir zusammen hin! Bei mir geht es ja auch ...

@Adam: Werde mir mal Dein Modul anschauen und auf Linux anpassen. Ich wollte langfristig auch weg von den Shellskripten, die gerade bei mir laufen, da die Kontrolle aus fhem heraus eher schlecht ist.

Gruß PeMue

[kvo1]

Hallo Peter,
danke für die aufbauenden Worte , ich bin immer noch wild entschlossen 
(man müßt eben nur mehr Zeit haben).

Ich setze jetzt mal einen komplette neuen RPi auf !

klaus

[Adam]

Hallo zusammen,

habe mich dann doch noch mal mit dem Auslesen der Daten beschäftigt.

In meinem weiter oben im Thread beschriebenen Modul, rufe ich ja Batch-Files auf,
die wiederum vclient aufrufen, um dann eine Zwischendatei zu erzeugen,
die von fhem eingelesen werden muss, um an die Daten zu kommen..

Das finde ich echt unschön!! 

Aber wenn man vclient nutzt, hat man ja keine andere Chance.

Ich habe mir mal den Source Code von vclient ein bisschen angeschaut und gesehen,
dass er ja eigentlich nur den Commando-String per TCP/IP an den vcontrold server sendet.

Nach ein bisschen googlen habe ich dann raus gefunden, wie das auch aus Perl
und somit direkt aus Fhem funktioniert.

Mit der angehängten Funktion vfhemclient(@) (habe ich in meine 99_Utils.pm kopiert)
kann man also jetzt direkt ohne vclient die Kommandos an vcontrold senden
und den response auswerten. 

Beispiel:

my $response= vfhemclient("getTempA");
fhem ("set AussenTemp $response");

Das Auslesen eines einzelnen Wertes dauert leider auch mit dieser Variante ca. 2 Sekunden,
aber man spart sich den Umweg mit der Datei!!!

Habe dann natürlich todesmutig versucht alle Daten die ich bisher in meinem Modul auslese,
hintereinander auszulesen. Das sind 13 Werte.
('getTempA','getTempWWist','getTempWWsoll','getTempKist','getTempKsoll','getBrennerStatus',
'getBrennerStarts','getBrennerStunden1','getOelverbrauch','getPumpeStatusZirku','getBetriebArt',
'getBetriebPartyM1','getBetriebSparM1')

Leider liest er dann nur jeden 3. Wert vernünftig aus,
da vcontrold scheinbar immer eine kleine Pause vor jedem neuen Request benötigt.
Mit einem sleep 1 vor jedem Request habe ich dann alle Werte bekommen!

Das funktioniert also leider auch nur vernünftig in FHEM wenn man es "forked",
damit FHEM nicht blockiert ist.

Also vielleicht mag es ja jemand nutzen. Ich werde auch versuchen mein Modul
ohne den vclient Umweg umzuschreiben!!

Gruß
Adam

[kvo1]

Hallo Adam,

Danke für Deine tollen Ausführungen, is ja echt cool.

Klaus