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.
Der 1pm mini gen3 mist die Leistung und stellt sie auch dar.
In Cloud Szenen kann ich die Leistung die der Verbraucher am Shelly zieht auch als Kriterium in einer Wenn Dann Bedingung nutzen.
In der GUI zum Einrichten von Bedingungen in lokalen Aktionen fehlt der Leistungsparameter. Da können nur Eingangs und Ausgangszustand ausgewertet werden.
Gibts einen Trick oder Workaround, um auch für lokale Bedingungen die Verbrauchsleistung als Kriterium zu nutzen?
apreick Danke. Funktioniert wie gewünscht. 
Flutschi Ich würde halt gerne verstehen, welchen Fehler ich in der Bedingung mache, weshalb die Szene nicht einwandfrei funktioniert.
Für dieses Spezielle Problem habe ich zwar einen Workaround ohne Szene gefunden. Aber
Szenen brauche ich noch für andere Aufgabenstellungen. Und da wäre es ungemein wichtig, die etwas nebulöse Arithmetik dieser verschwurbelten Bedieneroberfläche in APP und GUI zu verstehen.
Vielleicht sind es ja auch garkeine Probleme in der Logik. Vielleicht ist ja die Methode mit der Cloud einfach fehlerfördernd. Z.b. das durch Systemreaktionszeiten Shelly--Cloud--Shelly, einfach bestimmte Logiken manchmal von veralteten Bedigungen ausgehen und zu falschen Schaltvorgägnen führen.....
Flutschi
a) Das Szenen mit UND nicht so funktionieren, wie es die gegebene Logik es verlangt. (-> Fehler: Wie definiere ich die 2. Bedingung für eine UND Verknüfung in einer Szene korrekt)
b) Das es für Aktionen keine UND Verknüfung in der GUI/APP gibt.
Für letzteres hat apreick einen Workaround aufgezeigt, der bei mir nun für Aktionen wunderbar und zuverlässig funktioniert.
MIHO Danke. Der link zum Beitrag in der Wissensdatenbank , bringt schon mehr Klarheit.
Was mich noch verwirrt, ist die Aussage: "Auch wenn die ursprünglich gestartete Szene noch nicht abgelaufen ist."
Wann gilt eine Szene als abgelaufen ?
Hallo,
ich habe in einer Szene 2 Bedingungen die per UND erfüllt sein sollen, damit eine Aktion getriggert wird.
Die 1. Bedingung im UND ist der Auslöser (">600W").
Die 2. Bedingung im UND ist die erforderliche Parallelbedingung, die selbst aber nichts auslösen soll. ("Schalter aus")
Bin mir unsicher wie die Einstellung für die 2. Bedingung gesetzt werden muß, damit es korrekt funktioniert.
Habe 2 Varianten ausprobiert.
In beiden Varianten kam es zu Fehlschaltungen, dass
obwohl Kondition 2 vorhanden (Ausgang an; nicht aus), auf Basis der erfüllten Kondition 1 (>600W) die "Dann" Aktion fälschlicherweise ausgeführt wird.
Interessanterweise passiert das sporadisch und nicht regelmäßig.
Internet+Cloud Verbindung ist von allen Seiten ok.
Alle Shelly stehen auf Energiesparmodus. Spielt das eine Rolle bei der Ausführung von Szenen?
Wie muß bei der UND Verknüpfung die 2. Bedingung ("Schalter aus") korrekt gesetzt werden,
damit die Szene einwandfrei vom "Schalter ein" blockiert wird,
und nicht fälschlicherweise doch die Aktion triggert wird bei ">600W", obwohl der Schalter an ist ?
Einstellung als:
Schau mal hier rein
apreick in der Tat sehr interessant.
Da kann ich, ausgelöst durch eine Bedingung auf Shelly A,
per HTTP URL Befehl eine Aktions-Regel auf einem Shelly B aktivieren/deaktivieren,
wenn ich die ID des Regel-Webhook auf dem Shelly B kenne.
Das wäre ziemlich genau, was ich brauche. Vielen Dank.
Und im detached Mode fungieren die Komponenten einzeln und du hast bei den Actions andere Möglichkeiten zur Steuerung:
marco.gr Danke. Die Steuerung zum Detached Mode sieht in der Webdarstellung ganz anders aus als in der App. Etwas verwirrend gemacht durch die zwei verschiedenen GUI.
Im Detached Mode wird zwar der Schalter vom Relais getrennt. Aber die Logik Optionen for "Wenn" sind doch 1:1 dieselben.
Das ergibt keine Möglichkeit zur "Und" Verknüpfung.
Oder habe ich was übersehen?
Hi,
holt sich eigentlich die Shelly App die aktuellen Daten und Zustände der Shellys immer aus der Cloud ,
oder geht das auch direkt lokal innerhalb des WLAN von den Shellys ?
Wenn es mit der Shelly App nicht lokal geht,
gibt es eine andere App, die die Daten und Zustände lokal abholt und die Shelly steuern kann ?
Flutschi Oh, interessant. Wie richtet man das ein, dass das SW Signal am Shelly eine Aktionsregel im Shelly aktiviert/deaktiviert?
Sorry, ich hadere noch mit dem verständnis der Aktionsregeln:
A)
"Einmal" - Aktiviert die Szene einmal, wenn die Bedingung erfüllt ist, und erfordert zur erneuten Aktivierung die Wiederholung der Bedingung.
a1) Heißt "Wiederholung", dass die Bedingung
nachdem sie einmal erfüllt wurde und eine Aktion triggerte,
mindestens einmal nicht erfüllt sein darf,
bevor sie erneut erfüllt ist und erst dann wieder eine Aktion triggert ?
a2) Oder heißt "Wiederholung", dass die Bedingung
solange erfüllt bleibt, wie der Wert der Bedingung erfüllt ist,
= Aktion wiederholt sich im angegebenen Zeitabstand von x Minuten ?
Die Variante a1 fände ich irgendwie widersinnig. a2 logischer. Wobei beide Varianten ihren Nutzen hätten.
Habe leider keine Belege gefunden, welche Auslegung der Erklärung zutreffend = im Shelly implementiert ist.
B)
"Bei jeder Änderung" - Löst die Szene jedes Mal aus, wenn sich ein überwachter Wert (z. B. Temperatur oder Leistung) ändert und die voreingestellten Bedingungen erfüllt.
b1) Heißt "bei jeder Änderung" , das sich der Wert erstmal ändern muß, bevor die Bedingung erneut gültig wird und eine Aktion triggert?
b2) Oder heißt "bei jeder Änderung", dass bei jeder erneuten Überprüfung (welches intervall?) (auch ein unveränderter Wert) die Bedigung erfüllt und die Aktion triggert ?
Aber im Prinzip müßte beides b1 und b2 doch darauf hinauslaufen, das ein Wert fortlaufend geprüft wird, und unmittelbar daraus der Trigger einer Aktion startet. == ständiges wiederholtes triggern einer Aktion, wenn der Wert die Bedingung erfüllt.
Das deckt sich aber nicht mit meiner Beobachtung des Verhaltens der Shelly.
Deshalb die Nachfrage.
apreick Die Idee dahinter: eine Aktion soll den Shelly nur einschalten können, wenn auch der SW Eingang "on" ist.
("Und" ; Einschaltverhinderung)
Die Standardverknüfung ist ja, dass sowohl als auch - eine Aktion oder der SW Eingang - den Shelly einschalten können.
Wenn der SW Eingang im Shelly nicht per Hardware Schaltung mit dem Relais verbunden ist, sondern nur per Logik, dann könnte sowas ja möglich sein.
(Bei reiner HW Verbindung vom SW Eingang zum Relais natürlich leider nicht)
Ich glaube dieser Beitrag gehört nicht in die Kategorie Shelly 1PM Mini Gen 3
War etwas verwundert dass der Shelly mit 24V betrieben wird.
Denn nach Datenblatt braucht der Shelly 1PM Mini Gen 3 110-240V AC Versorgung.
Das Bild im post #9 hat dann geklärt, dass es um einen andere Shelly geht, der auch mit 24V DC versorgt werden kann.
Vielleicht kann ein Moderator den Beitrag mal in die zutreffende Kategorie verschieben.
Hi,
soweit ich die Funktion des SW Eingang am 1PM Mini Gen3 verstehe, arbeitet diese per default in "Oder" Logik mit irgendwelchen "Wenn" Schaltbedingungen aus Aktionen oder Szenen.
D.h. der Schalter am SW Eingang wird das Relais im 1PM immer einschalten, egal was die "Wenn" Bedingung der Aktion/Szene ergibt.
Läßt sich das irgendwie in eine "Und" Logik wandeln ?
So dass das Relais im 1PM nur dann eingeschaltet werden kann, wenn auch der SW Eingang "on" ist ?
ostfriese aha ; naja - benutzerfreundlich ist anders.
Da muß man schon tief graben, drauf zu kommen dass - und wie - man einen Shelly Bluetooth Sensor Baustein als virtual component in einen Schalt-Shelly funktional integriert.
horkatz Ja, mit Szenen geht das. Hab ich bei mir ja auch so gelöst.
War mehr daran interessiert, ob's doch noch eine gangbare Lösung über Aktionen gibt; mit Schaltzuständen, virtuellen Schaltern o.ä.
Aber das geht wohl nicht, weil (lokale) Aktionen immer nur Wenn>Dann können aber ein UND/ODER im Wenn.
Wäre ja prinzipiell machbar, wenn es Allterco im Shelly und der GUI implementieren würde,
dass man eine Wenn-Kombination aus lokalen Messwerten, Schaltzuständen und virtuellen Schaltern definieren könnte, die dann woanders eine Shelly Schalte auslöst (oder verhindert).
Das würde ich nicht unterschreiben. Dies würde bedeuten nur eine Phase C[!] würde wegen fehlendem Drehfeld nicht korrekt messen.
Ich habe nicht gesagt, dass der Messchip dann nicht korrekt mißt.
Diese Behauptung kann ich nicht aufstellen, widerlegen oder erhärten.
Aber der 3EM meckert es an, wenn die Phasen in der "falschen" Richtung drehen.
(Mindestens, wenn in den Settings "Phasenfolge überwachen" eingeschaltet ist. Zur Kontrolle.)
BlackLotus die Phase "C" ist auch gleichzeitig die Stromversorgung des 3EM gegen Nullleiter. Mindestens diese Phase must du anschließen zum Betrieb des Shelly. Du kannst dann nur Phase C mit Strommessklammer messen oder auch alle drei.
Aber nur Phase A+B zu messen und Phase C nur als Stromversorgung zu nutzen wird eher keine relevanten Daten ergeben. (technisch möglich; was Shelly draus macht, ungewiß)
Bitte beachte auch das die Strommessklammern eine definierte Durchflußrichtung haben K->L (unten draufgedruckt). Alle müssen in dieselbe Richtung zeigen.
Selbstverständlich muss die Strom Klammer und Spannung zu Phase A jeweils am passenden A Anschluß des 3EM angeschlossen sein. Sonst sind Strom und Spannung nicht phasengleich und die errechneten Werte sind Müll.
Dito für Phasen B und C
Überdies erwartet der Mess-Chip im 3EM die Drehstromphasen, die ja 120° gegeneinander versetzt sind, in genau einer Drehrichtung sortiert. Damit die MessEingänge diese Drehrichtung korrekt beibringen, kann es schonmal nötig sein zwei Phasenanschlüsse zu tauschen. (rechts- versus linksdrehend) Der 3EM hat dafür einen Prüfmodus der das feststellt.
In unserem Hausanschlußkasten hatte ich z.B. die Mit L1/L2/L3 bezeichneten Phasen einfach in der Reihenfolge A/B/C and den 3EM angeschlossen. Das war die falsche Drehrichtung der Phasen.
Also habe ich L1/L2/L3 jetzt auf B/A/C gelegt. Danach stimmte das Ergebnis.
Das kann immer zufällig falsch oder richtig sein. Ist ja eine 50:50 Chance.
Flutschi http://192.168.178.13/rpc/switch.set…&toggle_after=1
Das ist das Ergebnis der Zusammenstellung der Aktion auf der GUI, aus Bedingung (B) und Aktion (A)
Ich sehe auch nicht, dass die Bedingung ständig geprüft würde. Und daraus standig wiederkehrend die Aktion getriggert würde. (Dann würde es ja funktionieren; im prinzip auch ohne timer; dann wäre es eine kntinuierliche Statuskontrolle; was Shelly nicht hat)
So wird die Bedingung auf B nur geprüft (und Aktion auf A einmalig ausgeführt), wenn sich der Status auf B ändert (auf on)
