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

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

Vorheriges Thema - Nächstes Thema

John

Hallo Bernhard,
ZitatGelegentlich verschwindet OWX - warum auch immer. Und damit stirbt auch PID

Nach dem derzeitigen Stand muss das so sein, da der PID vom Sensor "getrieben" wird.
Aber das wollen wir ja ändern.

ZitatDas letztendlich geführte FHT8V geht dann nach einiger Zeit in den Notbetrieb (Einstellung 30%) und muss dann, wenn alles wieder funktioniert, neu gepaired werden

Wir haben ja auch vorgesehen, dass wir den Sensor überwachen wollen.

Wenn nun der Sensor ausfällt und PID merkt dies, müsste er nach wie vor regelmässig den Stellbefehl an
FHT8V ausgeben, damit dieser nicht in Notbetrieb fällt ?

Wenn ja, wie in welchem Mindestintervall muss dies geschehen ?

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Bernhard

Hallo,
für den "Notbetrieb nehme ich an, dass dann 5-10 Minuten passen würden. Standardzyklus von FHT sind m.W. 2 Minuten. Dann sollte aber auch ein Not-Stellwert vorgegeben werden können. 30% dürfte im Allgemeinen zu viel sein.
Alternativ könnte ich mir auch nen Ersatzsensor vorstellen.
Das Ganze nur über  "at" und/oder "notify" zu treiben fände ich allerdings nicht ganz so toll.

Blödsinnigerweise passiert das immer, wenn ich ein paar Tage nicht da bin, dann glüht es im Wohnzimmer :-))
Bernhard

betateilchen

Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21Das Ganze nur über  "at" und/oder "notify" zu treiben fände ich allerdings nicht ganz so toll.

Das externe Triggern des PID wird komplett wegfallen, keine Sorge.

Zum FHT8V:
- Den Kommunikationstimeout müssen wir noch genauer rausfinden, ich denke, das ist länger als 5-10 Minuten.
- Die Notbetriebsstellung wird auch parametrierbar sein, das ist von mir schon vorgesehen, denn bei 30% wird es bei mir viel zu warm im Raum.
- Das viel größere Problem ist, dass ich nicht feststellen kann, ob der FHT8V überhaupt noch lebt, weil das ein reiner Empfänger ist

Die Attribute pidInterval, pidActorThreshold, pidDeltaTreshold habe ich bereits eingebaut.


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

Bernhard

Zum FHT8V:
[quote title=betateilchen schrieb am Do, 03 Oktober 2013 12:54]
Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21- Den Kommunikationstimeout müssen wir noch genauer rausfinden, ich denke, das ist länger als 5-10 Minuten.

* FHT sendet alle ca. 2 Minuten

* TimeOut dürfte im Stundenbereich sein - aber weiss der Teufel .....

[quote title=betateilchen schrieb am Do, 03 Oktober 2013 12:54]
Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21- Das viel größere Problem ist, dass ich nicht feststellen kann, ob der FHT8V überhaupt noch lebt, weil das ein reiner Empfänger ist

vielleicht darüber, dass die Temperatur nicht den Stellbefehlen folgt ?

Bernhard

stromer-12

[quote title=Bernhard schrieb am Do, 03 Oktober 2013 13:37]Zum FHT8V:
Zitat von: betateilchen schrieb am Do, 03 Oktober 2013 12:54
Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21- Den Kommunikationstimeout müssen wir noch genauer rausfinden, ich denke, das ist länger als 5-10 Minuten.

* FHT sendet alle ca. 2 Minuten

* TimeOut dürfte im Stundenbereich sein - aber weiss der Teufel .....

Der TimeOut liegt bei knapp unter 2 Stunden.
Gerade mal getestet.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

John

Hallo Udo

bin gerade dran meine PID-Variante mit Heating_Control zu verknüpfen.

habe folgendes realisiert:

set <device> (desired-temp|desiredTemerature|desired|comfort|comfort-temp|comfortTemperature|eco|eco-temp|eco-temperature) <temp>


mit temp : (<number>|comfort|comfort-temp|comfortTemperature|eco|eco-temp|eco-temperature)

damit geht folgends

set PID_BAD desired-temp comfort


Damit
- 2 weitere Readings: eco, comfort
- folgende auf initial-Wert stellen falls diese noch nicht definiert sind
    eco = 18, comfort=21, desired=21
   
 
Anbei die Realisierung in meinem Skript.

John
 
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

John

Ein Problem sehe ich noch im Zusammenhang mit Heating-Control.

Es wird beim Hochfahren von FHEM eher geladen als PID und will "desired" setzen.

Gibt es hierzu eine Lösung ?

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

ja, da muss im Heating-Control ein "require PID" eingebaut werden.

Ich habe jetzt mal eine erste Testversion fertig. Da ist HCS jetzt natürlich noch nicht eingebaut.  

Funktionsumfang und Define ist grundsätzlich wie im Originalmodul auch. Die Funktionsweise ist aber anders.


Attribute:

pidActorInterval = Mindestzeit zwischen zwei Kommandos an den Aktor
pidActorTreshold = Mindeständerung, ab der ein Kommando an den Aktor geschickt wird
pidActorErrorPos = Notstellung für Fehlerfall (noch nicht verwendet)
pidDeltaInterval = Intervall, in dem Sensorabfrage und Berechnung durchgeführt werden
pidDeltaTreshold = Mindesttemperaturänderung, ab der eine Berechnung stattfindet
pidSensorTimeout = Zeitraum, nach der ein Sensor als "tot" gemeldet wird (Reading und Logmeldung) wenn keine Aktualisierung des Messwertes erfolgt

Set Befehle:

set <name> clear = löscht die berechneten Werte manuell (automatisches Löschen erfolgt, wenn älter als 1 Stunde)
set <name> factors = wie bisher
set <name> desired-temp = setzt die gewünschte Temperatur



Es wird noch ein weiteres Attribut "pidParamTimeout" geben, um die Gültigkeitsdauer der berechneten Parameter festzulegen, aktuell steht die fest auf 3600 Sekunden.

Ich habe bis Montag weder einen Sensor noch einen Stellantrieb zur Verfügung, das Ganze ist nur aus der Theorie und mit Hilfe von dummies entstanden.
Es wäre schön, wenn jemand die implementierte Grundfunktion "in echt" testen könnte.

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

John

Hallo Udo,
besten Dank für den ersten Wurf.

Was mir bei der ersten Durchsicht aufgefallen ist:

Z.140
when("clear"){
Log3 $name, 3, "PID set $name $cmd";
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, 'actuation', '0.0');
readingsBulkUpdate($hash, 'delta', '0.0');
readingsBulkUpdate($hash, 'integrator', '0.0');
readingsBulkUpdate($hash, 'state', 'active');

Es macht aus meiner Sicht keinen Sinn acutation, delta und state zu löschen, da diese im nächsten zyklus wieder gesetzt werden. Integrator ist ok.

Z. 161
Zitatwhen("desired-temp") {
was machen wir wenn wir keine Temperatur regeln wollen, sondern Feuchte. Da macht das unverbindliche desired
auch wieder Sinn.
(siehe mein Vorschlag von heute Nachmittag für Alias-Namen)

sub PID_setValue($) {
...
if(!readingTimeValid(ReadingsTimestamp($sensor,$reading,''),AttrVal($name,'pidSensorTimeout',3600))) {
Log3 $name, 1, "PID $name: Sensor $sensor dead!";
readingsSingleUpdate($hash,'sensorState','dead',1);
} else {
readingsSingleUpdate($hash,'sensorState','alive',1);
}

Timeout sollte irgendwann parametriebar sein, nicht fest auf 1h. Es gibt auch schnellere Prozesse,
die es nicht erlauben 1h zu warten.

Sollwert-Container für eco und comfort wären natürlich schön und würde die Kompatiblität zu physischen
Reglern fördern.

Z. 218
if(!readingTimeValid(ReadingsTimestamp($name,'integrator',''),3600)){
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, 'actuation', 0.0);
readingsBulkUpdate($hash, 'delta', 0.0);
readingsBulkUpdate($hash, 'integrator', 0.0);

D.h. wenn der Regler auf Anschlag steht, z.B 100% wirst du ihn nach einer Stunde auf 0 runterprügeln;
damit wird es wenn es schon zu kalt ist, noch kälter.
Hab ich da was falsch verstanden ?

Z. 233

if($delta >= AttrVal($name,'pidDeltaTreshold','0')) {

Wenn der Regler eingeregelt ist, gibts hier leider keine Kurven mehr, da die Readings nicht mehr aktualisiert werden.

Z. 260
if($aDiff >= AttrVal($name,'pidActorTreshold','0') && $tDiff >= AttrVal($name,'pidActorInterval','0')) {
# send command to actor

Angenommen pidDeltaTreshold = 5 und Stellglied steht auf 96% und will weiter auffahren, dann kann er das nicht.
Man braucht am Anfang/Ende des Stellbereiches eine Sonderbehandlung.

Z. 270
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, 'actuation', $a);
readingsBulkUpdate($hash, 'delta',  $delta);
readingsBulkUpdate($hash, 'integrator', $i);
readingsBulkUpdate($hash, 'state', 'active');
readingsEndUpdate($hash, 1);

Ich würde mir hier noch den Sensorwert wünschen, dann ist der Chart schnell komplett (Istwert, Sollwert, Stellausgang).
Einen Minutenzyklus für den Integrator halte ich für sinnvoll, aber nicht für das Updaten der Readings.
Das müllt die Files unnötig mit immer denselben Werte zu. Vorschlag: dies mit pidActorInterval steuern und immer dann
wenn sich der Stellausgang ändert.


John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Z.140
Es macht aus meiner Sicht keinen Sinn acutation, delta und state zu löschen, da diese im nächsten zyklus wieder gesetzt werden. Integrator ist ok.

Es hilft, falls jemand alle Werte loggen möchte, denn dann hat er genau an dieser Stelle einen Peak nach unten im Log.

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Z. 161
was machen wir wenn wir keine Temperatur regeln wollen, sondern Feuchte. Da macht das unverbindliche desired auch wieder Sinn.
(siehe mein Vorschlag von heute Nachmittag für Alias-Namen)
...
Sollwert-Container für eco und comfort wären natürlich schön und würde die Kompatiblität zu physischen
Reglern fördern.

Ich hatte extra dazugeschrieben, dass Deine Vorschläge von heute nachmittag noch nicht berücksichtigt sind.

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Timeout sollte irgendwann parametriebar sein, nicht fest auf 1h. Es gibt auch schnellere Prozesse,
die es nicht erlauben 1h zu warten.

Ich hatte oben schon geschrieben, dass dieser Parameter in Arbeit ist.

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Z. 218
D.h. wenn der Regler auf Anschlag steht, z.B 100% wirst du ihn nach einer Stunde auf 0 runterprügeln;
damit wird es wenn es schon zu kalt ist, noch kälter.

Das Reading sollte auch einen neuen Timestamp bekommen, wenn es nicht verändert wurde. Bei mir funktioniert das jedenfalls so. Dadurch wird der Timeout eigentlich im laufenden Betrieb nicht erreicht.

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Wenn der Regler eingeregelt ist, gibts hier leider keine Kurven mehr, da die Readings nicht mehr aktualisiert werden.

muss ich mir anschauen.

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Angenommen pidDeltaTreshold = 5 und Stellglied steht auf 96% und will weiter auffahren, dann kann er das nicht.
Man braucht am Anfang/Ende des Stellbereiches eine Sonderbehandlung.

Ich weiss. Ich hatte aber auch nirgends geschrieben, dass diese Sonderbehandlung schon eingebaut sei ;)

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33Ich würde mir hier noch den Sensorwert wünschen

Der ist doch sowieso immer in den Readings vorhanden.

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33, dann ist der Chart schnell komplett (Istwert, Sollwert, Stellausgang).
Einen Minutenzyklus für den Integrator halte ich für sinnvoll, aber nicht für das Updaten der Readings.

Das läßt sich ganz individuell mit fhem-Boardmitteln (Attribute event-.*) steuern, deshalb muss ich da das Rad nicht neu erfinden und das im Modul selbst nachprogrammieren. Das kannst Du Dir konfigurieren, wie Du möchtest.

Es fehlen auch noch ein paar andere Dinge, z.B. wird eine Änderung des Intervals nicht sofort wirksam, sondern erst nach dem nächsten Durchlauf. Weiß ich alles, aber ich habe auch nur zwei Hände :)


Den Zusammenhang zwischen dem PID Modul und deinem HCS Einsatz habe ich noch nicht verstanden. Also, wie das zusammenspielen soll.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

John

Hallo Udo,
ich schätze deinen Einsatz sehr.

Mit meinen Anmerkungen will ich dich unterstützen, nicht kritisieren.

Zur Klärung  von "HCS"
das meine ich nicht
http://fhem.de/commandref.html#HCS

sondern dieses Modul
http://fhem.de/commandref.html#Heating_Control

Es ist ein Wochenschaltprogramm, das ich für die Thermostate einsetze.
Es setzt direkt oder indirekt über ein Skript zeitabhängig den Sollwert des Thermostats.

Beispiel:
Ich habe ein Thermostat f. Fussbodenheizung(PID in FHEM + Max als Stellglied) und eines f. Heizkörper (MAX realisiert Reglung und Stellglied) im selben Raum.

define HC.BAD Heating_Control HT.BAD 00:05|eco 12345|04:15|comfort 67|06:00|comfort 12345|07:00|eco 67|10:00|eco 15:00|comfort 21:30|eco {MaxScan_SetTemp("@","%");; fhem("set PID_BAD desired %");;}

Es wird also um 00:05 Uhr folgenden Befehl absetzen:
set PID_BAD desired eco

Nochmal die Bitte die Readings unabhängig vom Sensortyp zu formulieren, da PID ein universales Modell ist:
readingsSingleUpdate($hash,'measured-temp',$in,1);
Vielleicht: sensor-value

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

Zitat von: John schrieb am Do, 03 Oktober 2013 23:10Nochmal die Bitte die Readings unabhängig vom Sensortyp zu formulieren, da PID ein universales Modell ist

Ja ja... das ist mir gestern auch klargeworden. Ich bastle grade an einer Version, in der man den Namen des Messwert- und des Soll-Readings per Attribut selbst definieren kann. Wenn nichts definiert wird, heissen die Readings measured und desired.

Wenn ich die Sache mit dem Heating Control richtig verstehe, geht es Dir nur darum, dass "eco" und "comfort" in irgendwelche Zahlenwerte übersetzt werden muss?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Umgesetzt:

- die Namen für die Readings desired und measured über neue Attribute pidDesiredName und pidMeasuredName frei wählbar.
- interne Tabelle für Aliase, "set <name> desired, desired-temp, desiredTemperature <val>" bewirken alle die gleiche Aktion
- neues Attribut pidParamTimeout
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

John

ZitatJa ja... das ist mir gestern auch klargeworden. Ich bastle grade an einer Version, in der man den Namen des Messwert- und des Soll-Readings per Attribut selbst definieren kann. Wenn nichts definiert wird, heissen die Readings measured und desired.
ausgezeichnet.

Zitat von: betateilchen schrieb am Fr, 04 Oktober 2013 10:07Wenn ich die Sache mit dem Heating Control richtig verstehe, geht es Dir nur darum, dass "eco" und "comfort" in irgendwelche Zahlenwerte übersetzt werden muss?

Die meisten Thermostate verfügen über abgesenkten(eco) und normalen Sollwert(comfort).
Bei den Max-Thermostaten, bei meiner Heizung und vielen anderen regelnden Systemen kenne ich das so.

In meiner letzten Version hab ich das so implementiert:

# fuehrungsparameter der varianten ermitteln
  my $key = "";
  $key =  $PIDkeyDesiredTemp[0] if  grep(/^$arg/i, @PIDkeyDesiredTemp);
  $key =  $PIDkeyEcoTemp[0] if  grep(/^$arg/i, @PIDkeyEcoTemp);
  $key =  $PIDkeyComfortTemp[0] if  grep(/^$arg/i, @PIDkeyComfortTemp);
   
  # parameter converting eco/comfort       # TAG 3
  my $value =  $a[2];
  $value = ReadingsVal($pn,"eco","") if ($value eq "eco");
  $value = ReadingsVal($pn,"comfort","") if ($value eq "comfort");
  PID_sv($pid, $key, $value);

John


CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

betateilchen

Zitat von: John schrieb am Fr, 04 Oktober 2013 10:35
my $value =  $a[2];
$value = ReadingsVal($pn,"eco","") if ($value eq "eco");
$value = ReadingsVal($pn,"comfort","") if ($value eq "comfort");
PID_sv($pid, $key, $value);


Das ist ja schon etwas "von hinten durch die Brust ins Auge"... Nur mal so als Tipp:

PID_sv($pid, $key, ReadingsVal($pn, $a[2], ""));

bewirkt genau das gleiche in einer einzigen Zeile.

ABER: mir ist unklar, wie/wieso die Werte für "eco" und "comfort" in ein Reading kommen? Das sind doch keine Werte die vom PID generiert werden.

In meiner Lösung werden PID_sv() und PID_gv() nicht mehr vorkommen, weil das die Anwendung viel zu sehr einschränkt und die von fhem bereitgestellten komfortablen Möglichkeiten der event-Parametrierung ausschließt.

Die Tabelle für die "Befehlsübersetzung" habe ich inzwischen wieder ausgebaut, die steht in Konflikt mit der Möglichkeit, den Namen für "desired" jetzt frei wählen zu können.

Neu eingebaut:

set <name> stop
set <name> start


Es ist überhaupt noch die Grundsatzfrage zu klären, wann der PID gestartet werden soll. Im Moment ist das so, dass der PID Start nach einem "set <name> desired" erfolgt.

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