Ja Thomas, an eine solche PWM-Steuerung dachte ich auch bereits, habe mich aber noch nicht genauer mit einer möglichen Implementation befasst.
Als Steuerung ist sie simpel, aber als Temperatur-Regelung erscheint mir sie nicht trivial.
Ich werde gelegentlich genauer darüber nachdenken. 
Ich arbeite ja auch an einer besseren Regelung, was auch in der Doku dargelegt ist.
Zugegeben ist die Regelung mit einem solchen Stellantrieb nur mit Temperaturschwankungen möglich, was ich aber eher für gesund halte.
Das von mir neu entworfene Verfahren, was ich noch im Skript einbauen muss, wird voraussichtlich die Einschaltdauern der Pulse so nachführen, dass die Temperaturschwankungen kleiner gehalten werden.
Unsere bisherigen Erfahrungen mit der schlichten Zweipunktregelung hat sich trotzdem sehr bewährt, weil die Zieltemperatur im Vergleich zu herkömmlichen, mechanischen Thermostaten erheblich zielgenauer gehalten wird und wir auf diese Weise bereits deutlich Heizkosten einsparen konnten. Dies wird auch durch die leichte Fernbedienbarkeit und Überwachungsmöglichkeit der Regelung unterstützt.
Auch meine alte Implementation mit Shelly 1 (Gen. 1), AddOn und Node-RED Flows hat sich bestens bewährt. Allerdings kann meine alte Lösung nicht autark arbeiten.
Der Antrieb verfügt über einen 230V Motor. Er wird schlicht ein- oder ausgeschaltet.
Im eingeschaltete Zustand öffnet er das Ventil, was bis zum vollständigen Öffnen ca. 6 Minuten dauert. Im spannunglosen Zustand schließt er das Ventil.
Eine Zwischenstellung kann nicht gehalten werden. Man kann somit nur über die Einschaltdauer den Wärmefluss steuern/regeln.
Nun ein Bild davon:
Das Teil kostet ca. 15 Euro.
Hast du meine Doku zu meiner Konstruktion gelesen?
Btw, diese Regelung ist der alten, rein mechanischen haushoch überlegen.
Nach anfänglicher Zufriedenheit mit den TRV ist diese, meine Zufriedenheit, inzwischen etwas eingeschränkt.
Vorteile:
Nachteile:
Die Nachteile nahm ich als Grund zur Entwicklung eines Thermostats auf der Grundlage eines Shelly Plus 1, AddOn, Sensor(en), einem einfachen Stellantrieb für das Ventil, zweier Mikrotaster zwecks einfacher Zieltemperatureinstellung und einem Skript.
Das Skript implementiert die Temperaturregelung ohne Erfordernis einer Umgebung.
Die Taster stehen für eine simple Änderung der Zieltemperatur zur Verfügung - bspw. in 0.5°C Schritten.
Das Skript regelt die Temperatur per Ein- und Ausschalten des Stellantriebs.
Zusätzlich kommuniziert (optional) das Skript per MQTT und es liefert insbesondere eine informative und interaktive Webseite mit aktuellen Daten und teilweise einstellbaren Wochenplänen.
Zwei Nachteile will ich nicht verschweigen.
Solange die IT-Infrastruktur arbeitet, kann das Gerät selbstverständlich dort eingebunden sein und vieles mit den Daten, einem Dashboard ... angefangen werden. Die Autarkie und deren Nutzbarkeit ist eines meiner wesentlichen Ziele, was erreicht wurde. Viele Tests haben bisher eine hohe Stabilität meiner Anordnung gezeigt. Dieses so zusammengestellte Gerät ist dazu geeignet, einen TRV komplett zu ersetzen. Es arbeitet zugleich autark und ist bei Ausfall der IT-Infrastruktur über seinen AP erreichbar und somit nutzbar.
Wem dies alles evtl. zusagt, dem kann ich meine Dokumentation + herunterladbarem Skript empfehlen, was hier zu finden ist:
https://iotig.eichelsdoerfer.net/index.php/loes…r-shelly-script
request.query kann man auch direkt parsen, wenn der Parameter/Query im JSON Format vorliegt.
Gegenwärtig versuche ich das fetch API zu verstehen.
Damit soll man das gleiche erreichen können, mit sehr viel kürzerem Code, was hier optimal wäre.
Aber ich habe es noch nicht so recht verstanden.
Hm, damit werde ich mich bei Muße und genügend Zeitreserve mal beschäftigen.
Danke für die Hinweise.
Zu deinem Beispielcode auf meine Frage hin - also AJAX.
Gibt es einen besonderen Grund, warum du die Methode POST gewählt hast?
Ich habe selbstverständlich den body Inhalt im Skript verwendet, aber ein JSON Parameter ginge ja auch per GET.
Mein Projekt Shelly Plus 1 mit AddOn und Webseite per Skript hat Fortschritte gemacht.
Nun werden alle vorgesehenen Schedule Jobs angezeigt und der Anwender kann die Daten jedes Jobs ändern.
Nur die automatische Aktualisierung eine Sekunde nach einer Job Änderung tut es noch nicht, was beim ad hoc verändern der Zieltemperatur bereits geht.
Vielen Dank an @De kat, der mich teilweise dabei unterstützt hat.
Der Screenshot zeigt oben die Auswahl der regelmäßigen Aktualisierungen nach Bedarf.
Die obere Tabelle enthält die aktuellen Daten, worin man die Zieltemperatur ad hoc ändern kann - per Pfeil/Dreieck Symbole.
In die dort noch leeren Tabellenfelder will ich noch zusätzliche Informationen einbauen.
Die untere Tabelle zeigt die eingerichteten Wochenpläne als Schedule Jobs.
Unten kann man Werte eines Wochenplans ändern. Dazu ist mindestens die Nummer (Id) des Schedule Jobs einzutragen bzw. auszuwählen.
Optional können dazu der Zustand der Aktivität (enable) die Uhrzeit und die Zieltemperatur festgelegt werden.
Bleiben Uhrzeit- oder Zieltemperatur-Felder unbearbeitet, so bleiben die bisher eingestellten Werte erhalten.
Es wird also nur das geändert, was der Anwender entsprechend wählt bzw. einträgt.
Diese Webseite wird komplett vom Shelly per Skript geliefert, ohne irgendein zusätzliches System.
Ob ich ein Ausklappen der Wochenpläne implementiere(n kann), weiß ich noch nicht.
Jedenfalls ist auf diese Weise der Shelly zur Temperaturregelung an Heizkörpern bestens geeignet und insbesondere autark.
Für die Nutzung der Wochenpläne braucht der Shelly allerdings nach jedem Reboot eine Synchronisierung per NTP Server.
Andernfalls können die Wochenpläne nicht funktionieren.
Die ad hoc Einstellung der Zieltemperatur gelingt auch ohne Zeitsynchronisation und dies auch per zwei am AddOn angeschlossenen Mikrotastern.
Für Letzteres habe ich ursprünglich mit dieser Website per Skript begonnen.
Mal sehen, was mir dazu noch gelingen wird.
Wenn ich das Projekt abgeschlossen habe, will ich es an anderer Stelle ausführlicher dokumentieren.
Soeben fiel mir auf, dass ich die Wochentage zu einem Wochenplan noch nicht editierbar gemacht habe. Das werde ich in Kürze noch einbauen.
Edit:
Ich habe zuvor noch nie etwas mit AJAX codiert. Es ist spannend. Mal sehen, wie damit die Aktualität der Shelly-Anwendungsdaten zu realisieren ist. Ich bin zuversichtlich. @De kat hat mir Code mit AJAX bereitgestellt, den ich nach Recherche allmählich so durchdringe, dass ich eigenkreativ werden kann. Die zeitlichen Verzahnungen sind hier wesentliche Aspekte. Sowohl auf dem Shelly als auch im Browser. Damit sollte die Usability gesteigert werden können - alles, solange der Shelly Speicher ausreicht, was er bisher tat.
Edit 2: Stand 2023-12-20
Das Skript, welches die interaktive Webseite nach obiger Abbildung liefert, läuft vermutlich sehr stabil.
Leider gibt es Probleme mit dem RAM, wenn ich im Editierbereich - in der Abbildung ganz unten - noch die Wochentage zum anklicken hinzufüge.
Wir, @De kat und ich, arbeiten daran.
Notfalls muss hierbei die Editierbarkeit der Wochentage entfallen.
Auch so arbeitet das Skript bereits recht anwendungskomfortabel und bietet mehr als ich mir anfangs vorzustellen vermochte.
Immerhin kann es auch dann genutzt werden, wenn das WLAN komplett ausfällt und der Access Point des Shelly genutzt wird.
Genau das war und ist mein Ziel. Nur so kann mein Projekt komplett einen TRV ersetzen und mehr als letzterer Stabilität bieten.
Edit 3:
Ein Behelf kann darin bestehen, dass man mit einem anderen Mittel, bspw. auf tools.eichelsdoerfer.net zu finden, bestimmten Schedule Jobs bestimmte Wochentage zuordnet und dann mit meiner bisherigen Implementation in solchen Jobs die Zeiten und Zieltemperaturen einstellen kann. Das dürfte für die allermeisten Fälle vollkommen genügen.
Das ist interessant und neu für mich. Ich habe lange nicht mehr meinen Tasmota32-Geräten gearbeitet.
Wenn ich meine Zisternenmesslösung neu zusammenstellen werde, schau ich da mal genauer hin.
Ein wenig geben die Rules ja auch her, was Timer und die Tagesminuten betrifft.
Ich habe mir eine Kommunikation zwischen den Rules und Berry-Funktionen teilweise ausgeklügelt.
Das geht auch sehr gut. Dann ist anscheinend Berry noch gewachsen.
Ich finde, dass das Shelly Scripting sehr viele und gute Möglichkeiten mitbringt, welche allerdings erst zu ergründen sind.
Anfangs störte mich bspw., dass man keine Includes zur Verfügung hat, um ein Projekt auf mehrere Skripts verteilen zu können - der besseren Übersicht wegen.
Man kann aber per auslösen von Ereignissen durchaus Skript übergreifend kommunizieren lassen, was ich anfangs nicht wusste.
Entscheidend ist, dass man sich auf das Eventhandling einlässt.
Die Nutzung des KVS ist bestens für anwendungsbezogene Konfiguration geeignet.
Dass ich ein Fan der Schedule Jobs bin, ist vermutlich hinlänglich bekannt.
Die Firmware internen Methodenstandards und API sind sehr überzeugend. Man kann sie per HTTP, per MQTT und eben auch in einem Skript nutzen. Aus allen Perspektiven lauten die Methoden gleich und sie besitzen afaik überall die gleichen formalen Parameter, nur die Notationen letzterer sind bei HTTP anders.
Schließlich bieten so Skripte hervorragende Möglichkeiten, eigene Anwendungen für die Shellies zu implementieren - solange es die erforderlichen Hardware-Schnittstellen gibt.
Der Mangel besteht hier imho eher in den eingeschränkten AddOn. Hier wünschte ich mir mal ein AddOn, welches die GPIO des ESP32 ausgiebiger zur Verfügung stellt.
Und entsprechend General Purpose Methoden für die Nutzung der GPIO. Damit ginge noch erheblich mehr.
Jedenfalls kommt mir das relativ offene System sehr entgegen. Die Standards nutze ich auch - Licht, Pumpen, Magnetventile schalten. Aber bspw. mein Projekt zur Temperaturregelung an Heizkörpern schlägt den TRV und ist eben kein Standard. Wer so etwas per Cloud macht, weiß nicht , was er tut. Da ist ein Skript die eindeutig bessere Wahl, und es funktioniert verlässlich.
Ja, anfangs gab es merkwürdige Fehler bei der Skriptabarbeitung, die ich auch anmerkte, wurde aber leider nicht ernst genug genommen. Diese sind aber inzwischen beseitigt.
Fazit: Mit Skripten geht sehr, sehr viel - wenn man will. 
Meine Vermutung: [auch OT]
Die Sprache Pascal wurde relativ gut verstanden und sie ist konsequent strukturiert. Dass sie mal mit einigen Erweiterungen und Portierungen daher käme, hat vermutlich ihr Schöpfer, Herr Wirth, weder geahnt noch beabsichtigt. Jedenfalls wird ihr partieller Erfolg seine verständlichen Gründe haben.
Brücke zur Shelly Firmware und deren Online Dokumentation: [weniger OT]
Die Doku ist wenig zum lernen geeignet, aber als Nachschlagewerk sehr gut und ziemlich vollständig. Insofern überzeugen mich die Shelly Produkte incl. der Firmware und deren API Offenlegung.
Ich halte Pascal für eine sehr gute Lern-Programmiersprache, wozu sie auch afaik von Niklas Wirth gedacht war. Immerhin lernte ich an Hand von Borland Pascal die ersten Dinge der OOP und verstand sie auf Grund der sehr guten Borland Bücher sogar. Das bot mir dann die Grundlage zum verstehen der OOP in C++ - meiner Ansicht nach noch immer die herausstechendste Sprache, wenn man sorgfältig damit codet. DAC sicher ist sie allerdings nicht.
DAC ist meine ad hoc Schöpfung für Dümmster anzunehmender Coder.
Ich hätte mir früher aber auch nicht gedacht, dass ich mich mal mit JavaScript anfreunden täte. Aber die Aspekte der Programmiererei haben sich stark ausdehnend weiterentwickelt. Ich denke bspw. an das JSON Format.
Und ja, Blockly fand ich zunächst interessant (für Anfänger). Als ich dann damit experimentierte, fand ich es für mich ... hm, wenig zielführend.
Als Lernhilfsmittel ist Blockly vermutlich nicht schlecht, aus meiner Sicht als ausgedienter Lehrer. Ich habe aber bereits Erfahrung mit bspw. "Robot Karol" zwecks motivierendem Einstieg in's Programmieren/Coden gesammelt - und musste registrieren, dass die wenigsten meines Clientels die dort erworbenen Fähigkeiten auf eine ernsthafte Programmiersprache (hier; C unter C++) mitnahmen.
Somit stimme ich dir, @De kat, zu, was Blockly betrifft.
Interessant sind auch Vergleiche zwischen Tasmota32 mit Berry und der Shelly Firmware mit JavaScript Möglichkeiten. Beide sind Ereignis gesteuert zu verwenden, hier mit Events, dort mit Rules. Tasmota ist halt auf vielen ESP32 Schaltungen einsetzbar und in vielen Anwendungen nutzbar. Leider gibt es dort die von mir gerne genutzten Schedule Jobs nicht. Ich täte es begrüßen, wenn die Shelly Firmware auch auf sonstigen ESP32 Boards nutzbar wäre.
Wie soll denn "with all features enabled" und "without coding" zusammenpassen?
Mit "all features" kann vermutlich nur das gemeint sein, was sich der Autor vorstellen mag. Das ist aber vermutlich nicht alles, was man mit einem Shelly + Skript anstellen kann.
Edit: Oder der Text ist ein Werbetext. Und Werbetexte sind mit Vorsicht zu genießen. 
@De kat und andere
Hast du mal versucht, das OS Mongoose auf einem ESP32 Board zu installieren?
... und zu nutzen?
Edit:
Ich habe dbzgl. Erfahrung mit Tasmota32 und mag die enbedded Programmiersprache Berry.
Aber die Shelly Firmware auf Basis von Mongoose gefällt mir inzwischen noch besser.
Ob das noch sinnvoll ist, weiß ich nicht. Aber folgende Idee wäre vermutlich umsetzbar.
Ein Shelly dient ausschließlich dem Anbieten eines Dashboards, dessen Daten er von anderen Shellies importiert.
Zu diesem, hier eingesetzten Shelly habe ich einen Abschnitt auf meinem Node-RED Dashboard.
Hier sind die von mir fest vorgesehenen 8 Wochenpläne einseh- und editierbar.
Diese Wochenpläne sind selbstverständlich auf dem Shelly implementiert - als Schedule Jobs.
Das Dashboard stellt nur das Frontend für den Anwender bereit.
Das liefert ein Raspberry Pi 4.
Ich bin skeptisch, ob ich dieses auch in einem Shelly Skript zur Verfügung stellen könnte. Vielleicht werde ich es gelegentlich versuchen. Das dürfte, wenn es gelingen sollte, aber hart an die Grenze des Machbaren gehen.
@De kat
Ich habe den Härtetest wie folgt durchgeführt und will es noch einmal tun.
Über ca. 1 Stunde habe ich drei Endgeräte, 2 PC Web Browser und ein Smartphone, im 1s Refreshing laufen lassen. Es ergaben sich in dieser Zeit keine Probleme.
Ja, ich bin davon weitgehend überzeugt, dass das Skript stabil läuft.
Edit:
Das Skript tut ja mehr als nur die Webseite liefern und die Interaktion mit dem Browser betreiben.
Es regelt die Temperatur per Ventil-Stellantrieb, es kommuniziert per MQTT und es reagiert in Abständen von einer Minute auf Schedule Jobs oder solchen, die per Wochenpläne die Zieltemperatur ändern - letztere allerdings selten.
Edit 2:
Auszug aus Shelly.GetStatus:
"ram_size": 245760,
"ram_free": 130972,
"fs_size": 458752,
"fs_free": 122880,
Da sollte noch etwas gehen.
Ich habe mein Posting #22 erheblich überarbeitet und hoffe, dass es gefällt und einigermaßen verständlich ist.
Es steckt einige Stunden an Recherche, experimentieren und durchärgern dahinter.
Danke an @De kat und für die Rückmeldung zum einfügen von Abbildungen an thgoebel.
Hier noch die erheblich bessere Variante zu obigem Skript.
let Topic = "dein/eigenes/topic";
let Trans = [ // zwecks Transformation in booleschen Wert
{key:"ein", value:true},
{key:"aus", value:false}
];
let Out = 1; // Id des Ausgangs
function action(topic, payload) {
print(payload);
let p = JSON.parse(payload); // liefert die payload Struktur als Objekt
let i;
for(i=0; i<Trans.length && Trans[i].key!==p.schalte; ++i); // suche nach gültigem key
if(i===Trans.length) return; // p.schalte enthält ungültigen key
let para = {id:Out, on:Trans[i].value};
if(p.dauer!==undefined) para.toggle_after = p.dauer;
Shelly.call("Switch.Set", para);
}
MQTT.subscribe(Topic, action);Sie ist besser, weil per Werte am Skriptanfang die gewünschten Dinge festgelegt und so leicht änderbar sind und weil man für eine Änderung jeweils nur an einer einzigen Stelle die Änderung vorzunehmen braucht.
Außerdem ist das die Vorstufe zu einer Konfiguration außerhalb des Skripts im KVS.
Man kann selbstverständlich die MQTT Payload komplexer gestalten, bspw. um die Ausgangs-Id erweitern.
{"out":1, "schalte":"ein", "dauer":300} täte den Ausgang 1 für 5 Minuten einschalten.
Hierfür müsste aber action() noch angepasst werden.
Ich empfehle hierfür ein kurzes Skript, weil du damit das Topic selbst frei festlegen kannst. Das ergibt sich aus der Dokumentation.
Die Links sollen dir nur den Fokus geben. Die Doku ist sehr gut, aber auch umfangreich und nicht immer leicht verständlich.
Wenn du dir diese Doku nicht antun willst, nimm einfach das folgende Skript, baue es ein und stelle es auf automatischen Start (enable).
Das kleine passende Skript hierzu - getestet mit Firmware 1.1.0-beta2. Firmware 1.0.8 machte bei MQTT.subscribe() merkwürdige Probleme.
Man kann mehr Parameter nutzen, die aber hier nicht notwendig sind.
Der Code geht besser, aber dann wird er für Anfänger schwerer verständlich.
function action(topic, payload) {
print(payload);
let p = JSON.parse(payload); // liefert die payload Struktur als Objekt
if(p.schalte!=="ein" && p.schalte!=="aus") return; // ein oder aus sind die akzeptierten Schaltwörter
if(p.dauer===undefined) Shelly.call("Switch.Set", {id:1, on:p.schalte==="ein"});
else Shelly.call("Switch.Set", {id:1, on:p.schalte==="ein", toggle_after:p.dauer});
}
MQTT.subscribe("dein/eigenes/topic", action);Die Funktion action führt das aus, was du willst.
MQTT: Topic = "dein/eigenes/topic", Payload = {"schalte":"ein" bzw. "aus", optional "dauer":Sekundenwert}
Hiermit kannst du dein gewünschtes Topic im Aufruf von MQTT.subscribe() einsetzen.
Wenn du statt "schalte" mit "ein" bzw. "aus" lieber "on" mit true bzw. false nutzen willst, ist das Skript darauf leicht anpassbar.
Ich möchte dir bei dieser Gelegenheit auch die Flexibilität per Skript aufzeigen.
Es geht erheblich besser, wozu aber mehr Aufwand gehört.
Die ohne Skript verfügbare MQTT-Kommunikation läuft über RPC erheblich anders und gewöhnungsbedürftig ab.
Deshalb habe ich dir das kleine Skript empfohlen.
Hinweis: Kopiere nicht per Markierung, Copy & Paste sondern über das Kopiersymbol am Codefenster! Andernfalls erhältst du nicht sichtbare Zeichen, welche die Shelly Firmware nicht verdaut.
Edit:
Ich korrigiere. In Firmware 1.0.8 lag mein Problem womöglich darin, dass ich beim aktivieren von MQTT auch ein Pre-Topic festlegen muss - teilweise verständlich.
Ich werde noch einmal daran arbeiten, aber nicht sofort. 