Blockly zur Klimaanlagensteuerung

[paul53]

@linguist sagte: gerne selber "zusammenstecken" was du gepostet hast.

Ändere noch die Abfrage der Temperaturen, damit das Klimagerät auch einschaltet, wenn die ganze Zeit die PV-Leistung > 3000 W ist und die Temperatur erst später auf > 23°C steigt.

[linguist]

@paul53 Auf >21 gesetzt. Sollte also ab 22 an gehen.

[paul53]

@linguist sagte: Auf >21 gesetzt. Sollte also ab 22 an gehen.

Ich habe die Prüfung der Raumtemperatur vor "Ausführen delayOn" gesetzt, damit sie auch dann erfolgt, wenn die PV-Leistung schon seit einiger Zeit > 3000 W ist.

[linguist]

@paul53 Hallo Paul,

also so?

[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 )