Beiträge von eiche

@De kat :

Ich habe soeben mal deinen Shelly Script httpd ausprobiert.

Sehr sehr chique. Ich werde mal etwas Funktionales testen, mit meinem autarken Shelly Heizkörperregler.

Auf jeden Fall ist deine Vorlage eine vorzügliche Anregung. Ich bin gespannt, ob damit auch JavaScript mit "angular.min.js" geht. Dann könnte der Shelly eine autarke anwendergerechte Webseite bieten und wäre so nicht nur ziemlich ausfallsicher (wegen Autarkie), sondern böte auch noch ein echtes Dashboard.

Das wär dann richtig cool.

Wenn intern diese temporäre Konfiguration tatsächlich geändert würde und vor einem Reboot diese SSID (temporär) nutzbar wäre, könnte ich dies ja mit einem Skript so lösen.

Mit dem Skriptstart würde ich die SSID ändern und hätte so einen für meine Zwecke vielsagenden String dort.

Ich werde das mal gelegentlich testen.

Ich hab's wie folgt testweise versucht, nachdem ich die Original SSID gesichert hatte:

http://<IP-Adresse des Shelly>/rpc/wifi.setconfig?config={"ap":{"ssid":"Emma"}}

Die Antwort war

{
    "restart_required": false
}

Es kam somit keinerlei Fehlermeldung oder Hinweis auf den read only Eintrag. Der Shelly hat die SSID schlicht nicht geändert.

Hm, ich sehe durchaus einen solchen Grund, wie mein Anwendungsfall + Ausfallsicherheit zeigt.

Aber danke für deine informative Antwort.

Edit: Ich werde jedenfalls kein Facebook Mitglied, da ich Facebook verabscheue.

Zunächst einmal einen Dank an @De kat.

Meine Anwendungsumgebung

Ich habe vor, mehrere Shelly Plus 1 mit AddOn und Temperaturfühler zur autarken Heizkörperregelung einzusetzen. Mein Prototyp arbeitet bereits zur vollen Zufriedenheit. Per Node-RED Dashboard kann ich und insbesondere meine Frau alles anwenderfreundlich einstellen, was das Herz begehrt, auch bspw. Schedule Jobs.

Zwecks Optimierung der Ausfallsicherheit, will ich den Shelly mit einem Taster ansteuern - langer Druck -> Zieltemperatur erhöhen, kurzer Druck - Zieltemperatur senken.

Für die aktuellen Daten der Regelung (Zieltemperatur, gemessene Temperatur, Ventil auf/zu) kann das Web UI des Plus 1 nicht verwendet werden, weil hier die Zieltemperatur fehlt. Also will ich eine Webseite per Skript zusammenstellen, die mir diese Daten anzeigt. Hierzu ist im Falle eines Netzwerkausfalls das anzeigende Smartphone per WLAN mit dem AP des Shelly zu koppeln. Leider fand ich bisher keinen Weg, die kryptischen, und damit wenig anwenderfreundlichen, AP-SSID zu ändern.

Meine Fragen

1. Gibt es eine Möglichkeit, irgendwie die AP-SSID zu manipulieren, damit diese benutzerfreundlich gestaltet werden kann?
2. Weiß jemand hier, ob seitens Allterco die Änderbarkeit dieser SSID auf einer todo Liste steht?

Über konstruktive Reaktionen täte ich mich freuen.

Anmerkung

Meine Implementation der Heizkörperregelung arbeitet verlässlicher als dies die TRV tun. Deshalb will ich erstere zukünftig bevorzugen, auch wenn die TRV das Stellventil quantifiziert öffnen können, was mein Stellantrieb nicht kann.

langerES : Zu den Schedules

Ich habe mir das an einem Shelly Plus Plug S mit Firmware 1.0.8 mal angesehen. Die Wege sind etwas komplexer geworden, Dafür bietet das Web UI deutlich mehr Möglichkeiten zur Einstellung von Schedule Jobs, die ich nur noch mit einer eigenen Webseite toppen kann. Mir gefallen die neuen Möglichkeiten. Es fehlt allerdings eine Konfigurationsmöglichkeit für weniger ambitionierte Anwender. Ich zeige mal meine Screenshots aus dem Web UI.

Dazu ist ein Schedule Job auszuwählen (anklicken) oder ein neuer anzulegen.

Interessanterweise wird beim ansehen eines vorhandenen Schedules der Modus "Advanced schedule" vorausgewählt, beim neu anlegen hingegen "Basic schedule". Dies erscheint mir eher zur Verwirrung beizutragen, auch wenn ich dies keineswegs als Fehler interpretiere.

1. Die Darstellung im Modus "Advanced schedule" (Titel "Schedule type").
Die Bezeichnung "Schedule type" halte ich für ungeeignet, weil die zugrunde liegenden Schedule Jobs alle die gleichen Einstellmöglichkeiten bieten. Ausschließlich die Benutzerschnittstellen (hier: im Web UI) unterscheiden sich.

Hier lassen sich auch erweiterte Einstellungen nutzen, bspw. an einem bestimmten Tag in einem bestimmten Monat.

.

Unter "When to execute" kannst du in engl. Prosa die Zeiteinstellung lesen. In meinem Fall stimmt allerdings darin die Angabe "At weekday Sonntag" nicht, weil dieser Job für alle Wochentage gilt.

2. Die Darstellung im Modus "Basic schedule" (Titel "Schedule type").

Hier lassen sich ausschließlich Wochenpläne ablesen bzw. einstellen.

Vermutlich kommt dir dieser zweite Modus mehr entgegen. Allerdings muss man afaik dies in jedem Schedule Job aktiv selektieren.

Ich fand leider bisher keine Möglichkeit, diesen Modus als Standard festzulegen.

Fazit: Die Benutzerfreundlichkeit (usability) kann sicher noch gesteigert werden. Dire neuen Möglichkeiten sind imho aber sehr begrüßenswert.

Stefanie24

Deine Anregung passt.

Das kann man ja leicht bspw. per Web-UI konfigurieren, allerdings habe ich eine solche Kombination aus konfigurierter Einschaltdauer und Skript-Timer bisher nicht getestet.

Sie müsste aber funktionieren.

Kleine Korrektur am Rande - in aller Freundschaft:

Zitat von Stefanie24

man Skripte per html callen

1. Nicht ein Skript wird aufgerufen (call), sondern ein HTTP Handler, was eine Funktion im Skript ist.
2. Es wird nicht per HTML sondern per HTTP GET (Adresszeile im Browser) aufgerufen, bzw. im Shelly per action/webhook.

Ansonsten Danke für dein Interesse.

Edit: Inzwischen getestet ... und funktioniert wie gewünscht.

Ok, in diesem Fall wäre bei Einsatz eines PT1000 eine elektronische Ergänzung per Messbrücke und Verstärker ziemlich nützlich, da du Wert auf eine noch relativ genaue Messung legst.

Ich kann bei dem von mir angedeuteten Verfahren nicht hinreichend Erfolg versprechen, insbesondere weil hierfür eine etwas aufwändigere Kalibrierung erforderlich wäre.

Am interessantesten wäre die Verwendung des vorhandenen Sensors an BT3, falls dieser zu einer Kommunikation bewegt werden könnte.

Ein PT1000 kam ja nur zur Sprache, weil der Platz für einen digitalen Sensor nicht ausreichte.

Hier täte ich aus Sicherheitsgründen für den Einbau eines Sensors nicht viel basteln.

Ich kenne die Oberflächenstruktur an BT3 nicht, vermute aber dass der vorhandene Sensor dort an der Speicherhülle befestigt ist. Wenn dort genügend Platz zum temperaturstabilen Ankleben oder gar Anschrauben eines digitalen Sensors, wie einem 18B20 im Metallröhrchen vorhanden ist, sollte diese Montage bevorzugt werden.

Ggf. kann eine zusätzliche Wärmeleitung von BT3 zum Sensor hergestellt werden, einen systematischen Messfehler bei höheren Wassertemperaturen in Kauf nehmend. Wenn die Umgebungstemperatur um den Speicher wenig schwanken sollte, was ich mal vermute, dann ließe sich dieser Messfehler per Messwertvergleiche zwischen eingebautem Sensor (Anzeige) und 18B20 entweder per Korrekturfunktion oder Lookup-Tabelle hinreichend verringern.

Prinzipiell könnte die Messung der Umgebungstemperatur zusätzlich zur Fehlerkorrektur herangezogen werden, was jedoch relativ aufwändig wäre und deshalb vermutlich nicht in Frage käme.

All dies ist letztlich ein Workaround, wenn der vorhandene Sensor bzw. Mikrocontroller nicht zu einer nutzbaren Kommunikation bewegt werden kann und der Einbau eines 18B20 nur in größerem Abstand von bspw. 2 bis 4 cm (grob geschätzt) zu BT3 gelingt. Eine Wärmeleitung von BT3 zum 18B20 erwähnte ich bereits, kann jedoch nicht einschätzen, wie gut diese gelänge, incl. umgebender Wärmeisolierung dieser Wärmeleitung. Ein Kupferblech mit Wärmeleitpaste könnte die Wärmeleitung realisieren. Schließlich wären in jedem Fall Messwertvergleiche heranzuziehen, um die Nutzbarkeit einer solchen Anordnung zu prüfen - und ggf. zu verwerfen.

In der Tendenz stimme ich Rolf zu, aber nicht in der Absolutheit.

Bei kleinem Messbereich und evtl. niedrigem Anspruch an die Genauigkeit, was bspw. für eine Regelung durchaus genügen kann, würde eine schlichte Reihenschaltung aus konstantem Widerstand und PT1000 an der AddOn Referenzspannung genügen.

Der evtl. zusätzlich erforderliche elektronische Schaltungsaufwand (Messverstärker ...) hängt in erster Linie von der angestrebten Anwendung und deren Messgenauigkeitsanforderungen ab.

ingmarstein:

Wenn du uns deine konkrete Anwendung bzw. Einsatzzweck schilderst, könnte vielleicht eine genauere Empfehlung herauskommen.

Ich sehe nur zwei Möglichkeiten:

1. Digital, d.h. ein digitaler (intelligenter) Sensor liefert unmittelbar die Messwerte.
2. Analog, d.h. ein analoger (dummer) Sensor wird in einen Spannungsteiler oder Messbrücke eingebaut, was eine analoge Spannung liefert.

Schließlich wird der zu verwendende Sensor von dessen Einbaumöglichkeiten abhängen, wobei, wenn möglich, die erste Variante zu empfehlen wäre.

Das vorliegende Problem ist offensichtlich die Nichteinbaubarkeit eines handelsüblichen digitalen Sensors.

Zu meinem Posting #18:

Dies zeigt, dass prinzipiell eine Umrechnung analoge Spannung -> digitaler Wert bspw. per Shelly Skript möglich ist.

Der Umrechnungsaufwand ist umso geringer, je kleiner der interessierende Messbereich und je geringer die erforderliche Genauigkeit sind.

Schließlich dürfte an den o.a. prinzipiellen Varianten nichts vorbeigehen.

Anmerkung: Die Nichtlinearität des ESP32 internen Analog-Digital-Umsetzers dürfte entscheidend für die Nichtlinearität in der Umrechnung sein. Dafür kann imho Allterco nichts.

sebastian73

Interessantes Projekt

Ich kenne den Ventilator nicht, aber meine "interne" Logik sagt mir, dass im Schaltplan von #11 die beiden Kondensatoren C3, C4 auch parallel geschaltet werden könnten, was vermutlich eine etwas höhere Drehfrequenz zur Folge hätte.

Ich sehe somit nicht, dass dein U2-Shelly notwendigerweise gegenseitig verriegelte Ausgänge braucht.

Zitat

herumgemessen, da sind -neben der 220V WechselSpannung - nur 5V Spannungen und 6.3V Gleichstrom zu messen

Das sind erst einmal unbrauchbare Angaben.

1. Was ist bitteschön eine 5V Spannung (im Singular oder im Plural? )? Wechselspannung vielleicht?
2. Einen 6.3V "Gleichstrom" gibt es schonmal gar nicht. Das muss eine Spannung sein.

Das mal unabhängig von den obigen Reaktionen, die selbstredend alle ihre guten Seiten haben.

Ich gehe ja schon ...

DIYROLLY

Schon klar.

Erst einmal täte ich eine Lookup Tabelle mit linearer Interpolation einsetzen.

Wenn dies nicht genügend genau sein sollte, wäre eine Brückenschaltung mit Operationsverstärker anzustreben.

In jedem Fall ist eine Referenzquelle erforderlich, um festzustellen, wie groß die Messabweichungen von dieser Referenz sind.

Und schließlich ist eine o.a. Lookup-Tabelle per KVS und geeignetem Frontend auch benutzerfreundlich einrichtbar.

Ich sage nicht, dass ich dies in 3 Tagen realisieren täte, aber all dies ist möglich.

Und mein Einwand richtete sich gegen eine angedeutete Unmöglichkeit.

Trotz alledem ist selbstverständlich dein Know How immer willkommen.

Ich sage nur:

Gebt mir die Dinge wie PT100, PT1000 und ich stelle ein Skript zusammen, das alles bietet, was das Temperaturerfassungsherz begehrt.

Klar.

Irgendwo muss der Messwert ja verarbeitet werden. Genau dort sollte sich die Messspannung in eine Temperatur umwandeln lassen. Mit einem Shelly Plus x ginge das locker per Skript.

MR2021 Vermutlich bist du ein Java- oder C++-Coder.

Ich schrecke vor der Ausnahmebehandlung, welche du recht umfangreich in deinem Skript einsetzt, auf einem ESP32 zurück, aber evtl. kann dies genutzt werden.

Ich bevorzuge möglichst robusten Code ohne Exceptionhandling, was auf Grund des Eventhandlings und dem Wissen über die Asynchronität der RPC recht gut gelingt.

Und ob dieses Exceptionhandling in einem Skript hinreichend robust ist, erscheint mir nicht hinreichend gewährleistet.

Ansonsten Hut ab vor deinen sehr umsichtig-vorsichtigen Skript-Code.

Ich empfehle aber eher zielgerichteten Code, der nicht als Wollmilchsau-Schablone geeignet ist, dafür aber relativ schlank mit Reserve für Erweiterungen.

Nur mal so als Rückmeldung,

agent47:

Ich habe dies bisher zwar nicht getestet, aber der Shelly mit AddOn sollte durchaus einen PT100 oder so zwecks Temperaturmessungen nutzen können. Hierfür gibt es einen analogen Eingang und auch einen Referenzspannungsausgang.

Der Rest ist ein Spannungsteiler oder eine Brückenschaltung.

Gelewu17 :

Selbstverständlich gelingt dein Anliegen - warum auch immer du das tun willst.

Du schließt deine FritzBox, oder welches Gerät auch immer, an den Ausgang (O) deines Shelly an und trägst auf dem Shelly den passenden Zeitplan ein.

Selbst wenn sich zeitlich ungünstig ein Stromausfall ereignen sollte, wird danach die FritzBox hochfahren - alles gut.

Du kannst zum temporären Ausschalten einen Timer verwenden oder schlicht zwei Zeitpläne, die geringfügig versetzt aus- und einschalten.

Der Rest ist schlicht TESTEN.

Die pauschale Einstellung zu einem zentralen System ist so nicht geeignet.

1. Ein zentrales System kann bei Überwachung, Speicherung und auch Dashboard für bspw. Smartphones helfen. Soweit Ok ... aber
2. Wenn es um spezielle Funktionen zum schalten, steuern, regeln eines an einen Shelly Plus angeschlossenen Gerätes geht, ist ein Skript unschlagbar, weil dies
   1. immer arbeitet, solange Stromversorgung anliegt,
   2. auch dann funktioniert, wenn das übergeordnete System ausfällt oder durch ein anderes ersetzt wird und
   3. am schnellsten reagieren kann, weil keine zusätzliche Kommunikation erforderlich ist.

Somit sollte die angestrebte Funktionalität, wenn möglich, so nahe wie möglich am Gerät implementiert werden, bspw. per Skript.

Smartscha:

Dein Skript ist erst einmal nicht schlecht strukturiert, aber

es wäre besser, wenn der Eventhandler an die aufgerufene Funktion die bereits vorliegenden und benötigten Daten per Parameter übergibt. Dann braucht nämlich deine Funktion checkPowerAndSwitch() nicht die benötigten Daten per RPC anzufordern, was eh nicht synchron gelingt. Auf die Schnelle etwa so:

// Aufruf im Eventhandler:
checkPowerAndSwitch(event);

Statt des Aktual-Parameters "event" kann es zweckmäßig sein, eine Unterstrukltur "event.xxx" als Parameter zu verwenden.

Die Dokumentation auf https://shelly-api-docs.shelly.cloud/gen2/ ist tatsächlich ziemlich gut, wenn die einzelnen Abschnitte im wesentlichen vertraut sind. Dies kostet allerdings einige Mühe und, je nach Vorkenntnissen, viele Experimente. Aber dann ...

@De kat : Sorry, ich habe mir nicht die Zeit genommen, deine ausführlichen Vorschläge zu studieren. Aller Wahrscheinlichkeit und Erfahrung nach sind diese sehr gut.

Einfach gelänge dies mit temporärem Einschalten statt eine gemessene bzw. erfasste verbrauchte Energie zu verwenden.

Dafür ist eine schlichte HTTP-Kommunikation geeignet, abhängig davon, ob es sich um einen Plug S (erste Generation) oder einen Plug Plus S (zweite Generation) handelt.

Dazu gibt es gut dokumentierte Seiten, in denen man aber erst einmal Orientierung finden muss, was zunächst nicht ganz leicht ist.

Übergreifend: https://shelly-api-docs.shelly.cloud/

Dann entweder zu "First Generation Shelly" oder zu "Second Generation Shelly" navigieren ...

Zum Plug S (1. Gen.):

http://<IP-Adresse des Plug S>/relay/0?turn=on&timer=<Dauer in s>

Die Verwendung der verbrauchten Energie ist erheblich aufwendiger und mit einem einzelnen Plug S afaik nicht realisierbar. Dies könnte evtl. mit der Cloud gelingen, was ich nicht empfehlen kann (Kanone auf Spatz und ohne Funktion, wenn keine Cloud-Verbindung).