Siehe neues Modul PID20
http://forum.fhem.de/index.php/topic,17067.msg111615.html#msg111615 (http://forum.fhem.de/index.php/topic,17067.msg111615.html#msg111615)
Ich mühe mich derzeit damit ab, meine Fussbodenheizung mit einem Max-Ventil als Stellglied und PID als Regler
in den Griff zu bekommen. Dabei sind nachfolgende Punkte aufgefallen, die ich zur Diskussion stelle.
Bearbeitungszyklus hängt vom Sensor ab
PID wir derzeit vom Sensor getriggert. Der Bearbeitungszyklus hängt also direkt von der Datenrate
des Sensors ab. Das hat unmittelbar Einfluss auf den I-Anteil.
Vorschlag:
Der Bearbeitungszyklus wird über einen Timer im Minuten-Takt getriggert, unabhängig vom Sensor.
Ausgabehäufigkeit an das Stellglied sollte parametriebar sein
Das PID Modul hat in kürzester Zeit sämtliche Credits meines CULS verbraten, so dass für die anderen Funktionen
keine Reserven mehr vorhanden waren. (z.B. Heating-Control)
Vorschlag:
Ausgabe nicht häufiger als alle n-Minuten
Ausgabe nur dann, wenn die Stellgröße um mindestens xy % zu verändern ist.
Prozesswissen merken beim Neustart von FHEM
Der I-Anteil wird beim Neustart stets gelöscht, so dass der Regler wieder von NULL anfangen muss, diesen aufzubauen.
Vorschlag:
Nur wenn der in Readings gemerkte I-Anteil älter als 1 Stunde ist wird dieser beim Aufstarten verworfen.
I-Anteil limitieren
Auch wenn der P-Anteil bereits 100% einnimmt, kann der I-Anteil parallel dazu ebenfalls bis auf 100% bzw. satMax
anwachsen. Wenn sich eine Umkehr der Regeldifferenz ergibt wird der P-Anteil in die richtige Richtung weisen,
jedoch der Überhang vom I-Anteil bewirkt, dass der Stellausgang auf 100% verharrt.
Dasselbe gilt auch bei 0% bzw. satMin.
Vorschlag:
I-Anteil nur soweit anwachsen lassen, dass er in Summe mit dem P-Anteil die 100% bzw. satMax nicht überschreitet,
Entsprechendes für satMin.
Sensor Überwachung
Sobald der Sensor nach einer Zeit von xy-Minuten keinen Wert mehr liefert, sollte der PID-Regler
auf den aktuellen Zustand einfrieren und in den Readings einen entsprechend Meldung liefern.
Charting Fähigkeit
schön wäre auch, wenn die Readings zu desired, aktuellem Sensor-Istwert und Reglerausgang(actuation), unabhängig von der Änderung des Stellausgangs aktualisiert würden, damit diese direkt in einer Log-Datei gespeichert werden können und
entsprechende Charts möglich wären.
John
Ich habe das PID Modul von Alexander "geerbt", bzw. er hat PID als Funktionen fuer notify plus Beschreibung in contrib abgelegt, und ich habe daraus ein Modul mit Doku gebaut. Ich habe es weder verwendet, noch kann ich es sinnvoll testen, deswegen bin ich einigermassen erstaunt darueber, dass bisher kaum Fragen dazu gab.
Die Vorschlaege sind vermutlich alle sinnvoll, die entsprechenden Intervalle/Minimum-Werte sollten aber per Attribut konfigurierbar sein. Falls jemand mir hier Patches zur Verfuegung stellt, baue ich sie gerne ein, danach kann ich die Modulpflege an dem Patch-Autor auch gerne weitergeben.
Zitat von: rudolfkoenig schrieb am Mi, 02 Oktober 2013 07:43Falls jemand mir hier Patches zur Verfuegung stellt, baue ich sie gerne ein, danach kann ich die Modulpflege an dem Patch-Autor auch gerne weitergeben.
Dreh doch die Reihenfolge mal um, dann kann ich mal schauen, was sich alles machen läßt.
Einige der geäußerten Wünsche sind auch derzeit schon machbar, (z.B. mit addLog() u.ä.) aber es wäre natürlich schön, wenn das Modul selbst etwas besser konfigurierbar wäre. Ich würde in dem Zusammenhang auch eine Umstellung auf readings..Update() durchführen.
Lustig finde ich, dass man ewig gar nichts zu dem Modul liest und dann nahezu zeitgleich zwei Leute darüber stolpern, dass da einiges zu optimieren ist.
> Dreh doch die Reihenfolge mal um, dann kann ich mal schauen, was sich alles machen läßt.
Von mir aus gerne, Du hast ja auch weitere Module.
Damit bist Du zum PID Maintainer geworden.
Ok :) Dann kann ich ja meine Änderung aus dem anderen PID-Thread schonmal gleich selbst einchecken.
Da gratuliere ich dem neuen Maintainer des PID-Moduls.
Meine Änderungsvorschläge habe ich alle schon prototypisch umgesetzt.
Das Skript befindet sich noch in der Testphase.
Sobald es sich bewährt hat, stelle ich es Betateilchen zur Verfügung.
John
OK...
ToDo-Liste (meine Ideen) von meiner Seite:
- Ausbau der hardwareabhängigen Typprüfung, stattdessen prüfen, ob der Sensor ein Standardreading "temperature" oder "measured-temp" hat, falls nicht und keine Angaben spezifiziert -> Fehlermeldung ausgeben
- Umstellung auf readings...Update() (bereits umgesetzt)
- Zyklische Abfrage über InternalTimer anstatt Trigger vom Sensor, Intervall per Attribut setzbar, default=60s (bereits umgesetzt)
- Regelmäßiges Logging (ergibt sich automatisch aus der zyklischen Abfrage)
- Intervall für Ansteuerung des Stellantriebs paramtrierbar machen
ZitatVorschlag:
Der Bearbeitungszyklus wird über einen Timer im Minuten-Takt getriggert, unabhängig vom Sensor.
Welchen Sinn macht das eigentlich, wenn ich während des Abfragezyklus keine Rückmneldung vom Sensor bekommen habe, wie sich die Isttemperatur verändert? Die meisten Temperatursensoren, die ich kenne, liefern (hardwareseitig festgelegt) Daten nur im Abstand von ca. 3 Minuten.
Zitat von: betateilchen schrieb am Mi, 02 Oktober 2013 14:53OK...
ToDo-Liste (meine Ideen) von meiner Seite:
- mehrere PID Instanzen
- Ausbau der hardwareabhängigen Typprüfung, stattdessen prüfen, ob der Sensor ein Standardreading "temperature" oder "measured-temp" hat, falls nicht und keine Angaben spezifiziert -> Fehlermeldung ausgeben
- Umstellung auf readings...Update() (bereits umgesetzt)
- Zyklische Abfrage über InternalTimer anstatt Trigger vom Sensor, Intervall per Attribut setzbar, default=60s (bereits umgesetzt)
- Regelmäßiges Logging (ergibt sich automatisch aus der zyklischen Abfrage)
- Intervall für Ansteuerung des Stellantriebs paramtrierbar machen
ZitatVorschlag:
Der Bearbeitungszyklus wird über einen Timer im Minuten-Takt getriggert, unabhängig vom Sensor.
Welchen Sinn macht das eigentlich, wenn ich während des Abfragezyklus keine Rückmneldung vom Sensor bekommen habe, wie sich die Isttemperatur verändert? Die meisten Temperatursensoren, die ich kenne, liefern (hardwareseitig festgelegt) Daten nur im Abstand von ca. 3 Minuten.
ZitatWelchen Sinn macht das eigentlich, wenn ich während des Abfragezyklus keine Rückmneldung vom Sensor bekommen habe, wie sich die Isttemperatur verändert? Die meisten Temperatursensoren, die ich kenne, liefern (hardwareseitig festgelegt) Daten nur im Abstand von ca. 3 Minuten.
Der I-Anteil ist ein Integrator über die Zeit zur Regeldifferenz.
Die ist auch noch da, wenn mal 3 Minuten kein Wert vom Sensor kommt.
Über die Zeit integrieren heisst in einem festgelegt Zyklus die Differenz bewerten und akkumulieren.
Im Skript ist das schon richtigt angelegt. Es muss nur regelmässig ausgeführt werden.
# i-anteil berechnen
my $i = PID_gv($pid,'integrator')+$delta*$pid->{iFactor};
John
Zitat von: John schrieb am Mi, 02 Oktober 2013 15:00Im Skript ist das schon richtigt angelegt. Es muss nur regelmässig ausgeführt werden.
Kein Problem, das hab ich schon drin.
Im Prinzip bin ich grade dabei, das ganze Modul an die aktuelle fhem-Implementierung anzupassen. Von der Regelung selbst habe ich nicht soviel Ahnung, da übernehme ich erstmal das, was schon da ist, bzw. das was Du mir als Verbesserung vorschlägst.
Um die Dinge wie "Werte merken" kümmere ich mich quasi nebenbei auch noch. Wenn Du noch irgendwelche Codeschnipsel hast, die in dem Modul Sinn machen, kannst Du mir die gerne per email hier über das Forum schicken, dann kann ich Dir auch zwischendurch mal einen Entwicklungsstand zurückschicken.
Viele Grüße
Udo
Hallo Udo,
das Ganze sieht bei mir so aus:
(siehe Anhang / see attachement)
Der Regler macht das was man erwartet, er versucht den Sollwert zu erreichen und zwar "gesittet"
, er lässt den anderen Komponenten noch Luft zum atmen.
Sein Verhalten ist für mich klarer und nachvollziehbarer als das der Max-internen Regler selbst.
Deren Verhalten kann ich nicht immer nachvollziehen (belässt stundenlang eine Regeldifferenz von 1 Grad)
Im ersten Diagramm zeigen die markierten Bereiche das Gezapple, das sich ergibt, wenn man das Ausgabeintervall
nicht limitiert, das war im Original noch schlimmer, da praktisch alle 3 Minuten eine Ausgabe erfolgte.
Ab 15 Uhr ist die Limitierung drin. Das nächste Diagramm zeigt den heutigen Tag.
Ab 04:00 wird die Heizung eingeschalten.
Internals
actuationTime ist der Zeitstempel der letzten Ausgabe an das Stellglied.
Brauchen wir zur Bestimmung des Zeitkriteriums.
Daneben gibt es mit dem Attribut actuatorThreshold das 2. Kriterium das eine Mindeständerung fordert.
Readings
actuation ist der interne Rechenwert, actuationDone derjenige, der tatsächlich am Stellglied ausgegeben wurde.
pPortion ist der P-Anteil an actuation.
currentValue ist der Istwert des Reglers, also der Sensorwert
processingState, sagt uns ober der Regler gestoppt ist (Istwert fehlt) oder pausiert oder läuft (processing).
Attributes
actuatorThreshold, schon erwähnt
deltaThreshold, wenn diese Mindestabweichung unterschritten ist, pausiert der Regler. (Pseudo-Abweichung)
sensorTimeout , in Minuten, wenn der Zeitstempel des sensor-Readings älter ist als diese Zeitdifferenz, haben wir den Sensor verloren, der Regler geht auf stopped
updateRate, in Minuten hat 2 Bedeutungen:
1. die Mindestwartezeit für neue Ausgabe an Stellglied,
2. die UpdateRate der Readings, damit wir schöne Charts bekommen
Der I-Anteil wird bei Start nicht mehr auf 0 gesetzt, somit bleibt das Prozesswissen vorhanden.
Ausserdem wird sein Wachstum nach unten und oben begrenzt, so dass er in Summe mit dem p-Anteil die 100 nicht überschreitet.
und die 0 nicht unterschreitet.
Anbei noch mein Skript.
John
hm... danke.
Wir sollten grundsätzlich nicht vergessen, dass es auch noch andere Komponenten als die von Max gibt ;)
Hallo Udo,
da ist nichts drin, was MAX-spezifisch ist.
Alles was mit Funk läuft muss auf die Ressourcen achten oder liege ich da falsch ?
(1% Regel)
John
Das stimmt schon. Mein Gedanke ging auch eher in eine andere Richtung (ich muss mal eine Nacht drüber schlafen).
Ach, da muss ich mich doch gleich anhängen (kapern):
Dass keine Meldungen zu PID kommen, bedeuted nicht, dass es nicht verwendet wird.
Ich habe folgendes Problem:
Als Sensor verwende ich einen OWXTerm. Gelegentlich verschwindet OWX - warum auch immer. Und damit stirbt auch PID (vermutlich wegen der internen Verknüpfung mit demdann nicht mehr existierenden OWX-Device). Das letztendlich geführte FHT8V geht dann nach einiger Zeit in den Notbetrieb (Einstellung 30%) und muss dann, wenn alles wieder funktioniert, neu gepaired werden ( äääääääääääää! ). Fruet sich die Gattin, wenn es piept und nicht weiss, wie sie es wieder in die Gänge kriegen soll.
Gibt doch bestimmt eine Lösung (innerhalb PID)????
Bernhard
Hallo Bernhard,
ZitatGelegentlich verschwindet OWX - warum auch immer. Und damit stirbt auch PID
Nach dem derzeitigen Stand muss das so sein, da der PID vom Sensor "getrieben" wird.
Aber das wollen wir ja ändern.
ZitatDas letztendlich geführte FHT8V geht dann nach einiger Zeit in den Notbetrieb (Einstellung 30%) und muss dann, wenn alles wieder funktioniert, neu gepaired werden
Wir haben ja auch vorgesehen, dass wir den Sensor überwachen wollen.
Wenn nun der Sensor ausfällt und PID merkt dies, müsste er nach wie vor regelmässig den Stellbefehl an
FHT8V ausgeben, damit dieser nicht in Notbetrieb fällt ?
Wenn ja, wie in welchem Mindestintervall muss dies geschehen ?
John
Hallo,
für den "Notbetrieb nehme ich an, dass dann 5-10 Minuten passen würden. Standardzyklus von FHT sind m.W. 2 Minuten. Dann sollte aber auch ein Not-Stellwert vorgegeben werden können. 30% dürfte im Allgemeinen zu viel sein.
Alternativ könnte ich mir auch nen Ersatzsensor vorstellen.
Das Ganze nur über "at" und/oder "notify" zu treiben fände ich allerdings nicht ganz so toll.
Blödsinnigerweise passiert das immer, wenn ich ein paar Tage nicht da bin, dann glüht es im Wohnzimmer :-))
Bernhard
Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21Das Ganze nur über "at" und/oder "notify" zu treiben fände ich allerdings nicht ganz so toll.
Das externe Triggern des PID wird komplett wegfallen, keine Sorge.
Zum FHT8V:
- Den Kommunikationstimeout müssen wir noch genauer rausfinden, ich denke, das ist länger als 5-10 Minuten.
- Die Notbetriebsstellung wird auch parametrierbar sein, das ist von mir schon vorgesehen, denn bei 30% wird es bei mir viel zu warm im Raum.
- Das viel größere Problem ist, dass ich nicht feststellen kann, ob der FHT8V überhaupt noch lebt, weil das ein reiner Empfänger ist
Die Attribute pidInterval, pidActorThreshold, pidDeltaTreshold habe ich bereits eingebaut.
---
Zum FHT8V:
[quote title=betateilchen schrieb am Do, 03 Oktober 2013 12:54]
Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21- Den Kommunikationstimeout müssen wir noch genauer rausfinden, ich denke, das ist länger als 5-10 Minuten.
* FHT sendet alle ca. 2 Minuten
* TimeOut dürfte im Stundenbereich sein - aber weiss der Teufel .....
[quote title=betateilchen schrieb am Do, 03 Oktober 2013 12:54]
Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21- Das viel größere Problem ist, dass ich nicht feststellen kann, ob der FHT8V überhaupt noch lebt, weil das ein reiner Empfänger ist
vielleicht darüber, dass die Temperatur nicht den Stellbefehlen folgt ?
Bernhard
[quote title=Bernhard schrieb am Do, 03 Oktober 2013 13:37]Zum FHT8V:
Zitat von: betateilchen schrieb am Do, 03 Oktober 2013 12:54Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21- Den Kommunikationstimeout müssen wir noch genauer rausfinden, ich denke, das ist länger als 5-10 Minuten.
* FHT sendet alle ca. 2 Minuten
* TimeOut dürfte im Stundenbereich sein - aber weiss der Teufel .....
Der TimeOut liegt bei knapp unter 2 Stunden.
Gerade mal getestet.
Hallo Udo
bin gerade dran meine PID-Variante mit Heating_Control zu verknüpfen.
habe folgendes realisiert:
set <device> (desired-temp|desiredTemerature|desired|comfort|comfort-temp|comfortTemperature|eco|eco-temp|eco-temperature) <temp>
mit temp : (<number>|comfort|comfort-temp|comfortTemperature|eco|eco-temp|eco-temperature)
damit geht folgends
set PID_BAD desired-temp comfort
Damit
- 2 weitere Readings: eco, comfort
- folgende auf initial-Wert stellen falls diese noch nicht definiert sind
eco = 18, comfort=21, desired=21
Anbei die Realisierung in meinem Skript.
John
Ein Problem sehe ich noch im Zusammenhang mit Heating-Control.
Es wird beim Hochfahren von FHEM eher geladen als PID und will "desired" setzen.
Gibt es hierzu eine Lösung ?
John
ja, da muss im Heating-Control ein "require PID" eingebaut werden.
Ich habe jetzt mal eine erste Testversion fertig. Da ist HCS jetzt natürlich noch nicht eingebaut.
Funktionsumfang und Define ist grundsätzlich wie im Originalmodul auch. Die Funktionsweise ist aber anders.
Attribute:
pidActorInterval = Mindestzeit zwischen zwei Kommandos an den Aktor
pidActorTreshold = Mindeständerung, ab der ein Kommando an den Aktor geschickt wird
pidActorErrorPos = Notstellung für Fehlerfall (noch nicht verwendet)
pidDeltaInterval = Intervall, in dem Sensorabfrage und Berechnung durchgeführt werden
pidDeltaTreshold = Mindesttemperaturänderung, ab der eine Berechnung stattfindet
pidSensorTimeout = Zeitraum, nach der ein Sensor als "tot" gemeldet wird (Reading und Logmeldung) wenn keine Aktualisierung des Messwertes erfolgt
Set Befehle:
set <name> clear = löscht die berechneten Werte manuell (automatisches Löschen erfolgt, wenn älter als 1 Stunde)
set <name> factors = wie bisher
set <name> desired-temp = setzt die gewünschte Temperatur
Es wird noch ein weiteres Attribut "pidParamTimeout" geben, um die Gültigkeitsdauer der berechneten Parameter festzulegen, aktuell steht die fest auf 3600 Sekunden.
Ich habe bis Montag weder einen Sensor noch einen Stellantrieb zur Verfügung, das Ganze ist nur aus der Theorie und mit Hilfe von dummies entstanden.
Es wäre schön, wenn jemand die implementierte Grundfunktion "in echt" testen könnte.
Viele Grüße
Udo
Hallo Udo,
besten Dank für den ersten Wurf.
Was mir bei der ersten Durchsicht aufgefallen ist:
Z.140
when("clear"){
Log3 $name, 3, "PID set $name $cmd";
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, 'actuation', '0.0');
readingsBulkUpdate($hash, 'delta', '0.0');
readingsBulkUpdate($hash, 'integrator', '0.0');
readingsBulkUpdate($hash, 'state', 'active');
Es macht aus meiner Sicht keinen Sinn acutation, delta und state zu löschen, da diese im nächsten zyklus wieder gesetzt werden. Integrator ist ok.
Z. 161
Zitatwhen("desired-temp") {
was machen wir wenn wir keine Temperatur regeln wollen, sondern Feuchte. Da macht das unverbindliche desired
auch wieder Sinn.
(siehe mein Vorschlag von heute Nachmittag für Alias-Namen)
sub PID_setValue($) {
...
if(!readingTimeValid(ReadingsTimestamp($sensor,$reading,''),AttrVal($name,'pidSensorTimeout',3600))) {
Log3 $name, 1, "PID $name: Sensor $sensor dead!";
readingsSingleUpdate($hash,'sensorState','dead',1);
} else {
readingsSingleUpdate($hash,'sensorState','alive',1);
}
Timeout sollte irgendwann parametriebar sein, nicht fest auf 1h. Es gibt auch schnellere Prozesse,
die es nicht erlauben 1h zu warten.
Sollwert-Container für eco und comfort wären natürlich schön und würde die Kompatiblität zu physischen
Reglern fördern.
Z. 218
if(!readingTimeValid(ReadingsTimestamp($name,'integrator',''),3600)){
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, 'actuation', 0.0);
readingsBulkUpdate($hash, 'delta', 0.0);
readingsBulkUpdate($hash, 'integrator', 0.0);
D.h. wenn der Regler auf Anschlag steht, z.B 100% wirst du ihn nach einer Stunde auf 0 runterprügeln;
damit wird es wenn es schon zu kalt ist, noch kälter.
Hab ich da was falsch verstanden ?
Z. 233
if($delta >= AttrVal($name,'pidDeltaTreshold','0')) {
Wenn der Regler eingeregelt ist, gibts hier leider keine Kurven mehr, da die Readings nicht mehr aktualisiert werden.
Z. 260
if($aDiff >= AttrVal($name,'pidActorTreshold','0') && $tDiff >= AttrVal($name,'pidActorInterval','0')) {
# send command to actor
Angenommen pidDeltaTreshold = 5 und Stellglied steht auf 96% und will weiter auffahren, dann kann er das nicht.
Man braucht am Anfang/Ende des Stellbereiches eine Sonderbehandlung.
Z. 270
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, 'actuation', $a);
readingsBulkUpdate($hash, 'delta', $delta);
readingsBulkUpdate($hash, 'integrator', $i);
readingsBulkUpdate($hash, 'state', 'active');
readingsEndUpdate($hash, 1);
Ich würde mir hier noch den Sensorwert wünschen, dann ist der Chart schnell komplett (Istwert, Sollwert, Stellausgang).
Einen Minutenzyklus für den Integrator halte ich für sinnvoll, aber nicht für das Updaten der Readings.
Das müllt die Files unnötig mit immer denselben Werte zu. Vorschlag: dies mit pidActorInterval steuern und immer dann
wenn sich der Stellausgang ändert.
John
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Z.140
Es macht aus meiner Sicht keinen Sinn acutation, delta und state zu löschen, da diese im nächsten zyklus wieder gesetzt werden. Integrator ist ok.
Es hilft, falls jemand alle Werte loggen möchte, denn dann hat er genau an dieser Stelle einen Peak nach unten im Log.
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Z. 161
was machen wir wenn wir keine Temperatur regeln wollen, sondern Feuchte. Da macht das unverbindliche desired auch wieder Sinn.
(siehe mein Vorschlag von heute Nachmittag für Alias-Namen)
...
Sollwert-Container für eco und comfort wären natürlich schön und würde die Kompatiblität zu physischen
Reglern fördern.
Ich hatte extra dazugeschrieben, dass Deine Vorschläge von heute nachmittag noch nicht berücksichtigt sind.
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Timeout sollte irgendwann parametriebar sein, nicht fest auf 1h. Es gibt auch schnellere Prozesse,
die es nicht erlauben 1h zu warten.
Ich hatte oben schon geschrieben, dass dieser Parameter in Arbeit ist.
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Z. 218
D.h. wenn der Regler auf Anschlag steht, z.B 100% wirst du ihn nach einer Stunde auf 0 runterprügeln;
damit wird es wenn es schon zu kalt ist, noch kälter.
Das Reading sollte auch einen neuen Timestamp bekommen, wenn es nicht verändert wurde. Bei mir funktioniert das jedenfalls so. Dadurch wird der Timeout eigentlich im laufenden Betrieb nicht erreicht.
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Wenn der Regler eingeregelt ist, gibts hier leider keine Kurven mehr, da die Readings nicht mehr aktualisiert werden.
muss ich mir anschauen.
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Angenommen pidDeltaTreshold = 5 und Stellglied steht auf 96% und will weiter auffahren, dann kann er das nicht.
Man braucht am Anfang/Ende des Stellbereiches eine Sonderbehandlung.
Ich weiss. Ich hatte aber auch nirgends geschrieben, dass diese Sonderbehandlung schon eingebaut sei ;)
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Ich würde mir hier noch den Sensorwert wünschen
Der ist doch sowieso immer in den Readings vorhanden.
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33, dann ist der Chart schnell komplett (Istwert, Sollwert, Stellausgang).
Einen Minutenzyklus für den Integrator halte ich für sinnvoll, aber nicht für das Updaten der Readings.
Das läßt sich ganz individuell mit fhem-Boardmitteln (Attribute event-.*) steuern, deshalb muss ich da das Rad nicht neu erfinden und das im Modul selbst nachprogrammieren. Das kannst Du Dir konfigurieren, wie Du möchtest.
Es fehlen auch noch ein paar andere Dinge, z.B. wird eine Änderung des Intervals nicht sofort wirksam, sondern erst nach dem nächsten Durchlauf. Weiß ich alles, aber ich habe auch nur zwei Hände :)
Den Zusammenhang zwischen dem PID Modul und deinem HCS Einsatz habe ich noch nicht verstanden. Also, wie das zusammenspielen soll.
Hallo Udo,
ich schätze deinen Einsatz sehr.
Mit meinen Anmerkungen will ich dich unterstützen, nicht kritisieren.
Zur Klärung von "HCS"
das meine ich nicht
http://fhem.de/commandref.html#HCS (//fhem.de/commandref.html#HCS)
sondern dieses Modul
http://fhem.de/commandref.html#Heating_Control (//fhem.de/commandref.html#Heating_Control)
Es ist ein Wochenschaltprogramm, das ich für die Thermostate einsetze.
Es setzt direkt oder indirekt über ein Skript zeitabhängig den Sollwert des Thermostats.
Beispiel:
Ich habe ein Thermostat f. Fussbodenheizung(PID in FHEM + Max als Stellglied) und eines f. Heizkörper (MAX realisiert Reglung und Stellglied) im selben Raum.
define HC.BAD Heating_Control HT.BAD 00:05|eco 12345|04:15|comfort 67|06:00|comfort 12345|07:00|eco 67|10:00|eco 15:00|comfort 21:30|eco {MaxScan_SetTemp("@","%");; fhem("set PID_BAD desired %");;}
Es wird also um 00:05 Uhr folgenden Befehl absetzen:
set PID_BAD desired eco
Nochmal die Bitte die Readings unabhängig vom Sensortyp zu formulieren, da PID ein universales Modell ist:
readingsSingleUpdate($hash,'measured-temp',$in,1);
Vielleicht: sensor-value
John
Zitat von: John schrieb am Do, 03 Oktober 2013 23:10Nochmal die Bitte die Readings unabhängig vom Sensortyp zu formulieren, da PID ein universales Modell ist
Ja ja... das ist mir gestern auch klargeworden. Ich bastle grade an einer Version, in der man den Namen des Messwert- und des Soll-Readings per Attribut selbst definieren kann. Wenn nichts definiert wird, heissen die Readings measured und desired.
Wenn ich die Sache mit dem Heating Control richtig verstehe, geht es Dir nur darum, dass "eco" und "comfort" in irgendwelche Zahlenwerte übersetzt werden muss?
Umgesetzt:
- die Namen für die Readings desired und measured über neue Attribute pidDesiredName und pidMeasuredName frei wählbar.
- interne Tabelle für Aliase, "set <name> desired, desired-temp, desiredTemperature <val>" bewirken alle die gleiche Aktion
- neues Attribut pidParamTimeout
ZitatJa ja... das ist mir gestern auch klargeworden. Ich bastle grade an einer Version, in der man den Namen des Messwert- und des Soll-Readings per Attribut selbst definieren kann. Wenn nichts definiert wird, heissen die Readings measured und desired.
ausgezeichnet.
Zitat von: betateilchen schrieb am Fr, 04 Oktober 2013 10:07Wenn ich die Sache mit dem Heating Control richtig verstehe, geht es Dir nur darum, dass "eco" und "comfort" in irgendwelche Zahlenwerte übersetzt werden muss?
Die meisten Thermostate verfügen über abgesenkten(eco) und normalen Sollwert(comfort).
Bei den Max-Thermostaten, bei meiner Heizung und vielen anderen regelnden Systemen kenne ich das so.
In meiner letzten Version hab ich das so implementiert:
# fuehrungsparameter der varianten ermitteln
my $key = "";
$key = $PIDkeyDesiredTemp[0] if grep(/^$arg/i, @PIDkeyDesiredTemp);
$key = $PIDkeyEcoTemp[0] if grep(/^$arg/i, @PIDkeyEcoTemp);
$key = $PIDkeyComfortTemp[0] if grep(/^$arg/i, @PIDkeyComfortTemp);
# parameter converting eco/comfort # TAG 3
my $value = $a[2];
$value = ReadingsVal($pn,"eco","") if ($value eq "eco");
$value = ReadingsVal($pn,"comfort","") if ($value eq "comfort");
PID_sv($pid, $key, $value);
John
Zitat von: John schrieb am Fr, 04 Oktober 2013 10:35
my $value = $a[2];
$value = ReadingsVal($pn,"eco","") if ($value eq "eco");
$value = ReadingsVal($pn,"comfort","") if ($value eq "comfort");
PID_sv($pid, $key, $value);
Das ist ja schon etwas "von hinten durch die Brust ins Auge"... Nur mal so als Tipp:
PID_sv($pid, $key, ReadingsVal($pn, $a[2], ""));
bewirkt genau das gleiche in einer einzigen Zeile.
ABER: mir ist unklar, wie/wieso die Werte für "eco" und "comfort" in ein Reading kommen? Das sind doch keine Werte die vom PID generiert werden.
In meiner Lösung werden PID_sv() und PID_gv() nicht mehr vorkommen, weil das die Anwendung viel zu sehr einschränkt und die von fhem bereitgestellten komfortablen Möglichkeiten der event-Parametrierung ausschließt.
Die Tabelle für die "Befehlsübersetzung" habe ich inzwischen wieder ausgebaut, die steht in Konflikt mit der Möglichkeit, den Namen für "desired" jetzt frei wählen zu können.
Neu eingebaut:
set <name> stop
set <name> start
Es ist überhaupt noch die Grundsatzfrage zu klären, wann der PID gestartet werden soll. Im Moment ist das so, dass der PID Start nach einem "set <name> desired" erfolgt.
[quote title=betateilchen schrieb am Fr, 04 Oktober 2013 11:33]
Zitat von: John schrieb am Fr, 04 Oktober 2013 10:35ABER: mir ist unklar, wie/wieso die Werte für "eco" und "comfort" in ein Reading kommen?
Das sind doch keine Werte die vom PID generiert werden.
Stellst du eco und comfort generell in Frage oder willst du sie eher als Attribut anlegen ?
[quote title=betateilchen schrieb am Fr, 04 Oktober 2013 11:33]
Zitat von: John schrieb am Fr, 04 Oktober 2013 10:35Es ist überhaupt noch die Grundsatzfrage zu klären, wann der PID gestartet werden soll. Im Moment ist das so, dass der PID Start nach einem "set <name> desired" erfolgt.
Ich würde dafür plädieren, dass der PID sich selbst komplett nach der initialen Defiition "konservativ" für Raumtemperaturregelung parametriert und losstartet. (falls der Istwert verfügbar ist)
Motivation: vermuteter häufiger Einsatz für Raumtemperaturregelung, einfache Anwendung.
Alle Readings wie folgt einstellen, wenn noch nicht definiert:
- pFactor = 20
- iFactor = 0.15
- desired = 17
- eco=17
- comfort=20
- Bewertungs-Zykls = 60 sec
- Sensor-Timeout = 60 Minuten
- Threshold actuator = 5
- threshold sensor =0
- TimeLimit Actuator = 10 Minuten
John
Ich stelle eco und comfort nicht in Frage, aber es sind genausowenig Readings wie pFactor und iFactor. Das sind alles Parameter, die der PID für seine Funktion verwendet (und nicht generiert!) Es gibt bei Dir offenbar noch ein Verständnisproblem, was "Readings" sind.
In meinen obigen Codeschnipsel hat sich ein Fehler eingeschlichen. Es muss heißen: PID_sv($pid, $key, ReadingsVal($pn, "$a[2]", "$a[2]"));
Zitat von: John schrieb am Fr, 04 Oktober 2013 11:59wie folgt einstellen, wenn noch nicht definiert:
- pFactor = 20
- iFactor = 0.15
Hast Du auch noch einen Vorschlagswert für dFactor? Für den FHT8V sind ja folgende Faktoren festgelegt: p 25.5 / i 3 / d 5,9
Hallo Udo,
ich lerne tatsächlich bei dir ne ganze Menge.
Aber es scheinen auch die Entwickler von FHEM keine einheitliche Sprache zu sprechen:
Hier die Darstellung eines Max-Thermostats aus 10_MAX.pm.
ecoTemperature ist als Reading angelegt.
(siehe Anhang / see attachement)
Wo findet man den eine übergeordente Beschreibung der Verfahren und Mechanismen ?
Meine bisherige Quelle war der vorhanden Source-Code der Modul-Autoren.
John
[quote title=betateilchen schrieb am Fr, 04 Oktober 2013 12:47]
Zitat von: John schrieb am Fr, 04 Oktober 2013 11:59Hast Du auch noch einen Vorschlagswert für dFactor? Für den FHT8V sind ja folgende Faktoren festgelegt: p 25.5 / i 3 / d 5,9
dFactor auf 0.0.
John
Zitat von: John schrieb am Fr, 04 Oktober 2013 12:50Hier die Darstellung eines Max-Thermostats aus 10_MAX.pm.
ecoTemperature ist als Reading angelegt.
Ah...
Merke: Nicht alles, was mit set an ein device übergeben wird, ist automatisch auch ein Reading!
Beispiel: Die Faktoren für p i d die man mit set <pidName> factors setzen kann, werden nie in den Readings aufgeführt. Die werden als Parameter übergeben, die das Modul dann für die Verarbeitung verwendet.
Zitat von: John schrieb am Fr, 04 Oktober 2013 11:59wie folgt einstellen, wenn noch nicht definiert:
- pFactor = 20
- iFactor = 0.15
- dFactor auf 0.0
- Bewertungs-Zykls = 60 sec
- Sensor-Timeout = 60 Minuten
- Threshold actuator = 5
- threshold sensor = 0
- TimeLimit Actuator = 10 Minuten
Diese Parameter sind nun alle erledigt. Der Einheitlichkeit wegen erfolgen aber alle Zeitangaben in Sekunden!
Sieht doch recht übersichtlich aus, oder?
(siehe Anhang / see attachement)
Hallo Udo,
ja sieht sehr aufgeräumt aus.
Noch folgender Vorschlag:
actuation ergibt sich aus dem p-Anteil, dem i-Anteil und dem d-Anteil.
Mit integrator sehen wir nur den i-Anteil.
Es wäre sinnvoll auch den d-Anteil und noch mehr den p-Anteil im reading zu sehen.
Dann weiss man wie sich die Stellausgabe zusammensetzt und man hat bessere Optimierungsmöglichkeiten.
John
Aber p und d verändern sich doch während der Laufzeit des PID nicht? Also gehören die für mich nicht in die Readings.
Mit "get <pidName> params" kannst Du Dir jederzeit alle eingestellten internen Parameter anzeigen lassen.
Defined parameters for PID pid:
Actor name : ventil
Actor cmd : valve
Sensor name: sensor
Sensor read: state
Factor P: 20
Factor I: 0.15
Factor D: 0
satMin : 0
satMax : 100
---
Ich meine ja auch nicht die Faktoren, sondern die "Anteile" an actuation
my $outVal = PID_saturate($pid, $p + $i + $d);
Nur $i landete im alten Skript im Reading "integrator".
Es wäre eben interessant, wie gross die anderen Anteile sind, nämlich $p und $d.
John
achso...
Ich habe heute den PID geärgert und den Sollwert mehrmals via Heating-Control verstellen lassen.
Es handelt sich hier um eine Fussbodenheizung und ich finde er schlägt sich sehr wacker.
In den letzten 3 Stunden liegt die Abweichung im Bereich <0.3 Grad.
Das schaffen die MAX-Thermostate nicht mal bei den normalen Heizkörpern.
Die Stellvorgänge sind sehr überschaubar.
(siehe Anhang / see attachement)
John
Hallo!
Ich will mich hier auch mal einklinken. Verwende PID erst seit ca. 1,5 Wochen und bin wirklich zufrieden damit wie es funktioniert. Nächste Woche kommt mein HM-Fensterkontakt an, den ich gerne einbinden würde. Ich könnte es per notify lösen, praktische wäre es aber wenn ich direkt dem PID Modul sagen könnte welcher Fensterkontakt "überwacht" werden soll und beim öffnen dann die entsprechende Soll-Temp. setzt.
Da ihr ja gerade beim umbauen seit, könnte man das vielleicht noch mit einbauen?
Grüße
Hallo Udo,
ich verstehe einerseits den Wunsch von fhainz, den PID in die Richtung eines modernen
Heizungsthermostaten zu entwickeln ( mit Fensterkontakt-Unterstützung u.s.w).
Allerdings geht dann der universelle Ansatz des schlichten PID verloren.
Kann man den von dem MODUL PID ein Modul PID_HT (PID for Heating Thermostats) ableiten,
ohne den Quellcode doppelt pflegen zu müssen ?
Dann würde ich auch auf mein ECO und COMFORT zugunsten des PID_HT verzichten,
John
Ich habe nun ziemlich viel nachgedacht und habe eine gute und eine schlechte Nachricht.
Die gute Nachricht:
Ich verstehe sowohl den Wunsch nach "eco und comfort" als auch den Wunsch nach "Fensterkontakte überwachen".
Die schlechte Nachricht:
Ich werde beides nicht in das Modul PID einbauen.
Warum?
Beides hat grundsätzlich nichts mit der originären grundlegenden Aufgabe eines PID Reglers zu tun. Dessen Aufgabe ist es, mittels eines (beliebigen) Stellglieds, dessen Bedienung er kennt, einen Sollwert einzuregeln. Nicht mehr und nicht weniger.
Würde man jetzt Dinge wie "alphanumerische" Sollwertvorgaben und "Überwachung weiterer Sensoren, die die Funktion beeinflussen" wäre das kein universell einsetzbarer Regelkreis mehr.
Aber:
Eure beiden Wünsche sind trotzdem relativ leicht zu realisieren.
1. eco/comfort
Das ist einfach über eine Funktion in der 99_myUtils zu lösen.
sub pidTranslate($) {
my ($v) = @_;
return 17 if ($v eq "eco");
return 21 if ($v eq "comfort");
}
Der Aufruf in Heating_Control würde dann so aussehen:
define HC.BAD Heating_Control HT.BAD 00:05|eco 12345|04:15|comfort 67|06:00|comfort 12345|07:00|eco 67|10:00|eco 15:00|comfort 21:30|eco {MaxScan_SetTemp("@","%");; fhem("set PID_BAD desired pidTranslate(%)");;}
Diese Lösung hat den Vorteil, dass sich auch noch andere Werte "übersetzen" lassen, indem man einfach weitere Definitionen anlegt. Es wäre übrigens exakt der Lösungsansatz, den ich in das Modul eingebaut hätte. Aber ich finde, diese Funktion in die 99_myUtils auszulagern, gibt dem Anwender viel mehr Freiheit für eigene Definitionen.
2. Fensterkontakte überwachen
Das geht doch auch jetzt schon völlig problemlos über entsprechende notify Definitionen.
Natürlich kann man diese Erweiterungen auch in eine Art "Wrapper-Modul" verpacken, das den PID dann anspricht. Aber eine wirkliche Notwendigkeit sehe ich dafür derzeit nicht.
---
# i-anteil berechnen
# i-Anteil mit p-Anteil darf nicht groesser als 100% werden
my $i = PID_gv($pid,'integrator')+$delta*$pid->{iFactor};
$i= 100-$p if ($i > 100-$p);
# i-Anteil mit p-Anteil darf nicht kleiner als 0 werden
$i= -$p if ($i<0 && abs($i) > $p);
@John: das "warum" erschließt sich mir noch nicht ganz?
Hallo Udo,
das war der bescheidene Versuch meinerseits den
Windup-Effekt zu entgegnen.
http://de.wikipedia.org/wiki/Regler (//de.wikipedia.org/wiki/Regler)
ZitatWind-up-Effekt bei Großsignalverhalten: Wenn beim I-Regler die Stellgröße u(t) durch die Regelstrecke begrenzt wird, tritt ein Wind-up-Effekt auf. Dabei arbeitet die Integration des Reglers weiter, ohne dass die Stellgröße zunimmt. Wird die Regelabweichung e(t) kleiner, entsteht beim Rücklauf von u(t) eine ungewollte Verzögerung der Stellgröße und damit der Regelgröße y(t). Dem tritt man mit der Begrenzung der Integration auf die Stellgrößen-Grenzen entgegen (Anti-wind-up).
Als eine mögliche Anti-Wind-Up Maßnahme wird der I-Anteil bei Erreichen der Eingangsgrößenbeschränkung auf dem letzten Wert eingefroren (z.B. durch Absperrung des I-Gliedes). Wie bei jedem Begrenzungseffekt innerhalb eines dynamischen Systems verhält sich der Regler nichtlinear. Das Verhalten des Regelkreises ist durch numerische Berechnung zu prüfen. Siehe auch Artikel Regelkreis#Einfluss nichtlinearer Übertragungssysteme auf den Regelkreis mit grafischer Darstellung des Anti-Wind-up Einflusses!
Im original Skript war dies so realisiert:
my $i = PID_saturate($pid, PID_gv($pid,'integrator')+$delta*$pid->{iFactor});
Damit konnte sich ein I-Anteil von 100% aufbauen und damit theoretisch ein Überhang von 100%, wenn
gleichzeitig der p-Anteil 100% liefert.
Mein Ansatz war, dass P-Anteil und I-Anteil in Summe nicht > 100% werden sollten
und der I-Anteil wird nachrangig behandelt.
Aber ich haben nicht den Stein des Weisen. Es mag bessere Lösungen geben.
John
Danke, ich schau mir das nochmal an - ich muss das eigentliche Problem noch genauer verstehen.
Was mir im Testlauf heute aufgefallen ist:
Die actuation geht nicht auf 0, sondern bleibt immer auf 1, selbst wenn die Isttemperatur längere Zeit größer als die Solltemperatur ist.
Ich muss mal rausfinden, ob das an den Defaultwerten liegt, oder ob da noch irgendeine Sonderbehandlung eingebaut werden muss.
Ansonsten fehlt jetzt nur noch die Fehlerbehandlung für den Fall "toter Sensor". Einfach auf die definierte Error-Position fahren, solange der Sensor tot ist?
ZitatAnsonsten fehlt jetzt nur noch die Fehlerbehandlung für den Fall "toter Sensor". Einfach auf die definierte Error-Position fahren, solange der Sensor tot ist?
Es kommt auf die konkrete Anwendung an was zu tun ist.
Betrachtung der Kritizität im Fall von Raumheizung.
a. die Rohre frieren ein (auch wenn es unwahrscheinlich ist, weil es noch andere Heizkörper gibt)
b. der Raum wird unnötig überhitzt.
a. ist kritischer als b, also wäre hier eine vorgebbare Ventilposition sinnvoll.
Es gibt aber auch die sinnvolle Option, dass der Stellausgang, da wo er steht eingefroren werden soll.
Ich schlage vor beide Optionen anzubieten, dann haben wir alle Fälle abgedeckt.
John
Zitat von: John schrieb am Sa, 05 Oktober 2013 22:11Ich schlage vor beide Optionen anzubieten, dann haben wir alle Fälle abgedeckt.
zwei neue Attribute eingebaut:
pidActorErrorAction:freeze,errorPos (default:freeze)
pidActorErrorPos (default:5)
So... nach meinem Empfinden sollte nun alles eingebaut sein.
Falls jemand Lust hat zu testen - nur zu! Und bitte Rückmeldung hier im Thread.
Attribute:
pidActorErrorAction:freeze,errorPos = Verhalten im Fehlerfall (default = freeze)
pidActorErrorPos = Soll-Position im Fehlerfall (default = 5)
pidActorInterval = Mindestzeit zwischen zwei Kommandos an den Aktor (default = 600)
pidActorTreshold = Mindeständerung, ab der ein Kommando an den Aktor geschickt wird (default = 5)
pidDeltaInterval = Intervall, in dem Sensorabfrage und Berechnung durchgeführt werden (default = 60)
pidDeltaTreshold = Mindesttemperaturänderung, ab der eine Berechnung stattfindet (default = 0)
pidDesiredName = Name für Reading und in "set <name> <pidDesiredName>" (default = desired)
pidMeasuredName = Name für Reading des Ist-Wertes (default = measured)
pidParamTimeout = Zeitraum, nach der die berechneten Werte für p i d als ungültig betrachtet und neu berechnet werden (default = 3600)
pidRoundValveValue:0,1 = nur ganzzahlige Werte an actor schicken (default = undef)
pidSensorTimeout = Zeitraum, nach der ein Sensor als "tot" gemeldet wird (Reading und Logmeldung) wenn keine Aktualisierung des Messwertes erfolgt (default = 3600)
Set Befehle:
set <name> clear = löscht die berechneten Werte manuell (automatisches Löschen erfolgt, wenn älter als 1 Stunde)
set <name> <pidDesiredName> = setzt die gewünschte Temperatur
set <name> factors = wie bisher
set <name> start = startet pid
set <name> stop = stoppt pid
Dokumentation fehlt noch komplett - das weiß ich :)
Hallo Udo,
vielen Dank für deine Arbeit.
Ich werde es mir demnächst genauer ansehen.
Mir sind noch 2 Dinge eingefallen, die aber nachrangig behandelt werden können.
1. invertierter Wirksinn des Stellgliedes
Bisher hatten wir: wenn Temperatur höher werden soll, dann Ventil weiter öffnen .
Es gibt aber auch den umgekehrten Fall: z.B Regeln der Geschwindigkeit durch Bremsen
Wenn wir schneller werden wollen, dann weniger bremsen.
(sollte mit dem Invertieren des Vorzeichens von delta erledigt sein)
2. Dynamische Adaption des Stellgliedes beim Aufstarten
Nach dem bisherigen Ansatz bestimmt der Regler "patriachalisch" den I-Anteil und verwendet beim Neustart
einfach den zuletzt in den Readings abgelegten Wert.
Es gibt auch sinnvolle Anwendungen, in denen er sich nach dem Starten einmalig vom Stellglied den aktuellen Wert holt
und damit seinen I-Anteil initial berechnet.
Damit fährt er "sprungfrei" das Stellglied weiter und holt es dort ab wo es steht.
John
1. Werde ich so umsetzen, dass die Min und Max des Stellglieds dann als 100:0 im define angegeben werden. In der Doku werde ich die Werte dann als Start und Stop beschreiben.
2. Funktioniert nicht, da es nicht zu allen Stellgliedern eine zuverlässige Methode der Abfrage gibt.
Hallo!
szStellventil zeigt immer nur defined an und die szHeizung springt hin und wieder auf pauset.
define szStellventil FHT8V 1234
attr szStellventil alias Stellventil
attr szStellventil group Heizung
attr szStellventil icon sani_heating
attr szStellventil room 2_Schlafzimmer
define szHeizung PID Schlafzimmer szStellventil
attr szHeizung alias Temperatur
attr szHeizung group Heizung
attr szHeizung icon temp_temperature
attr szHeizung room 2_Schlafzimmer
Hab ich noch etwas vergessen zu definieren?
Grüße
Guten Tag,
hier würde ich mich als potentieller Tester mal einklinken: sehe ich das doch richtig, dass Homematic Sensoren/Aktoren noch nicht unterstützt werden?
Ich erhalte für ein:
define PID_Suedzimmer PID CC_Suedzimmer:measured-temp Aktor_Suedzimmer
PID_Suedzimmer: Unknown sensor type CUL_HM, specify regexp
Das finde ich schade, weil ich da Bedarf hätte :-)
Christian
Du kannst verwenden, was Du willst (funktioniert sogar mit einem dummy), solange Du DIch beim define an die vorgegebene Syntax hältst, wie sie in der commandref steht.
Und Dein Fehler wird Dir ja im Klartext angegeben: Du hast keine regexp angegeben.
Zitat von: fhainz schrieb am So, 06 Oktober 2013 19:42szStellventil zeigt immer nur defined an und die szHeizung springt hin und wieder auf pauset.
Hab ich noch etwas vergessen zu definieren?
szStellventil ist aber schon mit fhem gepaired, oder? "Paused" beim PID bedeutet, dass die Solltemperatur erreicht ist und deshalb keine Regelung stattfindet.
Zitat von: betateilchen schrieb am So, 06 Oktober 2013 16:251. Werde ich so umsetzen, dass die Min und Max des Stellglieds dann als 100:0 im define angegeben werden. In der Doku werde ich die Werte dann als Start und Stop beschreiben.
Ganz so einfach spontan gedacht funktioniert es dann doch nicht...
Hab vorhin gesehen das am Ventil 30% steht. Anscheinend hat es heute Nachmittag beim rumprobieren 1h die Verbindung verloren und ging in den Notbetrieb. Hab schon ein paar mal versucht neu zu pairen aber das antennensymbol blinkt immer noch.
Hast du einen Tipp?
Grüße
Hat das Ventil beim Pairen gepiept? Wenn ja, blinkt das Antennensymbol so lange, bis es einen Befehl bekommt. Schick halt mal irgendeinen Stellbefehl über die Kommandozeile ab.
Beim pairen hat's gepiepst ja. Nach dem direkten befehl senden hat da antennensymbol aufgehört zu blinken. Ich denke jetzt funktionierte. Ich warte nur noch das die 20% die ich gesendet hab wieder runter auf 0 gehen. SollTemp aktuell < IstTemp.
Eine frage hab ich noch. Wann muss ich PID mit set <name> start starten?
Grüße
Wenn Du ihn vorher mit set <name> stop angehalten hast :)
Normalerweise startet der PID, wenn eine desired-Temperatur eingestellt wird. Die Autostart-Option (z.B. nach einem reload oder einem fhem-Restart) habe ich noch nicht eingebaut.
Ok alles klar, danke ;)
Ich starte zur sicherheit mal, in den letzten paar minuten hat sich noch nichts getan.
Das Modul hat noch einen Bug: Wenn die Pause wegen Überschreiten der Solltemperatur länger dauert als die Zeit, in der der Sensor eine Kommunikation erwartet, bevor er auf Notbetrieb geht, gibts ein Problem. Das werde ich noch abfangen, aber heute hab ich keine Lust mehr. Hab grade 6 Stunden Bahnfahrt hinter mir.
Moin,
bin neu im Forum, verfolge aber seit einiger Zeit die Entwicklung mit stetig steigendem Interesse.
Ich habe just mal das neue 98_PID-Modul getestet und die Meldung "unknown attribute disable" erhalten.
Ist die Möglichkeit, das PID-Device zu disablen weggefallen?
Ich fände es schade, da so eine einfache Möglichkeit bestand, zwischen Sommer und Winterbetrieb zu wechseln.
Ansonsten: Klasse Job (auch wenn ich die internen Funktionen des Reglers bislang nicht mal annähernd durchschaue :))
Hans
Hallo Udo,
ich vermisse das Anti-Wind-Up in Richtung SatMin.
Hab ich was übersehen ?
John
Zitat von: Hans Franz schrieb am Mo, 07 Oktober 2013 11:10Ist die Möglichkeit, das PID-Device zu disablen weggefallen?
Gibt es nicht mehr als Attribut, sondern als "set <name> stop"
Zitat von: John schrieb am Mo, 07 Oktober 2013 11:15ich vermisse das Anti-Wind-Up in Richtung SatMin.
öh... sollte eigentlich drinsein.
Zeile 304: $i= -$p if ($i < $hash->{helper}{satMin} && abs($i) > $p);
Hallo Udo,
im Log noch eine (klitze)kleine Unschönheit:
Readings:
desired 20.0
measured 20.4
Log:
paused - delta: -0.399999999999999
Scheint nur bei einer Differenz <1 vorzukommen.
Hans
Da kann ich nix für, das kommt von perl :) ich subtrahiere einfach nur die beiden Werte.
Wenn ich jetzt anfange zu runden, kommt der Nächste und jammert "ich will es aber mit allen Nachkommastellen haben" zumal mit diesen Werten ja auch weitergerechnet wird.
Zitat von: Hans Franz schrieb am Mo, 07 Oktober 2013 11:10Ich fände es schade, da so eine einfache Möglichkeit bestand, zwischen Sommer und Winterbetrieb zu wechseln.
Wenn der PID aber gar nicht läuft, hast Du spätestens nach zwei Stunden ein Problem, z.B. mit einem FHT8V, der dann seine Synchronisation verliert, weil niemand mehr mit ihm spricht und dann auf Notbetrieb geht und das Ventil auf 30% aufdreht.
Einfachste Lösung für Sommerbetrieb: Stell die desired-temp auf 10° ein :)
Yeap,
Pragmatische Lösung für Sommerbetrieb, danke dir.
Die Nachkommastelen sind wirklich schnurz.
Hans
Naja schön sind die 10 Nachkommastellen auch nicht. Hab mich auch schon gefragt ob man die selbst auf 1 stelle runden kann?
Das könnte man schon, aber im Modul selbst wird ja z.B. mit solchen Sachen wie "65/2.55" gerechnet, die dann wieder mit solchen krummen Zahlenwerten multipliziert werden.
Und ausserdem ist das doch nur Optik - mit dem Wert selbst wirst Du doch als Anwender nie etwas wichtiges bewerkstelligen. Und wenn doch, kannst Du ihn ja in Deiner eigenen Anwendung dann runden.
Das hab ich gemeint, ob man die Ausgabe "selbst" runden kann. ;)
Das das modul mit den ganzen zahlen rechen muss ist klar.
Ich denk mal drüber nach, ob mir was elegantes einfällt. Eine Idee hab ich immerhin schon.
Hallo!
Da bisher das Ventil immer noch nicht auf das PID Modul gehört hat, hab ich nochmal die alte Version eingespielt. Neugestartet und schon wurde mir der richtige Stellwert angezeigt und hat auch aufs Modul gehört. Wieder deine Version eingespielt und wieder stand defined da. Sollwert schicken hat nichts gebracht. Direkter Wert hat geklappt, aber wird nicht mehr durch PID zurückgeregelt.
Hat noch jemand mit einem FHT 8V Ventil getestet?
Grüße
Edit:
actuation im Modul ist auf 63% aber das Ventil rührt sich nicht.
Zitat von: fhainz schrieb am Mo, 07 Oktober 2013 17:50Hallo!
Hat noch jemand mit einem FHT 8V Ventil getestet?
Das kann ich leider bestätigen :(.
Außerdem:
2013.10.07 18:28:08 3: PID heizung.04: paused - delta: -3
2013.10.07 18:30:33 3: PID heizung.04: set heizung.04 desired 25
2013.10.07 18:35:35 2: PID heizung.04: outdated readings deleted
Seitdem kein Log-Eintrag von heizung.04 mehr.
Wenn sich outdated auf den Temp.-Sensor bezieht, hier der Auszug aus dem Log:
2013-10-07_18:30:52 CUL_WS_5 T: 18.0 H: 75.3 D: 13.6
2013-10-07_18:33:47 CUL_WS_5 T: 17.9 H: 75.3 D: 13.5
Edit:
Nach Herabsetzen von desired:
2013.10.07 19:05:10 3: PID heizung.04: set heizung.04 desired 15
2013.10.07 19:05:10 3: PID heizung.04: paused - delta: -2.9
2013.10.07 19:06:11 3: PID heizung.04: paused - delta: -2.9
2013.10.07 19:07:11 3: PID heizung.04: paused - delta: -2.9
2013.10.07 19:08:11 3: PID heizung.04: paused - delta: -2.9
Hans
äh... irgendwie versteh ich das Problem grade nicht. (Ja, ich habe erfolgreich mit einem FHT8V getestet, aber welcher Stellantrieb verwendet wird, ist wurscht, es funktioniert sogar mit einem Dummy).
2013.10.07 18:28:08 3: PID heizung.04: paused - delta: -3
2013.10.07 18:30:33 3: PID heizung.04: set heizung.04 desired 25
2013.10.07 18:35:35 2: PID heizung.04: outdated readings deleted
Der PID steht auf paused, weil die Ist-Temperatur 3 Grad höher ist als die Solltemperatur. Was soll der PID da regeln?
Die paused-Meldung sollte sich im Log wiederholen, und zwar im Abstand von "pidDeltaInterval".
Zitat von: betateilchen schrieb am Mo, 07 Oktober 2013 19:05Der PID steht auf paused, weil die Ist-Temperatur 3 Grad höher ist als die Solltemperatur. Was soll der PID da regeln?
Die desired um 18:30 auf 25 Grad erhöht (gemessen 18 Grad), dann keine Logeinträge mehr bis desired wieder kleiner als gemessene Temperatur.
Oder verstehe ich etwas grundsätzlich falsch?
Hans
mach mal bitte ein "list <pidName>" und poste die Ausgabe hier.
(siehe Anhang / see attachement)
Teste mal diese Version hier im Anhang.
Gerne:
Internals:
DEF CUL_WS_5 stellantrieb.04
NAME heizung.04
NR 360
STATE 17.8 (delta 2.2)
TYPE PID
Readings:
2013-10-07 19:41:17 actuation 70
2013-10-07 19:41:17 delta 2.2
2013-10-07 19:39:16 desired 20
2013-10-07 19:36:34 integrator 0
2013-10-07 19:41:17 measured 17.8
2013-10-07 19:41:17 p_d 7.05882352941176
2013-10-07 19:41:17 p_i 7.72941176470588
2013-10-07 19:41:17 p_p 56.078431372549
2013-10-07 19:41:17 sensorState alive
2013-10-07 19:41:17 state active
Helper:
actor stellantrieb.04
command valve
dFactor 5.88235294117647
errorState
iFactor 3.05882352941176
pFactor 25.4901960784314
reading temperature
regexp ([\d\.]*)
satMax 100
satMin 0
sensor CUL_WS_5
Attributes:
alias Heizungen_4
pidActorTreshold 2
room Heizungen
Ich habe einfach nur das PID-Modul getauscht, ohne attributes zu setzen (jetzt gerade erst pidActorTreshold).
Könnte hier der Fehler liegen?
Nein, das Modul läuft auch komplett ohne gesetzte Attribute. Siehe meinen Screenshot von eben.
Hallo,
auch mit der neuen Version Logeinträge nur bei negativem Delta und keine Befehle an Stellantriebe.
Hans
keine Ahnung was Du da machst.
Bei mir im Log passiert folgendes:
2013.10.07 20:02:47 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:03:47 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:04:48 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:05:48 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:06:48 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:07:48 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:08:49 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:09:49 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:10:49 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:11:49 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:12:49 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:13:50 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:14:50 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:15:50 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:16:51 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:17:51 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:18:51 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:19:51 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:20:52 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:21:52 3: PID ku_FHT: paused - delta: -7.2
2013.10.07 20:21:52 3: PID ku_FHT: send keepAlive
2013.10.07 20:21:52 3: FHT8V set ku_Ventil valve 0
Solange der PID pausiert, erfolgt jede Minute ein Logeintrag, aber ansonsten keine Aktion.
Spätestens nach 30 Minuten wird ein keepAlive Befehl an das Stellventil gesendet.
Und genau so ist das auch gedacht.
Auch mit der neuen Version rührt sicher das Ventil nicht. Hab auch nochmal neu gepaired. Pipser wie immer erhalten und Soll-Temp. hoch gesetzt aber nichts passiert.
Internals:
DEF Schlafzimmer szStellventil
NAME szHeizung
NR 254
STATE 18.4 (delta 1.6)
TYPE PID
Readings:
2013-10-07 21:13:24 actuation 50
2013-10-07 21:13:24 delta 1.6
2013-10-07 21:08:21 desired 20
2013-10-07 20:50:25 integrator 0
2013-10-07 21:13:24 measured 18.4
2013-10-07 21:13:24 p_d 3.52941176470589
2013-10-07 21:13:24 p_i 5.89411764705883
2013-10-07 21:13:24 p_p 40.7843137254902
2013-10-07 21:13:24 sensorState alive
2013-10-07 21:13:24 state active
Helper:
actor szStellventil
command valve
dFactor 5.88235294117647
errorState
iFactor 3.05882352941176
pFactor 25.4901960784314
pausedSince 0
reading temperature
regexp ([\d\.]*)
satMax 100
satMin 0
sensor Schlafzimmer
Attributes:
alias Temperatur
group Heizung
icon temp_temperature
room 2_Schlafzimmer
Edit:
Hier auch mal meine Defines:
define szStellventil FHT8V 1234
attr szStellventil alias Stellventil
attr szStellventil group Heizung
attr szStellventil icon sani_heating
attr szStellventil room 2_Schlafzimmer
define szHeizung PID Schlafzimmer szStellventil
attr szHeizung alias Temperatur
attr szHeizung group Heizung
attr szHeizung icon temp_temperature
attr szHeizung room 2_Schlafzimmer
define szHeizungDesiredTemp dummy
attr szHeizungDesiredTemp alias Temperatur Sollwert
attr szHeizungDesiredTemp group Heizung
attr szHeizungDesiredTemp icon temp_control
attr szHeizungDesiredTemp room 2_Schlafzimmer
attr szHeizungDesiredTemp setList state:17,17.5,18,18.5,19,19.5,20,20.5,21,21.5,22
attr szHeizungDesiredTemp webCmd state
define nSzHeizung notify szHeizungDesiredTemp {\
my $neuer_wert = ReadingsVal("szHeizungDesiredTemp","state","0") ;;\
fhem("set szHeizung desired $neuer_wert");;\
}
*grübel* ich habe jetzt zumindest verstanden, was das Problem ist. Ich mach mich mal auf die Suche :)
EDIT: Ich habe den Fehler gefunden, aber noch nicht seine Ursache...
Bitte testen :)
Die letzte Version zeigt das gleiche Verhalten.:(
Ich habe mal $aDiff und $pAT mitprotokolliert.
Bei mir bleibt $aDiff auf 0.
Somit wird $aDiff >= $pAT wohl nicht wahr.
Hans
lösche mal das Attribut pidActorTreshold
Hi Udo
delta kann positiv u. negativ werden.
ZitatHallo,
auch mit der neuen Version Logeinträge nur bei negativem Delta und keine Befehle an Stellantriebe.
Hans
if($delta >= AttrVal($name,'pidDeltaTreshold','0')) {
John
ja, das ist aber im Moment nicht das Problem.
Zitat von: betateilchen schrieb am Mo, 07 Oktober 2013 23:46lösche mal das Attribut pidActorTreshold
Tata,
2013.10.07 23:50:46 3: aDiff:0 pAT:0 tDiff:4.38690185546875e-05 pAI:0
2013.10.07 23:50:46 3: PID heizung.04: set stellantrieb.04 valve 98
Das sieht doch schon besser aus.
Aber wieso ist
$aDIFF immer 0?
Weil der Stellantrieb noch nie gestellt wurde. Eigentlich sollte das JETZT nicht mehr 0 sein.
Nochmal,
wenn der Istwert goesser als der Sollwert ist, dann geht der Regler in Pause, da Delta negativ wird.
Das ist nun wirklich ein Problem oder ?
Wie wärs mit
if(abs($delta) >= AttrVal($name,'pidDeltaTreshold','0')) {
Dann sind wohl auch die anderen Probleme mit der Stellausgabe gelöst.
John
Zitat von: betateilchen schrieb am Mo, 07 Oktober 2013 23:54Weil der Stellantrieb noch nie gestellt wurde. Eigentlich sollte das JETZT nicht mehr 0 sein.
Leider doch:
2013.10.07 23:53:48 3: PID heizung.04: set stellantrieb.04 valve 98
2013.10.07 23:53:48 3: FHT8V set stellantrieb.04 valve 98
2013.10.07 23:53:48 3: get stellantrieb.04 valve : 97
2013.10.07 23:53:48 3: PID heizung.04: set heizung.04 desired 21
2013.10.07 23:53:49 3: aDiff:0 pAT:0 tDiff:60.8145229816437 pAI:0
2013.10.07 23:53:49 3: PID heizung.04: set stellantrieb.04 valve 98
2013.10.07 23:53:49 3: FHT8V set stellantrieb.04 valve 98
2013.10.07 23:54:49 3: aDiff:0 pAT:0 tDiff:60.3309800624847 pAI:0
2013.10.07 23:54:49 3: PID heizung.04: set stellantrieb.04 valve 98
2013.10.07 23:54:49 3: FHT8V set stellantrieb.04 valve 98
2013.10.07 23:54:49 3: get stellantrieb.04 valve : 97
2013.10.07 23:54:49 3: PID heizung.04: set heizung.04 desired 21
2013.10.07 23:54:50 3: aDiff:0 pAT:0 tDiff:60.8117101192474 pAI:0
2013.10.07 23:54:50 3: PID heizung.04: set stellantrieb.04 valve 98
2013.10.07 23:54:50 3: FHT8V set stellantrieb.04 valve 98
2013.10.07 23:55:50 3: aDiff:0 pAT:0 tDiff:60.3267669677734 pAI:0
2013.10.07 23:55:50 3: PID heizung.04: set stellantrieb.04 valve 98
2013.10.07 23:55:50 3: FHT8V set stellantrieb.04 valve 98
2013.10.07 23:55:50 3: get stellantrieb.04 valve : 97
2013.10.07 23:55:50 3: PID heizung.04: set heizung.04 desired 21
2013.10.07 23:55:51 3: aDiff:0 pAT:0 tDiff:60.8101971149445 pAI:0
2013.10.07 23:55:51 3: PID heizung.04: set stellantrieb.04 valve 98
2013.10.07 23:55:51 3: FHT8V set stellantrieb.04 valve 98
2013.10.07 23:56:51 3: aDiff:0 pAT:0 tDiff:60.3250930309296 pAI:0
2013.10.07 23:56:51 3: PID heizung.04: set stellantrieb.04 valve 98
2013.10.07 23:56:51 3: FHT8V set stellantrieb.04 valve 98
Wenn schon, dann bitte so: if(abs($delta) >= abs(AttrVal($name,'pidDeltaTreshold','0'))) {
Aber um dieses Thema geht es gerade überhaupt nicht!
Zitat von: Hans Franz schrieb am Di, 08 Oktober 2013 00:06Leider doch:
Mach nochmal bitte ein "list <pidName>"
Internals:
DEF CUL_WS_5 stellantrieb.04
NAME heizung.04
NR 360
STATE 18.8 (delta 1.2)
TYPE PID
Readings:
2013-10-08 00:15:51 actuation 0
2013-10-08 00:15:51 delta 0
2013-10-08 00:16:45 desired 20
2013-10-08 00:15:51 integrator 0
2013-10-08 00:21:47 measured 18.8
2013-10-07 22:57:21 p_d 16.4705882352941
2013-10-07 22:57:21 p_i 3.13725490196076
2013-10-07 22:57:21 p_p 96.8627450980392
2013-10-08 00:21:46 sensorState alive
2013-10-08 00:21:47 state paused
Helper:
actor stellantrieb.04
command valve
dFactor 5.88235294117647
errorState
iFactor 3.05882352941176
pFactor 25.4901960784314
pausedSince 1381184151.72795
reading temperature
regexp ([\d\.]*)
satMax 100
satMin 0
sensor CUL_WS_5
Attributes:
alias Heizungen_4
room Heizungen
setActor wird niemals aufgerufen solange {lastActVal} nicht definiert ist.
my $aDiff = 0;
$aDiff = abs($a - $hash->{helper}{lastActVal}) if($hash->{helper}{lastActVal});
.....
if($aDiff >= $pAT && $tDiff >= $pAI) {
# send command to actor
setActor($hash,$a);
}
damit bleibt aDiff dauerhaft auf 0.
lastActVal wird aber nur in setActor aktualisiert.
if(abs($delta) >= AttrVal($name,'pidDeltaTreshold','0')) {
führt zu
Use of uninitialized value $i in numeric gt (>) at ./FHEM/98_PID.pm line 305.
Use of uninitialized value $i in numeric lt (<) at ./FHEM/98_PID.pm line 306.
Use of uninitialized value $i in addition (+) at ./FHEM/98_PID.pm line 309.
Use of uninitialized value $a in int at ./FHEM/98_PID.pm line 310.
Use of uninitialized value $i in int at ./FHEM/98_PID.pm line 310.
Use of uninitialized value $i in sprintf at ./FHEM/98_PID.pm line 312.
also wieder rausgeschmissen.
dennoch jetzt:
Use of uninitialized value $a in int at ./FHEM/98_PID.pm line 310.
Use of uninitialized value $a in sprintf at ./FHEM/98_PID.pm line 312.
Use of uninitialized value $a in int at ./FHEM/98_PID.pm line 316.
Ich blick' den Code leider überhaupt noch nicht:(.
(heizung.04 ist mein Schlafzimmer. Ich geh' erst mal lüften :).)
Moin. Ich hab grad keine Lust mehr.
Lasst mich doch einfach mal in Ruhe einen Fehler suchen, anstatt hier durch sinnlose Code-Basteleien, die scheitern
müssen den Thread noch unübersichtlicher zu machen, als er sowieso schon ist.
Zitat von: John schrieb am Di, 08 Oktober 2013 00:27setActor wird niemals aufgerufen solange {lastActVal} nicht definiert ist.
Diese Aussage ist so schlichtweg
falsch.
Moin,
lastActVal ist nun intialisiert, wieso auch immer.
Wenn desired grösser ist als measured wird das Ventil auch geöffnet. Alles OK.
Aber wenn desired kleiner als measured (negatives Delta) bleiben actuation und Delta in den Readings auf den alten Werten.
Das Ventil wird nicht geschlossen.
Zitat von: Hans Franz schrieb am Di, 08 Oktober 2013 09:51Aber wenn desired kleiner als measured (negatives Delta) bleiben actuation und Delta in den Readings auf den alten Werten.
Das Ventil wird nicht geschlossen.
Ja, ich weiß...
Bis auf den negatives Delta Fehler funktioniert's jetzt bei mir. :)
kommt alles, aber wahrscheinlich erst am nächsten Wochenende.
Hallo Udo,
sorry, wenn meine Kommentare im Forum mehr Stress als Hilfe für dich waren.
Ich habe dein letztes Skript nun bei mir eingespielt und einige Fixes/Anmerkungen eingetragen.
(#jjj als Marker)
Einige Fragmente konnte ich nicht nachvollziehen.
Anpassungen:
"pidReverseAction " invertierter Wirksinn;
geändertes Handling bei wind-up am unteren Stellbereich.
erstmalige Ausgabe Actuation sicherstellen
Vielleicht hilft es deine Einsatzzeit am Samstag zu verkürzen.
Noch eine Frage
PID startet nicht automatisch. Was ist hier der Plan ?
beste Grüße
John
Hallo John, danke für Deine Unterstützung.
ZitatPID startet nicht automatisch. Was ist hier der Plan ?
Den Autostart hatte ich schon in meiner hiesigen Version (die noch nicht im Forum war) eingebaut.
Zitat"pidReverseAction " invertierter Wirksinn;
geändertes Handling bei wind-up am unteren Stellbereich.
erstmalige Ausgabe Actuation sicherstellen
Habe ich jetzt erstmal so übernommen.
ZitatEinige Fragmente konnte ich nicht nachvollziehen.
Das waren fast alles Dinge, die ich aus dem Originalmodul übernommen hatte.
Schau Dir bitte das angehängte Modul nochmal an, ich habe da auch noch ein paar Kommentare zu Deinen Fragen eingefügt. Wenn Du das so ok findest, werde ich noch die Doku dazu machen und ein paar unserer Kommentare entfernen, bevor ich es dann einchecke.
Übrigens - Du verwendest scheinbar einen sehr abstrusen Editor, von Sonderzeichen hat der irgendwie noch nie was gehört.
Hallo Udo,
besten dank für das überarbeitete Modul.
Anti-Wind_Up-StrategieIch hab mir in den vergangenen Tagen nochmal die Anti-WindUp Strategie vorgenommen
und meine, diese muss geändert werden.
Folgendes konnte ich (wenn auch unter exotischen Bedingungen) produzieren.
Zitatdesired=0
2013-10-09_23:47:26 PID.BAD temperature: 21
2013-10-09_23:47:26 PID.BAD actuation: 0
2013-10-09_23:47:26 PID.BAD delta: -21.0
2013-10-09_23:47:26 PID.BAD p_i: 735
2013-10-09_23:47:26 PID.BAD p_p: -735
desired=20
2013-10-09_23:47:28 PID.BAD temperature: 21
2013-10-09_23:47:29 PID.BAD actuation: 100 <----
2013-10-09_23:47:29 PID.BAD delta: -1.0 <----
2013-10-09_23:47:29 PID.BAD p_i: 135
2013-10-09_23:47:29 PID.BAD p_p: -35
Das Ventil macht zu 100 % auf, obwohl wir unter dem Sollwert liegen.
Der Effekt ist auf die Anti-windup-Strategie zurückzuführen.
Ich bin auf die Suche gegangen und habe folgende mir plausibel erscheinende Realisierung gefunden,
die ich die letzten Tage mit meinem "alten" Modul getestet habe.
my $isWindup = ( $delta >0 && $actuationLast>$satMax) ||( $delta <0 && $actuationLast<$satMin);
if (! $isWindup) # nur weiter integrieren, wenn kein windUP
{
$i = $i + $delta * $pid->{iFactor};
$pid->{windUP}=0;
}
else {
$pid->{windUP}=1;
}
XPID_sv($pid, 'integrator', $i);
Den Vorschlag habe ich hier
http://www.mikrocontroller.net/topic/82685 (http://www.mikrocontroller.net/topic/82685)
gefunden und leicht abgeändert.
Idee:1. actuation wird nicht begrenzt, nur die Ausgabe an das Stellglied wird begrenzt
2. wenn actuation die Stellgrenzen beim letzten Scan verletzt hat,
wird das Integrieren des I-Anteils beim aktuellen Scan gestoppt. (isWindup=1)
Hat sich die letzten 2 Tage gut bewährt.
Gefällt mir auch vom Ansatz her gut.
Code-FragmentDer Sinn diese Fragments leuchtet mir trotz deiner Erklärung nicht ein.
$a = (int($a) == int($i)) ? $hash->{helper}{satMin} : $a; #jjj unklar warum
# bt weil der Aktor sonst auf != 0 stehenbleiben kann.
Der Fall tritt nur ein, wenn $d=0 und $p=0
oder
wenn $d=-$p
warum muss man dann $a auf satMin zwingen ?
D-AnteilIch verwende zwar den D-Anteil praktisch nicht,
aber ich glaube dass die derzeitige Umsetzung technisch falsch ist.
Gründe:Das Modul war zuvor vom Sensor getrieben (wir wissen das hat Nachteile),
damit hatte der D-Anteil seine natürliche Zeitbasis, nämlich die der physischen Werteänderung.
Das ist mit dem Timer-gesteuerten Treiber nun anders.
Das Sende-Intervall des Sensors muss nicht mit der des Timers übereinstimmen.
ZitatSensor-Scan A
PID-Scan Delta 1
PID-Scan Delta 2
PID-Scan Delta 3 (muss 0 sein, da wir keinen neuen Istwert haben)
Sensor-Scan B
Delta 2 - Delta 1 ist immer 0 (Istwert hat sich nicht geändert)
Delta 3 - Delta 2 ist immer 0 (Istwert hat sich nicht geändert)
Damit liefert Delta 1 einen Peak, der sofort wieder verschwindet (Delta 2,3) ohne physische Berechtigung.
Ich denke man müsste Delta1 merken und bis zum nächsten SensorScan in der PID-Verrechnung verwenden.
Somit müssten wir für den D-Anteil ein eigenständiges Delta mitführen.
Vielleicht ist auch ein anderer Algorithmus möglich, aber der aktuelle scheint mir nicht zu passen.
John
ZitatDer Sinn diese Fragments leuchtet mir trotz deiner Erklärung nicht ein.
...
Der Fall tritt nur ein, wenn $d=0 und $p=0
oder
wenn $d=-$p
warum muss man dann $a auf satMin zwingen ?
Bei mir trat der Fall auf, dass der erste Fall auftrat und der $a auf 1 stehenblieb, was dazu führte, dass das Heizkörperventil auf 1% steheblieb anstatt komplett zu schließen. Und bei 1% machen meine Heizkörper schon ganz schön warm.
Zu Deinen anderen Vorschlägen:
Ich habe mich noch nicht mit dem technischen Hintergrund der PID-Berechnung selbst befasst. Wenn Du da tiefer drin bist, und irgendwelche (funktionierenden) Verbesserungen hast, baue ich die gerne in das Modul ein. Im Moment habe ich etwas wenig Zeit, mich auch noch mit der Theroie des PID zu befassen :(
Viele Grüße
Udo
Hi Uli
Beispiel im Code
Log3 $pn, 2, $msg;
sollte es nicht besser so heissen ?
Log3 $hash, 2, $msg;
mit
sub
Log3($$$)
{
my ($dev, $loglevel, $text) = @_;
$dev = $dev->{NAME} if(defined($dev) && ref($dev) eq "HASH");
John
Log3 kann mit mit beidem korrekt umgehen (sowohl $name als auch $hash) aber was hat das mit dem PID zu tun? Und wo nimmst Du den Uli her?
Moin,
Danke für die Optimierung des Moduls.
Ich habe mir erlaubt es zu testen und erhalte:
2013.10.13 11:51:41 3: set stellantrieb.02 valve 5.22458e-15 : Set valve needs a numeric parameter between 0 and 100
2013.10.13 11:51:41 2: PID heizung.02: response: Set valve needs a numeric parameter between 0 and 100
Muss ich vor dem Testen noch eine Säuberungsaktion ausführen?
Hans
Hallo Hans
vesuchs mit
attr <pidName> pidRoundValveValue 1
Das sollte den Ausgabewert an das Stellglied auf eine Ganzzahl runden.
John
Hallo John,
Danke, das wars.
Moin,
Wenn ich den PID-Regler zur Heizungsteuerung einsetze (direktes Ansteuern von FHT8V), wie setze ich dann die Attribute möglichst sinnvoll?
Im Moment (keine Attribute außer pidRoundValveValue gesetzt), ergeben sich extreme Sprünge:
2013.10.15 13:42:51 3: PID heizung.02: set stellantrieb.02 valve 99
2013.10.15 13:42:51 3: FHT8V set stellantrieb.02 valve 99
2013.10.15 13:42:51 3: get stellantrieb.02 valve : 98
2013.10.15 13:42:51 3: PID heizung.02: set stellantrieb.02 valve 99
2013.10.15 13:42:51 3: FHT8V set stellantrieb.02 valve 99
2013.10.15 13:43:53 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:43:53 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:43:54 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:43:54 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:44:54 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:44:54 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:44:55 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:44:55 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:45:55 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:45:55 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:45:56 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:45:56 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:47:01 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:47:01 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:47:01 3: PID heizung.02: set stellantrieb.02 valve 0
2013.10.15 13:47:01 3: FHT8V set stellantrieb.02 valve 0
2013.10.15 13:48:02 3: PID heizung.02: set stellantrieb.02 valve 95
2013.10.15 13:48:02 3: FHT8V set stellantrieb.02 valve 95
2013.10.15 13:48:02 3: get stellantrieb.02 valve : 94
2013.10.15 13:48:02 3: PID heizung.02: set stellantrieb.02 valve 95
2013.10.15 13:48:02 3: FHT8V set stellantrieb.02 valve 95
2013.10.15 13:49:03 3: PID heizung.02: set stellantrieb.02 valve 97
2013.10.15 13:49:03 3: FHT8V set stellantrieb.02 valve 97
2013.10.15 13:49:03 3: get stellantrieb.02 valve : 96
Gruss
Hans
Hallo Hans,
ich bin gerade dran die Innereien des Moduls neu zu organisieren.
Ich bitte dich daher noch um etwas Geduld.
John
Das kann ich auch bestätigen. PID rechnet den Stellwert richtig, FHT8V stellt aber immer auf 100 bzw 0%.
Grüße
1. reden wir über die Modulversion, die am Wochenende hier im Thread angehängt wurde?
2. was steht in den Readings selbst?
Zitat von: betateilchen am 15 Oktober 2013, 16:17:40
1. reden wir über die Modulversion, die am Wochenende hier im Thread angehängt wurde?
2. was steht in den Readings selbst?
zu 1: ja klar :)
zu 2: ich habe gerade mal ein neues Log-File angelegt. Habe bisher nur desired,measured und actuation gelogt.
Bericht folgt.
Gruss
Hans
Zitat von: betateilchen am 15 Oktober 2013, 16:17:40
1. reden wir über die Modulversion, die am Wochenende hier im Thread angehängt wurde?
2. was steht in den Readings selbst?
1: Ja
2:
ZitatReadings:
2013-10-15 17:59:11 actuation 7.83686840911875e-15
2013-10-15 17:59:11 delta -1.4
2013-10-15 16:56:44 desired 17
2013-10-12 21:11:14 integrator 0
2013-10-15 17:59:11 measured 18.4
2013-10-08 17:38:33 measured-temp 18.4
2013-10-15 17:59:11 p_d 7.83686840911875e-15
2013-10-15 17:59:11 p_i 35.6862745098039
2013-10-15 17:59:11 p_p -35.6862745098039
2013-10-15 17:59:10 sensorState alive
2013-10-15 17:59:11 state active
Grüße
Zitatzu 2: ich habe gerade mal ein neues Log-File angelegt. Habe bisher nur desired,measured und actuation gelogt.
Bericht folgt.
Mich interessiert nicht das Logfile, sondern die Readings in der Detailansicht, so wie fhainz sie dankenswerterweise gepostet hat.
Irgendwann gab es eine Version, die auf Kommastellen begrenzt war.
(Nebenbemerkung: Wer FHT8V nutzt, MUSS das Attribut pidRoundValveValue setzen, sonst gibt es eine Fehlermeldung, weil der Stellantrieb nur ganzzahlige Werte nimmt)
Ich warte mal ab, was John im Moment bastelt, dann können wir nochmal schauen, wo es klemmt.
Wir kriegen das schon zum Laufen :)
Zitat von: betateilchen am 15 Oktober 2013, 19:35:28(Nebenbemerkung: Wer FHT8V nutzt, MUSS das Attribut pidRoundValveValue setzen, sonst gibt es eine Fehlermeldung, weil der Stellantrieb nur ganzzahlige Werte nimmt)
Ich denke das wars! Nachdem ich das Attribut gesetzt hab, zeigt jetzt das Stellventil den gleichen Stellwert wie das Modul! Ich beobachte das heute Abend noch aber ich denke jetzt klappts endgültig :)
Grüße
Zitat von: betateilchen am 15 Oktober 2013, 19:35:28
Mich interessiert nicht das Logfile, sondern die Readings in der Detailansicht
Ach so,
Ich dachte, die Werte zum Zeitpunkt der extremen Sprünge seien die wichtigen.
Egal, ich lass noch eine Zeit mitlaufen.
Gruss
Hans
Hallo John,
ich habe jetzt noch ein paar Verbesserungen in der "internen Verwaltung" innerhalb des Moduls eingebaut, z.B. wird bei einem Antrieb vom Typ FHT8V das Runden der Ventilwerte vor der Übertragung automatisch aktiviert und es werden redundante Events unterdrückt.
Hast Du noch grundlegende Änderungen in der PID-Logik in der Pipeline oder kann ich das Modul jetzt um die Doku ergänzen und dann einchecken?
Viele Grüße
Udo
Hallo Udo,
Zitat von: betateilchen am 20 Oktober 2013, 21:16:15
ich habe jetzt noch ein paar Verbesserungen in der "internen Verwaltung" innerhalb des Moduls eingebaut, z.B. wird bei einem Antrieb vom Typ FHT8V das Runden der Ventilwerte vor der Übertragung automatisch aktiviert und es werden redundante Events unterdrückt.
Ich plädiere dafür, alle proprietären Sonderlösungen die antriebs-sensorbezogen sind komplett rauszunehmen.
Stattdessen sollten wir Attribute/Parameter vorsehen, die alle notwendigen Einstellungen allgemeingültig ermöglichen.
Zitat von: betateilchen am 20 Oktober 2013, 21:16:15
Hast Du noch grundlegende Änderungen in der PID-Logik in der Pipeline oder kann ich das Modul jetzt um die Doku ergänzen und dann einchecken?
Ist ist kein Stein auf dem anderen geblieben, ich habe viel getestet und gehe derzeit in den produktiven Betrieb im Haus über.
Ich habe in einer Wiki-Seite angefangen die wesentlichen Dinge zusammenzustellen und auch zur Diskussion zu stellen.
http://www.fhemwiki.de/wiki/PID (http://www.fhemwiki.de/wiki/PID)
Die nächsten Tage werden zeigen, wie sich das Skript im produktiven Betrieb bewährt.
Danach würde ich das Skript ins Forum stellen.
Eine breitere Anwenderbasis mit Beta-Testern und deren Rücklauf wäre sehr hilfreich.
Dich Udo würde ich bitten, dir vor allem das Skript selbst vorzunehmen und kritisch zu beurteilen.
John
Zitat von: John am 20 Oktober 2013, 22:05:20Stattdessen sollten wir Attribute/Parameter vorsehen, die alle notwendigen Einstellungen allgemeingültig ermöglichen.
Das geht doch sowieso.
Hallo!
Kann der p_d Wert stimmen? 10^-15?
ZitatReadings:
2013-10-20 22:11:00 actuation 0
2013-10-20 22:11:00 delta -0.8
2013-10-20 22:06:57 desired 17
2013-10-20 22:11:00 measured 17.8
2013-10-20 22:11:00 p_d -3.91843420455938e-15
2013-10-20 22:11:00 p_i 20.3921568627451
2013-10-20 22:11:00 p_p -20.3921568627451
2013-10-20 22:11:00 sensorState alive
2013-10-20 22:11:00 state active
Grüße
ja, das ist quasi 0 :)
Ok alles klar!
Zitat von: John am 20 Oktober 2013, 22:05:20Dich Udo würde ich bitten, dir vor allem das Skript selbst vorzunehmen und kritisch zu beurteilen.
Du hast das Modul für die Mehrzahl der Anwender unbenutzbar gemacht. Auch für mich. Reicht das als vorläufige Kritik?
Ich trage Dich gerne als Maintainer für das Modul in fhem ein und ich bin dann komplett raus.
ZitatDu hast das Modul für die Mehrzahl der Anwender unbenutzbar gemacht. Auch für mich. Reicht das als vorläufige Kritik?
Eine Begründung deiner Kritik wäre hilfeich, um Deine Aussage zu verstehen.
Ich habe viele Stunden mit der Codierung und Validierung des Skriptes verbracht und würde mir daher eine qualifizierte Expertise wünschen.
Als verantwortlicher Modul-Maintainer kannst du jederzeit, meine Veränderungen verwerfen oder in Teilen übernehmen.
Willst du dieser nicht mehr sein, kannst du dein Mandat an Rudi zurückgeben.
ZitatIch trage Dich gerne als Maintainer für das Modul in fhem ein....
Dazu benötigst du meine Zustimmung, die du nicht hast.
John
Zitat von: John am 20 Oktober 2013, 22:48:12Eine Begründung deiner Kritik wäre hilfeich, um Deine Aussage zu verstehen.
Völlig unterschiedliche Philosophien darüber, wie ein Modul in fhem für die Allgemeinheit nutzbar sein sollte.
Zitat von: John am 20 Oktober 2013, 22:48:12Ich habe viele Stunden mit der Codierung und Validierung des Skriptes verbracht
Das habe ich nicht bestritten.
Zitat von: John am 20 Oktober 2013, 22:48:12Dazu benötigst du meine Zustimmung, die du nicht hast.
Das habe ich weder behauptet, noch würde ich das ohne Zustimmung tun. Es war lediglich ein Angebot.
Hallo Udo,
da dich meine Zuarbeit offensichtlich mehr behindert als es dir hilft,
werde ich mich zum Thema PID zurückziehen und wünsche dir gutes Gelingen.
Wichtig ist, dass am Ende und eine gut funktionierendes und anwendbares Stück Software entsteht,
das einen PID-Regler implementiert, wir er zuvor diskutiert wurde.
Um die Anwender nicht zu verwirren, habe ich auch den angelegten Wiki - Eintrag gelöscht.
ZitatVöllig unterschiedliche Philosophien darüber, wie ein Modul in fhem für die Allgemeinheit nutzbar sein sollte.
Vielleicht kannst du mehr zu Deiner Philosphie sagen und was dich ohne je mein Skript gesehen zu haben zur Aussage bewogen hat:
ZitatDu hast das Modul für die Mehrzahl der Anwender unbenutzbar gemacht. Auch für mich. Reicht das als vorläufige Kritik?
John
Zitat von: John am 21 Oktober 2013, 15:14:07da dich meine Zuarbeit offensichtlich mehr behindert als es dir hilft,
werde ich mich zum Thema PID zurückziehen und wünsche dir gutes Gelingen.
...
Um die Anwender nicht zu verwirren, habe ich auch den angelegten Wiki - Eintrag gelöscht.
Du musst doch jetzt hier nicht die beleidigte Leberwurst und/oder bockiges Kind spielen? Ich habe weder Deine Arbeit schlechtgemacht noch irgendetwas gegen Dich persönlich geäußert.
Zitat von: John am 21 Oktober 2013, 15:14:07und was dich ohne je mein Skript gesehen zu haben zur Aussage bewogen hat
Dein WIKI-Eintrag.
Lass uns den Rest bitte per email diskutieren.
Irgendwie glaube ich das ja jetzt nicht...
Ich habe sehnsüchtig seit Tagen auf Johns neues Modul gewartet, weil der alte PID-Regler nach meiner, zugegebenermassen unfachmännischen, Meinung nicht besonders gut zur Heizkörperreglung taugt. Die Plots der Ventilöffnung zeigen im Vergleich zum FHT doch krasse Unterschiede: Bei geringer Differenz zwischen Soll- und Isttemperatur öffnet der alte Regler gerne auf 100%, der FHT reagiert wesentlich moderater.
Das Modul von betateilchen ist gar nicht zu gebrauchen: Bei jeder Erniedrigung des p_i-Wertes (oder Erhöhung des p_p-Wertes, was weiss ich) öffnet das Ventil auf 1%. Und die FHT8V sind laut. Ich habe den Regler testhalber über Nacht laufen lassen. War nicht gut.
Meine Entscheidung für FHEM beruht, neben dem Bastel- und Spieltrieb, hauptsächlich auf der Hoffnung, meine Heizkosten zu senken. Ich verbrenne jedes Jahr 7t Pellets. Ein gut funktionierender PID-Regler ist somit essentiell. Es geht hier echt um Geld.
Deshalb meine Bitte an John, nicht hinzuschmeissen. Du bist hier, soweit ich sehe, der einzige, der den Regler verstanden hat und den auch in einen Algorihtmus giessen kann. Den Wiki-Artikel finde ich hervorragend. Hard Stuff, aber mir ist einiges klarer geworden.
Gruss
Hans
tja, ich hatte mir die Zusammenarbeit auch irgendwie anders vorgestellt...
Zitat von: rudolfkoenig am 02 Oktober 2013, 11:09:27Von mir aus gerne, Du hast ja auch weitere Module.
Damit bist Du zum PID Maintainer geworden.
Ich habe gerade das Rad zurückgedreht. Bis auf weiteres werde ich keine Änderungen (im Sinne von neuen Funktionalitäten) in dieses Modul einbauen. Falls sich jemand anderes findet, der das Modul überarbeiten/weiterentwickeln möchte, bin ich gerne bereit, die Wartung für das Modul abzugeben.
Schade, dass es sich so entwickelt hat. Das Modul machte einen interessanten, wenn auch sehr komplexen Eindruck. Bei mindestens 48 Nutzern des bisherigen Mpduls, wenn ich die Statistik richtig interpretiere, wäre vielleicht ein Ansatz, Johns Ansatz zunächst als alternatives Modul laufen zu lassen, um auch Testen besser organisieren zu können.
Christian
Zitat von: cwagner am 22 Oktober 2013, 09:27:14Bei mindestens 48 Nutzern des bisherigen Mpduls,
Genau DA liegt mein Problem (und die Philosophiefrage): Ein Modul das relativ häufig im Einsatz ist, darf man nicht einfach schon im define grundlegend ändern. Ein überarbeitetes Modul muss so weit wie möglich ohne jegliche Änderungen bei den bisherigen Anwendern weiterfunktionieren. Und das war bei dem von John vorgestellten Konzept nicht gegeben.
Meine Philosophie ist: Mach es dem Benutzer so einfach wie möglich und verlagere möglichst viel "Intelligenz" in das Modul. Deshalb hatte ich z.B. auch das automatische Setzen des Attributes für die gerundeten Ventilwerte eingebaut, weil das bei FHT8V immer gesetzt sein muss.
John wollte genau das Gegenteil - gar nichts im Modul definieren, sondern alles über Attribute steuern, was für mich ein Irrweg wäre (genau wie Laminatfußboden und Landhausstil)
Und genau das hier:
Zitatöffnet das Ventil auf 1%.
hatte ich auch schon irgendwann im Modul korrigiert.
Zitat von: betateilchen am 22 Oktober 2013, 09:42:48
hatte ich auch schon irgendwann im Modul korrigiert.
Version vom 12.10.2013:
Um 2 Uhr war der WAF unterirdisch...
Zitat von: Hans Franz am 22 Oktober 2013, 12:33:21Version vom 12.10.2013:
ja, und gestern war der 21.10. und meine aktuellen Änderungen waren noch gar nicht hier im Thread, um keine Verwirrung durch die unterschiedlichen, parallel stattfindenden Arbeitsschritte am Modul von mir und John zu schaffen.
Wie wäre es denn wenn das PID20-Modul von John das PID-Modul von Udo ersetzt?
So wie ich das sehe kennt sich John in puncto PID besser aus....
Udo, wäre das ok für dich?
Es gibt kein PID Modul von mir.
Zitat von: rudolfkoenig am 02 Oktober 2013, 11:09:27
> Dreh doch die Reihenfolge mal um, dann kann ich mal schauen, was sich alles machen läßt.
Von mir aus gerne, Du hast ja auch weitere Module.
Damit bist Du zum PID Maintainer geworden.
Ja. Und weiter?
Was das bedeutet, habe ich im Forum heute schonmal erklärt (schau mal in den Thread zum neuen PID (http://forum.fhem.de/index.php/topic,17067.msg113795.html) Modul)
Ok ok...
Ich sehe, dass das kurzfristig leider wohl doch nichts mehr wird mit einem neuen verbesserten PID-Modul... :'(
Zitat von: betateilchen am 21 Oktober 2013, 20:26:24
Ich habe gerade das Rad zurückgedreht. Bis auf weiteres werde ich keine Änderungen (im Sinne von neuen Funktionalitäten) in dieses Modul einbauen. Falls sich jemand anderes findet, der das Modul überarbeiten/weiterentwickeln möchte, bin ich gerne bereit, die Wartung für das Modul abzugeben.
John ist auch raus:
Zitat von: John am 21 Oktober 2013, 15:14:07
Hallo Udo,
da dich meine Zuarbeit offensichtlich mehr behindert als es dir hilft,
werde ich mich zum Thema PID zurückziehen und wünsche dir gutes Gelingen.
Wichtig ist, dass am Ende und eine gut funktionierendes und anwendbares Stück Software entsteht,
das einen PID-Regler implementiert, wir er zuvor diskutiert wurde.
Um die Anwender nicht zu verwirren, habe ich auch den angelegten Wiki - Eintrag gelöscht.
Ahh! Von den neuen Entwicklungen am PID(20) in dem neuen Thread (http://forum.fhem.de/index.php/topic,17067.0.html) hab ich bisher noch nichts mitgekriegt. Schön, dass es doch irgendwie weiter geht.
Dann kann man ja hier zu machen, oder?