Neues Modul PID20 - Der PID-Regler

Begonnen von John, 02 Dezember 2013, 22:03:40

Vorheriges Thema - Nächstes Thema

abc2006

Gerade habe ich versucht, meine gestrigen Erkenntnisse umzusetzen. Dabei ist mir aufgefallen, dass actuation immer ziemlich lange auf dem gleichen Wert bleibt, während sich actuationCalc ändert.
2017-01-05 15:42:20.206 PID20 PID.FUBO actuation: 0.5
2017-01-05 15:42:20.206 PID20 PID.FUBO actuationCalc: 0.350500000000001
2017-01-05 15:43:20.284 PID20 PID.FUBO actuation: 0.5
2017-01-05 15:43:20.284 PID20 PID.FUBO actuationCalc: 0.354000000000001
2017-01-05 15:44:20.362 PID20 PID.FUBO actuation: 0.5
2017-01-05 15:44:20.362 PID20 PID.FUBO actuationCalc: 0.357500000000001


Un das zu beheben, habe ich ActorInterval kleiner gemacht (ist bei mir egal, wie groß das ist, weil ich auf die Events triggere).
hat aber nicht geholfen. Normal müsste doch bei ActorInterval = CalcInterval, immer beide actuation-Readings gleichzeitig aktualisiert werden, oder?

Sieht man auch schön im SVG... Ich weiss nicht, woran das liegt...
habs gefunden: ActorThreshold ist standardmäßig auf 1. Und da ich mit werten <1 arbeite... Wäre es nicht sinnvoll, standardmäßig alles auszugeben und nur bei Bedarf einzuschränken?

Internals:
   DEF        RE_TEMP_VorlaufHK:temperature D_MischerPID
   NAME       PID.FUBO
   NR         358
   NTFY_ORDER 50-PID.FUBO
   STATE      A: 0.5 AC: 0.4 Soll: 29.1°C Ist: 28.8°C
   TYPE       PID20
   VERSION    1.0.0.9
   Helper:
     Dblog:
       Actuation:
         Logdb:
           TIME       1483627400.2707
           VALUE      0.5
       Actuationcalc:
         Logdb:
           TIME       1483627400.2707
           VALUE      0.354000000000001
       Delta:
         Logdb:
           TIME       1483627400.2707
           VALUE      0.350000000000001
       Desired:
         Logdb:
           TIME       1483627400.2707
           VALUE      29.1
       Measured:
         Logdb:
           TIME       1483627400.2707
           VALUE      28.75
       P_d:
         Logdb:
           TIME       1483627400.2707
           VALUE      0
       P_i:
         Logdb:
           TIME       1483627400.2707
           VALUE      0.00399999999999928
       P_p:
         Logdb:
           TIME       1483627400.2707
           VALUE      0.350000000000001
       State:
         Logdb:
           TIME       1483627400.29952
           VALUE      processing
   Readings:
     2017-01-05 15:43:20   actuation       0.5
     2017-01-05 15:43:20   actuationCalc   0.354000000000001
     2016-11-13 21:00:54   alt             I: 0.9 P: 28 D: 50
     2017-01-05 15:43:20   delta           0.350000000000001
     2017-01-05 15:43:20   desired         29.1
     2017-01-05 15:43:20   measured        28.75
     2017-01-05 15:43:20   p_d             0
     2017-01-05 15:43:20   p_i             0.00399999999999928
     2017-01-05 15:43:20   p_p             0.350000000000001
     2016-11-13 21:00:54   pidFactor_D     0
     2016-11-13 21:00:54   pidFactor_I     0
     2016-11-13 21:00:54   pidFactor_P     0.99
     2017-01-05 15:43:20   state           processing
   Helper:
     actor      D_MischerPID
     actorCommand
     actorErrorAction freeze
     actorErrorPos 0
     actorInterval 1
     actorKeepAlive 1800
     actorLimitLower -5
     actorLimitUpper 5
     actorThreshold 1
     actorTimestamp 2017-01-05 15:36:40
     actorValueDecPlaces 1
     adjust
     calcInterval 60
     deltaGradient 0
     deltaOld   0.350000000000001
     deltaOldTS 2017-01-05 15:43:35
     deltaTreshold 0
     desiredName desired
     disable    0
     factor_D   0
     factor_I   0.01
     factor_P   1
     isWindUP
     measuredName measured
     reading    temperature
     regexp     ^([\+,\-]?\d+\.?\d*$)
     reverseAction 0
     sensor     RE_TEMP_VorlaufHK
     sensorTimeout 3600
     stopped    0
     updateInterval 600
Attributes:
   DbLogInclude .*
   pidActorInterval 1
   pidActorLimitLower -5
   pidActorLimitUpper 5
   pidActorValueDecPlaces 1
   pidCalcInterval 60
   pidFactor_D 0
   pidFactor_I 0.01
   pidFactor_P 1
   room       Heizung
   stateFormat {sprintf("A: %.1f AC: %.1f Soll: %.1f°C Ist: %.1f°C", ReadingsVal("PID.FUBO","actuation",0),ReadingsVal("PID.FUBO","actuationCalc",0),ReadingsVal("PID.FUBO","desired",0),ReadingsVal("PID.FUBO","measured",0),)}


2017-01-05 15:42:18.837 PID20 PID.FUBO start
2017-01-05 15:42:20.206 PID20 PID.FUBO desired: 29.1
2017-01-05 15:42:20.206 PID20 PID.FUBO measured: 28.75
2017-01-05 15:42:20.206 PID20 PID.FUBO p_p: 0.350000000000001
2017-01-05 15:42:20.206 PID20 PID.FUBO p_d: 0
2017-01-05 15:42:20.206 PID20 PID.FUBO p_i: 0.000499999999999264
2017-01-05 15:42:20.206 PID20 PID.FUBO actuation: 0.5
2017-01-05 15:42:20.206 PID20 PID.FUBO actuationCalc: 0.350500000000001
2017-01-05 15:42:20.206 PID20 PID.FUBO delta: 0.350000000000001
2017-01-05 15:42:20.226 PID20 PID.FUBO processing
2017-01-05 15:43:20.284 PID20 PID.FUBO desired: 29.1
2017-01-05 15:43:20.284 PID20 PID.FUBO measured: 28.75
2017-01-05 15:43:20.284 PID20 PID.FUBO p_p: 0.350000000000001
2017-01-05 15:43:20.284 PID20 PID.FUBO p_d: 0
2017-01-05 15:43:20.284 PID20 PID.FUBO p_i: 0.00399999999999928
2017-01-05 15:43:20.284 PID20 PID.FUBO actuation: 0.5
2017-01-05 15:43:20.284 PID20 PID.FUBO actuationCalc: 0.354000000000001
2017-01-05 15:43:20.284 PID20 PID.FUBO delta: 0.350000000000001
2017-01-05 15:43:20.304 PID20 PID.FUBO processing
2017-01-05 15:43:57.231 PID20 PID.FUBO desired: 29.1
2017-01-05 15:44:20.362 PID20 PID.FUBO desired: 29.1
2017-01-05 15:44:20.362 PID20 PID.FUBO measured: 28.75
2017-01-05 15:44:20.362 PID20 PID.FUBO p_p: 0.350000000000001
2017-01-05 15:44:20.362 PID20 PID.FUBO p_d: 0
2017-01-05 15:44:20.362 PID20 PID.FUBO p_i: 0.00749999999999929
2017-01-05 15:44:20.362 PID20 PID.FUBO actuation: 0.5
2017-01-05 15:44:20.362 PID20 PID.FUBO actuationCalc: 0.357500000000001
2017-01-05 15:44:20.362 PID20 PID.FUBO delta: 0.350000000000001
2017-01-05 15:44:20.381 PID20 PID.FUBO processing


FHEM nightly auf Intel Atom (lubuntu) mit VDSL 50000 ;-)
Nutze zur Zeit OneWire und KNX

mafl2k

#346
Hallo John,

die D-Anteil Kalkulation darf keinen Bezug zur Desired Temperature haben.
Aktuell beeinflusst eine Änderung der Desired auch den D-Anteil für einen Takt.

Wenn ich deine Code richtig gelesen habe, reicht quickanddirty ein Entfernen der Variable in PID20_Notify.
Dadurch wird nur noch der SensorValue betrachtet. Man könnte noch die Namen anpassen.

258c258
<     my $delta    = $desired - $sensorValue           if ( defined($desired) );
---
>     my $delta    = $sensorValue;


Außerdem muss, glaube ich, noch dass Vorzeichen des D-Anteils gedreht werden.
Aktuell wirkt der Differenzierer verstärkend in Richtung der Änderung.

540c540
<       $dPortion = ($deltaGradient) * $hash->{helper}{calcInterval} * $hash->{helper}{factor_D};
---
>       $dPortion = ($deltaGradient) * $hash->{helper}{calcInterval} * $hash->{helper}{factor_D} * -1;

Oder man dreht den Gradienten vorher.

Gruß
Matthias

tyrolean

Hallo,

Ich habe seit ca einem Jahr meine gesamte Heizungssteuerung mit 1Wire und PID20 problemlos geregelt. Das Ganze ist via Homebridge in Homekit integriert.

Seit einiger Zeit verlieren die PID20 nach einem FHEM Neustart jedoch den desired Wert, was eher lästig ist da dadurch meine Regelung ausfällt, habt ihr hierzu eine Idee/Lösung?

Gruß aus Tirol

JoeALLb

Kann ich bestätigen, meines verliert die auch!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

frank

ich erhalte 9x perl warning nach restart.

2017.03.01 08:45:23.902 1: PERL WARNING: given is experimental at ./FHEM/98_PID20.pm line 305, <$fh> line 1044.
2017.03.01 08:45:23.902 1: stacktrace:
2017.03.01 08:45:23.902 1:     main::__ANON__                      called by ./FHEM/98_PID20.pm (305)
2017.03.01 08:45:23.902 1:     (eval)                              called by fhem.pl (2333)
2017.03.01 08:45:23.902 1:     (eval)                              called by fhem.pl (2332)
2017.03.01 08:45:23.902 1:     main::CommandReload                 called by fhem.pl (1748)
2017.03.01 08:45:23.903 1:     main::LoadModule                    called by fhem.pl (1810)
2017.03.01 08:45:23.903 1:     main::CommandDefine                 called by fhem.pl (1106)
2017.03.01 08:45:23.903 1:     main::AnalyzeCommand                called by fhem.pl (975)
2017.03.01 08:45:23.903 1:     main::AnalyzeCommandChain           called by fhem.pl (1241)
2017.03.01 08:45:23.903 1:     main::CommandInclude                called by fhem.pl (520)


zusätzlich für die zeilen 307, 339, 341, 345, 356, 363, 370 und 385.


das desired problem muss ich mir mal anschauen. gut zu wissen, dass dort was klemmt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ripperle

Ich habe eine kurze Frage und hoffe es ist ok sie hier einfach zu stellen:

Durch die Anti windup Strategie wird ja der i Anteil eingefroren wenn die Differenz kleiner min wert ist.
Wenn meine Heizung morgens eine tiefere soll Temperatur bekommt, springt die regeldifferenz auf z.B. - 5.
Da das kleiner 0 ist wird der i Anteil eingefroren und baut sich über Stunden nicht ab...
Ist dieses Verhalten so gewollt?
Ich würde erwarten das der i Anteil sich bis auf minimum abbaut (hier wäre das 0) bevor die Anti windup Strategie diesen einfriert...?!

Gruß
Andreas

JoeALLb

Vorab eine Entwarnung: bei den letzten Neustarts wurde mein desired-temp nicht mehr zurückgesetzt. Vermutlich hatte es etwa smit einem anderen FHEM-Update zu tun, denn ein weiteres Device hat etwas verloren...

Frage zu Fenster-Offen:
Wenn ich im Winter (bei -20°) die Türe etwas länger offen lasse, was beim Beladen des Autos öfter vorkommt, übersteuert meine FB-Heizung danach komplett.
Da der Raumfühler sehr kalt meldet, gehen die Ventile auf und der Boden bekommt zu warm. Hat jemand eine Idee, wie ich das am besten abfedere?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

ripperle

Ich habe ein Fenster kontakt (DIY mit mysensors) und schalte beim öffnen des Fensters den regler auf stopp und die Heizung aus. Nach dem schließen warte ich 10 Minuten und schalte den regler wieder ein...

Kann jemand noch was zu meinem vorigen Post sagen?

Mathea

Hi, gibt es eine Möglichkeit, dass der Regler seinen Zustand (processing / stop / ...) nach einem Neustart von fhem behält?

Ich steuere mit dem Regler meine Rolläden an, um im Sommer die Raumtemperatur konstant zu halten. Natürlich sollen die Rolläden allerdings nicht herunterfahren wenn meine Balkontür offen ist. Dementsprechend schalte ich den Regler mit "set BalkontuerPID stop" ab wenn die Tür geöffnet ist. Starte ich fhem nun allerdings neu, wird der Regler wieder eingeschaltet und fährt unter Umständen meine Rolläden trotz geöffneter Tür zu. Das möchte ich irgendwie vermeiden.

Vielen Dank im Voraus,
Mathea

AntonTheBuilder

Hallo,
ich habe mir einen Homematic Wandthemperaturregler und Thermostat zugelegt und im fhem installiert.
dann habe ich den PID20 definiert.
kann mir bitte jemand bestätigen dass das ungefähr passt oder nicht- vor allem das measured-temp und maxvalveSetting - sind das die richtigen kommandos für die Homematic komponenten?

define PID.Eingang PID20 HM_Wandthermometer:measured-temp HM_Thermostat:maxvalveSetting

2) Kann ich Dem PID-EDesired den Wert vom Homematic Wandthermostat übergeben? bzw wie?

Danke.

JoeALLb

Zitat von: Mathea am 10 Juni 2017, 15:55:34
Hi, gibt es eine Möglichkeit, dass der Regler seinen Zustand (processing / stop / ...) nach einem Neustart von fhem behält?
Ich hab mir hier über ein startupscript beholfen:

Das Schema(pseudocode) ist grob so, wenn Du mit dem Code schwierigkeiten bekommst kann ich ihn dir genauer raussuchen:
if STARTUP and DOOR=OPEN, set pid20 stop; set rollo value 0

Du kannst Dir auch den letzten Zustand in ein eigenes Reading schreiben und dann auf diesen Wert beim Neustart setzen.

Grüße Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

dirkcx

#356
Hallo zusammen,

hat jemand einen eQ3 BT Regler (Eqiva Funk-Heizkörperthermostat elektronisch CC-RT-BLE-EQ mit Bluetooth) mit PID20 gekoppelt?
Den eQ3 kann man nur per "desiredTemperature" steuern und das bekomme ich über PID20 nicht direkt hin.
Ich habe das nun über ein Notify geregelt und den Regelbereich über pidActorLimitLower und pidActorLimitUpper limitiert, bin aber nicht sicher, ob ich das alles richtig verstanden habe. Beim eQ3 kann man nicht die Ventilsteuerung regeln sondern nur die Temperatur. Eigentlich würde ich nicht noch ein Notify dazwischen haben wollen. Hat jemand Erfahrung mit der Kombination?


define PID.BAD PID20 mqtt_chip_htu21d:temperature eq3_bad:desiredTemperature

klappt definitiv nicht! Leider!

Mein Setup ist:

defmod PID.BAD PID20 mqtt_chip_htu21d:temperature dummy.Heizungsregler
attr PID.BAD event-on-change-reading .*
attr PID.BAD pidActorLimitLower 5
attr PID.BAD pidActorLimitUpper 29
attr PID.BAD pidActorValueDecPlaces 0
attr PID.BAD pidUpdateInterval 900
attr PID.BAD userReadings temperature
attr PID.BAD verbose 5



attr PID.BAD pidDesiredName desiredTemperature führt zu einem alarm bim PID20



defmod mqtt_chip_htu21d MQTT_DEVICE
attr mqtt_chip_htu21d autoSubscribeReadings smarthome/sensors/chip/+
attr mqtt_chip_htu21d event-on-change-reading humidity,temperature
attr mqtt_chip_htu21d subscribeReading_temperature smarthome/sensors/chip/temperature/state



defmod eq3_bad EQ3BT 00:1A:22:06:xx:xx



defmod dummy.Heizungsregler dummy



defmod notify.Heizungsregler notify dummy.Heizungsregler:.* {\
my $intval = InternalVal("dummy.Heizungsregler","STATE","");;;;  \
fhem("set eq3_bad desiredTemperature $intval ");;;;\
}



Vielen Dank
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

JHo

#357
Hallo zusammen,

auch ich würde gerne mal das PID20-Modul testen, werde aber aus dem Wiki-Eintrag zum Modul bzw. zur Fußbodenheizung per MAX nicht schlau.

Mein Setting:
- MAX! Heizkörperthermostat (arbeit.therm)
- MAX! Wandthermostat im gleichen Raum (arbeit.wand)
Bisher verwende ich beide "im Sinne des Systems", also assoziiert.


Config
define arbeit.PID PID20 arbeit.wand:temperature arbeit.therm:maxValveSetting
define arbeit.wand.Event notify arbeit.wand:(desiredTemperature:).*  {fhem("set arbeit.PID desired %EVTPART1");;}


    Fragen:

    • Muss ich die Assoziation von Wand- und Heizkörperthermostat für PID20 entfernen?
    • Was passiert, wenn ich am Heizkörper die gewünschte Temperatur händisch verstelle? Das "desired Temperature on" aus dem Fußbodenheizungs-Wikieintrag wird doch von PID20 eh gleich überschrieben, oder? Frage ist obsolet, wenn ich die Assoziation entfernen muss...
    • Ich speichere in Wand- und Heizkörperthermostat das Wochenprogramm. Kann ich das (abhängig von Antwort 1) zumindest im Wandthermostat weiter verwenden?
    • Was passiert, wenn FHEM ausfällt? Das Ventil bleibt auf dem zuletzt vom Regler gesendeten "Valveposition"-Wert, oder?

    Danke fürs Aufhellen,
    Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

JHo

Ich antworte mir mal selber. Was ein bisschen Nachdenken so alles anrichten kann... mindestens die Hälfte meiner Fragen sind dumm, daher bitte ich eher um Bestätigung meiner eigenen Antworten:

  • ja, klar. Sonst setzt das Heizkörperthermostat die Wärmeanforderung nur im Bereich der vom PID20 vorgegebenen maximalen Valveposition um. Also im Zweifelsfall gar nicht.
  • lesen bildet: geht ja um die Temperatur, nicht die Ventilstellung. Temperatur an der Heizung auf "offen", damit PID20 das jeweils notwendige "offen" über die maxValvePosition steuern kann. Daher: nicht die gewünschte Temperatur am Heizkörper verstellen
  • Da Heizkörperthermostat immer auf max. Temperatur stehen soll, geht ein Wochenprogramm nur im Wandthermostat.
  • Da die beiden beteiligten Akteure Wand- und Heizungsthermostat nicht mehr gekoppelt sind, passiert beim FHEM-Ausfall gar nichts mehr.
Aus der letzten Antwort folgt eine neue Frage: steuern die MAX-Heizkörperthermostate intern auch bei via PID20 gesetzter maxValveposition von 0 (Ventil komplett zu) etwas auf, wenn akute Frostgefahr droht? Wenn ich im Winterurlaub bin und beim urlaubsbedingten Absenken FHEM abstürzt, droht mir dann ein Frostschaden, weil die Ventile ums Verrecken zu bleiben?

Danke,
Jan
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

John

ZitatAus der letzten Antwort folgt eine neue Frage: steuern die MAX-Heizkörperthermostate intern auch bei via PID20 gesetzter maxValveposition von 0 (Ventil komplett zu) etwas auf, wenn akute Frostgefahr droht? Wenn ich im Winterurlaub bin und beim urlaubsbedingten Absenken FHEM abstürzt, droht mir dann ein Frostschaden, weil die Ventile ums Verrecken zu bleiben?


Ja, das wird so sein. MaxValveSetting begrenzt den Ventilhub ohne Rücksicht auf Verluste.
Du kannst mit pidActorLimitLower dafür sorgen, daß PID20 nie ganz auf 0 fährt, aber ein sicherer Frostschutz ist auch das nicht.


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP