Das Modul PID20 ist seit 26.03.2014 Bestandteil von FHEM
(die Zwischenversionen in diesem Thread wurden gelöscht)
Das neue Modul PID20 realisiert einen PID-Regler mit erweiterten Funktionalitäten.
PID20 implementiert im Wesentlichen die in diesem Thread
http://forum.fhem.de/index.php/topic,15060.0.html (http://forum.fhem.de/index.php/topic,15060.0.html)
diskutierten neuen Features.
Es kann unabhängig zum bestehenden PID-Modul eingesetzt werden, so dass jederzeit der Schritt "zurück" möglich ist.
Beide Module können innerhalb von FHEM unabhängig voneinander, auch gleichzeitig genutzt werden.
Das Grundkonzept des Moduls, insbesondere die Dynamisierung von Setter-Namen beruht auf Code-Vorlagen von Betateilchen
aus dem erwähnten Thread.
Ich verwende das Modul seit nunmehr 2 Monaten mit einem MAX-Thermostat als Stellglied und einen HMS100TF als Istwert-Geber
für die Temperatur zur Regelung meiner Fußbodenheizung und bin damit sehr zufrieden.
Die Beschreibung findet sich im Wiki unter
http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler (http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler)
John
Danke !
Habe gerade umgestellt.
Log läuft. Plot auch. Werde berichten.
Gruss
Hans
Hallo John,
heute habe ich das Modul für einen von zwei Wohnzimmerheizkörpern in Betrieb genommen. Bisher haben alle
Regelversuche in irgendwelchen Extremsituationen versagt, darum suche ich noch immer nach einer Lösung.
Ich verwende FHT8V Stelltriebe und ein S300TH als Temperaturgeber.
Eine meiner Besonderheiten ist, dass meine Ventile bereits bei 18% geschlossen sind. Also sind ActorLimitLower auf 18 und ActorLimitUpper auf 100 gesetzt. Das führt alledings dazu, dass actuationCalc zwar richtig errechnet aber nie übergeben wird. Der actuation bleibt immer auf 18 stehen. Die Ausgabe von Get Params sagt dann auch für
Lower und Upper Limit 18 obwohl die Attribute richtig gesetzt sind.
Ohne LimitLower 18 scheint alles einwandfrei zu laufen, lediglich mit träger Regelung weil dann ja erst eine Ventilöffnung über 18% wirksam wird.
Vielleicht hast Du eine Idee für eine Anpassung.
Gruß, Friedhelm
Hallo Friedhelm,
ich denke du hast den ersten Bug entdeckt.
Bin an dem Thema dran.
John
Hallo Friedhelm,
Problem ist gefixed.
Betrifft nur die, die das Attribut pidActorLimitUpper explizit gesetzt haben.
Anbei die neue Version 1.00.c
John
PS: Dateianhang gelöscht, da Modul in FHEM integriert ist
Läuft jetzt einwandfrei!
Danke, Friedhelm
Vielen Dank für das neue Modul....
Ich bin schon lange auf der Suche meinen MAX-Thermostaten vernünftiges Regeln bei zu bringen. Dazu möchte ich die Raumtemp.
über S300TH messen und die Stellgröße an das Thermostat ausgeben.
Wie hast Du den MAX Thermostaten als Stellorgan eingebunden?
mfg.
Michael
Oh Augen auf... dann sieht man es :o
Habe eben erst den Hinweis auf den WIKI Eintrag gesehen....
http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler#Inbetriebnahme
Sorry
mfg.
Michael
Hallo Michael,
ich regle mit PID20+Max+HMS100TF meine Fußbodenheizung.
Den entsprechenden Forumseintrag findest du hier
http://forum.fhem.de/index.php/topic,14154.msg89039.html#msg89039 (http://forum.fhem.de/index.php/topic,14154.msg89039.html#msg89039)
falls es von Interesse für dich ist.
John
Kleine Anmerkung zum Wiki-Artikel:
Zitat:
actuationCalc
Der Ausgabewert für das Stellglied wird wie folgt berechnet
actuationCalc = p_d + p_i + p_d
In der Formel muss doch auch einmal p_p auftauchen - oder?
Uwe
Hallo Uwe,
schon erledigt. Danke für den Hinweis.
John
Wie macht ihr das mit der Sendehäufigkeit?
Ich habe 9 MAX Thermostate... Wenn ich bei jedem den Intervall auf 15 Minuten stelle, dann habe ich 36 Sendevorgänge pro Stunde.
MAX lässt aber nur 33 Telegramme pro Stunde zu (zumindest mit dem CUL).
Gibt es hierfür einen Ansatz oder bin ich hier den Grenzen hilflos ausgeliefert?
Viele Grüße
Michael
Hallo Michael,
warum überlässt du das Regeln nicht den Max-Thermostaten selbst ?
Ich habe 8 Maxe im Einsatz und nur 1 davon wird via PID20 angesteuert.
Die technischen Grenzen sind vom Gesetzgeber festgelegt siehe Wiki
http://www.fhemwiki.de/wiki/1%25_Regel (http://www.fhemwiki.de/wiki/1%25_Regel)
John
Ich hab das Modul seit ein paar Tagen mit einem FHT8V in Verwendung. Klappt soweit ganz gut.
Nur kann ich irgendwie einstellen das mein log nicht so zugespammt wird?
2013.12.08 21:47:31.524 3: [szHeizung] PID20_Calc.667 <set szStellventil valve 33> with ret:
2013.12.08 21:47:31.677 2: [szHeizung] PID20_Calc.691 readings updated
2013.12.08 21:48:03.409 3: [szHeizung] PID20_Set.329 set szHeizung desired 18
2013.12.08 21:48:55.424 2: [szHeizung] PID20_Notify.213 check 3 readings for temperature
2013.12.08 21:51:52.436 2: [szHeizung] PID20_Notify.213 check 3 readings for temperature
2013.12.08 21:53:03.410 3: [szHeizung] PID20_Set.329 set szHeizung desired 18
2013.12.08 21:54:49.457 2: [szHeizung] PID20_Notify.213 check 3 readings for temperature
2013.12.08 21:57:31.854 3: FHT8V set szStellventil valve 34
2013.12.08 21:57:31.964 3: [szHeizung] PID20_Calc.667 <set szStellventil valve 34> with ret:
2013.12.08 21:57:32.114 2: [szHeizung] PID20_Calc.691 readings updated
2013.12.08 21:57:46.455 2: [szHeizung] PID20_Notify.213 check 3 readings for temperature
2013.12.08 21:58:03.408 3: [szHeizung] PID20_Set.329 set szHeizung desired 18
2013.12.08 22:00:43.463 2: [szHeizung] PID20_Notify.213 check 3 readings for temperature
2013.12.08 22:03:03.436 3: [szHeizung] PID20_Set.329 set szHeizung desired 18
2013.12.08 22:03:40.482 2: [szHeizung] PID20_Notify.213 check 3 readings for temperature
Grüße
Hallo fhainz,
wenn du verbose auf 1 nimmst , sollte der Spuk ein Ende haben.
John
Danke, nun ist im Log ruhe.
Dafür ist mir noch etwas anderes aufgefallen.
Bis 6 Uhr regelte der Regler richtig. Um 6 Uhr wird die Solltemp von 18 auf 17 runtergesetzt. Wurde auch gemacht, nur dem Regler war's egal das die Temp. > 17 war. Sollte der Regler das Ventil nicht zudrehen wenn die Solltemp kleiner ist als die Isttemp?
Grüße
Hallo fhainz,
es wäre hilfreich, wenn du die Werte der P und I- Anteile sowie actuationCalc wie im Wiki angegeben im Chart darstellen würdest.
Dann wirst du selbst den PID-Algorithmus besser verstehen und ich kann das Teil besser auswerten.
weiterhin bitte noch Ausgabe zu folgendem Befehle mitsenden
list <pid>
Beim Sollwertsprung, macht ja auch der Stellausgang einen Sprung. Dafür ist der p-Anteil verantwortlich, der sofort reagiert.
und nun deutlich negativ sein wird . Da die Summe der Anteile immer noch positiv ist muss somit der i-Anteil sehr gross sein.
Der I-Anteil wiederum hängt von der Vorgeschichte ab, die wir hier nicht sehen. Zumindest muss er vor dem Sollwertsprung
anwachsen, da die Regeldifferenz negativ war. (Soll-Ist)
Ausserdem erkennt man eine Totzeit von fast 3 Stunden. Solange dauert es bis die Temperatur auf die Sollwertänderung reagiert.
Ggf lässt sich das Verhalten noch verbessern, wenn du den I-Faktor reduzierst und den P-Faktor erhöhst.
John
Zitat von: John am 09 Dezember 2013, 13:33:34
es wäre hilfreich, wenn du die Werte der P und I- Anteile sowie actuationCalc wie im Wiki angegeben im Chart darstellen würdest.
Kann ich gerne machen wenn du die Werte benötigst um das Verhalten besser analysieren zu können. Mir sagen die Werte nichts und ich brauch sich auch nicht im live-system
Zitat von: John am 09 Dezember 2013, 13:33:34
weiterhin bitte noch Ausgabe zu folgendem Befehle mitsenden
list <pid>
Bitteschön:
Internals:
CFGFN ./FHEM/heizung.cfg
DEF Schlafzimmer:temperature szStellventil:valve
NAME szHeizung
NR 369
NTFY_ORDER 50-szHeizung
STATE processing
TYPE PID20
Readings:
2013-12-09 16:44:13 actuation 0
2013-12-09 16:45:13 actuationCalc -0.17499999999972
2013-12-09 16:45:13 delta -0.800000000000001
2013-12-09 16:44:13 desired 16
2013-12-09 16:44:13 measured 16.8
2013-12-09 16:45:13 p_d 0
2013-12-09 16:45:13 p_i 19.8250000000003
2013-12-09 16:45:13 p_p -20
2013-12-09 16:45:13 state processing
Helper:
actor szStellventil
actorCommand valve
actorErrorAction freeze
actorErrorPos 0
actorInterval 180
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2013-12-09 16:34:12
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld -0.800000000000001
deltaOldTS 2013-12-09 16:44:43
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.25
factor_P 25
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor Schlafzimmer
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
alias Heizung
group Heizung
icon temp_temperature
room 2. Schlafzimmer
verbose 1
Zitat von: John am 09 Dezember 2013, 13:33:34
Beim Sollwertsprung, macht ja auch der Stellausgang einen Sprung.
Ab 6 Uhr ist die SollTemp 1 Grad unter der IstTemp. Sollte das Ventil dann nicht auf 0 gehen? Heizbedarf ist ja zu dem Zeitpunkt keiner vorhanden.
Zitat von: John am 09 Dezember 2013, 13:33:34
Ausserdem erkennt man eine Totzeit von fast 3 Stunden. Solange dauert es bis die Temperatur auf die Sollwertänderung reagiert.
Was meinst du damit genau? Die Zeit von 6-9?
Zitat von: John am 09 Dezember 2013, 13:33:34
Ggf lässt sich das Verhalten noch verbessern, wenn du den I-Faktor reduzierst und den P-Faktor erhöhst.
Wie viel soll ich da reduzieren? Sry ich hab von der Materie keine Ahnung.
Ich häng noch einen aktuellen Screenshot der Heizung an.
Grüße
Hallo fhainz,
als Erstmassnahme empfehle ich dir folgende Änderungen
a.) pidFactor_P auf 50
b.) pidFactor_I auf 0.1
ZitatMir sagen die Werte nichts und ich brauch sich auch nicht im live-system
Wenn du PID verwenden willst, solltest du dich mit dem Gedanken anfreunden, das auch zu verstehen, was passiert,
sonst kannst du ihn nicht korrekt einstellen.
Dann brauchtst du auch die Werte auch im live-system.
ZitatWas meinst du damit genau? Die Zeit von 6-9?
sorry,hab grad gesehen, dass du um 08:30 nochmal die Temperatur auf 16 Grad reduziert hast.
Kann es sein, dass die Heizung bis ca. 04:00 Uhr im abgesenkten Betrieb gefahren ist und dann in den Normalbetrieb
(erhöhte Vorlauftemperatur) zurückkehrt ?.
John
Zitat von: John am 09 Dezember 2013, 20:14:42
sonst kannst du ihn nicht korrekt einstellen.
Ok ich wusste nicht das ich da noch was einstellen muss. Dachte das ding läuft wie es ist ;) Dann ist klar das ich die werte brauche.
Zitat von: John am 09 Dezember 2013, 20:14:42
Kann es sein, dass die Heizung bis ca. 04:00 Uhr im abgesenkten Betrieb gefahren ist und dann in den Normalbetrieb
(erhöhte Vorlauftemperatur) zurückkehrt ?.
Bis 01:00 Uhr hab ich 19°, bis 06:00 18° und ab 06:00 17° eingestellt. Heute hab ich nur manuell um 08:30 auf 16° gestellt damit das Ventil auf 0 geht ;)
Ich lass jetzt mal mit neuen werten bis morgen mitloggen dann poste ich einen neuen Screenshot. Hab bisher nur Soll, Ist, Ventil geloggt.
Grüße
Hallo fhainz
ich hab mich wohl nicht klar genug ausgedrückt.
Es ging mir nicht um die Einstellung des Thermostats, sondern um die Einstellung des Heizkessels.
Dazu kannst du natürlich nur etwas sagen, wenn du darauf Zugriff hast.
Normalerweise wird die Vorlauftemperatur nachts am Heizkessel abgesenkt.
Dies kann man mit Zeitprogrammen an der Kesselsteuerung einstellen.
Das von dir gewünschte Heizverhalten ist allerdings genau entgegengesetzt.
Du willst es Nachts warm haben.
Wenn dem so ist, dann muss der Regler gleich 2 Dinge ausgleichen.
1. er muss nachts mit weniger Wäremenergie versuchen den Raum zu erwärmen, was relativ lange dauern kann.
2. wenn dann der Tag beginnt wird er mit Wärme geflutet (Tagbetrieb beginnt bei Heizung mit höherer Vorlauftemperatur)
und dann willst du abkühlen.
Wenn du Zugriff auf die Brennersteuerung hast, solltest du das vielleicht angleichen.
John
Ahh ok jetzt weiß ich was du meinst. Nachdem ich in einer Wohnung in einem Mehrparteienhaus wohne hab ich keinen zugriff auf den Heizkessel.
Stimmt, ich will wenn ich ins Bett gehe es im Schlafzimmer warm haben ca. 18-19 Grad. In der nacht kanns dann kühler werden bis min. 17 Grad. Tagsüber wenn ich nicht zu hause bin muss es auch nicht wärmer als max. 16-17 grad sein.
Das der Heizkessels in der Nacht die Temperatur des Vorlaufes absenkt ist jetzt wirklich zu meinem Nachteil. Kann ich mit den Regler Einstellungen etwas dagegen machen?
Grüße
Klar kann man was machen.
Setzt den Sollwert so zeitig, dass du gegen 00:00 Uhr den Sollwert erreichst (war ja im Chart nicht der Fall).
Dazu wirst du mehrere Versuche brauchen, aber mit Hilfe der Charts gelingt das gut.
(ggf. musst du schon um 21:00 Uhr beginnen)
Dafür kannst du den Sollwert um 00:00 Uhr runternehmen, denn es darf ja kühler werden.
Es dauert nun auch wieder Stunden bis der Raum um 3 Grad runterkühlt, das sollte nachts auch kein Problem sein.
Der I-Anteil des Reglers wirds dir danken.
John
Hi John,
kannst du in der (noch kommenden)Comandref und im Wiki bitte ganz genau abgrenzen für welchen Einsatzzweck PID20 und für welchen das "alte" PID-Modul ist? Wo liegen die UNterschied im Einsatzzweck?
Wenn sie sehr marginal sind möchte ich dafür plädieren nur Eins mit fhem auszuliefern. Also Mergen oder eins wegwerfen. Rudi als Maintainer des PID-Moduls kann dir sicher auch die Maintainerrechte am PID-Modul übertragen.....
De arme FHEM-Anwender weiß später nicht mehr was nun besser für seinen Einsatzweck ist.
Btw: Hast du schonmal die BatterieLebenszeit beim PID20 Einsatz gecheckt?
Ich zb. sende alle 10min ein FakeWT und nach 3-5Monaten sind die Batterien tot.
Hallo Tobias
Zitatkannst du in der (noch kommenden)Comandref und im Wiki bitte ganz genau abgrenzen für welchen Einsatzzweck PID20 und für welchen das "alte" PID-Modul ist? Wo liegen die UNterschied im Einsatzzweck?
Das erschliesst sich aus dem anfangs erwähnten Forumseintrag, in dem die neuen und notwendigen Features von PID
diskutiert wurden.
ZitatWenn sie sehr marginal sind möchte ich dafür plädieren nur Eins mit fhem auszuliefern. Also Mergen oder eins wegwerfen.
Die Änderungen sind nicht marginal, sondern fundamental. Mergen macht keinen Sinn.
ZitatRudi als Maintainer des PID-Moduls kann dir sicher auch die Maintainerrechte am PID-Modul übertragen.....
Betateilchen ist der Maintainer. Er kann sich mit meinem Konzept nicht anfreunden, wie dies ebenfalls aus dem zuvor genannten
Forumseintrag zu entnehmen ist.
ZitatDe arme FHEM-Anwender weiß später nicht mehr was nun besser für seinen Einsatzweck ist
Nachvollziehbar. Wir sind aber derzeit in der Evaluationsphase.
Zitat
Btw: Hast du schonmal die BatterieLebenszeit beim PID20 Einsatz gecheckt?
Ich zb. sende alle 10min ein FakeWT und nach 3-5Monaten sind die Batterien tot.
Es gibt einige Parameter im PID20, mit den der Anwender die Zugriffshäufigkeit beeinflussen kann
und damit auch die Lebensauer der Batterie.
Ich selbst verwendet den MaxScanner nun seit bald 1 Jahr. Hier wird alle 15 Minuten der Mode umgeschalten.
Die Batterien halten bisher.
Da das WT selbst alle 3 Minuten den Istwert sendet, halte ich die als Ursache für schwindende Batterie-Ladung
für nicht plausibel.
John
Hallo,
Der Regler scheint, soweit ich das nach dieser kurzen Testphase beurteilen kann, gut zu regeln.
Was mich noch stört, sind diese kleinen Ventilbewegungen bei einer Verminderung des I-Anteils.
Hier die Daten:
Internals:
DEF CUL_WS_5:temperature stellantrieb.04:valve
NAME heizung.04
NR 370
NTFY_ORDER 50-heizung.04
STATE processing
TYPE PID20
Readings:
2013-12-10 10:24:23 actuation 0
2013-12-10 10:28:23 actuationCalc -0.225000000000115
2013-12-10 10:28:23 delta -1
2013-12-10 10:24:23 desired 15.0
2013-12-10 10:24:23 measured 16.0
2013-12-10 10:28:23 p_d 0
2013-12-10 10:28:23 p_i 24.7749999999999
2013-12-10 10:28:23 p_p -25
2013-12-10 10:28:23 state processing
Helper:
actor stellantrieb.04
actorCommand valve
actorErrorAction freeze
actorErrorPos 0
actorInterval 180
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2013-12-10 10:24:23
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld -1
deltaOldTS 2013-12-10 10:26:05
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.25
factor_P 25
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor CUL_WS_5
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
alias Heizungen_4
room Heizungen
verbose 1
(//)
Zitat von: John am 10 Dezember 2013, 07:59:58Betateilchen ist der Maintainer. Er kann sich mit meinem Konzept nicht anfreunden,
Erzähl bitte nicht solch einen Unsinn!
Du schreibst selbst:
Zitat von: John am 10 Dezember 2013, 07:59:58Die Änderungen sind nicht marginal, sondern fundamental. Mergen macht keinen Sinn.
Und genau aus diesem Grund - es machte einfach keinen Sinn, alle von Dir konzipierten Änderungen in das "alte" Modul zu packen - habe ich das damals so entschieden. Man muss bei sowas auch immer an die Benutzer denken, die das Modul in seiner bisherigen Version bereits einsetzen (ob sie damit zufrieden sind oder nicht sei dahingestellt).
Wenn Du nun daraus ein neues Modul gebaut hast - umso besser.
Ein Mergen macht tatsächlich keinen Sinn. Was ich mir vorstellen kann, ist der Weg, das alte Modul PID in absehbarer Zeit in den Zweig /contrib zu verschieben, dies auch im Forum entsprechend anzukündigen und Dein neues Modul dann im Hauptzweig von FHEM mit auszuliefern. Das wird aber erst dann relevant, wenn Du der Meinung bist, dass Dein Modul "fertig" ist. Solange die von Dir angesprochene Evaluierungsphase noch läuft, tut diese Umstrukturierung aber nicht Not.
Und nochwas: Maintainer eines Moduls zu sein, heißt nicht, dass man auch der Entwickler des Moduls ist oder die Funktionalität des Moduls uneingeschränkt gutheißt. Das kann auch "nur" bedeuten, dass man u.a. die Verantwortung dafür übernommen hat, ein Modul regelmäßig konform der aktuellen fhem-Entwicklung zu halten.
Viele Grüße
Udo
Hallo Hans Franz
sieh dir nochmals die Attribute pidActorThreshold und pidActorInterval im Wiki an.
Damit kannst du das Verhalten ändern.
Vorschlag:
pidActorThreshold zwischen 5 und 10 einstellen
pidActorInterval auf 600-900 stellen (max alle 10..15 Minuten Stellausgang betätigen)
John
Zitat von: John am 10 Dezember 2013, 14:38:00
Vorschlag:
pidActorThreshold zwischen 5 und 10 einstellen
pidActorInterval auf 600-900 stellen (max alle 10..15 Minuten Stellausgang betätigen)
Danke dir.
Gruß
Hans
Zitat von: John am 09 Dezember 2013, 21:57:30
Klar kann man was machen.
Setzt den Sollwert so zeitig, dass du gegen 00:00 Uhr den Sollwert erreichst (war ja im Chart nicht der Fall).
Dazu wirst du mehrere Versuche brauchen, aber mit Hilfe der Charts gelingt das gut.
(ggf. musst du schon um 21:00 Uhr beginnen)
Dafür kannst du den Sollwert um 00:00 Uhr runternehmen, denn es darf ja kühler werden.
Es dauert nun auch wieder Stunden bis der Raum um 3 Grad runterkühlt, das sollte nachts auch kein Problem sein.
Der I-Anteil des Reglers wirds dir danken.
Alles klar, danke. Ich werde das mal versuchen!
Anbei noch ein Screenshot von heute mit p,i Kurve.
Grüße
Hallo fhainz,
sieht schon besser als als zu vor.
Der erhöhte P-Faktor schlägt gut durch,
das Ventil schiesst nun vollständig beim Sollwertsprung nach unten um 06:00 Uhr.
Vorschlag wie zuvor bei Hans Franz:
pidActorThreshold zwischen 5 und 10 einstellen
pidActorInterval auf 600-900 stellen (max alle 10..15 Minuten Stellausgang betätigen).
Der Regler darf ruhig in gröberen Schritten agieren.
Temperatur zu regeln ist ein langsames "Geschäft".
Zusätzlich solltest du eher damit beginnen den Raum aufzuheizen.
Gegen 00:00 Uhr ist das Ventil praktisch 100% offen, die Temperatur steigt kaum noch.
Der Sollwert wird nicht erreicht.
John
Ok danke.
Ich hab die 2 attribute gesetzt und beginne heute mit dem aufheizen um 19:00. Mal sehen wie es morgen aussieht!
Grüße
Hallo!
Die heutige Kurve sieht unter Tags nicht so gut aus. Es wird wärmer aufgeheizt als auf die Soll Temp.
Ich blick da noch nicht durch. An welchen Rädchen muss ich drehen?
Und um die 12 Grad zu erklären: Nach dem Lüften wurde nicht automatisch wieder auf die letzte Temp zurückgesetzt. Warum auch immer. Das muss ich mir erst ansehen.
Grüße
Hallo fhainz,
kannst du präzisieren, in welchem Zeitbereich du mit der Regelung nicht zufrieden bist.
Ich finde der Regler hat sein Geschäft so schlecht nicht gemacht.
Hast du um 06:30 das Fenster geöffnet ?
Der Raum kühlt zwischen 7 und 10 praktisch nicht ab. Aber das Thermostat macht immerhin komplett zu.
Der leichte Überschwinger um 10 nach Sollwertänderung ist akzeptabel.
John
Ja, ich hab um halb 7 das Fenster aufgemacht. Nachdem ich es geschlossen hatte sollte normalerweise ein script die letzte Temperatur vor dem lüften setzten. Ist aber nicht passiert. Warum auch immer.
Nachdem ich um halb 10 manuell die richtige Soll Temp gesetzt hatte war die Ist-Temperatur immer leicht höher als die Soll Temp. Rund 0.4-0.8 Grad. Ich weiß das sind jetzt Kleinigkeiten ;)
Grüße
Das was in der Nacht zwischen 00:00 und 06:00 Uhr bei dir passiert ist,
dürfte sehr selten zu sehen sein.
Über Stunden eine Regeldifferenz von praktisch 0.
Das war wohl eher Zufall.
Meine MAX-Thermostate sind übrigens was Übertemperaturen anbelangt wesentlich grosszügiger als dein PID-Regler.
Da treten teilweise Regeldifferenzen von 2 Grad auf .
Sehen wir uns den Überschwinger um 10:00 Uhr an.
Der I-Anteil stammt noch von der Nacht und ist identisch mit der Ventilstellung für 18 Grad Solltemperatur
bei abgesenkter Vorlauftemperatur.
Der passt natürlich tagsüber nicht mehr, denn nun ist die Vorlauftemperatur höher.
Daher der leichte Überschwinger. Aber der I-Anteil wird nun zusehends reduziert und der starke P-Anteil
greift sofort durch und prügelt das Ventil in den unteren Stellbereich.
Ich könnte damit gut leben.
John
PS:
pidActorThreshold und pidActorInterval haben sich gut bewährt. Die Regelgüte leidet offensichtlich kaum.
Alles klar. Ich denke ich kann auch gut damit leben.
Ich beobachte das jetzt ein paar tage dann meld ich mich nochmal!
Vielen dank für deine Hilfe!
Grüße
Ich möchte die Nutzer des PID20 Moduls bitten, ihre Erfahrungen hier zu veröffentlichen,
damit ich ein besseres Bild über die Anwendbarkeit gewinnen kann.
(fhainz hat dies schon erledigt)
Hilfreich wären hierbei Kurven , wie im Wiki dargestellt und ein Auszug der Parameter via "list <pid20>".
Es geht darum, zu beurteilen, wie sich das Modul bei unterschiedlichen Regelstrecken verhält.
Mir bisher bekannte Anwender:
Hans Franz
fgerhardt
Smooth
Im Voraus besten Dank für eure Zuarbeit.
John
Zitat von: John am 14 Dezember 2013, 11:45:32
Ich möchte die Nutzer des PID20 Moduls bitten, ihre Erfahrungen hier zu veröffentlichen,
damit ich ein besseres Bild über die Anwendbarkeit gewinnen kann.
Gerne:
Internals:
DEF CUL_WS_1:temperature stellantrieb.01:valve
NAME heizung.01
NR 305
NTFY_ORDER 50-heizung.01
STATE processing
TYPE PID20
Readings:
2013-12-14 14:59:10 actuation 19
2013-12-14 15:07:17 actuationCalc 17.2999999999999
2013-12-14 15:07:17 delta -0.300000000000001
2013-12-14 14:59:10 desired 20.5
2013-12-14 14:59:10 measured 20.8
2013-12-14 15:07:17 p_d 0
2013-12-14 15:07:17 p_i 24.8
2013-12-14 15:07:17 p_p -7.50000000000002
2013-12-14 15:07:17 state processing
Helper:
actor stellantrieb.01
actorCommand valve
actorErrorAction freeze
actorErrorPos 0
actorInterval 600
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 5
actorTimestamp 2013-12-14 14:49:09
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld -0.300000000000001
deltaOldTS 2013-12-14 15:06:07
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.25
factor_P 25
isWindUP
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor CUL_WS_1
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
alias Heizungen_1
pidActorInterval 600
pidActorTreshold 5
room Heizungen
Internals:
DEF CUL_WS_2:temperature stellantrieb.02:valve
NAME heizung.02
NR 325
NTFY_ORDER 50-heizung.02
STATE processing
TYPE PID20
Readings:
2013-12-14 15:09:17 actuation 0
2013-12-14 15:09:17 actuationCalc -19.3000000000002
2013-12-14 15:09:17 delta -1.4
2013-12-14 15:09:17 desired 17.0
2013-12-14 15:09:17 measured 18.4
2013-12-14 15:09:17 p_d 0
2013-12-14 15:09:17 p_i 15.6999999999997
2013-12-14 15:09:17 p_p -35
2013-12-14 15:09:17 state processing
Helper:
actor stellantrieb.02
actorCommand valve
actorErrorAction freeze
actorErrorPos 0
actorInterval 600
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 5
actorTimestamp 2013-12-14 14:49:09
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld -1.4
deltaOldTS 2013-12-14 15:07:14
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.25
factor_P 25
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor CUL_WS_2
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
alias Heizungen_2
pidActorInterval 600
pidActorTreshold 5
room Heizungen
Internals:
DEF CUL_WS_5:temperature stellantrieb.04:valve
NAME heizung.04
NR 370
NTFY_ORDER 50-heizung.04
STATE processing
TYPE PID20
Readings:
2013-12-14 15:01:49 actuation 29
2013-12-14 15:01:49 actuationCalc 29.2499999999999
2013-12-14 15:01:49 delta 0
2013-12-14 15:01:49 desired 18.0
2013-12-14 15:01:49 measured 18.0
2013-12-14 15:01:49 p_d 0
2013-12-14 15:01:49 p_i 29.2499999999999
2013-12-14 15:01:49 p_p 0
2013-12-14 15:01:49 state processing
Helper:
actor stellantrieb.04
actorCommand valve
actorErrorAction freeze
actorErrorPos 600
actorInterval 180
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 5
actorTimestamp 2013-12-14 14:41:46
actorValueDecPlaces 0
adjust
calcInterval 600
deltaGradient 0
deltaOld 0
deltaOldTS 2013-12-14 15:09:38
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.25
factor_P 25
isWindUP
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor CUL_WS_5
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
alias Heizungen_4
pidActorTreshold 5
pidCalcInterval 600
room Heizungen
verbose 1
heizung.01 und heizung.02 sind die Zimmer meiner Söhne. Und die sind hot. Anders kann ich mir das gelegentliche Überschwingen nicht erklären. :)
Gruß
Hans
Hallo Hans Franz
danke für deine Antwort.
Zitat
heizung.01 und heizung.02 sind die Zimmer meiner Söhne. Und die sind hot. Anders kann ich mir das gelegentliche Überschwingen nicht erklären.
Ich denke da gibts noch Optimierungs-Potential.
PID_1Die kurzeitige geringe Ventilöffnung um 11:30 Uhr bewirkt einen steilen Anstieg der Temperatur von ca. 2.5 Grad/h.
Anders verhält sich das System jedoch um 15:30 Uhr als ein massiver Sollwertsprung von 17 auf 21 Grad stattfindet.
Hier ist die Steigung der Temperatur wesentlich geringer als zuvor, obwohl das Ventil auf 70 Grad öffnet.
Hast du dafür eine Erklärung? (z.B. unterschiedliche Vorauftemperaturen)
Zum Zeitpunkt 15:30 Uhr:
Der massive Sollwertsprung von 17 auf 21 Grad führt zu einer Regeldifferenz von ca. 2.5 Grad.
Ich würde sagen, hier wäre eine Ventilöffnung von 100% angebracht.Alles was schnell gehen muss wird über den P_Faktor erledigt.
Der P-Faktor beträgt derzeit : 25 %/(Grad Regeldifferenz).
Bei 1 Grad Regeldifferenz liefert der P-Anteil 25 %. zu ActuationCalc.
Wir haben 2.5 Grad, also erhalten wir eine P-Anteil von ca. 65%.
Formel:
P-Anteil [%] = Regel-Differenz [Grad] * P-Faktor [%/Grad]Gleichzeit legt nun auch der I-Anteil los zu wachsen, (siehe Chart) das ist aber in dieser Phase noch kontraproduktiv, dazu später.
Wir verdoppeln gedanklich den P-Faktor auf 50%/Grad.
Nun würde der P-Anteil 130% betragen, das Ventil macht also komplett auf.
Der I-Anteil wächst nicht, da nun ActuationCalc >100% ( actorLimitUpper) ist und die Anti-Windup-Massnahmen greifen.
Erst wenn die Regeldifferenz < 2 Grad wird, wird der I-Anteil beginnen zu wachsen.
Der I-Anteil wächst ohnehin zu schnell. Er ist im wesentlichen für die Überschwinger ab 18:00 Uhr verantwortlich.
Also mein Vorschlag:
P-Faktor von 25 auf 50-75 setzen
I-Faktor von 0.25 auf 0.1 setzen
ActuationCalc = I-Anteil + P-Anteil
morgen sehen wir weiter.
John
Hallo John,
Danke für die Erklärung/Interpretation.
Ich habe für PID_1 die Werte geändert. Oder sollte ich das für die anderen PIDs auch schon machen?
Ich gebe allerdings zu bedenken, dass verschiedene Störfaktoren mitspielten: Um 12 Uhr schien gestern die Sonne ins Zimmer, abends war Zocken mit zwei Kumpel angesagt. Drei Jungmänner heizen! Also wird ein Fenster aufgerissen...
Ich beschränke mich daher noch aufs Beobachten der Plots. Deine Hilfe ist somit Gold wert.
Ein kleiner Fehler ist mir bei "Inbetriebnahme" im WIKI noch aufgefallen: Es müsste wohl "98_PID20.pm" heissen.
Gruss
Hans
Hallo John,
Die Änderungen (pidFactor_I 0.1, pidFactor_P 50) haben ja dramatische Auswirkungen. Für PID_1 die Werte geändert, bei PID_2 noch die Default-Werte.
Ist jetzt der p-Faktor nicht zu bestimmend ? Für mich sieht PID_2 erstmal gesünder aus.
Gruß
Hans
Hallo John,
Dein PID20 setze ich zur Steuerung eines Heizkreises für Fußbodenheizung ein.
Problemstellung: In einem Altbau mit vielen alten Heizkörpern muss ich relativ hohe Vorlauf-Temperaturen fahren. Diese sind für die Fußbodenheizung viel zu hoch. Deshalb wird aus dem Haupt-Heizkreis über einen motorisch betriebenen Mischer ein zweiter Heizkreis mit deutlich niedrigeren Vorlauftemperaturen abgezweigt. Dein PID20 steuert hier also einen 4-Wege-Mischer über zwei Aktoren. Aktuell debugge ich noch meine Mischer-Steuerungsroutine. Wenn ich hier fertig bin, poste ich hier die Plots.
PID20 ersetzt hier also eine professionelle Honeywell Centratherm, die ich eben nicht in die gesamte Hausautomatisierung (Anwesenheitssteuerung etc) einbinden konnte. Die ersten 2 Wochen Betrieb zeigen schon ohne Optimierung der Einstellwerte, dass PID20 mit einer solchen industriellen Lösung mithalten kann.
Herzliche Grüße
Christian
Hallo Hans,
ich stimme dir zu, die Änderungen sind dramatisch. Wir haben einen schwingenden Regler.
Dann ist einer der Faktoren zu hoch, in deinem Fall der p-Faktor.
Als Erstmassnahme p-Faktor auf 30 nehmen und schrittweise erhöhen, bis das Schwingen wieder einsetzt.
Dann die vorherige Einstellung wählen.
Hast du eine Erklärung dafür, dass es fast 1h dauert bis die Temperatur auf die sich öffnende Ventilstellung reagiert ?
(z.B. um 04:30 Uhr)
Aber dann mit einem extrem steilen Anstieg. Das ist ungewöhnlich.
Kann es sein dass dein Ventil eine Todzone hat (Bereich in dem keine Änderung der Regelgröße stattfindet)
D. h. das Ventil muss erst eine Mindestöffnung erreichen bis es überhaupt wirkt.
In diesem Fall müsste man pidActorLimitLower entsprechend anpassen.
Kannst du etwas mehr zu dein Heizsystem sagen:
Verlauf der Vorlauftemperatur ?
elektronisch geregelt Umwälzpumpe ?
Zweirohrsystem ?
Es handelt sich um herkömmliche Heizkörper, die über Konvektion arbeiten ?
In welcher Zeit ist die Vorlauftemperatur abgesenkt ?
Wie stabil ist die Vorlauftemperatur ?
John
Hallo Christian,
danke für deine Rückmeldung.
ZitatDein PID20 steuert hier also einen 4-Wege-Mischer über zwei Aktoren. Aktuell debugge ich noch meine Mischer-Steuerungsroutine. Wenn ich hier fertig bin, poste ich hier die Plots.
Das ist ja schon einen High-End-Anwendung.
Ich bin gespannt, ob sich PID20 bewährt.
John
Hallo John,
Ich befürchte, wir muten deinem armen PID-Regler bei mir viel zu :).
Für das zu späte Reagieren des Ventils(FHT8V) habe ich keine Erklärung.
Verlauf der Vorlauftemperatur ?
Müsste ich erst händisch dokumentieren.
elektronisch geregelt Umwälzpumpe ?
Ja. Wilo 4132452
Zweirohrsystem ?
Ja
Es handelt sich um herkömmliche Heizkörper, die über Konvektion arbeiten ?
Ja
In welcher Zeit ist die Vorlauftemperatur abgesenkt ?
22:30 -6:00
Wie stabil ist die Vorlauftemperatur ?
Tja, das ist der Punkt, der mir Sorgen macht:
Pelletofen versorgt 1000l-Speicher und scheint manchmal überfordert. Vor Wartung (alle 1.5t) bei Frostgraden ohne Sonne drehe ich schon mal alle Ventile für eine Stunde zu, um den Speicher und damit die Vorlauftemperatur zu halten.
Ich glaube, mit FHEM und einem noch zu findenden Sensor sollte ich die Vorlauftemperatur protokollieren.
Gruss
Hans
Hallo Hans
ZitatFür das zu späte Reagieren des Ventils(FHT8V) habe ich keine Erklärung.
Wie kalibrierst du den Stellantrieb ?
In der Bedienungsanleitung von FHT8V habe ich zu diesem Thema nichts gefunden.
Meine MAX-Ventile können das automatisch; nach Einlegen der Batterie und Bestätigung erfolgt das Kalibrieren des Stellbereiches.
Vielleicht kannst du es so rausfinden
- Ventilstellung auf 0 %
- Heizkörper abkühlen lassen
- Ventilstellung in 5% Schritten erhöhen und dabei prüfen, ob sich Heizkörper erwärmt, mit ausreichend Wartezeit
- Ventilposition merken, bei der sich HK erwärmt und bei pidActorLimitLower eintragen
2. zeitsparende Möglichkeit:
pidActorLimitLower nach und nach (1x pro Tag) um 5% erhöhen, Weiteres werden uns die Kurven zeigen.
John
Hallo John,
Wert des P-Faktors seit gestern ca. 13:00 Uhr auf 30. Scheint immer noch zu überschwingen oder interpretiere ich das falsch?
Habe jetzt den PID gestoppt, um die von dir angeregte Kalibrierung duchzuführen.
Gruß
Hans
Edit:
pidActorLimitLower auf 10 gesetzt da bei 15% Ventilöffnung der Heizkörper anfing warm zu werden
Hallo Hans,
den Sollwertsprung um 17:30 Uhr hat PID20 richtig gut hinbekommen, der Rest ist noch nicht so toll.
Reduziere den P-Faktor schrittweise um 5%. Ein verbleibendes Schwingen um 0.5 Grad ist akzeptabel.
Auch wenn wir die Todzone eliminiert haben, reagiert das System im unteren Bereich des Stellausgangs schon sehr massiv.
Daher sollten wir den Regler "feingliedriger" machen.
pidActorThreshold auf 2..3.
pidActorInterval von 600 auf 420
Man muss an vielen Schrauben drehen, aber es ist gut sie zu haben.
Hast du eine Erklärung dafür, warum die markierte Stelle eine so hohen Temperaturanstieg zeigt, obwohl das Verhalten des Stellgliedes wie zuvor ist.
(stark erhöhte Vorlauftemperatur ?)
John
Hallo John,
pidActorThreshold auf 2,
pidActorInterval auf 420,
pidFactor_P auf 25.
Der Temperaturanstieg ist wohl Folge der Sonneneinstrahlung = Störgrösse :).
Gruß
Hans
Hallo John,
Ich glaube, ich habe ihn kaputtgemacht :).
Nach stop und start bleibt actuation auf 10 bzw. jetzt 0 (habe actorLimitLower wieder auf 0 gesetzt) stehen. Delta bei 4, actuationCalc > 100.
Was kann das sein?
Internals:
DEF CUL_WS_1:temperature stellantrieb.01:valve
NAME heizung.01
NR 305
NTFY_ORDER 50-heizung.01
STATE processing
TYPE PID20
Readings:
2013-12-16 16:40:58 actuation 0
2013-12-16 16:50:04 actuationCalc 105
2013-12-16 16:50:04 delta 3.8
2013-12-16 16:40:58 desired 22.0
2013-12-16 16:40:58 measured 17.7
2013-12-16 16:50:04 p_d 0
2013-12-16 16:50:04 p_i 10
2013-12-16 16:50:04 p_p 95
2013-12-16 16:50:04 state processing
Helper:
actor stellantrieb.01
actorCommand valve
actorErrorAction freeze
actorErrorPos 0
actorInterval 420
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 0
actorThreshold 2
actorTimestamp 2013-12-16 16:40:58
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient -0.00112945139341439
deltaOld 3.8
deltaOldTS 2013-12-16 16:48:37
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.1
factor_P 25
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor CUL_WS_1
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
alias Heizungen_1
pidActorInterval 420
pidActorLimitLower 0
pidActorTreshold 2
pidFactor_I 0.1
pidFactor_P 25
room Heizungen
Gruß
Hans
Hallo Hans,
ich glaub du bist einem Bug auf die Spur gekommen.ZitatReadings:
2013-12-16 16:40:58 actuation 0
2013-12-16 16:50:04 actuationCalc 105
isWindUP 1
Versuch den Regler aus dem Windup rauszukriegen, in dem zu den Sollwert temporär in die Nähe vom Istwert setzt.
Wenn er sich gefangen (Windup inkativ) hat, sollte er weiterlaufen.
Dann kannst du den Sollwert wieder passend setzen.
Start/Stop muss nicht sein, wenn man die Attribute ändert.
Aber zum Fehler finden ist es gut so.
John
Hallo John,
Stop war wegen Kalibrierung.
Sehe aber gerade. das pidActorLimitUpper auf 0 steht. Das kann natürlich auf meine Paddeligkeit zurückzuführen sein, glaube es aber eigentlich nicht.
Aus dem Windup war er gerade 'raus, bei setzen des Sollwertes aber auch wieder drin.
2013-12-16 17:31:25 actuation 0
2013-12-16 17:33:26 actuationCalc 32.65
2013-12-16 17:33:26 delta 1.3
2013-12-16 17:31:25 desired 21
2013-12-16 17:31:25 measured 19.6
2013-12-16 17:33:26 p_d 0
2013-12-16 17:33:26 p_i 0.15
2013-12-16 17:33:26 p_p 32.5
2013-12-16 17:33:26 state processing
isWindUP 1
Ich muss ihn jetzt ersteinmal stoppen. Meinem Sohn ist es zu kühl. ::)
Gruß
Hans
Hallo Hans
kann es sein dass du noch mit der alten Version fährst ?
die aktuelle ist 1.00c (siehe auch WIKI)
http://forum.fhem.de/index.php/topic,17067.msg111828.html#msg111828 (http://forum.fhem.de/index.php/topic,17067.msg111828.html#msg111828)
Auszug aus Change-Log
Zitat
# V 1.00.c
# 03.12.2013 - bug: pidActorLimitUpper wrong assignment
In der Vorgängerversion war genau der Fehler drin.
John
Zitat von: John am 16 Dezember 2013, 20:33:48
kann es sein dass du noch mit der alten Version fährst ?
Mann ,mann,mann. Ja klar. Danke
Hans
Hallo John,
bei meinem Projekt "Mischersteuerung" mit PID20 musste ich umdisponieren. Die Temperaturmesswerte für den Vorlauf im Fußbodenheizkreis liess ich mir bei Homematic Sensor funken. Die Werte kamen alle drei Minuten und da der Vorlauf des Hauptkreises sehr schnell durchaus zwischen 40 und 60 Grad sich ändert, ist PID20 gar nicht mehr aus den Extremwerten rausgekommen, hat den Nebenkreis auf dem niedrigen Vorlaufniveau recht stabil gehalten.
Ich habe jetzt mit 1-Wire einen Sensor dran, der mir aktuell alle 30 Sekunden die Messwerte liefert. Damit kann PID20 viel näher um den Sollpunkt arbeiten.
Ich werde weiter berichten, aber glaube nun auf dem richtigen Weg zu sein.
Christian
Hallo Christian,
wenn die Prozessänderung so schnell ist,
solltest du in Betracht ziehen, das Attribut pidCalcInterval (default 60 Sekunden) zu verkleinern.
Dies ist der Bewertungszyklus beim PID.
Allerdings habe ich hier noch einen Fehler entdeckt.
Also bitte noch die nächste Version abwarten, bevor du dieses Attribut änderst.
John
Moin, John,
zu spät! :-)
Hatte schon herabgesetzt, weil mir die Idee gekommen war (sowohl ActorInterval (60 s, weil ein kompletter Mischerlauf 95 s dauert) wie auch CalcInterval auf 30 s). Wir werden mal sehen. Die häufigeren Meßwerte führten zumindest dazu, dass die Aktorwerte systematischer schwankten (also nicht ständig zwischen den beiden Polen des Vierwegeventils hin und her gefahren wird, sondern ein Annäherungsprozess an einen Wert, um den herum jetzt in kleineren Schritten iteriert wird, zu erkennen ist. Dieser Punkt gleitet dann mit der steigenden oder fallenden Temperatur des Haupt-Vorlaufs, was schon sinnig erscheint).
Bin auf Deine Version e gespannt. Bis dahin: Schönes Festtagszeit...
Herzliche Grüße aus dem aktuell windigen Norden
Christian
Hallo John,
Kannst du noch 'mal einen Blick darauf werfen?
PID_1:
pidActorInterval 420
pidActorTreshold 2
pidFactor_I 0.1
pidFactor_P 25
PID_2:
pidActorInterval 600
pidActorTreshold 5
pidFactor_I default
pidFactor_P default
PID_1 schwingt zu sehr oder täusche ich mich? pidFactor_P ist aber gleich. Was tun?
Gruß
Hans
Die Kurve von gestern bereitet mir auch Kopfzerbrechen.
Bis 13:00 Uhr so wie ich es erwarte, dann Soll-Absenkung wegen Wartung des Ofens.
Ab 20:00 Uhr beginnt das Schwingen ohne Änderung der Parameter von aussen.
Gruß
Hans
Hallo Christian und alle anderen Anwender von PID20,
anbei die Version V 1.00.d
Bugfix:
betrifft diejenigen, die pidCalcInterval gändert haben. Hierbei wurde auch actorErrorPos mit dem Wert von pidCalcInterval gesetzt.
John
PS: Dateianhang gelöscht, da Modul in FHEM integriert ist
Hallo Hans
zu deinem Beitrag #58
Ich finde der Einsatz von pidActorLimitLower hat sich positiv ausgewirkt. Die Überschwinger liegen nun im Bereich von 0.8 Grad.
Vorher waren wir bei 1.5 Grad.
Du solltet pidActorLimitLower in Schritten noch vergrößern bis du die Einsatzschwelle von 15% erreichst, die du ermittelt hast.
Die Periodendauer für einen Schwingungsvorgang beträgt ca. 1h. Es dauert ca. 20 Minuten bis die Temperatur überhaupt ansteigt,
das erscheint mir relativ lange.
zum Beitrag #59
na ja, ab 20 Uhr machen sich die Änderungen des Stellausgangs bemerkbar (vorher war die Temperatur zu hoch).
Anbei noch ein Bild meines MAX-Reglers (also kein PID20). Der schwingt auch.
Ich denke mit dem Schwingen im Bereich von +/- 0.5 Grad kann man leben.
John
Guten Morgen, John,
vielen Dank für die rasche Korrektur. Wirkliche Erfahrungen werde ich Dir allerdings erst in ein paar Tagen liefern können. Über Weihnachten ist der WAF sehr wichtig, und der ist nicht nur vom kuscheliger Wärme beinflusst :-)
Gute Festtage
Christian
Im Wiki habe ich die Erkenntnisse zum Stellglied nochmals zusammengefaßt:
http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler#Temperatur_im_Raum_steigt_nicht_oder_stark_verz.C3.B6gert.2C_was_kann_ich_tun_.3F (http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler#Temperatur_im_Raum_steigt_nicht_oder_stark_verz.C3.B6gert.2C_was_kann_ich_tun_.3F)
John
Guten Morgen, John,
willkommen im Jahr 2014 - möge es alle Wünsche erfüllen :-)
Wie gesagt, experimentiere ich bei meiner Fussbodenheizkreis-Mischerregelung mit Hilfe von PID20 noch immer - ich habe in den letzten Tagen die Parameter verändert, um das doch sehr häufige und wilde Stellen des 4-Wege-Mischers zu dämpfen. Auf diesem Weg bin ich gut vorangekommen. Doch nun habe ich plötzlich Fehlermeldungen im zentralen Log.
Zunächst das Listing meines Regelers:
Internals:
CFGFN ./FHEM/heizung.cfg
DEF T_Vorlauf_FBH:temperature FBH_Stellwert
NAME PID_Mischer_FBH
NR 556
NTFY_ORDER 50-PID_Mischer_FBH
STATE processing
TYPE PID20
Readings:
2014-01-01 09:57:19 actuation 66
2014-01-01 09:57:19 actuationCalc 65.7542250000012
2014-01-01 09:57:19 delta 1.4975
2014-01-01 09:57:19 desired 38
2014-01-01 09:57:19 measured 36.5025
2014-01-01 09:57:19 measured_avg_day 31.7
2014-01-01 09:57:19 measured_avg_month 30.0
2014-01-01 09:57:19 measured_cum_day 1137871.3475
2014-01-01 09:57:19 measured_cum_month 3670687.34749999
2014-01-01 07:04:38 measured_max_day 53.3
2014-01-01 07:04:38 measured_max_month 53.3
2014-01-01 05:34:12 measured_min_day 23.2
2014-01-01 05:34:12 measured_min_month 23.2
2014-01-01 09:57:19 p_d 0
2014-01-01 09:57:19 p_i 50.7792250000012
2014-01-01 09:57:19 p_p 14.975
2014-01-01 09:57:19 state processing
Helper:
actor FBH_Stellwert
actorCommand
actorErrorAction freeze
actorErrorPos 0
actorInterval 100
actorKeepAlive 18000
actorLimitLower 0
actorLimitUpper 100
actorThreshold 3
actorTimestamp 2014-01-01 09:57:19
actorValueDecPlaces 0
adjust
calcInterval 100
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.1
factor_P 10
isWindUP
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor T_Vorlauf_FBH
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
group Fussbodenkreis
pidActorInterval 100
pidActorKeepAlive 18000
pidActorTreshold 3
pidActorValueDecPlaces 0
pidCalcInterval 100
pidFactor_D 0
pidFactor_I 0.1
pidFactor_P 10
room Heizung
verbose 0
Die Fehlermeldung die nun bei jeder Änderung des Stellwertes kommt:
Zitat2014.01.01 09:55:38 2: CUL_HM set FBH_Mischer_weniger on-for-timer 7
Use of uninitialized value in sprintf at ./FHEM/98_PID20.pm line 660.
2014.01.01 09:57:18 2: CUL_HM set FBH_Mischer_mehr on-for-timer 11
Use of uninitialized value in sprintf at ./FHEM/98_PID20.pm line 660.
2014.01.01 09:58:59 2: CUL_HM set FBH_Mischer_weniger on-for-timer 9
Use of uninitialized value in sprintf at ./FHEM/98_PID20.pm line 660.
Wie Du siehst, wird ein Stellwert errechnet und von meiner kleinen Routine dann das Delta für die konkrete Steuerung des Stellmotors ausgeführt. Aktuell sind die Schwankungen des Vorlaufes sowie der Stellbefehl so gering wie selten zuvor.
Leider habe ich bei meinen vorherigen Experimenten nicht alle Parameter des Reglers dokumentiert.
FBH_Stellwert ist ein Dummy, mit dem ich "Deine" Stellwerte aufnehme, dann das Delta ermittele, mit dem ich dann den Stellmotor konkret auf den von "Deinem" Modul gewünschten Wert verändere.
Herzliche Grüsse
Christian
Hallo Christian,
ich kann den Fehler leider bei mir nicht nachvollziehen.
Daher habe ich eine neue Version 1.00.e angefügt mit erweiterter Debug-Ausgabe.
Bitte Attribut verbose des PID auf 4 stellen via
attr PID_Mischer_FBH verbose 4
FHEM neu starten und Log an mich zurück.
John
PS: Dateianhang gelöscht, da Modul in FHEM integriert ist
Hallo PIDler,
habe jetzt auch einen Versuch gestartet, eine Reglung zum Laufen zu bringen - mit folgendem Code gemäß Wiki:
define Stell.Br FHT8V 5655
#
define PID.Br PID20 fht.Buero:measured-temp Stell.Br
attr PID.Br pidActorInterval 900
attr PID.Br pidActorTreshold 8
attr PID.Br pidActorValueDecPlaces 0
attr PID.Br pidFactor_I 0.2
attr PID.Br pidFactor_P 50
define PID.PID.File FileLog ./log/PID.PID-%Y.log PID\.PID
attr PID.PID.File logtype text
Abweichend vom Wiki nutze ich als Istwert den Messwert eines FHT80b, der nicht mit dem FHT8V verbunden ist und eben den FHT8V.
Fehler wurden zwar keine gemeldet - doch es tut sich auch nichts. Das Logfile bleibt leer.
Fehlt da was?
Grüße zum Neuen Jahr!
Hallo Vorhand,
Da liegt der Hund begraben:
define PID.PID.File FileLog ./log/PID.PID-%Y.log PID\.PID
gemäß CommandRef zu FileLog
define <name> FileLog <filename> <regexp>
<regexp> ist dein Freund. Das was du hier eingetragen hast, kommt einfach niemals als Ereignis.
Aber im FHEM-Logfile sollten schon einige Einträge vom PID20 zu finden sein und ebenso im Monitor.
John
Hi John,
bei meinem Projekt geht es darum, in einem Altbau mit einem Heizkreis mit relativ hohen Vorlauftemperaturen einen Heizkreis für eine Fußbodenheizung mit deutlich niedrigeren Vorlauftemperaturen auszuschleusen.
Hydraulisch läuft das über einen Vierwegemischer und eine eigene (Hocheffizienz-)Pumpe, die den Fußbodenheizkreis bedient. Im Hauptkreis schwanken die Vorlauftemperaturen zwischen 40 und 75 Grad, im Fussbodenkreis sollen sie so begrenzt werden, dass die Fußbodentemperatur wegen des Laminats keinesfalls 28 Grad überschreitet (verprobt mit einem Fühler im Fußboden, der ein THRESHOLD bedient, der die Pumpe anhält), zugleich aber die Raumtemperatur von 21 Grad schnell (für eine träge Fussbodenheizung) erreicht wird. Aktuell experimentiere ich mit einem Vorlauf im Fußbodenkreis von 36 Grad. Und so sieht dann der Tag wie im Anhang aus.
Um 5.30 Uhr wird die desired-temp des PID-Reglers von 16 auf 36 Grad hochgestellt. Die Actuation wird über eine kleine Routine in die rechts-links-Bewegungen des Mischers umgesetzt. Aktuell sind mir die Mischerbewegungen noch zu "hektisch", aber die Vorlauftemperatur pendelt schon hübsch im Bereich der 36°. Sobald/solange der Raum 21 Grad hat, wird über einen weiteren Threshold die Pumpe angehalten. Ab 15.30 Uhr wird wieder "Nachtabsenkung" eingeschaltet, weil der aufgeheizte Fußboden noch für die Restnutzung lang genug Wärme abgibt.
Sachdienliche Hinweise zum Setzen der Parameter sind hochwillkommen.
Christian
Hallo Christian
ein
list DeinPid
wäre hilfreich, damit wir alle Parameter kennen.
Die Dynamik der Temperatur ist bemerkenswert. Dennoch meine ich der P-Faktor ist zu gross. (ohne diesen zu kennen)
Ist dir klar, dass du dir in der Phase der Nachtabsenkung den tagsüber gelernten I-Anteil wieder "verspielst".
Da gibts ja eigentlich nichts mehr zu regeln.
Der I-Anteil ist so etwas wie ein angelernter Arbeitpunkt für den P-Anteil, um den dieser pendeln kann.
Aber der I-Faktor scheint sehr klein, vielleicht zu klein.
Mögliche Verbesserungen:
PID in der Absenkphase auf Stop nehmen, zumindest solange der Istwert>Sollwert
Fragen:
in welchen Bereich darf den die Vorlauftemperatur pendeln, oder welche Regelabweichung wäre akzeptabel ?
John
PS:
Noch eine Frage: hängt das "Überleben" deines Laminats von einem lauffähigen FHEM ab ?
Hallo John,
die Idee mit dem Start/Stopp werde ich versuchen, schnellstmöglich umzusetzen. War mir eigentlich klar, war ich aber irgendwie drüber weggekommen. Die Schwankungen der Vorlauftemperatur im FBH-Kreis kann ich nur empirisch ermitteln. Ich befürchte, sie sollte nicht über 55 Grad steigen.
Das Listing:
Internals:
CFGFN ./FHEM/heizung.cfg
DEF T_Vorlauf_FBH:temperature FBH_Stellwert
NAME PID_Mischer_FBH
NR 554
NTFY_ORDER 50-PID_Mischer_FBH
STATE processing
TYPE PID20
Readings:
2014-01-02 22:05:32 actuation 0
2014-01-02 22:07:12 actuationCalc -120.840774999999
2014-01-02 22:07:12 delta -17.5025
2014-01-02 22:05:32 desired 16
2014-01-02 22:05:32 measured 33.565
2014-01-02 22:05:32 measured_avg_day 33.3
2014-01-02 22:05:32 measured_avg_month 32.2
2014-01-02 22:05:32 measured_cum_day 2648469.20499999
2014-01-02 22:05:32 measured_cum_month 8120733.26750007
2014-01-02 07:12:22 measured_max_day 46.9
2014-01-01 12:28:11 measured_max_month 53.8
2014-01-02 05:41:53 measured_min_day 21.4
2014-01-02 05:41:53 measured_min_month 21.4
2014-01-02 22:07:12 p_d 0
2014-01-02 22:07:12 p_i 54.1842250000013
2014-01-02 22:07:12 p_p -175.025
2014-01-02 22:07:12 state processing
Helper:
actor FBH_Stellwert
actorCommand
actorErrorAction freeze
actorErrorPos 0
actorInterval 100
actorKeepAlive 18000
actorLimitLower 0
actorLimitUpper 100
actorThreshold 3
actorTimestamp 2014-01-02 19:25:01
actorValueDecPlaces 0
adjust
calcInterval 100
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.1
factor_P 10
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor T_Vorlauf_FBH
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
group Fussbodenkreis
pidActorInterval 100
pidActorKeepAlive 18000
pidActorTreshold 3
pidActorValueDecPlaces 0
pidCalcInterval 100
pidFactor_D 0
pidFactor_I 0.1
pidFactor_P 10
room Heizung
verbose 0
Herzliche Grüße
Christian
Hallo Christian,
warum hast du pidCalcInterval von 60 auf 100 hochgenommen ?
Bei der Schnelligkeit der Erwärmung hätte ich eher mit einer Reduzierung gerechnet,
die ich auch für sinnvoll erachten würde.
Vorschläge in folgender Reihenfolge :
a.) Wenn möglich pidCalcInterval verkleinern (30 Sek.), damit der PID besser auf die hohe Dynamik reagieren kann.
Prozess beobachten.
b.)
Ich schlage vor wie zuvor schon angedeutet, dem I-Anteil eine grössere Gewichtung zu geben (I-Faktor auf 0.2) und den P-Anteil zu
reduzieren (6 statt 10).
Die schwingende Bereiche weisen auf eine zu hohe Verstärkung hin bzw. zu langsame Reaktion (wg. pidCalcInterval) hin
John
Moin, moin,
PIDCalcInterval hatte ich hochgenommen, weil der Mischer für eine Vollbewegung 95 Sekunden braucht. Ich hatte mit frühren P/I-Werten die Beobachtung gemacht, dass es häufig Vollausschläge gab, die noch nicht abgearbeitet waren, als schon die nächste gegenläufige Bewegung errechnet wurde.
Werde Deine Werte mal ausprobieren, ich hatte mich schrittweise zu den bisherigen, im Vergleich zu Deinen Vorschlägen ja noch großen P/I-Werten gearbeitet und dabei dann den PIDCalcInterval aus den Anfangszeiten stehen gelassen.
Ich merke, dass ich das Wirkungsmechanismen des Reglers noch nicht ausreichend verstanden habe. Du hilfst mir vor allem auch mit der Erklärung Deiner Vorschläge sehr gründlich weiter!
Gruß
Christian
Hallo Christian
ZitatPIDCalcInterval hatte ich hochgenommen, weil der Mischer für eine Vollbewegung 95 Sekunden braucht. Ich hatte mit frühren P/I-Werten die Beobachtung gemacht, dass es häufig Vollausschläge gab, die noch nicht abgearbeitet waren, als schon die nächste gegenläufige Bewegung errechnet wurde.
Dein System hat ein hohe Reaktionsgeschwindigkeit.
Beim mir benötigt ein Sollwertsprung von 2..3 Grad Raumtemperatur ca. 1.5 bis 2 h, damit der Raum diese Temperatur tatsächlich erreicht.
(Istwert=Sollwert)
Bezogen auf 2 Stunden erhält der Regler 120x die Gelegenheit (pidCalcInterval=60) die Situation zu bewerten und zu korrigeren.
Das kann er somit in kleinen Schritten auch tun.
Nehmen wir an, du gibst im nur noch 2x pro Stunde diese Möglichkeit.
Dann werden sich grosse Regeldifferenzen aufbauen, da der Regelalgorithmus viel zu selten die Möglichkeit hat, die sich ändernden Größen
zu bewerten und zu korrigieren.
Ein schwingendes System ist das Ergebnis, das mit -100% .. +100% arbeitet.
Und das nur deswegen, weil der Regler viel zu selten "bewerten" kann.
Man muss sich also die Änderungsgeschwindigkeit des Istwertes ansehen. Je steiler die Transienten, umso schneller sollte PID bewerten.
Es gibt dabei eines zu berücksichtigen:
pidCalcInterval wirkt nicht direkt auf den p-Anteil, aber auf den I-Anteil, damit der häufigeren Bewertung nun auch häufiger integriert wird.
Also bitte nicht beides gleichzeitig ändern, sondern immer nur einen Parameter, beobachten, dann den nächsten.
Versuch die maximale Steigung der Temperatur aus deinen Charts rauszufinden, dann haben wir einen Anhaltspunkt für
die Dimensionierung zu pidCalcInterval.
John
Muß oder soll ein externer Tempgeber eingesetzt werden oder kann ich auch die "desiredTemperature" des Max Thermostates selbst verwenden?
Hallo stgeren,
ZitatMuß oder soll ein externer Tempgeber eingesetzt werden oder kann ich auch die "desiredTemperature" des Max Thermostates selbst verwenden?
ganz schlau werde ich aus deiner Frage nicht:
Ein Temperaturgeber liefert den Istwert für den Regler, desiredTemperature hingegen stellt den Sollwert des Max-Thermostaten dar.
Wie geht das zusammen ?
PID20 erwartet einfach ein Reading für den Istwert, woher dieses kommt ist völlig unerheblich.
Da desiredTemperature ein Reading vom Max-Thermostat ist, kannst du diese als Istwert verwenden.
Ob das Sinn macht ist eine andere Frage.
John
Moin, John,
Deine Tipps haben mein PID20 entscheidend vorangebracht (und mein Verständnis auch). Die Stellbefehle sind deutlich kleiner geworden, die Solltemperatur wird wesentlich enger eingehalten. Noch schlagen die Flanken des Haupt-Vorlaufes durch, wenn der Brenner anspringt. Aber ich wäre mit meinen zaghaften Veränderungen noch lange nicht in die Nähe dieses Ergebnisses gekommen. Bisher war ich ja auch nicht vorangekommen, weil ich ja den Lernerfolg eines jeden Tages immer wieder verloren hatte...
Den heutigen Stand habe ich angefügt.
Herzliche Grüße
Christian
Hallo Christian,
das ist ja ein erfreuliches Ergebnis.
Wie sehen die aktuellen Parameter aus ?
John
Ja, John, Deine Argumentation (vor allem in Bezug auf die Berechnungshäufigkeit) war so überzeugend, dass ich PIDActorInterval auf 30 Sekunden gestellt habe und I-Faktor auf 0.2 sowie P-Anteil auf 6.
Ich guck mir das jetzt noch einmal an und will noch Deinen Vorschlag nachvollziehen, das Sensor- und Berechnungsintervall vielleicht noch kürzer zu machen (ist ja bei 1-Wire kein wesentliches Problem), damit PID20 maximales Futter bekommt.
Es macht richtig Spaß jetzt in einem Sprung soviel näher an ein gutes Regelergebnis gekommen zu sein.
Grüße
Christian
Hi,
ich habe mal ein paar Fragen zu dem PID20-Regler:
* Kann man das Teil auch mit dem neuen Homematic HM-CC-RT-DN Stellantrieb einsetzen? Beim HM-CC-RT-DN kann man keine prozentuale Ventilöffnung einstellen, sondern nur Ist und Solltemperatur... Ich würde die gerne nehmen, da ich ein HM-CFG-LAN btreibe und nicht auf MAX! umsteigen will...
* Ist der Regler selbstlernend und speichert er die Konstanten automatisch ab?
* Welches Funk-Raum-Thermometer wird empfohlen (433 MHZ oder HM)?
* Ich will 2 Räume mit FBH damit regeln. Niedrigenergiehaus, d.h. extrem träge. Mir geht es eigentlich im wesentlichen darum, abends die Kinderzimmer runterzukühlen...
Danke!
dero
Hi dero ,
ich versuch mal deine Fragen zu beantworten
(zu den Homematic Komponenten habe ich keine Erfahrungen)
ZitatKann man das Teil auch mit dem neuen Homematic HM-CC-RT-DN Stellantrieb einsetzen
Laut Wiki ist ja da HM-CC-RT-DN kein reiner Stellantrieb, sondern ermittelt den Istwert selbst und regelt auch selbst.
D.h. er hat den Regler schon intus.
So stellt sich die Frage, warum dann noch ein PID20 eingesetzt werden soll.
Wenn du ihn trotzdem einsetzen willst brauchst du
- ein Reading das den Istwert beschreibt
- ein Actuator-Device, das das Stellglied realisiert
Wenn du auf den Stellausgang vom HM-CC-RT-DN nicht direkt Einfluss nehmen kannst, sind die Voraussetzungen nicht gegeben.
Zitat
Ist der Regler selbstlernend und speichert er die Konstanten automatisch ab?
Ja, die Konstanten werden gespeichert, PID20 ist ein klassischer PID-Regler.
Wenn du den angelernten I-Anteil als selbstlernenden Regler interpretierst, dann ist er einer.
ZitatWelches Funk-Raum-Thermometer wird empfohlen (433 MHZ oder HM)?
Hier gibts keine Empfehlung. Seitens des PID20 kann praktisch jedes numerische Reading verwendet werden.
Die Auswahl hängt wohl eher vom der Dynamik der zu regelnden Strecke ab.
ZitatMir geht es eigentlich im wesentlichen darum, abends die Kinderzimmer runterzukühlen.
Wenn das Teil ein Wochenprogramm hat, kannst du dies doch damit realisieren.
Ansonsten gibt es noch das Modul Heating_Control, mit dem du zeitabhängig Sollwerte automatisiert setzen kannst.
John
Danke!!!
Okay, dann heißt es entweder MAX oder kein PID20...
Ich baue erstmal meine alten FHT80b an, mal sehen, wie gut die laufen...
dero
Hi John,
habe das Modul mit ein paar FHT8V direkt am CUL in Betrieb und muss sagen, funktioniert sehr gut! Die Verbesserungen gegenüber dem "normalen" PID.Modul sind sehr nützlich. Danke dafür!!
Hallo d-man,
besten Dank für die Rückmeldung.
Vielleicht könntest du noch den einen oder anderen Chart hier reinstellen, damit wir auch sehen, ob das Lob begründet ist.
John
Hallo John,
wäre es sehr vermessen, dich zu bitten, noch einige Erklärungen der drei wesentlichen Parameter(P,I und D) hier oder besser noch im Wiki zu verfassen?
Im Netz steht ja einiges zum PID-Regler, aber leider auch viel Unausgegorenes, Falsches oder auf einem Niveau, das ohne regen Besuchs von Vorlesungen zur Regelungstechnik kaum zu verstehen ist. Die Spreu vom Weizen zu trennen fällt zumindest mir immer noch schwer :'(.
Welchen Sinn macht der D-Faktor? In meiner Simulation (Tabellenkalkulation) scheint er einen dämpfenden Einfluss zu haben. Ist er in einer doch sehr trägen Heizungsregelung sinnvoll?
Gruß
Hans
Hallo Hans,
alle 3 Übertragungslieder (P,I,D) haben als Eingangsgröße die Regeldifferenz:
R-Diff = Sollwert-Istwert
Alle 3 Übertragungsglieder liefern ihren Anteil für den Reglerausgang (Vorgabe für das Stellglied in %)
Reglerausgang = P-Anteil + I-Anteil +D-Anteil
Berechnung P-Anteil
P-Anteil = R-Diff * P-Faktor
Also einfach eine lineare Gleichung. Der Zusammenhang von P-Anteil und R-Diff ist proportional.
Die Einheit vom P-Faktor ist bei Temperatur-Regelung % pro C°.
Beispiel: P-Faktor=50 %/C°, Regelabweichung 0.5, ergibt einen P-Anteil von 25%
Andersherum gedacht benötigt man eine Regeldifferenz von 2 Grad, damit der P-Anteil +/-100% wird,
und somit das Ventil voll auf/zu -fährt.
Bei den herkömlichen Thermostatköpfen spricht man hier von 2K-Ventilen, die eine Regeldifferenz von 2 Kelvin benötigen,
damit sie voll auffahren.
Der P-Anteil hängt nicht von der Zeit ab, er reagiert sofort auf eine sich ändernde Regeldifferenz und zwar proportional über
den P-Faktor und liefert so seinen Anteil am Reglerausgang.
Er ist für die schnelle Reaktion auf die Änderung der Regelabweichung zuständig.
Später mehr zum I-Glied und D-Glied.
John
PS: wie läuft es den mit deinem PID-Regler ?
Hallo John,
Danke für die Erklärungen.
Auch wenn dein Wiki zum PID20 schon umfangreich ist, sind solche Erläuterungen, so glaube ich, essentiell.
Einfach intuitiv an Parametern zu schrauben verbietet sich beim PID irgendwie.
Antworten auf Fragen wie "Wie erreiche ich ein schnelleres Ansprechen(P-Faktor?)?" oder, aktuell bei mir jetzt "Wie stelle ich auf Grund von Problemen den I-Anteil(='Gedächtnis'?) zurück?" machten sich im Wiki wie evtl auch einige Beispielplots hervorragend.
Schön fände ich es, wenn mehr Nutzer ihre Charts hier hereinstellen würden, denn nur mit Erfahrung im Interpretieren derselben lässt sich der Regler mAn individuell optimieren.
Rein subjektiv arbeitet der PID bei mir hervorragend, soll heißen: Das Wärmeempfinden ist gut.
Aber beim Betrachten der Charts stellt sich oft dieses Gefühl ein: "Mist! Ich kenn' mich damit zu wenig aus!" . Vielleicht geht es anderen genauso? Soweit ich das beurteilen kann, ist aber doch ein PID-Regler die sinnvollste Art einer Heizungssteuerung, oder?
Aktuell habe ich auf Grund der herrschenden Minusgrade mit dem Problem der schwankenden Vorlauftemperatur zu kämpfen. Da kann der PID nicht gegenan regeln.
Deswegen im Anhang Charts vom 23. diesen Monats. Dem Phänomen, das beim PID_1 die IST-Temperatur über der SOLL-Temperatur bleibt, bin ich durch Verändern von pidActorLimitLower auf der Spur. Oder liege ich falsch.
Bei PID_4 fällt mir öfter auf, dass die Soll-Temperatur nicht ganz erreicht wird, weil der Stellantrieb zu früh wieder zu fährt. Ich habe mich aber noch nicht getraut, viel mit den Einstellungen herumzuspielen.
Der Peak gegen 2:30 Uhr ist wohl auf ein hartes "kill -9 fhem" zurückzuführen. ::)
Bei gleichbleibender Vorlauftemperatur ist das Erstaunen beim Blick auf die Thermometer, wie genau die Temperatur jetzt eingehalten wird, oft beträchtlich. Schon geil. :)
PID_1:
factor_D 1
factor_I 0.1
factor_P 25
PID_2,PID_4:
factor_D 0
factor_I 0.25
factor_P 25
Gruß
Hans
Hallo Hans
ich dank dir für den ausführlichen Bericht.
Zu deinen Themen
ZitatAktuell habe ich auf Grund der herrschenden Minusgrade mit dem Problem der schwankenden Vorlauftemperatur zu kämpfen. Da kann der PID nicht gegenan regeln..
Im Idealfall sollte es so sein, dass der Raumregler (PID) nichts davon mitbekommt, wenn es kälter/wärmer wird, da ja die Vorlauftemperatur über die Kennlinie abhängig von der Aussentemperatur geführt wird.
Bei gleicher Ventilstellung wird mehr Wärme abgegeben, aber durch die höhere Differenztemperatur (Innen zu Aussen) wird auch mehr Wärme durch die Aussenwände abgegeben.
Eine zu hohe Vorlauftemperatur wirkt wie eine Erhöhung des P-Faktors. Schon bei geringer Ventilöffnung wird ein hohe Wärmemenge zugeführt.
Ausserdem ist die Änderung der Aussentemperatur normalerweise ein langsamer Vorgang, den der PID-Regler klaglos mitmachen sollte.
Die Frage ist, warum bei PID_1 ab 20:00 Uhr die Temperatur steigt, obwohl die Ventilstellung kaum verändert wurde.
(Kachelofen, Erhöhung der Vorlauftemperatur wegen Brauchwasserladung ?)
ZitatDem Phänomen, das beim PID_1 die IST-Temperatur über der SOLL-Temperatur bleibt, bin ich durch Verändern von pidActorLimitLower auf der Spur.
pidActorLimitLower splielt eigentlich nur im unteren Stellbereich eine Rolle (Begrenzung nach unten).
Das sehe ich nicht als Erklärung da die Stellposition stets>30% liegt.
Das Schwingen von 04:00 bis 16:00 Uhr ist absolut normal, da sich die Regelung hier nur noch im Stellbereich von 0..10% arbeiten kann
(wg. des niedrigen Sollwerts). Der untere Bereich des Ventils ist eher nicht linear, hier kann der PID nur schwer regeln.
(Dasselbe Verhalten haben auch meine MAX-Thermostate).
Der Sollwertsprung von 4 Grad um 16 Uhr ist schon sehr gross. Ich rechne im Mittel mit 1 Grad/Stunde, das schafft deiner in 2.5 h.
Zu PID_2 ist nicht viel zu sagen. Um 19:00 Uhr wurde wohl das Fenster geöffnet.
PID_4 ist etwas schwach auf der Brust. Sieht man schon in der Ruhephase bis 11:00 Uhr. Nur wenig Schwingungsneigung.
Dafür schafft er eben auch den Sollwertsprung von 15:00 Uhr nicht.
Den P-Faktor solltest du kräftig erhöhen (ruhig mal verdoppeln also 50 statt 25)
John
Hallo Zusammen,
würde gerne ebenfalls das neue PID Modul ausprobieren. Allerdings wird das Modul in der .cfg - Datei nicht erkannt. Ich habe dies 98_PID20.pm Datei in den angegebenen Pfad kopiert. Muss ich noch zusätzlich was beachten? Des Weiteren wollte ich mal fragen, wie ihr das mit dem Max!-Thermostat gemacht habt. Ich habe ebenfalls eins eingebundenen. Allerdings kann ich die Ventilstellung nicht vorgeben. Da manche Leute das PID Modul fleißig in Verbindung mit einem Max! - Thermostat einsetzen würde es mich interessieren, wie dieser angesteuert wird. Im Wiki-Eintrag soll dies über maxValveSettings geschehen. Allerdings ist dies doch die maximale Begrenzung des Ventilstellbereichs.
Vielen Dank im Voraus!
Gruß
manavu
Hallo manavu
um dir zu helfen, sende bitte das define deines PID20 in fhem.cfg und ggf einen Auszug aus der FHEM*.Log Datei.
Wiki hast du ja sicher gelesen.
Wie man das MAX-Thermostat als reines Stellglied einsetzt, ist hier
http://forum.fhem.de/index.php/topic,14154.msg96815.html#msg96815 (http://forum.fhem.de/index.php/topic,14154.msg96815.html#msg96815)
beschrieben.
Idee dahinter:
Man stellt das Thermostat auf desiredTemperature ON.
Demnach wird es voll auffahren, der Reglerbetrieb ist nun inaktiv.
Nun kann man mit maxValveSetting die Öffnung des Stellausgangs direkt steuern.
Funktioniert wunderbar, du kannst das direkt über FHEM testen.
Ich steuere damit meine Fussbodenheizung. (PID20+Temperaturgeber+MAX)
John
Hallo John,
vielen Dank für die schnelle Antwort.
Auszug aus cfg. -Datei
Momentan regele ich meine Heizkörper über einen FHT8V und dem alten PID Modul.
define stellantrieb.01 FHT8V 1234
attr stellantrieb.01 room Schlafzimmer
define PID_SZ PID Temp_Hum_Schlafzimmer:temperature stellantrieb.01:valve
Wenn ich nun das PID durch ein PID20 ersetze passiert folgendes:
Unknown module PID20, choose one of ALL3076 ALL4000T ALL4027 BS CM11 CUL CUL_EM CUL_FHTTK CUL_HM CUL_HOERMANN CUL_IR CUL_MAX CUL_RFR CUL_TX CUL_WS CULflash Calendar DbLog ECMD ECMDDevice EGPM EGPM2LAN EIB EM EMEM EMGZ EMWZ ENIGMA2 ESA2000 EnOcean FBAHA FBDECT FB_CALLMONITOR FHEM2FHEM FHEMWEB FHT FHT8V FHZ FLOORPLAN FRM FRM_AD FRM_I2C FRM_IN FRM_LCD FRM_OUT FRM_PWM FRM_SERVO FS20 FileLog GDS HCS HMLAN HMS HMinfo HTTPSRV HUEBridge HUEDevice Heating_Control I2C_BMP180 IPCAM IPWE IT Itach_Relay JeeLink JsonList KM271 KS300 LGTV LIRC LISTENLIVE LUXTRONIK2 LightScene M232 M232Counter M232Voltage MAX MAXLAN MSG MSGFile MSGMail NetIO230B OREGON OWAD OWCOUNT OWDevice OWFS OWID OWLCD OWMULTI OWSWITCH OWServer OWTEMP OWTHERM OWX PCA301 PID PIFACE POKEYS PRESENCE PachLog RFXCOM RFXMETER RFXX10REC RSS RandomTimer Revolt SCIVT SISPM SIS_PMS SML STV SVG SWAP SWAP_0000002200000003 SYSSTAT TCM THRESHOLD TRX TRX_ELSE TRX_LIGHT TRX_SECURITY TRX_WEATHER TUL TellStick Twilight USBWX USF1000 VIERA VantagePro2 WEBCOUNT WEBIO WEBIO_12DIGITAL WEBTHERM WOL WS2000 WS300 WS3600 Weather X10 YAMAHA_AVR ZWDongle ZWave _internal_ at autocreate average backup dewpoint dummy eventTypes fheminfo holiday mailcheck notice notify openweathermap panStamp readingsGroup remotecontrol sequence speedtest structure telnet update watchdog weblink xxLG7000 Please define PID_SZ first Please define PID_SZ first Please define PID_SZ first Please define PID_SZ first Please define PID_SZ first Please define PID_SZ first
Laut der Anleitung von Wiki habe ich die PID20.pm Datei in den angegebenen Pfad hineingespeichert. In dem Ordner auf meinem Raspberry Pi ist auch die alte PID.pm Datei vorhanden. Ein Neustart des fhem hat auch nichts gebracht. In der Logdatei steht auch nicht nennenswertes drin. Ich hoffe du kannst damit etwas anfangen.
Grüße
manavu
Hallo manavu,
fhem findet das PID20-Modul nicht.
gehe bitte in das Verzeichnis /opt/fhem/FHEM
dann folgendes ausführen und Ergebnis senden:
cd /opt/fhem/FHEM
ls -la 98_PID*
Ich erhalte hier:
[/code]
-rw-rw-rw- 1 fhem dialout 27422 Jan 22 18:54 98_PID20.pm
-rw-rw-r-- 1 fhem dialout 8042 Jan 11 12:03 98_PID.pm
[/code]
Wieso willst du unbedingt MAX verwenden, wenn du das bereits mit FHT8V realisierst ?
John
Dankeschön! Ich werde das gleich ausprobieren. Warum ich das mit Max! ausprobieren möchte liegt einfach daran, dass ich ein bekannter von mir Max! Stellmotoren hat und ich das für ihn ausprobieren soll.
Grüße
manavu
Hier ist das Ergebnis.
-rw-r--r-- 1 pi pi 0 Jan 26 18:07 98_PID20.pm
-rw-rw-rw- 1 fhem root 8042 Oct 6 11:59 98_PID.pm
Hi manavu,
hab gerade zum Thema Fußbodenheizung mit MAX einen Wiki-Eintrag verfasst.
Vielleicht hilfts das , nachdem PID20 von deinem FHEM erkannt wurde.
http://www.fhemwiki.de/wiki/MAX!_Thermostat_f%C3%BCr_die_Fussbodenheizung (http://www.fhemwiki.de/wiki/MAX!_Thermostat_f%C3%BCr_die_Fussbodenheizung)
John
Alles klar,
mit 0 Bytes kommen wir nicht weit. Du hast ein Download Problem. Deine Datei ist 0 Byte lang.
Und ein Rechte Problem hast du auch, fhem muss Zugriff auf die Datei haben.
Zitat-rw-r--r-- 1 pi pi 0 Jan 26 18:07 98_PID20.pm
Nochmal downloaden
Datei übertragen zu pi
Danach Rechte anpassen
sudo chown fhem.dialout 98_PID20.pm
John
Hallo John,
danke für deine Hilfe. Macht aufjedenfall Sinn. Werde die Datei nochmals downloaden. Was mir noch einfällt... Kann ich eigentlich einen Plot mit Stellsignal, Sollwert und Istwert gleichzeitig in einen Plot anzeigen lassen? Bei dem alten PID funktioniert das bei mir nur mit dem Sollwert. Vielleicht stimmt meine Regexp nicht. Hier ein Auszug aus der gplot- Datei.
#FileLog 4:PID_SZ.temperature:0:
#FileLog 4:PID_SZ.acutation:0:int
#FileLog 4:PID_SZ.desired:0:
plot "<IN>" using 1:2 axes x1y2 title 'Raumtemperatur' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Stellsignal(%)' ls l1fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sollwert' ls l2 lw 1 with steps
Gruß
manavu
Hallo manavu,
im Wiki ist alles erklärt. Auch wie man die Charts anlegt.
Das ist mit PID20 alles sehr einfach, die Werte sind einfach da, die man braucht.
Solltest du beim PID20 bleiben wollen wäre schön, wenn du ein paar Kurven hier reinstellen würdest.
Das Modul wird ja noch getestet und da brauche ich Rückmeldung.
John
Hallo John,
ich werde dann so bald ich wieder diese Woche dazu komme meine Chart posten.
Grüße
manavu
Hallo John,
habe die PID20.pm nochmals in den Ordner /opt/fhem/FHEM kopiert. Anschließend habe als Antwort ebenfalls das gleiche erhalten wie du damals
-rw-rw-rw- 1 fhem dialout 27422 Jan 22 18:54 98_PID20.pm
-rw-rw-r-- 1 fhem dialout 8042 Jan 11 12:03 98_PID.pm
Meine Datei ist ebenfalls keine 0 Bytes mehr lang. Danach wollte ich die Rechte anpassen. Allerdings hat das nicht geklappt. Ich habe folgendes auf dem PI ausgeführt.
cd /opt/fhem/FHEM
sudo chown fhem.dialout 98_PID20.pm
Habe aber immernoch das gleiche Problem. Das FHEM findet das pid20 Modul nicht. Habe ich irgendwas übersehen?
Vielen Dank im Voraus!
Grüße
manavu
Hallo manavu
das ist merkwürdig.
Bitte Raspi neu starten und nochmal Auszug aus Log-Datei reinstellen.
John
Hallo manavu01
sudo chown fhem:dialout 98_PID20.pm
Also ein Doppelpunkt zwischen user und group.
Die Datei gehört aber schon fhem und dialout.
Gruß
Hans
Hallo John,
Hallo Hans Franz,
jetzt funktioniert es. Habe den Raspberry nochmal neugestartet. Ich werde den jetzt testen, dann bekommt ihr meine Rückmeldung.
@John:
Entspricht P dem Proportionalfaktor Kp oder dem Proportionalbereich?
I - Anteil = Integrierbeiwert Ki oder der Nachstellzeit?
D - Anteil = Differenzierbeiwert Kd oder Vorhaltzeit?
Freundliche Grüße
manavu01
Hallo John,
hab auch nochmal im deinem Wikibeitrag nachgeschaut. Hier wird der I-Anteil in %/Minute angegeben. Ist dieser auch so realisiert? Normalerweise kenn ich das so, dass der I-Anteil die Einheit %/(s *K) besitzt oder ist dies auch so programmiert?
Bsp.:
esum = esum + e
y = Kp * e + Ki * Ta * esum
Quelle: http://www.rn-wissen.de/index.php/Regelungstechnik#PI-Regler
Gruß
manavu
Hallo manavu01
pidFactor_P ist der Proportionalbeiwert des P-Gliedes, der P-Anteil ist die Ausgangsgröße des P-Gliedes
pidFactor_I ist der Proportionalbeiwert des I-Gliedes, der I-Anteil ist die Ausgangsgröße des I-Gliedes
pidFactor_D ist der Proportionalbeiwert des D-Gliedes, der D-Anteil ist die Ausgangsgröße des D-Gliedes
anbei die grafische Darstellung
John
Hallo John,
okay dann hast du ihn auch nach der gängigen Theorie programmiert. Mich interessiert nur, ob du der I-Anteil in deiner Reglerformel auch in %/min eingesetzt wird oder nicht? Weil ich rechne dies meist in eine Nachstellzeit um: Tn = Kp/Ki
Gruß
manavu
Weil das würde dann nämlich von gängigen Einstellregeln von Ziegler & Nichols abweichen.
Gruß
manavu
Hi manavu,
du forderst mich heftig , mein Studium liegt schon einige Jahrzehnte zurück.
die massgebliche Stelle im Programm:
$iPortion = $iPortion + $workDelta * $hash->{helper}{factor_I};
Damit erfolgt die Integration im Takt von pidCalcInterval, steht default auf 60 Sekunden.
Das wäre noch ein Punkt den ich ggf. im Modul ändern sollte, damit die Integration unabhängig vom Scan-Intervall wird.
Ist mir schon bei der Diskussion mit cwagner aufgefallen.
John
Hi John,
wollte dich nicht fordern;). Im Grunde passt das auch. Ich meine du solltest den letzten Term mit der Abtastrate in Sekunden multiplizieren.
$iPortion = $iPortion + $workDelta * $hash->{helper}{factor_I} * "Abtastzeit"
für den D-Anteil
DAnteil = Kd * (e-e_alt)/Abstastzeit
Somit würde das den gängigen Reglern entsprechen. So habe ich das letztens auch programmiert. Ist aber auch nur ein Vorschlag.
Gruß
manavu
Mit Abtastzeit meine ich natürlich die 1/ScanRate. Das würde dann der Zeit entsprechen bis das Programm einmal abgearbeit wurde.
Anbei die erste Auswertung. Habe auch ein schwingendes Verhalten feststellen können. Muss mal schauen ob ich das über die Einstellwert noch kompensieren kann.
Gruß
manavu
Hi manavu,
dein Stellausgang arbeitet am unteren Ende und nutzt nur einen sehr kleinen Bereich zum regeln.
Gerade der untere Bereich ist oft nicht linear.
Ich vermute deine Vorlauftemperatur ist zu hoch. Das wirkt wie ein hoher P-Faktor.
Gut wäre wenn sich die Ventilstellung bei Raum-Auslegungstemperatur (20 Grad) im mittleren Bereich bewegt. (30..70%)
Dann hat der Regler optimale Bedingungen seinen Job zu erledigen.
Ich hatte genau diese Problem mit meinen Max-Thermostaten.
Siehe
http://forum.fhem.de/index.php/topic,18248.msg127704.html#msg127704 (http://forum.fhem.de/index.php/topic,18248.msg127704.html#msg127704)
John
Hi John,
jep das kann natürlich sein. Ich hab eh relativ große Heizkörper wodurch ich eine geringere Übertemperatur benötige. Allerdings habe ich momentan eine Vorlauftemperatur von 45°C und das kommt mir nicht allzu groß vor. Muss auch mal die Heizkörper hydraulisch abgleichen, dann ist das vielleicht auch etwas besser.
Allerdings muss ich auch noch sagen, dass ich mit alten PID die Temperatur besser regeln konnte als jetzt. Ist der alte vom Algorithmus identisch mit dem neuen?
Gruß
manavu
hallo manavu01,
ZitatIst der alte vom Algorithmus identisch mit dem neuen?
da ist kein Stein auf dem anderen geblieben.
siehe Verbesserungsvorschläge zum alten PID
http://forum.fhem.de/index.php/topic,15060.0.html (http://forum.fhem.de/index.php/topic,15060.0.html)
John
Hallo,
hier sind 3 Beispiele für die Regelungsverläufe bei mir (PID20 regelt FHT8V an normalen Heizkörpern, Sensoren sind S300TH).
Im 1. Beispiel sieht man rechts, wie der Sollwert schön ohne Überschwingen erreicht wird. Könnte vielleicht etwas schneller dort ankommen, da muss ich noch experimentieren.
Im 2. Beispiel sieht man, dass die Temperatur schön konstant gehalten wird.
Im 3. Beispiel sieht es etwas unruhiger aus, das sind die Raumbedingungen auch etwas anders, also da gibt es externe Einflüsse. Aber es wird trotzdem ganz gut geregelt.
Hallo d-man,
besten Dank für die Rückmeldung.
wichtig für eine Beurteilung wären noch die Einstellung der P,I,D Faktoren.
Weiterhin wäre es hilfreich ,wenn du die Skalierung der rechten Temperatur-Achse veränderst, so dass man den Verlauf besser erkennen kann.
zu Beispiel 1:
der erste Sollwertsprung um 06:30 Uhr von von 21 auf 22 Grad
- der Anstieg dauert sehr lange, der Zielwert wird in den 2h nicht erreicht
- das Ventil öffnet nur bis ca. 25%
Du solltest den P-Faktor deutlich erhöhen (ggf. verdoppeln).
Wenn das optimiert ist, kannst du den I-Anteil behandeln
zu Beispiel 2:
Der Sollwert ändert sich nur sehr wenig, (vielleicht 0.5 Grad), das ist nicht wirkliche eine Prüfung für den PID.
Die Ventilöffnung ist trotz der Solltemperatur von ca. 21 Grad sehr gering.
zu Beispiel 3:
ähnliches Verhalten wie bei Beispiel 1, Sollwertsprung dauert zu lange.
Das Ventil öffnet zwar nun deutlich mehr, aber hat immer noch eine Reserve von 50%.
Auch hier würde ich den P-Faktor erhöhen
Generell ist die Ventilstellung bei allen 3 Kurven bei Erreichen der oberen Solltemperatur relativ niedrig.
Ich vermute mal , dass du deine Vorlauftemperatur noch reduzieren könntest bei der aktuellen Aussentemperatur.
John
Moin, John,
beim Suchen nach anderen Fehlern auf meinem System fiel mir nun eine Fehlermeldung auf, die ich in den logs schon ziemlich weit zurück verfolgen kann:
Use of uninitialized value $d in hash element at fhem.pl line 3073.
Use of uninitialized value $reading in concatenation (.) or string at ./FHEM/98_PID20.pm line 489.
Use of uninitialized value $sensor in concatenation (.) or string at ./FHEM/98_PID20.pm line 489.
Use of uninitialized value $dev in hash element at fhem.pl line 2981.
erhalte ich auf der Console nach meiner Beobachtung immer dann, wenn der measured Wert sich ändert. Das Listing dieses 1-Wire-Device:
Internals:
ALARM 1
ASYNC 0
CFGFN ./FHEM/1wire_devices.cfg
CHANGED
DEF DS1820 787E83020800
ERRCOUNT 0
INTERVAL 30
IODev OWio1
NAME T_Vorlauf_FBH
NR 63
OW_FAMILY 10
OW_ID 787E83020800
PRESENT 1
ROM_ID 10.787E83020800.65
STATE T: 37.5
TYPE OWTHERM
Readings:
2014-02-01 16:05:09 T_avg_day 33.4
2014-02-01 16:05:09 T_avg_month 32.4
2014-02-01 16:05:09 T_cum_day 1932919.41999999
2014-02-01 16:05:09 T_cum_month 4676119.42000002
2014-02-01 15:01:25 T_max_day 50.6
2014-02-01 15:01:25 T_max_month 50.6
2014-02-01 05:30:41 T_min_day 22.3
2014-02-01 05:30:41 T_min_month 22.3
2014-01-18 14:53:01 humidity 0
2014-02-01 16:05:39 state T: 37.50 °C ▾
2014-02-01 16:05:39 temperature 37.5025
Tempf:
factor 1
offset -0.56
Attributes:
IODev OWio1
event-on-change-reading state,temperature
group Fussbodenkreis
interval 30
model DS1820
room Heizung
stateFormat {"T: ".sprintf('%.1f',ReadingsVal($name,'temperature',0))}
tempHigh 74
tempLow 69
tempOffset -0.56
Besonderheit der OWTHERM-Ausgabe ist, temperature im state so merkwürdig formatiert wird. Das "bügele" ich für STATE in die in Homematic-Devices übliche "T:"-Darstellung. Aber auch wenn ich stateFormat weglasse, habe ich keine Besserung. Praktisch mit jeder Messwert-Änderung kommen die zwei Fehlermeldungen.
-----
Ansonsten läuft das Modul bei mir im Mischerbetrieb zunehmend erfolgreich - dank Deiner vielen Tipps und Ratschläge. Temperaturverlauf, wenn er sich dann einmal eingeregelt hat, ist top. Ich kämpfe derzeit mit der Wiedereintrittsfähigkeit, die physische Mischerstellung bei Neustart u.ä. Ereignissen korrekt wiederherzustellen. Zweites Problem, dass ich in meinem Hilfsprogramm auffangen muss, ist die Tatsache, dass ein Vollausschlag 95 Sekunden dauert - ich der Regelpäzision zuliebe aber mit 30sec/30sec für PicCalcInterval und PicActorInterval arbeite, was ja eine Regelung alle Minute bedeutet, oder?
Herzliche Grüße
Christian
Hallo Christian,
Zitat
beim Suchen nach anderen Fehlern auf meinem System fiel mir nun eine Fehlermeldung auf, die ich in den logs schon ziemlich weit zurück verfolgen kann:
Das muss ich mir noch ansehen.
Zitat
Zweites Problem, dass ich in meinem Hilfsprogramm auffangen muss, ist die Tatsache, dass ein Vollausschlag 95 Sekunden dauert - ich der Regelpäzision zuliebe aber mit 30sec/30sec für PicCalcInterval und PicActorInterval arbeite, was ja eine Regelung alle Minute bedeutet, oder?
pidCalcInterval ist der Takt, in dem der Regler die Regelabweichung überprüft.
pidActorInterval ist die Mindestwartezeit für ein weitere Ausgabe am Aktor.
letztere wird aber im Takt von pidCalcInterval überprüft.
Du hast einen sehr schnellen Prozess, also rate ich dazu pidActorInterval auf 1 zu setzen, damit er mindestens im Takt von pidCalcInterval
ausgegeben wird. (Funk verwendest du offensichtlich nicht zur Ansteuerung)
John
hallo john,
ich versuche gerade deinen regler geschickt in mein system einzubinden, bin mir aber nicht im klaren, ob es überhaupt gut funktionierieren kann.
szenario:
ich habe mir ein heizsystem mit variablem referenzraum angelegt. der raum mit dem aktuell grössten heizbedarf wird referenzraum und serviert dem heizkessel raumsollwert und raumistwert. daraus ermittelt der kessel die vorlauftemperatur. in diesem fall übernimmt der regler des kessels die temperaturregelung des aktuellen referenzraumes über die vorlauftemperatur und das zugehörige stellglied muss auf 100% öffnen.
die stellglieder der restlichen räume sollen dann mit deinem regler gesteuert werden.
die problematik ergibt sich nun beim umschalten der regler, wenn der referenzraum wechselt.
zur zeit stoppe ich deinen regler, wenn der kesselregler übernehmen soll und setze das ventil separat auf 100%. soweit ganz klar.
doch wie realisiere ich den umgekehrten fall, wenn dein regler wieder übernehmen soll?
es kann ja durchaus vorkommen, dass dein regler über mehrere stunden, vielleicht sogar tage, gestoppt war. dass würde bedeuten, dass die gespeicherte reglervergangenheit nicht mehr sinnvoll ist.
im moment nutze ich "restart 100", da das stellglied kurz vor dem umschalten auf 100 stand. macht aber irgend wie keinen sinn, wenn Tist ungefähr Tsoll entspricht. ein einfaches start macht auch nicht wirklich sinn.
wenn ich das richtig verstanden habe, ist der einzige unterschied zwischen start und restart der anfangswert von actuation. aber beide nutzen die gleiche vergangenheit. irgendwie könnte ich einen "echten" restart gebrauchen, bei dem der regler resettet wird. oder habe ich da was übersehen?
für welches szenario hast du die steuerung deines reglers (start, stop, restart) genau konzipiert? soll es dabei nur um die verhinderung der stellglied kommandos gehen? so etwa wie play, pause bei einem player? welchen unterschied bringt disable? fragen über fragen. ich hoffe du kannst mich ein wenig beraten.
gruss frank
Hallo frank,
zu Deinen Fragen:
Zitatfür welches szenario hast du die steuerung deines reglers (start, stop, restart) genau konzipiert?
Ich wollte meine Fussbodenheizung regeln, bin mit dem alten PID nicht klargekommen und habe angefangen mit anderen
Usern zu diskutieren. Daraus ist PID20 entstanden.
Zitatsoll es dabei nur um die verhinderung der stellglied kommandos gehen? so etwa wie play, pause bei einem player? welchen unterschied bringt disable? fragen über fragen.
stop und disable wirken identisch. "stop" ist eher dazu gedacht temporär den Regler zu deaktivieren.
Deaktivieren heisst, dass der Regler, nichts mehr rechnet, bewertet oder verstellt und keine Befehle mehr zum Stellglied schickt.
"start" bedeutet, dass der Regler mit allen vorhandenen readings seine Arbeit wieder aufnimmt.
Er nimmt keine Rücksicht darauf, wo sich das Stellglied zu diesem Zeitpunkt befindet.
"restart" arbeitet wie "start", allerdings übernimmt er "sprungfrei" die als Parameter übergebenen Position des Stellgliedes.
Damit das mathematische Modell funktioniert, muss einmalig I-Anteil so angepasst werden, dass am Reglerausgang der gewünschte
Stellwert ansteht. Damit wird der zuvor erlernte I-Anteil zugunsten einer sprungfreien Übernahme des Stellausgangs "geopfert".
Zu deinem Problem einige Überlegungen:Zum Zeitpunkt der Raum-Umschaltung ist beim alten Raum die Position des Stellgliedes stimmig mit der Raumtemperatur.
Wenn neue "Führungs-Raum" einen höherer Vorlauftemperatur fordert, wird es im alten "Führungsraum" zu einer Übertemperatur kommen.
Entsprechend umgekehrt im Fall einer niedrigeren Vorlauftemperatur.
Die Phase der Umschaltung wird also zu größeren Regelabweichungen führen.
Aber es scheint mir noch der konkreteste Ansatz zur Wiederaufnahme der Regelung.
Wie sind den deine Erfahrungen, wenn du mit "restart 100" den Regler im alten Führungsraum startest ?
Am besten du stellt einen Plot rein dann können wir mehr sehen.
Ich hoffe zu änderst den Führungsraum nicht zu oft,
da sich ändernde Vorlauftemperaturen wie sich ändernde P-Faktoren auswirken.
Besteht nicht die Möglichkeit eine aussentemperatur-geführte Vorlauftemperatur vorzusehen ?
John
Hallo John,
PID20 als Mischersteuerung habe ich jetzt ziemlich gut am Laufen - nun kommt der Schlusspunkt, das Ganze auch noch vom Heizbedarf abhängig zu machen. Und da habe ich ein Problem mit set desired. Wenn ich dem nämlich den Sollwert über eine Variable übergebe, gibt's eine Fehlermeldung
set PID_Mischer_FBH desired Unknown command my, try help.
value $desire is not a number
Dies hatte ich auch schon bei THRESHOLD und Damian hat dann eine Änderung eingebaut, die dazu führte, dass ich mit einer Variable Sollwerte übergeben kann.
Hast Du da eine Idee oder Lösung?
Herzliche Grüße
Christian
P.S: Hier mal ein Screenshot vom Tagesverlauf - Nachtabsenkung realisiere ich über ein Stoppen von PID über Heating-Control, ein THRESHOLD sorgt für die Überwachung der Raumtemperatur und Dein PID20 steuert den Vorlauf (hier 38 Grad). Das Absinken zwischen 9 und 10 ist verursacht durch ein Absinken des Hauptvorlaufes, weil durch Sonneneinstrahlung im restlichen Haus überhaupt kein Wärmebedarf mehr bestand. Calcinterval 1, Actorintervall 30, alle 30 Sekunden gibt es einen Meßwert für den Vorlauf
Hallo Christian,
kannst du mir mal deinen Beispielcode schicken, der NICHT funktioniert.
John
Hallo John,
gerne:
my $desire = 34+(21-(ReadingsVal("TF_Galerie","temperature",21))*2;
set PID_Mischer_FBH desired $desire;
Es kommt dann bei Abschicken die genannte Fehlermeldung.
Die Idee: Nach der nächtlichen Abkühlungsphase hat der von der Fußbodenheizung wieder aufzuheizende Raum in Abhängigkeit von Wind/Außentemperatur eine bestimmte Zahl von Grad auf die Solltemperatur von 21 verloren. Durch Experimente habe ich den Ansatz, dass die Vorlauftemperatur nach obiger Formel gesetzt werden muss. Heute Morgen hätte das also einen Vorlauf von 36,4° bedeutet. Die Formel wird nur gezogen, wenn Ist-Temperatur < Solltemperatur (THRESHOLD).
Ich möchte die Solltemperatur manipulieren, weil eine zu Hohe Vorlauftemperatur zwei Nachteile hat: Der Fußboden wird zu schnell aufgeheizt und ehe der Raumfühler "zuschlagen" kann aufgeladen. Er überschwingt dann durchaus auch mal um 2 Grad. Außerdem besteht die Gefahr, dass der Fußboden überhitzt und die für das Laminat förderliche Grenze von 28 Grad nicht eingehalten wird (Aktuell habe ich da einen zweiten Threshold der da als Aufpasser dient).
Herzliche Grüße
Christian
probier doch folgendes:
my $desire = 34+(21-(ReadingsVal("TF_Galerie","temperature",21))*2;
my $cmd="set PID_Mischer_FBH desired $desire";
fhem($cmd);
John
da muss ich Dich enttäuschen. Alle Varianten, in denen ich dem set <PID20> desired den Zahlenwert aus einer Variablen mitgebe, gibt es die Fehlermeldung "is not a number".
Ich hab' die Zeile jetzt soweit eingegrenzt, dass ich es darauf festmachen kann: Es funktioniert mit einer Zahl (z.B. 37.1), nicht aber mit derselben Zahl in einer Variablen.
Ich werde mal Damian anfragen, wie er damals in Threshold das Problem gelöst hat. Vielleicht hilft das weiter.
Christian
Hallo Christian,
im THRESHOLD-Modul filtere ich lediglich nach Zahlen, die Variable muss vorher aufgelöst sein.
Die Lösung deines Problems dürfte sein:
{my $desire = 34+(21-(ReadingsVal("TF_Galerie","temperature",21))*2;;fhem "set set PID_Mischer_FBH desired ".$desire}
Gruß
Damian
@Christian.
define testme.event notify testme {my $desi=30.6;;my $cmd="set PID.Test desired $desi";;fhem($cmd);;}
Das funktioniert bei mir völlig problemlo.
Der Sollwert wird gesetzt.
Den Notify hab ich an einen Dummy gehängt.
John
Lieber John, lieber Damian,
danke für Eure Hilfsbereitschaft.
@John: Vom Notify komm ich auch her - das funktioniert wie von Dir beschrieben. Dein Einwand hat mich zum Ergebnis gebracht, dass nicht von "Deinem" PID20 sondern vom THRESHOLD die Fehlermeldung kommt, was mir
@Damian im Prinzip auch bestätigt hat.
{{my $desire=34+(21-ReadingsVal("TF_Galerie","temperature",20))*2;;fhem ("set PID_Mischer_FBH desired ".$desire)} als cmd im THRESHOLD
funktioniert genau wie gedacht, desired steht auf: 33.8 weil TF_Galerie auf 21.1 steht.
Das ist geil, nun werden vom Thermostaten dynamisch Regelparameter vom PID20 angepasst.
@Damian: Jetzt werde ich verwegen: Ist im CMD eines THRESHOLD der Steuerungsparameter sensor_value (nämlich obige 21.1) als Variable verfügbar (_sv1 aus dem Stateformat habe ich vergeblich oder falsch versucht)? Dann bräuchte ich da gar nicht mehr ein ReadingVal()! Wie geil wäre das denn. Meine Mails verschickenden Grenzwert-Thresholds wären noch einmal einfacher formuliert...
Herzliche Grüße
Christian
Hallo John,
bin gerade fleißig und rüste alles auf den neuen Regler um. Ich möchte dieses mal den Regler in den Floorplan integrieren bzw. den Sollwert und das Stellsignal des Reglers anzeigen lassen. Allerdings klappt das noch nicht so richtig? Ist das dementsprechend die gleiche Vorgehensweise wie im WIKI beschrieben ist oder hat sich da noch was geändert? http://www.fhemwiki.de/wiki/FHT_8v_direkt_ansprechen
gruß
manavu01
Hallo manavu01
das angegebene Wiki bezieht sich auf PID nicht auf PID20.
Zu PID20 gibts ein eigenes Wiki
http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler (http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler)
Am besten stellst du dein Define rein.
John
Hallo John,
eine Frage hätte ich allerdings noch. Ich wollte den PID20 gerne mal mit dem MAX! eq3 ausprobieren. Allerdings bekomme ich das nicht zum laufen. Ich kann zwar das maxValveSettings beschreiben (siehe) allerdings bewegt der Stellantrieb einfach nicht. Habe ich das irgendwas vergessen? Anbei der Quellcode:
define cm CUL_MAX 123456
define MAX_0b1578 MAX HeatingThermostatPlus 0b1578
attr MAX_0b1578 room Badezimmer
define FileLog_MAX_0b1578 FileLog ./log/MAX_0b1578-%Y.log MAX_0b1578
attr FileLog_MAX_0b1578 logtype text
attr FileLog_MAX_0b1578 room Badezimmer
set MAX_0b1578 desiredTemperature On
define PID_BZ PID20 Temp_Hum_Badezimmer:temperature MAX_0b1578:maxValveSetting
attr PID_BZ pidActorInterval 1
attr PID_BZ pidCalcInterval 1
attr PID_BZ pidFactor_I 0.0833
attr PID_BZ pidFactor_P 25
attr PID_BZ room Badezimmer
Log Datei
2014-02-10_20:05:29 MAX_0b1578 desiredTemperature on
2014-02-10_20:09:03 MAX_0b1578 maxValveSetting 0
2014-02-10_20:10:05 MAX_0b1578 maxValveSetting 0
2014-02-10_20:12:58 MAX_0b1578 maxValveSetting 0
2014-02-10_20:14:12 MAX_0b1578 maxValveSetting 100
2014-02-10_20:16:27 MAX_0b1578 maxValveSetting 0
2014-02-10_20:18:29 MAX_0b1578 maxValveSetting 100
2014-02-10_20:27:58 MAX_0b1578 maxValveSetting 0
Vielen Dank im Voraus!
gruß
manavu
Hi manavu01,
Zitatattr PID_BZ pidActorInterval 1
attr PID_BZ pidCalcInterval 1
attr PID_BZ pidFactor_I 0.0833
attr PID_BZ pidFactor_P 25
pidCalcInterval ist viel zu klein auf default-wert 60 belassen.
Wäre nur für ganz schnelle Regelvorgänge sinnvoll.
pidActorInterval 1 ist
destruktiv.
Der raubt dir alle Credits.
Ich verwende bei meiner FUBO den Wert 900.
pidFactor ist ziemlich klein , würde auch hier default wert belassen.
Das Setzen der 31.5 Grad für den Sollwert würde ich über das Max-Wochenprogramm realisieren.
Wirklich Sinn macht es nicht, den Istwert vom Thermostat zu holen und nur den Regler extern zu realisieren.
Dann kannst du gleich MAX selbst regeln lassen.
Man kann PID20 natürlich auch so einsetzen, dass man FHEM an seine Grenzen bringt.
Quasi als Stress-Test-Tool. Dann wären die Einstellungen OK.
John
Hi John,
ja da hast du recht. Den PIDActorInterval sollte ich aufjedenfall noch hochstellen.
Ich habe ein hms100TF als Temperaturgeber und das MAX! Thermostat als Stellglied. Nur ich habe das Gefühl der Regler steuert den Antrieb nicht an, obwohl das MaxValveSetting verändert wird und desiredTemperatur ist auf ON gestellt. Habe ich sonst irgendetwas dabei vergessen=?
Hinsichtlich des PIDCalcIntervall möchte ich das mein I-Anteil sekündlich ermittelt wird. Da der Default auf 60 steht bedeutet dies, dass ich mein Ki-Wert in %/Minute einsetzen muss. So kann ich ich den in %/s einsetzten und dementsprechend nach gängigen Einstellregeln einstellen. Ich denke das hängt halt von der Abtastzeit Ta ab. Es wird möglicherweise aufs Gleiche rauskommen. oder irr ich mich da?
y = Kp * e + Ki * Ta * esum
Gruß
Manavu
Hast du das schon einmal manuell probiert, also ohne PID20 ?
Sollwert auf ON
warten bis das Thermostat komplett aufgefahren
nun maxValveSetting auf 50 setzten
nach spätestens 2 Minuten sollte sich was bewegen.
John
Hallo John,
vielen Dank für deine Hilfe. Kann es vielleicht auch sein, dass es Probleme gibt wenn ich über das Gleiche COC Modul einen FHT8V ansteuere? Und muss das DesiredTemperatur auf ON stehen bleiben? Weil bei mir steht in der Sollwert vom MAX! immernoch auf 20°C. Siehe Anhang.
Ich werde das dann mal mit dem PID ausprobieren und mich dann bei dir melden, ob es geklappt hat.
Gruß
manavu
Hallo,
ich habe seit gestern auch in einem Testraum das PID20 Modul als Regler am Laufen.
Setup:
- Aktor: MAX HeizkörperThermostatPlus an einem normalen Heizkörper
- Istwert-Geber: Lacrosse Temperatursensor (TX29-IT)
- Heating_Control für das Wochenprogramm
- Anbindung von fakeSC (Fensterkontakt) und MAX Eco-Taster, Eco-Temperatur und FensterOffen-Temperatur werden aus dem MAX-Thermostat übernommen.
Der Testraum ist ein relativ kleines Badezimmer im Erdgeschoss und regiert sehr schnell mit großen Temperaturschwankungen auf minimale Energiezufuhr vom Heizkörper. Außerdem enthält das Wochenprogramm zur Zeit relativ geringe Sollwerte (6:00-18:00 19°C, 18:00-6:00 17°C). In der Vergangenheit habe ich den Termperatursensor mittels fakeWT angebunden und hatte ein starkes Schwingen der Temperatur (siehe erster Anhang, da war die comfortTemperatur allerdings noch auf 18°C eingestellt). Jetzt bin ich gespannt, wie sich das System mit dem PID20-Regler verhält und wie weit man es optimieren kann.
Die Vorlauftemperatur der Heizung habe ich schon so weit es geht reduziert. Die Heizung läuft zur Zeit mit einer Nachtabsenkung von 22:00 - 6:00 Uhr. Allerdings habe ich die Regelparameter der Heizung noch nicht ganz verstanden, da ich schon um ca. 3 Uhr einen Anstieg der Temperatur im Heizungsraum messe. Aber das ist ein anderes Thema.
Der zweite Anhang zeigt den Plot für die PID-Regelung von heute. Jetzt heißt es erstmal abwarten und das Verhalten beobachten.
Settings sind wie folgt:
Internals:
DEF T_00_Bad:temperature MAX_EG_Bad_HT:maxValveSetting
NAME PID_EG_Bad
NR 250
NTFY_ORDER 50-PID_EG_Bad
STATE processing
TYPE PID20
Readings:
2014-02-12 10:21:41 actuation 4
2014-02-12 10:22:41 actuationCalc -0.76
2014-02-12 10:22:41 delta -0.199999999999999
2014-02-12 10:21:41 desired 19.0
2014-02-12 10:21:41 measured 19.2
2014-02-12 10:22:41 p_d 0
2014-02-12 10:22:41 p_i 9.23999999999996
2014-02-12 10:22:41 p_p -9.99999999999996
2014-02-12 10:22:41 state processing
Helper:
actor MAX_EG_Bad_HT
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 900
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 2
actorTimestamp 2014-02-12 10:11:41
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient -0.00081274724405253
deltaOld -0.199999999999999
deltaOldTS 2014-02-12 10:21:50
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.2
factor_P 50
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor T_00_Bad
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
pidActorInterval 900
pidActorTreshold 2
pidFactor_I 0.2
pidFactor_P 50
room EG_Bad
@John: Vielen Dank für die Arbeit!
Gruß,
Gero
Hallo Gero,
ich denk du solltest den pidFactor_P von 50 auf 25 nehmen, da die Aufheizung sehr schnell ist und bei geringer Öffnung
schon eine wuchtige Reaktion erfolgt.
Den pidFactor_I ebenso reduzieren von 0.2 auf 0.15.
Anmerkung:
irgendwas ist allerdings überdimensioniert (Vorlauftemperatur oder Heizkörper),
da die Ventilstellung nur im Bereich von 0..10 % im eingeschwungenen Zustand arbeitet.
Kannst du den Vorlauf weiter reduzieren oder den Volumenstrom über ggf vorhandene voreinstellbare Ventile begrenzen ?
Hast du mit der vorhergenden Variant via WT versucht über maxValveSetting den Arbeitsbereich zu reduzieren (z.B auf 30 statt 100 setzen) ?
John
Hallo John,
Zitat von: John am 12 Februar 2014, 10:47:22
ich denk du solltest den pidFactor_P von 50 auf 25 nehmen, da die Aufheizung sehr schnell ist und bei geringer Öffnung
schon eine wuchtige Reaktion erfolgt.
Den pidFactor_I ebenso reduzieren von 0.2 auf 0.15.
Danke für den Hinweis, ich werde es heute mal umstellen.
Zitat von: John am 12 Februar 2014, 10:47:22
Anmerkung:
irgendwas ist allerdings überdimensioniert (Vorlauftemperatur oder Heizkörper),
da die Ventilstellung nur im Bereich von 0..10 % im eingeschwungenen Zustand arbeitet.
Kannst du den Vorlauf weiter reduzieren oder den Volumenstrom über ggf vorhandene voreinstellbare Ventile begrenzen ?
Der Testraum ist ein relativ kleines Badezimmer mit ca. 4m² und wahrscheinlich ist die Heizung für diesen Raum etwas überdimensioniert. Gestern verhielt sich der Raum bei gleichen Parametern etwas anders (siehe Anhang). Eine genaue Erklärung habe ich nicht dafür, außer dass ein Handtuch zum Trocknen über dem Heizköprer hing. Heute nachdem das Handtuch entfernt wurde, schwingt die Temperatur wieder lustig.
Die Vorlauftemperatur liegt zur Zeit bei ca. 40°C. Ich habe nur normale Heizkörper im ganzen Haus und keine Fußbodenheizung. Die Vorlauftemperatur und die Pumpenleistung kann ich nicht weiter reduzieren, weil es sonst in anderen Räumen nicht mehr warm genug wird. Anscheinend wurde aber nie ein hydraulischer Abgleich der gesamten Heizungsanlage gemacht. Aber welche Auswirkung hätte ein hydraulischer Abgleich für diesen Raum, wenn dort das Ventil auch so nie voll öffnet? Ich muß mich mit dem Thema hydraulischer Abgleich wohl noch etwas tiefer befassen. Hat die Voreinstellung am Ventil die gleiche Bedeutung, wie die Begrenzung durch das maxValveSetting?
Zitat von: John am 12 Februar 2014, 10:47:22
Hast du mit der vorhergenden Variant via WT versucht über maxValveSetting den Arbeitsbereich zu reduzieren (z.B auf 30 statt 100 setzen) ?
Bevor ich den PID20 eingesetzt habe stand maxValveSetting immer auf 100%. Ich habe lediglich einen externen Temperatursensor über fakeWT angebunden. Aber auch dort hat das Ventil ja nie mehr als 25% geöffnet.
Gruß,
Gero
Hallo Gero,
die Regelkurve sieht doch nicht schlecht aus ?
ZitatHat die Voreinstellung am Ventil die gleiche Bedeutung, wie die Begrenzung durch das maxValveSetting?
Im Prinzip schon, da ja die maximale Durchflussmenge durch beide Massnahmen reduziert wird.
Allerdings muss MAX eben einen Teil seines Stellbereiches "opfern". Dies ist entfällt bei Nutzung der Voreinstellung und für MAX steht wieder der volle Stellbereich zur Verfügung. (Voller Hub des Ventils)
John
Nachdem ich in einigen Räumen mit der MAX!-internen Regelung sehr unzufrieden bin, habe ich diese jetzt auch auf PID20 umgestellt.
Hierzu noch eine Frage:
Was ist der beste Weg, falls man in einem Raum mehrere Aktoren steuern will?
(Das PID20 Modul selbst kann nur einen Aktor steuern, soweit ich es verstanden habe.)
Hier die Ideen, die ich bisher hatte:
- Man könnte pro Heizkörper ein PID20- Regler definieren. (Das mache ich zur Zeit so). Das ist aber eigentlich zuviel, da sich die Regler innerhalb eines Raumes auch so gleich verhalten.
- Man könnte ein dummy Aktor definieren, der alle anderen zusammenfasst.
- Oder kann man nur einen Aktor anzusteuern und über die groupid automatisch alle anderen mit steuern?
- Kann man alle Heizkörper in einem Raum über eine structure zusammenfassen und diese structure dem PID20-Regler als Aktor angeben?
Gruß,
Gero
Zitat von: gero am 21 Februar 2014, 11:19:11- Kann man alle Heizkörper in einem Raum über eine structure zusammenfassen und diese structure dem PID20-Regler als Aktor angeben?
Ja, solange das alles identische Regler sind und für alle der Steuerbefehl gleich lautet.
Danke für die Antwort.
Ich habe es gerade ausprobiert und es funktioniert.
Jetzt bin ich gespannt, ob die Regelung mittels PID20 zu besseren Resultaten führt als die Regelung mit MAX ohne FHEM Eingriff.
Ich hätte noch eine kurze Frage (wahrscheinlich eine dumme Anfängerfrage):
Ich würde gerne über das Web-Interface die gewünschte Temperatur des PID Reglers einstellen können.
Ein webCmd liefert keine DropDownListe, da die Werteliste für desired nicht im PID20_Set Kommando definiert ist.
Ein
attr <PID20_Regler> setList desired:...
funktioniert auch nicht, da dieses Attribute nicht unterstützt wird.
Der einzige Umweg, der mir einfällt, ist ein dummy Device. Aber ich möchte gerne ein weiteres Device umgehen, weil es irgendwann unübersichtlich wird,
Gibt es eine einfache Lösung? Ist es evtl. sinnvoll ein setList oder ähnliches dem Modul hinzuzufügen?
Gruß,
Gero
Soweit ich weiß (zumindest war das mal ursprünglich so), ist der set-Befehl dynamisch, weil nicht jedes Device "desired" verlangt, sondern bei manchen auch ein "desired-temp" (als Beispiel) vorkommt.
ZitatName des Setters kann vom Anwender über das Attribute "pidDesiredName" definiert werden
Deshalb ist das mit der Dropdownliste nicht so ohne weiteres möglich.
Zitat von: betateilchen am 24 Februar 2014, 14:17:43
Soweit ich weiß (zumindest war das mal ursprünglich so), ist der set-Befehl dynamisch, weil nicht jedes Device "desired" verlangt, sondern bei manchen auch ein "desired-temp" (als Beispiel) vorkommt.
Deshalb ist das mit der Dropdownliste nicht so ohne weiteres möglich.
Das war mir bewußt. Deshalb auch mein Vorschlag, die Liste ebenfalls von extern definieren zu können.
Hey,
kann ich auch einen Istwert über GPIO4 vom RPI verarbeiten?
VG Steve
@Steve
jeder Wert der als Reading verfügbar ist, kann als Istwert verwendet werden.
John
@John: Möchtest Du das Modul nicht irgendwann mal einchecken - z.B. vorläufig nach ./contrib ? Hier im Thread geistern jetzt schon drei verschiedene Versionen rum. Vielleicht kannst Du ja auch die aktuelle Modulversion immer im ersten Beitrag hier bereitstellen.
@John,
ich habe den Sensor wie folgt erstellt "define Keller GPIO4 10-000802906860".
Wenn ich den Sensor mit Keller benenne kommt die Meldung "Unknown sensor device Keller specified"
Wo liegt der Fehler?
Steve
schick mal ein
list Keller
und dein PID20-define.
John
Hier mal ein kleiner Auszug:
define PID.FUBO PID20 Keller:GPIO4_Keller:maxValveSetting
#-----------------------------------------------------------------
define RPI GPIO4 BUSMASTER
#---------------------------------------------------------------------
define Keller GPIO4 10-000802906860
attr Keller model DS18B20
attr Keller room GPIO4
define GPIO4_Keller at +*00:01 set GPIO4_Keller messen;; sleep 1;; get GPIO4_Keller temp
define Log_Keller FileLog /opt/fhem/log/Temperatur-%Y.log Keller:(temp).*
--------------------------------------------------------------------------------------------------------------------------------------
Im Logfile kommt aber noch eine seltsame Meldung.
Ich habe erst gestern den 1Wire über RPI in Betrieb genommen. Kann sein das ich dort noch einen Fehler habe :-\
Hi Steve,
schau dir bitte noch mal das Wiki an
define PID.FUBO PID20 Keller:GPIO4_Keller:maxValveSetting
Da stimmt fast gar nix. Wo ist der Aktor ?
maxValveSetting ist wohl nicht das "regexp" , das man nur ganz selten braucht.
Welchen Aktor hast zu geplant (auch hier ein list <actor>)
Ausserdem brauche ist das "list Keller" !!
John
Ich habe jetzt in der Küche einen der neuen Homematic-Wandthermostaten mit meinem alten FHT8v per PID20 verknüpft. Läuft gut :)
Internals:
CFGFN
DEF ku_TC_Weather:temperature ku_Ventil:valve
NAME ku_PID20
NR 360
NTFY_ORDER 50-ku_PID20
STATE T: 21.7 °C D: 16 °C V: 0 %
TYPE PID20
CHANGETIME:
Helper:
Dblog:
Desired:
Fhemdblog:
TIME 1393275820.5338
VALUE 16
Readings:
2014-02-24 22:03:00 actuation 0
2014-02-24 22:04:00 actuationCalc -142.9
2014-02-24 22:04:00 delta -5.7
2014-02-24 22:03:40 desired 16
2014-02-24 22:03:00 measured 21.7
2014-02-24 22:04:00 p_d 0
2014-02-24 22:04:00 p_i -0.399999999999999
2014-02-24 22:04:00 p_p -142.5
2014-02-24 22:04:00 state processing
Hi John,
hab bitte etwas Geduld mit mir, bin leider noch nicht ganz sattelfest was FHEM betrifft. ;)
Als Aktoren mochte ich zwei Relais über NetIO ansteuern. Damit kann ich den Mischer meines HK von der
FBH regeln.
Das einzurichten wäre der nächste Schritt. Eventuell werde ich andere Hardware verwenden.
Ich glaube ein Dummy (Stellventil) wäre zum probieren erst einmal ideal.
Internals:
DEF 10-000802906860
NAME Keller
NR 77
STATE T: 25.25
TYPE GPIO4
Readings:
2014-02-24 21:34:21 failures 0
2014-02-24 22:04:52 state T: 25.25
2014-02-24 22:04:52 temperature 25.25
Fhem:
interfaces temperature
Attributes:
model DS18B20
room GPIO4
@Steve
Hallo Steve,
folgendes sollte funktionieren
define PID.FUBO PID20 Keller:temperature MyDummy
Vom Objekt Keller wird das Reading "temperature" als Istwert gelesen.
Die Ausgabe des Stellwertes erfolgt an MyDummy via
set Mydummy <value>
John
@John,
ich glaube das Problem gefunden zu haben. Im Log steht eine Fehlermeldung im Bezug auf den GPIO4.
2014.02.25 08:46:25 2: After sleep: No get implemented for GPIO4_Keller
2014.02.25 08:47:24 3: GPIO4_Keller: No set implemented for GPIO4_Keller
Werde erst einmal sehen wie ich das hin bekomme.
Dein Vorschlag möchte auch nicht funktionieren.
Steve
Hey,
gibt es noch einen Trick für die Ausgabe des Stellwertes?
Mit dem Vorschlag von John geht es nicht.
Die Temperaturabfrage habe ich jetzt zum laufen gebracht.
Steve
@Steve
du brauchst keinen Trick, sondern musst es nur richtig machen.
Geh mit verbose auf 3 und suche in der FHEM-log nach Einträgen dieser Art:
Zitat2014.02.25 21:16:07 3: [PID.Test] PID20_Calc.685 <set PID.Actor 23> with ret:
Beim mir ist PID.Actor auch ein dummy.
Es funktioniert, er wird gesetzt.
define PID.Test PID20 PID.Sensor:temperature PID.Actor
Sowohl PID.Sensor, wie auch PID.Actor sind Dummys.
Beim PID.Sensor ist noch das userReading temperature hinzufgefügt.
John
@Steve:
auch bei mir läuft es wie von John beschrieben - die PID20-Werte werten in einen Dummy geschrieben.
Eine Veränderung dieses Dummys wird bei mir nun von einem Notify ausgewertet. Und dieses Notify steuert zwei Releais, die nun je nach Veränderung zum Vorwert ein Mischerventil um den entsprechenden Betrag auf- oder zufahren.
Du müsstest also mal sagen, was Du mit Deinen beiden Relais schließlich steuern willst.
Christian
Ich bekomme es nicht auf die Reihe :'(
Im Log steht:
2014.02.26 14:05:53 1: [PID.Test] PID20_Define.135 PID.Test: Unknown sensor device PID.Sensor specified
2014.02.26 14:05:53 1: define: PID.Test: Unknown sensor device PID.Sensor specified
In der CFG habe ich folgendes eingetragen:
define PID.Test PID20 PID.Sensor:temperature PID.Actor
attr PID.Test verbose 3
define PID.Sensor dummy
attr PID.Sensor userReadings temperature
define PID.Actor dummy
Der PID wird bei mir gar nicht erst erstellt, so das ich auch verbose 3 nicht einstellen kann.
@ Christian
Kannst Du mir eventuell deine Konfiguration zukommen lassen, da ich auch mit zwei Relais arbeiten möchte.
Die Harware dafür habe ich schon konfiguriert.
Steve
Zitat von: Steve am 26 Februar 2014, 14:12:44
In der CFG habe ich folgendes eingetragen:
define PID.Test PID20 PID.Sensor:temperature PID.Actor
attr PID.Test verbose 3
define PID.Sensor dummy
attr PID.Sensor userReadings temperature
define PID.Actor dummy
Wenn das wirklich SO in der fhem.cfg steht, kann das auch nicht funktionieren.
Dir ist offenbar nicht klar, dass Du versuchst, den PID zu definieren, BEVOR Du den Sensor und den Actor generiert hast?
Dreh doch einfach mal die Reihenfolge um:
define PID.Sensor dummy
attr PID.Sensor userReadings temperature
define PID.Actor dummy
define PID.Test PID20 PID.Sensor:temperature PID.Actor
attr PID.Test verbose 3
Und verbose 3 brauchst Du normalerweise gar nicht zusetzen, das sollte in fhem Standard sein.
Danke es funktioniert.
Ich wußte nicht das die Reihenfolge in der CFG wichtig ist ::)
Die Konfiguration wird Schritt für Schritt in genau der Reihenfolge abgearbeitet, wir der Kram da drinsteht.
Deshalb sollte man jedem die Hände abhacken, der manuell und hirnfrei in der fhem.cfg rumpfuscht, ohne zu wissen was er/sie/es da eigentlich tut.
Ich habe zwei Bitten:
- Könnte man bitte die Loglevel vereinheitlichen, damit man einigermaßen vernünftig mit verbose arbeiten kann.
- Ausserdem wäre es schön, wenn sich die Logmeldungen am allgemeinen fhem Standard orientieren würden.
2014.02.26 19:07:44 2: [ku_PID20] PID20_Calc.701 readings updated
2014.02.26 19:07:46 3: [ku_PID20] PID20_Set.335 set ku_PID20 desired 16
2014.02.26 19:09:48 3: [ku_PID20] PID20_Set.335 set ku_PID20 desired 16
2014.02.26 19:12:39 3: [ku_PID20] PID20_Set.335 set ku_PID20 desired 16
2014.02.26 19:15:16 3: [ku_PID20] PID20_Set.335 set ku_PID20 desired 16
2014.02.26 19:15:45 2: [ku_PID20] PID20_Calc.701 readings updated
Hallo betateilchen,
ZitatKönnte man bitte die Loglevel vereinheitlichen, damit man einigermaßen vernünftig mit verbose arbeiten kann.
Werde ich mir ansehen.
ZitatAusserdem wäre es schön, wenn sich die Logmeldungen am allgemeinen fhem Standard orientieren würden
Ich finde es ungemein erleichternd bei der Analyse von Problemen, wenn
- man die Instanz erkennen kann
- man die auslösende Position im Code sofort ansteuern kann
Darauf will ich zumindest während der Evaluation nicht verzichten.
Ggf spendier ich noch ein Attribut um das Log-Verhalten zu verändern.
John
Hallo John,
Zitat von: John am 26 Februar 2014, 19:45:31
Ich finde es ungemein erleichternd bei der Analyse von Problemen, wenn
- man die Instanz erkennen kann
- man die auslösende Position im Code sofort ansteuern kann
Das eine schließt das andere nicht aus.
Normalerweise loggt man ja so, dass nach dem TimeStamp und dem Loglevel der Modultyp und der Devicename kommen.
2014.02.26 00:15:29 2: PID20 ku_PID20: Calc.701 readings updated
würde also Deine Wünsche und meine Wünsche vollständig und ohne großen Änderungsaufwand erfüllen. Außerdem wäre das dann auch DbLog-kompatibel (was im Moment definitiv nicht der Fall ist!)
Wobei solche von Dir nachvollziehbar gewünschten, ausführlichen Debugging/Evaluierungs-Meldungen eher in Loglevel 4 oder 5 gehören - dort kann man so ausführlich werden wie man möchte. Aber für Level 1-3 sollte man sich schon an den Entwicklungsrichtlinien (auch wenn sie kein Gesetz sind) orientieren, das vermeidet einige Probleme an anderen Stellen in fhem. Und man muss hinterher in seinem Modul nichts mehr am Logging ändern ;)
Viele Grüße
Udo
Achja, was ich noch sagen wollte: Ist ja ein ganz prima Modul geworden inzwischen!
Hallo Udo,
ich habe versucht die neuen Anforderungen einzubringen.
Anbei die Version 1.00.h
Somit ist dies nun die aktuelle Version mit folgenden Änderungen:
- diverse kleine Fixes
- bei pidDeltaTreshold kann auch ein float zugewiesen werden
- die Berechnung des i-Anteils ist nun unabhängig von pidCalcInterval
( Achtung: dies betrifft alle, die den default-Wert von pidCalcInterval verändert haben)
John
PS: Dateianhang gelöscht, da Modul in FHEM integriert ist
Hallo John,
danke, ich werde es testen und berichten.
Viele Grüße
Udo
Spontan würde ich sagen "sieht gut aus" (bis auf den fehlenden Namen in der Initialize-Meldung)
2014.02.26 21:19:04 0: PID20 PID20: Initialize.111 Init Done with Version V 1.00.h - 26.02.14 - john
2014.02.26 21:19:37 3: PID20 ku_PID20: Set.345 set ku_PID20 desired 16
2014.02.26 21:22:40 3: PID20 ku_PID20: Set.345 set ku_PID20 desired 16
Hallo Steve,
das "Aktor-Modul" ist ein Notify, das auf den Dummy FBH_Stellwert "horcht". durch Vergleich mit dem vorherigen Stellwert (zwischengespeichert in Alt_Stellwert) findet das Notify heraus, welches der beiden Relais (Funkschalter) er ansteuern und für welche Zeit (was in meinem Fall für 100 % 95 Sekunden sind.
FH_Stellwert {
my $alt_stellwert = ReadingsVal("FBH_Stellwert","Alt_Stellwert",0);
fhem ("setreading FBH_Stellwert Alt_Stellwert $EVENT");
my $delta=($EVENT-$alt_stellwert)*.95;
if ($delta > 0) {fhem("set FBH_Mischer_mehr on-for-timer $delta");}
if ($delta < 0){$delta = -$delta; fhem("set FBH_Mischer_weniger on-for-timer $delta")};
if (abs($delta) >30) {$delta = abs($delta)-30; sleep $delta}
}
Das ist es eigentlich schon.
Herzliche Grüße
Christian
@Udo
Wenn du unter "Namen" den Instanz-Namen verstehst, kann ich deine Anmerkung nicht nachvollziehen.
Initialize ist nicht instanzbezogen, sondern modulbezogen, oder ?
Also kann ich auch keinen Instanz-Namen angeben.
John
Ja, ist nicht schlimm.
@Christian,
bis zum FBH-Stellwert funktioniert es super. Doch die Ansteuerung der Relais geht noch nicht.
Du schreibst das der "Alt_Stellwert" zwischengespeichert wird. Geschieht das mit dem Aktor-Modul
oder muß noch zusätzlich etwas erstellt werden?
Steve
Hi Steve,
in der zweiten Zeile wird der Wert des Notifys zwischengespeichert:
fhem ("setreading FBH_Stellwert Alt_Stellwert $EVENT");
$EVENT beinhaltet den Wert des jeweils durch Veränderung auslösenden Stellwertes...
Herzliche Grüße
Christian
An alle Anwender von PID20.
Die aktuelle Version 1.00.h findet sich hier
http://forum.fhem.de/index.php?topic=17067.msg143065#msg143065 (http://forum.fhem.de/index.php?topic=17067.msg143065#msg143065)
mit Anmerkungen.
John
Hallo John,
Tipp: In der aktuellen Forumsoftware kannst Du auch alte Beiträge editieren, Du kannst also die aktuelle Modulversion immer in den ersten Beitrag hier im Thread ablegen. Dann kannst Du auch die Zwischenversionen, die im Verlauf der Entwicklung entstanden sind, hier wieder rausnehmen und eine Einheitlichkeit bei allen Anwendern herstellen.
Viele Grüße
Udo
Hallo Christian,
bei mir wollen die Relais nicht zucken.
Bis zum FBH_Stellwert funktioniert alles.
Habe jetzt noch ein Dummy erstellt als "Alt_Stellwert".
Dort steht im Reading nur ein Fragezeichen. Sollte nicht ein letzter Meßwert angezeigt werden?
VG Steve
Hi Steve,
ich versuche mal aus der Ferne mich Deinem Problem Schritt für Schritt anzunähern:
1. PID20 hast Du mit Johns Hilfe eingerichtet und in dem Dummy FBH_Stellwert hast Du nun stets drin stehen, welchen Prozentwert Dein Mischer haben sollte. Sobald PID20 diesen Stellwert verändert, springt das Notify an. Nehmen wir an, PID20 will 60
2. Das Notify ist definiert
define FBH_Notify FBH_Stellwert {
my $alt_stellwert = ReadingsVal("FBH_Stellwert","Alt_Stellwert",0);
fhem ("set Alt_Stellwert $EVENT");
my $delta=($EVENT-$alt_stellwert)*.95;
if ($delta > 0) {fhem("set FBH_Mischer_mehr on-for-timer $delta");}
if ($delta < 0){$delta = -$delta; fhem("set FBH_Mischer_weniger on-for-timer $delta")};
if (abs($delta) >30) {$delta = abs($delta)-30; sleep $delta}
}
3. Sobald also erstmals eine Änderung des FBH_Stellwertes stattfand, sollte im Dummy Alt_Stellwert derselbe Wert stehen, nämlich 60
4. Damit ist das Delta für diese Runde 0 und Deine Relais zucken nicht.
5. PID20 fordert 65
6. Notify springt an und das Delta ist 5, mein Aktor FBH_MIscher-mehr bewegt sich um 5*0.95 (dieser Korrekturfaktor entsteht, weil bei mir der Mischer von 0 bis 100 eben nur 95 Sekunden braucht.
7. Im Alt_Stellwert steht nun 65
Hilft Dir das zum Umsetzen - für jedes der Relais brauchst Du in meiner Konstruktion also einen Aktor.
Herzliche Grüße
Christian
Hallo Christian,
der "Alt_Stellwert" ändert sich nicht und somit gehen die Stellglieder(Relais)auch nicht.
Kannst du mal bitte schauen wo der Fehler ist.
Ich habe schon alles mögliche geändert aber ohne Erfolg
Danke Steve
#--------------------------------------------------------------------------
# PID_ Sensor+ Ausgabe
#-----------------------------------------------------------------------------
define FB_VL ECMDDevice ONEWIRE 107a7d90020800f5
attr FB_VL room Heizung
define 1Wire_FB_VL at +*00:01 set FB_VL messen;; sleep 1;; get FB_VL temperature
define Log_FB_VL FileLog /opt/fhem/log/Temperatur-%Y.log FB_VL:(temp).*
attr Log_FB_VL logtype text
#----------------------------------------------------------------------------
# PID Steuerung
#------------------------------------------------------------------------
define PID.Test PID20 FB_VL:temperature FBH_Stellwert
attr PID.Test pidActorInterval 3
attr PID.Test pidActorTreshold 5
attr PID.Test pidActorValueDecPlaces 0
attr PID.Test pidFactor_I 0.2
attr PID.Test pidFactor_P 10
#------------------------------------------------------------------------------
define PID.Test.File FileLog /opt/fhem/log/PID.PID-%Y.log FBH_Mischer_mehr:.*|FBH_Mischer_weniger:.*|FBH_Stellwert:.*|FB_VL:.*|PID.PID|PID.Test:actuation:.*|PID.Test:actuationCalc:.*|PID.Test:delta:.*|PID.Test:desired:.*|PID.Test:measured:.*|PID.Test:p_p:.*
attr PID.Test.File logtype text
#-------------------------------------------------------------------------
define SVG_PID.Test.File_1 SVG PID.Test.File:SVG_PID.Test.File_1:CURRENT
#-------------------------------------------------------------------------------
define Alt_Stellwert dummy
define FBH_Stellwert dummy
#---------------------------------------------------------------------------
# PID Steuerglieder
#--------------------------------------------------------------------------
#define FBH_Mischer_weniger ECMDDevice RELAIS 01
#define FBH_Mischer_mehr ECMDDevice RELAIS 02
define FBH_Mischer_weniger dummy
define FBH_Mischer_mehr dummy
#------------------------------------------------------------------------------
define Mischer notify FH_Stellwert {\
my $alt_stellwert = ReadingsVal("FBH_Stellwert","Alt_Stellwert",0);;\
fhem ("setreading FBH_Stellwert Alt_Stellwert $EVENT");;\
my $delta=($EVENT-$alt_stellwert)*.95;;\
if ($delta > 0) {fhem("set FBH_Mischer_mehr on-for-timer $delta");;}\
if ($delta < 0){$delta = -$delta;; fhem("set FBH_Mischer_weniger on-for-timer $delta")};;\
if (abs($delta) >30) {$delta = abs($delta)-30;; sleep $delta}\
}
Hallo John,
Ich habe ein klitzkleines Problem mit deinem Modul:
Es benutzt ja in den Readings als Ist-Temperatur "measured". Dummerweise erzeugt "jsonlist" ohne spec aufgerufen genau diesen Ausdruck als key für timestamp:
"measured": "15.4",
"measured": "2014-03-05 12:35:28"
Das ist schlecht zu parsen :'(.
Ruft man "jsonlist" mit devspec auf, werden interessanterweise Readings so angezeigt:
"measured": {
"TIME": "2014-03-05 12:35:28",
"VAL": "15.4"
Ist natürlich besser zu parsen. Aber da der Ausdruck "measured" ohne Zusatz wie "-temp" oder "Temp" soweit ich das überblicke nur im Modul PID20 erscheint, könntest du dich entschließen, ihn zu erweitern? Oder führt das bei anderen Anwendern zu übermäßiger Hektik.
Gruß
Hans
benenne das doch einfach um. Soweit ich weiß, gibts dafür ein Attribut pidMeasuredName
Moin,
Ja klar. Danke.
Gruß
Hans
Zitat von: Hans Franz am 05 März 2014, 14:36:47werden interessanterweise Readings so angezeigt:
Übrigens: Jedes Reading besteht aus Timestamp und Value, deshalb gibt es dafür die beiden Funktionen ReadingsVal() und ReadingsTimestamp() um genau diese Werte ermitteln zu können.
Hallo,
ich habe wie folgt in der cfg konfiguriert:
define PID.Sensor dummy
attr PID.Sensor userReadings temperature
define PID.Actor dummy
define PID.Test PID20 PID.Sensor:temperature PID.Actor
attr PID.Test verbose 3
Jetzt bekomme ich im PID.Test die Fehlermeldung:
"state alarm - no temperature yet for PID.Sensor "
Gibt es dafür eine Lösung?
Steve
ZitatGibt es dafür eine Lösung?
Wiki lesen, dort nach Alarm suchen
John
hallo john,
ich habe meine pid20-regler nun einigermassen gut in mein system einbinden können.
als definition benutze ich folgenden code:
define PID20.SZ PID20 Thermostat.SZ:measured-temp VentilControler.SZ_Btn1:valvePos
nun habe ich festgestellt, dass der regler bei jedem event von "Thermostat.SZ" anspricht und nicht nur beim reading "measured-temp". da meine sensoren (hm-cc-tc) auch diverse andere readings bereitstellen, führt dieses verhalten mit unter zu systemverzögerungen, die ich gerne unterbinden möchte. hier werden zb 7 events erzeugt, wobei lediglich einmal mesured-temp enthalten ist. bei 5 reglern kommt dann einiges an rechenzeit zusammen.
2014.03.08 18:59:02.085 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 18:59:02.135 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 18:59:02.185 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 18:59:02.236 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 18:59:02.286 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 18:59:02.339 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 18:59:02.390 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
kann ich das durch verwendung von "regex" eventuell anpassen? und wenn ja, wie würde das dann genau aussehen?
gruss frank
Zitatkann ich das durch verwendung von "regex" eventuell anpassen
nein.
Das von dir beschrieben Verhalten ein Kern-Feature von FHEM.
Jede Modulinstanz erhält alle Ereignisse und extrahiert jene, die von Interesse sind.
Das nicht nur bei PID20 so, sondern praktisch bei allen Modulen, die Events verarbeiten. (z.B Notify).
Mit einem kleineren verbose-Wert verschwinden du die Einträge in der Log.
John
hallo john,
danke für die schnelle antwort.
2014.03.08 19:59:00.045 4: addLog exec {
addLog("PID20.AZ","desired");;
....
....
addLog("Broetje","wwTsollRedu");;
}
2014.03.08 19:59:01.604 4: PID20 PID20.AZ: Notify.228 check 1 readings for Tsmooth
2014.03.08 19:59:01.650 4: PID20 PID20.AZ: Notify.228 check 1 readings for Tsmooth
2014.03.08 19:59:01.696 4: PID20 PID20.WZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:01.748 4: PID20 PID20.WZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:01.797 4: PID20 PID20.WZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:01.848 4: PID20 PID20.WZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:01.898 4: PID20 PID20.WZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:01.949 4: PID20 PID20.WZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.000 4: PID20 PID20.WZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.052 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.103 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.153 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.203 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.254 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.319 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.370 4: PID20 PID20.SZ: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.423 4: PID20 PID20.Bad: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.516 4: PID20 PID20.Bad: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.608 4: PID20 PID20.Bad: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.714 4: PID20 PID20.Bad: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.805 4: PID20 PID20.Bad: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.879 4: PID20 PID20.Bad: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:02.950 4: PID20 PID20.Bad: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:03.025 4: PID20 PID20.Kueche: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:03.104 4: PID20 PID20.Kueche: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:03.174 4: PID20 PID20.Kueche: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:03.225 4: PID20 PID20.Kueche: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:03.277 4: PID20 PID20.Kueche: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:03.342 4: PID20 PID20.Kueche: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:03.394 4: PID20 PID20.Kueche: Notify.228 check 1 readings for measured-temp
2014.03.08 19:59:04.654 1: Perfmon: possible freeze starting at 19:59:00, delay is 4.654
ZitatJede Modulinstanz erhält alle Ereignisse und extrahiert jene, die von Interesse sind.
demnach verursachen alle module diese verzögerung, aber nur dein modul zeigt die aktivität durch den logeintrag an? im obigen beispiel reagiert pid20 zb 30 mal obwohl nichts relevantes für pid20 dabei ist.
ZitatMit einem kleineren verbose-Wert verschwinden du die Einträge in der Log.
verbose habe ich ja gerade hochgedreht um die verzögerungen zu orten. ;)
gruss frank
Hallo Steve,
sorry wegen der Wartezeit auf meine Antwort: Mir fällt in Deiner Umsetzung nur ein Fehler auf: Das Notify soll ja auf den Stellwert lauschen, den PID20 nach FBH_Stellwert schreibt. Dein Notify lauscht aber auf FH_Stellwert?
2. In der Zeile fhem ("setreading FBH_Stellwert Alt_Stellwert $EVENT");;\ sicherst Du den neu geforderten Stellwert ($EVENT) in ein Reading von FBH_Stellwert, dies entsteht entweder durch ein manuelles Befüllen mit einem Inititalwert oder durch den ersten erfolgreichen Lauf des Notify.
Dein Dummy Alt_Stellwert insofern gar nicht gefüllt und ist auch überflüssig.
Mit dem trigger-Befehl kannst Du ja das Notify mit Testwerten befeuern, um meine Tipps zu überprüfen.
Leider habe ich aktuell kein Testsystem zur Verfügung und beruflich extrem angespannt - so kann ich Dir nur auf diese theoretische Weise versuchen zu helfen.
Dabei freue ich mich sehr, dass mein Ansatz schon von jemanden ausprobiert wird, während ich noch in der Bastelphase bin.
Es gibt auch noch ein Problem, für die meine Abhilfe jetzt seit 4 Wochen passabel läuft: Durch rundungsfehler und vielleicht auch mechanische Ungenauigkeit stimmen mecahnische Prozentstellung des Mischers und FBH_Stellwert bei sehr vielen Regelvorgängen (ich hatte anfangs in 10 Stunden 600 und mehr! nicht mehr überein. Deshalb fahre ich bei Eintritt in die Nachtabsenkung den Mischer bewußt mit einem Timerbefehler von FBH_MIscher_mehr von 95 (bei mir dauert eine komplette Bewegung 95 Sekunden) auf 100%. Egal wo er dann steht, mit 95 Sekunden wird er dann bei 100% ankommen, es schadet bei meinem MIscher nicht, wenn er einen zu langen Befehl bekommt, weil bei 0 und bei 100 % schaltet er ab.
Ebenso setze ich dann natürlich mit einem
fhem ("setreading FBH_Stellwert Alt_Stellwert 100");;\
auch den Alt-Meßwert. Wenn dann PID20 am nächsten Morgen startet, sende ich ein
set PID_Mischer_FBH restart 100
und Mischer/PI20 gehen erst einmal vom selben Istzustand aus.
Die 100 habe ich gewählt, weil PID20 typischerweise bei kalten Raum sowieso in den höheren Anforderungsregionen sein wird. Genauso gut könnte man gegen 0 synchronisieren. Dieses findet bei mir genau einmal am Tag statt und das reicht tatsächlich. Allerdings bei Stromausfall zum ungünstigen Zeitpunkt steht der Mischer irgendwo und PID20 weiß gar nichts, da müsste man auch noch Vorkehrung treffen, aber die Zeit, siehe oben.
Herzliche Grüße und gutes Gelingen!
Christian
Hallo John,
was hältst Du von dem Vorschlag, zum nächsten Major-Release von fhem (vermutlich im April) das alte PID Modul nach contrib zu verschieben und Dein neues Modul "offiziell" zu machen?
Viele Grüße
Udo
Hallo Udo,
Zitatwas hältst Du von dem Vorschlag, zum nächsten Major-Release von fhem (vermutlich im April) das alte PID Modul nach contrib zu verschieben und Dein neues Modul "offiziell" zu machen?
Ich denke PID20 ist nun soweit gereift, dass man dies guten Gewissens tun kann.
Ich bin momentan beruflich stark eingespannt, habe noch keinen Developer-Status und kann mich derzeit mit dem Prozedere
nicht auseinandersetzen.
Wärst du bereit als Maintainer zu agieren und ggf. die Modul-Doku noch zu checken ?
Dann wäre die von dir vorgeschlagene Timeline einzuhalten.
John
Ich werde mir die Doku anschauen und kann auch gerne das Modul für Dich einchecken, wenn ich das Verschieben des alten Moduls mache. Aber Maintainer für das Modul würdest Du bleiben, denn es steckt DEIN Hirnschmalz drin, nicht meines.
Doku checken ist ein cooler Job, wenn es noch gar keine Doku gibt 8)
Das Modul 98_PID20.pm ist ab sofort Bestandteil von fhem und in SVN ab Version
# $Id: 98_PID20.pm 5330 2014-03-26 15:19:04Z
enthalten. Die Verteilung erfolgt ab morgen auch automatisch innerhalb des regulären FHEM update prozesses.
Bitte nun keine Modulversionen mehr hier aus dem Thread verwenden oder bearbeiten, um Inkonsistenzen zu vermeiden!
Fehler & Probleme bitte weiterhin hier diskutieren.
@John: kannst Du bitte einen Hinweis in den Eingangsbeitrag schreiben und ggf. vorhandene Zwischenversionen hier aus dem Thread entfernen?
@Udo
Besten Dank für die Zuarbeit.
Die Dateinahänge im Thread sind allesamt gelöscht und im initialen Eintrag findet sich ein entsprechender Verweis.
Auch das Wiki wurde angepasst.
John
Guten Morgen, John,
einen habe ich noch: immer wieder läuft meine Mischerregelung in eine Störung, weil ein Timer nicht ausgeführt werden kann. Jetzt habe ich die Ursache: Der Timer, der ein Delta abarbeiten soll, ist gerundet 0 und das geht natürlich nicht. Warum ist er Null, obwohl ich Threshold sogar auf 6 gesetzt habe? Das passiert, wenn die letzte Actuation weniger als 6% an der 100 dran ist und der nächste Schritt dann auf 100 erhöht. Meiner Meinung dürfte in diesem Beispiel keine Aktuatoränderung mehr stattfinden, oder?
2014-03-29_07:46:01 PID_Mischer_FBH desired: 37.6
2014-03-29_07:46:01 PID_Mischer_FBH measured: 28.69
2014-03-29_07:46:01 PID_Mischer_FBH p_p: 35.64
2014-03-29_07:46:01 PID_Mischer_FBH p_d: 0
2014-03-29_07:46:01 PID_Mischer_FBH p_i: 64.015
2014-03-29_07:46:01 PID_Mischer_FBH actuation: 99.7
2014-03-29_07:46:01 PID_Mischer_FBH actuationCalc: 99.655
2014-03-29_07:46:01 PID_Mischer_FBH delta: 8.91
2014-03-29_07:46:32 PID_Mischer_FBH desired: 37.6
2014-03-29_07:46:32 PID_Mischer_FBH measured: 28.565
2014-03-29_07:46:32 PID_Mischer_FBH p_p: 36.14
2014-03-29_07:46:32 PID_Mischer_FBH p_d: 0
2014-03-29_07:46:32 PID_Mischer_FBH p_i: 64.9185
2014-03-29_07:46:32 PID_Mischer_FBH actuation: 100.0
2014-03-29_07:46:32 PID_Mischer_FBH actuationCalc: 101.0585
2014-03-29_07:46:32 PID_Mischer_FBH delta: 9.035
2014-03-29_07:48:04 PID_Mischer_FBH desired: 37.6
2014-03-29_07:48:04 PID_Mischer_FBH measured: 30.7525
2014-03-29_07:48:04 PID_Mischer_FBH p_p: 27.39
2014-03-29_07:48:04 PID_Mischer_FBH p_d: 0
2014-03-29_07:48:04 PID_Mischer_FBH p_i: 65.60325
2014-03-29_07:48:04 PID_Mischer_FBH actuation: 93.0
2014-03-29_07:48:04 PID_Mischer_FBH actuationCalc: 92.99325
2014-03-29_07:48:04 PID_Mischer_FBH delta: 6.8475
2014-03-29_07:49:05 PID_Mischer_FBH desired: 37.6
2014-03-29_07:49:05 PID_Mischer_FBH measured: 32.94
2014-03-29_07:49:05 PID_Mischer_FBH p_p: 18.64
2014-03-29_07:49:05 PID_Mischer_FBH p_d: 0
2014-03-29_07:49:05 PID_Mischer_FBH p_i: 66.6415
2014-03-29_07:49:05 PID_Mischer_FBH actuation: 85.3
2014-03-29_07:49:05 PID_Mischer_FBH actuationCalc: 85.2815
2014-03-29_07:49:05 PID_Mischer_FBH delta: 4.66
Ehe ich jetzt auf meiner Seite den Fall abfange, stellt sich die Frage, ob Du in Deinem Programm ein Unterschreiten des Thresholds am "Rande" der Regelstrecke auffangen kannst.
Mit Dir freue ich mich, dass PID20 nun zum Funktionsumfang von FHEM gehört. Ich finde es eine wirkliche Bereicherung des Projektes.
Herzliche Grüße
Christian
Es gibt 2 Thresholds.
Welchen meinst du denn ?
Bitte nochmals ein list <pid> reinstellen.
John
Hallo John, hier das aktuelle Listing meiner PID20-Instanz am Mischer:
nternals:
CFGFN ./FHEM/heizung.cfg
DEF T_Vorlauf_FBH:temperature FBH_Stellwert
NAME PID_Mischer_FBH
NR 593
NTFY_ORDER 50-PID_Mischer_FBH
STATE processing
TYPE PID20
Readings:
2014-03-29 10:33:32 actuation 100.0
2014-03-29 10:33:32 actuationCalc 118.4645
2014-03-29 10:33:32 delta 9.8475
2014-03-29 10:33:32 desired 37.6
2014-03-29 10:33:32 measured 27.7525
2014-03-29 10:33:32 p_d 0
2014-03-29 10:33:32 p_i 79.0744999999999
2014-03-29 10:33:32 p_p 39.39
2014-03-29 10:33:32 state processing
Helper:
actor FBH_Stellwert
actorCommand
actorErrorAction freeze
actorErrorPos 0
actorInterval 1
actorKeepAlive 24000
actorLimitLower 0
actorLimitUpper 100
actorThreshold 6
actorTimestamp 2014-03-29 09:53:22
actorValueDecPlaces 1
adjust
calcInterval 30
deltaGradient 0.0020678481108515
deltaOld 9.8475
deltaOldTS 2014-03-29 10:32:57
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.2
factor_P 4
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor T_Vorlauf_FBH
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
group Fussbodenkreis
pidActorInterval 1
pidActorKeepAlive 24000
pidActorTreshold 6
pidActorValueDecPlaces 1
pidCalcInterval 30
pidDebugActuation 1
pidDebugCalc 1
pidDebugDelta 1
pidDebugNotify 1
pidDebugSensor 1
pidDebugUpdate 1
pidFactor_D 0
pidFactor_I 0.2
pidFactor_P 4
room Heizung
verbose 0
Deine Antwort hat mir aber aufgezeigt, dass Dein PID20 mir eine Option bietet, die vermutlich besser als actor_Threshold mein Problem erschlägt: Delta_Threshold. Ich würde jetzt also Actor-Threshold auf 0 und Delta_Threshold auf 6 setzen.
Kannst Du mal sagen, wo bei den beiden Thresholds in der Praxis dann der Unterschied ist?
Danke für die schnelle Antwort
Christian
Hallo Christian,
Argumente für pidActorThreshold
- praktisch kein Stellglied kann man beliebig fein stellen, sie benötigen einen "Mindesthub", damit der Stellvorgang glückt.
(z.B. einen 100 Kg schweren Schrank auf einen halben Millimeter positionieren ist sehr schwierig/kaum möglich mit herkömmlichen Mitteln)
- man will die Häufigkeit der Stellvorgänge begrenzen, sehr sinnvoll bei funkorientierten Stellgliedern,
im Fall der Temperaturregelung ist es kein Problem, wenn nicht 1x pro Minute nachgeregelt wird,
man kann sich viel Zeit damit lassen, der Vorgang ist träge
Argumente für pidDeltaTreshold
- man weiss, dass die Regelgenauigkeit begrenzt ist, wenn die Regeldifferenz < xy ist, soll der sich der Regler schlafen legen (idle);
ansonsten würde er immer wieder versuchen den 100kg schweren Schrank auf 0.5 mm zu positionieren, was im einfach nicht gelingen kann, aber er versucht es eben
- auch damit lassen sich die Stellvorgänge reduzieren, da nur jene ausgeführt werden, die zielführend sind
John
Hallo,
ich habe PID20 gerade im Rahmen eines Updates meiner FHEM-Installation entdeckt.
Hatte bisher PID im Einsatz. Habe jetzt gerade mal auf PID20 gewechselt und werde berichten.
Zur Infos zu meiner Installation:
- 4 Fußbodenheizungskreise mit je einem thermisch Stellglied (an/aus).
- Unter und auf dem Estrich (unter dem Bodenbelag) habe ich jeweils einen 1wire-Temperatursensor.
- In jedem Raum ein 1wire-Raumtemperaturfühler (in ca. 1,2m Höhe an der Wand).
Die Fußbodentemperatur ist mit dem Modul
THRESHOLD als Zweipunktregelung ausgeführt.
Für das PID-Modul ist die Raumtemperatur
[measured].
Die Stellgröße
[actuation] ist dabei der
[desired]-Wert vom Modul THRESHOLD.
Die Fußbodentemperatur ist begrenzt im Bereich 18-28 Grad
[pidActorLimitLower,pidActorLimitUpper].
Bisher hat das alte Modul auch recht gut funktioniert, wenn auch ich von Regleroptimierung keinen Plan habe, obwohl ich irgendwann in grauer Vorzeit (vor 20 Jahren) ein Semster lang eine Reglungstechnikvorlesung hatte. *schäm*
OT an die Reglungsprofis hier: Gibt es eine Freeware (vorzugsweise für Linux) mit der man das ganze simulieren kann?
Ich glaube damals in der Hochschule hatten wir WinFact unter Win3.1 oder so... ;-)
Die Software gibt es noch aber nur zum Spielen so eine Software zu kaufen scheint mir etwas überzogen.
Gruß
Holger
Moin,Moin,
Habe zwar keine Software, aber eine simple Simulation für Libre Office Calc, mit der ich mal `rumgespielt habe. Ist nach einem Youtube-Tutorial gebaut.
Viel Spaß,
Hans
Also bisher läuft das Modul anscheinend ganz gut, leider (oder zum Glück) ist zur Zeit kein richtiges "Heizwetter" mehr.
Ein kleiner Schönheitsfehler ist mir im Log aufgefallen:
Use of uninitialized value $retStr in concatenation (.) or string at ./FHEM/98_PID20.pm line 685.
Gruß
Holger
Ändere mal Zeile 684 im Modulquelltext in:
my $retStr = ($ret) ? $ret : "";
und teste nochmal.
(es erschließt sich mir allerdings noch nicht wirklich, wieso da plötzlich eine zweite Variable eingeführt und benutzt wird)
Zitat von: betateilchen am 11 April 2014, 15:45:10
Ändere mal Zeile 684 im Modulquelltext in:
okay, hab das jetzt mal eingebaut und test weiter...
Hallo,
PID20 stellt als Untergrenze für aktuationr den mit pidActorLimitLower vereinbarten Wert ein.
m.E. wäre es aber besser, wenn für "geschlossen" wirklich "0" und nur für actuator-Werte > 0 pidActorLimitLower+ ermitteltes actuation gesetzt würde.
Grund: pidActorLimitLower dürfte in der Regel den Wert enthalten, bei dem der Anwender weiss/merkt, dass der Regler geöffnet wird (z.B. 8).
Ob da der Regler (z.B. ein FHT8V) wirklich geschlossen ist, weiss man deshalb trotzdem nicht!!!
Bernhard
Hallo Bernhard,
ZitatGrund: pidActorLimitLower dürfte in der Regel den Wert enthalten, bei dem der Anwender weiss/merkt, dass der Regler geöffnet wird (z.B. 8).
Ob da der Regler (z.B. ein FHT8V) wirklich geschlossen ist, weiss man deshalb trotzdem nicht!!!
Es geht nicht um den Anwender, sondern um den PID-Regler selbst.
pidActorLimitLower bezeichnet die Stellposition, ab der das Stellglied tatsächlich seine Wirkung "entfaltet".
Damit sagst du dem PID, alle Stellpositionen < pidActorLimitLower sind sinnlos, da sich diese nicht auf den Regelkreis auswirken.
John
@John
da möchte ich behaupten: scheinbar nicht auswirken!
Der Anwender legt pidActorLimitLower fest und kann dabei irren.
Wenn ich mich recht erinnere, wurde diese Schwelle eingeführt, da das mit FHT8V gesteuerte Ventil mitunter ein sehr eigenartiges Verhalten zeigen kann.
Ich selbst habe an einem HK ein Ventil, das erst bei knapp 9% zu öffnen, ein anderes , das bei ca 5% und eins das ich an der Rücklaufverschraubung stark bremsen muss - und das in einem Raum.
Erzähl mir jetzt aber bitte nicht, dass ich die Ventile tauschen soll - es ist mir schlicht nicht möglich.
Vielleicht könnte als Stellsignal 0 ausgegeben werden, wenn das errechnete actuation <= pidActorLimitLower ist.
Hallo!
Ich versuche seit Tagen den Regler zu stoppen, leider startet der Regler nach jedem FHEM-Neustart wieder.
Bug oder Feature? :D
Grüße
Hallo fhainz,
ZitatIch versuche seit Tagen den Regler zu stoppen, leider startet der Regler nach jedem FHEM-Neustart wieder.
Das Stop/Start/Restart-Command war als Befehl während der Laufzeit geplant, die enstprechende Stati sind im
nicht remanenten Bereich abgespeichert.
Beim Hochstarten von FHEM wird der Regler automatisch auf Start genommen.
Das Disable Attribut hat denselben Effekt, wie das Stop-Kommando und übersteht auch einen FHEM-Neustart.
Vielleicht ist dir damit geholfen.
John
Perfekt danke. Hatte doch glatt das disable Attribut überlesen ;D
Hallo zusammen,
ich setze seit einigerzeit auch den PID20 Regler ein und bin total zufrieden damit.
Jetzt habe ich ein neues Einsatzgebiet für den Regler und würde gerne mit einem PID20 Regler zwei Stellantriebe ansteuen ist dies möglich?
Wenn ja was muss ich dafür machen?
Grüße
Jochen
Hallo Jochen,
ZitatJetzt habe ich ein neues Einsatzgebiet für den Regler und würde gerne mit einem PID20 Regler zwei Stellantriebe ansteuen ist dies möglich?
Wenn ja was muss ich dafür machen?
Wenn du dem PID20 als Stellglied einen Dummy anbietest, sollte dein Vorhaben realisierbar sein.
Du setzt dich über ein Notify auf die Aktualisierung des Dummys drauf und verteilst den Stellbefehl, so wie du es benötigst.
John
Bevor es wieder Winter wird, möchte ich endlich meine (sehr alte) FB-Heizung mit thermischen Ventilen ausstatten. Ja, es gibt 100 Argumente dagegen, so etwas überhaupt zu tun. Aber ich weiß, warum ich es will.
Wie auch immer, hierzu muss ich Ventile für die einzelnen Räume mit thermischen Stellantrieben ausstatten. Dies sind 2-Punkt-"Steller" können also nur auf oder zu. Daher muss der Aktorwert als PWM auf die Stellantriebe gegeben werden. Beispiel: Aktor-Wert 50% -> Duty Cycle 50% (sagen wir bei einer Frequenz von 1 / 15 min, wäre dann das ventil 7,5 Minuten auf und 7,5 Minuten zu)
Darf ich es als Feature Request einbringen, so eine PWM-Regelung mit in das PID20 Modul einzubauen? Ich kann natürlich auch alle 30 Sekunden ein Polling machen und das so "von Hand" realisieren, da ich aber eine ganze Reihe von Ventilen haben werde, wäre das als integrierte Funktion natürlich schöner.
Oder vll. hat jemand eine bessere Idee für diese Problemstellung.
Hallo Unimatrix,
warum verwendest du nicht das Modul Threshold zur Lösung des Problems ?
Das ist für schaltende Stellglieder weitaus besser geeignet.
John
Zitat von: Jochen Auer am 25 Mai 2014, 15:17:43
Jetzt habe ich ein neues Einsatzgebiet für den Regler und würde gerne mit einem PID20 Regler zwei Stellantriebe ansteuen ist dies möglich?
Hallo Jochen,
ich habe es über eine structure gelöst (zuerst).
Aber inzwischen habe ich meinen Antrieben (FHT8V) einfach mit dem selben Hauscode gepairt und steuerer auf dem PID20 den ersten an.
Der zweite läuft dann synchron mit.
Gruß
Martin
@unimatrix
Ich habe die PWM für Fussbodenheizungen so gelöst: http://forum.fhem.de/index.php/topic,11025.msg123773.html#msg123773 (http://forum.fhem.de/index.php/topic,11025.msg123773.html#msg123773)
Vielleicht ist dieses Prinzip für dich auch nutzbar.
ob PID o. PID20 ist dabei egal.
Gruss.
Hallo My-FHEM,
kannst Du ein paar Tipps geben, wie Du Dich den richtigen Werte für P, I und D genähert hast (außer durch ein Studium an einer Technischen Hochschule)? ;D
Dank
Tino
Hallo John,
jetzt mit der beginnenden Heizsaison bekommt auch PID20 wieder Arbeit. Über den Sommer hatte sich anscheinend einiges geändert, was zu "Perl"-Fehlermeldungen führte, von denen der eine Teil durch den jüngsten Update beseitigt wurde. Nun habe ich aber noch eine Fehlermeldung, für die ich nicht verstehe. Es wird immer mal wieder das Fehlen eines Sensorwertes angemeckert, obwohl er da ist. Im Einsatz:
# $Id: 98_PID20.pm 6796 2014-10-20 21:17:57Z john99sr $
Die Konfiguration:
Internals:
CFGFN ./FHEM/pid.cfg
DEF T_Vorlauf_FBH:temperature:(\d[0-9].[0-9]) FBH_Stellwert
NAME PID_Mischer_FBH
NR 717
NTFY_ORDER 50-PID_Mischer_FBH
STATE processing
TYPE PID20
Readings:
2014-10-24 08:24:25 actuation 100.0
2014-10-24 08:29:26 actuationCalc 105.35
2014-10-24 08:29:26 delta 6.4
2014-10-24 08:24:25 desired 26
2014-10-24 08:24:25 measured 19.6
2014-10-24 08:29:26 p_d 0
2014-10-24 08:29:26 p_i 79.75
2014-10-24 08:29:26 p_p 25.6
2014-10-24 08:29:26 state processing
Helper:
actor FBH_Stellwert
actorCommand
actorErrorAction freeze
actorErrorPos 0
actorInterval 1
actorKeepAlive 24000
actorLimitLower 0
actorLimitUpper 100
actorThreshold 2
actorTimestamp 2014-10-24 08:04:24
actorValueDecPlaces 1
adjust
calcInterval 60
deltaGradient 0
deltaOld 6.4
deltaOldTS 2014-10-24 08:29:29
deltaTreshold 1
desiredName desired
disable 0
factor_D 0
factor_I 0.2
factor_P 4
isWindUP 1
measuredName measured
reading temperature
regexp (\d[0-9].[0-9])
reverseAction 0
sensor T_Vorlauf_FBH
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
group Fussbodenkreis
pidActorInterval 1
pidActorKeepAlive 24000
pidActorTreshold 2
pidActorValueDecPlaces 1
pidDeltaTreshold 1
pidFactor_D 0
pidFactor_I 0.2
pidFactor_P 4
room Heizung
Beispielhaft ein Stück Log, eingedampft auf PID20:
2014.10.23 22:06:02 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.23 22:07:27 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 00:03:27 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 01:22:01 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 01:25:01 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 02:30:27 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 02:35:01 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 03:34:28 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 03:40:28 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 05:37:01 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 05:38:28 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 07:32:01 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 07:43:28 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 07:53:01 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
2014.10.24 08:00:22 3: Stellwertveränderung 37.145
2014.10.24 08:00:22 3: PID20 PID_Mischer_FBH: Calc.686 <set FBH_Stellwert 60.9> with ret:
2014.10.24 08:01:23 3: Stellwertveränderung 25.27
2014.10.24 08:01:23 3: PID20 PID_Mischer_FBH: Calc.686 <set FBH_Stellwert 87.5> with ret:
2014.10.24 08:02:23 3: Stellwertveränderung 6.555
2014.10.24 08:02:23 3: PID20 PID_Mischer_FBH: Calc.686 <set FBH_Stellwert 94.4> with ret:
2014.10.24 08:03:24 3: Stellwertveränderung 4.085
2014.10.24 08:03:24 3: PID20 PID_Mischer_FBH: Calc.686 <set FBH_Stellwert 98.7> with ret:
2014.10.24 08:04:24 3: Stellwertveränderung 1.235
2014.10.24 08:04:24 3: PID20 PID_Mischer_FBH: Calc.686 <set FBH_Stellwert 100> with ret:
2014.10.24 08:07:28 1: PERL WARNING: Use of uninitialized value $sensorValue in subtraction (-) at ./FHEM/98_PID20.pm line 244.
PID_Mischer_FBH ist ein Dummy
Was kann ich tun?
Danke für Dein Modul und dank für eine Antwort im Voraus!
Christian
Hallo Christian,
kannst du mir bitte ein EventLog deiner Sensorwerte schicken.
Sieh dir bitten nochmal dein regexp an, dass scheint mir verdächtig.
Was spricht gegen die Default-Regexp, die verwendet wird, wenn du nichts angibst ?
^([\+,\-]?\d+\.?\d*$)
John
Hallo John,
mit dem RegEx warst Du auf der richtigen Spur - über 16 Stunden hinweg habe ich jetzt die Fehlermeldungen nicht mehr und die Steuerung des Mischers mit Hilfe von PID20 und STELLMOTOR läuft wie gewünscht:
2014-10-25 15:43:14 OWTHERM Zuluft temperature: 18.4375
2014-10-25 15:43:19 STELLMOTOR Stellmotor2 position: 18
2014-10-25 15:43:19 STELLMOTOR Stellmotor2 queue_lastdiff: 0
2014-10-25 15:43:19 STELLMOTOR Stellmotor2 locked: 1
2014-10-25 15:43:19 STELLMOTOR Stellmotor2 lastStart: 1414244599.20334
2014-10-25 15:43:19 STELLMOTOR Stellmotor2 stopTime: 1414244616.10148
2014-10-25 15:43:19 OWSWITCH Switch_Heizkeller output Mischer_mehr ON
2014-10-25 15:43:19 OWSWITCH Switch_Heizkeller output Mischer_weniger OFF
2014-10-25 15:43:19 PID20 PID_Mischer_FBH actuation: 18
2014-10-25 15:43:20 OWSWITCH Switch_Heizkeller Brenner: OFF Mischer_weniger: OFF Mischer_mehr: ON Waschkueche: OFF EWT: OFF F: OFF G: OFF H: OFF
2014-10-25 15:43:35 OWTHERM T_Vorlauf_FBH temperature: 22.9375
2014-10-25 15:43:35 OWTHERM T_Vorlauf_FBH T: 22.94 °C
2014-10-25 15:43:36 OWSWITCH Switch_Heizkeller output Mischer_weniger OFF
2014-10-25 15:43:36 OWSWITCH Switch_Heizkeller output Mischer_mehr OFF
2014-10-25 15:43:36 STELLMOTOR Stellmotor2 position: 18
2014-10-25 15:43:36 STELLMOTOR Stellmotor2 queue_lastdiff: -0.24103139576159
2014-10-25 15:43:36 STELLMOTOR Stellmotor2 locked: 0
2014-10-25 15:43:36 STELLMOTOR Stellmotor2 stopTime: 0
2014-10-25 15:43:36 STELLMOTOR Stellmotor2 18
2014-10-25 15:43:38 OWTHERM Abluft temperature: 20.95
2014-10-25 15:43:39 OWSWITCH Switch_Heizkeller Brenner: OFF Mischer_weniger: OFF Mischer_mehr: OFF Waschkueche: OFF EWT: OFF F: OFF G: OFF H: OFF
2014-10-25 15:44:09 OWTHERM T_Vorlauf_FBH temperature: 23.4375
2014-10-25 15:44:09 OWTHERM T_Vorlauf_FBH T: 23.44 °C
2014-10-25 15:44:19 STELLMOTOR Stellmotor2 position: 16
2014-10-25 15:44:19 STELLMOTOR Stellmotor2 queue_lastdiff: 0
2014-10-25 15:44:19 STELLMOTOR Stellmotor2 locked: 1
2014-10-25 15:44:20 STELLMOTOR Stellmotor2 lastStart: 1414244659.9365
2014-10-25 15:44:20 STELLMOTOR Stellmotor2 stopTime: 1414244662.14973
2014-10-25 15:44:20 OWSWITCH Switch_Heizkeller output Mischer_mehr OFF
2014-10-25 15:44:20 OWSWITCH Switch_Heizkeller output Mischer_weniger ON
2014-10-25 15:44:20 PID20 PID_Mischer_FBH actuation: 16
2014-10-25 15:44:21 OWSWITCH Switch_Heizkeller Brenner: OFF Mischer_weniger: ON Mischer_mehr: OFF Waschkueche: OFF EWT: OFF F: OFF G: OFF H: OFF
2014-10-25 15:44:22 OWSWITCH Switch_Heizkeller output Mischer_weniger OFF
2014-10-25 15:44:22 OWSWITCH Switch_Heizkeller output Mischer_mehr OFF
2014-10-25 15:44:22 STELLMOTOR Stellmotor2 position: 16
2014-10-25 15:44:22 STELLMOTOR Stellmotor2 queue_lastdiff: 0.476996020266884
2014-10-25 15:44:22 STELLMOTOR Stellmotor2 locked: 0
2014-10-25 15:44:22 STELLMOTOR Stellmotor2 stopTime: 0
2014-10-25 15:44:23 STELLMOTOR Stellmotor2 16
2014-10-25 15:44:25 OWSWITCH Switch_Heizkeller Brenner: OFF Mischer_weniger: OFF Mischer_mehr: OFF Waschkueche: OFF EWT: OFF F: OFF G: OFF H: OFF
2014-10-25 15:44:38 OWTHERM T_Vorlauf_FBH temperature: 23.5625
2014-10-25 15:44:38 OWTHERM T_Vorlauf_FBH T: 23.56 °C
2014-10-25 15:48:37 OWTHERM T_Vorlauf_FBH temperature: 23.6875
2014-10-25 15:48:37 OWTHERM T_Vorlauf_FBH T: 23.69 °C
2014-10-25 15:49:11 OWTHERM T_Vorlauf_FBH temperature: 23.75
2014-10-25 15:49:11 OWTHERM T_Vorlauf_FBH T: 23.75 °C
Herzliche Grüße
Christian
Hallo zusammen,
ich habe ein (hoffentlich nicht Anfänger-)Problem.
Ich verwende zum Steuern meines FBH-Mischers ein MAX-Thermostat als Stellglied, und one-wire-Sensoren zur Temperatur Messung.
Die Regelung erfolgt über das PID20-Modul von FHEM.
Mein Tunen der Regelparameter ist mir aufgefallen, dass der D-Anteil an der Stellgröße immer 0 ist.
Woran kann das liegen?
Hier der Auszug aus meinem Info:
Internals:
CFGFN /opt/fhem/FHEM/Heizung.cfg
DEF Heizung.Ruecklauf.FBH:temperature Heizung.Mischer.FBH:maxValveSetting
NAME Heizung.FBH_Regler
NR 211
NTFY_ORDER 50-Heizung.FBH_Regler
STATE processing
TYPE PID20
Readings:
2014-11-10 19:44:47 actuation 16
2014-11-10 19:53:47 actuationCalc 13.5532749999947
2014-11-10 19:53:47 delta -0.375
2014-11-10 19:44:47 desired 29
2014-11-10 19:44:47 measured 28.5
2014-11-10 19:53:47 p_d 0
2014-11-10 19:53:47 p_i 14.6782749999947
2014-11-10 19:53:47 p_p -1.125
2014-11-10 19:53:47 state processing
Helper:
actor Heizung.Mischer.FBH
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 90
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 80
actorThreshold 3
actorTimestamp 2014-11-10 19:44:47
actorValueDecPlaces 0
adjust
calcInterval 10
deltaTreshold 0
desiredName desired
disable 0
factor_D 10
factor_I 0.30
factor_P 3
isWindUP
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor Heizung.Ruecklauf.FBH
sensorTimeout 3600
sensorTsOld
stopped 0
updateInterval 600
Attributes:
disable 0
pidActorInterval 90
pidActorLimitLower 0
pidActorLimitUpper 80
pidActorTreshold 3
pidActorValueDecPlaces 0
pidCalcInterval 10
pidFactor_D 10
pidFactor_I 0.30
pidFactor_P 3
room Heizung
verbose 2
Viele Grüße
Markus
Hallo Markus,
ich seh mir das Thema nochmal an. Selbst hab ich den D-Faktor noch nie produktiv benutzt.
John
Hallo Markus,
würde dich bitte die angehängte Version zu testen und vom Ergebnis zu berichten.
John
Hallo John,
da bin ich natürlich sofort dabei - erste Rückmeldung nach einigen Stunden: P- und I-Anteil habe ich beibehalten und habe mal mit D=0.1 angefangen und in meinem Fall (alle 45 Sekunden eine Messung, sehr schnelle und extreme Ausschläge im Eingang) habe ich zwei sehr positive Effekte: 1. Deutlich weniger Regelschritte und 2. deutlich kleinere Ausschläge...
Herzliche Grüße
Christian
Hallo Christian,
besten Dank für die Rückmeldung.
Wäre schön, wenn du noch einen Plot reinstellen könntest, der auch den D-Anteil abbildet.
John
Hallo John, hier nun der Plot. Bei der Beurteilung ist wichtig zu wissen, dass hier der Vorlauf einer Fußbodenheizung, die niedrige Vorläufe braucht, aus einem Heizkreislauf ausgekoppelt wird, der normale Radiatoren beliefert. PID20 steuert über das Modul STELLMOTOR von Florian einen Vierwegemischer.
Dadurch sind auch die extremen Vorlaufschwankungen zu erklären. Heute ist die zusätzliche Besonderheit, dass im restlichen Haus ab 14.30 Uhr kein Wärmebedarf mehr vorlag und so der Hauptkreis auskühlte.
Die Einstellungen von PID20:
pidActorInterval 10
pidActorKeepAlive 24000
pidActorLimitLower 1
pidActorLimitUpper 99
pidActorTreshold 2
pidActorValueDecPlaces 0
pidCalcInterval 30
pidFactor_D 0.1
pidFactor_I 0.4
pidFactor_P 4
Die Solltemperatur ist ein jeden Tag neu errechneter Wert. Wie geschildert, sind durch D=0.1 jetzt die Ausschläge kleiner, aber PID20 regelt eigentlich eher von "oben". Der AVG zeigt, wie gut es im Schnitt passt. Die Reaktionen sind im Vergleich zum einem Heizkörper natürlich extrem viel schneller, deshalb füttere ich auch alle 45 Sekunden mit den Temperaturen von Heizungsvorlauf und Vorlauf FBH-Kreis
Falls Du Vorschläge hast für bessere Einstellungen - immer gerne!
EDIT 16.11.: Durch den nachfolgenden Beitrag bin ich darauf gestoßen, dass ich in der Überschrift des Plots noch einen Zuordnungsfehler hatte. Das Bild ist jetzt korrigiert.
Herzliche Grüße
Christian
Hallo,
ich hab jetzt ewig gerätselt, was bei mir schief läuft, da ich keinen Effekt beim D-Anteil gesehen habe; d.h. p_d ist Dauer-0.
Jetzt, nachdem ich den Plot von cwagner gesehen habe, sehe ich, das dort der D-Anteil auch Dauer-0 ist.
Ich habe versucht - bin kein FHEM-Experte - etwas zu debuggen und habe gesetzt:
attr Heizung.FBH_Regler pidDebugNotify 1
attr Heizung.FBH_Regler verbose 5
Ich hatte erwartet aus der Funktion "PID20_Notify" die Meldungen zu "tsDiff" in irgendeinem log (FileLog.Heizung.FBH_Regler oder fhem-2014-11.log) zu finden. Aber nada.
Also nochmal den Code angeguckt - habs gefunden:
Zeile 195:
if ( defined( $attr{$name} ) && defined( $attr{$name}{disable} ) )
Hier wird "disable" auf if defined abgefragt; es müsste auf if == 1 heißen.
Wenn ich das Attribut "disable" lösche, läuft die Kiste...
Viele Grüße
Markus
@Markus
du hast recht, das disable Attribut wurde nicht korrekt ausgewertet. Habs gefixed.
@Christian
Der D-Anteil darf keine Linie sein, sonst stimmt etwas nicht.
Das D-Glied bewertet ja den Gradienten, also die Änderung der Regeldifferenz über die Zeit und das kann bei deinen Kurven
nicht konstant sein.
Anbei nochmals das korrigierte Skript mit der Bitte diese zu testen. Wenn alles OK ist werde ich es einchecken.
(wurde eingechecked)
Da ich selbst keine schnellen Regelvorgänge habe, wäre es gut , wenn ihr Plots vom D-Anteil zeigen könntet.
John
Hallo John,
p-d ist bei mir nicht 0, es schwankt in sehr kleinen Werten. Hier ein Stück von heute nachmittag - die reinen Zahlen (wegen der Dimension von p-d im Vergleich zu p-i und p-p, wirkt die D nur wie eine Linie);
2014-11-16_15:34:20 PID_Mischer_FBH p_d: 0.0248813680582505
2014-11-16_15:35:51 PID_Mischer_FBH p_d: 0.0248721851706279
2014-11-16_15:36:52 PID_Mischer_FBH p_d: 0.0143549065895293
2014-11-16_15:37:53 PID_Mischer_FBH p_d: 0.0213458915027788
2014-11-16_15:39:24 PID_Mischer_FBH p_d: 0.0216208131998161
2014-11-16_15:40:25 PID_Mischer_FBH p_d: 0.0124322063086849
2014-11-16_15:41:25 PID_Mischer_FBH p_d: 0.0149306210019877
2014-11-16_15:42:57 PID_Mischer_FBH p_d: 0.014358378579982
2014-11-16_15:43:57 PID_Mischer_FBH p_d: 0.0106786537915731
2014-11-16_15:44:58 PID_Mischer_FBH p_d: 0.0124466309501089
2014-11-16_15:45:59 PID_Mischer_FBH p_d: 0.0149295206843092
2014-11-16_15:47:00 PID_Mischer_FBH p_d: 0.0106338937555385
2014-11-16_15:48:01 PID_Mischer_FBH p_d: 0.0136046682422604
2014-11-16_15:49:31 PID_Mischer_FBH p_d: 0.0124462628866459
2014-11-16_15:50:32 PID_Mischer_FBH p_d: 0.0155393638661834
2014-11-16_15:51:03 PID_Mischer_FBH p_d: 0.012214488342445
2014-11-16_15:52:34 PID_Mischer_FBH p_d: 0.0105362267701914
2014-11-16_15:53:04 PID_Mischer_FBH p_d: 0.00815090971460677
2014-11-16_15:54:05 PID_Mischer_FBH p_d: 0.00705843063482323
2014-11-16_15:55:06 PID_Mischer_FBH p_d: 0.0069281211526855
2014-11-16_15:56:06 PID_Mischer_FBH p_d: 0.0104652568873166
2014-11-16_15:57:07 PID_Mischer_FBH p_d: 0.0104652568873166
2014-11-16_15:58:08 PID_Mischer_FBH p_d: 0.00692664155385658
2014-11-16_15:59:08 PID_Mischer_FBH p_d: 0.0062306969845137
2014-11-16_16:00:09 PID_Mischer_FBH p_d: 0.0062306969845137
2014-11-16_16:00:40 PID_Mischer_FBH p_d: 0.015546602960345
2014-11-16_16:01:41 PID_Mischer_FBH p_d: 0.015546602960345
2014-11-16_16:02:41 PID_Mischer_FBH p_d: 0.00705796329198912
2014-11-16_16:03:42 PID_Mischer_FBH p_d: 0.00623725915782773
2014-11-16_16:04:42 PID_Mischer_FBH p_d: 0.0056973346187168
2014-11-16_16:05:43 PID_Mischer_FBH p_d: 0.00680180615373993
2014-11-16_16:06:44 PID_Mischer_FBH p_d: 0.00623767642555614
2014-11-16_16:07:14 PID_Mischer_FBH p_d: 0.00623767642555614
2014-11-16_16:08:15 PID_Mischer_FBH p_d: 0.00569210494465283
2014-11-16_16:09:16 PID_Mischer_FBH p_d: 0.00412194344765417
2014-11-16_16:09:46 PID_Mischer_FBH p_d: 0.014928339199675
2014-11-16_16:10:47 PID_Mischer_FBH p_d: 0.014928339199675
2014-11-16_16:11:48 PID_Mischer_FBH p_d: 0.00312164116702395
2014-11-16_16:12:49 PID_Mischer_FBH p_d: 0.00623583363607626
2014-11-16_16:13:49 PID_Mischer_FBH p_d: 0.00565219758529818
2014-11-16_16:23:51 PID_Mischer_FBH p_d: 0.00296688667049527
2014-11-16_16:33:52 PID_Mischer_FBH p_d: 0.00297336448133566
2014-11-16_16:43:54 PID_Mischer_FBH p_d: 0.0032856689926215
2014-11-16_16:53:57 PID_Mischer_FBH p_d: 0.00312175664880167
2014-11-16_17:03:59 PID_Mischer_FBH p_d: 0.00312176834677254
2014-11-16_17:13:59 PID_Mischer_FBH p_d: 0.00178467933223126
2014-11-16_17:24:00 PID_Mischer_FBH p_d: 0.00260192752536126
2014-11-16_17:34:01 PID_Mischer_FBH p_d: 0.0124484951412243
2014-11-16_17:44:01 PID_Mischer_FBH p_d: -0.00151944869433917
2014-11-16_17:46:02 PID_Mischer_FBH p_d: -0.248551318690214
2014-11-16_17:46:33 PID_Mischer_FBH p_d: -0.25701037882441
2014-11-16_17:47:04 PID_Mischer_FBH p_d: -0.226251512518227
2014-11-16_17:47:34 PID_Mischer_FBH p_d: -0.186736571096475
2014-11-16_17:48:35 PID_Mischer_FBH p_d: -0.201997551043344
2014-11-16_17:49:06 PID_Mischer_FBH p_d: -0.199206890444025
2014-11-16_17:50:07 PID_Mischer_FBH p_d: -0.194597305101541
2014-11-16_17:50:38 PID_Mischer_FBH p_d: 0.199185146120138
2014-11-16_17:51:39 PID_Mischer_FBH p_d: -0.208948621238322
2014-11-16_17:52:10 PID_Mischer_FBH p_d: 0.211665923108114
2014-11-16_17:52:40 PID_Mischer_FBH p_d: 0.261327202664079
2014-11-16_17:53:11 PID_Mischer_FBH p_d: -0.388057399997664
2014-11-16_17:54:12 PID_Mischer_FBH p_d: 0.344830650949062
2014-11-16_17:54:43 PID_Mischer_FBH p_d: -0.0746273975009399
2014-11-16_17:55:13 PID_Mischer_FBH p_d: -0.062252853995941
2014-11-16_18:01:14 PID_Mischer_FBH p_d: 0.0373524267521596
2014-11-16_18:03:15 PID_Mischer_FBH p_d: 0.0514416007022356
2014-11-16_18:05:16 PID_Mischer_FBH p_d: 0.0746916181563814
2014-11-16_18:06:17 PID_Mischer_FBH p_d: -0.0745694433464426
2014-11-16_18:06:48 PID_Mischer_FBH p_d: 0.124493902971605
2014-11-16_18:07:19 PID_Mischer_FBH p_d: 0.0746631891087321
2014-11-16_18:08:19 PID_Mischer_FBH p_d: 0.0622469495150369
2014-11-16_18:09:50 PID_Mischer_FBH p_d: -0.159470026756454
2014-11-16_18:10:21 PID_Mischer_FBH p_d: -0.174127609455332
2014-11-16_18:10:52 PID_Mischer_FBH p_d: -0.149356919185618
2014-11-16_18:11:23 PID_Mischer_FBH p_d: -0.124497217887727
2014-11-16_18:11:54 PID_Mischer_FBH p_d: -0.144211730661291
2014-11-16_18:12:25 PID_Mischer_FBH p_d: -0.128740592621842
2014-11-16_18:12:55 PID_Mischer_FBH p_d: -0.149364895027585
2014-11-16_18:13:26 PID_Mischer_FBH p_d: -0.124450319971003
2014-11-16_18:13:57 PID_Mischer_FBH p_d: -0.124271400856205
2014-11-16_18:14:28 PID_Mischer_FBH p_d: -0.112039952705348
2014-11-16_18:14:59 PID_Mischer_FBH p_d: -0.122568150238374
2014-11-16_18:15:29 PID_Mischer_FBH p_d: -0.110778592692066
2014-11-16_18:16:00 PID_Mischer_FBH p_d: -0.0871408115531655
2014-11-16_18:17:31 PID_Mischer_FBH p_d: -0.0497694034474099
2014-11-16_18:18:02 PID_Mischer_FBH p_d: -0.0745234916966797
2014-11-16_18:18:32 PID_Mischer_FBH p_d: -0.0720167838798308
2014-11-16_18:19:34 PID_Mischer_FBH p_d: 0.124474468344193
2014-11-16_18:20:05 PID_Mischer_FBH p_d: -0.0746704046769015
2014-11-16_18:21:05 PID_Mischer_FBH p_d: 0.0996010113732992
2014-11-16_18:22:36 PID_Mischer_FBH p_d: 0.0746950747992042
2014-11-16_18:24:07 PID_Mischer_FBH p_d: 0.0622443541250328
2014-11-16_18:25:37 PID_Mischer_FBH p_d: 0.0622401885528726
2014-11-16_18:26:38 PID_Mischer_FBH p_d: 0.0606001785798567
2014-11-16_18:28:39 PID_Mischer_FBH p_d: -0.0995947392619115
2014-11-16_18:29:09 PID_Mischer_FBH p_d: -0.111835158750964
2014-11-16_18:29:40 PID_Mischer_FBH p_d: -0.134996065635904
2014-11-16_18:30:11 PID_Mischer_FBH p_d: -0.112049430443321
2014-11-16_18:30:42 PID_Mischer_FBH p_d: -0.087116955498337
2014-11-16_18:31:43 PID_Mischer_FBH p_d: -0.0622468278205024
2014-11-16_18:32:43 PID_Mischer_FBH p_d: -0.0368572234539315
2014-11-16_18:33:14 PID_Mischer_FBH p_d: -0.0747007809993668
2014-11-16_18:35:14 PID_Mischer_FBH p_d: -0.0746802017441923
2014-11-16_18:35:45 PID_Mischer_FBH p_d: -0.0614301308655381
2014-11-16_18:39:46 PID_Mischer_FBH p_d: 0.0497874043577986
2014-11-16_18:43:47 PID_Mischer_FBH p_d: 0.0514863332310446
2014-11-16_18:45:48 PID_Mischer_FBH p_d: -0.06223552609857
2014-11-16_18:46:49 PID_Mischer_FBH p_d: 0.497733522533784
2014-11-16_18:47:19 PID_Mischer_FBH p_d: 0.124479985009826
2014-11-16_18:48:20 PID_Mischer_FBH p_d: 0.0497810776444732
2014-11-16_18:49:21 PID_Mischer_FBH p_d: -0.883946857221338
2014-11-16_18:49:51 PID_Mischer_FBH p_d: -0.298683561333712
2014-11-16_18:50:22 PID_Mischer_FBH p_d: 0.821581971791053
2014-11-16_18:50:53 PID_Mischer_FBH p_d: 0.246498051756514
2014-11-16_18:51:24 PID_Mischer_FBH p_d: 0.0995659391615969
2014-11-16_18:51:54 PID_Mischer_FBH p_d: 0.112026014377939
2014-11-16_18:52:25 PID_Mischer_FBH p_d: 0.0858280914633164
2014-11-16_18:52:56 PID_Mischer_FBH p_d: -0.435509245385859
2014-11-16_18:53:27 PID_Mischer_FBH p_d: -1.09546022888364
2014-11-16_18:53:58 PID_Mischer_FBH p_d: 0.550302473277117
2014-11-16_18:54:28 PID_Mischer_FBH p_d: 0.497804037039759
2014-11-16_18:54:59 PID_Mischer_FBH p_d: -0.423215791408638
2014-11-16_18:55:30 PID_Mischer_FBH p_d: -2.51018128439353
2014-11-16_19:05:31 PID_Mischer_FBH p_d: 0.0124416882873865
2014-11-16_19:15:32 PID_Mischer_FBH p_d: -0.0622376745038285
2014-11-16_19:25:51 PID_Mischer_FBH p_d: -0.0401541333821545
2014-11-16_19:35:54 PID_Mischer_FBH p_d: 0.180055651181425
2014-11-16_19:45:55 PID_Mischer_FBH p_d: 0.0366604260859924
2014-11-16_19:55:59 PID_Mischer_FBH p_d: 0.00617824871145764
2014-11-16_20:06:03 PID_Mischer_FBH p_d: 0.0122142257899577
2014-11-16_20:16:06 PID_Mischer_FBH p_d: 0.0481972309292531
2014-11-16_20:26:11 PID_Mischer_FBH p_d: -0.0708026778420629
2014-11-16_20:36:17 PID_Mischer_FBH p_d: -0.0834626955253888
2014-11-16_20:46:22 PID_Mischer_FBH p_d: 0.0520475107792625
2014-11-16_20:56:28 PID_Mischer_FBH p_d: -0.0762446769796157
2014-11-16_21:06:34 PID_Mischer_FBH p_d: 0.0536976930434043
2014-11-16_21:16:37 PID_Mischer_FBH p_d: 0.0270772238615143
Herzliche Grüße
Christian
Hallo Christian,
es gilt:
$actuationCalc = $pPortion + $iPortion + $dPortion;
Damit wäre der Einfluss vom D-Anteil bei dir praktisch 0.
John
Hallo,
habe das neue Modul getestet und es funzt. Anbei ein Bild von dem Regler in Action.
D-Anteil steht bei mir auf 20, Interval ist 10s.
Viele Grüße
Markus
Danke John und Markus -
leider kann ich in den nächsten Tagen nicht mehr groß testen, daher nur zwei Beispieel.
Ich bin nun viel mutiger geworden (P=6;i=2, D=10) und habe jetzt ein Regelergebnis, das deutlich schneller und näher an der Solllinie liegt...
Christian
Ich hab die neue Version eingechecked.
John
Moin John,
ersteinmal vielen Dank für Dein Modul, bin gerade dabei, damit meine ersten Gehversuche damit zu machen.
Dazu gleich eine Frage?
Kann es sein, dass
attr PID_CB_HZ_BZ_FB event-on-change-reading actuation,actuationCalc,delta,desired,measured,p_d,p_i,p_p
und
attr PID_CB_HZ_BZ_FB event-min-interval actuation:300,actuationCalc:300,delta:300,desired:300,measured:300,p_d:300,p_i:300,p_p:300
nicht funktioniert?
Hier mal ein Logauszug:
2014-11-23_03:49:32 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_03:59:32 PID_CB_HZ_BZ_FB actuation: 33
2014-11-23_04:09:32 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_04:19:32 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_04:29:33 PID_CB_HZ_BZ_FB actuation: 35
2014-11-23_04:44:33 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_04:44:33 PID_CB_HZ_BZ_FB actuation: 41
2014-11-23_05:04:34 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_05:14:34 PID_CB_HZ_BZ_FB actuation: 38
2014-11-23_05:24:34 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_05:29:34 PID_CB_HZ_BZ_FB actuation: 44
2014-11-23_05:39:35 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_05:59:35 PID_CB_HZ_BZ_FB actuation: 41
2014-11-23_06:29:36 PID_CB_HZ_BZ_FB actuation: 43
2014-11-23_06:47:36 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_06:47:36 PID_CB_HZ_BZ_FB actuation: 49
2014-11-23_06:57:36 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_07:17:37 PID_CB_HZ_BZ_FB actuation: 46
2014-11-23_07:47:38 PID_CB_HZ_BZ_FB actuation: 48
2014-11-23_08:17:38 PID_CB_HZ_BZ_FB actuation: 50
2014-11-23_08:47:43 PID_CB_HZ_BZ_FB actuation: 51
2014-11-23_09:07:46 PID_CB_HZ_BZ_FB measured: 19.8
2014-11-23_09:17:47 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_09:17:47 PID_CB_HZ_BZ_FB actuation: 53
2014-11-23_09:47:53 PID_CB_HZ_BZ_FB measured: 19.8
2014-11-23_09:47:53 PID_CB_HZ_BZ_FB actuation: 50
2014-11-23_10:17:55 PID_CB_HZ_BZ_FB measured: 19.9
2014-11-23_10:17:55 PID_CB_HZ_BZ_FB actuation: 46
2014-11-23_10:37:19 PID_CB_HZ_BZ_FB measured: 20
2014-11-23_10:37:19 PID_CB_HZ_BZ_FB actuation: 41
2014-11-23_10:52:37 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_10:52:37 PID_CB_HZ_BZ_FB actuation: 26
2014-11-23_11:02:49 PID_CB_HZ_BZ_FB measured: 21
2014-11-23_11:07:54 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_11:18:07 PID_CB_HZ_BZ_FB measured: 20.8
2014-11-23_11:26:19 PID_CB_HZ_BZ_FB measured: 20.7
2014-11-23_11:26:19 PID_CB_HZ_BZ_FB actuation: 5
2014-11-23_11:46:42 PID_CB_HZ_BZ_FB measured: 20.6
2014-11-23_11:56:51 PID_CB_HZ_BZ_FB actuation: 6
2014-11-23_12:07:01 PID_CB_HZ_BZ_FB measured: 20.7
2014-11-23_12:12:05 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_12:22:12 PID_CB_HZ_BZ_FB measured: 20.6
2014-11-23_12:37:23 PID_CB_HZ_BZ_FB measured: 20.5
2014-11-23_12:37:23 PID_CB_HZ_BZ_FB actuation: 7
2014-11-23_13:07:38 PID_CB_HZ_BZ_FB actuation: 4
2014-11-23_13:37:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-23_13:57:49 PID_CB_HZ_BZ_FB measured: 20.4
2014-11-23_14:07:56 PID_CB_HZ_BZ_FB actuation: 4
2014-11-23_14:38:30 PID_CB_HZ_BZ_FB actuation: 1
2014-11-23_14:53:47 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_15:24:17 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_15:24:17 PID_CB_HZ_BZ_FB actuation: 5
2014-11-23_15:49:33 PID_CB_HZ_BZ_FB measured: 20.4
2014-11-23_15:49:33 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_16:19:49 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_16:19:49 PID_CB_HZ_BZ_FB actuation: 3
2014-11-23_16:37:55 PID_CB_HZ_BZ_FB measured: 20.4
2014-11-23_16:37:55 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_16:57:57 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_17:07:59 PID_CB_HZ_BZ_FB actuation: 1
2014-11-23_17:23:00 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_17:47:18 PID_CB_HZ_BZ_FB measured: 20.2
2014-11-23_17:47:18 PID_CB_HZ_BZ_FB actuation: 5
2014-11-23_18:12:36 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_18:12:36 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_18:52:58 PID_CB_HZ_BZ_FB measured: 20.2
2014-11-23_19:13:05 PID_CB_HZ_BZ_FB actuation: 3
2014-11-23_19:43:11 PID_CB_HZ_BZ_FB actuation: 2
2014-11-23_20:01:22 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_20:01:22 PID_CB_HZ_BZ_FB p_p: -15
2014-11-23_20:01:22 PID_CB_HZ_BZ_FB p_d: 0
2014-11-23_20:01:22 PID_CB_HZ_BZ_FB p_i: 11.2200000000003
2014-11-23_20:01:22 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_20:01:22 PID_CB_HZ_BZ_FB actuationCalc: -3.77999999999973
2014-11-23_20:01:22 PID_CB_HZ_BZ_FB delta: -0.300000000000001
2014-11-23_20:11:32 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_20:11:32 PID_CB_HZ_BZ_FB p_p: -15
2014-11-23_20:11:32 PID_CB_HZ_BZ_FB p_d: 0
2014-11-23_20:11:32 PID_CB_HZ_BZ_FB p_i: 11.2200000000003
2014-11-23_20:11:32 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_20:11:32 PID_CB_HZ_BZ_FB actuationCalc: -3.77999999999973
2014-11-23_20:11:32 PID_CB_HZ_BZ_FB delta: -0.300000000000001
2014-11-23_20:21:38 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_20:21:38 PID_CB_HZ_BZ_FB p_p: -15
2014-11-23_20:21:38 PID_CB_HZ_BZ_FB p_d: 0
2014-11-23_20:21:38 PID_CB_HZ_BZ_FB p_i: 11.2200000000003
2014-11-23_20:21:38 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_20:21:38 PID_CB_HZ_BZ_FB actuationCalc: -3.77999999999973
2014-11-23_20:21:38 PID_CB_HZ_BZ_FB delta: -0.300000000000001
2014-11-23_20:51:49 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_20:51:49 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_21:01:49 PID_CB_HZ_BZ_FB measured: 20.2
2014-11-23_21:01:49 PID_CB_HZ_BZ_FB actuation: 1
2014-11-23_21:11:50 PID_CB_HZ_BZ_FB measured: 20.2
2014-11-23_21:11:50 PID_CB_HZ_BZ_FB actuation: 1
2014-11-23_21:16:52 PID_CB_HZ_BZ_FB measured: 20.2
2014-11-23_21:16:52 PID_CB_HZ_BZ_FB actuation: 0
2014-11-23_21:17:37 PID_CB_HZ_BZ_FB measured: 20.2
bis 2014-11-23_20:01:22 war das event-on-change Reading gesetzt,
von 2014-11-23_20:01:22 bis 2014-11-23_20:21:38 keins von beiden,
und ab 2014-11-23_20:21:39 beide.
Gruß Joachim
Hallo Joachim,
beides sind Standard-Readings, die aus meiner Sicht nicht vom PID20-Modul, sondern vom FHEM-Kern umgesetzt werden.
Oder liege ich da falsch ?
Hab mir mal folgendes angesehen:
Zitat
"bis 2014-11-23_20:01:22 war das event-on-change Reading gesetzt"
keine 2 aufeinanderfolgenden Werte sind gleich
2014-11-23_03:49:32 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_04:09:32 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_04:19:32 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_04:44:33 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_05:04:34 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_05:24:34 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_05:39:35 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_06:47:36 PID_CB_HZ_BZ_FB measured: 19.6
2014-11-23_06:57:36 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_09:07:46 PID_CB_HZ_BZ_FB measured: 19.8
2014-11-23_09:17:47 PID_CB_HZ_BZ_FB measured: 19.7
2014-11-23_09:47:53 PID_CB_HZ_BZ_FB measured: 19.8
2014-11-23_10:17:55 PID_CB_HZ_BZ_FB measured: 19.9
2014-11-23_10:37:19 PID_CB_HZ_BZ_FB measured: 20
2014-11-23_10:52:37 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_11:02:49 PID_CB_HZ_BZ_FB measured: 21
2014-11-23_11:18:07 PID_CB_HZ_BZ_FB measured: 20.8
2014-11-23_11:26:19 PID_CB_HZ_BZ_FB measured: 20.7
2014-11-23_11:46:42 PID_CB_HZ_BZ_FB measured: 20.6
2014-11-23_12:07:01 PID_CB_HZ_BZ_FB measured: 20.7
2014-11-23_12:22:12 PID_CB_HZ_BZ_FB measured: 20.6
2014-11-23_12:37:23 PID_CB_HZ_BZ_FB measured: 20.5
2014-11-23_13:57:49 PID_CB_HZ_BZ_FB measured: 20.4
2014-11-23_15:24:17 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_15:49:33 PID_CB_HZ_BZ_FB measured: 20.4
2014-11-23_16:19:49 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_16:37:55 PID_CB_HZ_BZ_FB measured: 20.4
2014-11-23_16:57:57 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_17:47:18 PID_CB_HZ_BZ_FB measured: 20.2
2014-11-23_18:12:36 PID_CB_HZ_BZ_FB measured: 20.3
2014-11-23_18:52:58 PID_CB_HZ_BZ_FB measured: 20.2
Das wäre ja ein eindeutiger Hinweis, dass event-on-change funktioniert.
Was konkret hättest du dir Anderes erwartet ?
John
Moin John,
mein Problem ist, dass nur measured und actuation durchgekommen sind, jedoch nicht die anderen geänderten Readings wie z.B.
p_p, p_i, p_d, desired, actuationCalc, usw.
Damit war der Plot dann nicht zu gebrauchen.
Nachdem ich das mehrere Male bei mir ausprobiert habe, um Schreibfehler meinerseits auszuschliessen, suche ich jemanden, der das gegencheckt.
Der Teufel ist schliesslich ein Eichhörnchen.
Gruß Joachim
Hi Joachim,
schick mir bitte mal die komplette PID20 Definition samt Attributen.
und ein
list <meinPID20>
John
Moin John,
kommt morgen früh, bin jetzt auf der Arbeit.
Danke für Deine Hilfe.
Gruß Joachim
Kann es sein, dass dein Regler im State "idle" liegt ?
Die Regelabweichungen aus deinem Log waren ja sehr gering. ( delta: -0.300000000000001)
Kann aber nur bei gesetztem pidDeltaTreshold>0 auftreten.
John
Guten Morgen John,
nu is Feierabend, und ich kann Deine Fragen beantworten.
erst einmal einige Informationen zum System:
- PID20-FHEM auf Cubietruck mit aktuellsten Updates
- 1-Wire-FHEM auf Fritzbox7390, über FHEM2FHEM und cloneDummy an CubieFHEM gebunden
- Heizungsregler MAX mit MAX-Cube auf Cubietruck
- Fußbodenheizung mit Oventrop Unibox RTL Plus direkt an Fernwärmeversorgung (keinen Einfluss auf VL_Temp) RL eingedrosselt auf max. 30°, Ventil auf Kleinsten Durchfluss eingedrosselt (10 l/h bei 1% Ventilöffnung).
Zitatschick mir bitte mal die komplette PID20 Definition samt Attributen.
Ersteinmal ohne event-on-change und event-min-intervall:
define PID_CB_HZ_BZ_FB PID20 TS_BZ:helper_T CB_HZ_BZ_FB:maxValveSetting
attr PID_CB_HZ_BZ_FB pidActorInterval 900
attr PID_CB_HZ_BZ_FB pidActorTreshold 1
attr PID_CB_HZ_BZ_FB pidActorValueDecPlaces 0
attr PID_CB_HZ_BZ_FB pidFactor_I 0.01
attr PID_CB_HZ_BZ_FB pidFactor_P 50
attr PID_CB_HZ_BZ_FB pidUpdateInterval 60
attr PID_CB_HZ_BZ_FB room Badezimmer,PID
und das dazugehörige list:
Internals:
CFGFN ./FHEM/000_max.cfg
DEF TS_BZ:helper_T CB_HZ_BZ_FB:maxValveSetting
NAME PID_CB_HZ_BZ_FB
NR 241
NTFY_ORDER 50-PID_CB_HZ_BZ_FB
STATE processing
TYPE PID20
Readings:
2014-11-25 07:24:49 actuation 0
2014-11-25 07:24:49 actuationCalc -0.818454999999903
2014-11-25 07:24:49 delta -0.0338999999999992
2014-11-25 07:24:49 desired 20
2014-11-25 07:24:49 measured 20.0339
2014-11-25 07:24:49 p_d 0
2014-11-25 07:24:49 p_i 0.876545000000055
2014-11-25 07:24:49 p_p -1.69499999999996
2014-11-25 07:24:49 state processing
Helper:
actor CB_HZ_BZ_FB
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 900
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2014-11-25 07:23:49
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 8.48067458240056e-05
deltaOld -0.0254000000000012
deltaOldTS 2014-11-25 07:25:00
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.01
factor_P 50
isWindUP 1
measuredName measured
reading helper_T
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor TS_BZ
sensorTimeout 3600
stopped 0
updateInterval 60
Attributes:
pidActorInterval 900
pidActorTreshold 1
pidActorValueDecPlaces 0
pidFactor_I 0.01
pidFactor_P 50
pidUpdateInterval 60
room Badezimmer,PID
und ein Bild dazu:
(http://forum.fhem.de/index.php?action=dlattach;topic=17067.0;attach=22019;image)
Und jetzt das ganze mit gesetzten event-on-change und event-min-intervall:
define PID_CB_HZ_BZ_FB PID20 TS_BZ:helper_T CB_HZ_BZ_FB:maxValveSetting
attr PID_CB_HZ_BZ_FB event-min-interval actuation:300,actuationCalc:300,delta:300,desired:300,measured:300,p_d:300,p_i:300,p_p:300
attr PID_CB_HZ_BZ_FB event-on-change-reading actuation,actuationCalc,delta,desired,measured,p_d,p_i,p_p
attr PID_CB_HZ_BZ_FB pidActorInterval 900
attr PID_CB_HZ_BZ_FB pidActorTreshold 1
attr PID_CB_HZ_BZ_FB pidActorValueDecPlaces 0
attr PID_CB_HZ_BZ_FB pidFactor_I 0.01
attr PID_CB_HZ_BZ_FB pidFactor_P 50
attr PID_CB_HZ_BZ_FB pidUpdateInterval 60
attr PID_CB_HZ_BZ_FB room Badezimmer,PID
und das dazugehörige list:
Internals:
CFGFN ./FHEM/000_max.cfg
DEF TS_BZ:helper_T CB_HZ_BZ_FB:maxValveSetting
NAME PID_CB_HZ_BZ_FB
NR 241
NTFY_ORDER 50-PID_CB_HZ_BZ_FB
STATE processing
TYPE PID20
Readings:
2014-11-25 07:49:57 actuation 1
2014-11-25 07:49:57 actuationCalc 0.896805000000009
2014-11-25 07:49:57 delta 0.000399999999999068
2014-11-25 07:49:57 desired 20
2014-11-25 07:49:57 measured 19.9996
2014-11-25 07:49:57 p_d 0
2014-11-25 07:49:57 p_i 0.876805000000055
2014-11-25 07:49:57 p_p 0.0199999999999534
2014-11-25 07:49:57 state processing
Helper:
actor CB_HZ_BZ_FB
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 900
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2014-11-25 07:38:54
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient -9.9775223475371e-07
deltaOld 0.000299999999999301
deltaOldTS 2014-11-25 07:50:00
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.01
factor_P 50
isWindUP
measuredName measured
reading helper_T
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor TS_BZ
sensorTimeout 3600
stopped 0
updateInterval 60
Attributes:
event-min-interval actuation:300,actuationCalc:300,delta:300,desired:300,measured:300,p_d:300,p_i:300,p_p:300
event-on-change-reading actuation,actuationCalc,delta,desired,measured,p_d,p_i,p_p
pidActorInterval 900
pidActorTreshold 1
pidActorValueDecPlaces 0
pidFactor_I 0.01
pidFactor_P 50
pidUpdateInterval 60
room Badezimmer,PID
auch wieder ein Bild dazu:
(http://forum.fhem.de/index.php?action=dlattach;topic=17067.0;attach=22021;image)
Und ein Logauszug (ab 07:28:50 mit event-on-change und event-min-intervall) :
2014-11-25_07:15:47 PID_CB_HZ_BZ_FB p_i: 0.877216000000055
2014-11-25_07:15:47 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:15:47 PID_CB_HZ_BZ_FB actuationCalc: 0.882216000000043
2014-11-25_07:15:47 PID_CB_HZ_BZ_FB delta: 9.99999999997669e-05
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB measured: 19.9999
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB p_p: 0.00499999999998835
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB p_i: 0.877217000000055
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB actuationCalc: 0.882217000000043
2014-11-25_07:16:48 PID_CB_HZ_BZ_FB delta: 9.99999999997669e-05
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB measured: 19.9999
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB p_p: 0.00499999999998835
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB p_i: 0.877218000000055
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB actuationCalc: 0.882218000000043
2014-11-25_07:17:48 PID_CB_HZ_BZ_FB delta: 9.99999999997669e-05
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB measured: 20.0156
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB p_p: -0.779999999999959
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB p_i: 0.877062000000055
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB actuationCalc: 0.0970620000000965
2014-11-25_07:18:48 PID_CB_HZ_BZ_FB delta: -0.0155999999999992
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB measured: 20.0156
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB p_p: -0.779999999999959
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB p_i: 0.876906000000055
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB actuationCalc: 0.0969060000000964
2014-11-25_07:19:48 PID_CB_HZ_BZ_FB delta: -0.0155999999999992
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB measured: 20.0117
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB p_p: -0.585000000000058
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB p_i: 0.876789000000055
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB actuationCalc: 0.291788999999997
2014-11-25_07:20:48 PID_CB_HZ_BZ_FB delta: -0.0117000000000012
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB measured: 20.0244
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB p_p: -1.22
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB p_i: 0.876545000000055
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB actuationCalc: -0.343454999999944
2014-11-25_07:21:48 PID_CB_HZ_BZ_FB delta: -0.0244
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB measured: 20.0244
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB p_p: -1.22
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB p_i: 0.876545000000055
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB actuationCalc: -0.343454999999944
2014-11-25_07:22:48 PID_CB_HZ_BZ_FB delta: -0.0244
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB measured: 20.0339
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB p_p: -1.69499999999996
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB p_i: 0.876545000000055
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB actuation: 0
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB actuationCalc: -0.818454999999903
2014-11-25_07:23:49 PID_CB_HZ_BZ_FB delta: -0.0338999999999992
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB measured: 20.0339
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB p_p: -1.69499999999996
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB p_i: 0.876545000000055
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB actuation: 0
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB actuationCalc: -0.818454999999903
2014-11-25_07:24:49 PID_CB_HZ_BZ_FB delta: -0.0338999999999992
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB measured: 20.0254
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB p_p: -1.27000000000006
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB p_i: 0.876545000000055
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB actuation: 0
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB actuationCalc: -0.393455000000005
2014-11-25_07:25:49 PID_CB_HZ_BZ_FB delta: -0.0254000000000012
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB measured: 20.0191
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB p_p: -0.955000000000084
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB p_i: 0.876545000000055
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB actuation: 0
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB actuationCalc: -0.0784550000000287
2014-11-25_07:26:50 PID_CB_HZ_BZ_FB delta: -0.0191000000000017
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB measured: 20.0191
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB p_p: -0.955000000000084
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB p_d: 0
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB p_i: 0.876545000000055
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB actuation: 0
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB actuationCalc: -0.0784550000000287
2014-11-25_07:27:50 PID_CB_HZ_BZ_FB delta: -0.0191000000000017
2014-11-25_07:28:50 PID_CB_HZ_BZ_FB measured: 20.0143
2014-11-25_07:29:50 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:29:50 PID_CB_HZ_BZ_FB measured: 20.0143
2014-11-25_07:29:50 PID_CB_HZ_BZ_FB actuation: 0
2014-11-25_07:30:50 PID_CB_HZ_BZ_FB measured: 20.0107
2014-11-25_07:31:50 PID_CB_HZ_BZ_FB measured: 19.9924
2014-11-25_07:33:50 PID_CB_HZ_BZ_FB measured: 19.9943
2014-11-25_07:34:50 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:34:50 PID_CB_HZ_BZ_FB actuation: 0
2014-11-25_07:35:50 PID_CB_HZ_BZ_FB measured: 19.9957
2014-11-25_07:36:54 PID_CB_HZ_BZ_FB measured: 19.9968
2014-11-25_07:38:54 PID_CB_HZ_BZ_FB measured: 19.9976
2014-11-25_07:38:54 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:39:54 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:40:54 PID_CB_HZ_BZ_FB measured: 19.9982
2014-11-25_07:41:54 PID_CB_HZ_BZ_FB measured: 19.9987
2014-11-25_07:43:54 PID_CB_HZ_BZ_FB measured: 19.999
2014-11-25_07:43:54 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:44:54 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:45:54 PID_CB_HZ_BZ_FB measured: 19.9993
2014-11-25_07:46:57 PID_CB_HZ_BZ_FB measured: 19.9995
2014-11-25_07:48:57 PID_CB_HZ_BZ_FB measured: 19.9996
2014-11-25_07:48:57 PID_CB_HZ_BZ_FB actuation: 1
2014-11-25_07:49:57 PID_CB_HZ_BZ_FB desired: 20
2014-11-25_07:50:57 PID_CB_HZ_BZ_FB measured: 19.9997
Gruß Joachim
Hallo Joachim,
folgendes halte ich für absolut kontraproduktiv:
attr PID_CB_HZ_BZ_FB event-min-interval actuation:300,actuationCalc:300,delta:300,desired:300,measured:300,p_d:300,p_i:300,p_p:300
Beispiel actuationCalc: wird nur als Event weitergereicht, wenn mindestens 5 Minuten vergangen sind. D.h es werden effektiv bestimmte Änderungen ignoriert und somit nicht gelogged.
Das führt zum Ausschnitt wie im Bild dargestellt.
(http://forum.fhem.de/index.php?action=dlattach;topic=17067.0;attach=22061)
Actuation fährt hoch ohne dass ActuationCalc diese induziert.
Die Readings werden nicht regelmässig aktualisiert, sondern nur dann wenn es nötig ist.
Es gibt durchaus Zustände, in denen die P/I/D-Anteile nicht mehr aktualisiert werden (z.B. Anti-Windup).
Also verzichte event-min-interval und alles wird gut. Man sieht dass alles plausibel ist, wenn du dieses Attribut nicht verwendest.
Würde ich die Ursache nicht kennen, müsste man meinen PID20 arbeitet fehlerhaft.
John
Moin John,
dann ist meine Frage geklärt, und ich muss das Problem nicht bei mir suchen.
event-on-change und event-min-intervall funktionieren nicht wie gewohnt mit PID20.
Wenn man einen durchgehenden Plot haben möchte, sollte man darauf verzichten.
Wieso Du das für kontraproduktiv hälst, erschliesst sich mir allerdings noch nicht ganz.
Gerade in der Einregelungszeit des Thermotaten (oder zur Fehlersuche) ist ein Plot genial, um zu verstehen, wie sich Änderungen auswirken.
Unnötig ist es aber, jedes mal alle Werte, auch die nicht geänderten, zu Loggen.
Danke für Deine Antwort, werde mich nun an die Optimierung meiner FB_Heizung machen.
Gruß Joachim
ZitatWieso Du das für kontraproduktiv hälst, erschliesst sich mir allerdings noch nicht ganz.
event-on-change-reading habe ich nicht kritisiert, aber event-min-intervall.
Wenn letzteres dazu führt, dass wichtige Änderungen nicht dargestellt werden, kommt man zu einem falschen Bild
und zu falschen Rückschlüssen. (Siehe vorheriger Post)
John
Ich hege den Verdacht, wir reden aneinander vorbei.
Bisher hatte ich die Kombination auch event-on-change und event-min-intervall so verstanden, dass jede Änderung eines angegebenen Wertes zu einem Event, und damit zu einem Eintrag im Log führt. Da dadurch allerdings Werte, die sich nicht verändert haben nicht zu einem Event, und damit zu einem Eintrag im Log füren benötigt man event-min-intervall, um nach einer Vorgegbenen Zeit (die 300 Sekunden sind natürlich zu kurz) auch für diese Werte, z.B. desired einen Eintrag im Log zu haben.
So war es zumindest bisher bei jedem anderen Log. deshalb irretierte mich dieses Verhalten.
Joachim
ja. so hängen beide zusammen.
wenn es dir aber nur um die plots geht ist min-intervall nicht nötig wenn du logProxy verwendest.
gruß
andre
Moin Andre,
danke für die Info, mit logProxy bin ich schon am ausprobieren, ist schön geworden, werde ich auch die Tage noch mal im richtigen Thread eine Frage stellen.
Ich war halt nur irritiert, das es bei PID20 nicht so geht, wie gewohnt, und wollte den Fehler bei mir ausschliessen.
(es würde mich natürlich brennend interessieren, warum?)
Gruß Joachim
Hallo Joachim,
ich glaube ich habe das Problem entdeckt. Muss es noch genauer untersuchen.
John
Moin John,
Zitatich glaube ich habe das Problem entdeckt. Muss es noch genauer untersuchen.
Das ist schön, dass Du da dran bist.
Mittlerweile habe ich meine ersten Gehversuche mit dem Regler gemacht, und dabei ist mir etwas aufgefallen.
Meine wunderschön auf Linie laufende PID_Regelung kommt bei Sollwertänderung aus dem Tritt.
Das liegt mMn an der Sollwertänderung, und könnte durch eine Anti-WindUp-Strategie II beseitigt werden.
Hier mal meine nicht wissenschaftlich korrekte Begründung dazu:
Wenn man von außen (also durch Sollwertänderung) den Regler aus dem Tritt bringt, macht es Sinn, den I-Anteil bis zum Erreichen der neuen Solltemperatur einzufrieren, da sich die eigentlichen Regelparameter (Energiezufluss, Energieabfluss) nicht verändert haben. Der I-Anteil darf sich also bis zum Erreichen der neuen Solltemperatur nicht verändern, da sonst bei erreichen der Solltemperatur ein Überschwingen erfolgt, welches sich nur sehr langsam abbaut.
Im Bild ist es sehr gut zu erkennen.
Gruß Joachim
Hallo Joachim,
sind das die aktuellen Regelparameter ?
factor_D 0
factor_I 0.01
factor_P 50
Überleg dir zunächst mal bei welcher Regeldifferenz, das Ventil zu 100% geöffnet sein soll.
Gehen wir von Delta T=1 °C aus.
Mit einem P-Faktor von 100 würde der P-Anteil schon 100% Öffnung fordern. Der Regler wäre im "Wind-UP" , der I-Anteil eingefroren.
Ich denke du solltest erst die Reglerparameter ausloten, bevor wir uns neue noch komplexere Mechanismen überlegen.
Woher kommen eigentlich die Nadelimpulse beim Istwert ?
John
Moin John,
Zitatsind das die aktuellen Regelparameter ?
Nein, habe da natürlich schon versucht, das Regelverhalten zu ändern, allerdings ist das Haus super gedämmt, und draussen ist es noch zu warm.
Es ist mir halt nur ins Auge gefallen, dass mir der I-Anteil nach Sollwertänderung einen Strich durch die Rechnung macht.
Aktuelle Regelparameter:
Internals:
CFGFN ./FHEM/000_max.cfg
DEF TS_BZ:helper_T CB_HZ_BZ_FB:maxValveSetting
NAME PID_CB_HZ_BZ_FB
NR 248
NTFY_ORDER 50-PID_CB_HZ_BZ_FB
STATE processing
TYPE PID20
Readings:
2014-11-27 15:59:24 actuation 0
2014-11-27 15:59:54 actuationCalc -2.76341361607922
2014-11-27 15:59:54 delta -0.170100000000001
2014-11-27 15:59:24 desired 19
2014-11-27 15:59:24 measured 19.1701
2014-11-27 15:59:54 p_d -0.000173616079222227
2014-11-27 15:59:54 p_i 3.19026000000006
2014-11-27 15:59:54 p_p -5.95350000000005
2014-11-27 15:59:54 state processing
Helper:
actor CB_HZ_BZ_FB
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 840
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 35
actorThreshold 1
actorTimestamp 2014-11-27 15:59:24
actorValueDecPlaces 0
adjust
calcInterval 30
deltaGradient -0.000192156850932329
deltaOld -0.190100000000001
deltaOldTS 2014-11-27 16:00:04
deltaTreshold 0
desiredName desired
disable 0
factor_D 0.1
factor_I 0.08
factor_P 35
isWindUP 1
measuredName measured
reading helper_T
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor TS_BZ
sensorTimeout 3600
stopped 0
updateInterval 60
Attributes:
pidActorInterval 840
pidActorLimitUpper 35
pidActorTreshold 0.5
pidActorValueDecPlaces 0
pidCalcInterval 30
pidFactor_D 0.1
pidFactor_I 0.08
pidFactor_P 35
pidUpdateInterval 60
room Badezimmer,PID
ZitatWoher kommen eigentlich die Nadelimpulse beim Istwert ?
Duschen!
Ich habe jetzt ersteinmal pidActorLimitUpper auf 35 % reduziert, und werde jetzt mal den nächsten Versuch fahren.
Wie bekomme ich eigentlich p_I auf 0 gesetzt?
Mit löschen von pidFactor_I und restart 0 geht es nicht.
Hier noch einmal ein Bild in besserer Auflösung mit dem überschiessenden I_Anteilund eins nach löschen und restart von pidFactor_I und pidFactor_d
Gruß Joachim
ZitatWie bekomme ich eigentlich p_I auf 0 gesetzt?
wenn du das Attribut pidFactor_I =0 setzt.
"I" steht für Integral-Anteil.
John
Die neue Version 1.0.0.4 ist eingechecked.
Die Readings werden nun zyklisch aktualisiert, so daß die Standardmechanismen von FHEM greifen: event-on-change-reading, event-min-interval.
Mit der neuen Version erhöht sich die Aktualisierung der Readings dramatisch.
Damit die Log-Dateien nicht übermäßig gross werden sollte man die Events begrenzen.
Ich habe mich bei meinem Regler für folgende Einstellungen entschieden:
Event nur feuern, wenn sich Reading um einen Mindestwert ändert:
attr PID.PID event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0
Event auch dann feuern, wenn dieser innerhalb eines festgelegten Zeitraums (hier 30 Minuten) nicht gefeuert wrude (für die Charts sinnvoll)
attr PID.PID event-min-interval .*:1800
John
Tolles Modul.
Ist es gewollt, das definierte UserReadings aktualisiert werden, wenn "desired" geändert wird?
und nicht zum definierten CalcIntervall?
Gruß
Hallo My-FHEM,
wenn du desired aktualisierst, wird in jedem Fall auch das Reading "desired" beschrieben.
Die Aktualisierung von UserReadings wird nicht im PID.Modul, sondern im FHEM-Kern geregelt.
Die CommandRef sollte hier weiterhelfen.
John
@ John, Danke für deinen Hinweis.
Wie kann ich erreichen, d.h. welcher Event kann als trigger benutzt werden sodas ein userReading synchron zum CalcInterval aktualisiert wird?
Gruß
actuationCalc wird sich am häufigsten ändern und wird in jedem Zyklus geschrieben.
John
Hallo,
ich habe heute das PID20 Modul ausprobiert und bin direkt in der define-Anweisung auf ein kleines Problem gestoßen. Meine Definition sollte so aussehen:
define PID.PID PID20 netatmo_D70:ee:50:04:cd:38:temperature MAX_1059f4:maxValveSetting
wobei "netatmo_D70:ee:50:04:cd:38" der Name meines Sensors ist. Ich erhalte als Fehlermeldung: "PID.PID: Unknown sensor device netatmo_D70 specified". Meine Vermutung ist, dass das Reading (also "temperature" in diesem Fall) direkt nach dem ersten auftretenden Doppelpunkt erwartet wird.
Ein Versuch, den Alias des Sensors zu verwenden hat leider nicht funktioniert. "Unknown Sensor..."
Ich hoffe, der Beitrag ist hier richtig.
Viele Grüße
Alter Schwede
Das Problem hatte ich auch. Die Doppelpunkte im Namen der Netatmo sind das Problem. Benenne die Netatmo Module um, dann dann sollte das klappen.
@AlterSchwede
mkninc hat wohl recht.
Das Problem ist, daß der Doppelpunkt als Separator zwischen Device-Namen und Reading verwendet wird.
Das ist überall so in FHEM.
Der Name ist daher extrem ungünstig.
Umbemennen geht via "rename <alt> <neu>"
John
Hallo John, Hallo mkninc!
Die Netatmo ist umbenannt. Danach hat alles bestens funktioniert. Tolles Modul! Danke!
Der erste Thermostat läuft als Stellglied. Morgen sind die beiden anderen dran!
Viel Erfolg und ein Gesundes Neues Jahr!
Der Alte Schwede
Hallöle,
ich habe eine Anwendung, bei der ich einen Heizstrahler mit einem FS20-Dimmer ansteuern möchte. Dazu verwende ich das PID20-Modul.
Problem war, dass der FS20-Dimmer nur in Stufen von 6,25 % dimmt und das im PID20-Modul nicht einstellbar war.
Ich habe deshalb eine kleine Änderung vorgenommen:
+ Zusätzlicher Parameter FS20Dim
+ Wenn dieser auf '1', wird der Actuator in 6.25er-Schritten angesteuert
Das diff dazu:
--- ./98_PID20.pm 2015-01-24 10:40:53.164577065 +0100
+++ /opt/fhem/FHEM/98_PID20.pm 2015-01-24 10:42:06.811027901 +0100
@@ -107,7 +107,7 @@
. "pidDebugDelta:0,1 "
. "pidDebugUpdate:0,1 "
. "pidDebugNotify:0,1 "
-
+ . "FS20Dim:0,1 "
. "disable:0,1 "
. $readingFnAttributes;
@@ -672,6 +672,12 @@
# perform output to actor
if ($actuationReq)
{
+ if (AttrVal($name, 'FS20Dim', '0') eq '1')
+ {
+ my $int = sprintf("%.0f", $actuation/6.25);
+ $actuation = int($int * 6.25);
+ }
+
#build command for fhem
PID20_Log $hash, 5, "actor:".$hash->{helper}{actor}
." actorCommand:".$hash->{helper}{actorCommand}
Viele Grüße
Nick666
Moin Nick666,
nette Idee, besser wäre, wenn man die Dimmschritte frei wählen könnte.
Ich habe z.B. das Problem, dass die Max-Thermostaten in meiner Konstellation im unteren Bereich Probleme mit 1% Schritten haben (die ersten 0-5%) danach ist es egal.
Gruß Joachim
Ich habe mittlerweile diese Lösung erfolgreich in Betrieb:
--- ./98_PID20.pm 2015-01-24 10:40:53.164577065 +0100
+++ /opt/fhem/FHEM/98_PID20.pm 2015-01-25 10:59:43.656551209 +0100
@@ -107,7 +107,7 @@
. "pidDebugDelta:0,1 "
. "pidDebugUpdate:0,1 "
. "pidDebugNotify:0,1 "
-
+ . "pidActorStepWidth "
. "disable:0,1 "
. $readingFnAttributes;
@@ -672,6 +672,14 @@
# perform output to actor
if ($actuationReq)
{
+ # Calc actor step width if 'pidActorStepWidth' is set
+ my $StepWidth = AttrVal($name, 'pidActorStepWidth', '0');
+ if ($StepWidth ne '0')
+ {
+ my $int = sprintf("%.0f", $actuation/$StepWidth);
+ $actuation = int($int * $StepWidth);
+ }
+
#build command for fhem
PID20_Log $hash, 5, "actor:".$hash->{helper}{actor}
." actorCommand:".$hash->{helper}{actorCommand}
Mit 'pidActorStepWidth' kann man eine Schrittweite angeben, im Falle von FS20-Dimmern also 6.25.
Ist somit etwas flexibler gehalten.
Grüße
Nick
Zitat von: Joachim am 24 Januar 2015, 14:34:07
Ich habe z.B. das Problem, dass die Max-Thermostaten in meiner Konstellation im unteren Bereich Probleme mit 1% Schritten haben (die ersten 0-5%) danach ist es egal.
Das, oder ein ähnliches Problem hatte ich auch. Unter 5-6% sind die Thermostaten noch komplett zu. Ich hatte anfangs mal mit dem Parameter pidActorLimitLower gespielt, allerdings schneidet der alle Regeländerungen unterhalb des Limits einfach ab. Was dann zum gleichen Ergebnis führt. Ist halt mehr als mechanisches Limit gedacht. Deshalb hab ich bei mir noch einen neuen Parameter eingeführt, der als Offset drauf gerechnet wird. Sodass auch Regeländerungen im unteren Bereich von 1-5 % schon eine Änderung bewirken.
--- FHEM/98_PID20.pm (revision 7702)
+++ FHEM/98_PID20.pm (working copy)
@@ -89,6 +89,7 @@
. "pidActorKeepAlive "
. "pidActorLimitLower "
. "pidActorLimitUpper "
+ . "pidActorDeadZoneLower "
. "pidCalcInterval "
. "pidDeltaTreshold "
. "pidDesiredName "
@@ -288,7 +289,8 @@
$ret .= 'Factor I : ' . $hash->{helper}{factor_I} . "\n";
$ret .= 'Factor D : ' . $hash->{helper}{factor_D} . "\n\n";
$ret .= 'Actor lower limit: ' . $hash->{helper}{actorLimitLower} . "\n";
- $ret .= 'Actor upper limit: ' . $hash->{helper}{actorLimitUpper} . "\n";
+ $ret .= 'Actor upper limit: ' . $hash->{helper}{actorLimitUpper} . "\n\n";
+ $ret .= 'Actor lower dead zone: ' . $hash->{helper}{actorDeadZoneLower} . "\n";
return $ret;
}
default { return $usage; }
@@ -438,6 +440,8 @@
my $actorLimitLower = $hash->{helper}{actorLimitLower};
$hash->{helper}{actorLimitUpper} = ( AttrVal( $name, 'pidActorLimitUpper', 100 ) =~ m/$reFloat/ ) ? $1 : 100;
my $actorLimitUpper = $hash->{helper}{actorLimitUpper};
+ $hash->{helper}{actorDeadZoneLower} = ( AttrVal( $name, 'pidActorDeadZoneLower', 0 ) =~ m/$reFloat/ ) ? $1 : 0;
+ my $actorDeadZoneLower = $hash->{helper}{actorDeadZoneLower};
$hash->{helper}{factor_P} = ( AttrVal( $name, 'pidFactor_P', 25 ) =~ m/$reFloatpos/ ) ? $1 : 25;
$hash->{helper}{factor_I} = ( AttrVal( $name, 'pidFactor_I', 0.25 ) =~ m/$reFloatpos/ ) ? $1 : 0.25;
$hash->{helper}{factor_D} = ( AttrVal( $name, 'pidFactor_D', 0 ) =~ m/$reFloatpos/ ) ? $1 : 0;
@@ -533,6 +537,12 @@
# calc actuation
$actuationCalc = $pPortion + $iPortion + $dPortion;
+
+ # add dead zone offset
+ if ($actuationCalc > 0.1)
+ {
+ $actuationCalc = $actuationCalc + $actorDeadZoneLower;
+ }
PID20_Log $hash, 2, "P1 delta:" . sprintf( "%.2f", $delta ) . " isWindup:$isWindup" if ($DEBUG_Calc);
Zu den vielfältigen Wünschen der letzten Einträge zum Thema Stellausgabe:
Ich schlage eine Callback-Funktion vor, in der der Anwender seine spezifische Implementierung für
die Wertvorgabe zum Stellwert realisieren kann.
Diese Methode würde immer unmittelbar vor der Ausgabe eines Stellwertes ausgeführt werden.
Damit könnte man alle beliebig exotischen Regeln implementieren ohne das Basis-Modul zu überfrachten.
John
So exotisch find ich die Sachen gar nicht.
Das Runden auf 6,25% passt doch schon fast zum Parameter pidActorValueDecPlaces. Den könnte man erweitern. Ist doch egal, ob ich z.B. auf 2 Nachkommastellen, bzw. Vielfache von 0,01 Runde, oder eben auf Vielfache von 6,25. Das könnte man evtl. sogar abwärtskompatibel implementieren.
Und für meine Änderung fände ich eine Callbackfunktion auch eher ungünstig. Die Einstellung will ich ja individuell für jedes Thermostat machen. Vielleicht habe ich aber auch noch nicht die Funktion von pidActorLimitLower richtig verstanden. Oder wie ist der gedacht?
Hallo,
ich habe folgendes Verhalten beobachtet:
Obwohl ich ActorErrorAction auf 'errorPos' und ActorErrorPos auf '0' gestellt habe, wird der Actor bei einem Fehler nicht auf 0 gesetzt, sondern auf der aktuellen Positionen eingefroren. Die Readings blieben auch auf den alten Werten (außer state, der den alarm entsprechend anzeigt) und es tauchen auch keine Events mehr auf. Ist das vielleicht ein Fehler im Modul und kann das jemand bestätigen (einen Fehler kann man recht leicht provozieren, indem man zB SensorTimeout auf '1' stellt) oder muss ich bei mir noch an einer anderen Stelle weitersuchen?
und noch eine andere Sache:
Ich würde solch einen Fehlerfall gerne weiter mit notifies auswerten, jedoch taucht 'state' nicht in den Events auf und ich weiß nicht, wie ich das sonst auswerten könnte. Jemand eine Idee?
Viele Grüße
Nick666
Hallo Nick666,
ich habe das selbst probiert und es funktioniert.
Stell bitte ein die Ausgabe von "list <dein PID>" hier rein.
John
Seltsam, habs gerade nochmal auch mit einer "unbefummelten" 98_PID20.pm probiert. Der Wert friert ein aber wird nicht auf 0 (oder andere Werte in actorErrorPos) gesetzt. Bin mal gespannt, wechen Denkfehler ich diesmal wieder drin hab :)
Internals:
DEF TH.Terrarium:temperature HZ.Terrarium:dim
NAME PID.HZ.Terrarium
NR 25
NTFY_ORDER 50-PID.HZ.Terrarium
STATE processing - Soll: 24 °C
TYPE PID20
Readings:
2015-02-02 23:00:19 actuation 46
2015-02-02 23:00:19 actuationCalc 45.7500000000001
2015-02-02 23:00:19 delta 0.399999999999999
2015-02-02 23:00:19 desired 24
2015-02-02 23:00:19 measured 23.6
2015-02-02 23:00:19 p_d 0
2015-02-02 23:00:19 p_i 33.2500000000001
2015-02-02 23:00:19 p_p 12.5
2015-02-02 23:00:19 state processing
Helper:
actor HZ.Terrarium
actorCommand dim
actorErrorAction errorPos
actorErrorPos 0
actorInterval 1
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2015-02-02 23:00:19
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld 0.399999999999999
deltaOldTS 2015-02-02 22:59:57
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 1.25
factor_P 31.25
isWindUP
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor TH.Terrarium
sensorTimeout 180
stopped 0
updateInterval 600
Attributes:
pidActorErrorAction errorPos
pidActorErrorPos 0
pidActorInterval 1
pidFactor_I 1.25
pidFactor_P 31.25
pidSensorTimeout 180
room Terrarium.Technik
stateFormat state - Soll: desired °C
Hi nick666
Zitat2015-02-02 23:00:19 state processing
also der ist noch nicht eingefroren.
John
Nein, ist ein Auszug bei normalem Betrieb. Ich dachte, es geht um die Einstellungen.
Wie auch immer, spätestens nach pidActorKeepAlive aktualisiert er die Werte und damit auch die errorPos. Für meine Anwendung ist mir der Standardwert aber zu groß und ich habe diesen entsprechend angepasst.
Grüße
Nick
Hallo,
eigentlich ist das PID20 Modul ja für die Regelung von Stellantrieben gedacht und das Funktionsprinzip ist mir auch soweit klar, ich würde aber gerne eine Pumpe darüber schalten, ich weiß aber nicht was ich für den actor als cmd angeben muss, damit nicht ein Regelwert zwischen 0 und 100 ausgegeben wird, sondern on/off.
Im Wiki, Forum oder Commandreff konnte ich dazu nix finden.
LG
Hi MadCat
für digitale Stellglieder ist eventuell das Threshold Modul besser geeignet.
Ansonsten solltest du die Problemstellung genauer spezifizieren.
Konkret: was hast du vor.
John
Hallo John,
ich würde gerne mit dem Pid Regler meine Heizkreispumpe steuern. Mit dem Threshold habe ich das schon versucht, aber da das ganze zu träge ist kommt es zu Temperaturschwankungen von ca 5 bis 10°C, das hoffe ich mit dem PID zu minimieren.
Lg
Hi MadCat
es ist nicht klar was du regeln willst. (Regler Führungsgröße)
Vorlauftemperatur, Rücklauftemperatur, Raumtemperatur im Führungsraum,... ?
Hast du Kurven vom bisherigen Regelverhalten und beschreibe was dir daran nicht gefällt.
Wie sieht die Stellausgabe aus ?
Der PID gibt als Stellgroesse 0..100% aus.
Willst du das Puls/Pausenverhältnis über den Stellausgang des PIDs ändern ? (Regler Stellgröße)
Wie hoch soll die Periodendauer eines Schaltzyklus (Pumpe EIN - Pumpe AUS) sein ?
Wieviele Ein/Aus-Takte sind laut Hersteller für die HK-Pumpe pro Tag zulässig ?
John
Hallo,
ich habe zwei Fragen / Probleme beim PID20-Regler. Vielleicht könnt ihr mir ja helfen :-)
Zunächst etwas Information: ich steuere mit dem PID-Regler den Vorlauf meiner Fußbodenheizung. Die Ist-Temperatur ändert sich bei Änderungen am Actor (aktuell ein MAX-Thermostat) sehr, sehr schnell (<1 Min), zudem gibt es immer wieder starke Ausschläge (z.B. wenn einer der angeschlossenen FBH-Heizkreise zu macht). Diese starken Ausschläge versuche ich über eine entsprechende Einstellung des D-Anteiles schnell entgegenzuregeln. Nun zu meinen Fragen / Problemen:
1. Der D-Anteil kann verloren gehen, wenn pidcalcinterval kleiner pidactorlimit ist.
Mein pidcalcinterval ist auf 60, mein pidactorlimit ist auf 180. Unter der Annahme, dass in Sekunde 0 eine Änderung des Actors erfolgte, passiert folgendes: wenn die schnelle Änderung der zu regelnden Größe in den Sekunden 1-120 erfolgt, und in den Sekunden 121-180 die Größe sich normal schnell ändert, geht nach meinem Verständnis (und wenn ich meine Plots richtig lese) der D-Anteil bei der Berechnung des actuationCalc verloren. Meine nächste Idee war also, pidcalcinterval gleich pidactorlimit zu setzen. Aber neben dem Nachteil, dass der I-Anteil dann nicht weiter integriert würde, hätte man nach meinem Verständnis auch das Problem, dass eine Neuberechnung immer erst nach 180 Sekunden erfolgt, selbst wenn vorher zum Beispiel 360 Sekunden der Actor nicht verändert wurde. Ist ja auch Mist :-(
Ist mein Verständnis hierzu richtig und habt ihr Vorschläge?
2. Sensor immer bei Neuberechnung auslesen
Dies ist nicht unbedingt direkt PID20-bezogen, aber vielleicht könnt ihr mir ja trotzdem helfen: wie kann ich sicherstellen, dass der PID-Regler, immer direkt vor der Berechnung den Sensor ausliest? Ich habe einen DS18B20 Temperatursensor, bei dem das PollingInterval aktuell auf 30 Sek. gesetzt ist. Das macht aber die Log-Files ganz schön zu und außerdem gibt es immer etwas Versatz zwischen Auslesen und Berechnung des PID20.
Ich wäre für Hilfe sehr dankbar!
-Michael
Hallo Michael,
das sind eine Menge Themen, die du ansprichst.
1. SignaturEs ist sehr hilfreich, wenn du deine FHEM Konstellation in der Signatur deines Profils vermerkst, da man dann schon viele grundlegend Informationen hat.
2. Schnelle RegelvorgängeEin Max-Thermostat ist für schnelle Regelvorgänge unbrauchbar. Eine Stellbefehlsausgabe verbrät ca. 150 Credits.
Wenn du alle 2.5 Minuten einen Stellbefehl loslässt, bleibt für alle anderen Max-Devices nichts mehr übrig.
Ein pidcalcinterval mit 60 und der Wunsch Änderungen binnen einer Minute zu regeln widersprechen sich, da kommt es zu den
Effekten, wie du sie beschreibst.
3. UnklarheitenZitatzudem gibt es immer wieder starke Ausschläge (z.B. wenn einer der angeschlossenen FBH-Heizkreise zu macht).
Wieso hat das Schliessen eines Verbrauchers unmittelbar eine Rückwirkung auf den Vorlauf ?
Kannst du die Elemente deines Heizsystem genauer erklären (Mischer, wie wird die Temperatur in den einzelnen Räumen geregelt ...)
4. AntwortenZitat2. Sensor immer bei Neuberechnung auslesen
Dies ist nicht unbedingt direkt PID20-bezogen, aber vielleicht könnt ihr mir ja trotzdem helfen: wie kann ich sicherstellen, dass der PID-Regler, immer direkt vor der Berechnung den Sensor ausliest? Ich habe einen DS18B20 Temperatursensor, bei dem das PollingInterval aktuell auf 30 Sek. gesetzt ist. Das macht aber die Log-Files ganz schön zu und außerdem gibt es immer etwas Versatz zwischen Auslesen und Berechnung des PID20.
Du kannst das PollingInterval verkürzen und die Attribute event-on-change-reading (nur Änderungen > xy Grad werden aufgezeichnet)
und event-min-interval (spätestens nach dieser Zeit erfogt eine Zwangsaufzeichnung) verwenden.
Damit hast du stets aktuelle Werte ohne die Logfiles zu überfrachten.
John
Hallo John,
danke für die schnelle Antwort - eine Signatur habe ich direkt angelegt. Man möge mir das Fehlen nachsehen, das war mein erstes Posting hier ;)
Zu deinen Punkten: das mit den Credits war mir bewusst, ich habe aber aktuell keine größeren Pläne auf dem 886-Band. Letztendlich hat sich aber sowohl dieser als auch die anderen Punkte erledigt. Ich habe nämlich durch weiteres Experimentieren festgestellt, dass der Vorlauf doch träger reagiert, als ich aufgrund der Plots gedacht hatte. Ich bin daher komplett auf einen PI-Regler umgestiegen, den D-Anteil habe ich auf 0 gesetzt. Nur interessant, dass ich vorher trotzdem ein relativ stabiles Regelverhalten hinbekommen hatte :-)
Zu deinen Fragen: ich habe vier Heizkreise und die Steuerung der Vorlauftemperatur dieser Heizkreise (d.h. Beimischung des heißen Kesselwassers zum kalten Rücklaufwasser der FBH) wird bisher gesteuert über eine normalen (nicht-digitalen) Thermostatkopf mit Tauchfühler im Vorlauf. Anders ausgedrückt: es wird quasi das ganz (Heiz-)Jahr ca. 38° Vorlauf gefahren, da man jedesmal in den Keller und am Thermostatkopf drehen müsste, um die Vorlauftemperatur anzupassen. Das habe ich umgebaut, in dem der Tauchfühler durch einen DS18B20-Sensor ersetzt und das MAX-Thermostat den alten Thermostatkopf ersetzt. Ferne messe ich die Außentemperatur und kann so das Ganze auf eine außentemperaturgesteuerte Vorlauftemperatur umbauen. Größere Ausschläge gibt es hierbei immer, wenn der Kessel heizt (Temperatur des Kesselwasser steigt erheblich) oder wenn einer der Heizkreise auf-/zumacht (mehr/weniger warmes Wasser aus Kesselvorlauf benötigt).
Viele Grüße,
Michael
Moin Micael,
Ich habe hier einen ähnlichen Aufbau (hänge allerdings an der Fernwärme mit 60° - 80° Vorlauf).
Kann Dir aber trotzdem einige Erfahrungswerte mitteilen (bin allerdings noch beim Justieren).
- geringster pidActorInterval bei dem MAX noch zuverlässig arbeitet sind 84 Sekunden
- maximale Stellbefehle die MAX in der Stunde vekraftet sind 34
- p_D ist richtig eingestellt nötig, da der Kreis sonst im unteren Bereich das Schwingen bekommt
- der Vorlaufregler muss einen eigenen CUL/Cube bekommen, wenn man legal bleiben will
- pidActorInterval, pidCalcInterval und pidUpdateInterval sollten identisch sein, sonst kommt es zu den von Dir beschriebenen Problem mit dem p_d Anteil
- 1Wire Abfrage, wie von John geschrieben event-min-intervall, event-on-update mit Schwellwert , ggf. das attr onkick, dann sind sehr kurze Abfragezyklen möglich
in der Anlage mal der Plot von heute.
Gruß Joachim
kurze Frage:
wie verwendet man das <actor:cmd > in
define <name> PID20 <sensor[:reading[:regexp]]> <actor:cmd >
wenn man kein set ausführen will, sondern ein setreading auf ein dummy?
Ich habe ein Problem mit pidDesiredName
Nach der Definition sollte doch durch ein Reading die dort eingestellte Temperatur in PID übernommen werden. Ich wollte die Measured und Desired Temperatur von einem HM- Wandtermostat nehmen.
bei der Definition klappt es auch mit BadThermostat:measured-temp, wenn ich aber
bei Attr pidDesiredName Bad Thermostat:desired-temp eingebe bekomme ich ein Alarm missing desired
Zitat von: Paul am 21 April 2015, 17:35:13
Ich habe ein Problem mit pidDesiredName
Nach der Definition sollte doch durch ein Reading die dort eingestellte Temperatur in PID übernommen werden. Ich wollte die Measured und Desired Temperatur von einem HM- Wandtermostat nehmen.
bei der Definition klappt es auch mit BadThermostat:measured-temp, wenn ich aber
bei Attr pidDesiredName Bad Thermostat:desired-temp eingebe bekomme ich ein Alarm missing desired
Mit pidDesiredName legt man den Namen des Readings "desired" fest, wenn man es anders nennen möchte.
Du kannst um die Temperatur vom Thermostaten zu benutzen mit einen Notify die desired-temp nach desired schreiben.
Ich habe heute Nacht einen kleinen Fehler gehabt.
Der Wert von "actuationCalc" wurde falsch gesetzt. Es wurde das "e" im Rechenwert entfernt.
Dadurch kommt es zu Fehlermeldungen in Fhem und später im SVG.
fhemlog
2015.04.27 04:28:56 1: PERL WARNING: Argument "-7.82398290858424-05" isn't numeric in subtraction (-) at fhem.pl line 3769.
2015.04.27 04:28:56 1: PERL WARNING: Argument "-7.82398290858424-05" isn't numeric in sprintf at ./FHEM/33_readingsGroup.pm line 1034.
SVG Aufruf
2015.04.27 17:45:32 1: PERL WARNING: Argument "-7.82398290858424-05" isn't numeric in multiplication (*) at (eval 380184) line 1.
DBLOG Auszug
2015-04-27 04:28:57: HZ_PI_TH_VL, PID20, actuationCalc: -7.82398290858424-05, actuationCalc, -7.82398290858424-05,
Bitte folgendes zu weiteren Fehleranalyse:
pidDebugCalc auf 1 setzen.
verbose mindestens auf 2 setzen.
Wenn der Fehler nochmals passiert, brauche ich die entsprechenden log-Auszüge.
John
Es liegt nicht am PID20 es ist ein event-on-change Problem.
Ich denke, das da einen Fehler in die PID20 Module anwesend ist.
Ich arbeite mit MAX-thermostaten die ich mit fhem steuere. Ich benutze die MAX Temperatur-scanner von John und das Wochenprofil habe ich angelegt mit das UtilMaxProf von Risiko.
Nun wollte ich das PID20 Programm von John brauchen um die überschwingung bei Änderung von die Temperatur zu minimalisieren. Ich habe dazu das folgende define gemacht:
define PID_Badkamer PID20 MAX_CV_Badkamer:temperature MAX_CV_maxValveSetting
Gebe ich nun hinter "set" PID_Badkamer desired eine Temperur ein, dann arbeitet der PIDregler wie gewünst.
Stelle ich das
attr PID_Badkamer pidDesiredName ein auf MAX_CV_Badkamer, um eine Temperatur aus das Wochen profiel ein zu lesen, geht es falsch. Ich bekomme die Fehlermeldung: alarm – missing desired.
Hinter "set" PID_Badkamer bekomme ich im das Auswahlfenster: MAX_CV_Badkamer und im das Eingabefenster desiredTemperature. Ich hatte erwartet, das im Auswahlfenster MAX_CV_Badkamer:desiredTemperature war erschienen und im Eingabefenster die Temperatur als Zahl aus das Wochen profiel.
Auch hatte ich erwartet das in die Readings desired war geändert im MAX_CV_Badkamer:desiredTemperture und das dabei die Temperatur aus das Wochen Profiel wurde gezeicht, wie bei MAX_Badkamer:temperature für die gemessene Temperatur.
Ich habe längere Zeit gesucht in die Programmlistung van PID20.PM und ich denke das rund die Zeilen beginnend bei Zeihlenummer 300 etwas schief geht. Ich denke, das die Variablen $a[1] und $a[2] nicht richtig umgesetzt werden, aber meine Kenntnisse von Perl ist beinahe nichts.
Vielleicht wollte John noch einmal einen Blick auf das Problem werfen.
Grüss Sibbe
Möchte diese Frage nochmals vorholen, da ich vor der gleichen Situation stehe/stand...
Habe es jetzt mal interimistisch via meiner 99_myUtils gelöst, aber schöner wäre es wenn es gleich richtig aus der PID Instanz heraus gemacht werden würde.
Zitat von: hanske am 21 April 2015, 10:51:47
kurze Frage:
wie verwendet man das <actor:cmd > in
define <name> PID20 <sensor[:reading[:regexp]]> <actor:cmd >
wenn man kein set ausführen will, sondern ein setreading auf ein dummy?
In meinen Dummy habe ich die Readings mit readingList definiert, dann geht auch set.
define pid PID20 dummy:pid_mes dummy:pid_state
Gesendet von meinem GT-I9295
yupp, danke. An setList habe ich nicht gedacht.
Hi, ich habe das Modul gerade mal für meine Heizungssteuerung mit Selbstgebauten Temperatursensoren (MQTT WLAN) testweise in Betrieb genommen.
Läuft alles auch soweit.
Ich wollte mir jetzt als webcmd ein paar feste Temperaturen anlegen, damit ich die Desired-Temp nicht immer per Hand eintippen muss. Allerdings fehlt ein "setlist" als Attribut und ich weisss nicht, wie ich sonst ein Dropdownmenu als webcmd realisieren kann. Der einzige umweg wäre ein dummy-gerät, aber ich hätte es lieber direkt im device. Vielleicht hat einer von euch eine idee!
Benutze das Attribut widgetOverride und erstelle deine Liste: desired:18,19,20,21,22
ah cool, danke! ;)
Lässt sich mit dem PID Modul auch ein 3-Wege Mischer der nur Richtung auf/zu oder Stop kennt regeln?
Zitat von: John am 26 Januar 2015, 09:48:09
Zu den vielfältigen Wünschen der letzten Einträge zum Thema Stellausgabe:
Ich schlage eine Callback-Funktion vor, in der der Anwender seine spezifische Implementierung für
die Wertvorgabe zum Stellwert realisieren kann.
Diese Methode würde immer unmittelbar vor der Ausgabe eines Stellwertes ausgeführt werden.
Damit könnte man alle beliebig exotischen Regeln implementieren ohne das Basis-Modul zu überfrachten.
John
Gibt es dazu schon konkrete Ideen?
Ich habe aktuell 2 Probleme:
1. Bei mir ist der Regelwert invertiert: 100 heißt geschlossen, 0 offen. Habe das im Moment über ein Notify gelöst, wäre aber anders schöner. pidReverseAction invertiert ja nicht actuation, sondern "nur" die Berechnung.
2. Bei mir soll von 78 gleich auf 100 gesprungen werden, weil hier beim Ventilstellung keine Änderung mehr passiert.
Zitat1. Bei mir ist der Regelwert invertiert: 100 heißt geschlossen, 0 offen. Habe das im Moment über ein Notify gelöst, wäre aber anders schöner. pidReverseAction invertiert ja nicht actuation, sondern "nur" die Berechnung.
Aber genau das ist doch die Zielrichtung von pidReverseAction. Das Ergebnis ist ein invertierter Stellausgang.
Zitat2. Bei mir soll von 78 gleich auf 100 gesprungen werden, weil hier beim Ventilstellung keine Änderung mehr passiert.
pidActorLimitUpper ist für solche Fälle vorgesehen, der Stellausgang wird nach oben begrenzt und beeinflusst auch Anti-Windup.
John
Zitat von: John am 07 Januar 2016, 11:10:08
pidActorLimitUpper ist für solche Fälle vorgesehen, der Stellausgang wird nach oben begrenzt und beeinflusst auch Anti-Windup.
Aber ich benötige auch den Wert 100, nur nichts zwischen <78 und <100. 78 ist praktisch der letzte Stellwert. Zwischendrin wird kein Wert akzeptiert, und 100 um ganz zu schließen.
Wenn ich pidActorLimitUpper auf 78 stelle, schließt das Ventil nie ganz (mit 100), oder hab ich das falsch verstanden?
@ JoeALLb
ich hab dein Problem verstanden und die schon angekündigte Callback Funktion eingefügt.
Anbei das überarbeitete Modul.
Hier findet sich das neue Attribut pidActorCallBeforeSetting.
ich habe in 99_Utils.pm folgende Sub definiert:
# 1. Parameter = Name des PID
# 2. Parameter = actuator value
sub PIDActorSet($$)
{
my ( $name, $actValue ) = @_;
return $actValue+1;
}
und das Attribut wie folgt gesetzt:
Zitat
attr PID.Test pidActorCallBeforeSetting PIDActorSet
Diese Sub wird immer genau vor dem Setzen des Aktors aufgerufen und Muss den auszugebenden Stellwert zurückliefern.
Bitte um Feedback.
John
Danke vielmals. Kann es aber erst nächste Woche testen, wenn ich wieder vor Ort bin...
noch eine Frage: Wie berücksichtigt ihr extrem schwankende Vorlauftemperaturen? Meiner ist in einem Heizkreis manchmal nur 25 grad, manchmal aber auch 50. Das beeinflusst den Temperaturanstieg im Raum enorm. ich stelle mir vor, dass bei 50 grad das Ventil weniger öffnen sollte als bei 25 grad.... Und das bei 25 die Desired Temp von 27 gar nie erreicht werden kann.....
Hat jemanden dazu eine Theorie?
ich weiß nicht ob dir das hilft:
hier
http://forum.fhem.de/index.php/topic,31586.msg258336.html#msg258336 (http://forum.fhem.de/index.php/topic,31586.msg258336.html#msg258336)
habe ich beschrieben, wie ich die überhöhte Vorlauftemperatur in ihrer Wirkung kompensire, nämlich über eine pulsierende Pumpe
(5 Minuten EIN 10 Minuten aus , ab R-TempL von 30 Grad) gesteuert über die LOGO.
Meine MAX-Thermostate nehmen seitdem die Schwankungen der VL-Temperatur nicht mehr übel.
John
Zitat von: JoeALLb am 09 Januar 2016, 17:18:09
noch eine Frage: Wie berücksichtigt ihr extrem schwankende Vorlauftemperaturen? Meiner ist in einem Heizkreis manchmal nur 25 grad, manchmal aber auch 50. Das beeinflusst den Temperaturanstieg im Raum enorm. ich stelle mir vor, dass bei 50 grad das Ventil weniger öffnen sollte als bei 25 grad.... Und das bei 25 die Desired Temp von 27 gar nie erreicht werden kann.....
Hat jemanden dazu eine Theorie?
Ich rechne die Vorlauftemperatur als Offset in den Ausgang des PID-Reglers rein, quasi als nachgeschalteter P-Regler.
Damit kann ich die Schwankungen in der Vorlauftemperatur ganz gut kompensieren.
Gruß,
Gero
Zitat von: John am 08 Januar 2016, 13:38:07
Hier findet sich das neue Attribut pidActorCallBeforeSetting.
Diese Sub wird immer genau vor dem Setzen des Aktors aufgerufen und Muss den auszugebenden Stellwert zurückliefern.
Bitte um Feedback.
John
Hallo John,
vielen Dank. Sorry, dass es gedauert hat, ich hatte nach einem Update abstürze im fhem, die kamen aber von einem anderen Modul.
Es scheint perfekt zu funktionieren, und ist mir wirklich eine große Hilfe!
@gero danke auch für den Tip, ich werd dies gleich mit der neuen Möglichkeit hier mit umsetzen!
Zur Info an alle: Ich nutze im Bad das Rollo zur Lüftungssteuerung und habe hier jetzt experimental auch mal dieses Modul mit einem hohen pidFactor_P zur Steuerung der Rolladen-Öffnung eingesetzt.
Scheint ebenfalls sehr gut zu funktionieren, mir ist lediglich aufgefallen, dass das Modul einen Stop oder Restart-Befehl oft lange nicht anzeigt. Hängt dies mit dem pidActorInterval zusammen?
Prinzipiell fände ich es schöner, wenn der state sofort auf Stop wechselt, da ich am tablet sonst einfach nicht weiß, ob ich vielleicht nur daneben gedrückt habe...
@JoeAllb
Zitat
mir ist lediglich aufgefallen, dass das Modul einen Stop oder Restart-Befehl oft lange nicht anzeigt
Hab das bereinigt und eingecheckt. (V 1.0.0.8)
John
Danke, funktioniert bestens!!!
Was mir noch aufgefallen ist: Wenn ich ein FHEM-Restart mache (nach einem Update, etc...), startet das Modul nicht im Modus von zuvor, es startet immer als gestarted.
Das mag bei einer Heizung nach einem Ausfall sinn machen, nach so kurzen Ausfällen wie einem Restart ist das bei mir eher problematisch.
Kann das in einem nächsten Update auch noch einfließen, oder soll ich mir die Stati in dummies wegsichern und diese beim Neustart zurückspielen?
Hallo
gibt es eine Möglichkeit den internen Rechenwerte p_i zu resetten - spricht auf Null zu setzen?
Setze ich pidFactor_I = 0 dann bleibt p_i auf dem zuletzt berechneten Wert stehen.
Ein Restart setzt die internen Rechenwerte auch nicht auf Null.
Bei meinen Einstellversuchen läuft p_i ab und zu aus dem Ruder und dann würde ich gerne
einen neuen Versuch starten. Deshalb meine Frage.
Gruß Martin
Noch was, was mir aufgefallen ist: set pid20 restart 75 setzt den Aktor nicht wie erwartet zuerst auf 75, sondern direkt auf 0.
Ich verwende zwar "pidActorCallBeforeSetting PIDActorSet",
aber dieser Code sollte dran nicht schuld sein.
# 1. Parameter = Name des PID
# 2. Parameter = actuator value
sub PIDActorSet($$)
{
my ( $name, $actValue ) = @_;
if( $actValue<6 ) {
return 0;
}
elsif($actValue > 90 ) {
return 100;
}
else {
return $actValue -3;
}
}
Diese Werte zeigen an, was das Modul auch gemacht hat.
Habe ich die Restart-Funktion falsch verstanden?
actuation=0
actuationCalc= -873.39509287767
@alpine310
Zitatgibt es eine Möglichkeit den internen Rechenwerte p_i zu resetten - spricht auf Null zu setzen?
Setze ich pidFactor_I = 0 dann bleibt p_i auf dem zuletzt berechneten Wert stehen.
Ein Restart setzt die internen Rechenwerte auch nicht auf Null.
man kann den I-Anteil (p_i) auf 0 setzen durch folgende Maßnahmen
set <dein Pid> restart <p_p + p_d>
Danach wird p_i 0 sein.
John
Danke, hat funktioniert
Martin
Hier ein interessanter Vortrag über die Auslegung von PI-Reglern für die Steuerung einer Heizung:
https://www.youtube.com/watch?v=quqxyny5kBU (https://www.youtube.com/watch?v=quqxyny5kBU)
Natürlich macht er ein paar Vereinfachungen (z.B. "regelt" er die Vorlauftemperatur anstatt der Ventilöffnung) und ein paar Dinge fallen auch einfach vom Himmel (Zeitkonstanten sowie Totzeit), trotzdem eine wirklich gute Methode, den Regler zu veranschaulichen.
Seine Methode der Auslegung der Regelung mag auch extrem schnell sein, aber die starken Überschwinger nimmt wohl kaum einer hin, dann lieber eine etwas langsamere Regelung. Die ermittelten Parameter kann man aber danach ja hiermit weiter verbessern: https://de.wikipedia.org/wiki/Faustformelverfahren_(Automatisierungstechnik)#Empirische_Dimensionierung
//EDIT: Ach ja, die Möglichkeit, einen Arbeitspunkt einzustellen, wäre für den PID20 vielleicht auch ganz nett. Und sollte mit sehr wenig Aufwand möglich sein (nur ein konfigurierbarer Offset, der einfach draufgerechnet wird)
Und was ebenfalls noch interessant wäre: Konfigurierbarer WindUp für den I-Anteil. Folgender Fall: Die Vorlauftemperatur reicht einfach nicht aus, um die gewünschte Temperatur zu erreichen. Man kommt vielleicht nah dran, aber nicht drüber. Der P-Anteil regelt konstant seinen festen Wert, der vielleicht schon sehr gering ist, da man nah an der gewünschten Temperatur ist. Der I-Anteil steigt aber langsam und stetig, bis das Ventil in Summe zu 100% geöffnet ist. Die Temperatur steigt trotzdem nicht weiter. Irgendwann will man wieder eine geringere Temperatur haben. Der immer noch sehr hohe I-Anteil sorgt nun dafür, dass man über Stunden oder vielleicht Tage immer eine zu hohe Temperatur bekommt, bis der I-Anteil wieder ausreichend gesunken ist.
Ideen wären:
- Begrenzung des I-Anteils auf fest eingstellten Wert (z.B. max. 30%)
- schlaue Erkennung, dass Temperatur z.B. über 30min keine Veränderung gemacht hat (trotz positiver Regelabweichung), obwohl der I-Anteil bzw. die gesamte Ventilöffnung gestiegen ist -> I-Anteil einfrieren
- schlaue Erkennung, dass Temperatur z.B. über 30min schon die maximale Steigung erreicht hat (bei positiver Regelabweichung) (z.B. 2° pro Stunde) -> I-Anteil einfrieren, bringt dann auch keine Steigerung
- und eventuell nochmal Gedanken machen, ob man irgendwas davon auch bei negativer Regelabweichung betrachten möchte
Hallo
den Wunsch nach einer Begrenzung des I-Anteil (nach unten sowie auch nach oben) unterstütze ich auch.
Ich verwende den PID20 zur Beeinflußung der Vorlauftemperatur meiner Heizung. Als Eingangsgröße verwende ich die durchschnittliche Ventilstellung meiner Heizkörperthermostate. Die Antwortzeiten sind hier prinzipbedingt sehr langsam. Wähle ich den I-Faktor sehr klein, dann läuft der I-Anteil währen der Nachtabsenkung an die untere Grenze. Bei der Umschaltung auf Tagbetrieb dauert es ewig bis der I-Anteil wieder nach oben gelaufen ist. Wähle ich den I-Faktor größer (für eine schnellere Reaktion) dann beginnt die Regelung zu schwingen.
Eine Begrenzung des I-Anteils wäre hier genau das richtige.
Martin
@tobby, @alpine310
Anbei das überarbeitete Modul.
Hier findet sich das neue Attribut pidIPortionCallBeforeSetting.
ich habe in 99_Utils.pm folgende Sub definiert:
# 1. Parameter = Name des PID
# 2. Parameter = i-portion value
sub PIDIPortionSet($$)
{
my ( $name, $iPortion ) = @_;
return $iPortion;
}
und das Attribut wie folgt gesetzt:
Zitat
attr PID.TEST pidIPortionCallBeforeSetting PIDIPortionSet
Diese sub wird vor der Berechnung von actuationCalc aufgerufen.
Bitte um Feedback. Wenn alles klappt checke ich die Änderungen ein.
John
Hallo John
habe ich das richtig verstanden, daß die Korrektur
des I-Anteils in der sub PIDIPortionSet erfolgen soll,
damit jeder das dann nach seinem eigenen Gusto
implementieren kann?
Martin
genau so
John
Hallo John
Hab das ganze mit einer einfachen Begrenzung nach oben und unten
bei mir umgesetzt und es funktioniert einwandfrei.
Martin
Ich kann zwar programmieren, aber leider überhaupt kein Perl. Magst du uns deine Umsetzung hier mal posten?
Hallo tobby
Angelegt habe ich das ganze wie oben von John beschrieben und die
sub PIDIPortionSet folgendermaßen ergänzt:
sub PIDIPortionSet ($$)
{
my ( $name, $iPortion ) =@_;
Log 1, 'PIDPortion Eingangswert: '.$iPortion; #zum debuggen ins Log schreiben
if ( $iPortion > 250 ) { $iPortion = 250}; #auf 250 nach oben begrenzen
if ( $iPortion < -250 ) { $iPortion = -250}; #auf -250 nach unten begrenzen
Log 1, 'PIDPortion Ausgangswert: '.$iPortion; #geänderter Wert zum debuggen ins Log schreiben
return $iPortion;
}
Martin
P.S.: Ich habe bis jetzt auch noch nie in Perl programmiert. Irgendwann muß
man halt mal mit anfangen :) ... hab extra deswegen ein Perl-Buch gekauft ;D
Moin Moin,
ich habe auch bei mir einen PID mit folgenden Einstellungen definiert:
CFGFN
CHANGED
DEF Temp.AZ:temperature Poti:value
NAME Heizg_AZ
NR 138
NTFY_ORDER 50-Heizg_AZ
STATE idle
TYPE PID20
VERSION 1.0.0.9
Readings:
2016-02-11 19:48:28 delta 2.4375
2016-02-11 19:48:28 desired 25
2016-02-11 19:48:28 measured 22.5625
2016-02-11 19:48:28 p_i 0
2016-02-11 19:48:28 state idle
Helper:
actor Poti
actorCommand value
actorErrorAction freeze
actorErrorPos 0
actorInterval 180
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 4
actorValueDecPlaces 1
adjust 25
calcInterval 60
deltaGradient 0
deltaOld 2.4375
deltaOldTS 2016-02-11 19:49:04
deltaTreshold 5
desiredName desired
disable 0
factor_D 0
factor_I 0.2
factor_P 50
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor Temp.AZ
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
event-min-interval .*:1800
event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0
pidActorErrorPos 0
pidActorInterval 180
pidActorKeepAlive 1800
pidActorLimitLower 0
pidActorLimitUpper 100
pidActorTreshold 4
pidActorValueDecPlaces 1
pidDeltaTreshold 5
pidFactor_I 0.2
pidFactor_P 50
room Heizung
verbose 5
Die Einstellungen habe ich mir erstmal aus Thread und commandref zusammenkopiert, um starten zu können. Ich hatte keine Fehlermeldungen, schien alles ok zu sein. Aber nun komme ich über einen entscheidenden Punkt nicht hinaus, der STATE ist "idle" und ändert sich nicht. Ich habe offenbar was Grundlegendes übersehen...kann mir jemand auf die Sprünge helfen?
Danke und Gruß
Uwe
pidDeltaTreshold 5
mach das mal auf 0.
http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler (http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler)
Der Pid Regler geht erst in prozessing, wenn diff zwischen desired und measured größer 5 ist,weil Du das so eingestellt hast:
ZitatdeltaTreshold 5
Gruß Joachim
Mist, Frank war schneller >:(
Ich sach ja, was Grundlegendes übersehen *verschämtindieeckeduck*
Vielen Dank und einen schönen Abend (meiner ist gerettet...) ;)
Gruß
Uwe
Hallo zusammen,
nachdem meine Installation mittlerweile ganz zufriedenstellend läuft, bin ich beim Feintuning.
Die PID20 regeln sehr schön, ich möchte lediglich, daß sie bei einer Änderung der Solltemperatur sofort reagieren, also stellen.
Um nicht vom "Sägen" der fht8v genervt zu werden, habe ich
pidActorInterval=1800
pidActorTreshold=5
eingestellt. Im Regelbertrieb funktioniert das auch gut. Lediglich der Start morgens reagiert etwas verzögert auf die geänderte Wunschtemperatur, wie man im SVG-Plot ganz gut erkennt.
Wenn ich alles richtig verstanden habe, kann ich das mit den div. T(h)reshold-Werten nicht verändern - oder? Was müßte ich tun, damit der Stellantrieb sofort bewegt wird, wenn ich "desired" anpasse?
Anbei SVG und list PID20
Gruß, Bernd
pidActorInterval uint 180 minimale Wartezeit in Sekunden, bis eine neue Ausgabe an das Stellglied erfolgen kann
ich arbeite bei mir mit 0s. somit wird nach jeder berechnung (60s), wenn zusätzlich auch pidActorTreshold erreicht ist, ein neuer wert zum aktor gesendet. du hast mindestens eine halbe stunde wartezeit zwischen 2 stellbefehlen.
@ frank,
Veto!
Zitatich arbeite bei mir mit 0s
das ist so z.B. bei MAX und weiteren Geräten, die der 1% Regel unterliegen fatal.
Sinnvoller ist, das Zusammenspiel aller möglichen Parameter, die im Wiki beschrieben sind.
pidActorInterval für eine "Zwangspause" nach einem erfolgten Stellbefehl. MAX kann nur 36 Stellbefehle in der Stunde, und andere Aktoren wollen auch noch bedient werden.
pidCalcInterval für die schnelle Reaktion, wenn die "Zwangspause" abgelaufen ist.
Gruß Joachim
ZitatVeto!
doppel-veto! ;)
bei der load (1%) kommt es ja noch auf weitere faktoren an.
mit 6 homematic-ventilen über pid20 angesteuert, komme ich lediglich auf knapp 10% (siehe grafik heute und am anfang), obwohl ich sogar noch pidActorTreshold=1 gesetzt habe. zusätzlich benötigen die ventile (hm-cc-vd) auch noch streicheleinheiten (mindestens alle 7,5 min bekommen sie ein keepalive), damit sie nicht einschlafen. der grundtakt wird bei mir quasi durch die measured-temp gegeben, die sich aber höchstens alle 2,5 min ändern kann. durch die trägheit der heizung eher weniger.
(http://forum.fhem.de/index.php?action=dlattach;topic=17067.0;attach=47220;image)
hier sieht man sehr schön, was es bedeutet, wenn ich pidActorTreshold=0 setze. dann wird jedes ventil alle 2,5 min angefunkt. in diesem fall wurde die load auf ca 20% verdoppelt. das hatte ich zufällig die letzten tage mal probiert.
du hast aber völlig recht, dass man die load immer im auge behalten sollte.
gruss frank
Frank,
Du solltest den load des Rechners, auf dem FHEM läuft nicht mit der 1% Regel gleichsetzen.
Bei HM weiß ich nicht wieviele Befehle von der Zentrale an die Teilnehmer abgesetzt werden können, bei MAX sind es nach meinem Kenntnissstand 36.
Gehen wir von 6 ventilen aus, bedeutet das, dass pro Ventil maximal alle 10 Minuten ein Stellbefehl abgesetzt werden darf, damit MAX die 1% Regel nicht überschreitet (1 Stunde = 60 Minuten --> 6 Befehle pro Thermostat * 6 Thermostate = 36 ! )
ZitatDu solltest den load des Rechners, auf dem FHEM läuft nicht mit der 1% Regel gleichsetzen.
joachim, das hat nichts mit der load des rechners zu tun.
hierbei handelt es sich um die aktuelle load (auslastung des erlaubten funkkontingentes), die der hmlan (ein interface-funk-modul von homematic) ca. alle 25 sekunden an fhem meldet. bei einer gemeldeten load von 10% stehen also noch 90% des erlaubten funkkontingentes zur verfügung. die 1%-regel erlaubt pro stunde 36 sekunden sendezeit. bei der ermittlung kommt es nicht nur auf die anzahl der messages an, sondern vor allem auch auf die länge der messages, da die sendedauer einer message entscheidend ist.
wie gesagt, werden im fall meiner load von 20% ca alle 2,5 minuten an alle 6 ventile folgende messages gefunkt:
2016.02.22 17:07:08.002 0: HMLAN_Send: hmlan1 S:S09BBFD33 stat: 00 t:00000000 d:01 r:09BBFD33 m:7C A258 B4B4B4 1CE9F5 0302
hier werden also ca 6 x 25 = 150 messages gesendet, die die 1%-regel zu 20% ausnutzen. demnach müsste eine dieser 11 byte langen message ca 36s x 0,2 / 150 sekunden lang sein. => 48 millisekunden.
gruss frank
Hi everyone!
I am trying to create a PID to manage a valve (Smartdrive mx EEP A5-20-04).
Anybody could explain me the correct attributes I have to use for the correct performance of this device. Also I would like to make a plot with this device and PID.
Thank you very much.
hi,
i think your pid works fine.
desired=10, measured=14.2 => actuation=0.00000 and state=processing.
but needs your valve all the blue zero's? i do not think so. you can adjust the places with the attribute pidActorValueDecPlaces.
your valve model i have never seen, so i can not say anything of correct function.
is the valve realy closed?
for fine adjustment of the pid-factors, you need the plots first. in the wiki is a brief explanation to plot some values.
http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler (http://www.fhemwiki.de/wiki/PID20_-_Der_PID-Regler)
Hallo,
Ich habe folgende Situation
Ich habe im Wohnzimmer 3 Heizkörper.
Diese haben alle ein max thermostat. Ist es möglich alle 3 gleichzeitigmit pid20 zu steuern?
Wenn ich jeden einzelnen mit pid20 regele wird die funklast zu hoch und die Credits reichen nicht aus.
Mfg
Hallo Shadow3561,
schau mal hier (https://forum.fhem.de/index.php/topic,16803.msg109953.html#msg109953). Da wird von einer "Raumlösung" gesprochen in der nur ein Thermostat die Regelgröße per Signal bekommt und dann alle weiteren Themrostaten im Raum über die Änderung "informiert".
Grüße Fritz
Danke, das Prinzip der Group-id war mir bereits bekannt.
Dieses hat jedoch nur Einfluss auf das Reading desiredTemperature.
Beim pid20 ist dieses jedoch immer auf on gestellt und es wird nur über MaxValvePosition geregelt. Hierauf hat die groupId leider keinen Einfluss.
Trotzdem danke für deine Mühe
Dann ist vielleicht das erhöhen von pidActorInterval des PID20 eine Option um die Funklast zu verringern.
Hab gerade noch eine Idee bzgl. Verringerung der Funklast. Den desired Wert vom PID20 in einen dummy schreiben und den Dummy Wert dann rollierend im sagen wir mal 10 Minuten Takt an jeweils einen MAX Thermostaten senden.
Zitat von: frank am 07 Juli 2016, 11:27:53
but needs your valve all the blue zero's?
Do you know
attr pidActorValueDecPlaces
??
Hat es schon jemand geschafft das Modul mit Tablet-Ui und dem Themostat Widget zum laufen zu bekommen?
Mfg
Zitat von: Shadow3561 am 02 Dezember 2016, 19:15:11
Hat es schon jemand geschafft das Modul mit Tablet-Ui und dem Themostat Widget zum laufen zu bekommen?
Mfg
Ja, ich! Wobei ich korrekter Weise sagen muss, das ich nicht das Thermostat Widget nutzte, sondern eine Kombination aus Spinner/Label und Symbol Widgets.
Kannst du evtl ein Screenshot einstellen oder den Quellcode?
Ich habe es jetzt mit dem Volume Widget und Label gemacht, mir gefällt es mit dem Thermostat Widget aber besser, da dort die aktuelle Temperatur direkt angezeigt wird .
Meins sieht aus wie im Screenshot.(Wohnzimmer und Bad mit Volume-Widget und PID20, Schlafzimmer mit Thermostat-Widget und MAX!) das Thermostat-Widget finde ich optisch schöner.
Mfg
Klar, gerne doch, komme aber erst morgen dazu. Bin gerade unterwegs!
@Shadow3561
<li data-row="1" data-col="6" data-sizex="4" data-sizey="3">
<header>Gast WC</header>
<div class="">
<div class="row" style="padding-top:7px;">
<div data-type="label" class="inline col-1-4">Raumtemp.
</div>
<div
class="inline col-1-4 big"
data-type="label"
data-device="EgThermpidBad"
data-get="measured"
data-unit="°">
</div>
<div data-type="symbol"
class="inline medium col-1-4"
data-device="EgSenTempBad"
data-get="battery"
data-get-on='["ok","low"]'
data-icons='["fa-battery-full fa-rotate-270","fa-battery-1 fa-rotate-270"]'
data-on-colors='["SeaGreen","IndianRed"]'>
</div>
</div>
<div class="row" style="padding-top:7px;">
<div data-type="label" class="inline col-1-4">Ventilpos.
</div>
<div
class="inline col-1-4 big"
data-type="label"
data-device="EgThermpidBad"
data-get="actuation"
data-unit="%">
</div>
<div data-type="symbol"
class="inline medium col-1-4"
data-device="EgAktVentilBad"
data-get="battery"
data-get-on='["ok","low"]'
data-icons='["fa-battery-full fa-rotate-270","fa-battery-1 fa-rotate-270"]'
data-on-colors='["SeaGreen","IndianRed"]'>
</div>
</div>
<div class="row" style="padding-top:7px;"">
<div data-type="label" class="inline col-1-4">Luftfeuchte
</div>
<div
class="inline col-1-4 big"
data-type="label"
data-device="EgSenTempBad"
data-get="humidity"
data-unit="%">
</div>
<div class="autohide top-space inline col-1-4">
</div>
</div>
</div>
<div>
<div data-type="spinner"
data-device="EgThermpidBad"
data-get="desired"
data-set="desired"
data-step="0.5"
data-min="10"
data-max="30"
data-unit="°"
class="top-space centered valueonly"
>
</div>
<div>
<div data-type="symbol" class="top-space inline col-1-4"
data-device="EgSenFkMxBad" data-get="onoff" data-get-on='["0","1"]'
data-on-colors='["SeaGreen","IndianRed"]'>
</div>
<div class="autohide top-space inline col-1-4">
</div>
<div class="autohide top-space inline col-1-4">
</div>
</div>
<div>
<div data-type="symbol" class="medium inline col-1-4"
data-device="EgSenFkMxBad" data-get="battery" data-get-on='["ok","low"]'
data-on-colors='["SeaGreen","IndianRed"]'
data-icons='["fa-battery-full","fa-battery-1"]'>
</div>
<div class="autohide top-space inline col-1-4">
</div>
<div class="autohide top-space inline col-1-4">
</div>
</div>
<div class="row top-space">
<div class="autohide top-space inline col-1-4">
</div>
<div class="autohide top-space inline col-1-4">
</div>
<div data-type="popup" data-width="800px" data-height="400px"
class="medium inline col-1-4">
<div class="medium inline col-1-4"
data-type="symbol"
data-icon="fa-line-chart">
</div>
<div class="dialog">
<header>Gast WC Raumtemperatur Luftfeuchte Ventilposition</font></header>
<div class="nobuttons"
data-type="chart"
data-device="myDblog"
data-logdevice='["myDbLog","myDbLog","myDbLog"]'
data-logfile='["HISTORY","HISTORY","HISTORY"]'
data-columnspec='["EgThermpidBad:actuation","EgSenTempBad:humidity","EgSenTempBad:temperature"]'
data-style='["ftui l2","ftui l6","ftui l3"]'
data-ptype='["lines","lines","lines"]'
data-uaxis='["primary","primary","secondary"]'
data-legend='["Ventilposition","Luftfeuchte","Raumtemperatur"]'
data-yunit="%"
data-yunit_sec="°C"
data-ytext="Luftfeuchte / Ventilposition"
data-ytext_sec="Raumtemperatur"
data-minvalue="0"
data-minvalue_sec="auto"
data-maxvalue_sec="auto"
data-maxvalue="100"
data-yticks="auto"
data-daysago="0"
data-caption="Temp."
data-height="350px"
data-width="700px"
data-showlegend="true">
</div>
</div>
</div>
</div>
Der Code ist leider etwas unsauber formatiert, aber vielleicht kannst Du ja trotzdem was brauchbares für Dich "rausziehen".
Grüße Fritz
Hallo zusammen,
ich habe seitdem ich mehrere PID-Regler verwende die Befürchtung, dass FHEM dadurch extrem langsam geworden ist.
Ich vermute, dass das Problem die Verschachtlung mehrerer PID-Regler und UserReadings ist, sodass unnötigerweise irgendwelche internen Notifys getriggert werden.
Von der Funktionsweise her habe ich es zur Erklärung so gemacht:
- An einem Heizkörper befinden sich zwei Temperatursensoren: zum Einen ein Heizkörpertemperatursensor und ein Raumtemperatursensor
- Beide DS18B20-Temperatur-Sensoren sind per 1-Wire an einem ESP8266 angeschlossen, der die ESPEasy-Firmware verwendet
- Auf dem FHEM-Host läuft das ESPEasy-Modul zum Empfangen der Daten
- Des Weiteren ist ein Thermoelektrisches Heizungsthermostat am ESP angeschlossen. Dieser steuert per Longpulse die Ventilposition (PWM ist nicht gut genug wegen des thermischen positiven Feedbacks)
- Zusätzlich sind Lüfter in den Heizkörper integriert um den Raum schneller auf Temperatur zu bekommen
- Insg. werden drei Regelschleifen verwendet:
- Raumtemperatur
- Heizkörperleistung
- Lüfterdrehzahl
- Die Raumtemperatur wird auf einen Sollwert geregelt (äußere Regelschleife). Dazu wird die Soll-Leistung des Heizkörpers gesteuert
- Die Heizleistung des Heizkörpers errechnet sich auf der Temperaturdifferenz zwischen Heizkörper und Raum multipliziert mit einem Faktor, der von der Lüfterdrehzahl abhängt und somit den Einfluss der natürlichen Konvektion und der erzwungenen Konvektion zusammenfasst
- Die Heizleistung des Heizkörpers wird über die Ventilposition geregelt
- Die Lüfterdrehzahl wird abhängig von der Heizkörpertemperatur und den Bedürfnissen der Bewohner geregelt
Wie man sieht sind da sehr viele verschachtelte PID-Schleifen und UserReadings vorhanden. Nachfolgend sind die wichtigsten Code-Abschnitte angefügt. Dabei verwende ich folgende Bezeichnungen:
- eth: Thermostat
- heat: Heizung
- room: Raum
- fan: Lüfter
- temp: Raumtemperatur
- power: Heizleistung des Heizkörpers
- powerCharged: Heizleistung des HEizkörpers, die vom Wärmemengenzähler gemessen wird
- forcedConvectionFactor: Angleichfaktor zur Berechnung der Heizleistung durch die Verwendung der Lüfter
Anmerkung: fan = 1000: aus, fan = 0: 100% an
define esp_wz_hz_temp_heat ESPEasy 192.168.***.*** 80 esp_bridge esp_wz_hz_temp_heat
attr esp_wz_hz_temp_heat IODev esp_bridge
attr esp_wz_hz_temp_heat Interval 60
attr esp_wz_hz_temp_heat eventMap /pwm 2:pwm_fan/pwm 3:pwm_eth/longpulse 3 1:longpulse_eth/gpio 4 on:on_sup/gpio 4 off:off_sup/gpio 5 on:on_fan/gpio 5 off:off_fan/
attr esp_wz_hz_temp_heat userReadings powerCharged:Temperature.* {return 0 if (ReadingsVal("$name","Temperature","0") < ReadingsVal("esp_wz_hz_temp_room","Temperature",0)+2);;;; return (ReadingsVal("$name","Temperature",0)-ReadingsVal("esp_wz_hz_temp_room","Temperature",0))*1400/30}, power:powerCharged.* {ReadingsVal("$name","powerCharged",0)*(ReadingsVal("$name","forcedConvectionFactor",0)+1)}, energy:power.* integral {ReadingsVal("$name","power",0)/3600/1000*(ReadingsVal("$name","forcedConvectionFactor",0)+1)}, energyCharged:powerCharged.* integral {ReadingsVal("$name","powerCharged",0)/3600/1000}, forcedConvectionFactor:powerCharged.* {(1-ReadingsVal("pid_wz_hz_fan","actuation",1000)/1000)*0.9}
define esp_wz_hz_temp_room ESPEasy 192.168.***.*** 80 esp_bridge esp_wz_hz_temp_room
attr esp_wz_hz_temp_room IODev esp_bridge
attr esp_wz_hz_temp_room Interval 60
attr esp_wz_hz_temp_room userReadings temperatureChange:Temperature.* differential { ReadingsVal("$name","Temperature",0)*60;; }
define pid_wz_hz_eth PID20 esp_wz_hz_temp_heat:power esp_wz_hz_temp_heat:longpulse_eth
attr pid_wz_hz_eth pidActorInterval 60
attr pid_wz_hz_eth pidActorKeepAlive 60
attr pid_wz_hz_eth pidActorLimitLower 0
attr pid_wz_hz_eth pidActorLimitUpper 59
attr pid_wz_hz_eth pidCalcInterval 60
define pid_wz_hz_fan PID20 esp_wz_hz_temp_heat:Temperature esp_wz_hz_temp_heat:pwm_fan
attr pid_wz_hz_fan pidActorInterval 15
attr pid_wz_hz_fan pidActorKeepAlive 15
attr pid_wz_hz_fan pidActorLimitLower 0
attr pid_wz_hz_fan pidActorLimitUpper 750
attr pid_wz_hz_fan pidCalcInterval 15
attr pid_wz_hz_fan verbose 5
define pid_wz_hz_temp PID20 esp_wz_hz_temp_room:Temperature pid_wz_hz_eth:desired
attr pid_wz_hz_temp pidActorInterval 60
attr pid_wz_hz_temp pidActorLimitLower -100
attr pid_wz_hz_temp pidActorLimitUpper 3000
attr pid_wz_hz_temp pidCalcInterval 60
Ich habe mal testweise das verbose-Level vom fan-pid hoch gedreht. Es kommen dann z.B. folgende Einträge im Event Monitor für ein 30-Sekunden-Fenster:
Zitat
2016.12.13 09:40:43 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:40:43 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:40:43 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:40:46 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:40:46 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:40:46 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:40:49 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:40:49 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:40:49 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:41:03 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:41:03 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:41:03 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:41:03 1 : Perfmon: possible freeze starting at 09:40:50, delay is 13.671
2016-12-13 09:41:04 PID20 pid_wz_hz_fan stopped
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_actuation: 0
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_p_p: -0.9456
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_p_i: 3.858
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_p_d: 0
2016.12.13 09:41:04 5 : PID20 pid_wz_hz_fan: RestartTimer.138 name:pid_wz_hz_fan seconds:1
2016.12.13 09:41:04 3 : PID20 pid_wz_hz_fan: Set.383 set pid_wz_hz_fan restart 750
2016-12-13 09:41:04 PID20 pid_wz_hz_fan restart 750
2016.12.13 09:41:04 5 : PID20 pid_wz_hz_fan: RestartTimer.138 name:pid_wz_hz_fan seconds:1
2016-12-13 09:41:04 PID20 pid_wz_hz_fan stop
2016-12-13 09:41:04 PID20 pid_wz_hz_fan actuation: 1000
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_actuation: 0
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_p_p: -0.9456
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_p_i: 3.858
2016-12-13 09:41:04 PID20 pid_wz_hz_fan voltage_p_d: 0
2016.12.13 09:41:04 4 : PID20 pid_wz_hz_fan: Notify.240 check 1 readings for Temperature
2016.12.13 09:41:04 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<off_fan>
2016.12.13 09:41:04 4 : PID20 pid_wz_hz_fan: Notify.240 check 1 readings for Temperature
2016.12.13 09:41:04 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<pwm_fan 1000>
2016.12.13 09:41:05 2 : sys_nanoCUL IT_set: it_kz_window off
2016.12.13 09:41:05 2 : sys_nanoCUL IT_set: it_kc_window off
2016.12.13 09:41:06 4 : PID20 pid_wz_hz_fan: Notify.240 check 1 readings for Temperature
2016.12.13 09:41:06 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<off_sup>
2016.12.13 09:41:06 1 : Perfmon: possible freeze starting at 09:41:04, delay is 2.505
2016-12-13 09:41:06 PID20 pid_wz_hz_fan stopped
2016-12-13 09:41:06 PID20 pid_wz_hz_fan voltage_actuation: 0
2016-12-13 09:41:06 PID20 pid_wz_hz_fan voltage_p_p: -0.9456
2016-12-13 09:41:06 PID20 pid_wz_hz_fan voltage_p_i: 3.858
2016-12-13 09:41:06 PID20 pid_wz_hz_fan voltage_p_d: 0
2016.12.13 09:41:06 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:41:06 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:41:06 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:41:09 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:41:09 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:41:09 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:41:12 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:41:12 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:41:12 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:41:15 4 : PID20 pid_wz_hz_fan: Notify.240 check 1 readings for Temperature
2016.12.13 09:41:15 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<longpulse_eth 0>
2016.12.13 09:41:29 4 : PID20 pid_wz_hz_fan: Notify.240 check 2 readings for Temperature
2016.12.13 09:41:29 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<presence: absent>
2016.12.13 09:41:29 5 : PID20 pid_wz_hz_fan: Notify.248 check event:<absent>
2016.12.13 09:41:29 1 : Perfmon: possible freeze starting at 09:41:16, delay is 13.319
Mir kommt es vor, als ob zu viele event checks durchgeführt werden. Kann man das irgendwie begrenzen? Bei den UserReadsings habe ich das schon versucht, so gut wie möglich zu machen. Aber trotzdem gibt es noch recht viele "possible freezes", die immer während der PID-Aktivität auftreten...
Zusatzinfo: Falls jemand ähnliche Probleme hat: Es hilft, die UserReadings nur auf bestimmte Events triggern zu lassen (siehe oben).
Edit: Meine Frage ist, wieso der auf die absent-Meldung vom Temperatursensor triggert und ob man dem PID20-Modul irgendwie sagen kann, dass der nur auf Änderungen des Temperature-Readings reagieren soll (weil es wird nur das absent-Reading im esp-device aktualisiert, nicht das Temperature-Reading)
ich würde erst einmal die events reduzieren => "attr <dev> event-on-change-reading .*"
dann muss pid20 nicht alle 3sec checken.
Hallo
Zitat von: frank am 14 Dezember 2016, 13:08:54
ich würde erst einmal die events reduzieren => "attr <dev> event-on-change-reading .*"
dann muss pid20 nicht alle 3sec checken.
Danke für die Antwort. Das habe ich jetzt gemacht. Ich meine, dass es recht viel gebracht hat. Ich habe aber parallel die Datenbank von MySQL auf SQLite umgestellt und arbeite jetzt mit dem log-Verzeichnis und der Datenbank auf einer zyklisch gesicherten RAM-Disk, da MySQL die SD-Karte durch zu viele Schreibzugriffe zerstört hat.
Trotzdem nochmal zurück zur Frage: Kann man den PID20-Regler nur auf den Sensor-Wert triggern lassen anstatt auf alle Events vom Sensor-Device?
Noch zwei weitere Fragne (ggf. sogar Feature Request):
Kann man das Modul seine calculations und das Setzen des Aktuators genau dann machen, wenn der Sensor-Wert geliefert wird (und vielleicht ein max-Interval für fehlende Sensoren)? Das würde bei mir die Regelschleife etwas schneller machen und die Anzahl der Berechnungen auf das nötigste Reduzieren. Es reicht ja normalerweise, wenn der Aktuator auf das reagiert, was der Sensor gerade gemessen hat. Zur Zeit muss ich etwa 2-4 Calculations bzw. Aktuator-Sets pro Sensor-Reading durchführen, damit die Verzögerung durch den PID-Regler nicht zu groß wird...
Könnte es eingestellt werden, dass der integrierende Anteil in einem definierten Bereich aus dem Aktuatorlimits heraus laufen darf? Das würde bei einer meiner Regelungen den Vorteil haben, dass die Langzeit-Abweichung geringer werden würde. Aktuell kann desshalb der Integrator in Fall einer "anti-windup-Begrenzung" den statischen Regelfehler nicht herausregeln...
Vielen Dank für eure Bemühungen und eure Rückmeldung ;)
Hallo ich habe da mal eine Frage, möchte Konstantlichtregelung mit Hilfe des Helligkeitssensors EnOcean-FBH65S und dem Dimmer Eltako-FUD61 realisieren, weiß allerdings nicht genau wie. Wäre das mit dem PID20-Modul möglich oder sollte man da besser auf if bzw. DOIF zurückgreifen?
Danke im Voraus
Zitat von: sunred am 02 Januar 2017, 21:20:26
Hallo ich habe da mal eine Frage, möchte Konstantlichtregelung mit Hilfe des Helligkeitssensors EnOcean-FBH65S und dem Dimmer Eltako-FUD61 realisieren, weiß allerdings nicht genau wie. Wäre das mit dem PID20-Modul möglich oder sollte man da besser auf if bzw. DOIF zurückgreifen?
Danke im Voraus
ich kenne deine hardware nicht, aber ich würde es einfach mal probieren.
das wiki kennst du?
Hi,
ich setze seit etwa einem Jahr das PID20-Modul ein, um mit einem 5-Wege-Mischer die Vorlauftemperatur meiner Fußbodenheizung zu regeln.
Nachdem ich erstmal die Grundlagen verstanden hatte, habe ich die Funktion immer weiter optimiert. Bin sehr zufrieden.
Vielen Dank für die viele Arbeit, die ganzen Features und Anpassungen, die du immer wieder vornimmst.
Ich habe heute ebenfalls ein paar Features zusammengetragen, die das Handling in meinem Fall erleichtern würden:
Erstmal ganz trivial ein Frontend-Feature:pidActorCallBeforeSetting und pidIPortionCallBeforeSetting als (ich glaube) text-Long formatieren (dann klappts mit dem Codemirror)
Das andere ist etwas komplexer, ich hoffe ich krieg das um diese Uhrzeit noch vernünftig rüber:
Momentan ist es so vorgesehen, dass PID den Stellwert direkt an das Device übergibt. Im Falle von HK-Stellmotoren auch absolut sinnvoll.
Ich hingegen muss (möchte) den Wert erst noch weiterverarbeiten, bevor mein Mischer irgendwas tut.
D.h. ich bräuchte einen (zusätzlichen) Dummy, ein zusätzliches notify, um eine Perl-Funktion zu triggern, die dann ihrerseits entscheidet, welches Relais wie lange anzieht (abhängig von z.B. Problemen, Sicherung gegen Übertemperatur, Unterdrückung von Schaltbefehlen, wenn die Pumpe eh nicht läuft usw).
Bis jetzt habe ich das so gelöst, dass ich ein notify auf actuation getriggert habe.
Damit ist der ActorInterval für mich nutzlos, aber einen dummy brauche ich trotzdem, da PID sonst meckert. <- blöde Idee ... 8) :P
Heute habe ich versucht, mit der pidActorCallBeforeSetting direkt meine Funktion aufzurufen - entweder funktioniert es nicht, oder ich hab nen Knoten im Hirn. (kann die Zeilen gerade nicht kopieren, ist auf einem Testsystem ohne Internet)
WUNSCH: kann man das Modul so erweitern, dass anstatt einem Device auch eine perl-Funktion aus der MyUtils aufgerufen werden kann?
Dann sind mir noch zwei Sachen aufgefallen:
Erstens: Das reading actuationCalc wird ja alle pidCalcInterval Sekunden neu berechnet und aktualisiert. Das reading actuation erzeugt dabei ebenfalls ein Event. Da der Wert von actuation aber nur geändert wird, wenn pidActorInterval Sekunden abgelaufen sind, bin ich der Meinung, es wäre sinnvoll, auch (nur) dann ein entsprechendes Event für dieses reading zu erzeugen.
Zweitens: event-min-interval.
Im Wiki (und auch mehrfach in diesem Thread) steht:
ZitatEvents feuern, wenn sich über lange Zeit ein Reading nicht ändert: wenn sich z.B. desired über Stunden nicht ändert, so wird kein einziger Event gefeuert. Mit nachfolgender Einstellung erreicht man, dass ein Event auch dann erzeugt wird, wenn sich das Reading nach einer festgelegten Zeit nicht ändert(sinnvoll für Charts, hier z.B. alle 30 Minuten)
Ich habe es gerade noch einmal probiert und muss hier leider protestieren:(Auszug aus der commandref)
event-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind.
Soll heissen: wenn event-min-interval auf 30 Sekunden gesetzt ist, und ActorInterval auf 120, ist event-min-Intervall sinnlos, da zwischen den Events generell mehr als 30 Sekunden vergehen (nämlich 120). Wenn allerdings ActorInterval auf 30 und event-min-interval auf 120 Sekunden stehen, wird auch nur alle 120 Sekunden ein Event erzeugt.
Falls die Wahrheit anders liegt, lasse ich mich gerne überzeugen - aber meine Tests bestätigen eigentlich die commandref ...
Viele Grüße
Stephan
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
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
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
Kann ich bestätigen, meines verliert die auch!
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.
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
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?
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?
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
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.
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
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
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
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
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
Hallo John,
super, vielen Dank für die Aufklärung! Ich werde im Winter mal monitoren, wie stark das von mir betreute Clubheim auskühlt, wenn die Therme nur im Frostmodus ist und zirkuliert, aber die Heizkörper "zu" bleiben. Vielleicht reicht ja die Heizleistung im Beton aus, um zumindest ein paar Tage über die Runden zu kommen und die Nachbarn zu alarmieren, notfalls die elektrischen Heizkörperthermostate ab- und die guten alten analogen Dinger wieder anzuschrauben.
Noch eine Frage, auf die ich hier im Thread gestoßen bin: Nachtabsenkung der Heizkreistemperatur.
Ich habe das sehr krass im Clubheim (#2 meiner Signatur) mit 1-2 Terminen pro Woche, in denen geheizt werden muss. Von Mitte Dezember bis Mitte Januar ist gar nichts los. Dort fahren wir die Therme im Frostschutzbetrieb (springt bei Vorlauf um die 5° an) mit den MAX-Thermostaten auf 5.5°. Wenn eine Veranstaltung ansteht, geht die Therme via HCS auf 75° im Vorlauf, damit wir den massiv ausgekühlten Raum schnell auf Temperatur bringen. Die Thermostate stehen dann auf 19.5°. Über HCS wird die Therme nach Erreichen der Zieltemperatur wieder abgeschaltet, die Hitze im Vorlauf hält ja aber noch ein wenig an und "heizt" weiter.
Klar, dass die MAX-interne Regelung damit komplett überfordert ist und von sich aus Schwankungen über +-2.5° um die Zieltemperatur produziert. Sie kann ja auch nicht wissen, dass zwischenzeitlich mal der Wärmelieferant Therme wieder ab- und bei Bedarf wieder zugeschaltet wird. Dummerweise kommen zwischendurch dann auch noch einige Personen in den Raum, die kräftig Wärme abstrahlen. Das MAX-System ist hier meiner Meinung nach viiiel zu träge, und reizt geradezu, die Zieltemperatur vor Ort händisch nachzuregeln. Das macht die Schwankung dann natürlich noch schlimmer.
Frage dazu also: wie verfahre ich mit der Kombination HCS / PID20? Habe vorne im Thread (https://forum.fhem.de/index.php/topic,17067.msg134945.html#msg134945 (https://forum.fhem.de/index.php/topic,17067.msg134945.html#msg134945) bzw. https://forum.fhem.de/index.php/topic,17067.msg121126.html#msg121126 (https://forum.fhem.de/index.php/topic,17067.msg121126.html#msg121126)) gelesen, dass sinnvollerweise in dem Fall PID bei Ist>Soll gestoppt werden soll. Macht hier als Stop-Temperaturwert genau der Zielwert fürs Ausschalten der Therme Sinn? Ab welchem Delta nach unten starte ich PID sinnvollerweise wieder?
Fraglich für mich auch die x Tage, in denen gar nichts passiert und nichts zu regeln ist (außer Frostschutz ggf.). Heute z.B. sind dort Ist bei 11°, Soll bei 6. Macht das Sinn, hier PID weiter laufen zu lassen, auch wenn ohnehin nichts zu regeln ist? "Versaue" ich mir damit auch den I-Anteil, wenn PID weiter läuft, oder besser: gelten die Aussagen für "Ist>Soll" auch bei so einer großen Soll/Ist-Differenz?
Bin leider kein Techniker und daher sehr unsicher in meinen Überlegungen... daher nochmal herzlichen Dank für unterstützende Gedanken!
Jan
@Jho
Den Frostschutz zu gewährleisten ist die eine Sache, aber es gilt auch die Feuchte im Gebäude im Griff zu behalten.
Wenn die relative Feuchte zu hoch ist (>70%) besteht die Gefahr von Schimmelbildung an den kältesten Stellen des Gebäudes.
Auch das kann man mit ausreichender Raumtemperatur beeinflussen.
Die Max-Thermostate halte ich für deinen Anwendungsfall nur bedingt für geeignet. Diese haben einen adaptiven (selbst-lernenden) Algorithmus, der sich über Tage hinweg ausbildet.
Vielleicht gibt es die Möglichkeit die Temperatur im Versammlungsraum als Führungsgröße (Istwert für die Regelung) für deine Therme zu verwenden. Einige Heizungsregelungen unterstützten diesen Modus. Dazu müsste ein kompatibler Themeraturfühler in dem Raum installiert sein, der direkt an die Steuerung deiner Therme angeschlossen ist.
Die Aufheizphase sollte nicht zu kurz bemessen sein, da sich sonst sehr viel Wärmeengergie in kurzer Zeit im System befindet, was regelungstechnisch nicht einfach zu handhaben ist.
Ein anderer Ansatz:
* du verwendest PID20 für die Präsenz-Zeiten, hierbei ist das MAX-Ventil das Stellglied (Sollwert auf 30 Grad, PID beeinflusst maxValveSetting)
* du vewendest MAX im Normal-Modus (hier greift die Max-Reglung) für die Absenz-Zeiten und gewährleistet damit die Mindest-Raumtemperatur um Schimmelbildung und Frost zu verhindern
Wie steuerst du deine Therme an ? nur per EIN/AUS oder kannst du den Sollwert vorgeben ?
John
Hallo John,
nochmal Danke. Schimmel... ja. Jein. Das Gebäude ist in den 60ern selbst gebaut worden und bis auf ganz wenig am Dach komplett ungedämmt. Da pfeift es durch, Schimmel hatten wir noch nie. Aber klar, das muss jetzt natürlich intensiver beobachtet werden: die letzten 40 Jahre wurde mit zwei Gas-Einzelöfen geheizt (d.h. der Referent ist bei kalten Temperaturen ein paar Stunden vor Beginn vorbei gefahren und hat die Öfen aufgedreht) und im Winter zusätzlich mit Elektrofrostwächtern die Sanitäranlagen bedient. Unser Vermieter hat uns "erfreulicherweise" den Sanitärbereich renoviert und damit auf Zentralheizung (Gastherme) und Wasser-Radiatoren umgestellt. Damit haben wir nun mit FHEM / MAX zwar mehr Komfort, aber eben viel Ballast nebenbei. Den ersten Winter haben wir in 2 Monaten unseren vorherigen Jahresverbrauch an Gas durchgebracht, daher bin jetzt ich mit FHEM und MAX am Drücker.
Wir steuern die Therme bisher ohne eigenen Raumthermostat (lässt sich organisieren, verbaut ist die Junkers FW120 direkt am Gerät) über das Heatronic-Modul und einen Pitiny-Adapter am Heizungsbus. Im Moment steuere ich wirklich rein über An (75° Fuß- und Endpunkt, also völlig unabhängig von der Außentemperatur) / Aus (Frost) und lasse die Heizkörperthermostate "den Rest" regeln. Da wir ca. 3K/Stunde beim Aufheizen schaffen, kann ich die notwendige Dauer fürs Aufheizen im Wochenprogramm jeweils (händisch) drauflegen und unsere Ausbildungsteilnehmer sitzen im Warmen, zumindest im Rahmen der o.g. Schwankungen. Klar kann ich weniger Vorlauf einstellen und tue mich dann leichter, die Zieltemperatur zu halten. Dafür brauche ich eben längeren Vorlauf. Keine Ahnung, was effizienter ist.
Ich kann per Heatronic auch die Raum-Zieltemperatur vorgeben, habe aber zumindest bei der Fuß-/Endpunkteinstellung das Gefühl, dass das überhaupt keinen Einfluss auf irgendwas hat. Da muss ich nochmal das Junkers-Handbuch wälzen, welche Methode da die richtige wäre. In jedem Fall brauche ich eine Vorlauftemperatur, die unabhängig von der Außentemperatur ist, um die notwendige Aufheizzeit irgendwie sinnvoll miteinkalkulieren zu können.
Wie stelle ich denn nach Deiner Anregung zwischen PID20 und Max-Modus um?
*Präsenzzeit --> PID --> Wochenprogramm auf "ON" und PID starten (Ist- und Solltemperatur wird vom Wandthermostat genommen)
*Absenzzeit --> Normalmodus --> Wochenprogramm auf 6°, PID stoppen; Solltemperatur kann nicht am Wandthermostat gestellt werden, da es ja nicht mit den Heizkörpern assoziiert sein darf
Jan
ZitatIn jedem Fall brauche ich eine Vorlauftemperatur, die unabhängig von der Außentemperatur ist, um die notwendige Aufheizzeit irgendwie sinnvoll miteinkalkulieren zu können.
Es macht schon Sinn, wenn die Brennersteuerung die Vorlauftemperatur über die Aussentemperatur festlegt. Je kälter es draussen ist, umso höher wird die Vorlauftemperatur,
da ja auch mehr Wärmeverluste auszugleichen sind (Temperaturdifferenz zwischen Raum- und Aussentemperatur).
Auch wenn du fix mit 75 Grad im Vorlauf fährst wird sich je nach Aussentemperatur ein anderes zeitliches Verhalten ergeben.
Zum Thema alternierender Betrieb von MAX und PID20:
* die Regelung von MAX kann man eigentlich nicht abschalten
* wenn man jedoch den höchsten Sollwert vorgibt (der nie erreicht wird), so wird MAX das Ventil immer zu 100% öffnen
* in dieser Situation kann PID20 mit maxValveSetting direkt die Ventilöffnung beeinflussen
Präsenz-Modus:* Sollwert Max auf 30 Grad (Max-Regelung ist "inaktiv")
* PID20 aktivieren (manipuliert das Reading maxValveSetting und steuert somit direkt die Ventilöffnung von MAX)
* set <PID> restart 100
Absenz-Modus* Sollwert von Max auf 5 Grad bzw. OFF (Frostschutz)
* PID20 deaktivieren (set <PID> stop)
* maxValveSetting auf 100 setzen
John
Moin,
kann man das Modul einsetzten um eine KWL anhand des Co2 Wertes in der Luft zu regeln?
Ich habe einen Co2 Sensor, welcher mir jede Minute den Co2-Wert bereitstellt.
Die Lüftungsanlage kann in 8-Stufen geregelt werden.
Ich habe den Regler definiert:
defmod co2regler PID20 ESPEasy_Umweltsensor_co2_og:PPM Vallox_350SE:Stufe
attr co2regler event-on-change-reading .*
attr co2regler pidActorErrorAction errorPos
attr co2regler pidActorErrorPos 4
attr co2regler pidActorInterval 30
attr co2regler pidActorKeepAlive 900
attr co2regler pidActorLimitLower 1
attr co2regler pidActorLimitUpper 8
attr co2regler pidActorTreshold 0
attr co2regler pidActorValueDecPlaces 0
attr co2regler pidCalcInterval 30
attr co2regler pidFactor_I 0.1
attr co2regler pidFactor_P 0.8
attr co2regler pidReverseAction 1
attr co2regler room ESPEasy
Wie taste ich mich am Besten an die P/I Komponenten ran?
Ich habe diverse Einstellungen durchprobiert, aber es wird immer nur die Stufe 1 / 8 angefahren, Zwischenstufen leider nicht.
Kann mit hier vielleicht jemand auf die Sprünge helfen oder ist das Modul für sowas ungeeignet?
Gruß Steffen
Hi,
als erstes würde ich dir vorschlagen, ein SVG zu erstellen, in dem du measured, pi,pp und pd sowie actuation ausgibst. Daran kannst du sehr gut erkennen, welcher der Werte den sprung von 1 auf 8 verursacht.
Mein Gefühl sagt:
calcInterval zu klein
pidFactor_i zu groß
pidFactor_d zu klein
Wie stark schwankt denn der CO2-Wert? Zeig mal ein paar Messwerte...
Wenn du einen "schlechten" CO2-Wert hast und die Lüftung auf 1 (2...8) einschaltest, wie lange dauert es etwa, bis sich der Wert anfängt zu ändern?
Was mir grade noch einfällt: Wenn der CO2-Sensor direkt an der Zuluft hängt, könnte das durchaus kontraproduktiv sein... ich würde ihn an eine geschützte stelle bauen, evtl sogar in den Abluft-Kanal...
Grüße,
Stephan
Meine Erfahrung ist bei einer KWL ebenfalls, dass die Messung in der Abluft deutlich besser als Regelgröße funktioniert.
Herzliche Grüße
Christian
Danke für eure Antworten :)
Was habt ihr für Werte eingestellt? Müsste ein PI-Regler nicht langen?
Abluft direkt am Zentralrohr der KWL oder beim zu "überwachenden" Raum selber im Abluftrohr?
LG
Da ich aktuell nur einen Fühler habe (und schließlich auch nur je einen Zuluft-/Abluftmotor, den ich steuern kann) habe ich mich entschlossen, der zentralen Abluftrohr (hinter dem letzten Filter) zu messen (Mischung aller Abluften).
Herzliche Grüße
Christian
ZitatWie stark schwankt denn der CO2-Wert? Zeig mal ein paar Messwerte...
Wenn du einen "schlechten" CO2-Wert hast und die Lüftung auf 1 (2...8) einschaltest, wie lange dauert es etwa, bis sich der Wert anfängt zu ändern?
Wenn du mir ein paar Werte zur Verfügung stellt, äusser ich mich gerne mal zu den start-faktoren..
aber *raten* kann ich die nicht...
grüße,
Stephan (der für diese Steuerung vermutlich auf den I-Anteil verzichten würde)
@exciter
Ich meine daß diese Parametrierung keine gute Idee ist:
attr co2regler pidActorLimitLower 1
attr co2regler pidActorLimitUpper 8
attr co2regler pidActorTreshold 0
Gründe:
Der PID Actor-Bereich wird extrem eingeschränkt, um eine Anpassung an den Eingang des Aktors mit Stufe 1..8 zu erreichen.
Viel sinnvoller ist die Vorstellung, daß PID am Ausgang eine Wert von 0..100% aufweisen kann.
Dieser ist dann auf den Eingangsbereich des physischen Aktors zu transformieren.
Beispiel:
Von Bis Stufe
0 | 12 | 1 |
13 | 25 | 2 |
26 | 37 | 3 |
38 | 50 | 4 |
51 | 62 | 5 |
63 | 75 | 6 |
76 | 87 | 7 |
88 | 100 | 8 |
Damit kann auch pidActorTreshold wieder eingesetzt werden und das ist auch dringend geboten.
Angenommen PID befindet sich direkt am Übergang von einer zur nächsten Schaltstufe, so würde er dauernd hin- und herschalten.
Die vorgeschlagene Transformation lässt sich sicher gut mit einem User-Reading umsetzen.
Denkbare logiche Transformations-Formel : GANZZAHL(actuation/100+1)
John
Kann ich denn userreadings nutzen um das Reading actuation direkt zu ändern?
Nur unter Verwendung eines neuen Readings oder nicht?
Z.B. actuation {int( ReadingsVal("co2regler","actuation",0)/12.5)} funktioniert nicht.
Schreibe ich: actuation2 {int( ReadingsVal("co2regler","actuation",0)/12.5)}, haut es hin und ich bekomme bei actuation 100% -> actuation2 = 8.
Bezüglich werte/Diagramme/SVG habe ich noch nix Vernünftiges.
Rezept:
- beim Device Vallox_350SE ein UserReading "actuation" erzeugen
- die PID20 Defintion so abändern, daß das neue Reading verwendet wird
- Für Vallox_350SE.actuation ein notify definieren, daß den Wert wie vorgeschlagen transformiert und in das Reading Vallox_350SE:Stufe schreibt.
Gründe:
Der PID Actor-Bereich wird extrem eingeschränkt, um eine Anpassung an den Eingang des Aktors mit Stufe 1..8 zu erreichen.
Für mich zum Verständnis:
*Eigentlich* dürfte das doch keinen Unterschied machen, ob ich jetzt Werte von 1-100 nehme und die Faktoren auf 5 oder 10 einstelle,
oder ob ich Werte 1-8 nehme und die Faktoren auf 0.2 einstelle?
mit dem Threshold hast du natürlich recht, da sollte man das schwanken verhindern.
Bleibt die Frage, in welchen Grenzen sich der CO2-Wert bewegt...
Grüße,
Stephan
Moin,
der CO2-Wert schwankt so zwischen 400PPM (keiner Anwesend) und ~1200-1500PPM (2 Personen anwesend im Schlafzimmer).
Gruß Steffen
Also haben wir einen Regelbereich:
pidActorLimitLower 1
pidActorLimitUpper 8
pidActorValueDevPlaces 0
pid_Factor_P //
Annahmen: Soll-Wert= 500 (abhängig von a) was geht, wenn zwei Personen anwesend sind und die Anlage auf 8 röhrt, b) welches ist dein Wunsch-Ziel
Maximalwert 1500 -> hier soll die Anlage auf Stufe 8 laufen
8 Stufen / Differenz 1000ppm = 0,008
pid_Factor_I //
Dieser Faktor bestimmt, wenn der PID in einem stabilen Zustand steht, wann die Anlage trotzdem hoch oder runter schaltet.
Annahme: wenn der CO2-Gehalt nach Entscheidung der Stufe weiterhin nicht passt:
1 Regelstufe / 150PPM Abweichung IST-SOLL * 600 Sekunden = 0,00001 wird bei Abweichung von 150ppm vom Sollwert nach 600 Sekunden eine Stufe höhergeschaltet. Achtung, gilt dann natürlich auf fürs zurückschalten...
pid_Factor_D //
Größe ist ausschließlich abhängig davon, wie schnell die Anlage regelt, ob sie ins schwingen kommt usw. Kann ich anhand der verfügbaren Daten leider nicht abschätzen.
Dieser Faktor regelt, wie schnell die Anlage reagiert, wenn sich der gemessene Wert ändert.
Soll heissen, wenn die Anlage auf 8 steht, und der Wert fällt plötzlich von 2000 auf 1500, fährt der D-Anteil die Anlage bereits zurück, obwohl nach I und P noch hochgeregelt werden müsste.
Praxistipps: SVG zeichnen, da sieht man sehr schnell, welcher der drei Parameter für unerwünschtes Verhalten verantwortlich ist, und kann ihn anpassen...
Grüße,
Stephan (der sich jetzt hoffentlich nicht verrechnet hat)...
PS: Wenn du es umsetzt in der 0-100%-Schaltung, kannst du natürlich genauso vorgehen. Musst dann nur die Werte anpassen (die bei diesem Regel/Messbereich natürlich sehr klein werden..
Hi,
Hinweis: Ich habe ein Bild im Anhang.
Ich setze mich gerade mit dem PID-Regler auseinander.
Den Sollwert setze ich aus einem Notify namens "n_Wolf_Ansteuerung" heraus auf den PID-Regler.
fhem("set Regelung_Wolf_Sparfaktor DesiredTempFromMaxTempDiff $DesiredTempFromMaxTempDiff");;
Der wird offensichtlich im PID gesetzt.
Der Istwert habe ich in meinem Notify als Reading "MeasuredTempFromMaxTempDiff" abgelegt . (Der wird offensichtlich schon abgeholt.)
Den Stellwerk möchte ich in einem Dummy Namens "d_Wolf_BM1" auf das Reading 65_Sollwertkorrektur schreiben. Wobei der Wert zwischen -4 und +4 liegen kann.
Bei mir steht als Status "alarm - missing desired" obwohl sich gerade mein desired Wert aktualisiert hat.
Was mache ich falsch bzw. was möchte mir die Meldung sagen?
Hi,
also das Problem im Beitrag drüber konnte ich umgehen, indem ich mein Attribut "pidDesiredName" wieder entfernt habe und somit den Standard Reading Namen Desired beschrieben habe. Somit konnte ich nun den Regler auch starten.
Allerdings bekomme ich in meinem Haupt Fhem Logfile alle Minute diesen Fehlerblock, weiß jemand was man dagegen unternehmen muss?:
2018.03.31 19:59:13.514 1: ERROR: empty name in readingsBeginUpdate
2018.03.31 19:59:13.514 1: stacktrace:
2018.03.31 19:59:13.515 1: main::readingsBeginUpdate called by ./FHEM/98_PID20.pm (720)
2018.03.31 19:59:13.515 1: main::PID20_Calc called by fhem.pl (3064)
2018.03.31 19:59:13.515 1: main::HandleTimeout called by fhem.pl (615)
2018.03.31 19:59:13.515 1: readingsUpdate(,p_i,0) missed to call readingsBeginUpdate first.
2018.03.31 19:59:13.516 1: stacktrace:
2018.03.31 19:59:13.516 1: main::readingsBulkUpdate called by ./FHEM/98_PID20.pm (725)
2018.03.31 19:59:13.516 1: main::PID20_Calc called by fhem.pl (3064)
2018.03.31 19:59:13.516 1: main::HandleTimeout called by fhem.pl (615)
2018.03.31 19:59:13.517 1: ERROR: empty name in readingsBeginUpdate
2018.03.31 19:59:13.517 1: stacktrace:
2018.03.31 19:59:13.517 1: main::readingsBeginUpdate called by fhem.pl (4562)
2018.03.31 19:59:13.518 1: main::readingsSingleUpdate called by ./FHEM/98_PID20.pm (739)
2018.03.31 19:59:13.518 1: main::PID20_Calc called by fhem.pl (3064)
2018.03.31 19:59:13.518 1: main::HandleTimeout called by fhem.pl (615)
2018.03.31 19:59:13.519 1: readingsUpdate(,state,alarm - no yet for ) missed to call readingsBeginUpdate first.
2018.03.31 19:59:13.519 1: stacktrace:
2018.03.31 19:59:13.519 1: main::readingsBulkUpdate called by fhem.pl (4563)
2018.03.31 19:59:13.519 1: main::readingsSingleUpdate called by ./FHEM/98_PID20.pm (739)
2018.03.31 19:59:13.520 1: main::PID20_Calc called by fhem.pl (3064)
2018.03.31 19:59:13.520 1: main::HandleTimeout called by fhem.pl (615)
Tach auch,
ich lese mich seit geraumer Zeit begeistert durch dieses Forum.
Jetzt habe ich eine eigene Anwendung, zu der ich noch nichts fand:
Der Pufferspeicher der Zentralheizung in unserem EFH wird von verschiedenen Wärmequellen beheizt.
Nun kommt ein elektrischer Heizstab hinzu, der ausschließlich überschüssige PV Energie verheizen wird.
Er heizt in einem Durchlauferhitzer, der per Pumpenkreislauf mit dem Speicher, der keinen Einschraubflansch hat, verbunden ist.
Um die Schichtung im Speicher zu gewährleisten, soll die Durchflussmenge der Umwälzpumpe per Differenztemperatur (Speicher oben - Ausgang Durchlauferhitzer) geregelt werden. Das soll PID20 erledigen.
Nun meine Frage:
Welchen Sollwert soll die Pumpe verarbeiten können, um möglichst einfach eingebunden werden zu können?
Analog 0-10V? PWM? Sonst was?
Bin gespannt...
Bist Du Dir sicher, daß PID20 der richtige Weg ist?
Eigentlich willst Du doch überschüssige Energie in Wasser einbringen und zwischenspeichern. Ist doch egal, ob das punktgenau ist - je mehr Du reinheizt (im zulässigen Rahmen natürlich), je länger mußt Du nicht anders heizen.
D.h. ein notify oder DOIF reicht völlig aus: einfach auf UnusedEnergy > 0 und BelowMaxTemp pruefen. Wenn wahr, schalte die Pumpe ein und bringe Hitze in den Speicher...
Ciao, -MN
Über welches System willst du die Pumpe ansprechen?
Zum Beispiel für KNX gibt es zig 0-10V Aktoren, jedoch nichts vernünftiges in PWM. Daher würde ich immer ersteres bevorzugen.
Bin stolz auf mich: Hab den schlummernden Thread geweckt :)
@Morgennebel: genau, von der überschüssigen PV soll so viel wie möglich in den Puffer. Die Kommunikation mit der PV erledigt der intelligente Heizstab selbst und saugt ab, was überschüssig gemeldet wird und die Max Temp nicht überschreiten lässt. So weit, so einfach, doch dann kommt die Hürde "Schichtung":
PID20 soll sicherstellen, dass das eingespeiste Wasser mindestens so warm ist, wie im Puffer am Vorlaufstutzen. Der Überschuss kann bei heiter bis wolkig höchst dynamisch schwanken. Dem muss die Fördermenge folgen, um die Schichtungsaufgabe zu bewältigen. Daher der Ansatz, die Temperaturdifferenz zu regeln.
@JoeALLb: Danke, genau so einen Einstieg hatte ich erhofft. Bin noch nicht systemgebunden und werde nun mal bei KNX 0-10V studieren
Deine Heizung selbst kann das nicht mit regeln?
Meine Buderus kann bis zu 9 solcher Kreisläufe regeln, auch über 0-10V (aber auch per PWM). Funktioniert simpel und zentral. Ich habe 4 Zuführer, alle mit eigenem Wärmetauscher von der einen Heizung gesteuert. Bei mir wird der Solarstrom in eine Wärmepumpe gesteckt und somit die Wärmeausbeute nochmal um den Faktor 5 erhöht...
Danke auch für DEN Hinweis!
Hab die Vaillant Calormatic 470/3. Bislang fand ich darin nur Betriebsmodi mit 2 Wärmequellen. Die 1. -Vaillant LuftWasser Wärmepumpe arotherm vwl85- wird morgen nach langem Streit mit meinem Heizunsbauer wegen illegaler Lärmemission von selbigem endlich zurückgebaut. Legale Varianten sind mir zu teuer, deshalb erstmal der Heizstab.
Werde mich also mal tiefergend mit der Calormatic beschäftigen.
Kleines Abdeet meinerseits:
Nach dem Rausschmiss der Lärmquelle arotherm hat meine Heizung keine ebus Versorgung mehr. Sowohl die Mischersteuerung VR61 als auch das ebus-Kesselmodul VR39 und die Calormatic 470/4 empfangen und liefern nur Signale.
Fand für erträgliches Geld eine Calormatic 630, die den ebus versorgt und mehrere Wärmequellen für den Puffer im Griff halten können soll. Dennoch sehe ich kommen, die Pufferladung durch den stark modulierenden Heizstab unabhängig davon zu realisieren. Werde berichten und ggf. hier weiter auf Hilfe hoffen, wenn es darum geht, mit Bastelelektronik den PID20 Ausgang in 0-10 V zu wandeln.
Werde weiter berichten...
Zitat von: rostak am 03 September 2018, 21:42:35
weiter auf Hilfe hoffen, wenn es darum geht, mit Bastelelektronik den PID20 Ausgang in 0-10 V zu wandeln.
Werde weiter berichten...
mit KNX kann ich dir dabei helfen... Aber da brauchst du natürlich auch Mal das grundlegende wie einen Trafo.... ;-)
Guten Morgen,
ich habe gerade mal testweise ein MAX-Thermostat von dem *'!*'!! (problematischen...) fakeWT auf PID20 umgestellt. Eine Frage hierzu - wenn ich das richtig verstanden habe setze ich ja jetzt die gewünschten Temperaturen via PID per "set desired XXX", korrekt.
as ist denn mit den "alten" eingestellten Week-Profiles? Werden die direkt ignoriert? Muss ich die löschen? Will vermeiden dass sich da unterschiedliche Regelungen im Weg stehen. Sprich, wer "überstimmt" denn hier wen? Und was passiert wenn jemand am Themostat direkt dreht?
------------------------
EDIT: hat sich erledigt. Dachte ich hätte einen Parameter für die Übergabe im Modul übersehen. Ich hab jetzt einfach ein notify gebastelt das mir den Wert übernimmt.
Schönen guten Morgen zusammen,
ich könnte Hilfe bei der Einrichtung meines ersten PID-Reglers gebrauchen.. Ich werde aus dem Log nicht so ganz schlau und verstehe das Verhalten nicht so ganz..
Das Problem ist folgendes:
Um 7 Uhr springt die Soll-Temperatur von 18 auf 20 Grad. Die Ist-Temperatur beträgt aber bereits mehr als 20 Grad. Trotzdem geht das Ventil auf..
Um 9:45 Uhr habe ich gelüftet, das wird auch vom Fensterkontakt sauber erkannt und das Thermostat wird abgeschaltet.
List meines Thermostates:
Internals:
DEF HeatingThermostat 1b35b2
FUUID 5c6eee46-f33f-dc26-5275-b94f1bb47cb3caa8
IODev cm
LASTInputDev cm
MSGCNT 1013
NAME MAX_HT_SZM
NR 90
RSSI -65.5
STATE 17.0 °C
TYPE MAX
addr 1b35b2
backend cm
cm_MSGCNT 1013
cm_TIME 2019-03-04 10:28:31
dstsetting 1
mode 0
rferror 0
type HeatingThermostat
READINGS:
2019-03-04 10:28:31 RSSI -65.5
2019-02-21 19:34:10 TimeInformationHour 2
2019-03-04 10:28:31 battery ok
2019-03-04 10:28:31 batteryFKf1 ok
2019-03-04 10:28:31 batteryState ok
2019-02-22 07:17:26 boostDuration 25
2019-02-22 07:17:26 boostValveposition 80
2019-02-22 07:17:26 comfortTemperature 21.0
2019-02-22 07:17:26 decalcification Sat 12:00
2019-03-04 10:28:31 desiredTemperature 17.0
2019-02-22 07:17:26 ecoTemperature 17.0
2019-02-22 07:17:26 firmware 1.0
2019-02-22 07:17:26 groupid 0
2019-03-04 10:28:31 humidity 46.6
2019-03-04 10:27:10 maxValveSetting 0
2019-02-22 07:17:26 maximumTemperature on
2019-02-22 07:17:26 measurementOffset 0.0
2019-02-22 07:17:26 minimumTemperature off
2019-03-04 10:28:31 mode auto
2019-03-04 10:27:09 msgcnt 225
2019-03-04 10:28:31 state 17.0 °C
2019-03-04 10:28:31 temperature 18.1
2019-02-22 07:17:26 testresult 160
2019-02-22 07:17:26 valveOffset 0
2019-03-04 10:28:31 valveposition 0
2019-02-28 21:01:24 weekprofile-0-Sat-temp 19.0 °C / 20.0 °C / 17.0 °C / 20.0 °C / 19.0 °C / 19.0 °C
2019-02-28 21:01:24 weekprofile-0-Sat-time 00:00-08:00 / 08:00-10:00 / 10:00-21:00 / 21:00-23:00 / 23:00-23:55 / 23:55-00:00
2019-02-28 21:01:24 weekprofile-1-Sun-temp 19.0 °C / 20.0 °C / 17.0 °C / 20.0 °C / 19.0 °C / 19.0 °C
2019-02-28 21:01:24 weekprofile-1-Sun-time 00:00-08:00 / 08:00-10:00 / 10:00-21:00 / 21:00-23:00 / 23:00-23:55 / 23:55-00:00
2019-02-28 21:01:24 weekprofile-2-Mon-temp 18.0 °C / 20.0 °C / 17.0 °C / 20.0 °C / 18.0 °C / 18.0 °C
2019-02-28 21:01:24 weekprofile-2-Mon-time 00:00-07:00 / 07:00-09:00 / 09:00-21:30 / 21:30-23:00 / 23:00-23:55 / 23:55-00:00
2019-02-28 21:01:24 weekprofile-3-Tue-temp 18.0 °C / 20.0 °C / 17.0 °C / 20.0 °C / 18.0 °C / 18.0 °C
2019-02-28 21:01:24 weekprofile-3-Tue-time 00:00-07:00 / 07:00-09:00 / 09:00-21:30 / 21:30-23:00 / 23:00-23:55 / 23:55-00:00
2019-02-28 21:01:24 weekprofile-4-Wed-temp 18.0 °C / 20.0 °C / 17.0 °C / 20.0 °C / 18.0 °C / 18.0 °C
2019-02-28 21:01:24 weekprofile-4-Wed-time 00:00-07:00 / 07:00-09:00 / 09:00-21:30 / 21:30-23:00 / 23:00-23:55 / 23:55-00:00
2019-02-28 21:01:24 weekprofile-5-Thu-temp 18.0 °C / 20.0 °C / 17.0 °C / 20.0 °C / 18.0 °C / 18.0 °C
2019-02-28 21:01:24 weekprofile-5-Thu-time 00:00-07:00 / 07:00-09:00 / 09:00-21:30 / 21:30-23:00 / 23:00-23:55 / 23:55-00:00
2019-02-28 21:01:24 weekprofile-6-Fri-temp 18.0 °C / 20.0 °C / 17.0 °C / 20.0 °C / 18.0 °C / 18.0 °C
2019-02-28 21:01:24 weekprofile-6-Fri-time 00:00-07:00 / 07:00-09:00 / 09:00-21:30 / 21:30-23:00 / 23:00-23:55 / 23:55-00:00
2019-03-04 10:28:31 window1 closed
2019-02-22 22:56:47 windowOpenDuration 1
2019-02-22 21:50:39 windowOpenTemperature off
internals:
interfaces thermostat;battery;temperature
Attributes:
IODev cm
group Heizung
room 2_SZ_Marvin
scanTemp 1
scnModeHandling AUTO
scnProcessByDesiChange 1
scnShutterList MAX_FK_SZM
userReadings window1 {ReadingsVal('MAX_FK_SZM','state','')} , humidity {ReadingsVal('DHT22_SZ1','humidity','')}, batteryFKf1 {ReadingsVal('MAX_FK_SZM','battery','')}
userattr scnProcessByDesiChange:0,1 scnShutterList scnModeHandling:NOCHANGE,AUTO,MANUAL
List meines Sensors:
Internals:
DEF 100
FUUID 5c5b2da1-f33f-dc26-26bc-672793b5f484faa4
IODev MySensorGateway
NAME DHT22_SZ1
NR 54
STATE 18.9°C - 46.9% - 10:30:44
TYPE MYSENSORS_DEVICE
ack 0
radioId 100
repeater 0
READINGS:
2019-02-24 08:16:08 SKETCH_NAME TemperatureAndHumidity
2019-02-24 08:16:08 SKETCH_VERSION 1.1
2019-03-04 10:30:44 humidity 46.9
2019-02-24 08:16:07 parentId 0
2019-02-24 08:16:08 state received presentation
2019-03-04 10:30:12 temperature 18.9
gets:
readingMappings:
0:
0:
name temperature
1:
name humidity
42:
name id
sensorMappings:
0:
receives:
sends:
16
15
1:
receives:
sends:
16
15
10:
receives:
sends:
6
7
11:
receives:
sends:
11
12:
receives:
sends:
12
14
13:
receives:
24
sends:
17
18
54
55
56
24
14:
receives:
sends:
45
21
0
2
15:
receives:
sends:
13
43
16:
receives:
sends:
23
37
17:
receives:
sends:
18:
receives:
sends:
19:
receives:
36
sends:
36
2:
receives:
sends:
16
15
20:
receives:
32
sends:
33
50
32
21:
receives:
24
sends:
34
35
24
22:
receives:
sends:
37
43
23:
receives:
24
25
26
27
28
sends:
24
25
26
27
28
24:
receives:
sends:
37
43
25:
receives:
sends:
19
20
26:
receives:
40
17
3
sends:
40
17
3
27:
receives:
41
17
3
sends:
41
17
3
28:
receives:
40
sends:
40
29:
receives:
sends:
2
0
45
44
21
46
22
3:
receives:
2
17
sends:
2
17
30:
receives:
sends:
38
39
14
31:
receives:
sends:
2
16
32:
receives:
sends:
16
15
33:
receives:
sends:
37
16
15
34:
receives:
sends:
37
16
15
35:
receives:
sends:
37
16
15
36:
receives:
47
sends:
47
37:
receives:
sends:
34
35
38:
receives:
sends:
49
39:
receives:
sends:
0
51
52
53
2
4:
receives:
2
3
17
sends:
2
3
17
5:
receives:
29
30
31
3
sends:
29
30
31
3
6:
receives:
sends:
0
42
7:
receives:
sends:
1
8:
receives:
sends:
4
5
9:
receives:
sends:
8
9
10
sets:
clear noArg
flash noArg
fwType
reboot noArg
time noArg
typeMappings:
0:
type temperature
1:
type humidity
10:
type direction
11:
type uv
12:
type weight
13:
type distance
14:
type impedance
15:
type armed
val:
0 off
1 on
16:
type tripped
val:
0 off
1 on
17:
type power
18:
type energy
19:
type button_on
2:
type status
val:
0 off
1 on
20:
type button_off
21:
type hvacflowstate
22:
type hvacspeed
23:
type brightness
range:
max 100
min 0
step 1
24:
type value1
25:
type value2
26:
type value3
27:
type value4
28:
type value5
29:
type up
3:
type percentage
range:
max 100
min 0
step 1
30:
type down
31:
type stop
32:
type ir_send
33:
type ir_receive
34:
type flow
35:
type volume
36:
type lockstatus
val:
0 off
1 on
37:
type level
38:
type voltage
39:
type current
4:
type pressure
40:
type rgb
41:
type rgbw
42:
type id
43:
type unitprefix
44:
type hvacsetpointcool
45:
type hvacsetpointheat
46:
type hvacflowmode
47:
type text
48:
type custom
49:
type position
5:
type forecast
val:
0 stable
1 sunny
2 cloudy
3 unstable
4 thunderstorm
5 unknown
50:
type ir_record
51:
type ph
52:
type orp
53:
type ec
54:
type value
55:
type va
56:
type power_factor
6:
type rain
7:
type rainrate
8:
type wind
9:
type gust
Attributes:
IODev MySensorGateway
group MySensors
mapReading_humidity 0 humidity
mapReading_id 0 id
mapReading_temperature 0 temperature
mode node
room 2_SZ_Marvin
stateFormat {ReadingsVal('DHT22_SZ1','temperature','')."°C - ".ReadingsVal('DHT22_SZ1','humidity','')."% - ".substr(ReadingsTimestamp('DHT22_SZ1','humidity',''),11,8)}
List meines PID20-Reglers:
Internals:
CHANGED
DEF DHT22_SZ1:temperature MAX_HT_SZM:maxValveSetting
FUUID 5c78ef90-f33f-dc26-6d02-37db176740e3f88c
NAME PID_SZM
NR 106
NTFY_ORDER 50-PID_SZM
STATE processing
TYPE PID20
VERSION 1.0.0.9
READINGS:
2019-03-04 10:31:10 actuation 0
2019-03-04 10:31:10 actuationCalc -40.7399999999996
2019-03-04 10:31:10 delta -1.9
2019-03-04 10:31:10 desired 17.0
2019-03-04 10:31:10 measured 18.9
2019-03-04 10:31:10 p_d 0
2019-03-04 10:31:10 p_i 54.2600000000003
2019-03-04 10:31:10 p_p -94.9999999999999
2019-03-04 10:31:10 state processing
helper:
actor MAX_HT_SZM
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 180
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2019-03-04 10:27:09
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld -1.9
deltaOldTS 2019-03-04 10:31:17
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.2
factor_P 50
isWindUP 1
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor DHT22_SZ1
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
event-min-interval actuation:300,actuationCalc:300,delta:300,desired:300,measured:300,p_d:300,p_i:300,p_p:300
event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0
group PID
pidActorValueDecPlaces 0
pidFactor_I 0.2
pidFactor_P 50
pidReverseAction 0
room 2_SZ_Marvin
Kann mir helfen helfen bzw. Hilfe zur Selbsthilfe geben?
Liebe Grüße und schon mal vielen Dank,
Marvin
Hallo,
grundsätzlich scheint etwas Verständnis für den Regler zu fehlen, mal ganz grob beschrieben:
Proportional-Anteil (P) ... Jede Temperaturdifferenz erzeugt eine Ventilöffnung nach dieser Formel: deltaT*pidFactor_P
Beispiel: Soll: 20°C,IST:18°C,pidFactor_P=10 --> Ventilöffnung=20%
Beispiel 2: Soll: 20°C,IST:21°C,pidFactor_P=10 --> Ventilöffnung= -10%
Integraler Anteil (I) ... dieser Wert ist ein "gelernter Wert" aus der Vergangenheit, er beschreibt im Grunde genommen wie weit das Ventil geöffnet sein muss um eine Temperatur zu "halten". Denn bei deltaT=0K wäre der P-Anteil 0%, da aber Räume auch "nachgeheizt" werden müssen, benötigt man einen I-Anteil.
Zu jedem Zeitpunkt ergibt sich die tatsächliche Ventilöffnung als Summe aus I-Anteil + P-Anteil.
Dein Regler hat irgendwann mal gelernt (vermutlich hattest du das Attribut pidFactor_I irgendwann mal viel zu hoch), dass zum Halten der Temperatur etwa 50%Ventilöffnung nötig sind. Darum sinkt die Temperatur beim Absenken der Soll-Temperatur in der Nacht auch nicht ab.
dein I-Anteil ist, warum auch immer, viel zu hoch.
Als erstes würde ich empfehlen:
pidFactor_I 0.05
pidFactor_P 10
Danach den PID-Regler "resetten":
ZitatWie kann ich den I-Anteil (p_i) im Regler auf 0 setzen ?
Dies ist nach folgender Anweisung möglich:
set <Pid-Name> restart <p_p + p_d>
Danach rantasten Regler-Einstellungen (https://de.wikipedia.org/wiki/Faustformelverfahren_(Automatisierungstechnik)) --> empirische Dimensionierung
Hi Folgendes Problem.
Bei meinen thermostaten ist "Handbetrieb" möglich.
Durch eine Regel wird beim Handbetrieb der manuelle Modus mit Ventilöffnung deaktiviert.
Der PID läuft aber weiter.
pidActorKeepAlive ist 3600
Jetzt wechsel ich via Visu wieder auf Ventilöffnung.
Die neue Sollvorgabe wird dann z.B 21 Grad gestellt. Im Zimmer ist aber schon 22 Grad (durch Handbetrieb)
Der PID20 soll jetzt wieder greifen. Das Thermostat wechselt auch auf Stellantrieb.
Beim PID steht die actuation z.B jetzt auf 0 da neues SOLL 21 Grad ist und IST 22 Grad ist.
Durch den pidActorKeepAlive 3600 wird aber nicht direkt neue actuation gesendet.
Auch wenn ich in einem DOIF "PID restart 10" sende.. passiert nichts.
Gibt es eine möglichkeit die actuation einmalig via Befehl zu senden?
Nein, aber du könntest ActuationCalc direkt ins Thermostat ins maxvalvesetting senden.
Zitat von: bartman121 am 05 März 2019, 13:57:18
Hallo,
grundsätzlich scheint etwas Verständnis für den Regler zu fehlen, mal ganz grob beschrieben:
Proportional-Anteil (P) ... Jede Temperaturdifferenz erzeugt eine Ventilöffnung nach dieser Formel: deltaT*pidFactor_P
Beispiel: Soll: 20°C,IST:18°C,pidFactor_P=10 --> Ventilöffnung=20%
Beispiel 2: Soll: 20°C,IST:21°C,pidFactor_P=10 --> Ventilöffnung= -10%
Integraler Anteil (I) ... dieser Wert ist ein "gelernter Wert" aus der Vergangenheit, er beschreibt im Grunde genommen wie weit das Ventil geöffnet sein muss um eine Temperatur zu "halten". Denn bei deltaT=0K wäre der P-Anteil 0%, da aber Räume auch "nachgeheizt" werden müssen, benötigt man einen I-Anteil.
Zu jedem Zeitpunkt ergibt sich die tatsächliche Ventilöffnung als Summe aus I-Anteil + P-Anteil.
Dein Regler hat irgendwann mal gelernt (vermutlich hattest du das Attribut pidFactor_I irgendwann mal viel zu hoch), dass zum Halten der Temperatur etwa 50%Ventilöffnung nötig sind. Darum sinkt die Temperatur beim Absenken der Soll-Temperatur in der Nacht auch nicht ab.
dein I-Anteil ist, warum auch immer, viel zu hoch.
Als erstes würde ich empfehlen:
pidFactor_I 0.05
pidFactor_P 10
Danach den PID-Regler "resetten":
Danach rantasten Regler-Einstellungen (https://de.wikipedia.org/wiki/Faustformelverfahren_(Automatisierungstechnik)) --> empirische Dimensionierung
Vielen Dank für deine Antwort!
Ich komme anscheinend mit dem resetten des Reglers nicht ganz klar. Wenn ich die beiden Attribute angepasst habe und dann
set PID_SZM restart 10
in die Konsole eingebe, erhalte ich folgendes:
Internals:
DEF DHT22_SZ1:temperature MAX_HT_SZM:maxValveSetting
FUUID 5c78ef90-f33f-dc26-6d02-37db176740e3f88c
NAME PID_SZM
NR 106
NTFY_ORDER 50-PID_SZM
STATE processing
TYPE PID20
VERSION 1.0.0.9
READINGS:
2019-03-08 11:32:23 actuation 9
2019-03-08 11:32:23 actuationCalc 10
2019-03-08 11:32:23 delta -1.9
2019-03-08 11:32:23 desired 17.0
2019-03-08 11:32:23 measured 18.9
2019-03-08 11:32:23 p_d 0
2019-03-08 11:32:23 p_i 29
2019-03-08 11:32:23 p_p -19
2019-03-08 11:32:23 state processing
helper:
actor MAX_HT_SZM
actorCommand maxValveSetting
actorErrorAction freeze
actorErrorPos 0
actorInterval 180
actorKeepAlive 1800
actorLimitLower 0
actorLimitUpper 100
actorThreshold 1
actorTimestamp 2019-03-08 11:30:50
actorValueDecPlaces 0
adjust
calcInterval 60
deltaGradient 0
deltaOld -1.9
deltaOldTS 2019-03-08 11:32:32
deltaTreshold 0
desiredName desired
disable 0
factor_D 0
factor_I 0.05
factor_P 10
isWindUP
measuredName measured
reading temperature
regexp ^([\+,\-]?\d+\.?\d*$)
reverseAction 0
sensor DHT22_SZ1
sensorTimeout 3600
stopped 0
updateInterval 600
Attributes:
group PID
pidActorValueDecPlaces 0
pidFactor_I 0.05
pidFactor_P 10
pidReverseAction 0
room 2_SZ_Marvin
Ist das korrekt so? Der P-Anteil stimmt ja so mit dem Wert -19. Jedoch bekomme ich den I-Anteil nicht gesenkt.. Wie wird dieses Reading aus dem Attribut bestimmt?
Noch eine andere Frage:
Ich hatte vor dem Einrichten des PID-Reglers den Max-Scanner und feste Wochenprogramme definiert.
Muss ich davon eins löschen, wenn der Regler arbeitet?
Liebe Grüße,
Marvin
Der I-Anteil wird integriert, das heißt grob folgendes:
deltaT*pidFactor_I*Zeit, es gibt da noch ein paar andere Sachen (Anti-Wind-Up usw.) ist aber egal ...
Um den PID zu resetten musst du die Summe aus p_p und P_d nutzen, da p_d 0 ist ...
um den PID zu resetten (dein Beispiel):
set PID_SZM restart -19
Danach ist der I-Anteil bei 0
Die Wochenprogramme sind egal, solange das HT auf "manual" steht. Wichtig ist auch dass die Thermostate desired "on" haben.
Zitat von: bartman121 am 08 März 2019, 11:58:30
Der I-Anteil wird integriert, das heißt grob folgendes:
deltaT*pidFactor_I*Zeit, es gibt da noch ein paar andere Sachen (Anti-Wind-Up usw.) ist aber egal ...
Um den PID zu resetten musst du die Summe aus p_p und P_d nutzen, da p_d 0 ist ...
um den PID zu resetten (dein Beispiel):
set PID_SZM restart -19
Danach ist der I-Anteil bei 0
Ach, klar. Ich hatte fälschlicherweise die Werte aus den Attributen für den Neustart herangezogen. Jetzt sind die Anteile korrekt.
Zitat von: bartman121 am 08 März 2019, 11:58:30
Die Wochenprogramme sind egal, solange das HT auf "manual" steht. Wichtig ist auch dass die Thermostate desired "on" haben.
Okay, dann habe ich scheinbar irgendetwas noch nicht verstanden.
Ich sende mit einem Notify die desired Temperatur des Heizungsthermostates an den Regler.
Internals:
DEF MAX_HT_SZM:desiredTemperature:.* { fhem ("set PID_SZM desired $EVTPART1");}
FUUID 5c78fb93-f33f-dc26-bc2c-721239c9c7831de4
NAME not_PID_SZM
NOTIFYDEV MAX_HT_SZM
NR 107
NTFY_ORDER 50-not_PID_SZM
REGEXP MAX_HT_SZM:desiredTemperature:.*
STATE 2019-03-08 12:04:19
TRIGGERTIME 1552043059.35188
TYPE notify
READINGS:
2019-03-07 22:50:44 state active
Attributes:
Wenn ich jetzt das Thermostat auf Manuell stelle, werden die Wochenprogramme nicht herangezogen.
Jedoch übergebe ich doch dann den "on"-Wert an den Regler?
Dementsprechend steht jetzt im Log folgendes:
2019.03.08 12:04:19 3: set PID_SZM desired on : value on is not a number
2019.03.08 12:04:19 3: not_PID_SZM return value: value on is not a number
Ein Wandthermostat verwende ich allerdings garnicht. Kann es sein, dass ich für mein Vorhaben garkeinen Regler verwenden kann?! :D
Ich meine ich weiß, dass der Regler über die maxValveSetting agiert und ich dafür die interne Regelung des MAX-Systems umgehen muss.
Nur woher bekomme ich dann meinen Soll-Wert? Aus einem externen Notify ohne Bezug zum HT? Bzw. dann am besten aus einem at..
Liebe Grüße, Marvin
Das HT muss auf on stehen, sonst regelt das Thermostat mit dem eingebauten Mechanismus. Bei "on" fährt das Thermostat immer mit maximaler Ventiöffnung (begrenzt durch maxValveSetting). Genau das ist es was der PID20 "will". Eigentlich will der PID20 die Ventilöffnung vorgeben, das funktioniert aber nicht direkt, sondern über den "workaround".
Die Sollwertvorgabe musst du woanders hernehmen, ich habe dazu einen Dummy. Wochenprofile kannst du dann nicht mehr verwenden, du musst die Werte beispielsweise per AT anpassen.
Völlig einleuchtend.. Danke für deine Hilfe :)
EDIT: Der MAX-Scanner kann dann ja weg, richtig? Oder stört der nicht, wenn der im ModeChange-Modus nebenher läuft?
Der muss weg...
Zitat von: bartman121 am 08 März 2019, 13:31:42
Der muss weg...
Dachte ich mir schon. Ist weg!
Zitat von: bartman121 am 08 März 2019, 12:17:29
Die Sollwertvorgabe musst du woanders hernehmen, ich habe dazu einen Dummy. Wochenprofile kannst du dann nicht mehr verwenden, du musst die Werte beispielsweise per AT anpassen.
Also machst du AT -> Dummy -> Notify -> PID?
Ich habe jetzt einfach meinen Wochenplan in ein DOIF gepackt und gehe direkt von DOIF -> PID.
Hat es einen speziellen Grund, dass du über den Dummy gehst?
Liebe Grüße, Marvin
Das ist historisch gewachsen, es gibt dafür keinen echten Grund..
Alles klar, dann lasse ich es so! :-)
Vielen Dank für deine Hilfe!
Liebe Grüße und schönes Wochenende,
Marvin
Hallöchen,
mir kam noch eine Idee und ich würde gerne wissen was ihr davon haltet:
Mein jetziger Regler funktioniert mit dem Temperaturwert meines Dht22-Mysensors-Thermometers. Ich würde gerne eine Sicherung einbauen, sollte dieser aus welchen Gründen auch immer einmal streiken.
Die Idee ist folgende: Einfach einen zweiten Regler einrichten, der auf das interne Thermostat des MAX Heizungsthermostates zurückgreift. Sobald ein Reading älter als zb. 10 Minuten ist, soll Regler A den Betrieb einstellen und Regler B den Betrieb aufnehmen. Das ist ja über simple Anweisungen einfach zu bewerkstelligen. Auf diesem Wege hätte ich zwei Regler, die ich unabhängig voneinander Parametrieren kann.
Was haltet ihr davon? Ich meine rein praktisch gesehen, wäre es egal, ob jetzt mal 2 Grad mehr oder weniger in einem Raum sind. Aber die Komponenten sind alle da, also warum nicht?
Liebe Grüße, Marvin
Moin zusammen, ich nutze das Modul für meine MAX-Thermostate.
Im offenen Wohnzimmer habe ich 3 HKs und somit auch 3 HTs.
Ich habe mir jetzt mal angeschaut, ab welcher Ventilstellung die HTs Wasser durchlassen. Sagen wir einfach mal bei 10,20 und 40 Prozent Stellung.
Ich nutze logischerweise für den Raum 1 Temp-Sensor, welcher auf 3 PID-Regler der 3 HTs einwirkt.
Nun habe ich pidActorLimitLower
auf jeweils 10,20 und 40 gesetzt.
Allerdings sorgt das ja nur dafür, dass die HTs immer mindestens auf den Werten stehen. Sagen wir der errechnete Wert ist jetzt bei den 3 PIDs auf 15.
Dann ist nur 1 HK an und die anderen beiden sind noch "aus" auf 20 und 40.
Schön wäre eine Art Nullpunkt-Verschiebung, aber die habe ich nicht gefunden im Modul.
Ich habe nur pidActorCallBeforeSetting
gesehen, womit ich das vermutlich händisch hinbiegen könnte. Aber geht es auch schöner?
Gruß und Danke
Maui
Du kannst doch ein offset bei jedem TH-Ventil einstellen. Damit sollte es dann klappen.
Was meinst du genau mit offset? Steh grad auf dem Schlauch
Aus der MAX Commandref
valveOffset <value>
Nur für Heizkörperthermostate. Schreibt den angegebenen offset Wert der Ventilstellung in den Speicher des Gerätes Der Heizkörperthermostat wird diesen Wert während der Regelung zu den berechneten Ventilstellungen hinzuaddieren.
Das sollte bei deinem Vorhaben doch funktionieren.
Oh und ich hab immer nur bei PID20 gesucht. Danke. Teste ich ob es geht da bei MAX ja über maxValve gesteuert wird ob der offset dann auch greift.
Schreib dann nochmal ob es geht
Hi,
ich würde pidActorLimitLower verwenden. Sobald ich den Wert auf größer 0 setze, wird dieser immer als Minimum gesetzt, d.h.
auch wenn actuationCalc <= 0 ist.
Gibt es eine Möglichkeit, dass pidActorLimitLower nur greift, wenn actuationCalc > 0 ist?
Ich würde gern folgendes Erreichen:
1. Wenn actuationCalc <= 0 ... actuation = 0
2. Wenn actuationCalc > 0 dann actuation = actuationCalc falls größer als pidActorLimitLower sonst actuation = pidActorLimitLower
Hallo,
kann man das Modul auch für eine Klimaregelung verwenden? Müsste man etwas umstellen?
Ich habe in meinem Kanalsystem Klappen mit Stellmotoren, die ich entsprechend stellen will. Jetzt gibt es nur ein/aus dem zufolge wird ständig geregelt.
VG Stefan
Also prinzipiell kann man damit "alles" regeln. Zumindest das was sich halbwegs über einen PID abbilden lässt. Dein letzter Satz erschließt sich mir nicht.
Ich interpretiere das so dass seine momentane Regelung nur auf und zu kann, also 0 und 100%. Wenn die Klappen beispielsweise über einen Steppermotor o.ä. gesteuert werden und es Zwischenwerte gibt - denn kannst Du die auch hiermit berechnen und denn stellen lassen.
Nix anderes ist das bei der Heizungsregelung - 0 ist zu, 100 ist offen - der Regler berechnet die optimalen Öffnungswerte (also z.B. 11 statt 0 oder 20) und überschreibt die Regelwerte.
Ich habe jetzt einen Testaufbau hergestellt.
Der Unterschied bei der Klimatisierung ist, das der Regler öffnen soll wenn die Ist-Temperatur höher als die Soll-Temperatur ist. Also genau umgedreht zum Heizbetrieb.
Kann man da was einstellen?
2020-07-08 20:30:54 actuation 0
2020-07-08 20:30:54 actuationCalc -37.225
2020-07-08 20:30:54 delta -3
2020-07-08 20:30:54 desired 20
2020-07-08 20:30:54 measured 23.0
2020-07-08 20:30:54 p_d 0
2020-07-08 20:30:54 p_i 37.775
2020-07-08 20:30:54 p_p -75
2020-07-08 20:30:54 state processing
Ich hab zwar nur in die cref geguckt aber
pidReverseAction 1
Würde ich mal testen
Ok, das sollte funktionieren.
Ich habe noch etwas, wie kann ich einen Fenster Kontakt einbinden?
Da gibt es sicherlich 1000 Wege. Ich mache das per DOIF.
defmod diGastUntenFenster DOIF ( [fkGastUnten:state] eq "closed" and [htGastUnten] eq "cold") (set pidGastUnten desired 17)\
DOELSEIF ( [fkGastUnten:state] eq "opened") (set pidGastUnten desired 12, set hkGastUnten maxValveSetting 0)\
DOELSEIF ([fkGastUnten:state] eq "closed" and [htGastUnten] eq "hot") (set pidGastUnten desired 20)
Ich hab noch einen Taster drin zum warm machen und setze bei fenster auf direkt noch das ventil auf 0.
ansonsten würde PID ja bis zum nächsten Durchlauf warten.
Hallo
Benutzt jemand dieses Modul noch für etwas anderes als die Raumtemperatur damit zu regeln?
Ich versuche damit die Rücklauftemperatur meines Heizkessels zu Regeln?
Nachdem ich es jetzt endlich einen zuverlässigen Temperatursensor als Sollwertgeber gefunden habe bin ich am Rumspielen was die Regelparameter angeht.
Nach einem diesem Winter bin ich immer noch nicht dort wo ich gern seien wollte. Daher die Frage ob jemand für mich ein paar sinnvolle Vorschläge für die Regelparameter hat.
Mein Ziel ist es die Temperatur auf 73° +- 0,5° zu halten.
Heizkessel ist ein Atmos KC25 (Feststoffkessel mit 25KW)
Als Stellglied nutze ich einen 3 Wege Mischer der über das Stellmotor Modul gesteuert wird. (Geschlossen bis Offen 140s)
Sensor liefert alle 10s einen Temperaturwert
PID Modul berechnet alle 30s einen Stellwert für den Mischer.
Meine aktuellen Probleme:
Beim Hochheizen fängt der Mischer erst ab 80° an zu öffnen
Ab und zu kommt es zum aufschwingen des Mischers
Meine Aktuellen Parameter:
P: 3
I: 0,5
D: 2
Im Anhang ein Chart wo man das Verhalten sehen kann
14:00 Uhr Temperatur geht erst auf 80° bevor effektiv geregelt wird
15:00 Uhr Erstes aufschwingen (Mischer eines Heizkreises Regelt Temperatur nach unten)
15:30 Uhr Schwinngen keine Ahnung Warum
16:30 Uhr 1. Speicher voll umschalten auf 2. Speicher
17:45 Uhr Manuelle Eingriffe kann ignoriert werden
Jupp. genau das mache ich.
defmod PID_HV PID20 OW_HV_RLA:temperature none
attr PID_HV comment 90: Nur Vorlaufwasser/nach links drehen\
0: Nur kaltes Wasser/nach rechts drehen
attr PID_HV event-on-change-reading x_.*
attr PID_HV event-on-update-reading actuation,actuationCalc,p_d,p_i,p_p,measured,desired,delta,restarted
attr PID_HV pidActorCallBeforeSetting PID_HV_ActorSet
attr PID_HV pidActorInterval 1
attr PID_HV pidActorLimitLower 0
attr PID_HV pidActorLimitUpper 128
attr PID_HV pidActorTreshold 1
attr PID_HV pidActorValueDecPlaces 0
attr PID_HV pidCalcInterval 15
attr PID_HV pidDeltaTreshold 0.1
attr PID_HV pidFactor_D 0
attr PID_HV pidFactor_I 0.3
attr PID_HV pidFactor_P 0.5
attr PID_HV room HV_Steuerung,PID
attr PID_HV stateFormat {sprintf("%s, A: %.0f D: %.1f %s",ReadingsVal($name,"state",0),ReadingsVal($name,"actuation",0),ReadingsVal($name,"delta",0),ReadingsTimestamp($name,"actuation",0))}
attr PID_HV userReadings x_VL_HV {ReadingsVal("OW_HV_VL","temperature",-1)},\
x_Kessel_HV {ReadingsVal("OW_HV_Kessel","temperature",-1)},\
x_VL_RLA {ReadingsVal("OW_HV_RLA","temperature",-1)},\
x_VL_RL {ReadingsVal("OW_HV_RL","temperature",-1)}
Allerdings glaube ich, dass
a) so ein bisschen schwingen normal ist, grad bei nem Holzvergaser
b) man das nicht zuuu eng sehen darf
c) ein normaler PID damit überfordert ist, weil imho mehrere Messwerte zu berücksichtigen sind
d) ich mir den PID ein bisschen angepasst habe
Bei c) hab ich ein paar mal angesetzt, aber es läuft so "gut", dass mir das die Arbeit bisher nicht wert war.
Bild ist nicht so ganz aktuell, bin grade mit was anderem beschäftigt ...
Man sieht, dass der Abbrand gegen 22:30 gestartet ist, um kurz nach 4 war er fertig.
Grüße,
Stephan
Ich würde auf jeden Fall den D-Anteil wegnehmen. Ist ja eher was träges der hilft da nix
Ich nutze das Modul für die Luftverteilung meiner Klimaanlage. Die Regelung muss sehr direkt sein. Ich habe lange Probiert und in jedem Raum leicht andere Werte. Die Beispiele nutzten mir gar nichts.
Im Betrieb regeln die Klappen meist zwischen 40 und 60%. Was eine sehr gleichmäßige Regelkurve und Zieltemperatur ergibt. Eine Aufzeichnungskurve habe ich erst im Sommer.
defmod PID20_KiZi PID20 Klima_KiZi:Temperature Klappe_KiZi_PWM:dim
attr PID20_KiZi event-min-interval .*:120
attr PID20_KiZi event-on-change-reading desired,state,actuation,delta,p_i,p_p
attr PID20_KiZi pidActorInterval 60
attr PID20_KiZi pidFactor_I 5
attr PID20_KiZi pidFactor_P 50
attr PID20_KiZi pidReverseAction 1
attr PID20_KiZi pidUpdateInterval 60
attr PID20_KiZi room hidden
attr PID20_KiZi stateFormat actuation | state
attr PID20_KiZi userReadings desired {ReadingsNum("Klimaklappe_KiZi","desired",0)}
Ah noch was vergessen
Zitat von: Forstling am 16 März 2021, 18:11:11
Mein Ziel ist es die Temperatur auf 73° +- 0,5° zu halten.
imho zu Ehrgeizig, ich erkenne (für mich) keinen Mehrwert. Nichtsdestotrotz ist mir dieser Wunsch aus dem Holzheizer-Forum bestens bekannt. Nicht vergessen: das ist Holz, kein Gas...
Zitat
(Geschlossen bis Offen 140s)
Ich habe 120 sekunden. Alle Experimente mit (deutlich) längeren Zeiten waren für mich Nachteilig
Zitat
Sensor liefert alle 10s einen Temperaturwert
super
Zitat
PID Modul berechnet alle 30s einen Stellwert für den Mischer.
War mir zu langsam, ich rechne alle 15 sekunden. Lieber öfter weniger Bewegung, als seltener viel. Aber nicht übertreiben.
Zitat
Beim Hochheizen fängt der Mischer erst ab 80° an zu öffnen
PID resetten (der I-Anteil macht diese Probleme)
Mein Pid darf rechnen, sobald die VL-Temp >40 ist.
Grüße,
Stephan
Danke für die Antworten
@ Maui: Der D anteil sollte ja auf die Steigung reagieren Also den Regler schon auf machen kurz bevor die Solltemperatur erreicht ist und im Rest der Zeit nahe 0 sein. Ich hatte gehofft das er das anfängliche überschwingen wegnimmt.
Zitat von: abc2006 am 16 März 2021, 18:32:25
imho zu Ehrgeizig, ich erkenne (für mich) keinen Mehrwert. Nichtsdestotrotz ist mir dieser Wunsch aus dem Holzheizer-Forum bestens bekannt.
Man sollte halt Ziele haben aber zwichen 71 und 75 ist auch OK
ZitatIch habe 120 sekunden. Alle Experimente mit (deutlich) längeren Zeiten waren für mich Nachteilig
140s Braucht der Mischermotor wenn ich da was ändern will brauch ich neue Hardware
ZitatWar mir zu langsam, ich rechne alle 15 sekunden. Lieber öfter weniger Bewegung, als seltener viel. Aber nicht übertreiben.
Die 30s reichen für 21% Verstellweg vom Mischer 15 würden für ~11% ausreichen. Müsste man probieren. Ich hatte auch schon alle 10s Rechnen und alle 30s Stellen mein Mischer ist halt recht langsam.
ZitatPID resetten (der I-Anteil macht diese Probleme)
Mein Pid darf rechnen, sobald die VL-Temp >40 ist.
Also am besten 1 Doif das den PID 20 bei sagen wir 60° resetet. Die Berrechnung stoppen würde ich nicht, da bei Ausfall des Sensor der Mischer nicht mehr in seine Notfallstellung fährt. Obwohl das könnte ich noch über einen anderen Sensor abfangen. Falls mal jemand anfängt zu Heizen wenn der Sensor ausgefallen ist.
Zitat von: Forstling am 16 März 2021, 19:28:51
140s Braucht der Mischermotor wenn ich da was ändern will brauch ich neue Hardware
nicht zu eng sehen ;)
Zitat
Die 30s reichen für 21% Verstellweg vom Mischer 15 würden für ~11% ausreichen. Müsste man probieren. Ich hatte auch schon alle 10s Rechnen und alle 30s Stellen mein Mischer ist halt recht langsam.
japp. Deshalb hab ich mir das Stellmotor-Modul ein bisschen modifiziert.
Grob gesagt fährt der Mischer zuerst seinen Befehl zuende, bevor er den nächsten annimmt. Das stört den PID aber kaum (erfahrungsgemäß).
Ebenso Erfahrungsgemäß kommt es nicht oft vor, dass der Mischer so lange fahren muss - wenn denn der PID früh genug anfangen darf.
Zitat
Also am besten 1 Doif das den PID 20 bei sagen wir 60° resetet. Die Berrechnung stoppen würde ich nicht, da bei Ausfall des Sensor der Mischer nicht mehr in seine Notfallstellung fährt. Obwohl das könnte ich noch über einen anderen Sensor abfangen. Falls mal jemand anfängt zu Heizen wenn der Sensor ausgefallen ist.
Vor dieser Überlegung stand ich auch schon. Ist in den letzten 5 Jahren nicht passiert. Aber was ist die Sicherheitsstellung? Zu heiss ist blöd, da kommt die Thermosicherung. Zu kalt ist blöd, da rostet der Kessel... schwierig ...
lg,
stephan
So doif angelegt
@ abc2006
Ich habe mir mal deine Kurven angeschaut. sehe ich das richtig das dein Speicher am Ende des Abbrandes voll war?
Ich hatte immer das Problem das ich bei zu wening Abnahme meine Speicher umgewälzt habe. Das ganze so lange bis entweder morgens die Heizung anging oder der dann kalte Kessel die Speicher über die Esse soweit runtergkühlt hatte das der Mischer geschlossen wurde.
Das hat mich angeko....
Das war der Hauptgrund warum ich meinen Kessel über FHEM steuere und nicht über meine Solarsteuerung.
Ich habe mir für den Fall ein Doif geschrieben das die Solltemperatur vom Mischer auf 5° über die Rücklauftemperatur setzt.
Naja, voll würd ich jetzt nicht sagen, höchstens halb. Habe 4500l, da passen knapp 3 Abbrände rein. Siehe Bild.
Zitat
bei zu wening Abnahme meine Speicher umgewälzt habe
Verstehe ich das so, dass deine Puffer zu klein sind?
Meistgegebener Tipp: Mehr Puffer.
Viel einfacher: nicht so voll legen.
Zitatder dann kalte Kessel die Speicher über die Esse soweit runtergkühlt hatte das der Mischer geschlossen wurde
Du meinst mit "Mischer" die RLA?
Bei mir geht die HV-Pumpe aus, wenn der Abbrand fertig ist. Da wird nix weiter umgewälzt. Habe mal überlegt, ob ich die RLA komplett auffahre, um die Restwärme zu nutzen. Ist bisher aber nicht umgesetzt.
Den letzten Satz verstehe ich nicht. :)
Ja meine Speicher sind recht klein hab nur 2x 1000l aber der Platz gab nicht mehr her.
für 30m² Röhrenkollektor und einen 25kW Kessel ist das für den Staat ja ausreichend.
Aber wenn mich jemand fragen würde wie groß der Speicher sein soll würde ich sagen so groß wie möglich.
Zumindest war es wo ich die Teile eingebaut habe wenigsten im Winter beim Frühstück warm.
Und ja ich hätte eine Holzvergaserkessel Einbauen sollen aber damals hatte meine Mutter noch keinen Wald.
Das Problem ist halt wie kriege ich mit das ich nichts mehr reinlegen darf. Wenn mehrere Leute da was reinlegen ist das halt nicht so einfach. Und dann kommt es ja auch immer auf das Holz an. Jetzt war halt mal ein Haufen mit Birke dran das macht schon einen Unterschied zur Borkenkäfer-Fichte.
Ja meine Pumpe geht auch aus allerdings erst wenn die Wassertemperatur unter einen bestimmten Wert gefallen ist. (dann gehen Pumpe und Lüfter aus) Ist halt ein ziemlich einfacher Kessel. Elektronik findet man dort nicht ist alles klassiche Elektrik. Daher kann so etwas vorkommen.
Ja die Restwärme wollte ich auch mal nutzen. das Projekt schieb ich auch noch vor mir her.
zum letzten Satz: Sollwert für Mischer normalerweise 73° Wenn im Speicher unten über 68° sind dann: neuer Sollwert Speicher unten +5° (Also wenn im Speicher unten 70° sind wird die Solltemperatur auf 75° gesetzt:
Ich bin zwar bei deiner "hardware" raus aber ich würde den D Anteil wie gesagt weg lassen und den I Anteil auch erstmal. Lieber dem PID händisch ein I-Anteil einimpfen und dann anpassen zb nach unten beim überschwingen.
Die 0.5 wirkt auf mich auch erstmal relativ hoch, damit dürftest du schnell einen hohen I Anteil kriegen.
Den D-Anteil hab ich auch weggelassen. Ich würde aber eher auf den P-Anteil verzichten als den I-Anteil. Der I-Anteil regelt dir das im Laufe des Abbrandes schön aus (wenn er klein genug ist).
Abbrandende (für den Mischer) bekommst du schön mit, wenn du zb ein Abgasthermometer einbaust (MAX6675, Typ K), direkt an den Raspi
Wie du mitkriegst, dass du nix mehr reinlegen darfst:
Du machst mal einen Abbrand, dann hast du eine (ganz grobe) Vorstellung ,wieviel Energie bei einem mal anheizen rumkommt.
Dann könntest du (so wie ich) entweder einen Durchflusssensor und zwei Temperatursensoren anbringen (Wärmemengenzähler) oder (wie ich) an deine Pufferspeicher mehrere Temperatursensoren befestigen. (Ich hab alle 20 cm einen). Damit kann man schön sehen (und rechnen) wieviel Energie noch drin ist, und wieviel noch rein passt.
Da müssen sich dann natürlich alle dran halten, die den Ofen bedienen.
Zitat
ich hätte eine Holzvergaserkessel Einbauen sollen
der KC25S *ist* doch ein Holzvergaser - oder?
Grüße,
Stephan
Zitatder KC25S *ist* doch ein Holzvergaser - oder?
Nein das ist ein Feststoffvergaserkessel
Kleinerer Brennraum
Holz ist nur Zusatzbrennstoff
Eigentlich sollte man Braun oder Steinkohle reinlegen.
Dafür hat er einen sehr kleinen Abgaswärmetauscher und die Abgastemperatur soll bei 240° liegen bei mir ist sie 270°
ZitatAbbrandende (für den Mischer) bekommst du schön mit, wenn du zb ein Abgasthermometer einbaust (MAX6675, Typ K), direkt an den Raspi
Liegt in meiner Bastelkiste ist auf dem Plan Wenn ich das so recht überdenke wäre das auch eine Gute Steuerung für meine Nachlegelampe die geht derzeit auf den Durchflussmesser.
jetzt mus ich nur noch den passenden Bus zum Kessel bringen oder dort einen 2. Raspberry installieren langsam werden die Sensorkabel alle ist halt mist wenn Ofen und Kessel getrennt stehen.
ZitatWie du mitkriegst, dass du nix mehr reinlegen darfst:
Aktuell geht ein Lampe an wenn der Sensor im unteren dritttel des 2. Speicher eine gewisse Temperatur anzeigt.
Hier noch mal ein Bild zum besseren Verständniss meiner Heizung.
Hab mir mal das Bild angeschaut.. Dazu stellen sich mir erstmal zwei Fragen
a) warum sind bei dem linken Speicher oben und unten verbunden? Du sagtest was von "umschalten", deswegen glaube ich, dass die Zeichnung hier evtl. nicht ganz stimmt
b) Wie schaffst du es, dass deine Solarthermie *beide* Speicher heizt? Meine verwendet eine Solarflüssigkeit, die ich nicht mit dem Heizungswasser mische.
btw: vielleicht machst du besser nen neuen Thread auf, das wird doch arg OT
lg,
stephan
Hallo
Ja dafür wäre ein neuer Thread sinnvoll.
Kommen wir wieder zum eigentlichen Thema dem PID20 Modul.
Ich denke das hat einen gravierenden Fehler bei der Berechnung des D-Anteil (zumindest in meinem Fall: pidReverseAktion = 1)
Ich denke der D-Anteil wird in meinem Fall genau mit verkehrten Vorzeichen berrechnet.
Zur Eklärung:
Ich habe die Funktionsweise der Module eines PID-Regler folgendermaßen Verstanden:
P-Anteil: Nach den Regler schnell und genau ist einfach in diesem Fall Temperaturabweichung * P ist Anteil an der Mischerstellung
I-Anteil: schaut in die Vergangenheit wenn Sollwert erreicht hält er den Mischer auf dieser Position
D-Anteil: Schaut in die Zukunft wenn eine steigende Temperatur erkannt wird macht dieser Anteil den Mischer schon bevor die Solltemperatur erreicht ist ein Stück auf um Somit das erste Überschwingen zu minimieren bzw. man nähert sich langsam der Solltemperatur:
Beim meinem PID Regler macht der D-Anteil allerdings genau das Gegenteil er hält den Mischer zu wenn die Temperatur steigt und öffnet ihn wenn sie sinkt.
Jetzt ist meine Frage vestehe ich was falsch. Oder ist hier ein Fehler wegen der umgekehrten Aktion des Mischers.
Betrifft der Fehler auch den anderen Fall (pidReverseAction 0 --> Standardeinstellung)
Damit ist es das beste wenn man ihn auf 0 setzt und somit "nur" einen PI-Regler hat.
Zu den Fragen:
a. An der Verbindungstelle ist ein 3 Wegventil dieses schaltet etweder den unteren Ausgang des Speicher zum Rücklauf (somit 2. Speicher aus) oder den unteren Ausgang des 1. Speichers auf den oberen Eingang des 2. Speichers somit ist dieser mit im System. Ja, es fehlen ein paar Teile in der Zeichnung. Aber es Funktioniert.
b. Der Kasten wo die Wärmemengen drin stehen ist ein Wärmetauscher. somit habe ich 2 getrennte Kreisläufe 1x Solarflüssigkeit und 1x Heizungswasser
Ich hab mal kurz in das PID Modul reingeschaut.
Dann habe ich mir mal die Berrechnung des D-Anteils angeschaut und mal Testweise ein "* -1" eingefügt.
Sieht jetzt bei mir so aus:
# calc d-Portion
$dPortion = ($deltaGradient) * (-1) * $hash->{helper}{calcInterval} * $hash->{helper}{factor_D};
mal sehen wie es funktioniert.
Was erhoffst du dir denn konkret von dem D-Anteil? Ich bin mir ziemlich sicher dass du es falsch verstanden hast und falsche Erwartungen vom D-Anteil hast.
Der Code vom PID20 sieht richtig aus, er rechnet halt mit den Änderungen und da diese bei dir ja sicherlich kleiner werden ist der Wert nunmal negativ.
Bsp dein Ziel sind 20K und du hast erst 15K, dann 18K und dann 19K. Das delta davon ist 3K und 1K. Und 1-3 sind -2 und genau daher kommt dein Vorzeichen.
Du kannst natürlich einfach ein *(-1) davor machen aber das wird dir nicht helfen ;)
Aber noch(mal) was konstruktives: lass den D Anteil weg, dreh vermutlich den P-Anteil ein wenig runter ud stell den I Anteil erst einmal händisch ein, setz den Faktor für I auf 0 und taste dich an deine Ideale Regelung an. Oder eliminiere alle Störfaktoren für den I Regler, damit der nicht aus Blödsinn seinen Anteil berechnet.
Da kann ich mich den Empfehlung von Maui nur anschließen. Habe den PID-Regler für mehrere sehr träge Steuerungen genutzt und hatte nach langem Versuchsreihen den Durchbruch mit D=0 und dann einem nach Beobachtung eingestellten P Anteil: Bei Überschwingen zurücknehmen, bei zu zögerlichem Start raufnehmen. Faustformel für I-Anteil am Anfang 1/10 vom P-Wert.
Vielleicht helfen diese Praxis-Tips.
Christian
Zitat von: Maui am 31 März 2021, 22:41:16
Was erhoffst du dir denn konkret von dem D-Anteil?
Das er das macht was er soll und nicht genau das Gegenteil von dem was zumindest ich von ihm erwarte.
Heißt für mich der D-Anteil Regler erkennt eine steigende Temperatur also gibt er den Befehl gegenzusteuern.
Ich stelle mir das ungefähr so vor Soll 70°C ist schnell von 55°C auf 65 °C P-Anteil in meinem Fall -20 I-Anteil 0 (War ja die ganze Zeit zu kalt)
Jetzt sollte der D-Anteil schon bei ca +20 liegen das der Regler langsam anfängt auf zu gehen.
So meine Vorstellung eines PID Reglers. Und ich Glaube auch der einschlägigen FAchliteraturr
Ich will halt einen richtigen PID-Regler ansonsten hätte ich die miserable aber Funktionierende Reglung meiner Resol-Steuerung lassen können.
ich möchte halt einen funktionierenden PID-Regler und nicht wie vorgeschlagen einen P-Regler oder einen PI-Regler.
über Ostern wid es wieder kälter da werde ich Heizen müssen mal schauen ob sich der Regler jetzt so verhält wie in den Allgemeinen Beschreibungen die man so findet.
Mein ursprüngliches Ziel war es Die Vorlauftemperatur des Kessels zu Regeln die wollte ich auf 85-90°C halten. Aufgrund der Todzeit die sich durch die Rüclaufmischung einstellt wird das ganze Extrem Träge und das Überschwingen was jetzt schon fast 10K beträgt würde sich noch erhöhen und damit würde ich regelmäßig meine Notkühlung testen.
Sorry, aber Du scheinst eine Vorstellung zu haben, die so nicht nicht umzusetzten ist. Ich aber 16 PID20-Regler im Einsatz für so unterschiedliche Aufgaben wie Heizkörper-Steuerung, Kesselregelung, Vorlaufsteuerung für einen aus dem Hochtemparatur-Vorlauf abgeleiteter Fußbodenvorlauf, Solar-Kollektorsteuerung (da wurde übrigens auch eine kaputt gegangene Resol-Steuerung ersetzt) und es funktioniert.
Bitte aber auch https://wiki.fhem.de/wiki/PID20_-_Der_PID-Regler (https://wiki.fhem.de/wiki/PID20_-_Der_PID-Regler) beachten, da ist weiter unten die Strategie gegen den Windup-Effekt beschrieben, vielleicht "spuckt Dir der in die Suppe".
Meine zuvor beschriebene Strategie ist die des Ran-Tasten vom agilsten Regelanteil (P) über die Rückschau (I) hin zur Vorschau (D).
Schöne Feiertage
Christian
Gefühlt ist eines deiner gedanklichen Probleme dass du denkst ein PID würde sich unabhängig der Faktoren schon mit der Zeit selbst richtig einstellen.
Aber da du ein wenig resistent gegen Praxis Tipps bist, bin ich hier raus ;)
Zitat von: cwagner am 02 April 2021, 09:16:50
Bitte aber auch https://wiki.fhem.de/wiki/PID20_-_Der_PID-Regler (https://wiki.fhem.de/wiki/PID20_-_Der_PID-Regler) beachten, da ist weiter unten die Strategie gegen den Windup-Effekt beschrieben, vielleicht "spuckt Dir der in die Suppe".
Meine zuvor beschriebene Strategie ist die des Ran-Tasten vom agilsten Regelanteil (P) über die Rückschau (I) hin zur Vorschau (D).
Schöne Feiertage
Christian
Gegen den Windup-Effekt hatt hat das Modul seine eigene Strategie. Die kann man ja nutzen. Einfach pidActorLimitLower und pidActorLimitUpper setzen und schon ist der Wind-up effekt Geschichte.
Bei mir friert das den I-Anteil bei ca. 10 ein.
Somit sollte es keine Probleme geben.
Das mit dem Rantasten habe ich von Anfang an so gemacht mein Problem ist halt das der D-Anteil nicht den gewünchten Erfolg hat. Und nach mienem Verständnis eher das Gegenteil bewirkt. Daher das rumspielen am Code.
Zitat von: Maui am 02 April 2021, 09:49:34
Gefühlt ist eines deiner gedanklichen Probleme dass du denkst ein PID würde sich unabhängig der Faktoren schon mit der Zeit selbst richtig einstellen.
Die Faktoren sind das was die den Regler so flexibel macht und das dies kein selbstlernender Regler ist habe ich begriffen.
Ich werde Berichten wie es gelaufen ist meine Heizung vordert mich gerade zum heizen auf.
Edit:
So das erste mal Heizen mit Der Änderung im Code des Mischers.
Jetzt scheint er richtig zu rechnen.
Info an den Verantwortlichen für dieses Modul:
Ich glaube ich habe einen Fehler entdeckt.
Wenn pidReverseAction Aktiviert ist wird der D-Anteil des Mischer mit dem verkerten Vorzeichen berechnet.
Ich werde Versuchen meinen Mischer umzustellen damit ich das pidReverseAction nicht benötige. Und einen erenuten Test starten.
Edit2:
Ja der Fehler hat sich bestätigt. p_d wird bei pidReverseAction 1 und 0 mit dem gleichen Vorzeichen berechnet.
Daher bei
pidReverseAction = 0
Mischer in geschlossen = 100%
Bei steigender Temperatur: D-Anteil ist negativ --> Mischer wird eher geöffnet --> Verhalten Korrekt
pidReverseAction = 1
Mischer in geschlossen = 0%
Bei steigender Temperatur: D-Anteil ist negativ --> Mischer wird später geöffnet --> Verhalten in diesem Fall falsch
auf der linken Seite im Bild PID20 mit pidReverseAction = 1 auf der rechten Seite PID20 mit pidReverseAction = 0
Mischer haben gleiche Werte bei P, I, und D
Edit3:
Ich habe mich jetzt doch dazu entschlossen den D-Anteil zu deaktivieren.
Dieser errechnet die Steigung nur anhand der letzten Temperaturänderung. Daher führt es dazu das der Regler bei schnellen Temperaturänderungen ziemlich schnell aufschwingt. Dieser Anteil soll zwar schnell reagieren allerdings ist das bei dem Anwendungsbereich und meinem langsamen Mischer ziemlich ungünstig.
Vorschlag für eine Verbesserung:
Ich würde es als günstig empfinden wenn man den Integrationszeitraum des D-Anteils einstellen könnte.
Wenn man die Steigung der letzen 10 Werte berücksichtigen könnte würde dies zumindest in meinem Fall den D-Anteil stabilisieren und ich könnte ihn dazu nutzen das anfängliche Überschwingen zu eliminieren.
Hallo,
ich habe hier eine für mich recht verständliche Anleitung gefunden einen PID einzustellen:
https://kalka-automation.de/index.php/blogmenu-inbetriebnahme/37-einstellung-eines-pid-reglers-in-der-praxis
Jetzt habe ich aber eine Verständnisfrage zur Übersetzung der dort beschriebenen Werte Kp, Tn und Tv auf die Attribute pidFactor_P, pidFactor_I und pidFactor_D des PID20.
In meine Fall (Nulleinspeisung Solar-Wechselrichter) funktioniert es wie folgt ganz ok, wenn ich als Zeitbasis für Tu und Tg Minuten verwende:
pidFactor_P = Kp/60
pidFactor_I = Tn
pidFactor_D = Tv
Aber ist das so richtig oder eher Zufall?
Danke für eure Hilfe!
Lars
Hallo Lars,
puuuh, schwierig zu sagen, ich taste mich da jeweils ein wenig durch Experimentieren an die Werte heran bis es passt. Hast du denn die Werte mal aufgezeichnet und graphisch dargestellt? Siehe weiter oben im Thread zum Thema Logging etc.
Moin,
vielleicht wäre es besser, für konkrete aktuelle Fragen jeweils einen neuen Thread zu beginnen, anstatt diesen über 10 Jahre alten Thread immer wieder auszugraben.