VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Zur Messung der Bodenfeuchtigkeit ist imho der SMT50 von Truebner relativ gut geeignet. Dieser ist leider nicht billig, ist aber recht gut abgeschlossen und wird horizontal in's Erdreich gebracht. Er liefert zwei analoge Werte - einen zur Bodenfeuchtigkeit und einen zur Bodentemperatur. Meinen muss ich noch einbauen, bin aber sehr zuversichtlich. Damit und mit etwas Programmierung ist alles komfortabel möglich.
Von nichts kommt nichts.
Jede Jalousie/jeder Rollladen, von Shelly gesteuert, muss einzeln angesteuert werden. Wie soll denn sonst die Kalibrierung funktionieren - rhetorische Frage?
Dies täte voraussetzen, dass alle an einem Shelly/Relais angeschlossenen Rollläden immer genau gleich fahren, was technisch unmöglich ist.
Somit bleibt dir zum testen nur, einen einzelnen Rollladen, getrennt von anderen, an einen Shelly anzuschließen.
Wie ist die Original Endabschaltung aufgebaut?
Lichtschranke oder mechanisch betätigter Mikroschalter/taster?
Zumindest diese sollte/könnte analysierbar sein.
Um eine Action mit beliebigem URL einzutragen, kannst du die App nutzen oder besser das WebUI des Shelly selbst. Dort kannst du unter Action das konfigurieren, was dir als Bedingung zur Verfügung steht und den von dir gewünschten URL eintragen. Vermutlich bringt in deinem Fall die Cloud keinen Vorteil.
Da geht einiges durcheinander.
Mehr Sorgfalt könnte auch helfen.
Schließlich bleibt die Frage offen, was du vorhast.
Afaik ist Zeile 19 ungeeignet. Ich kenne bisher kein HTTP Objekt/Struktur mit der Methode get.
Die RPC Methode HTTP.Get ist via Shelly.call zu nutzen.
Shelly.call("HTTP.Get", {url:url}, ...);tvbshelly war schneller.
Hinweis: In einem Shelly Script sind alle RPC Methoden afaik ausschließlich via Shelly.call aufzurufen.
https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…ures#shellycall
Also kann ich das für mich kompilierte Script auch mit 5 Aktionen darstellen.
-kompilierte +komplizierte? Shelly Script ist eine reine Interpretersprache, da wird nichts kompiliert, es kann aber für manche "kompliziert" sein. 
Und ja, deine Aktionenlösung gelingt auch, allerdings ausschließlich mit schreiben in den nichtflüchtigen Speicher. Wie ich oben beschrieb, ist via Skript auch eine Lösung ohne Nutzung des nichtflüchtigen Speichers möglich. Wer keine Skripte mag/kann und hinreichend mit den RPC Methoden zurechtkommt, der sollte deine Lösung nutzen.
Noch ein Hinweis: Das von Tom-DD dargelegte Skript kann noch so erweitert werden, dass ein gesperrtes Einschalten ein sofortiges Ausschalten bewirkt. Das ist dann nützlich, wenn das Einschalten remote erfolgen sollte, also an den Zapfstellen-Mikroschaltern vorbei. Das kann nur ein Skript und keine Aktion.
Das Shelly RGBW Plus PM schaltet zwei LED Lampen via Bluetooth Buttons. Die Eingänge sind somit frei für andere Aufgaben. Soweit zumindest mein Gedanke. Die Schalter sollen dazu genutzt werden, das System zu steuern, wenn wir an einem Ort ohne Internetzugriff sind.
Aha, so wird ein Schuh draus. Ja klar, das geht - entweder via den von Flutschi angeregten Aktionen oder via Skript, wie bereits im Prinzip beschrieben.
Flutschi Wenn du mit "hier" die KVS Lösung von Tom-DD meinst, ja. Ansonsten wird weder beim lesen eines Zustandes (RPC Lesemethode) noch beim schreiben in eine Skript Variable in den nichtflüchtigen Speicher geschrieben.
Tom-DD Das Schreiben in den nichtflüchtigen Speicher ist nur dann relevant, wenn die Schreibdichte relativ hoch ist, also an einem Tag viele Schreibzugriffe erfolgen. Bekanntermaßen altert der nichtflüchtige Speicher mit schreiben erheblich schneller als der flüchtige Speicher. Mit Bezug auf deine KVS-Skript Lösung kann ich dir noch den Tipp geben, bei Bedarf statt KVS die Methode "Script.Eval" zu verwenden. Mit dieser kann der aufgerufenen Skriptfunktion ein Wert (hier ein boolescher Wert) via Parameter übergeben werden, welcher in einer globalen Skriptvariablen abgelegt wird. Von dieser kann deine Funktion checkPumpeAndSwitch unmittelbar lesen und braucht dazu das KVS System nicht. Nur wenn eine persistente Speicherung des booleschen Wertes zweckmäßig sein sollte, hat die Nutzung des KVS den entsprechenden Vorteil, was ich in deiner Anwendung nicht sehe.
Beispiel:
let PumpEn = false; // Globale Variable zum freigeben/sperren des Pumpen Einschaltens.
function enPumpe(en) { PumpEn = en; } // Via Methode "Script.Eval" remote aufzurufen.
function checkPumpeAndSwitch() {
if(PumpEn) {
Shelly.call("Switch.Set", { id: relay_id, on: true });
//...
}
// ...
}Zusätzlich kannst du per Schedule Job bspw. alle 60s via "Script.Eval" eine andere Skriptfunktion aufrufen lassen, die den aktuellen Eingangszustand des RGBW Shelly abfragt ...
Deine Fehlermeldung '"http" is not defined' deutet auf einen Tippfehler deinerseits hin. Du kannst alle Methoden, welche dein RGBW Shelly unterstützt mit der Methode "Shelly.ListMethods" anzeigen lassen. Ich bin davon überzeugt, dass sich die Eingänge des RGBW abfragen lassen, kann dies aber nicht testen.
d509794 Ich sah mir soeben noch einmal den von dir beschriebenen "kleinen Schönheitsfehler" an.
Ich sehe keinen Anlass, das Skript zu ändern, weil ich keinerlei unerwartete Funktion erkennen kann. Wenn der Rollladen vollständig geöffnet ist, sollte ein Druck auf die "Öffnen" Taste keine Wirkung haben, was ja bereits der Fall ist. Entsprechend bei vollständig geschlossenem Zustand.
Nur für den Fall von Eintastenbetrieb je Rollladen wäre das Skript anzupassen, aber dafür sollte es ja nie dienen.
Randy069 Ich kann ausschließlich folgende Fehlerursachen erkennen, wobei ich Tippfehler ausschließe.
Der von dir beschriebene Fehler kann keine Ursache in der Ablaufstruktur des Skripts haben.
Scheinbar können die zwei Shelly nicht via Http Ressource kommunizieren.
Solches können sie sehr wohl. Dazu gibt es einiges an Dokumentation in der API Beschreibung, u.a. https://shelly-api-docs.shelly.cloud/gen2/Component…tstatus-example
Btw, den Grund deines plötzlichen Schrittes zur zusätzlichen Verwendung eines Shelly Plus RGBW und weg vom Plus UNI zum Shelly 1 Gen. 4 habe ich nicht verstanden. Das erscheint vielleicht nicht wichtig, lässt aber zumindest meinerseits etwas mehr Durchblick zu deinem Vorhaben zu. Besonders energiesparend ist diese Kombination jedenfalls nicht.
Auf welchem der Shelly du ein mögliches, wenn auch nicht zwingend notwendiges Skript ablegst, ist gleichgültig, solange der RPC Aufruf per HTTP richtig verwendet wird.
Das Aktivieren/Deaktivieren von Actions nach Flutschi sollte mit dem RPC Sys.SetConfig gelingen - https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Sys. Bei Bedarf per Sys.GetConfig abfragen und sich etwas durchärgern!
Es kann nicht schaden, zu wissen, dass jede Konfigurationsänderung in den nichtflüchtigen Speicher schreibt, was bei einer Statusabfrage nicht der Fall ist.
Sorry, ich hatte das Gerät Shelly Plus Plug S nicht hinreichend bedacht.
Hast du Erfahrung mit Tasmota32? Wenn nicht, empfehle ich die Verwendung eines ggf. gebrauchten Shelly mit älterer Firmware zum sammeln von Tasmota32 Erfahrung - oder die eines ESP32 Entwicklungsboards zum experimentieren und kennenlernen.
Ansonsten ist die Shelly Firmware für die Shelly Geräte durchaus sehr gut geeignet, insbesondere wenn diese ausschließlich schalten. Dies kann Tasmota(32) imho nicht besser.
Gelingt das Ausschalten der rot leuchtenden LED nicht in der Output Konfiguration? (Tagsüber - soeben - getestet mit einem Plus Plug S und Firmware 1.5.1.)
Ein Argument gegen die Shelly Firmware ist leider die mittlerweile unsorgfältige Pflege dieser Firmware und die Sperre zum downgraden. Hier kann ich nur dazu raten "never change a running system." Gute, relativ unabhängige IT Fachkräfte, die sich auch gegen Kaufleute behaupten können, sind leider sehr rar.
Du wirst dazu einen FTDI Adapter brauchen und nicht per OTA flashen können. Dazu sei bspw. die flashen Sofware Tasmotizer zu empfehlen.
Damit zwingst du Tasmota32 dem Shelly auf - irreversibel.
Erklärung:
OTA (over the air) erfordert immer eine im Mikrocontroller bereits vorhandenes Stück Software, welches i.d.R ausschließlich zum updaten eines vorhandenen Systems gedacht ist, manchmal auch zum downgraden. Dieses Stück Software ist in der Shelly Firmware ausschließlich zum updaten der Shelly Firmware geeignet und insbesondere nicht für Fremdfirmware.
Empfehlung:
Baue eine berührungssichere Testschaltung aus ein/zwei Tastern, dem Shelly Dimmer und einer dimmbaren Leuchte auf und experimentiere damit! Solches schafft Erkenntnisse, insbesondere in den Konfigurationsmöglichkeiten eines Shelly.
Erst dann, wenn damit dein Ziel nicht erreichbar sein sollte, bliebe noch die Cloud (Szenen) und/oder noch weitergehender und im Zweifelsfalle besser ein Skript.
Sorry, ich fand soeben, dass ein Shelly Dimmer 2 zur Generation 1 gehört, welche nicht skriptfähig ist.
Falls du dafür einen Shelly kaufen willst, ist ein Generation 3 (+) Dimmer empfehlenswert.
Da der Shelly Dimmer 2 zwei Switch Eingänge hat, erscheint es mir zielführend zwei Taster anzuschließen, somit eher Shelly wall Switch 2 einzusetzen. Wäre deren Nutzung für deine Zielgruppe zu kompliziert?
Geht diese Kombi aus Schalter und Wall-Switch Taster?
Das geht selbstverständlich - aber s. obigen Hinweis. Man muss nicht alle Eingänge belegen. Die Frage bleibt, wie du den Dimmer steuern willst.
Es würde mir auch genügen, mit dem Wall switch auch nur ein/aus zu schalten und den shelly lediglich über die app zu dimmen.
Dazu genügt dann ein Shelly mit einem Ausgang ohne die Dimmerfunktion - oder gar ein bistabiles Relais an einem einfachen Taster.
Dies sollte per Konfiguration so nutzbar sein. Eingang auf detached und bei Statusänderung Ausgang umschalten lassen - per Action.
Nur der Vollständigkeit wegen:
Für etwas komplexere niederspannungsversorgte Schaltungen im Experimentiermodus ist ein Breadboard mit seinen vielen Steckkontakten besonders geeignet. Darauf kann eine Schaltung nicht selten auch länger "überleben" - Wochen oder gar Monate.
Boa ich dachte das ist einfacher...
Wie? Noch einfacher?
Tipp: Wer lesen kann ist klar im Vorteil. 
Noch ein ernsthafter Hinweis:
Wenn du eine Webseite mit beinhaltetem Code übersetzen lässt, verwende vorsichtshalber nie den ggf. mit übersetzten Code! Verwende stattdessen immer den Code im Original!
Dann bleibt noch 2. (s. #17):
Vertausche beide Schalter an S1, S2! Wie verhält sich die Steuerung dann?
Aber du wirfst hier mit Begriffen um dich, die ich noch nie gehört habe.
Das mag ja sein. Diese Begriffe spielen aber im Bereich IoT (Internet of Things), zu welchem auch smart home gehört, eine wesentliche Rolle.
Jetzt fühle ich mich dumm, doof, sinn und nutzlos.
Nicht doch! Jeder hat mal klein angefangen.
Und immerhin hast du mich auf die Spur von Gas-Füllstandssensoren gebracht. Ich fand solche hier:
https://www.ebay.de/sch/i.html?_nk…ksid=m570.l1313
