Wichtig: Profil hvac.01 (Kieback&Peter MD15-FTL-xx u. a.) geändert!

[klaus.schauer]

Das Profil hvac.01 (Kieback&Peter MD15-FTL-xx u. a.) ist vollständig überarbeitet. Ziel ist es, die Bedienung zu erleichtern, die Readings und Attribute zu vereinheitlichen sowie den Ventilaktor Micropelt iTRV besser zu integrieren.

Eine wesentliche Neuerung des Profils ist der integrierte PID-Regler. Für eine Temperaturregelung bei einem Ventilaktor ohne selfCtrl-Mode wie dem Micropelt iTRV musste bisher das Modul PID20 zusätzlich genutzt werden. Die PID-Funktion im Profil hvac.01 hat u. a. den Vorteil, dass der aktuell gesendete Temperatur-Istwert des Aktors jetzt unverzögert in die Berechnung des Stellwertes einfließt.

Der in Fhem integrierter PID-Regler kann über das Attribut pidCtrl aus- und eingeschaltet werden.

Folgende Readings entfallen bzw. werden ersetzt:
   - measured-temp >> roomTemp
   - actuatorStatus >> actuatorState
   - selfCtl >> selfCtrl
   - serviceOn >> maintenanceMode
   - tempSensor entfällt
   - state x >> state T: x SPT: x SP: x

Folgende set-Befehle entfallen bzw. werden ersetzt:
   - actuator entfällt
   - valveOpen >> valveOpens
   - valveClosed >> valveCloses
   - unattended entfällt

Das Attribut actualTemp entfällt. Die Ist-Temperatur eines Raumthermostaten kann wie bisher über das Attribut temperatureRefDev verknüpft werden.

Bereits vorhandene Fhem-Devices der Ventilaktoren sollten mit einem modify <name> A5-20-01 aktualisiert werden.

Ggf. müssen Konfigurationen insbesondere im Zusammenspiel mit anderen Devices wie einem Raumthermostat angepasst werden. Falls das Modul PID20 verwendet wurde, sollte es durch die im Profil vorhandene PID-Funktion ersetzt werden. Das Attribut event-on-change-reading .* sollte nicht genutzt werden, da der PID-Regler auf regelmäßige Events des Temperaturgebers prüft und beim Ausbleiben einen Alarm generiert!

[fallenguru]

Erstmal danke für's Aktuell-halten und ständige Verbessern der der EnOcean-Unterstützung!

Ein paar Fragen/Kommentare zu dieser Änderung:
* Gibt es eine "schönere" Möglichkeit, die alten readings loszuwerden, als sie händisch aus fhem.save zu löschen? Oder ist es das, was modify <name> A5-20-01 macht?
* Die Umbenennung von measured-temp ist eher unpraktisch, was Graphen und (durchgehende) Log-Auswertung angeht. Gibt es da irgendwelche best practices, wie man mit sowas umgeht?
* Verstehe ich das richtig, dass der neue im Fhem-Gerät integrierte Software-PID-Regler im selben Zyklus auf vom MD15 gemeldete Temperatur-Änderungen regieren kann und damit dem im MD15 integrierten Regler in jeder Hinsicht überlegen ist?
* Mit pidCtrl on ist mein ARM SoC (~ RPi2, von der Geschwindigkeit her) ziemlich am Limit, zumindest, wenn ich alle 6 MD15 in der FHEMWEB-Detailansicht geöffnet habe. Mit dem alten Code war das nicht einmal auf einem RPi1 ein Problem.
* Bisher habe ich mich per notify auf currentValue in den Prozess "eingehängt" und je nach Wärmebedarf die Therme ein- bzw. ausgeschaltet. currentValue wird offensichtlich nicht mehr aktualisiert, was statt dessen nehmen? Muss kein notify sein, ein Callback tut's auch -- Hauptsache, ich bekomme eine Änderung der Ventilstellung mit.
* Apropos Ventilstellung, wieso entfällt set actuator? Das war sehr praktisch, um z. B. in der Nacht Motor- und Fließgeräusche zo vermeiden. Oder ist die Ersatz-Liste schlicht nicht vollständig und der Ventilstand ist jetzt über setpoint setz- und lesbar?

[klaus.schauer]

* Gibt es eine "schönere" Möglichkeit, die alten readings loszuwerden, als sie händisch aus fhem.save zu löschen? Oder ist es das, was modify <name> A5-20-01 macht?

deletereading ...

* Verstehe ich das richtig, dass der neue im Fhem-Gerät integrierte Software-PID-Regler im selben Zyklus auf vom MD15 gemeldete Temperatur-Änderungen regieren kann und damit dem im MD15 integrierten Regler in jeder Hinsicht überlegen ist?

nein, der integrierte PID-Regler ist im Vergleich zum zusätzlichen eingesetzten PID20-Modul hier optimaler

* Mit pidCtrl on ist mein ARM SoC (~ RPi2, von der Geschwindigkeit her) ziemlich am Limit, zumindest, wenn ich alle 6 MD15 in der FHEMWEB-Detailansicht geöffnet habe. Mit dem alten Code war das nicht einmal auf einem RPi1 ein Problem.

zusätzliche Rechenoperationen und Code machen das EnOcean-Modul leider nicht schneller. Falls der integrierte MD15 Regler ausreicht, muss man die neuen Funktionen nicht nutzen.

* Bisher habe ich mich per notify auf currentValue in den Prozess "eingehängt" und je nach Wärmebedarf die Therme ein- bzw. ausgeschaltet. currentValue wird offensichtlich nicht mehr aktualisiert, was statt dessen nehmen? Muss kein notify sein, ein Callback tut's auch -- Hauptsache, ich bekomme eine Änderung der Ventilstellung mit.

setpoint enthält die Ventilstellung

* Apropos Ventilstellung, wieso entfällt set actuator? Das war sehr praktisch, um z. B. in der Nacht Motor- und Fließgeräusche zo vermeiden. Oder ist die Ersatz-Liste schlicht nicht vollständig und der Ventilstand ist jetzt über setpoint setz- und lesbar?

ja

[fallenguru]

Das ging ja flott, danke! Jetzt hab ich die Zusatzfrage gar nicht mehr im EDIT untergebracht ...

nein, der integrierte PID-Regler ist im Vergleich zum zusätzlichen eingesetzten PID20-Modul hier optimaler

Entschuldigung, dass ich noch einmal nachhake, aber worauf genau bezieht sich das "Nein"?
Das PID20-Modul habe ich (noch) nie verwendet, mir geht es lediglich um den Vergleich pidCtrl on (Fhem regelt) und pidCtrl off (MD15 regelt). Der MD15 hat, soweit ich mich erinnern kann, keinen PID-Regler, sondern etwas Einfacheres. Nur, mit 10 min Verzögerung zwischen Regelentscheidung und Umsetzung bringt die tollste externe Regelung nichts. Theoretisch sollte Werte-empfangen -- neuen-Stellwert-berechnen -- neuen Stellwert setzen ja in einem Zyklus möglich sein, so lange sich das alles ausgeht, bevor der Aktor wieder einschläft. Das wäre eine mittlere Sensation und in meinem Optimismus hatte ich "der aktuell gesendete Temperatur-Istwert des Aktors [fließt] jetzt unverzögert in die Berechnung des Stellwertes ein" so interpretiert.   

Zusatzfrage:
* desired-temp wird nicht erwähnt, wie sieht's damit aus? Es ist noch set-bar, wird aber in der Cref nicht mehr erwähnt und der Slider in FHEMWEB wirkt sich offensichtlich nur auf setpointTemp aus.

[klaus.schauer]

Das PID20-Modul habe ich (noch) nie verwendet, mir geht es lediglich um den Vergleich pidCtrl on (Fhem regelt) und pidCtrl off (MD15 regelt). Der MD15 hat, soweit ich mich erinnern kann, keinen PID-Regler, sondern etwas Einfacheres. Nur, mit 10 min Verzögerung zwischen Regelentscheidung und Umsetzung bringt die tollste externe Regelung nichts. Theoretisch sollte Werte-empfangen -- neuen-Stellwert-berechnen -- neuen Stellwert setzen ja in einem Zyklus möglich sein, so lange sich das alles ausgeht, bevor der Aktor wieder einschläft. Das wäre eine mittlere Sensation und in meinem Optimismus hatte ich "der aktuell gesendete Temperatur-Istwert des Aktors [fließt] jetzt unverzögert in die Berechnung des Stellwertes ein" so interpretiert.

Der MD15 hat einen integrierten PD-Regler. Zu den Regeleigenschaften kann ich nichts sagen.

"Mittlere Sensation" ist sicher übertrieben, aber ist ist schon so, dass der vom MD15 gesendete Raumtemperaturwert sofort in die Berechnung einfließt und damit der neue Stellwert ermittelt und als Rückmeldung unmittelbar an den MD15 gesendet wird. Das war ja so prinzipbedingt mit dem Zusatzmodul PID20 nicht machbar. 

* desired-temp wird nicht erwähnt, wie sieht's damit aus? Es ist noch set-bar, wird aber in der Cref nicht mehr erwähnt und der Slider in FHEMWEB wirkt sich offensichtlich nur auf setpointTemp aus.

Es gibt alles, was in den Auswahlmenüs angeboten wird. desired-temp entspricht setpointTemp. Ich habe es beibehalten - obwohl es nicht recht in die EnOcean Terminologie passt -, da es in manchen anderen Fhem Modulen verwendet wird.

[fallenguru]

"Mittlere Sensation" ist sicher übertrieben, aber ist ist schon so, dass der vom MD15 gesendete Raumtemperaturwert sofort in die Berechnung einfließt und damit der neue Stellwert ermittelt und als Rückmeldung unmittelbar an den MD15 gesendet wird.

Ach, ich bleib bei meiner "mittleren Sensation". 10 min weniger Verzögerung sind eine Ewigkeit.

Wäre es möglich, einen Callback zu bekommen, der aufgerufen wird, sobald der Aktor Daten sendet, und die Möglichkeit hat, für denselben Zyklus noch ein Kommando abzusetzen? pidActorCallBeforeSetting funktioniert ja wohl nur mit pidCtrl on.

desired-temp entspricht setpointTemp. Ich habe es beibehalten - obwohl es nicht recht in die EnOcean Terminologie passt -, da es in manchen anderen Fhem Modulen verwendet wird.

Hm, synchronisiert werden desired-temp und setpointTemp aber nicht, welches gilt dann? Egal, ich hab jetzt alles auf setpointTemp umgestellt.

Noch mehr Fragen (sorry):
* Was sollte passieren, wenn ich in pidCtrl on ein set setpoint absetze?
setpointSet und setpoint gehen zwar auf den gesetzten Wert, pidState auf stoped, operationMode auf setpoint und waitingCmds bleibt auf Dauer setpoint, der Aktor rührt sich nicht. Dasselbe mit pidCtrl off und der Motor springt an. Schön wäre, wenn das entweder funktionierte, mit automatischer Wiederaufnahme der PID-Steuerung nach dem nächsten set setpointTemp, oder eine Fehlermeldung brächte, dass manuelles Setzen des Ventilstandes im PID-Modus nicht möglich ist.
* Jetzt mit pidCtrl off: Warum bleibt nach einem set setpoint waitingCmds permanent auf setpoint, nämlich auch dann, wenn die Änderung schon längst erfolgreich ausgeführt wurde? Dafür springt setpointSet auf 0, sobald der Befehl ausgeführt wurde, sollte das nicht immer den zuletzt vom Benutzer gesetzten Wert enthalten, analog zu setpointTempSet?
* EDIT: Wenn's leicht geht, hätte ich gerne die Möglichkeit, eine berechnete "tatsächliche Raumtemperatur" zu injecten zurück. Das RefDev ist zwar schön, aber halt nur eine Datenquelle.

[klaus.schauer]

Wäre es möglich, einen Callback zu bekommen, der aufgerufen wird, sobald der Aktor Daten sendet, und die Möglichkeit hat, für denselben Zyklus noch ein Kommando abzusetzen? pidActorCallBeforeSetting funktioniert ja wohl nur mit pidCtrl on.

Die Funktion habe ich aus PID20 übernommen.
Wozu soll ein "callback" für das Profil selbst sinnvoll sein und was soll als Rückgabewert ausgewertet werden?

Hm, synchronisiert werden desired-temp und setpointTemp aber nicht, welches gilt dann? Egal, ich hab jetzt alles auf setpointTemp umgestellt.

Natürlich wird synchronisiert. Man muss halt waren können, manchmal 10 min!

* Was sollte passieren, wenn ich in pidCtrl on ein set setpoint absetze?
setpointSet und setpoint gehen zwar auf den gesetzten Wert, pidState auf stoped, operationMode auf setpoint und waitingCmds bleibt auf Dauer setpoint, der Aktor rührt sich nicht. Dasselbe mit pidCtrl off und der Motor springt an. Schön wäre, wenn das entweder funktionierte, mit automatischer Wiederaufnahme der PID-Steuerung nach dem nächsten set setpointTemp, oder eine Fehlermeldung brächte, dass manuelles Setzen des Ventilstandes im PID-Modus nicht möglich ist.
* Jetzt mit pidCtrl off: Warum bleibt nach einem set setpoint waitingCmds permanent auf setpoint, nämlich auch dann, wenn die Änderung schon längst erfolgreich ausgeführt wurde? Dafür springt setpointSet auf 0, sobald der Befehl ausgeführt wurde, sollte das nicht immer den zuletzt vom Benutzer gesetzten Wert enthalten, analog zu setpointTempSet?

Bitte die Device-Lists und verbose 5-LOGs zu den Zuständen vor und nach den Eingaben senden.

[fallenguru]

Wozu soll ein "callback" für das Profil selbst sinnvoll sein und was soll als Rückgabewert ausgewertet werden?

Naja, im Idealfall möchte man eben erst berechnen, was als nächstes zu tun ist, nachdem der Aktor seine Statusmeldung abgegeben hat (incl. brandaktueller Temperatur), und darauf unmittelbar reagieren, bevor der Aktor wieder einschläft. Momentan kann das scheint's nur die hardcoded integrierte PID-Logik, das bringt wenig, wenn man seine eigene Regellogik schreiben möchte. (Ich lasse die Therme hier nur einschalten, wenn ausreichend Wärmebedarf besteht, entsprechend bleibt eine Regelung am Aktor ohne messbare Auswirkungen, solange das nicht der Fall ist. Das verwirrt den PID-Regler endlos.) Ideal fände ich es, wenn man dem MD15 (&Co.) device per Attribut eine Perl-Expression geben könnte, die aufgerufen wird, nachdem die aktuellen readings gesetzt sind, und deren Rückgabewert verwendet wird, um den Befehl, der als Reaktion gesendet wird, zu bestimmen. Wie der Rückgabewert genau aussehen soll, hängt davon ab, was einfach zu implementieren ist. (Aus Benutzersicht naheliegend wäre ein string mit einem set-Kommando ohne "set" und device-Namen.)

Schon klar, dass das ein reines wishlist item ist und vielleicht nicht hierher gehört, es ist für mich nur die logische Konsequenz aus der neuen Funktionalität.

Natürlich wird synchronisiert. Man muss halt waren können, manchmal 10 min!

Seit ich die alten readings, incl. desired-temp, gelöscht habe, geht's. Jetzt wirkt sich set X desired-temp unmittelbar auf setpointTempSet aus.

Bitte die Device-Lists und verbose 5-LOGs zu den Zuständen vor und nach den Eingaben senden.

Gerne, sobald ich wieder daheim bin.

[klaus.schauer]

Naja, im Idealfall möchte man eben erst berechnen, was als nächstes zu tun ist, nachdem der Aktor seine Statusmeldung abgegeben hat (incl. brandaktueller Temperatur), und darauf unmittelbar reagieren, bevor der Aktor wieder einschläft. Momentan kann das scheint's nur die hardcoded integrierte PID-Logik, das bringt wenig, wenn man seine eigene Regellogik schreiben möchte. (Ich lasse die Therme hier nur einschalten, wenn ausreichend Wärmebedarf besteht, entsprechend bleibt eine Regelung am Aktor ohne messbare Auswirkungen, solange das nicht der Fall ist. Das verwirrt den PID-Regler endlos.) Ideal fände ich es, wenn man dem MD15 (&Co.) device per Attribut eine Perl-Expression geben könnte, die aufgerufen wird, nachdem die aktuellen readings gesetzt sind, und deren Rückgabewert verwendet wird, um den Befehl, der als Reaktion gesendet wird, zu bestimmen. Wie der Rückgabewert genau aussehen soll, hängt davon ab, was einfach zu implementieren ist. (Aus Benutzersicht naheliegend wäre ein string mit einem set-Kommando ohne "set" und device-Namen.)

Schon klar, dass das ein reines wishlist item ist und vielleicht nicht hierher gehört, es ist für mich nur die logische Konsequenz aus der neuen Funktionalität.

Lässt sich leider (derzeit) nicht realisieren, da aus Laufzeitgründen nach der Auswertung des Aktortelegramms Fhem sofort das Antworttelegramm sendet und erst danach die Readings ausgegeben werden. Das gilt für alle Profile und könnte nur durch völliges Neudesign der set-Routine ändert werden. Das halte ich aber wegen der dann auf jeden Fall größer werdenden Verzögerung der Antworttelegramme für kontraproduktiv.

P. S.: Es wird wahrscheinlich doch eine Lösung über ein neues Attribut rcvRespAction geben, in das die gewünschten Befehlssequenzen eingetragen werden. Die Syntax entspricht der aus notify und at. Spezielle Variablen z. B. $TEMPERATURE, $SETPOINT können in den individuellen Programmcode eingefügt werden. Ich teste das gerade.

[klaus.schauer]

Beim Profil hvac.01 (Kieback&Peter MD15-FTL-xx u. a.) können in der Phase nach der Auswertung des Aktortelegramms und dem Versand der Rückmeldung durch Fhem individuelle Operationen ausgeführt werden. Die Programmzeilen werden im Attribut rcvRespAction abgelegt. Innerhalb der Programme stehen folgende Variablen zur Verfügung: $NAME, $ACTUATORSTATE, $BATTERY, $COVER, $ENERGYINPUT, $ENERGYSTORAGE, $MAINTENANCEMODE,  $OPERATIONMODE, $ROOMTEMP, $SELFCTRL, $SETPOINT, $SETPOINTTEMP, $SUMMERMODE, $TEMPERATURE, $WINDOW. Diese Variablen beinhalten den Namen des Fhem-Devices und die aktuellen Werte der gleichnamigen Readings. Die Funktionalität entspricht der der  Module notify und at.

[fallenguru]

Tut mir leid, dass ich mich so lange nicht gemeldet habe, momentan steht mir die Arbeit bis da.

Beim Profil hvac.01 (Kieback&Peter MD15-FTL-xx u. a.) können in der Phase nach der Auswertung des Aktortelegramms und dem Versand der Rückmeldung durch Fhem individuelle Operationen ausgeführt werden. Die Programmzeilen werden im Attribut rcvRespAction abgelegt. Innerhalb der Programme stehen folgende Variablen zur Verfügung: ...

Das ist vielleicht ein Service, danke!

Die anderen Punkte scheinen sich in Luft aufgelöst zu haben (einzige Änderung, an die ich mich erinnern kann, ist die Entsorgung alter readings, momentane Version ist jedenfalls V11035). Das Einzige, was mir noch seltsam vorkommt, ist, dass nach der Ausführung eines set setpoint durch den Aktor das reading waitingCmd nicht gelöscht wird, bei set setpointTemp aber schon.

[klaus.schauer]

waitingCmd wird gelöscht, sobald es keinen wartenden Befehl mehr gibt. In einigen Aktorstatis - insbesondere nach maintenance-Aktionen - werden zwei Befehle nacheinander abgearbeitet. Deshalb bitte detailliert beschreiben, welche Befehle abgesetzt wurden.

[fallenguru]

Jetzt hab ich eine Dreiviertelstunde damit verbracht, log auf verbose 5 und vorher-nachher-zwischendurch list-Ausgaben für das nächste Posting zu sammeln -- nur um draufzukommen, dass im list eh alles passt. Sieht so aus, als ob mein FHEMWEB beim Entfernen von readings manchmal nachhängt, trotz Refresh (Shift-Refresh tut's immer). Das kann FHEMWEB sein und/oder meine Firefox-Version, aber nicht das EnOcean-Modul. Mea culpa . Na, jetzt weiß ich wenigstens, warum immer alle ein list haben wollen ...