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

[Gargano]

@sevensworld Die Werte sollten eigentlich nicht überschrieben werden.

Movements sind die Anzahl der Fahrten für jedes Ventil einzeln, egal ob 1 % oder um 100 %
200 Movements ist sehr wenig, die werden sehr schnell erreicht.
h ist die Uhrzeit, also 0 h ist um Mitternacht.
Und alles ist gleichberechtig.

Ich habs so eingestellt

Also nach 2000 Fahrten für jedes Ventil einzeln und
um Mitternacht jeweils Sonntags und Mittwochs für alle Ventile.
Das gilt immer , auch wenn die Ventile im Sommer in Park Position sind.

[Sevensworld]

@gargano
Ah ok, danke für die Erklärung.
Evtl. könnte man das mit Uhrzeit deutlicher machen, in dem man das als Uhrzeit eingeben muss ( 00:00 ).
h als Beschriftung dahinter wirkt für mich in dem Fall etwas unglücklich.
200 hatte ich eingeben, weil mir 2000 als sehr viel vorgekommen ist und weil mir das mit den Wochentagen nicht ganz klar war. Wenn aber sowieso alle Ventile auch an den eingestellten Wochentagen fahren, dann macht 2000 mehr Sinn.

Ich gehe davon aus, das die Info auf der Seite dazu im Github noch nicht aktualisiert ist, da die Topics und Inhalte leicht abweichen. Liegt sicher an der Dev Version, oder ?
In den MQTT Daten gibt es unter dem Topic "common" den Wert "message", da steht als Inhalt "SW" drin und in "state" steht "1" drin. 1 bedeutet sicher das es eine Info gibt, aber was bedeutet "SW" ?
Bei den Ventilen habe ich keine Temperaturen hinterlegt bzw. keine Sensoren zugeordnet, im MQTT Payload steht aber bei beiden Werten initial -50 drin. Ist das so gewollt ?

[Gargano]

@sevensworld
Ja, die Doku hinkt immer etwas hinterher.

State bedeutet dies

#define systemStateOK       0
#define systemStateInfo     1  // da gibt es was in message
#define systemStateError    2  // da gibt es was in message

Message ist ein SystemMessage , hier bedeutet SW Restart über Software

    "UNKNOWN",    //!< Reset reason can not be determined
    "POWERON",    //!< Reset due to power-on event
    "EXT",        //!< Reset by external pin (not applicable for ESP32)
    "SW",         //!< Software reset via esp_restart
    "PANIC",      //!< Software reset due to exception/panic
    "INT_WDT",    //!< Reset (software or hardware) due to interrupt watchdog
    "TASK_WDT",   //!< Reset due to task watchdog
    "WDT",        //!< Reset due to other watchdogs
    "DEEPSLEEP",  //!< Reset after exiting deep sleep mode
    "BROWNOUT",   //!< Brownout reset (software or hardware)
    "SDIO"       //!< Reset over SDIO

Bei den Temperaturen steht -50 wenn kein Sensor angeschlossen ist.

[Sevensworld]

@gargano
Da es jetzt langsam in Richtung Heizperiode geht, habe ich vom "ausprobieren" in die "live" Phase gewechselt.
Generell klappt das Zuweisen der Temperaturwerte über MQTT sehr gut.
Was mir allerdings aufgefallen ist, ist das die Regelung nicht so funktioniert, wie ich erwartet hätte oder ich habe das Prinzip noch nicht richtig verstanden.
Erwartet hätte ich eine Drosselung der Ventilköpfe, wenn die IST sehr nahe an die Solltemperatur heran kommt.
Es war aber so, das selbst bei einer Abweichung von nur noch 0,2 Grad, das Ventil immer noch bei 100% stand.
Ts ist die Intervallzeit zwischen den Regelzeitpunkten, richtig? also bei Ts=450s wird alle 7,5 Minuten neu auf die Temperaturen geguckt und die Ventile angesteuert?

Gruß

[Gargano]

@sevensworld Ts ist die Sampling time, nach der nach neuen Werten geschaut wird. Die Regeling ist eine PI Regelung. Bei Ist-Soll >0 wird der Durchfluss verringert. Bei Ist-Soll <0 wird der Durchfluss vergrößert. Wenn es eh schon auf 100% wird aber nichts mehr vergrößert. Wenn aber bei 100% gerade die Solltemp erreicht ist, dann hast Du aber keine Regelreserve mehr. Zeig mal bitte Deine Einstellung in Control

[Sevensworld]

@gargano
Wenn erst bei Ist-Soll > 0 der Durchfluss verringert wird, ist das doch eigentlich bei einer FB Heizung zu spät !? Die reagiert doch eh sehr träge und müsste viel eher abgeregelt werden. Wahrscheinlich habe ich einen Denkfehler ...
Wie funktioniert Ti in dem Zusammenhang bzw. was müsste angepasst werden?

[Gargano]

@sevensworld Ts sollte 4 bis 5 mal kleiner sein als Ti. Also passt das. Du musst Deine Schaltpunkte beim Soll entsprechend früh machen, damit dann zum richtigen Zeitpunkt die Temperatur erreicht ist.
Aber ich denke, Deine Vorlauftemperatur ist zu niedrig, wenn der Regler auf 100% geht und erst da die gewünschte Temperatur erreicht wird.
Im Wohnzimmer hast Du mehrere Kreise, die auch verlinkt sind. Hast Du da einen hydraulischen Abgleich gemacht?

[Sevensworld]

@gargano Was meinst Du mit "Schaltpunkte beim Soll entsprechend früh machen" ?
Ich gebe nur den Sollwert vor, welche Schaltpunkte meinst Du ??

Der Hydr. Abgleich ist vor langer Zeit mal gemacht worden. Allerdings sind auf Grund des Alters der Anlage in der Zwischenzeit diverse Teile getauscht worden und ich denke der Abgleich wird mittlerweile relativ ungenau sein -.-

[Gargano]

@sevensworld Mit Schaltpunkte meine ich Änderungen vom Sollwert während des Tages /Nachts.
Hydr. Abgleich habe ich bei mir selber gemacht mittels 'Fussthermometer' . Solange den Rücklaufbegrenzer der kleineren Kreise zugedreht, bis die Temperaturen der kleinen Kreise dem des größten entsprachen.

[Sevensworld]

Alles klar, danke für die Rückmeldung.
Morgen soll es ja ein wenig kühler werden, dann werde ein wenig testen.

In der Statussicht, kann man die detaillierte Sicht anzeigen. Was sind die "Dead Counts" bzw. was sagen die aus ?

[Gargano]

@sevensworld deadcounts ist die Differenz zwischen open und close counts. Wenn das Ventil streng geht ist deadcount größer.

[Sevensworld]

Einige Ventile habe einen negativen Wert bei deadcounts und ich versuche gerade herauszufinden, ob die Antriebe auch 100% schließen. Irgendeine Idee dazu oder ist das wieder ein Denkfehler ? :-D
Mit dem Faktor High bzw. Low bei den Characteristic Einstellungen, lässt sich da noch etwas machen oder ist 1,6 bei den HM Stellantrieben das maximum?

[Gargano]

@sevensworld wenn die Deadcounts nicht allzu gross sind ist das wohl nicht weiter relevant. Ich frag mal Andreas, wie sich das mit den Deadcounts verhält, wenn ich wieder zu Hause bin. Die 1.6 sind bei den HM Ventile das Maximum. Ich hab schon erlebt, dass die Ventile abspringen. Ich hab bei mir 1.4 eingestellt und als Sicherung Schlauchschellen verwendet.

[Sevensworld]

@gargano Magst Du bei Gelegenheit mal ein Foto von der Schlauchschellenlösung machen ?
Und würdest Du ein Beispiel für die Verwendung des Xp Wertes und des Offsets geben? Ich muss scheinbar ein paar Anpassungen vornehmen, damit ich auf die gewünschten Werte komme.

Dann gibt es noch 2x den Schalter für Ventil "active".
1x auf der Control-Seite und 1x auf der Config-Seite.
Warum 2 Stück, die sich unabhängig schalten lassen ?

Grüße

[Gargano]

@sevensworld

Schlauchschelle 32-50mm
Darauf achten , daß die Schelle nicht den Auslöser runterdrückt (das geriffelte Teil)

Active auf der Control Seite ist nur für den PI-Controller zuständig. Du kannst also Ventile aus dem Regler temporär rausnehmen.
Active auf auf der Config Seite ist für alle Aktionen betreffend der Ventile zuständig.

Offset wird auf den errechneten Wert dazu addiert.

Xp ist der reziproke Wert von kp (proportionale Anteil) in der PI - Gleichung, die Heizungsbauer verwenden eher den Wert (auch Band genannt)

Falls bei einer starken Erhöhung des Sollwertes die Heizkurve 'überschießt' , muß xp größer werden, damit der Proportional Anteil kleiner wird.

[Sevensworld]

@gargano Moin und Danke für die Erklärung.
Mal sehen ob ich das richtig verstanden habe. Xp erhöhen, wenn die Räume zu warm bzw. wärmer werden, als in der Zieltemperatur vorgegeben? Und Offset wird auf die errechneten % für die Ventilstellung drauf gerechnet, könnte man also einsetzen, wenn der Raum nicht warm genug wird? Wird das nur bei >0% gemacht oder auch bei 0% = Zu?

Aktuell habe ich noch das Problem, dass die Soll-Werte, die ich per MQTT übermittle, nur mit einer sehr großen Verzögerung vom Controller angezeigt werden. Ich nutze seit gestern einen separaten MQTT Broker ( mosquitto ).
Per MQTT Explorer sehe ich die geänderten Werte sofort, aber auf der Übersichtsseite des Controllers nicht.
Was ich bereits versucht habe, ist die MQTT Config einmal auf None zu setzen, zu speichern und wieder neu zu konfigurieren, bringt aber keine Besserung.
Könnte es sein, das meine diversen Testkonfigurationen die MQTT Einstellungen "kaputt" gemacht haben? :-( , gibt es eine Art Debug Seite auf der das zu sehen ist ?

[Gargano]

@sevensworld Am besten, Du zeichnest mal die Soll/Ist und Valve% Werte über 24 Stunden auf. Wobei hier für die Regelung der Sollwert und Valve % am Wichtigsten sind. Wenn der Valve% bei einer Erhöhung des Sollwertes stark überschießt, dann den xp Wert erhöhen. Bei meinem kleinen Wintergarten habe ich deshalb den xp Wert auf 80 gesetzt.

Wenn der Raum trotz 100% Valve Wert nicht die Solltemperatur erreicht, ist Deine Vorlauftemperatur der Heizung zu niedrig.
Da gibt es auch Offset und Steigung. Wenn an warmen Tagen der Sollwert im Raum trotz 100% Valve nicht erreicht wird, dann den Offset um 1-3 Grad erhöhen. Evtl. dafür die Steigung etwas erniedrigen, wenn an kalten Tagen das Ventil stark zu macht um die Temperatur zu halten.

Der Pi -Regler sollte die Differenz bis auf wenig zur Zieltemperatur regeln. Offset braucht man evtl. nur in speziellen Fällen, habe ich aber noch nie gebraucht.

Debug geht nur über den RS232 Port X23 (115200 BD, 8 Bit , no Parity)

Du kannst mit die Einstellungen zurücksetzen.

Bei mir kommen die Änderungen von tTarget und tValue innerhalb einer Sekunde (Weil Interval auf 1000 ms gesetzt ist)

[Sevensworld]

@gargano Ich habe die Vermutung, wir schreiben ein wenig aneinander vorbei -.-
Der Sollwert ist eigentlich stabil, bzw. hat nur 2 Werte ( 1x Heizbetrieb und 1x Absenkbetrieb ), schwankt also schon mal nicht.
Das mit der Vorlauftemperatur ist klar, das mit dem Xp Wert war nur eine Verständnisfrage.

Was die MQTT Werte an geht, da hakt es allerdings ein wenig ... wenn ich den Controller auf "none" setze, dann gehe ich davon aus, das alle Verbindungen gelöst werden und auch die Subscribes alle weg fallen.
Wenn ich diese Verbindung neu herstelle, dann sollte der Controller doch auf die tTarget und tValue Variablen ein Subscribe setzen und diese auch Zeitnah bei Änderung bekommen!? Das passiert aber nicht! Ich habe heute Mittag einen Wert geändert und die Änderung war auch sofort auf dem Broker sichtbar, nur der Controller hat bis jetzt nichts davon mitbekommen.
Hast Du eine Idee wo das Problem sein könnte?
Auch habe ich bei 7 Stellmotoren die Sollwerte weg gelassen (also auf 0 ) und trotzdem hat der Controller über 100 Moves registriert.
Was ist das sinnvollste Vorgehen bezgl. der Targetwerte?
Am besten ist es, wenn die schon vor der Konfiguration vom Controller auf dem Mosquitto Broker vorhanden sind oder wenn die erst hinterher erstellt werden und sollten die einen Retain Kenner haben oder besser nicht ?

Meine Einstellungen hatte ich auf 2000ms gesetzt, aber ob nun 1000ms oder 2000ms ist sicher nicht die Problemlösung.!

Hier jetzt noch eine merkwürdige Sache. Die 3 Ventile sind zusammengefasst, trotzdem haben sie unterschiedlichen % Einstellungen !?
Wohimmer.png
Oder das hier, da ist der Istwert um 3°C höher als der Sollwert und trotzdem geht der Antrieb auf 20% ?

[Gargano]

@sevensworld Du kannst mal den Sysylog Watcher Personal runterladen.
Einstellung ist dann wir folgt :

Client IP : Die IP von Deinem PC.

Im Syslog Watcher Text auf MQTT setzen
Es sollte ungefähr so aussehen :

Nach dem Start braucht er auch eine Zeit bis er das Regeln anfängt. Bei der ersten Änderung des % Wertes wird erstmal eine Kalibrierung gefahren.

Zeig nochmal bitte die komplette Control Seite.

[Sevensworld]

@gargano Ok, danke für den Hinweis, schaue ich mir nachher an.
Auf der Config Seite gibt es die Möglichkeit zw. Static Ki und Dynamic Ki zu wählen. Wo ist der Unterschied?