Beiträge von eiche
-
-
Zu 1.
Jeder Shelly ab der zweiten Generation kann flexibel konfiguriert werden, was zunächst alles ermöglichen dürfte, was du möchtest. Somit kannst du einfach hinter jeden Schalter/Taster einen solchen Shelly hängen, solange dort L und N verfügbar sind. Es ist halt zwingend WLAN erforderlich. Ob du dann zusätzlich an jeder Lichtquelle noch einen Shelly als Schaltaktor brauchst, hängt von den vorliegenden Leitungen ab.
Beispiel:
Die Lichtquelle wird per Shelly Plus 1(PM) am Lampenschluss geschaltet, d.h. die Lampe wird nicht mehr per Schalter unmittelbar sondern ausschließlich per Shelly geschaltet. Dann braucht jeder Schalter/Taster, der diese Lichtquelle schalten können soll, einen Shelly als Sensor und Nachrichtensender. Der Sensor-Shelly braucht selbstverständlich kein Relais, weil er selbst nicht schaltet.
In einer solchen Zusammenstellung kannst du, wann immer du willst, die Zuordnungen Schalter -> Lichtquelle ändern.
zu 2.
Prinzipiell ist das möglich, aber nicht immer empfehlenswert. Die Schalt-Shelly werden zwar zumeist mit bis zu 16A angegeben, aber ca. max. die Hälfte (8A) ist als empfehlenswert anzunehmen. Alternativ kannst du dafür einen Shelly Plus Plug S als intelligenten Zwischenstecker nutzen. Dieser trägt zwar auf, du kannst ihn dann aber jederzeit entfernen, wenn du einen Verbraucher mit hoher Leistung einstecken willst.
zu 3.
Das gelingt sehr gut mit jeweils einem Shelly Plus 2PM je Rollladen, ggf. mit einem Plus AddOn zum anschließen und auswerten eines Lichtsensors.
Einschränkung: Wenn die vorhandene Steuerelektrik per Funk gesteuert wird, kann es schwierig werden.zu 4.
Ich bekäme das hin. Aber nicht die "Rädchen" selbst sondern die Steuerung der Ventile, ggf. nach Austausch der Ventilantriebe - ist vermutlich nicht erforderlich.
zu 5.
Keine Ahnung. Ich verwende einen Raspberry Pi mit Mosquitto, Node-RED, Influx, Grafana und bekam bisher damit noch alles hin, was ich wollte.
Btw, ab der zweiten Shelly Generation können die meisten Geräte per Skript noch anwendungsgerechter programmiert werden.
-
Um eine "Alexa"-Anweisung parametrieren zu können - hier ist die Dauer der Parameter, müsstest du
- dich entweder mit AWS und eigener Programmierung zur Auswertung eines Sprachnachricht-Textes
- oder bspw. per Node-RED einen geeigneten Amazon Echo Node verwenden.
zu 1. Das habe ich bisher selbst nicht versucht.
zu 2. Solches hatte ich mal getestet, was, soweit ich erinnere, auch funktionierte.
Die Alternative wären die von DIYROLLY erwähnten Routinen, zu welchen du aber nur die darin festgelegten Dauern zielführend benutzen könntest, weil diese keine Parameter sind.
-
Deine Schaltung ist gewöhnungsbedürftig, um es vorsichtig auszudrücken. Hast du diese geplant? Hast du diese per trial and error "herausgefunden"?
Die folgende Schaltung ist angemessener und dürfte ebenfalls funktionieren. Ggf. musst du hierfür den Eingang S1 = "input:0" zurück konfigurieren (non inverted).
Hiermit wird, wie technisch zweckmäßig und üblich, der Außenleiter (Phase) geschaltet.Shelly-Plus-2PM_Außenleuchte-mit-Bewegungsmelder_Steinel-L22-S.png
Nur für den Falls, dass, aus mir unbekannten Gründen, diese Schaltung nicht wie gewünscht funktionieren sollte, wäre der Grund für dieses Nichtfunktionieren wissenswert.
-
-
You may use this script. Then you should at least understand the configuration of the script and adapt it yourself.
But what can you do if you want to make a change?
It will be relatively difficult to understand the entire script. I recommend this script only if you are able to understand it.
A much smaller and simpler script is sufficient for your intention. And it's best if you put together the script yourself. You decide for yourself. Perhaps my script introduction (in german) may help you.
If you want a simple script, I might be able to help you with that. I don't want to support the above script because it should only be used if you understand it.
-
You need the following:
- a Shelly measuring the power consumption - or two Shelly, one measuring the power consumption, the other switching your fan
The script should be run on the measuring Shelly, but it can also be run on the switching Shelly.
When using only one Shelly, channel 1 must be permanently switched on. - a configuration sequence containing the temperature threshold like
let MinPower = xx; - an event handler function that selects the appropriate events
- an instruction that adds the event handler function to the firmware
Have a look at Shelly Script Language Features and the using of event handler!
- a Shelly measuring the power consumption - or two Shelly, one measuring the power consumption, the other switching your fan
-
Yes indeed, that's why the Shelly firmware publishs its online status retained.
Btw, I've described this MQTT mechanism by the Shelly firmware - in german.
-
interested by eiche
-
Es mag für diesen Thread nicht relevant sein, was ich nicht einschätzen kann, da ich keine passende Konstellation nutze. Also bitte nur als ergänzenden Hinweis zu MQTT und Tasmota auffassen!
Nach meiner weiter zurückliegenden Erfahrung sendet Tasmota(32) ständig MQTT Nachrichten, auch dann wenn das regelmäßige Protokollieren ausgeschaltet ist. Außerdem kann es bei Verwendung von retained Nachrichten zu Phantom-Schaltvorgängen kommen. Deshalb sollte im Zweifelsfalle retained vermieden werden.
Da dies nichts mit einem IP Adressen Scan zu tun hat, glaube ich nicht an retained als Ursache. Ich verwende gelegentlich zum Scannen den "Angry IP Scanner". Es wäre interessant, ob solche unerwünschten Schaltvorgänge auch bei diesem Scanner auftreten.
-
Du kannst beide URL in einem Web Browser testen. Du wirst dann als Antwort "erledigt" oder "nicht erledigt" erhalten, abhängig davon, ob dein Wollen zum Öffnungszustand passt.
-
Ich habe ein möglichst einfach verwendbares Skript erstellt. Dieses stellt zwei sog. HTTP Endpoints zur Verfügung.
- Zum öffnen des Tors per Impulsausgabe, wenn der "Geschlossen-Sensor" dies signalisiert.
- Zum schließen des Tors per Impulsausgabe, wenn der "Offen-Sensor" dies signalisiert.
Ich konnte mangels zweier Sensoren nicht alles testen. Es sollte aber wie gewünscht funktionieren, wenn ich die Wirkung der Impulsausgabe richtig interpretierte (s. #5).
Wenn du das Skript bei geöffnetem Editierfenster startest, erhältst du zwei Sekunden danach im Protokollfenster zwei Ausgaben, etwa so:
Deine IP Adressen sind anders zu erwarten und die Skript Id (hier 1) kann anders sein, wenn du noch andere Skripte auf dem Shelly Plus 1 gespeichert hast.
Hier das Skript. Kopiere es per Kopier-Symbol oben rechts und nicht etwa per markieren ...!
Code
Alles anzeigenlet Response = { did : "erledigt", didnt: "nicht erledigt" }, Component = { // Components zu beiden Magnetschaltern opened: "input:100", closed: "input:101" }, Duration = 0.5; // Impulsdauer in Sekunden function impulseOut(dur) { Shelly.call("Switch.Set", {id:0, on:true, toggle_after: dur}); } function sendResponse(response, body) { response.code = 200; response.headers = [["Content-Type", "text/html"]]; response.body = body; response.send(); } function openGate(request,response) { let closed = Shelly.getComponentStatus(Component.closed); let doit = closed!==null && closed.state; if(doit) impulseOut(Duration); sendResponse(response, (doit ? Response.did : Response.didnt)); } function closeGate(request,response) { let opened = Shelly.getComponentStatus(Component.opened); let doit = opened!==null && opened.state; if(doit) impulseOut(Duration); sendResponse(response, (doit ? Response.did : Response.didnt)); } let openUrl = null, closeUrl = null, localIP = Shelly.getComponentStatus('wifi').sta_ip; Timer.set(2000,false, function(){ openUrl = 'http://'+localIP + HTTPServer.registerEndpoint('open', openGate); closeUrl = 'http://'+localIP + HTTPServer.registerEndpoint('close', closeGate); print("open URL: " + openUrl); print("close URL: " + closeUrl); } );
Bei Fragen stehe ich selbstverständlich zur Verfügung.
Edit:
Per open URL kannst du das Tor öffnen lassen wollen, per close URL schließen lassen wollen. Es wird aber nur dann geöffnet, wenn es geschlossen ist und umgekehrt. -
Ergänzung
Nach deinem Beitrag #1 reagiert der Torantrieb auf einen Impuls jeweils mit der gegenteiligen Aktion zur vorherigen. Tor schließt wenn zuvor geöffnet und umgekehrt. Stimmt das?
Dann sehe ich keinen Anlass, den Impuls nur unter einer erfüllten Bedingung ausgeben zu lassen. Entscheidend wäre vielmehr, den Öffnungszustand als Anwender zu erkennen.
Aber vielleicht habe ich die erforderliche Beschaltung und deren Signalgebung noch nicht verstanden ...
Edit:
Ich habe nachträglich erkannt, dass du zwei Auslöser möchtest und jede der beiden Auslösungen nur bedingt wirken sollen. Ok soweit. Ich schaue mal, ob ich auf die Schnelle ein kleines Skript baue. -
- Weil Cloud nicht erforderlich ist, nur etwas einfacher.
- Weil ich für Sicherheit relevante Einrichtungen nur lokal implementieren würde. Was nicht raus geht, kann weniger ausspioniert werden.
- Weil es nicht funktioniert, wenn auf die Cloud nicht zugegriffen werden kann.
Genügen diese Gründe? Dies schließt allerdings afaik "Nachricht an Alexa" aus.
Also kann ich erst einmal den Versuch mit Actions (=Webhooks) empfehlen, weil diese rein lokal arbeiten können. Damit kannst du einfach mal versuchen, dein Ziel zu erreichen.
Ich bin in Actions nur teilfit, weil ich oftmals Skripte mit deren höchstmöglichen Flexibilität bevorzuge.Edit:
Für dein Anliegen sollte es genügen, irgendetwas Optisches wie Signalleuchte, Leuchtring an einem Shelly (Plus) Plug S, Symbol in einem Dashboard ... genügen. Was hierfür auf relativ einfache Weise implementierbar ist, hängt von deiner bisherigen Ausstattung ab. -
Maybe you have that activated? Sorry, I use the german UI.
-
Du willst ein Tor remote steuern, ohne dessen Umgebung einsehen zu können?
Hast du dafür eine Versicherungsgesellschaft gefunden, die solches versichert?
Dies mal unabhängig davon, wie es implementierbar ist. Und wenn du das nun noch immer willst, dann doch bitte ohne eine Notwendigkeit einer Internetverbindung, also ohne Cloud und möglichst mit weiteren Sicherheitseinrichtungen. Solches ist erst einmal möglich - wenn nicht per Actions, dann jedenfalls per Skript.
Ich hoffe, dass meine Warnhinweise verständlich sind.
-
Alles gut Thomas. Solche Hinweise können durchaus nützlich sein. Ich denke, dass wir beide die beiden Endpunkte einer Implementations-Skala aufgezeigt haben und nun der TE am Zuge ist.
Edit: Vielleicht ist "Skala" schlecht gewählt und die Implementationsmenge hat eher eine zweidimensionale Gestalt.
-
Was erreicht man aber mit dem Ersatz des einen Wechselschalters durch einen (per Software-Regel konstruierten) Umschaltkontakt? Nichts, meine ich.
Das weiß ich nicht, aber die vom TE genutzte Tasmota Rule tut solches. Deshalb unterstelle ich einfach mal, dass er weiß, was er damit erreichen will. Ich muss nicht alle Situationen kennen, in welchen "ungewöhnliche" Konstellationen verständlich werden.
Btw, in einem anderen Thread hat mir ein anderes Mitglied per PM plausibel mitgeteilt, warum er etwas erreichen will, dessen Sinnhaftigkeit angezweifelt wurde. Wegen PM will ich dies nicht öffentlich darlegen.
-
SeeHome2024 meint nicht den Einbau eines Shelly in eine Wechselschaltung, sondern eine automatische Umschaltung zwischen den beiden Ausgängen - ähnlich einer Rollladensteuerung.
Solange diese Tasmota Rule arbeitet, ist immer einer der beiden Ausgänge eingeschaltet und der andere ausgeschaltet, wobei Power1 der Master ist.
In Shelly Notation sind Power1 "switch:0" und Power2 "switch:1".So etwas sollte bereits mit Actions (=Webhooks) lösbar sein. Schaue einfach mal unter Actions nach und analysiere deren Konfigurierbarkeit!
Sollte dies nicht gelingen, kann dafür ein kleines Skript eingesetzt werden.
-
Nachteil wäre, dass man keine Benachrichtigung bekommt, wenn das Wasser alle ist, aber das könnte man dann immer noch über den Verbrauch ermitteln
Kriegst du solches per Action hin? Wenn nicht per Szene, also wieder Cloud? Eine solche Mitteilung dürfte ja nur dann erfolgen, wenn trotz eingeschaltet Seins die Leistung 0 ist.