Beiträge von eiche

Es gibt Shelly, die keinen Neutralleiter benötigen, wofür afaik aber eine minimale Dauerlast erforderlich ist.

Du könntest stattdessen drei Shelly einsetzen, zwei brauchst du eh mindestens. Die Leitungen zwischen S2 und S3 sowie die hinführenden Leitungen zu S2 bzw S3 so umklemmen, dass sowohl Dauerphase als auch Neutralleiter dort jeweils vorliegen.

Ob dies alles so möglich ist, musst du selbst oder (besser) ein Elektriker prüfen. Die Wechselschaltung wäre dann durch einen Shelly zu ersetzen, der L2 schaltet, ich sage mal der an S3.

An S2 und an S1 jeweils einen Shelly. Der S2 Shelly braucht zwei Eingänge, also ein Shelly 2.5 oder den neueren Shelly Plus 2PM. Dieser sendet bei Schalter-/Tasterbetätigung eine Nachricht - entweder an den S3 Shelly oder an den S1 Shelly, abhängig vom betätigten Taster/Schalter. Die beiden Nachricht empfangenden Shelly schalten entsprechend.

Die Nachrichten sind per Actions zu konfigurieren und dort als URL zu hinterlegen, was nicht schwierig ist.

Btw, L1 und L2 müssen dafür nicht im selben Stromkreis (Außenleiter) liegen, weil es zwischen dem S2 Shelly und dem S1 Shelly eine Nachrichtenverbindung und keine Stromverbindung gibt.

Habe ich etwas übersehen?

Kleine Tipps für später vielleicht mal:

Um die (Nicht-)Funktion eines Bauteils zu prüfen, ist es zumeist zielführend ein anderes Bauteil einzusetzen, welches sicher funktioniert, hier bspw. einen Schalter oder einen Taster.

Außerdem kannst du den Magnetkontakt per Durchgangsprüfer testen.

Nun habe ich noch eine Ergänzung per Skript, welche ich auf Grund meiner kleinen Skripteinführung, hier Teil 3, erstellte.

Zunächst zur Ermittlung einer aktuellen Zeit:

function twoDigits(d) { // d ist als Zahl zu importieren mit 0 <= d <= 99
  return d<10 ? "0" + d : "" + d; // liefert einen String
}

function getTime() {
  let d = new Date();
  return twoDigits(d.getHours()) + ':' + twoDigits(d.getMinutes());
}

Und nun eine funktionierende Lösung zum ursprünglichen Anliegen, in welcher nur noch das tatsächliche Schalten fehlt - statt oder in Ergänzung zur Ausgabe.

Dies funktioniert bei Anschluss von Tastern, bei Verwendung von Schaltern muss das Skript ein wenig angepasst werden.

let Config = {
  enBeg: '22:00', // Begin der Freigabe
  enEnd: '06:00' // Ende der Freigabe
}

function switchToggle(id) {
  print("trying switch " + id + " to toggle");
}

function switchDepend() {
  if(event.component!==undefined && event.component==="input:0") {
    let t = getTime();
    if(Config.enBeg > Config.enEnd) {
      if(t > Config.enBeg || t <= Config.enEnd) switchToggle(0);
    } else {
      if(t > Config.enBeg && t <= Config.enEnd) switchToggle(0);
    }
  }
}

// Registrierung von switchDepend als EventHandler
Shelly.addEventHandler(switchDepend);

Ich ging für den Versuch und insbesondere die Fehlersuche

1. nicht davon aus, dass mehrere Taster/Schalter mit je einem Eingang verbunden sind und da nun doch,
2. dass diese Dinger im "Schaltplan" Taster und keine Schalter sind.

Hoffentlich sind es Taster, die alle Schließer oder alle Öffner sind und nicht etwa gemischt.

Vielleicht auch nicht "hoffentlich", wenn anders der/die Fehler leichter gefunden werden könnten.

Ich bin gespannt, was herauskommt. Menschengemachte Fehler gibt's, die gibt's gar nicht.

Zitat von DerSchroeder

In der Applikation wäre es Wünschenswert, Pfeile für auf/(stopp)/zu (hoch/runter) zu haben.

Hm, auf welchem Gerät soll denn die "Applikation" laufen, die ich als Mensch-Maschinen-Schnittstelle interpretiere und somit nicht die Steuerungsapplikation darstellt.

Diese Schnittstelle ist dann das Bedienungs-Fronend.

Hierfür kann bspw. das Skript eine Webseite liefern, welche solche Bedienungselemente beinhaltet. Das wäre der direkte Weg, der auch dann möglich ist, wenn das WLAN ausgefallen ist - dann stünde noch der Shelly eigene Access Point zur Verfügung.

Eine etwas weniger ausfallsichere Alternative wäre ein übergeordnetes System, welches ein Dashboard zur Verfügung stellt.

Edit:

Selbstverständlich können an die beiden binären Eingänge des Plus Uni auch zwei Taster angeschlossen werden und damit die "Torfahrt" relativ unmittelbar gesteuert werden.

Taster 1 für auf und stopp, Taster 2 für zu und stopp.

Edit 2:

Für noch mehr Sicherheit kann ein Hardware Timer als Watchdog hinzugefügt werden, welcher regelmäßig vom Shelly gefüttert wird. Habe ich ebenfalls in #9 angedeutet. Dies ist aber wegen der zwei Uni Ausgänge nicht leicht zu bewerkstelligen bzw. ich weiß noch nicht, über welchen Anschluss der Timer (re)getriggert werden kann.

Edit 3:

Noch besitze ich keinen Plus Uni. Ich sah soeben in der Doku, dass dieser auch einen Zähleingang besitzt. Somit wäre eine Ansteuerung per optisch-elektrischem Resolver möglich - und unter Verwendung zumindest einer Referenzposition deutlich präziser. Das sei nur für zukünftige Verbesserungsabsichten erwähnt. Vermutlich gibt es auch Resolver mit Hall-Sensoren (reagieren auf magnetische Felder).

Mein Beitrag #9 gibt eine machbare Richtung an, incl. Sicherheitsaspekt.

Der Shelly Plus Uni kann Skripte abarbeiten und man kann, wenn man es kann , anwendungsgerechte Schedule Jobs anlegen.

Das Skript entnimmt dem analogen Eingang die Spannung, selbstverständlich digitalisiert, und vergleicht mit den beiden Spannungswerten, welche per Versuche ermittelt werden.

Auf Grund dieser Vergleiche wird das Tor entweder angehalten oder gefahren.

Falls du dich nicht an das Skripten heranwagen solltest, hier gibt es Mitglieder, die das erstellen können.

Ich kann es derzeit wegen Abwesenheit nicht. Ich kann nur das Prinzip erläutern.

Da eine S7 auch nur ein Programm abarbeitet, ist eine Umstellung auf einen Plus Uni locker möglich.

Meine Berücksichtigung des Sicherheitsaspektes liegt in der Verwendung eines Schedule Jobs, welcher sekündlich sowohl eine Skriptfunktion aufruft als auch den Schaltshelly dazu bringt, den Antrieb auszuschalten. Hierbei ist es sehr empfehlenswert, an den Plus Uni ein Relais (evtl. Puls gesteuert) zwecks schalten des Torantriebs anzuschließen anstatt einen anderen Shelly dafür zu verwenden. Letzteres erfordert bekannterweise eine Kommunikation per WLAN, was ausfallen kann.

Btw, bei einer (schwierigen) Fehlersuche sollte man zunächst möglichst viel ausschließen und den Fokus auf das Angestrebte richten.

Das bedeutet hier, vorbereitend sämtliche (auch wenig vorstellbare) Fehlerquellen abstellen.

Hier konkret:

Es darf keine andere Quelle als der betreffende Shelly eine Nachricht an diesen senden - Cloud weg, andere Shelly weg, die an den betreffenden senden ...

Ob dies letztlich hilft, weiß ich nicht, es ist aber ein zielführender Weg.

Zitat von eiche

Als Ersatz für VPN, wenn man einen remote Zugriff auf ein Skript braucht?

Meine Intention war, dies als offene Frage zu stellen - nicht als ein Infragestellen. Sorry, wenn es anders interpretiert wurde. Ich hatte auch keine Info darüber, dass der TE remote am Shelly arbeiten wollte, was ja auch offensichtlich nicht der Fall war. Demzufolge passte mein Vergleich mit der Fahrt über Kairo durchaus.

Flieger42

Zitat von Flieger42

Ich kann also nicht einfach sagen ihr seid detached. Ich wüsste auch nicht wie das gehen sollte. Habe es dennoch eingestellt gehabt und funktioniert nicht.

Ich finde, dass diese Aussagen widersprüchlich sind. Vielleicht bin ich mit zu wenig Fantasie ausgestattet, um diese in Kombination interpretieren zu können.

Wenn du nicht weißt, wie du ein detached einstellen (besser als "sagen" ) kannst, dann hast du es trotzdem eingestellt? Merkwürdig ...

Zitat von Flieger42

Im übrigen geht dann gar kein Licht mehr an. Wie auch wenn der Schalter nicht weiß was er machen soll.

Vielleicht hilft zum Verständnis ein mehr technisch orientierter Sprachgebrauch.

Der Schalter hat nicht die geringste technische Intelligenz, die hat der Shelly. Die Firmware des Mikrocontrollers im Shelly erfasst, wenn am Eingang eine Pegeländerung vorliegt. Daraufhin kann sie zweierlei Aktionen abarbeiten.

1. Den zugeordneten Ausgang schalten.
   Dies tut sie, wenn der Eingang nicht auf detached konfiguriert ist.
2. Zusätzlich oder anstatt (bei detached) ein HTTP GET Request mit einem per Konfiguration eingetragenen URL senden.
   Dieses ist hier afaik dein ursprüngliches Anliegen.

Ich weiß nicht, ob dies so geschehen wird oder kann, wie ich das Folgende schildere. Ich kann es gegenwärtig nicht testen, weil ich weit weg von meinen Schaltern und Tastern bin.

Angenommen, der Eingang 0 ist nicht auf detached konfiguriert.

Ein Taster an diesem Eingang wird betätigt.

Demzufolge schaltet der Ausgang 0.

Zugleich wird ein HTTP GET Request mit dem URL an denselben Shelly gesendet, welcher ein Schalten des Ausgangs 0 bewirken soll, möglicherweise dem Schalten per Taster entgegenwirkend.

Die Wirkung könnte keine oder ein extrem kurzes (höchstens wenige ms) Um- und wieder Zurückschalten des Ausgangs 0 sein.

Ich denke, dass du aus einem solchen Grund erst einmal versuchen solltest, den HTTP GET Request mit einem konfigurierten detached zum funktionieren zu kriegen.

Dazu kannst du ja zwei solcher URL konfigurieren, einen zum selben Shelly und einen anderen zu einem anderen Gerät, um zu sehen, ob das andere Gerät reagiert.

Sorry, falls du das Letzte bereits getan haben solltest.

Ich wusste nicht, dass ein Skripten über die Cloud möglich ist. Wozu soll das gut sein? Als Ersatz für VPN, wenn man einen remote Zugriff auf ein Skript braucht?

Das ist ja so, als wenn ich von Frankfurt nach Kassel über Kairo fahren wollte.

Siehst du unter dem Editierfenster den blauen Schriftzug "Console" und in der selben Höhe rechts ein ">" Zeichen?

Dann klicke auf eines von beiden!

Wenn das nicht hilft:

Welcher Shelly?

Welche Firmware-Version?

Sind die Browser halbwegs aktuell?

Browser Cache geleert?

printf() gibt es in C, nicht hier. Hier gibt es print() oder console.log().

Interessante Kombination.

Detached bedeutet, dass der Eingang nicht (unmittelbar) auf den Ausgang wirkt.

Das erscheint mir zweckmäßig, wenn du eine Veränderung am Eingang bzw. Tastendrücke per Action (URL) verarbeiten lassen willst.

Ein Momentary mit solchen Actions habe ich noch nie versucht.

Diese Kombination erscheint mir aber als gegenseitig störend.

Somit solltest du Detached ausprobieren.

Du willst offenbar nicht verstehen, dass eine Nichtbewegung nicht erkennbar ist, dafür aber die Dauer von ausbleibenden Bewegungserkennungen.

Für Letzteres gäbe es bei entsprechender Ausstattung eine Möglichkeit.

Dazu müsstest du dir aber mehr Mühe für grundlegendes Verstehen geben, als du bisher gezeigt hat.

Ich schließe somit mein Bemühen hiermit ab.

Genau! Immer, wenn etwas per App oder Cloud nicht gelingt, sollte man den nächsten Weg versuchen - und das ist Browser mit Shelly IP-Adresse als URL ...

Zitat von Radnabe

Du hattest dich bereit erklärt, das zu testen, denn du hast den Motion 2.

Ich habe einen Motion ohne 2. Ich kann ausschließlich prüfen, ob man an einem solchen Motion die Bewegungserkennung bzw. -Action deaktivieren kann. Da ich derzeit weit weg von meinen Shelly bin, kann ich nicht den Erfolg prüfen. Eine Deaktivierungsmöglichkeit fand ich bisher nicht.

Zitat von eiche

Ein Motion bietet das Auslösen einer Action (URL) bei "END OF MOTION DETECTED".

Darauf bist du nicht eingegangen. Vielleicht täte dich so etwas deinem Ziel näher bringen, falls es am Blu Motion existiert.

Zitat von Radnabe

Entweder er erkennt eine Bewegung oder nicht. Das will ich wissen. Wie du es sprachlich formulierst, ist mir egal.

Die Nichterkennung einer Bewegung ist etwas anderes als die Erkennung von einer Nichtbewegung. Es ist durchaus nicht egal, wie es tatsächlich gemeint ist.

Zitat (ließ sich nicht einfügen): Prüfen, ob nun tatsächlich keine Bewegung erkannt wird.

Wie willst du etwas prüfen, was nicht erkannt werden kann?

Du kannst allenfalls (per Skript) prüfen, wie lange keine Bewegung erkannt wurde.

Bäh, das sieht nach Cloud bzw. App aus - wenig für Experimente geeignet.

Noch einmal gefragt: Welcher Shelly ist der betreffende? Genaue Bezeichnung bitte!

Retriggerung bedeutet, dass ein getriggerter Zustand, der nur eine gewisse Dauer, bspw. 2 Minuten, andauern soll, durch einen erneuten Trigger wieder gestartet wird.

zum Bsp: Nun wird getrriggert -> Zustand für 2 Minuten ein, nach 1 Minute wird erneut getriggert -> Zustand für weitere 2 Minuten ein, also insgesamt 3 Minuten ...

Zitat von Radnabe

vor dem Gerät einen Jive tanzen

Hast du Aufnahmen davon?

Ein Bewegungsmelder kann nicht keine Bewegung erkennen, aber etwas ähnliches vielleicht.

Ein Motion bietet das Auslösen einer Action (URL) bei "END OF MOTION DETECTED".

Zitat von Radnabe

Auch wenn ich die Nachrichten ignoriere, meldet das Blu Motion dennoch nicht, ob sich jetzt etwas bewegt, sondern auch ob sich innerhalb der letzten 30 Sekunden

Schwer verständlich. Ein (Blu) Motion sollte nach Ablauf einer Blind Time immer eine Bewegung erkennen und die Action auslösen.

Zitat von Radnabe

Eigentlich programmiere ich gern, aber wenn ich die riesigen Beispielcodes sehe, scheint mir das bei Shelly eher aufwändig. Aber ich komme wohl um die Skripts nicht herum.

Vielleicht hilft dir für den Anfang meine Skripteinführung, der Rest besteht im Studium der relativ ausführlichen Dokumentation - insbesondere der "Methoden".

Nun, es sollte zwar mit "localhost" gelingen, probiere trotzdem mal 127.0.0.1!

Zitat von Flieger42

Kann das irgendwas mit dem Punkt "Anmeldung einschränken" zu tun haben?

Das kann sein. Dann wären Anmeldedaten in den URL einzufügen.

Das kannst du aber doch ganz leicht selbst herausfinden, indem du im Ziel-Shelly die geforderte Authentifizierung temporär entfernst und damit die Funktionstüchtigkeit prüfst.

Zitat von Flieger42

Welche Gründe kann es haben, dass genau die Einstellung, wie beim TE beschrieben bei mir dennoch nicht funktionieren?

19784.5 Grunde

Dazu solltest du uns erst mitteilen, welche Shelly beteiligt sind.

Und noch etwas fällt mir bei genauerem Hinsehen auf.

Das Skript gibt jeweils bzgl. des Schaltens etwas aus, was "es nur vermuten kann", aber nicht vom beauftragten Gerät bzw. der Methode als Antwort kommt.

Das ist nicht geeignet und führt zu nicht sicheren Beobachtungen.

Hierfür sind Responses oder callback Funktionen einzusetzen.

Bei Einsatz von HTTP.Get ist die Antwort auszuwerten, die bei Shelly.call("HTTP.Get", ...) in der callback Funktion per Parameter (oft result benannt) eintreffen sollte.