Blockly zur Klimaanlagensteuerung

[paul53]

@linguist sagte: also so?

Nicht ganz: Das Einlesen der Temperatur in die Variable roomTemp muss vor deren Auswertung erfolgen - also ganz oben im Trigger.

[linguist]

@paul53 Pardon, übersehen, jetzt müsste es aber passen.

[paul53]

@linguist sagte: jetzt müsste es aber passen.

Ja. Ich würde für den Fall, dass sich die Temperatur innerhalb von 10 Minuten von < 19°C auf >= 19°C erhöht, den Grenzwert zwischen Heizen / Kühlen etwas höher setzen, damit in diesem Fall nicht gekühlt statt geheizt wird.

[linguist]

@paul53 Erledigt. Die erste Abfrage hab ich zu Testzwecken auf 20 gestellt. Kommt wieder auf 19.

Deine Hilfestellung ist wirklich der Wahnsinn. Danke dafür.

[linguist]

@paul53
Hallo Paul, um das ganze nochmal kurz hoch zu holen:
Spricht etwas dagegen um das ganze Script noch einen Zeitplan zu legen? Etwa dass bei manueller Bedienung und 0kW das Script nicht "abschalten" feuern würde (zb Nachts)? )?

Grüße

[paul53]

@linguist sagte: Spricht etwas dagegen um das ganze Script noch einen Zeitplan zu legen?

Ja: Trigger innerhalb von Triggern (Zeitplan) funktioniert nicht.

@linguist sagte in Blockly zur Klimaanlagensteuerung:

dass bei manueller Bedienung und 0kW das Script nicht "abschalten" feuern würde (zb Nachts)?

Innerhalb des Skriptes kann ein Datenpunkt "Manuell Ein" abgefragt werden, der das Abschalten verhindert.

[linguist]

@paul53 Muss ich mir mal anschauen wie ich einen solchen Datenpunkte sinnvoll realisieren kann.

Danke dir!

[paul53]

@linguist sagte: einen solchen Datenpunkte sinnvoll realisieren kann.

Man kann auch eine Variable manuell_ein verwenden, in der detektiert wird, dass das Einschalten nicht durch ein Skript erfolgte.

[linguist]

@paul53 Es kann so einfach sein. Ich wäre einen ganz anderen Weg gegangen. Danke dir.
Aber wo genau wird die Variable "Ursprung" verarbeitet?

[paul53]

@linguist sagte: Variable "Ursprung"

"Ursprung" findet man wie "Wert" unter "Trigger".

[linguist]

@paul53 ich habe falsch gefragt, aber mir die Frage anhand eines anderen deiner Postings selber beantworten können. Ich hatte die Funktionsweise nicht ganz verstanden da der Ursprung in deinem Beispiel gesetzt wird, aber im vorherigen Verlauf nirgends abgefragt wird.

Aber kurz gegoogled, auf einen Beitrag von dir gestossen und alle Fragen beantwortet.

[paul53]

@linguist sagte: da der Ursprung in deinem Beispiel gesetzt wird

Wo?
Er wird vom Trigger geliefert.

[linguist]

@paul53 Nirgends, ich dachte es wäre so. Aber manuell_ein wird ja nur auf true gesetzt, wenn der Ursprung NICHT js war.

Wie gesagt, komplett falsch ausgedrückt.

Edit: das macht immernoch vorne und hinten kein Sinn was ich gerade zusammen schreibe. Einfach ignorieren. Ich glaube ich habe es verstanden, kann es bloss gerade nicht zu Wort bringen.

[linguist]

@paul53 Okay, muss jetzt dezent peinlich berührt doch nochmal einhaken. Ich hab's nicht verstanden.

Falls PowerKlima geändert wird, setze manuell_auf Wert von PowerKlima und Ursprung auf ≠ js.

Soweit so gut, aber für was ist Ursprung nun gut? Wir setzen den Ursprung ≠ js, aber inwiefern ist diese variable im Rest des Scripts relevant?
Wie ich das verstehe wird nun bei jeder Änderung manuell_ein auf Wert PowerKlima und Ursprung ≠ js gesetzt, sei es drum ob diese Änderung durch manuelle Bedienung oder durch das obige Script erstellt wurde.

Weitere Verständnisfrage:
Trigger1 ->

• falls nicht true (also false) mache Programm

• falls nicht false (also true) mache Programm

Stehe gewaltig auf dem Schlauch und mein Logikverständnis ist anscheinend nicht vorhanden.

[paul53]

@linguist sagte: für was ist Ursprung nun gut?

Ursprung enthält die Instanz, die zur Wertänderung führte. Hat das Skript das Klimagerät eingeschaltet ist Wert = true und Ursprung = "system.adapter.javascript.0": manuell_ein bleibt false. Hat eine andere Instanz (z.B. "melcloud.0") eingeschaltet (Wert = true) , wird manuell_ein auf true gesetzt.

@linguist sagte in Blockly zur Klimaanlagensteuerung:

Weitere Verständnisfrage:
Trigger1 ->
falls nicht true (also false) mache Programm
falls nicht false (also true) mache Programm

falls nicht false mache Programm
Bei true wird nichts ausgeführt.

[linguist]

@paul53 okay soweit verstanden, aber würde nun der UND Baustein nicht dafür sorgen dass bei jeder Änderung Ursprung ≠ js gesetzt werden würde?

Wäre nicht FALLS Ursprung ≠ js setze manuell_ein auf true richtig? (Ist es natürlich nicht, sonst hättest du es so gemacht, ich versuche es bloss zu verstehen )

[paul53]

@linguist sagte: Ursprung ≠ js gesetzt werden würde?

Ursprung wird nicht gesetzt, sondern geprüft.
manuell_ein wird nur true, wenn Wert = true (eingeschaltet) und der Ursprung der Wertänderung kein Skript ist.

[linguist]

@paul53 ich hätte angenommen diese Prüfung findet vorher statt. Also falls Ursprung ≠ js setzte manuell_ein auf Wert.
Jetzt habe ich es aber verstanden.

Warum diese Prüfung aber nicht als erstes stattfindet hab ich immernoch nicht drinnen. Aber das ist auch unwichtig. Vielen Dank wieder mal deine Geduld.

[linguist]

@paul53 und schon wieder ich.

Da ich jetzt die Tage ein Smart Meter erhalte und damit dann mehr Werte zur Verfügung habe als Current Plant Generation, wäre die Frage ob man dann "Überschuss" als Trigger nimmt. Allerdings weiss ich nicht wie ich sinnvoll eine Abschaltbedingung erstellen kann, da Überschuss im Moment des zuschaltens ja sinkt.
Evtl. Bezug? Mit einem Gerät mag das alles noch Recht einfach sein, aber besonders wenn es mehrere Geräte werden kann das schon Recht kompliziert werden vermute ich.

Macht das also Sinn auf Überschuss-Trigger umzustellen? Oder doch lieber auf Current Plant Gen bleiben?

Grüße

[paul53]

@linguist sagte: Macht das also Sinn auf Überschuss-Trigger umzustellen?

Ja, denn der Überschuss ist aussagekräftiger.

@linguist sagte in Blockly zur Klimaanlagensteuerung:

wie ich sinnvoll eine Abschaltbedingung erstellen kann

Genauso wie bisher, nur mit dem Unterschied, dass die Hysterese größer sein muss als die Leistungsaufnahme des Klimagerätes. Wie hoch ist die max. Leistungsaufnahme?