Neues Modul PID20 - Der PID-Regler

[Hans Franz]

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:

Code Auswählen Erweitern

"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:

Code Auswählen Erweitern

"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

[betateilchen]

benenne das doch einfach um. Soweit ich weiß, gibts dafür ein Attribut pidMeasuredName

[Hans Franz]

Moin,
Ja klar. Danke.

Gruß
Hans

[betateilchen]

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

[Steve]

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

[John]

Gibt es dafür eine Lösung?

Wiki lesen, dort nach Alarm suchen

John

[frank]

hallo john,

ich habe meine pid20-regler nun einigermassen gut in mein system einbinden können.

als definition benutze ich folgenden code:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[John]

kann 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

[frank]

hallo john,

danke für die schnelle antwort.

Code Auswählen Erweitern

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


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

Mit 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

[cwagner]

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

[betateilchen]

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

[John]

Hallo Udo,

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?

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

[betateilchen]

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.

[betateilchen]

Doku checken ist ein cooler Job, wenn es noch gar keine Doku gibt 

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?

[John]

@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