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

Begonnen von John, 01 Oktober 2013, 23:22:35

Vorheriges Thema - Nächstes Thema

John

[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
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

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]"));
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

John

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
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

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
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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)

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

John

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
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

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



---
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

John

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
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

John

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
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

fhainz

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

John

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
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

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.


---
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!