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

[Codierknecht]

@mr-kan1ster
Im Expertenmodus siehst Du rechts neben dem Objekt einen Stift.
Darauf klicken und dann die "Objektdaten" hier posten. In Code-Tags </> !!!

[Wildbill]

@mr-kan1ster Wenn Du ganz oben links mal auf den Kopf klickst und den Expertenmodus einschaltest, erscheint hinten beim Wert noch so ein Bleistiftsymbol. Da klickst Du mal drauf und zeigst das hier. Dann sieht man, woraus das Objekt besteht.
Anschließend den Expertenmodus aber SOFORT wieder ausschaten!

BTW: Je früher Du anfängst, die Leerzeichen aus allem zu verbannen, desto weniger Aufwand hast Du später, das in allen Scripten, VIS usw. geradezuzehen. Also auch am Besten sofort.

Gruss, Jürgen

EDIT: Ich sehe, der Datenpunkt hat vorne kein Leerzeichen, sondern einen Unterstrich. Das wäre dann auch OK!

[Codierknecht]

@Mr-Kan1ster
Grundsätzlich gilt: Leer- und Sonderzeichen sind böse (Ausnahme: Unter- und Bindestrich).
Umlaute sind ganz ganz böse.

Das gilt für Objekt-ID's und auch für Variablen- und Methodennamen bei der Programmierung (dort ist wieder der Bindestrich böse - also gleich wieder vergessen).

[paul53]

@mr-kan1ster
Du vergleichst den Sollwert mit einem Objekt - nicht mit einem Zahlenwert.
Außerdem sollte ein Zweipunkt-Regler immer eine Hysterese haben, damit im Grenzbereich nicht ständig geschaltet wird.

Spoiler

<xml xmlns="https://developers.google.com/blockly/xml">
 <variables>
   <variable id="(@L{1Dm:]ck~khb(y:~y">Solltemp Kind2</variable>
   <variable id="${wtJ;M#@9#.+s)/(.Hx">ventil</variable>
 </variables>
 <block type="variables_set" id=":zeA?20y*Tg3gh6l`#XY" x="-563" y="-612">
   <field name="VAR" id="(@L{1Dm:]ck~khb(y:~y">Solltemp Kind2</field>
   <value name="VALUE">
     <block type="math_number" id="}{p#)E;:IVfY|{NKnc0P">
       <field name="NUM">22</field>
     </block>
   </value>
   <next>
     <block type="variables_set" id="Ig]Ov_oVEUU#_nZgDIyD">
       <field name="VAR" id="${wtJ;M#@9#.+s)/(.Hx">ventil</field>
       <value name="VALUE">
         <block type="get_value_var" id="T60^gU|A4%nl{o3s%*Pd">
           <field name="ATTR">val</field>
           <value name="OID">
             <shadow type="field_oid" id="D?j8qM[*:~kmXTt9z`,Q">
               <field name="oid">Object ID</field>
             </shadow>
             <block type="text" id="|0ONG0BC|O]~[gsq]!X:">
               <field name="TEXT">openknx.0.Kinderzimmer_2.Heizung_Kind_2.schaltende_Stellgröße_Kind2</field>
             </block>
           </value>
         </block>
       </value>
       <next>
         <block type="on" id="+@5PayeP*}[`W31?Hn9m">
           <field name="OID">openknx.0.Kinderzimmer_2.Heizung_Kind_2.Isttemperatur_Kind2</field>
           <field name="CONDITION">ne</field>
           <field name="ACK_CONDITION"></field>
           <statement name="STATEMENT">
             <block type="controls_if" id="UJBeFU58ERJkbQ]G#7zS">
               <mutation elseif="1"></mutation>
               <value name="IF0">
                 <block type="logic_compare" id="@_YREWj:WhZ0.UT#cR6d">
                   <field name="OP">LT</field>
                   <value name="A">
                     <block type="on_source" id="Jc5_X=JfO?o:s3-dx6%(">
                       <field name="ATTR">state.val</field>
                     </block>
                   </value>
                   <value name="B">
                     <block type="variables_get" id="t7Gy8=I2]G.0|MAwe-)k">
                       <field name="VAR" id="(@L{1Dm:]ck~khb(y:~y">Solltemp Kind2</field>
                     </block>
                   </value>
                 </block>
               </value>
               <statement name="DO0">
                 <block type="variables_set" id="hG=Flo5WG*wOekv|/npx">
                   <field name="VAR" id="${wtJ;M#@9#.+s)/(.Hx">ventil</field>
                   <value name="VALUE">
                     <block type="math_number" id="VScSGUvke6=C4GFD/kzX">
                       <field name="NUM">100</field>
                     </block>
                   </value>
                 </block>
               </statement>
               <value name="IF1">
                 <block type="logic_compare" id="z%a^kJ{GZ0j@$k44[p-q">
                   <field name="OP">GTE</field>
                   <value name="A">
                     <block type="on_source" id="9s,}5N8J41sEGO#XdH7;">
                       <field name="ATTR">state.val</field>
                     </block>
                   </value>
                   <value name="B">
                     <block type="math_arithmetic" id="h8fIk@.[et~ZH]|}+eg)">
                       <field name="OP">ADD</field>
                       <value name="A">
                         <shadow type="math_number" id="{}alCLNT6Htf{jzb#P(V">
                           <field name="NUM">1</field>
                         </shadow>
                         <block type="variables_get" id="CS(=!J=$V?H^Ht/}-;MI">
                           <field name="VAR" id="(@L{1Dm:]ck~khb(y:~y">Solltemp Kind2</field>
                         </block>
                       </value>
                       <value name="B">
                         <shadow type="math_number" id="]ri{sIm3E/1%DR(.[}]q">
                           <field name="NUM">0.5</field>
                         </shadow>
                       </value>
                     </block>
                   </value>
                 </block>
               </value>
               <statement name="DO1">
                 <block type="variables_set" id="4X:gNIjPO+XZdt4xzXFP">
                   <field name="VAR" id="${wtJ;M#@9#.+s)/(.Hx">ventil</field>
                   <value name="VALUE">
                     <block type="math_number" id="ykWReqRYOeReqcXFl~*9">
                       <field name="NUM">0</field>
                     </block>
                   </value>
                 </block>
               </statement>
               <next>
                 <block type="controls_if" id="qV70I!OxDm2N2Q,nhaq4">
                   <value name="IF0">
                     <block type="logic_compare" id="w{k^gDE)CH7|_*$UVL$!">
                       <field name="OP">NEQ</field>
                       <value name="A">
                         <block type="variables_get" id="Y_YAv#,[Cb8WrRiahZ.5">
                           <field name="VAR" id="${wtJ;M#@9#.+s)/(.Hx">ventil</field>
                         </block>
                       </value>
                       <value name="B">
                         <block type="get_value_var" id="C9GoY#9QEp(V;_7UCJ*g">
                           <field name="ATTR">val</field>
                           <value name="OID">
                             <shadow type="field_oid" id="D?j8qM[*:~kmXTt9z`,Q">
                               <field name="oid">Object ID</field>
                             </shadow>
                             <block type="text" id="?b!A^SG4=jh]031(0YOa">
                               <field name="TEXT">openknx.0.Kinderzimmer_2.Heizung_Kind_2.schaltende_Stellgröße_Kind2</field>
                             </block>
                           </value>
                         </block>
                       </value>
                     </block>
                   </value>
                   <statement name="DO0">
                     <block type="control" id="{[cGXUC!mAzH}G{cNBw]">
                       <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation>
                       <field name="OID">openknx.0.Kinderzimmer_2.Heizung_Kind_2.schaltende_Stellgröße_Kind2</field>
                       <field name="WITH_DELAY">FALSE</field>
                       <value name="VALUE">
                         <block type="variables_get" id="PJN`IJrhZH{c;(-E+)/c">
                           <field name="VAR" id="${wtJ;M#@9#.+s)/(.Hx">ventil</field>
                         </block>
                       </value>
                     </block>
                   </statement>
                 </block>
               </next>
             </block>
           </statement>
         </block>
       </next>
     </block>
   </next>
 </block>
</xml>

[Rico Sander]

@mr-kan1ster
Meine einfache Zweipunktregelung sieht so aus:

Wenn die Temperatur unter 3.1°C sinkt, schalte Heizlüfter ein.
Steigt sie auf über 3.6°C schalte Heizlüfter ab.

Die gewählten Temperaturen gewährleisten im Zusammenhang mit der thermischen Trägheit des Raumes, dass das System nicht anfängt zu schwingen.

[Codierknecht]

@pi-ter
Du solltest dann aber "Wert" nehmen und nicht den Wert noch 2x lesen.

[Rico Sander]

@codierknecht
ah, ok... danke für den Tipp.

[MartinP]

@pi-ter Ich arbeite bei meinem Regler mit einer Hysterese von +/- 0,15°C um die Solltemperatur, also 0,3 Grad Schwankungsbreite. Auch das ist mir eigentlich zu viel. Wenn sich die Temperatur im Raum der Einschaltschwelle am unteren Rand der Hysterese nähert, fange ich auch an zu frösteln... Vielleicht bin ich auch eine Frostbeule ...

Da der Regler als "Spezial Firmware" eines ESP8266 D1 Mini läuft, habe ich die Solltemperatur und die Hysterese (+/-) als Datenpunkt herausgeführt, weil ich auch Angst vor Schwingungen hatte, und deshalb schnell eingreifen wollte, ohne gleich eine neue Firmware in den ESP hochladen zu müssen ..

"Schwingungen" habe ich nicht beobachtet ... kommt aber wahrscheinlich auch auf den Temperatursensor an. Ich habe einen im Metallröhrchen konfektionieren DS18B20 im Einsatz. (Shelly https://www.pollin.de/p/shelly-temperatursensor-ds18b20-591021)

Wenn der Sensor stärker schwankende Temperatur-Messwerte bei eigentlich gleichbleibender Temperatur zeigen würde ("Rauschen") müsste man natürlich die Hysterese weiter, als das Rauschband des Sensors stellen...

Schwing-Probleme habe ich nicht...

[DJMarc75]

@pi-ter kuck mal :)

[paul53]

@djmarc75 sagte: kuck mal

Das verhindert zwar unnötiges Senden, verwendet aber zweimal die sehr komplexe Funktion "steuere" für den selben DP.

[Rico Sander]

@djmarc75
Das sieht nach einer ziemlich ausgeklügelten Lösung aus, ich verstehe nur nicht, was daran einfacher/besser/effektiver ist als mein (nach @Codierknecht 's Vorschlag geänderter) Wenigzeiler.

Dass man die Werte des Sensors nicht mehrfach lesen muss, habe ich verstanden. Das ist einleuchtend.
Für mich sieht Dein Beispiel recht aufwändig aus.
Kläre / klärt mich auf :-)

VG
Peter

[MartinP]

@paul53 "steuere" sollte man schon verwenden, wenn es darum geht, dass die Änderung auch im Gerät ankommt... Nur wenn es egal ist, ob das Gerät auch den Wert bekommt, reicht auch ein "aktualisiere"... Bei jedem "wurde geändert" Trigger wird ja maximal ein "steuere" Aufruf auch wirklich durchlaufen.

Wird doch hier diskutiert https://forum.iobroker.net/topic/5787/blockly-unterschied-zwischen-steuere-und-aktualisiere

Der Komplexitäts-Unterschied auf Javascript-Ebene ist jedenfalls nicht besonders groß wenn man sich den erzeugten Code so anschaut ...

Hier ein "aktualisiere" Block (Wert auf false, Bestätigt auf true)

setState('0_userdata.0.Heizung.Nachtabsenkung' /* Nachtabsenkung */, false, true);

Und hier eine "steuere" Block (Wert auf 18.7, Bestätigt durch implizite Parametrierung auf false (darum muss sich das Gerät kümmern)

setState('mqtt.0.thermostat.desired.temperature' /* thermostat/desired/temperature */, 18.7);

[DJMarc75]

... hier stand Quatsch :)

[MartinP]

@djmarc75 Ist die Frage, ob ich @paul53 richtig verstanden habe.
Aber auch wenn der "steuere" Aufruf schon einige Abläufe auslöst ist das "steuere" hier unvermeidlich

[Homoran]

@martinp sagte in Einfache Heizungsreglung:

"steuere" sollte man schon verwenden

ds wurde ja auch nicht angezweifelt. Nur die unnötige zweifache Verwendung!

[paul53]

@martinp sagte: "steuere" sollte man schon verwenden

Richtig, aber möglichst nur einmal pro DP innerhalb einer Callback-Funktion.

[MartinP]

@paul53 Das ist doch so... bei jedem Durchlauf des Skriptes wird ja nur maximal einer der beiden Zweige "falls" oder "sonst falls" durchlaufen... maximal wird das "steuere" im "falls" Zweig durchlaufen, oder das im "sonst falls" Zweig.
NIE in einem Durchlauf beide!

Die meiste Zeit wird wahrscheinlich bei einem Durchlauf durch die zusätzliche Abfrage der Hilfsvariable sogar gar kein "steuere" Aufruf erfolgen ...

[paul53]

@martinp sagte: Das ist doch so...

Ja, auf die CPU-Last hat es keinen Einfluss, aber jeder Funktionsaufruf belegt RAM. Was meinst du wohl, weshalb ioBroker solch ein RAM-Fresser ist?

[MartinP]

@paul53

aber jeder Funktionsaufruf belegt RAM. Was meinst du wohl, weshalb ioBroker solch ein RAM-Fresser ist?

Naja, das Anlegen einer Hilfsvariable, um unterhalb des Auskasperns, was denn nun gemacht werden soll nur EINEN Aufruf von SetState statt ZWEIEN zu generieren frisst auch Speicher ...

Ich bin aber nicht so fit im Abschätzen des Speicherbedarfs eines Funktionsaufrufes in Javascript - kann mir aber EIGENTLICH nicht vorstellen, dass die modernen Javascript Engines noch bei solchen simplen Dingen wie Funktionsaufrufen bereits beim Anlegen des JIT-Codes so viel Speicher fressen....

Bei C++ würde ich sagen "Bullshit" ...

Noch ein kleiner Einwand am Rande ....

Wenn man minimalen Speicherbedarf haben will, sollte man Blockly nicht verwenden...

Ein Beispiel:

Javascript Code dazu:

schedule("0 13 19 * * *", async () => {
  setState('sonoff.0.Bewaesserung.POWER' /* Bewaesserung POWER */, true);
  setStateDelayed('sonoff.0.Bewaesserung.POWER' /* Bewaesserung POWER */, false, 35000, false);
});

Codegröße des ganzen Scripts 214 Byte

Der Minifier von DigitalOcean macht daraus 140 Byte...

https://www.digitalocean.com/community/tools/minify

schedule("0 13 19 * * *",(async()=>{setState("sonoff.0.Bewaesserung.POWER",!0),setStateDelayed("sonoff.0.Bewaesserung.POWER",!1,35e3,!1)}));

Macht man die komischen Kommentare, die Blockly da hineinwirft weg, kommt man auch durch "Handoptimieren" auf 164 Byte

schedule("0 13 19 * * *", async () => {
  setState('sonoff.0.Bewaesserung.POWER', true);
  setStateDelayed('sonoff.0.Bewaesserung.POWER', false, 35000, false);
});

Ich kaufe mir lieber einen RAM-Riegel mehr, statt mir Gedanken um 140 vs 214 Bytes zu machen ;-)

[paul53]

@martinp sagte: Codegröße des ganzen Scripts 214 Byte

Wie stellst du die Codegröße fest?