UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mcm1957]

@fu_zhou

Ich hab da mal ein Topic geöffnet.

Bitte sobald passedn dorthin wechseln wenn es um Anwendung / Regelegungstechnikfragen geht.

[fu_zhou]

ich beobachte gerade die Überschussladung und stelle fest, dass mit der Zykluszeit noch etwas nicht ganz stimmt. Ich habe 500 ms parametriert, das ist auch der Wert, auf den immer wieder gesprungen wird, aber zwischendrin kommen sporadisch "Einbrüche" z.B. auf 41, 280, 340 ms, ich glaube, immer folgend auf die (dynamische) Veränderung von max. @mcm57 kannst du da noch mal reinschauen?

Ergänzung: Es sieht so aus, als wenn das immer passiert, wenn man einen "para" ändert - auch bei Tn, Kp etc.

[mcm1957]

@fu_zhou
Das sollte so nicht sein ist aber denkbar. Ich schaus mir an. Bin nur nicht sicher ob ich heut noch an pc komme. Bin unterwegs.

[fu_zhou]

@mcm57 Ich habe noch einen weiteren Regler hinzugefügt, damit ist die Instanz neu gestartet worden, jetzt scheint last_delta stabil bei 500 ms +- 1ms zu bleiben.

[fu_zhou]

@mcm57 beim zweiten Regler aus der Adapter-Instanz ist die Zykluszeit stabil, beim ersten kommt als Reaktion auf eine para Veränderung kurzzeitig der Sprung im last_delta.

[mcm1957]

@fu_zhou
Danke
Fehler schon gefunden. An sich müßte der Fehler bei allen Reglern auftreten.

Ursache ist eine Sonderbehandling von Cycle Time == 0. In diesem Fall wird eine Neuberechnugn getriggert, wenn neue Daten (act, Parameter, ...) eingeleifert werden. Das stammt noch aus der 0.0.0 Version. Ich bin aber zwischenzeitlich überzeutgt, dass das niemand braucht. Bevor ich nun in 3 Itaérationen (:-)) den Bug versuche zu beheben werde ich diese Sonderbahndlung ganz entfernen. Macht das Verhalten klarer nachvollziehbar. Wenn mal wirklich ein Bedarf auftritt nicht zyklisch sondern immer beim SChreiben der Daten neu zu berechnen kann man das ja wieder einfügen. Allerdings glaub ich wär da dann ein eigener State "jetzt berechnen" sinnvoller als diese krude Autiomatik.

Neue Release sollte morgen kommen.

[fu_zhou]

@mcm57 Da kann ich voll mitgehen - wie kann's auch anders sein 😉! Ist da nicht eh ein Denkfehler drin? Den I-Anteil will ich doch zyklisch berechnen, um die Regelabweichung abzubauen. Wenn eine Berechnung nur stattfindet, wenn sich Soll oder Ist ändert, bekomme ich doch eigentlich einen reinen P-Regler, auch wenn eine Nachstellzeit paramteriert ist, oder?

[paul53]

@fu_zhou sagte: Wenn eine Berechnung nur stattfindet, wenn sich Soll oder Ist ändert, bekomme ich doch eigentlich einen reinen P-Regler, auch wenn eine Nachstellzeit paramteriert ist, oder?

Nein, es kann aber lange dauern, bis sich die Regelabweichung ändert. Bis dahin ändert sich das Stellsignal nicht und macht dann plötzlich einen starken Sprung durch die Berechnung des I-Anteils. Deshalb sollte bei aktiviertem I-Anteil (Tn) auch immer eine nicht zu lange Zykluszeit aktiviert sein.

[mcm1957]

@fu_zhou said in Test neuer Adapter pid (pid-Regler) V0.0.x:

@mcm57 Da kann ich voll mitgehen - wie kann's auch anders sein 😉! Ist da nicht eh ein Denkfehler drin? Den I-Anteil will ich doch zyklisch berechnen, um die Regelabweichung abzubauen. Wenn eine Berechnung nur stattfindet, wenn sich Soll oder Ist ändert, bekomme ich doch eigentlich einen reinen P-Regler, auch wenn eine Nachstellzeit paramteriert ist, oder?

Nein, dass stimmt so nicht.
Der I Fehleranteil würde dann nur über ein längere Zeit summiert und dementsprechende ausfallen.

Aber wie schon geschrieben - ich seh den Bedarf nicht und mit fliegt diese Sonderbehandlung die nun schon zum driten (?) Mal nicht wie geplant funtkioniert weill immer wieder ein anderer Sonderfall nichgt codiert ist.

Mit 0.0.7 wird ein neuer Wert (hoffentlich) nur mehr berechnet wenn eine Zyklusperiode abgelaufen ist (und der Regler nicht gestoppt ist). Extrawürste gibts nicht mehr.

McM

[mcm1957]

@fu_zhou
Neue Version 0.0.7 released
Nun sollten Updates definitiv im Zyklusraster aktualisisert werden solange der Controller nicht gestoppet ist

[fu_zhou]

@mcm57 super, passt, vielen Dank!

[mcm1957]

Die Beschreibung des Adapters gibts nun auch auf deutsch:

https://github.com/iobroker-community-adapters/ioBroker.pid/blob/master/docs/de/pid_de.md

[paul53]

@mcm57
In welcher Einheit werden Tn (Nachstellzeit) und Tv (Vorhaltezeit) angegeben?
Da mit Nachkommastellen vermute ich Sekunden.

[mcm1957]

@paul53
Sollten Sekunden sein.

Die eingegebenen Werte werden in keiner Weise umgerechnet sondern 1:1 in die angegebenen Formeln eingesetzt.

[paul53]

@mcm57 sagte: Sollten Sekunden sein.

Bitte in der Beschreibung angeben.

[quorle]

Welche Werte würde man dem PI-Regler übergeben müssen, um einen Heizstab nach der vorhandenen PV-Leistung regeln lassen zu können?
Ein 0-100% Regelausgang würde mir reichen. Abschaltung des Reglers über die Temperatur wäre kein Problem ( zusätzliches Blockly ). Aktuelle PV-Leistung und aufgenommene Leistung des Heizstabes sind im ioB vorhanden.

[mcm1957]

@quorle said in Test neuer Adapter pid (pid-Regler) V0.0.x:

Welche Werte würde man dem PI-Regler übergeben müssen, um einen Heizstab nach der vorhandenen PV-Leistung regeln lassen zu können?
Ein 0-100% Regelausgang würde mir reichen. Abschaltung des Reglers über die Temperatur wäre kein Problem ( zusätzliches Blockly ). Aktuelle PV-Leistung und aufgenommene Leistung des Heizstabes sind im ioB vorhanden.

@paul53
@fu_zhou

Schätze da seid ihr seid Könner :-)

[paul53]

@quorle sagte: Aktuelle PV-Leistung

PV-Leistung (WR) oder PV-Überschuss (Einspeisung)?

[quorle]

@paul53

Sorry, meinte natürlich PV-Überschuss (Einspeiseleistung). Dieser Wert ist aber sowohl negativ, als auch positiv. Negativ = Netzbezug, positiv = Überschusseinspeisung

[paul53]

@quorle
Anhand früherer Beiträge zur "Nulleinspeisung" würde ich beginnen mit Xp = 10 * max. Heizstableistung und Tn = 2 * Aktualisierungszyklus der Leistung (Überschuss - Einspeisung). Davon ausgehend kann man dann optimieren.