Einfache Heizungsreglung

[wcag22]

@martinp
Die einzige "kritische Infrastruktur" wäre bei mir in der Tat nur das "Palmenhaus" (Umhausung für eine eingepflanzte Palme im Winter). Da die Palme nun ca. 40 Jahre alt ist, wäre es echt schade drum.
Über Redundanz habe ich mir daher auch schon Gedanken gemacht, sie aber angesichts der eher milden Witterung noch nicht umgesetzt.

Zur Temperaturmessung ist ein ESP8266 D1mini im Einsatz, geschaltet wird ein Sonoff TH16, auf dem noch die Originalsoftware läuft. Dort steckt auch der Temperaturfühler dran. Angebunden ist der TH16 an ioBroker über den HAM-Adapter und eweLink-Modul.

Die Überlegung war, den TH-16 autonom als Thermostat einzusetzen und bei Unterschreitung einer zweiten Minimumtemperatur den Lüfter einzuschalten.

Nächste Überlegung war: Was ist, wenn der kleine Heizlüfter den Geist aufgibt?
Hier könnte ich über eine P11 mit Tasmota einen zweiten Heizlüfter in Reserve halten, der dann z.B. bei unter 2.5°C scriptgesteuert einspringt.

Aber was immer wir auch tun: Ohne Stromnetz und ohne WLAN, WAN, what ever nutzt uns die ganze schöne Redundanz nix. Ohne Strom auch keine Heizung...

Die einzige Sicherheit, die ich mir bei Abwesenheit noch gönne, ist ein VPN ins häusliche Netz. Da kann ich wenigstens nachsehen, ob alles passt und ggfls. aktiv werden - und zur Not die Nachbarn/Freunde alarmieren

Bei mir läuft der raspi4 4GB mit ioBroker ebenfalls total stabil und ich würde auf den auch eher setzen, als auf die D1mini, was ich aber auch noch nie getestet habe ;-).

[MartinP]

@pi-ter said in Einfache Heizungsreglung:

Bei mir läuft der raspi4 4GB mit ioBroker ebenfalls total stabil und ich würde auf den auch eher setzen, als auf die D1mini, was ich aber auch noch nie getestet habe ;-).

Damals war meine Überlegung, dass der D1 Mini oder ein ähnliches vorgelagertes Kästchen eh gebraucht wird, um die Thermosensoren, Ventile usw. anzusteuern/abzufragen.
Wenn dann ohne den ioBroker nicht wenigstens ein Notbetrieb möglich ist, hat man keinen Single Point of Failure, sondern gleich zwei davon

Der Thermostat ist aber per MQTT ansteuerbar - vielleicht braucht man auf irgendeinem alten Linux-PC einen "Not" ioBroker, wenn denn doch irgendwas geschrottet wird beim Rumbasteln mit dem "Haupt" ioBroker ...

[wcag22]

@djmarc75

Moin,
gibt es einen Grund, warum Du im oberen Zweig Deines Blockly mit doppelter Negation arbeitest?
Ich habe das mal nachempfunden und komme letztlich zum selben Ergebnis.
In beiden Fällen funktioniert die UND-Verknüpfung von temperatur und Zustand heizung; der if-Zweig wird korrekt ausgewertet

var temperatur, heizung;
temperatur = 9;
heizung = false;

if (temperatur < 10 && !heizung) {
  window.alert('doppelte Verneinung');
}

if (temperatur < 10 && heizung == false) {
  window.alert('einfache abfrage');
}

Aber müsste Blockly nicht auch ein

heizung === false

generieren? Beide Werte sind ja von gleichem Typ

[DJMarc75]

@pi-ter Mit JS kenne ich mich leider absolut nicht aus, aber @paul53 hat ja schon geschrieben dass doppeltes "steuern" in meinem Skript viel Ressourcen braucht.

Daher lieber so:

[Codierknecht]

@pi-ter sagte in Einfache Heizungsreglung:

doppelter Negation

Hilf mir mal auf die Sprünge:
Wo siehst Du da eine doppelte Negierung (Negation) ???

Doppelpost?

[paul53]

@djmarc75 sagte: lieber so:

Die beiden "und" sind überflüssig.

[wcag22]

@codierknecht
Doppelpost habe ich schon zum Löschen gemeldet.

Die Variable "heizung" ist zunächst auf "falsch" gesetzt.
"nicht heizung" heißt dann doch "nicht falsch" - also wahr.

Geprüft weden soll doch aber auf "heizung gleich falsch", damit die UND-Verknüpfung
"Temperatur zu gering && Heizung aus" zum Einschalten führt.

&& !heizung

Wo ist da mein Denkfehler?

[DJMarc75]

@paul53 sagte in Einfache Heizungsreglung:

Die beiden "und" sind überflüssig

korrekt, wieder was gelernt

[paul53]

@pi-ter sagte: Geprüft weden soll doch aber auf "heizung gleich falsch"

"nicht heizung" entspricht "heizung gleich falsch".

[wcag22]

@paul53
Danke.

Gut, ich nehm das mal so hin, weil es wohl richtig ist.
Das sieht dann aber für mich so aus, als wenn auf die Variable und nicht deren Wert geprüft wird.
Es erklärt dann aber zumindest, warum die wirkliche (?) Prüfung auf Wert - also "heizung === False" (Wert === false) auch funktioniert.

Ich komme aus der php-Ecke und ich bin mir nicht sicher, ob das da auch so gehen würde. JS war bislang nie so mein Ding.

[Codierknecht]

@pi-ter
Die "variable" wird beim Start des Script initialisiert.
Nach dem Start des Script ist sie zunächst "falsch" - da hast Du schon Recht.
Aber zur Laufzeit wird die ja auch mal "wahr". Dann wird damit unnötiges Senden verhindert.

[wcag22]

@codierknecht Danke für Deine Mühe, aber das war ja gar nicht das Problem.

Hier nochmal das komplette Blockly:

Die Wertzuweisung für die Variable "heizung"am Anfang ist klar.

Dann läuft das Script in die erste if-Abfrage.
Nur wenn beide Teilausdrücke - Temperatur <3.1, Wert der Variablen gleich "falsch" - "wahr" ergeben (UND-Verknüpfung), erfolgt die Steuerung des Relais.

Laut Blockly und auch im Code wird aber auf "nicht falsch" (!heizung) - also "wahr"geprüft.

if ((obj.state ? obj.state.val : "") < 3.1 && !heizung)

Dass dann irgendwann die Variable auf "wahr" gesetzt wird, ist an dieser Stelle zunächst nicht relevant

Wo also mache ich hier einen Denkfehler? Mir erschließt sich dieses "nicht heizung" nicht. Aber vlt. ist das ja eine Besonderheit von Blockly.

[paul53]

@pi-ter sagte: Mir erschließt sich dieses "nicht heizung" nicht.

Der nicht-Operator (Ausrufezeichen) negiert den Wert: false wird true und true wird false.

[Codierknecht]

@pi-ter
"nicht heizung" ist semantisch das Gleiche wie "heizung = falsch".

Wenn die variable "heizung" mal ein "wahr" enthält, wird der Ausdruck "nicht heizung" zu "falsch" und im ersten Block passiert ... nix.

[wcag22]

@paul53 sagte in Einfache Heizungsreglung:

@pi-ter sagte: Mir erschließt sich dieses "nicht heizung" nicht.

Der nicht-Operator (Ausrufezeichen) negiert den Wert: false wird true und true wird false.

Naja, das weiß ich. Durch php bin ich ja nicht ganz unbewandert in diesen Dingen. Immerhin läuft mein selbstgestricktes Blog schon seit Jahren.

Aber genau das ist ja mein Problem
Wenn der Wert der Variablen "falsch" ist, und ich prüfen will ob "heizung" diesen Wert hat, wieso negiere ich dann die Abfrage?
Wäre dann nicht if ( heizung === falsch) { tue was; } die richtige Wahl?

Was übershe ich?

[wcag22]

@codierknecht sagte in Einfache Heizungsreglung:

@pi-ter
"nicht heizung" ist semantisch das Gleiche wie "heizung = falsch".

Und dann ist "heizung" das Gleiche wie "heizung =wahr"?
Dann ist die Zuweisung am Scriptanfang falsch:

heizung = falsch;

Wenn die variable "heizung" mal ein "wahr" enthält, wird der Ausdruck "nicht heizung" zu "falsch" und im ersten Block passiert ... nix.

Ähm, also im ersten if-Zweig wird geprüft, ob die Variable den Wert "falsch" hat. An dieser Stelle ist ein "wahr" noch nicht in Sicht und darauf wird im ersten Zweig auch nicht geprüft.

Ausdruck "nicht heizung" zu "falsch" und im ersten Block passiert ... nix.

Das wäre aber ziemlich blöd. Die Heizung würde nicht eingeschaltet.

[Codierknecht]

@pi-ter
Du musst da zwei Dinge unterscheiden:
Die erste Zuweisung passiert ja nur 1x - beim Start des Script.
Damit wird die Variable einfach nur auf einen definierten Startwert gesetzt.

Das mit "im ersten Block passiert ... nix" habe ich vielleicht etwas unglücklich formuliert.
Es passiert dann nix, wenn dieser Block zum zweiten (oder weiteren) Mal erreicht wird. Wenn also der Trigger bereits einmal ausgelöst hat. Deswegen heißt das Ding ja auch "Sperrvariable".
Darum wird die auch beim Start auf "false" gesetzt.

Vielleicht würde ein anderer Name das klarer machen: "heizungIstAn".

[wcag22]

@codierknecht
Ist schon spät, daher nur kurz. Zunächst danke für feedback. Aber:

Bitte, über wirklich simple Dinge wie die einmalige Initialisierung der Variablen müssen wir nun wirklich nicht reden. Seit 2004 beschäftigte ich mich erst mit perl, jetzt mit php. Ich bin also in einer ganzen Reihe von Basics wirklich einigermaßen fit. Was nicht heißen soll, dass ich alles weiß und über den Dingen stehe.

Dass ich gerade in JS etliche Wissenlücken habe, weiß ich selbst. Aber der Umgang mit Variablen, Operatoren und all der anderen Logik, die in Programmen und Programmabläufen steckt ist nicht ganz neu für mich. Und ich merke immer mehr, dass sich JS nicht soo doll von php unterscheidet.

Es passiert dann nix, wenn dieser Block zum zweiten (oder weiteren) Mal erreicht wird. Wenn also der Trigger bereits einmal ausgelöst hat. Deswegen heißt das Ding ja auch "Sperrvariable".

Siehe oben. Das ist mir doch alles bekannt. Aber auf die Frage, wieso mit "nicht heizung" abgefragt wird, habe ich noch keine nachvollziehbare Antwort erhalten. Das ist für mich das Unklare. Es ist für mich unlogisch.
Und dieses Problem, was ich doch eigentlich sehr deutlich skizziert habe, wird erstaunlicherweise von allen umschifft

BTW: Diese Hzg.-Regelung hat aber noch ganz andere Schönheitsfehler. Aber da bin ich noch dran.

Einen schönen Wochenanfang Euch allen...

VG
Peter

[Codierknecht]

@pi-ter sagte in Einfache Heizungsreglung:

aber auf die Frage, wieso mit "nicht heizung" abgefragt wird, habe ich noch keine nachvollziehbare Antwort erhalten. Das ist für mich das Unklare. Es ist für mich unlogisch.

Vielleicht hab' ich einfach noch nicht verstanden, wo genau Dein Verständnisproblem liegt.
Du kannst sowohl

!heizung

als auch

heizung == false

verwenden. Das ist völlig gleichwertig. Es soll etwas passieren, wenn die Variable false ist.
Geht übrigens in PHP genauso.
Wenn Dir das Zweite besser gefällt und für Dich verständlicher ist: Nimm das.

Macht ja keinen Sinn ein Script zusammenzuklöppeln, das Du nicht sofort verstehst.

Nur um das nochmal klarzustellen: Es wird hier nicht "zweimal negiert". Das "zweimal" entsteht nur in Deinem Kopf, für den Fall dass die Variable gerade false enthält.

Für den Compiler und den Prozessor ist die erste Variante übrigens die bessere. Ein not arbeitet mit nur einem Operanden, wohingegen der Vergleich davon zwei benötigt. Es schreibt sich auch schneller und wird minimal schneller verarbeitet.
Auch in Blockly ist das einfacher, weil man nur 2 statt 3 Bausteine benötigt.

Die Variable "heizung" macht das auch etwas schwierig zu lesen.
Nehmen wir vielleicht mal sowas hier

Und nehmen wir weiter an, wir hätten das bereits in eine gleichnamige Variable eingelesen.
Dann würde das mit good old Basic oder Pascal wie folgt formuliert:

if not isDayTime

bzw.

if isDayTime = false

, wenn man prüfen möchte ob es gerade Nacht ist .Vielleicht wird so eher klar, dass beide Ausdrücke vom Sinn her gleich sind.

Will man hier prüfen, ob es gerade Tag ist, schreibt man ja auch

if isDayTime

was das Gleiche ist wie

if isDayTime = true

Ansonsten bin ich mit meinem Latein am Ende. Ich wüsste jetzt nicht, wie ich es besser erklären könnte.
Ist aber ein tolles Beispiel, welche Auswirkungen die Benennung von Variablen (und Methoden, Objekten etc.) haben kann (siehe meine Signatur).

dass sich JS nicht soo doll von php unterscheidet.

In der Syntax nicht. Aber das Konzept der Ereignissteuerung und der Asynchronität ist ja nochmal etwas anderes.
Ich komme aus der Windows-Entwicklung. JS (genauer: NodeJS) ist für mich auch noch relativ neu.
Unter Windows muss man gehörigen Aufwand treiben, um nebenläufige Prozesse sauber hinzukriegen.
Unter NodeJS ist das Standard und es braucht Kniffe, um synchron zu programmieren.

[wcag22]

@codierknecht sagte in Einfache Heizungsreglung:

Hinweis an Moderatoren: Falls die Diskussion hier zu sehr ausartet, bitte verschieben. Vlt. langweilt es ja die Profis, während andere, wie ich, was lernen wollen. - Danke.

Moin,
wow... vielen Dank, dass Du Dir nochmal die Zeit genommen hast. Jetzt kommen wir der Sache näher und dann löst sich sicher auch der Knoten im BioRam.

Vielleicht hab' ich einfach noch nicht verstanden, wo genau Dein Verständnisproblem liegt.

Das kann nich nachvollziehen

Das "zweimal" entsteht nur in Deinem Kopf, für den Fall dass die Variable gerade false enthält.

Das ist wohl das Problem. Ich weiß.
Meine Überlegung war:

Variable deklarieren:

var MeineVariable;

Ich könnte wohl auch die Deklaration mit let machen. Sie existiert nun, aber hat den Wert "undefined".

Nun weise ich der Variablen einen Wert zu:

MeineVariable = false;

Eine if-Abfrage

if ( MeineVariable == false)
// oder bei gleichen Typen
if (MeineVaraible === false

sollte also true zurückgeben, während

if (MeineVariable == true)

in diesem Fall false liefern sollte.

Und wie @paul53 sagte:

Der nicht-Operator (Ausrufezeichen) negiert den Wert: false wird true und true wird false.

müsste damit

!MeineVariable

den Wert true zurückgeben, denn MeineVariable hat ja den Wert false und das Ausrufezeichen negiert diesen Wert.

Ich wundere mich jetzt im Alter , dass mir bei php dieses Problem noch nie so aufgefallen ist. Hm....

Auch in Blockly ist das einfacher, weil man nur 2 statt 3 Bausteine benötigt.

Dieses Beispiel ist für mich insofern irritierend, da hier mit istVormittag eine Variable vorliegt, deren Name auch irreführend sein kann. Welchen Wert hat denn in diesem Beispiel die Variable? Vermutlich true
Und was, wenn sie auf false gesetzt war?

Mit dem zweiten Beispiel isDayTime liegt der Fall ähnlich.

Will man hier prüfen, ob es gerade Tag ist, schreibt man ja auch

if isDayTime

was das Gleiche ist wie

if isDayTime = true

Diese Beispiele setzen doch immer voraus, dass der Name der Variablen auch den Wert der Variablen repräsentiert. Aber zwischen Namen und Wert sehe ich schon einen Unterschied.

Vielleicht macht es gerade das aus, dass ich mich da so schwer tue mit dem geistigen Aha-Effekt.

Ansonsten bin ich mit meinem Latein am Ende. Ich wüsste jetzt nicht, wie ich es besser erklären könnte.

ja, das kann ich Dir nicht übelnehmen. Vielleicht bin ich ein rettungsloser Fall.

Ok, wenn es für meinen Knoten im Kopf keine bessere oder überhaupt eine Erklärung gibt, bin ich damit einverstanden, diese Diskussion zu beenden.

Ist aber ein tolles Beispiel, welche Auswirkungen die Benennung von Variablen (und Methoden, Objekten etc.) haben kann (siehe meine Signatur).

Yepp

dass sich JS nicht soo doll von php unterscheidet.

In der Syntax nicht. Aber das Konzept der Ereignissteuerung und der Asynchronität ist ja nochmal etwas anderes.

Ok, das habe ich befürchtet aber so weit bin ich noch nicht.

In meiner ganzen Weblaufbahn habe ich mich immer vor JS gedrückt, auch aus Gründen der sogenannten Barrierefreiheit. Nun muss ich mich halt damit beschäftigen.

Ich danke Dir für die Zeit, die Du investiert hast.

VG Peter