Einfache Heizungsreglung

[wcag22]

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

[MartinP]

@paul53 Die sagt mir https://www.digitalocean.com/community/tools/minify wenn ich den Quellcode dort hin kopiere...
Die Aussage ist aber in Zeiten von JIT und ähnlichen Tricks mit Vorsicht zu genießen.
Als Javascript noch ein reiner Interpreter war, sah das noch anders aus ...

[Mr.Kan1ster]

@paul53 Ich habe eiiinige andere Themen gelesen und irgendwann tatsächlich gehofft "hoffentlich löst dieser Paul auch einfach mein Problem"

Ich weiss das ich dadurch wenig lerne, aber aktuell sitzt mir meine Frau im Nacken die in Ihrem temporären Büro (aka 2.Kinderzimmer) kalte Füße bekommt

@Wildbill
Ich hab diesen Expertenmodus Kopf gefunden, den Bleistift am Wert danach jedoch nicht. Aber wie es aussieht braucheich den auch nicht mehr.

@Codierknecht
Ich werd mich mal dran setzen und ETS dementsprechend durchgehen. Wie ihr ja schreibt, je länger ich warte desto mehr arbeit wird es.

Und danke auch an all die anderen Anteworten, das scheint hier sehr viel angenehmer zuzugehen als drüben im KNX User Forum

Ich teste Das Skript jetzt mal bis morgen abend und dann guck ich mal was im Bus so los war und wie war das zimmer ist.

[Codierknecht]

@mr-kan1ster sagte in Einfache Heizungsreglung:

aktuell sitzt mir meine Frau im Nacken

Da ist er wieder - der "WAF"

[Mr.Kan1ster]

@paul53
Das Zimmer ist heute morgen gemütlich warm auf 22°. Ich danke dir vielmals.
Aber jetzt zum Verstädndnis, was machen die grünen Bausteine?

Ich lese das so:
Setze die neue Variable "Ventil" auf den Wert den das Objekt schaltende Stellgröße hat. Also 0 oder 100.
Dann Temp Abgleich und auf oder zu drehen.
Und dann ?
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.

Wenn du mir das noch ganz kurz erläutern würdest könnte ich das auch das 1. Kinderzimmer übernehmen.

[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

[wcag22]

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

[wcag22]

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