Beiträge von eiche

  • HTML Webseite lokal auf dem Shelly [via http_Endpoint] Geht!

    Überarbeitung

    Damit nicht unnötige Posts hier erscheinen, habe ich dieses überarbeitet.

    Der Shelly stellt per Skript eine Webseite bereit, die in verschiedenen Modi zyklisch refresht werden kann - oder auch ohne Refresh.

    Zusätzlich ist sie interaktiv. Der Anwender kann die Zieltemperatur um jeweils 0.5°C erhöhen oder absenken.

    Vorteile

    1. Man kann mit dem Shelly auch über dessen Access Point Adresse 192.168.33.1 kommunizieren, wenn man bspw. das Smartphone mit dem Shelly AP gekoppelt hat.
    2. Es sind keine zusätzlichen Kommunikationspartner wie ein übergeordnetes System oder ein MQTT Broker erforderlich.

    Screenshots der Webseite

    Die folgenden Screenshots zeigen die Darstellungen in einem HTML 5 fähigen Web Browser. Sie erscheinen sowohl auf einem PC als auch auf einem Smartphone. Sogar ein relativ einfaches Smartphone aus dem Jahr 2013 kann mit installierten Firefox diese Seite darstellen und automatisch refreshen. Einzig die kleinen Links links und rechts der Zieltemperatur sind mit dem alten Smartphone nicht so leicht zu aktivieren. Mit meinem aktuellen Smartphone geht das leicht.

    Jede Abbildung zeigt einen von vier konfigurierten Refresh Modi. Die aktivierbaren Links sind in gelb dargestellt.

    Es sind vier Zeitangaben (Datum und Uhrzeit) enthalten, die alle lokal auf dem Shelly vorliegen sollten. Daran kann der Anwender erkennen, wie aktuell verschiedene Dinge sind. Derzeit habe ich den Fall "Shelly ist nach reboot offline" noch nicht getestet. Hierfür sind sicher Codeänderungen erforderlich - ein Punkt auf der todo Liste.

    Die Zeitangabe oben, unterhalb des Gerätenamens gibt an, wann die Webseite vom Shelly geliefert wurde.

    Unter "Zieltemperatur" liegt der Zeitpunkt der letzten Änderung.

    Unter "Temperatur" und "Luftfeuchtigkeit" stehen die Zeitpunkte der letzten Wertregistrierung, also wann die Firmware des Shelly diese Werte per Event zur Verfügung stellte.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Code und HTTP Requests

    Statt dieser Refresh-Zyklus-Werte können selbstverständlich auch andere genutzt werden. Sowohl die Namen als auch die Werte liegen in folgendem Datenfeld.

    Code
    Mode = [ // e.g. four refresh modes, you may try one mode ;-P
  {name:"ohne Ladezyklen", value:0}, // without refreshing
  {name:"alle 60s", value:60}, // regular mode
  {name:"per Taster einstellen", value:1}, // adjust mode
  {name:"alle 10s", value:10} // one of possible multiple alternatives
]

    Der Modus "per Taster einstellen" bezieht sich auf zwei Taster zum schrittweisen erhöhen bzw. absenken der Zieltemperatur. Diese Taster sind am AddOn angeschlossen, Tastendrücke werden per Skript verarbeitet. Da hierbei kein Display vorliegt, kann bspw. ein Smartphone mit der Shelly Skript-Website genutzt werden. Damit die Anzeige zügig reagiert, wird hier in 1s Abständen refresht.

    Diese Struktur kann selbstverständlich editierbar im KVS abgelegt sein und von dort bei Skriptstart eingelesen werden.

    Der URL hat die folgende Struktur.

    Code
    http://<IP-Adresse des Shelly>/script/<Skript-Id>/data?m=<Modus Index>
bzw. ohne Wahl des Modus und Verwendung des default Index 0
http://<IP-Adresse des Shelly>/script/<Skript-Id>/data
Zum verändern der Zieltemperatur gibt es zwei Alternativen.
1. http://<IP-Adresse des Shelly>/script/<Skript-Id>/data?s=<neuer Wert>
2. http://<IP-Adresse des Shelly>/script/<Skript-Id>/data?d=<Schrittwert>

    Der Request-Wert hinter data? kann alternativ drei verschiedene Parameter enthalten.

    1. m=<Refresh Modus als Index zum Datenfeld Mode (s.o.)>
      m=1 lässt die Webseite alle 60s refreshen
    2. s=<neuer Wert für die Zieltemperatur>
      s=12 setzt die Zieltemperatur auf 12°C
    3. d=<Änderung relativ zur vorliegenden Zieltemperatur, auch Vorzeichen behaftet>
      d=-0.5 senkt die Zieltemperatur um 0.5°C

    Der Codeabschnitt zu diesen Webseiten.

    Nochmals vielen Dank für die gute Grundlage, die @De kat zur Verfügung stellte.

    Die Variable Status mit deren Komponenten tT, tC und rh liegen im gesamten Skript an anderer Stelle, dort, wo nicht ganz regelmäßig die gemessenen Werte abgelegt und in regelmäßigen Abständen (Schedule Job) von dort nehmend geliefert werden. Diese werden zusammen mit einem Zeitstempel übertragen und landen in einer Zeitreihendatenbank - aber das ist ein anderes Thema.

    Die CSS-Angaben sind mir nicht sehr vertraut. Ich weiß halt, dass es so etwas gibt und die Struktur kenne ich auch, aber die genauen Bezeichnungen muss ich oft recherchieren und testen.

    So, nun sollte das Projekt vorläufig komplett sein.

  • HTML Webseite lokal auf dem Shelly [via http_Endpoint] Geht!

    In meinem Projekt "Autarke Heizkreisregelung" per Shelly Plus 1 mit AddOn funktioniert der kleine Webserver im Skript nach Vorlage von @De kat inzwischen bestens.

    Hier mal die vorläufige Darstellung:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Es wird sogar ein 1s Reload Zyklus bewerkstelligt. Dieser sehr kurze Zyklus dient ausschließlich der Rückmeldung einer Zieltemperaturänderung per zwei Mikrotastern am Addon.

    Somit gelingt quasi eine Nachbildung des TRV mit anderen Mitteln und geringerer Ausfallwahrscheinlichkeit.

    Der TRV hat trotzdem noch partiell kleine Vorteile, die ich aber nicht brauche. Zudem werde ich irgendwann einmal den schlichten Regelalgorithmus (Zweipunktregelung) per Puls/Pausenverhältnis etwas verbessern.

    Btw, ein paar wenige CSS Parameter ließen sich auch vom Anwender per KVS konfigurieren. Nur das Design, hier in Tabellenform, bliebe gleich.

    Ich werde gelegentlich versuchen, auf der Webseite per Button die Umschaltung zwischen zwei Modi zu unterstützen. Damit kann der Anwender zwischen "Einstellmodus" mit zügigen Rückmeldungen (1s) und "Regelmodus" (60s) umschalten.

    Wesentlich hierbei ist, dass dazu neben dem Shelly + Zubehör ausschließlich ein Smartphone oder so gebraucht wird. Dabei ist selbstverständlich ungenommen, dass auch ein übergeordnetes System verwendet werden kann, aber eben nicht muss.

    Edit:

    angular.min.js kann wegen zu großen Umfangs nicht auf dem Shelly zur Verfügung gestellt werden. Somit müsste die Einbindung dieser Bibliothek per Verweis auf eine externe Quelle erfolgen, was klar möglich ist, dafür aber das Computernetzwerk nicht ausfallen dürfte.

    Nun ja, zaubern geht halt mit so einem kleinen Shelly nicht. ;)

  • HTML Webseite lokal auf dem Shelly [via http_Endpoint] Geht!

    @De kat :

    Ich habe soeben mal deinen Shelly Script httpd ausprobiert. :thumbup: :thumbup: :thumbup:

    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. 8)

  • HTML Webseite lokal auf dem Shelly [via http_Endpoint] Geht!

    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.

  • Shelly Plus 1; nach Firmw. Update auf 1.08 Fehler beim sheduler und Taster ?

    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.

    . Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    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.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    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.

  • Per Bewegungsmelder ausschließlich in ausgeschaltetem Zustand einschalten mit Einschaltdauer, deaktivierbar

    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. ;)

  • Temperaturfühler DS18B20 Alternativen von der Kabelstärke und Fühlerstärke

    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.

  • Temperaturfühler DS18B20 Alternativen von der Kabelstärke und Fühlerstärke

    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.

  • Temperaturfühler DS18B20 Alternativen von der Kabelstärke und Fühlerstärke

    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.

  • Shelly Schaltung gesucht

    sebastian73

    Interessantes Projekt :thumbup:

    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.

  • Funkklingel "smart" machen

    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? :P )? 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 ...

  • Temperaturfühler DS18B20 Alternativen von der Kabelstärke und Fühlerstärke

    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. :)

  • Mein erstes Script: Leistungsüberwachung für Shelly Plus 2PM mit Auto-Abschaltfunktion

    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,