Beiträge von bp4willi

    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?

    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)

    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 ?

    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)

    Aha, also gibts da wohl wirklich nur sinnvolle Anwendungen über Skript Programmieren.
    Schade.
    Nix für non-IT Anwender.
    Sowas hätte Allterco doch auchmal anwendungstechnisch für Laien in der Web Gui oder App hübsch machen können.

    Flutschi Habs ausprobiert. Funktioniert nicht.
    Shelly B ist on ; Aktion in Shelly B definiert (wenn B on), um Shelly A für 1 sec off zu schalten.

    Resultat: geht B auf on - > schaltet A für 1 sec off und danach wieder on. = leider falsch.

    Solange B = on ist, soll A = Off bleiben.

    Ich hatte noch über virtuelle Komponente in A nachgedacht, die über B geschaltet wird.
    Aber leider können die Shellys anscheinend garkeine UND logik von physischen/virtuellem Schalteingang und weiteren lokalen Bedingungen. (zumindest über die WebGui und App nicht) :-((

    Hi,

    was kann man für schöne Sachen mit diesen virtuellen Komponenten anstellen (ohne skripting!) ?
    Hab hier im Forum nichts drüber gefunden.
    Hatte gedacht, dass man damit ggf einen virtuellen Eingangsschalter an einem Shelly erzeugen kann, und damit endlich eine und/oder Logik innerhalb einer Aktion erstellen könnte.

    Leider nein.
    Bisher sehe ich nur, dass man mit virtuellen Schaltern dasselbe machen kann, wie zwischen Shellys direkt ohne virt.Sch. auch.


    Für welche Anwendungen, bringen die virtuellen Komponenten also einen neuen Nutzen?
    Vielleich hat ja jemand schon was spannendes realisiert, aus dem man lernen kann.
    (Bin nur an Anwendungen ohne Skripting interessiert)

    Du kannst doch wenn Shelly B an per Aktion Shelly Aeinen off timer von 1 Sek. geben.

    Flutschi Verstehe deinen Vorschlag leider nicht.
    Was soll mir für Shelly A ein off-timer von 1 sekunde bringen,
    wenn Shelly A ggf. über Stunden und Tage off bleiben soll ? (indiziert über Shelly B zustand)

    nur wenn B irgendwann off ist, darf A wieder on geschaltet werden.

    Danke horkatz vielleicht habe ich den anderen Ansatz gefunden.

    Geht leider nicht mit Aktionen, weil man zwei Bedingung Verknüpfen muss.

    Und es braucht einen weiteren Shelly Ausgang, der als Status Memory dient.

    Die Schritte:

    Durch eine Bedingung in einer Aktion/Szene werden Shelly A aus und Shelly B eingeschaltet.

    Shelly B wird über einen Timer oder eine andere Bedingung irgendwann ausgeschaltet.

    Das weitere geht leider nicht mit Aktionen, weil man da keine 2 Bedingungen verschiedener Shelly kombinieren kann.

    Stattdessen wird in einer Szene zwei Bedingungen so definiert, dass Shelly A nur wieder eingeschaltet werden darf, wenn Shelly B aus ist. (Und)

    D.h. Shelly A bleibt mindestens solange aus, wie Shelly B an ist.

    Selbstverständlich wird das durch manuelles schalten oder Aktionen ausgehebelt, oder falsche Szenen.

    ------

    Aber es ermöglicht zumindest sowas in einer PV Anlage mit Batteriespeicher:

    Ein Wechselrichter an einer Batterie, wird je nach Energiebedarf ein und ausgeschaltet. (A)

    Ist aber die Batterie leer, kann der Wechselrichter solange nicht eingeschaltet werden, bis die Batterie wieder aufgeladen ist. (B)

    Hätte man sicher auch über einen invertierten Schalteingang am Shelly für den Wechselrichter machen können. Zum Batteriespannung messen wird aber der Uni eingesetzt, und dessen Schaltkontakt kann kein 230V AC schalten.

    Also muss es über eine Szene und zwei Bedingungen gelöst werden.

    Wenn einer eine einfachere Lösung hat, lerne ich gerne dazu.

    Mal abgesehen von der MAC thematik .....
    Würde der Shelly nicht einfach auch über RPC Http kommandos direkt über Bluetooth oder seine WLAN IP adresse akzeptieren und ausführen ?
    Oder wie ist das auf dem Shelly blockiert ?