Beiträge von eiche

Danke DIYROLLY, die schlagartige Entladung sagte mir auch nicht zu und ich dachte ebenso über einen Entladungswiderstand nach.

Ich werde deine Hinweise gerne verarbeiten und zumindest teilweise testen.

Bisher funktioniert alles wie gewünscht, allerdings nur in selten genutztem Laboraufbau.

Deine Hinweise sind jedenfalls angemessen und verständlich.

Edit:

Ich nutze das Projekt im praktischen Einsatz, nur bisher ohne die Taster.

Dort bewährt es sich bestens.

In einem parallelen Testaufbau stecken die Taster.

Ja klar, gerne.

Ich finde es nicht auf die Schnelle hier im Forum.

Deshalb hier der Link zu einer meiner Websites, auf welcher ich das Projekt beschreibe, noch ohne herunterladbarem Skript.

Autarke Heizkreisregelung per Shelly Script

Bei deutlichem Interesse am Skriptcode werden ich voraussichtlich diesen zum Herunterladen bereitstellen.

Ich bitte dann um eine entsprechende Mitteilung.

Falsch: Das Skript ist längst herunterladbar, hatte ich vergessen.

Edit: An der Verbesserung der vom Skript gelieferten Webseite werde ich noch arbeiten. Es gibt dazu neue Erkenntnisse und Ideen.

ostfriese

Ich kann hierfür mein laufendes Projekt zur Temperaturregelung einzelner Heizkreise auf der Basis von Skripten empfehlen.

Dieses ist

1. anpassbar
2. pflegbar
3. bisher robust am laufen
4. relativ ausfallsicher, s.a. Webserver im Skript
5. weitgehend unabhängig von Herstellerfehlern - Firmware ausgenommen
6. bereits mit Shelly Plus 1, AddOn und Temperatursensor arbeitsfähig
7. per zusätzlicher Taster und Elko am AddOn, also Niedrigspannung, leicht für Laien bedienbar.

Einschränkungen:

• Stromversorgung erforderlich, dafür aber auch kein Laden eines Akku notwendig
• Keine Anzeige, dafür aber der im Skript implementierte kleine Webserver, der eine Website liefert, welche von jedem halbwegs aktuellen Browser dargestellt werden kann
  (Diese Website ist auch dann per Shelly eigenem AP nutzbar, wenn das WLAN ausgefallen sein sollte. Auch eine LAN-Verbindung durch portieren auf einen Pro ist selbstverständlich möglich.)
• Ich kann selbstverständlich keine Gewährleistung übernehmen, halte aber die Qualität dieser Implementation für relativ hoch - zumindest verlässlicher als die TRV.

Außerdem entwickle ich daran weiter, wenn es mich packt.

Da du Skripten eher zugeneigt bist, könntest du dieses Projekt, quasi als Fork, selbst weiterpflegen.

LockeR56

Ich las diesen Thread erstmalig.

Hattest du auch mal den Shelly spannungsfrei geschaltet - Sicherungsautomat zu diesem Stromkreis aus?

Nach dem erneuten Einschalten und dem Booten des Shelly, hätte der Betrieb evtl. wieder funktioniert.

Aus gegebenem Anlass - eine von mir versehentlich weggelöschte E-Mail Anfrage

Ich erhielt kürzlich eine E-Mail, vermutlich von hier ausgehend weitergeleitet, welche ich leider nicht sorgfältig betrachtend zügig als Spam weglöschte.

In dieser E-Mail fragte mich der Absender, ob ich ihm für 70€ "eine solche Uhr" herstellen könne.

Im Nachhinein erfasste ich, dass er sich auf meine Implementation einer "Hauptuhr" in einem Shelly Plus 2 per Skript bezogen haben dürfte.

Falls der Absender dies hier liest, möge er sich bitte noch einmal dbzgl. an mich wenden, damit ich ihm antworten bzw. die Rahmenbedingungen erfragen kann.

Hier noch einmal die Links zur Beschreibung:

Emulation einer Hauptuhr per Shelly Plus 2

Hauptuhr-Emulation per Shelly - Installationsanleitung

Optionaler Tönezusatz

Zusätzlich lasse ich per altem Raspberry Pi mit Node-RED Flow und angeschlossenem Lautsprecher beliebige Töne alle Viertelstunde und zu jeder vollen Stunde (unterschiedlich) wiedergeben, selbstverständlich nur zu festgelegter Zeitspanne tagsüber.

Diese Töne sind beliebige Sounddateien, welche auf dem Raspberry abgelegt und dort nach Wunsch per kurzen JSON-Textdateien zu konfigurieren sind. Die zugeordneten Konfigurationsnamen (Dateinamen) werden auf dem Shelly im KVS abgelegt und sind entsprechend änderbar.

Aktuell werden in meiner Installation eine Abwandlung des Westminster Abbey Gong zu voller Stunde und eine Kuckuckruf zu jeder Viertelstunde (ein-, zwei- und dreimal) wiedergegeben.
Für mehr siehe Hauptuhr per Shelly Plus 2 - Audio Erweiterung und mehr

Eine solche Uhr läuft übrigens längst sehr zuverlässig mit automatischen Zeitumstellungen an meiner Schuppen-Außenwand - bisher verlässlicher als jede Funkuhr.

Diese Nebenuhr wurde mir dankenswerterweise von thgoebel geschenkt, da er, so darf ich behaupten, mit meiner Implementation sehr zufrieden ist.

Btw, das Hauptproblem beim "Herstellen" einer solchen Uhr ist die Beschaffung solcher alten Nebenuhren, wie sie bspw. in der Abbilddung gezeigt ist.

Solche Uhren ohne eigenen Taktgenerator (Uhrwerk) können auch andere Bauformen haben, wie bspw. eine Klappzahlenuhr mit zyklisch herunterklappenden Zahlenschildern.

Den Rest mit Shelly Plus 2 und Skript sowie einrichten der Hauptuhr (Shelly Plus 2 + Polwenderelais) kann ich beisteuern.

Thomas arbeitet vermutlich noch gelegentlich am Einbau eines SSR (Solid State Relais) inkl. Polwende in den Shelly als Ersatz für die beiden "Klick-Klack Relais", wodurch das externe Polwenderelais obsolet würde.

Ich hoffe, darüber bei unserem nächsten Treffen mehr zu erfahren.

Nordlicht_2023

Ich denke, dass du wenigstens einen Teil meiner Projektlösung brauchen kannst.

Wie ich weiter oben bereits mitteilte, kannst du weiteres dazu hier finden:

https://iotig.eichelsdoerfer.net/index.php/loes…r-shelly-script

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.

Krauskopp

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:

1. Die Montage ist einfach.
2. Die Geräte arbeiten autark.
3. Sie sind unabhängig von sonstiger Umgebung ad hoc einstellbar (ohne Wochenpläne).

Nachteile:

1. Sie müssen in gewissen Abständen, die sehr unterschiedlich sein können, geladen werden - naheliegenderweise.
2. Ihre Netzwerkeinbindung fällt mitunter aus, was nach meiner Erfahrung nicht immer schnell mal per Reset behoben werden kann - Grund unbekannt.

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.

1. Man muss die Stromversorgung irgendwie in Richtung Stellventil kriegen - ich habe an einer Stelle noch die improvisierende Zuleitung mit Schuko-Stecker in Betrieb.
2. Es gibt keine optische Anzeige am Gerät. Das Drücken eines Mikrotasters wird akustisch per einschalten des Relais für 1s leise rückgemeldet. Ansonsten ist ein Smartphone bestens geeignet, die vom Skript gelieferte Webseite zu nutzen und dort die aktuelle Zieltemperatur abzulesen.

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.