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

[Ben1983]

@mcm57 hi, ich bin noch nicht zum Testen gekommen.
Würde auch erst mal warten, nicht dass ich die gleichen Dinge auffällig finde wie die Kollegen hier.
Aber:
Was ist eine wahlweise Berücksichtigung von Setpoint?

[mcm1957]

@ben1983

Was ist eine wahlweise Berücksichtigung von Setpoint?

An sich sollte das in der GUI direkt daneben stehen :-)

Oder anders ausgedrückt: Je nach Einstellung wird der Anteil des Differenzierers nur durch die Änderung des ACT Wertes beeinflußt oder durch die Änderung der DIFFERENZ zwischen ACT und SET. Im ersten Fall wirken sich Änderungen des Setpoints nicht auf den Differenziereranteil aus.

Diese Berechnungsvariante hat @paul53 in der ersten Diskussionrunde ins Spiel gebracht.

Bitte lass mich noch wissen wie du zum Thema STATES / FOLDERSTRUKTUR denkst. Hier hat ja @fu_zhou den Einsatz von Foldern angeregt. Das muss ich vor der ersten Beta entscheiden und würde das ungern später noch ändern.

[mcm1957]

@paul53
Danke für dein Feedback.

• ad run / hold / man

  Ok, wenn man sie nicht braucht, muss man sie ja nicht benutzen. Sie sollten jedenfalls (bei Nichtbenutzung) nicht stören. Daher seh ich keinen (zwingenden) Grund sie zu entfernen.

• Im Limit ist der Regler ja zumindest teilweise gestört / Das sehe ich nicht so.

  OK, da kann man drüber nachdenken. Da es keine echte Störung gibt würde ich die (rote) Rufzeichenanzeige für Overflow belassen. Echte Auswirkungen hat das nach meiner Kenntnis nicht. Wenn es aber mehrfach als störend empfunden wird, dann kann ich das auch rausnehmen. Ich würd da auf Rückmeldungen aus dem echten Beta Test warten

• Zum Zusammenhang Xp / Kp / Offset:

  Da der Regler intern immer mit Kp arbeitet möchte ich schon zur Kontrolle sowohl xp als auch kp verfügbar halten. Ob man Offset nun im Xp Mode mit (Max-Min)/2 fixiert oder als freie Größe belässt muss ich mir noch ansehen. Hast du wo Links auf die man verweisen kann warum das so sein sollte ?

Bitte lass mich noch wissen wie du zum Thema STATES / FOLDERSTRUKTUR denkst. Hier hat ja @fu_zhou den Einsatz von Foldern angeregt. Das muss ich vor der ersten Beta entscheiden und würde das ungern später noch ändern.

[mcm1957]

@fu_zhou @paul53 @Ben1983

Neue Version 0.0.2.alpha.2

• geändert: die Werte von kp, xp und sup werden nun auch überprüft falls diese mittels Zuständen verändert werden
• geändert: Werte von min und max werden nun auch überprüftfalls diese mittels Zuständen verändert werden
• geändert: Aktivierung von man atzualisiert nun y mit aktuellem Wert von man_inp
• geändert: min Wert wird nun beim Neustart der Instanz nicht neu initialisiert
• geändert: Umrechnung zwischen kp und xp wurde an mehreren Stellen korrigiert
• geändert: kp oder xp werden jetzt gemäß Modeauswahl schreibgeschützt"

[Ben1983]

@mcm57 ok.
Er hat bestimmt nen Grund dafür gehabt.
Ich persönlich habe noch keinen Fall gehabt.
Die Änderung des Setpoints hat bei einem PID Regler ja eigentlich immer ne Änderung des Inzegralanteils zur Folge, da die Regelabweichung e=Set-act sich ja ändert.

Die Idee mit den Folders finde ich gut.
Etwas strukturiert.
(Ich werde es zwar eh in alias packen, aber ist ne gute Sache).

ich habe die 0.0.2 noch nicht installiert.
Werde wohl über Ostern nicht dazu kommen.
Familie usw. ;-)

[mcm1957]

@ben1983 @fu_zhou @paul53

Da ich eine Tendenz zu einer Folderstruktur sehe, schlag ich hier mal was vor
Bitte um Kommentar(e), d.h. OK, anders, ger nicht gewunschen ...

• cfg - statische Config, nur via GUI änderbar

  • cycle
  • useXp
  • dao
    .

• in - Regler INPUT

  • act
  • set
  • man_inp
  • man
  • rst
  • run
    .

• out - Regler OUTPUT

  • y
  • diff
  • lim
    .

• para - Reglerparameter, via GUI und via Stest änderbar; tw berechne´t

  • xp
  • kp
  • tn
  • tv
  • min
  • max
  • off
  • sup
    .

• xtra - extra Daten (statistic, imnternals, ...) - output

  • i_differr
  • i_sumerr
  • last_delta
  • last_upd
  • last_upd_str

[fu_zhou]

@mcm57 Die Ordner-Struktur finde ich gut. Die Frage ist, ob xtra so ein guter Name ist, aber wahrscheinlich schon, da die Ordner-Sortierung nach Alphabet (ioBroker Admin) eine sinnvolle Reihenfolge gibt (die oben).

zu run / hold / man: Ich habe das aktuell ja gelöst, in dem ich den Regler "bescheisse" indem ich eine Regelabweichung von 0 vorgebe:

if getState('mqtt.0.go-eCharger.modelStatus').val == 23) { // bei Phasenumschaltung Regler pausieren
        var y = pi.Control(0); // Stellwert nicht verändern
}

Vielleicht ist das eine Idee?

Hold ist aber kein eigenes Objekt, sondern wird erreicht indem run = false gesetzt wird, oder?

[mcm1957]

@fu_zhou

• xtra
  hab ich gewählt, damit das nicht in der Mitte der Ordner liegt :-). Hast du richtig erkannt.
  'stat' sollte auch gehen.

• run/hold
  Ja, y soll da "eingefroren bleiben. Und auch ach der Wiederfreigabe nicht springen (außer act/set/ xxx haben sich geändert

• hold
  ja ist kein eigenes Object sondern hold = !run. Hab ich so gemachrt, damit das "running" (connected) symbol der Instanz damit ansteuerbar ist. Ist der State inactiv (run inactiov) wird connected durchgestrichen dargestellt.

[fu_zhou]

Habe die neue Version installiert und bin am Testen:

• man = true schreibt jetzt man_inp auf y, allerdings setzt bei rücksetzen von man (= false) der Regler nicht auf diesen Wert auf, sondern springt auf dem im Hintegrund durch die Regelabweichung weiter berechneten Wert.
• bei run = false beobachte ich auch noch das Verhalten wie oben (y wird angehalten, springt aber auf den im Hintergrund ermittelten Wert wenn run = true)
• sup funktioniert irgendwie nur bei Instanzstart, wird sup dann verändert, verliert es seine Funktion und der Regler arbeitet weiter, auch wenn der Betrag der Abweichung< sup ist.

Wenn ich so drüber nachdenke führen eigentlich 3 Fälle dazu, dass dem Regler eine Regelabweichung von 0 "vorgegaukelt" wird:

1. man = true => man_inp wird auf y geschrieben. Bei man = false macht der Regler ab man_inp weiter (ist ja das letzte y)
2. run = false => y wir gehalten. Bei run = true macht der Regler ab dem alten y weiter
3. Betrag der Regelabweichung < sup => y wir gehalten. Bei Betrag der Regelabweichung > sup macht der Regler ab dem alten y weiter

Kombination: bei aktivem sup setze ich man = true. Dann wird y = man_inp und wenn ich dann man = false setze bleibt y auf man_inp (weil letztes y) und wenn sup dann nicht mehr aktiv ist, regelt der Regler ab dem letzte y (=man_inp in diesem Fall) weiter: Das ist jetzt eher ein Testszenario als spezifisch zu programmieren ;-)

bei dao ist noch ein Schreibfehler: deriative act only (v fehlt)
bei lim: contoller mit zwei "l"

Wenn der Regler bei min/max angekommen ist (lim = true) würde ich auch keinen Fehler sehen und auf das Rot sowie (!) verzichten. Ebenso auf das Orange, wenn run = false. Orange würde ich nehmen, wenn der Regler in der Konfig nicht "Aktiviert" ist - oder ist das das Selbe?

Berechnung von Xp ist jetzt plausibel

[lobomau]

habe den Adapter installiert und erster Test sieht nicht so schlecht aus. kp, tn, tv hab ich nur durch Rumprobieren eingesetzt.
Ein einfaches Script beschreibt hier "actual value" mit dem Wert meines Stromzählers also Bezug/Einspeisung. Der Bezug wird von einem anderen alten Script auf 25 W geregelt; hier wäre die Idee es später komplett mit diesem PID-Regler zu machen.
Min/Max Werte für y habe ich 5 und 800 eingesetzt (in diesem Watt-Bereich regelt mein soyosource).
Differenz SOLL-IST wird immer korrekt berechnet und y nimmt zu/ab je nach pos. oder neg. Regelabweichung. So weit so gut.

[mcm1957]

DANKE dass du dir so rasch Zeit zum Testen nimmst.

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

man = true schreibt jetzt man_inp auf y, allerdings setzt bei rücksetzen von man (= false) der Regler nicht auf diesen Wert auf, sondern springt auf dem im Hintegrund durch die Regelabweichung weiter berechneten Wert.

Das geht m.E. nicht anders. Sobald der Regler den man Modus verläßt muß y dem entsprechen was sich aus act, sup, ... und den Paramatern ergibt. Im allgemeinen wird da immer ein Sprung passieren. Was derzeit noch nicht funktioniert ist, dass der Integralanteil nicht eingefroren wird.
(sieh issue https://github.com/iobroker-community-adapters/ioBroker.pid/issues/30)

bei run = false beobachte ich auch noch das Verhalten wie oben (y wird angehalten, springt aber auf den im Hintergrund ermittelten Wert wenn run = true)

Ja, ist noch offen - siehe oben.

sup funktioniert irgendwie nur bei Instanzstart, wird sup dann verändert, verliert es seine Funktion und der Regler arbeitet weiter, auch wenn der Betrag der Abweichung< sup ist.

OK, dass muss ich mir ansehen.

Bezüglich man/run
y ist nie ein Input und der Regler kann daher nach man=false / run = true etc. nicht "von y wegregeln". y ist das Ergebnis lt. den angegebenen Formeln, d.h. hängt primär von act - set und xp ab. Dazu kommt noch offset und integral / differentialanteil. Das bedeutet fast immer einen Sprung wenn mann man abschaltet. Wird run auf false gesetzt bleibt y stehen und sollte bei run = true nicht mehr springen als bei jedem Zeitintervall. (Das ist noch offen)

Bezüglich Farben
Wo siehst du den Regler "orange" bzw. "rot"?
Ich seh nur das "rote !" bei lim=true. Ok, das ist klar.
Aber run steuert eigentlich nur das grüne bzw graue Online Zeichen daneben.

[mcm1957]

@lobomau
Danke fürs Testen.
Anregungen sind immer gern sehen - abenso ist jedes Feedback ohen Problem ebenfalls sehr hilfreich.

[fu_zhou]

noch was beobachte ich gerade:

diff wird nicht zuverlässig berechnet, daher funktioniert auch sup nicht immer. Ich versuche das mal nachvollziehbar zu machen:

1. Neustart Adapterinstanz
2. set = 0, act = 0, sup = 0.2 => keine Regelabweichung, y "eingefroren" (diff = 0)
3. set = 0, act = -0.1, sup = 0.2 => keine Regelabweichung wg. sup, y "eingefroren" (diff = 0)
4. set = 0, act = -0.2, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch (diff = 0.2)
5. set = 0, act = -0.1, sup = 0.2 => eigentlich keine Regelabweichung wg. sup, aber y läuft weiter und diff = 0,2, sollte aber 0 sein (s. 3.)
6. set = 0, act = -0.3, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch, aber diff = 0.2 sollte aber 0.3 sein
7. set = 0, act = -0.4, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch, diff stimmt jetzt wieder mit 0.4
8. set = 0, act = -0.1, sup = 0.2 => eigentlich keine Regelabweichung wg sup, aber y läuft weiter und diff = 0,1, sollte aber 0 sein (s. 3.)
9. set = 0, act = 0, sup = 0.2 => keine Regelabweichung, aber y läuft weiter weil diff = 0,1, sollte aber 0 sein
10. act = -0.4, dann act = 0 => diff = 0.4, dann 0 => dann stimmt es wieder und man kann wieder bei Punkt 2. einsteigen und das Ganze wieder beobachten.

Jetzt raucht mir erst mal die Birne...

[fu_zhou]

@mcm57 bei run = false: Orange

bei lim = true: rot

[Ben1983]

@mcm57 sieht ganz gut aus.
Ich weiß zwar aktuell nicht, was man_inp oder sup sein soll. Aber ok.

[fu_zhou]

@ben1983
man_inp = Vorgabe für y wenn man = true

Aus der OSCAT-Beschreibung: Mit dem Eingang SUP wird eine Rauschunterdrückung eingestellt, der Wert am Eingang SUP legt fest ab welcher Regeldifferenz der Regler einschaltet. Mit SUP wird vermieden, dass der Ausgang des Reglers dauernd schwankt. Der Wert am Eingang SUP sollte so bemessen sein, dass er das Rauschen der Regelstrecke und der Sensoren unterdrückt. Wird zum Beispiel der Eingang SUP auf 0.1 gesetzt so wird der Regler erst bei Regelabweichungen größer als 0.1 aktiv.

[fu_zhou]

@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:

Bezüglich man/run
y ist nie ein Input und der Regler kann daher nach man=false / run = true etc. nicht "von y wegregeln". y ist das Ergebnis lt. den angegebenen Formeln, d.h. hängt primär von act - set und xp ab. Dazu kommt noch offset und integral / differentialanteil. Das bedeutet fast immer einen Sprung wenn mann man abschaltet. Wird run auf false gesetzt bleibt y stehen und sollte bei run = true nicht mehr springen als bei jedem Zeitintervall. (Das ist noch offen)

Ja klar, verstehe. Wenn das implementiert wird das schon passen!

[mcm1957]

@fu_zhou
Danke. Offensichtlich hab ich ne andere Admin version die den Text nicht färbt.
Im Prinzip ist alles klar. Das rote Rufzeichen nehm ich mal raus. Orange bleibt da der Adapter in dem Zustand ja nicht läuft ist das meiner Ansicht nach OK.

https://github.com/iobroker-community-adapters/ioBroker.pid/issues/35

Welche Admin Version hast du aktiv?
Bei mir ist da nix bunt bei Admin 6.3.7 und 6.4.3.

[mcm1957]

@ben1983 said in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:

@mcm57 sieht ganz gut aus.
Ich weiß zwar aktuell nicht, was man_inp oder sup sein soll. Aber ok.

man / man_inp gehören zusammen.
Aktiviert man man, wird der Wert von man_inp direkt auf y durchgereicht.

Ein Anwendungsfall wär z.B. eine (Heizungs-)Steierung bei der ein Steuerventil (z.B. 0-10V) mit Y angesteuert wird. Im Servicefall will man das Ventil auf z.B. 25% stellen - unabhängig v Temperaturen etc. Dann lkann man setzen man=true, man_inp=25.

OK das gibge auch extern zu lösen, aber wenn man das gleich im Adapter hat braucht man für diesen Fall kein zwischengeschaltetes Blockly/Javascript da VIS die States des Adapters ggF direkt ansteuern kann.

Für den normalen Reglerbetrieb gilt man=false, man_inp=irrelevant

sup stellt eine Hysterese dar die kleine Änderungen des Inputs ignoriert. Dazu gibts hier gleich noch ne Diskussion :-)

[mcm1957]

@fu_zhou
Ok, da gibts eine Unterschiedliche Ansicht / Auffassung zu was sup tun soll.
Derzeit ist eingebaut, dass sub kleine Änderungen des Eingangs ignoriert, d.h.

if (act[t] - act[t-1]) < sup) then do_nix

Lt. deiner Beschreibung aus OSCAT soll sich sup aber auf den Wert von DIFF Beziehen, d.h. wenn die Regelabweichung < sup ist soll nix passieren, d.h.

if (set - act) < sup) then assume diff=0

OK, das kann / werd ich ändern. Durch diff=0 sollte dann auch der I Anteil gleich bleiben. Der Differenziereranteil kann sich noch ändern, da ja diff[t-1] ggf ungleich 0 war.

https://github.com/iobroker-community-adapters/ioBroker.pid/issues/32