Ich untersuche derzeit die Möglichkeit, auf einem Shelly Plus 1 mit Firmware 0.13.0-beta3 KVS und Schedule-Jobs zu verwenden.
Dazu gibt es die Limits 50 KVS Einträge (keys) und 20 Schedule-Jobs.
Frage: Fängt die Firmware das Anlegen solcher Einträge - evtl. mit entsprechenden Fehlerinfos - ab, wenn ein solches Limit bereits erreicht ist?
Wenn dies nicht der Fall ist, wäre eine Skript-Implementation hierzu zweckmäßig, was aber einigen zusätzlichen Aufwands bedürfte.
Ich reagiere nun sehr spät, weil ich mich derzeit mit den Schedule-Jobs per Skripts beschäftige.
Ich kenne keine Methode "disableswitch". Deshalb gibt es auch keinen Handler dazu. Jedenfalls nicht auf Shelly Plus 1 Geräten.
Wenn du alle verfügbaren Methoden deines Device wissen willst, nutze bspw. http:<device ip address>/rpc/shelly.listmethods !
Du kannst bspw. die Methode "script.eval" nutzen, welche als Parameter die Script Id und den Namen der aufzurufenden Funktion braucht.
Hierzu gibt es ein Beispiel-Skript namens "register-scheduled-script.js".
Der damit angelegte Schedule-Job beinhaltet "calls":[{"params":{"code":"scheduledTask()","id":2},"method":"script.eval"}].
Der Parameter "id":2 kann selbstverständlich einen anderen id-Wert haben, abhängig von den gerade gespeicherten Skripts bzw. der id des o.a. Skripts.
In diesem Skript muss die Funktion scheduledTask() existieren. Sie kann aber auch in einem anderen Skript existieren, welches notwendigerweise laufen muss.
Statt scheduledTask() ist selbstverständlich eine andere Funktion wie "myFunction()" verwendbar, die dann im Schedule-Job einzutragen ist.
Du kannst auch die optionalen Schedule-Einträge deines Device verwenden und per http://<device ip address>/rpc/schedule.list analysieren.
... 
Aussagekräftiger als eine solche Grafik sind die herunterladbaren CSV-Daten -> Tabellenkalkulation (bspw.), Zeitangaben ansehen.
In dieser Grafikdarstellung sind die Speicherzeitpunkte nicht erkennbar.
Vielleicht haben die H&T längere Zeit keine Messwerte gesendet.
Wie hast du denn die H&T konfiguriert - Temperaturänderung (zum senden), Zeitabstände (auch ohne wesentliche Temperaturänderung)?
@dekat win
Erst einmal vielen Dank für die nützliche tsKonverter() Funktion. Ich setze sie in meiner aktuellen Entwicklung ein.
Da ich gerne sowohl das Tagesdatum als auch die Uhrzeit in einem standardisierten Format nutze, habe ich eine kleine Funktion twoDigits() beigefügt.
Voraussetzung: Der importierte Wert ist eine Zahl.
Eine Funktion isNumber() ließe sich coden und deren Aufruf einbauen, dies lasse ich hier aber weg.
function twoDigits(value) {
return (value<10 ? "0" : "") + JSON.stringify(value);
}Sie liefert eine Zeichenkette zu einem Zahlenwert. Das Resultat beinhaltet mindestens zwei Zeichen.
Basierend auf deinem Code lasse ich datum und zeit kurz vor return ... wie folgt zusammensetzen. Die Formate sind selbstverständlich nach Belieben zusammenzustellen.
let datum = JSON.stringify(aktJahre) + '-' + twoDigits(aktMonat) + '-' + twoDigits(aktTag);
let zeit = twoDigits(korrekturStd) + ':' + twoDigits(aktMin) + ':' + twoDigits(aktSek);Das kann nicht gelingen. Der Ausgang kann nicht die für den Gong erforderliche Stromstärke schalten. Lies bitte gelegentlich die Unterlagen zu Uni!
Du wirst ein Relais oder eine Transistorschaltung mit dem Uni-Ausgang schalten müssen, damit es gelingt.
Ein Relais ist am leichtesten anzuschließen, wenn du keine Elektronikkenntnisse hast.
Edit: Ausnahme wäre ein Gong mit Relais an seinem Eingang. So etwas ist mir bisher nicht begegnet.
Bevor die diesen Aufwand treibst ...
Hast du an den Ausgang des Uni ein Relais oder eine Transistorschaltung angeschlossen?
Der Uni Ausgang kann sicher keinen Gong hinreichend treiben.
Sowohl Schubbie als auch thgoebel haben entsprechende Hinweise gepostet.
Und das am Schluss ohne Programmierkenntnisse?
Das lässt sich vermuten, ist aber nicht sicher. Der TE hat sich hierzu nicht geäußert.
Ok, die Szene mag funktionieren. Dabei kann ich nicht mitreden, da ich die Cloud wegen zu geringer Funktionssicherheit hierfür nicht nutze.
Frage: Was soll der TE tun, wenn die Cloud ausfällt ,,, oder der Internetzugriff ...?
Ja, verstanden und akzeptiert.
Ich habe versucht, die Problematik bei funktional grundlegenden Steuerungen per Cloud anzudeuten. Dies erscheint mir unabhängig von der Anzahl an zu steuernden Geräten.
Und mit einem Shelly Plus ließe sich die gewünschte Funktionalität ohne zusätzliche Hardware/Software implementieren, autark und weitgehend ausfallsicher.
Die Cloud mag dann zusätzliche Optionen bieten, die aber die grundlegende Funktionssicherheit nicht bereitstellen müssten.
Ich fand soeben in der mJS Library eine Vorlage für eine zyklische Schrittkette namens "cycle-switch.js", nutzbar in Shelly Plus Geräten.
Zitat aus der Library zu diesem Skript:
Configurable Cycle switch
Replicate Cycle switch feature from Gen1 devices. Allows for custom list of operations to cycle through.
Hm, wenn daran etwas verwirrend ist, dann bedauere ich dies. Zugleich bin ich gerne bereit, auf Fragen hierzu einzugehen oder Fehlernachweise entgegenzunehmen.
Eine fertige Lösung kann ich nicht anbieten, weil die Rahmenbedingungen hierfür noch nicht hinreichend dargelegt sind.
Vielleicht gibt es eine Möglichkeit für eine Implementation in der Cloud, aber die Cloud basierten "Programmiermöglichkeiten" erscheinen mir hierfür nicht flexibel genug - ich mag mich aber irren.
Hier täte das Prinzip der Schrittkette greifen.
Ein paar Bemerkungen:
Prinzip der Schrittkette:
In einer Statusvariablen wird der aktuelle Status gespeichert. Mit jeder Betätigung eines Sensors, hier Schalter oder Taster, wird die dem Status zugeordnete Aktion ausgeführt/angestoßen und der Status auf einen Nachfolgewert gesetzt. So wird nach jeder Betätigung des Schalters ... ein neuer Status eingenommen, welchem eine neue Aktion zugeordnet ist.
Im einfachsten Fall sind die Werte für den Status natürliche Zahlen 1, 2, 3, ,,,
Die Werte des Status muss eine zirkulare Folge bilden, bspw. 1, 2, 3, 1, 2, 3, 1, 2, ...
... oder die SSD ist mit dampfbetriebenem Generator ausgestattet.
Ich setze voraus, dass du mit Jalousie keinen Rollladen meinst.
Vermutlich wird vom Shelly zur zeitlichen Kalibrierung die ansteigende Leistung bei vom Motor aufgebrachtem ansteigendem Drehmoment erfasst. Ist dieses Drehmoment recht gering, wird evtl. die Leistung zu klein sein - eine Jalousie ist i.d.R. ja erheblich leichter als ein Rollladen. Da ich keine elektrisch betriebene Jalousie habe, habe ich auch keine Erfahrung hierzu.
Eine parallel zum Jalousiemotor geschaltete Zusatzlast könnte evtl. die geschaltete Leistung hinreichend erhöhen.
RobK_ Ich setze mal einen Shelly Plus 1 (PM) mit Plus Addon voraus.
Folgendes ungetestet, also nur eine Idee:
Wenn du auch gerne mal selbst lötest, kannst du auch mit Hilfe der Referenzspannung eine Konstantstromquelle (kurz Stromquelle) zusammenstellen - wie von thgoebel angedeutet.
Ich kenne von früher eine einfache Schaltung mit bipolarem pnp-Transistor, Referenzspannung zwischen Basis und hier Vcc+ und den Quellenstrom bestimmenden Widerstand im Emitterkreis.
Mit einem Feldeffekttransistor sollte dies auch gelingen, wenn man will.
Der Emitterwiderstand ist dann so zu dimensionieren, dass die Stromstärke durch den PT100(0) den gewünschten Spannungsmessbereich ergibt.
Per Skript ließe sich bei Bedarf der Spannungsmessbereich softwaremäßig anpassen bzw. kalibrieren ... Dies würde auch die Möglichkeit bieten, einen npn-Transistor einzusetzen -> fallende Spannung bei steigender Temperatur.
Wenn du keine selbstgelötete Elektronik magst, ist selbstverständlich der Hinweis von Frank Berges sehr gut.
Die values sind HTML Kommentare.
Diese haben in JSON Texten nichts zu suchen.
Sorry, mit einem Plug S lässt sich kein Ventil steuern. Da muss es noch einen vom Plug S geschalteten Antrieb geben, welcher das Ventil öffnet und schließt.
Deswegen wird das auch über NodeRed nicht laufen, zumindest lokal nicht.
Doch, das gelingt problemlos. Genau das habe ich im Experimentierstatus getan. Ich nutzte einen externen Sensor, einen Plug S und einen einfachen Stellantrieb zum öffnen (ein) und schließen (aus) des Ventils.
(Meine an dich wiederholt gestellte Frage gilt einem solchen Antrieb. Der Plug S besitzt ja keinen Antrieb.)
Später habe ich den Plug S und den externen Sensor gegen einen Shelly 1 mit Addon und Temperatursensor ersetzt.
Die Kommunikation läuft über MQTT. Die Temperatur regele ich per Node RED Flow. Selbstverständlich läuft diese Heizungsregelung im lokalen Netz und komplett ohne Cloud.
Und der von mir erstellte Flow kann viele Heizkörper mit jeweils obiger Ausstattung regeln, für jeden Shelly ist nur ein Eintrag in einem Konfigurationsknoten erforderlich, somit leicht erweiterbar oder änderbar.
Demnächst will ich die Shelly 1 mit Addon durch Shelly Plus 1 mit Addon ersetzen, weil ich dann die Regelung auf jedem dieser Shellies auch ohne Zentrale per Skript autark implementieren kann.
Bei unserer Haussteuerung ist es allerdings so, dass ein manueller Eingriff (egal ob BM, Lichststimmung, Thermostate...) die Programmierung übersteuert.
Aha, und das möchtest du auch für die Steuerung einer Raumheizung, wenn ich das nun richtig verstanden habe.
Ich fasse Node RED nicht als zusätzliche "Schnittstelle" auf. Zumindest dürfte ein Node RED Flow auf deinem Raspberry wesentlich zuverlässiger arbeiten als eine Szene oder ähnliches in der Cloud.
Und das, was du erreichen willst, ist in einem Node RED Flow sehr gut implementierbar, ok einen komplexen Zeitplan nutze ich nicht, nur Tag-Beginn und Tag-Ende.
Ich weiß noch immer nicht, was dein Aktor zum stellen des Ventils ist.
Deine Schlussfolgerung ist nicht belastbar.
Ich kenne weder die interne Beschaltung der Umwälzpumpe noch die des Stellmotors.
Ich habe 12V Hutschienen-Netzteile in Gebrauch, die in einem Radius von ca. 50 cm die WLAN-Verbindung von Shellies erheblich stören.
Vielleicht liegt bei dir ähnliches vor.
Hast du denn auch mal einen RC-Snubber zwischen I und O, also parallel zum Verbraucher, geschaltet?
Ein solcher Snubber kann sowohl die Relaiskontakte schonen als auch beim Abschalten Spannungsspitzen verkleinern.
Schaden kann ein RC-Snubber keinesfalls.
