Autor Thema: PID-Modul: Vorschläge (gelöst)  (Gelesen 39185 mal)

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
PID-Modul: Vorschläge (gelöst)
« am: 01 Oktober 2013, 23:22:35 »

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

« Letzte Änderung: 20 September 2014, 11:24:34 von John »
CubieTruck CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21223
Aw: PID-Modul: Vorschläge
« Antwort #1 am: 02 Oktober 2013, 07:43:15 »
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.


Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16098
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #2 am: 02 Oktober 2013, 10:59:02 »
Zitat von: rudolfkoenig schrieb am Mi, 02 Oktober 2013 07:43
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21223
Aw: PID-Modul: Vorschläge
« Antwort #3 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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16098
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #4 am: 02 Oktober 2013, 11:12:56 »
Ok :) Dann kann ich ja meine Änderung aus dem anderen PID-Thread schonmal gleich selbst einchecken.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #5 am: 02 Oktober 2013, 11:28:17 »
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
CubieTruck CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16098
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #6 am: 02 Oktober 2013, 14:53:08 »
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

Zitat
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16098
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #7 am: 02 Oktober 2013, 14:57:13 »
Zitat von: betateilchen schrieb am Mi, 02 Oktober 2013 14:53
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

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

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #8 am: 02 Oktober 2013, 15:00:57 »

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

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


John
CubieTruck CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16098
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #9 am: 02 Oktober 2013, 16:42:24 »
Zitat von: John schrieb am Mi, 02 Oktober 2013 15:00
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
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #10 am: 02 Oktober 2013, 18:05:39 »
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

CubieTruck CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16098
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #11 am: 02 Oktober 2013, 20:30:23 »
hm... danke.

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

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #12 am: 02 Oktober 2013, 20:37:27 »
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


CubieTruck CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16098
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #13 am: 02 Oktober 2013, 21:03:23 »
Das stimmt schon. Mein Gedanke ging auch eher in eine andere Richtung (ich muss mal eine Nacht drüber schlafen).

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline Bernhard

  • Full Member
  • ***
  • Beiträge: 131
Aw: PID-Modul: Vorschläge
« Antwort #14 am: 03 Oktober 2013, 10:46:18 »
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