Autor Thema: PID-Modul: Vorschläge (gelöst)  (Gelesen 39253 mal)

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #15 am: 03 Oktober 2013, 10:58:33 »
Hallo Bernhard,
Zitat
Gelegentlich 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.

Zitat
Das 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 CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline Bernhard

  • Full Member
  • ***
  • Beiträge: 131
Aw: PID-Modul: Vorschläge
« Antwort #16 am: 03 Oktober 2013, 11:21:24 »
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

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16101
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #17 am: 03 Oktober 2013, 12:54:14 »
Zitat von: Bernhard schrieb am Do, 03 Oktober 2013 11:21
Das 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.


---
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline Bernhard

  • Full Member
  • ***
  • Beiträge: 131
Aw: PID-Modul: Vorschläge
« Antwort #18 am: 03 Oktober 2013, 13:37:01 »
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

Offline stromer-12

  • Hero Member
  • *****
  • Beiträge: 1356
Aw: PID-Modul: Vorschläge
« Antwort #19 am: 03 Oktober 2013, 15:05:08 »
[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 5.9(SVN) auf cubietruck mit HMUSB
FHEM 5.9(SVN) auf RPi1B mit HMser | CUNO
FHEM 5.9(SVN) virtuell mit HMLAN | CUL

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #20 am: 03 Oktober 2013, 15:46:16 »
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 CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #21 am: 03 Oktober 2013, 15:47:42 »
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 CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16101
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #22 am: 03 Oktober 2013, 20:05:57 »
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
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #23 am: 03 Oktober 2013, 21:33:46 »
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
Zitat
      when("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 CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16101
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #24 am: 03 Oktober 2013, 22:39:29 »
Zitat von: John schrieb am Do, 03 Oktober 2013 21:33
Z.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:33
Z. 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:33
Timeout 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:33
Z. 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:33
Wenn 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:33
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.


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

Zitat von: John schrieb am Do, 03 Oktober 2013 21:33
Ich 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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #25 am: 03 Oktober 2013, 23:10:36 »
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 CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16101
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #26 am: 04 Oktober 2013, 10:07:05 »
Zitat von: John schrieb am Do, 03 Oktober 2013 23:10
Nochmal 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?
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16101
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #27 am: 04 Oktober 2013, 10:29:28 »
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
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1426
Aw: PID-Modul: Vorschläge
« Antwort #28 am: 04 Oktober 2013, 10:35:20 »
Zitat
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.

ausgezeichnet.

Zitat von: betateilchen schrieb am Fr, 04 Oktober 2013 10:07

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?


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 CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16101
  • s/fhem\.cfg/configDB/g
Aw: PID-Modul: Vorschläge
« Antwort #29 am: 04 Oktober 2013, 11:33:29 »
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.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

 

decade-submarginal