Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Codierknecht]

@mr-kan1ster sagte in Einfache Heizungsreglung:

Falls Ventil nicht den Wert 0 oder 100 hat, setze ihn auch 0 oder 100? Den teil verstehe ich absolut nicht. Und auch nicht wieso die Objekte so lange NAmen haben und in grün sind.

1. Es wird geprüft, ob überhaupt gesteuert werden muss oder nicht.
   Wenn das Ventil bereits auf den benötigten Wert eingestellt ist, muss ja nix gesteuert werden.
   Stichwort "Funkhygiene".
2. Ich gehe davon aus, dass @paul53 hier diesen Weg lediglich gewählt hat, weil er selbst diese DP nicht hat.
   In die grünen Blöcke kann man schreiben was man will, ohne dass dieser DP existieren muss.
   In der Realität kann man natürlich auch die üblichen blauen "Wert von" nehmen.

[MartinP]

@codierknecht said in Einfache Heizungsreglung:

@mr-kan1ster sagte in Einfache Heizungsreglung:

Falls Ventil nicht den Wert 0 oder 100 hat, setze ihn auch 0 oder 100? Den teil verstehe ich absolut nicht. Und auch nicht wieso die Objekte so lange NAmen haben und in grün sind.

Es wird geprüft, ob überhaupt gesteuert werden muss oder nicht.
Wenn das Ventil bereits auf den benötigten Wert eingestellt ist, muss ja nix gesteuert werden.
Stichwort "Funkhygiene".

Das ist ja auch bei dem Code von @DJMarc75 die Intention gewesen - da wird die Verriegelung über eine Hilfsvariable gemacht

[Rico Sander]

@djmarc75 @Codierknecht

Aha, nach Verfolghung der Diskussion hier, ist der Groschen (jetzt Cent) gefallen.
Es wird also zusätzlich zur akt. Temperatur noch geprüft, welchen Zustand der Heizlüfter hat. Wenn er z.B. bereits läuft, muss er somit nicht wieder mit "steuere..." angesprochen werden; bzw. muss nicht ständig "ausgeschaltet" werden, wenn die Temperatur hoch genug ist und er eh schon aus.

Edit1 :
Was spricht eigentlich dagegen, gleich auf den Zustand des DP (Relais für Hzg an/aus) zu prüfen? Was übersehe ich da vielleicht?

Edit2:
Dagegen könnte sprechen, dass bei jeder Temp.-Änderung der Wert des DP (Zustand des Relais für Hzg) abgefragt werden würde.

Besten Dank.
VG Peter

[MartinP]

@pi-ter Den Zustand des DP muss das Skript bei ioBroker anfragen - die lokale Variable ist ihm auf kurzem Dienstweg zugänglich ...
Ich würde vermuten, ersteres ist mehr Aufwand, kann es aber nicht mit Sicherheit sagen...

[Rico Sander]

@martinp sagte in Einfache Heizungsreglung:

@pi-ter Den Zustand des DP muss das Skript bei ioBroker anfragen - die lokale Variable ist ihm auf kurzem Dienstweg zugänglich ...
Ich würde vermuten, ersteres ist mehr Aufwand, kann es aber nicht mit Sicherheit sagen...

Ja, stimmt. Das ist das, was ich mit "DP abfragen" in Edit2 im Sinn hatte. Du hast es aber korrekter formuliert.
Zeitlich gesehen dürfte der Zugriff auf die vordefinierte Variable effektiver sein, wenn gleich das in diesem Kontext vlt. eine untergeordnete Rolle spielt.

Wieder was gelernt ;-)

VG Peter

[MartinP]

@pi-ter Noch ein Gedanke zur Heizungsregelung per ioBroker: Damit wird der ioBroker zu einem Gerät mit "Missionskritischer" Zuverlässigkeit. Da habe ich mich noch nicht so ganz drangetraut, und lasse die Thermostat-Regelschleifen lokal auf einem kleinen ESP8266 rechnen. Wenn mal wirklich ein sehr strenger Frost kommt, und man ist tagelang nicht zu Hause, während der ioBroker einfriert, kann da viel kaputtgehen
ioBroker ist bei mir bzgl Heizung nur für Protokollierung, Überwachung und Nachtabsenkung zuständig ...

Hat sich aber im Nachhinein herausgestellt, dass die ESP8266 Hardware instabiler ist, als der ioBroker, und deshalb der ioBroker sehr viel zuverlässiger läuft, als der ESP8266...

[Rico Sander]

@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 ...

[Rico Sander]

@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.

[Rico Sander]

@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".

[Rico Sander]

@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.

[Rico Sander]

@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.