PID-Modul: Vorschläge (gelöst)

[John]

Siehe neues Modul PID20

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

[rudolfkoenig]

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.

[betateilchen]

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.

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.

[rudolfkoenig]

> 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.

[betateilchen]

Ok :) Dann kann ich ja meine Änderung aus dem anderen PID-Thread schonmal gleich selbst einchecken.

[John]

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

[betateilchen]

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

Vorschlag:
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.

[betateilchen]

OK...

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

Vorschlag:
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.

[John]

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.

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.

Code: [Auswählen]


  # i-anteil berechnen
  my $i = PID_gv($pid,'integrator')+$delta*$pid->{iFactor};

John

[betateilchen]

Im 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

[John]

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

[betateilchen]

hm... danke.

Wir sollten grundsätzlich nicht vergessen, dass es auch noch andere Komponenten als die von Max gibt ;)

[John]

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

[betateilchen]

Das stimmt schon. Mein Gedanke ging auch eher in eine andere Richtung (ich muss mal eine Nacht drüber schlafen).

[Bernhard]

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