Beiträge von eiche

Zitat von ToLa62

Mal angenommen, ich würde diesen Weg gehen. Ich hätte trotzdem wieder eine Inter-Shelly-Kommunikation.
Die ließe sich (nach meinen naiven Annahmen) nur vermeiden, wenn ich eine Drahtverbindung zwischen Sensor und Add-On auf dem Shelly herstellen würde.

Die Kommunikation zwischen einem Nicht H&T Shelly und dem Schalt-Shelly funktionieren nach meinen Erfahrungen sehr zuverlässig.

Ich finde schlicht keine verständliche Ursache für das Nichtsenden des H&T im kurzen Zeitintervall.

Auch kann ich derzeit wegen Abwesenheit meinen einzigen Plus H&T dbzgl. nicht testen.

Die Nutzung der Cloud ist jedenfalls eingeschränkter als eine lokale Nutzung, bei welcher ausschließlich die beteiligten Shelly miteinander kommunizieren.

Zitat von ToLa62

13:55-14:25 -> ob tatsächlich das T-Kriterium weggelassen wird, kann ich nicht sicherstellen, da ich im GUI für die Action zwingend eine Überprüfung der Temperatur drin haben muss,

Das sehe ich anders. Wenn der H&T alle 5 Minuten seine Temperatur per Aufruf der Skriptfunktion mitteilen kann, genügt das völlig. Ob dies auf einem H&T als Action konfiguriert werden kann, weiß ich derzeit nicht. Mit einem messenden Plus 1 gelänge dies per Skript leicht. Der Action URL müsste sinngemäß wie folgt lauten.

http://192.168.178.16/rpc/script.eval?id=<Skript Id>&code="htTest(<aktuelle Temperatur>)"

Selbstverständlich muss dann die Skriptfunktion einen Parameter importieren, bspw. so:

function htTest(temp) {
    print("htTest wurde aufgerufen. Temperatur: ", temp);
}

In einem Mess-Shelly Plus 1 mit AddOn werden die Temperaturen in ca. 1 minütigen Abständen (nicht ganz regelmäßig) erfasst und können bspw. per Skript an den Schalt-Shelly gesendet werden. Dies täte sicherer funktionieren als mit einem H&T, der nicht skriptfähig ist. Die Zeitintervalle können auf dem einen oder dem anderen Plus 1 in ein Skript konfiguriert werden. Auch Schedule Jobs könnten eingesetzt werden.

Die Actions sind für Leute, die per Klicks, Auswahlen und wenigen Eingaben etwas erreichen wollen - und möglichst keine Wunder erwarten sollten.

Mit einem Skript ist man erheblich flexibler und kann viel mehr erreichen als mit diesen Actions. Ich nehme auch eine Action, wenn dies bereits genügt, aber in vielen meiner Einsatzzwecke genügen solche Actions nicht.

Das angepasste Skript.

Es enthält zusätzlich die Funktion toggleSwitch() für einen entfernten Auftrag, bspw. von einem i4.

let on = null; // output status
let th = null; // timer handle
let src = null; // source of switching

function send_response(response, body) {
    response.code = 200;
    response.body = body;
    response.send();
}

HTTPServer.registerEndpoint('on',
  function (request, response) {
    send_response(response, "OK");
    if (on!==true) {
      src = 'motion';
      Shelly.call("Switch.set", {'id': 0, 'on': true});
      if (request.query.length > 0) {
        let dur = JSON.parse(request.query);
        // print(dur);
        if(!isNaN(dur) && dur>0) {
          th = Timer.set(Math.floor(1000*dur), false,
            function () {
              Shelly.call("Switch.set", {id: 0, on: false});
            }
          );
        }
      }
    }
  }
);

Shelly.addEventHandler(function(e) {
  on = e.info.state;
  if (e.component==="input:0" || src!=='motion') {
    Timer.clear(th);
  }
});

// Für einen entfernten toggle Aufruf, bspw. von einem i4.
function toggleSwitch() {
  Shelly.call("Switch.Toggle", {id:0},
    function (result, errcode, errmsg) {
      if(errcode!==0) print("error in toggleSwitch:", errcode, ", ", errmsg);
      else src = 'remote';
    }
}

//Do some user friendly printout
function messages() {
  let ipAddress = Shelly.getComponentConfig("wifi").sta.ip;
  let myId = Shelly.getCurrentScriptId();
  print('Your motion url is: http://' + ipAddress + '/script/' + myId + '/on?<duration in seconds>');
  print('When switching via remote command the url at the remote action is:');
  print('http://' + ipAddress + '/rpc/script.eval?id=' + myId + '&code="toggleSwitch()"');
}

Timer.set(2000, false, messages);

Ich kann es gegenwärtig nicht testen, könnte aber funktionieren. Das Skript reagiert nun sowohl auf einen Schalter am Eingang 0 als auch auf einen Fernaufruf vom i4.

Nach dem Skriptstart erhältst du im Protokollfenster zwei Ausgaben.

1. Den URL für den motion.
2. Den URL für den i4

Teile bitte den Erfolg bzw. Nichterfolg mit!

Du kannst den Skriptinhalt (zwecks Kontrolle) in einen Code-Abschnitt (</>) statt als Abbildung einfügen. Dann ist er

1. besser lesbar,
2. scrollbar,
3. kopierbar.

Zitat von seba28

Der mini ist zusätzlich mit einem Schalter verbunden, um das Licht manuell einschalten zu können.

So in #1

Zitat von tomsta13

Tastendruck auf shellyi4 —> Befehl an 1pm mini —> Licht ein

Das widerspricht der Info in #1 und war mir bisher nicht bekannt.

Dafür muss das Skript ein wenig geändert werden.

Ich werde es mit der Änderung nachreichen.

Ups, hast du zwei Konten? Oder hast du dich später eingeklinkt?

Sorry horkatz , aber das versenden von Nachrichten über Internet ist in Notsituationen keine wirklich gute Idee.

Als optionale Ergänzung Ok.

Zitat von ToLa62

Condition:

When: Temperature Change,

Nun, die Temperaturänderung bezieht sich womöglich auf die Schwelle von 0.5°C.

Das dürfte aber nicht das Ausbleiben der Aufrufe in einem kleineren Zeitintervall erklären.

Ich nutze keine Szenen bzw. Actions, die per Cloud ausgelöst werden und bevorzuge die lokale Implementation. Deshalb weiß ich nichts Genaueres darüber.

Zitat von ToLa62

Ich denke, das Skript im Plus1 müsste (Pseudocode) in etwa sowas tun:

Temperatur von HTPlus empfangen (wurde als Parameter ans Skript übergeben)

Aktuelle Zeit auslesen

Durch die Liste der konfigurierten Zeitintervalle iterieren.

Wenn passendes Intervall gefunden:

Temperaturbedingung überprüfen

Bedingung trifft zu:

Aktion ausführen (ShellyPlus1 Relais ein- bzw. ausschalten

Alles anzeigen

Du kannst offensichtlich programmieren oder Software entwerfen.

Ja, so lässt sich ein Skript gestalten und sollte funktionieren.

Mir bleibt aber unklar, warum sich der H&T in dem kleineren Zeitintervall nicht mitteilt.

Letztlich halte ich die Funktionssicherheit mit einem Plus AddOn und Sensor eher gegeben als mit einem H&T.

Zitat von ToLa62

Der Ort des ShellyPlus1 ist im Verteilerkasten der FBH, die Temperatur müsste aber in einem anderen Raum gemessen werden.

Verständlich. Du kannst auch einen zusätzlich Shelly mit AddOn statt des H&T dafür nutzen. Dies gelänge sogar mit einem Shelly 1, also der ersten Generation - nur falls dir ein solcher mit AddOn zur Verfügung stehen sollte. Was ist FBH?

Zitat von ToLa62

Deine Anmerkungen zur Thematik Zeiten/Stromausfall/Zeitserver lassen bei mir den Entschluss reifen, doch einen permanenten Internetzugang zu nutzen.

Es täte genügen, wenn der Internetzugang ca. 2 Minuten lang nach Stromausfall verfügbar wäre. Dann hat sich zumindest der Plus 1 bereits synchronisiert.

Ich werde den Verdacht nicht los, dass der H&T ein Problem mit der Zeiterkennung hat.

Edit:

Vielleicht liegt es doch an der Bedingung "Temperature Change". Du solltest mal im kurzen Zeitinterval den H&T etwas wärmen (oder abkühlen), um zu sehen, ob er dann die Action ausführt.

Dabei muss die Temperaturänderung mehr als 0.5°C betragen.

Ist diese Bedingung zwingend oder kann sie weggelassen werden? Entferne sie, wenn möglich ...!

Which actions or script do you use?

Du musst das Skript starten, sonst kann es nichts bewirken.

Ich interpretiere, dass deine erste Abbildung deinen vorher eingetragenen URL zeigt und die zweite Abbildung den nun abgeänderten URL.

Die unteren Abbildungen mit dem Skriptinhalt durchsuche ich nicht.

Noch ein Hinweis:
Nenne das Skript bspw. terrasse oder terrassen_app! Intern werden Skripte ausschließlich per Id verwaltet, aber es erscheint zweckmäßig, für uns Menschen verständliche Namen zu vergeben.

Ich fand keinen logischen Fehler. Nach mehr kann ich nicht suchen.

Ich bin gespannt, ob alles so läuft, wie du es haben willst.

Hab's oben eingebaut.

Genau so etwas habe ich implementiert, mit einem Shelly Plus 1 und einem Shelly Motion.

Das Skript:

let on = null; // output status
let th = null; // timer handle

function send_response(response, body) {
    response.code = 200;
    response.body = body;
    response.send();
}

HTTPServer.registerEndpoint('on',
  function (request, response) {
    send_response(response, "OK");
    if (on!==true) {
      Shelly.call("Switch.set", {'id': 0, 'on': true});
      if (request.query.length > 0) {
        let dur = JSON.parse(request.query);
        // print(dur);
        if(!isNaN(dur) && dur>0) {
          th = Timer.set(Math.floor(1000*dur), false,
            function () {
              Shelly.call("Switch.set", {id: 0, on: false});
            }
          );
        }
      }
    }
  }
);

Shelly.addEventHandler(function(e) {
  on = e.info.state;
  if (e.component==="input:0") {
    Timer.clear(th);
  }
});

//Do some user friendly printout
let url = 'http://' + Shelly.getComponentConfig("wifi").sta.ip + '/script/' + Shelly.getCurrentScriptId() + '/on?<duration in seconds>';
print('Your url is:', url);

Der Motion muss dazu folgende Action ausführen:

http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Dauer in Sekunden>

Wenn auf dem Schalt-Shelly noch kein Skript liegt, hat dieses die Id 1. Angenommen die Einschaltdauer soll 5 Minuten sein. Dann ist der URL

http://<IP Adresse des Schalt-Shelly>/script/1/on?300

Wenn per Schalter eingeschaltet wird, wird die Wirkung des Motion gesperrt, bis per Schalter ausgeschaltet wird.

Wenn die Leuchte per Motion eingeschaltet ist und nun per Schalter eingeschaltet wird, bleibt die Leuchte bis zum ausschalten per Schalter an.

Viel Freude damit

Ich nutze eine solche Kombination nicht. Der Plus H&T ist mir dafür zu träge.

Dein Anliegen ist aber klar und ok.

Ich nehme an, dass du die Schwelle der Temperaturänderungen auf den kleinsten Wert von 0.5°C gestellt hast. Wenn nicht, schaue einmal nach!

Zeiten können von einem Shelly nur dann genutzt werden, wenn er seine Zeit synchronisieren konnte. Solange er die Zeit einmal von einem Zeitserver erhielt, arbeitet sein Uhrtakt auch dann weiter, wenn keine Verbindung zu einem Zeitserver existiert.

Fällt aber die Stromversorgung aus und ein Shelly bootet danach, dann hat er keine Uhrzeit, solange er keinen Zeitserver erreichen kann. Die Shelly haben keine Batterie gepufferte Uhr.

Eine lokale Lösung gelingt ohne verfügbaren Zeitserver also nur, solange sich keine Unterbrechung der Stromversorgung ereignet. Nach dem Stromausfall braucht hierfür der Shelly einen kurzen Zugriff (ca. 1 Minute) auf einen Zeitserver, damit die gesuchte Lösung funktionieren kann. Dies gelingt aber nicht nachträglich, weil eine Action ausschließlich zu Zeitpunkten und nicht später (nachträglich) ausgelöst wird.

Zur Fehleranalyse

Ich weiß nicht, warum die von dir gemachten Angaben 22:00 bis 22:59 nicht wie gewünscht funktionieren. Meine Vermutung geht in Richtung, dass vom Plus H&T in dieser Zeitspanne keine Nachricht gesendet wurde. Vielleicht, weil die Temperaturänderung nicht groß genug war.

Um dies zu prüfen, kannst du ein sehr kurzes Skript einsetzen.

function htTest() {
    print("htTest wurde aufgerufen.");
}

Im H&T fügst du zu deiner Bedingung eine Action hinzu, die diese Funktion aufruft.

Das Skript muss gestartet sein. Das Protokollieren per Web UI muss freigegeben/aktiviert sein, worauf dich die Skriptumgebung hinweisen sollte, sobald du das Skript startest.

Der URL der zusätzliche Action lautet:

http://192.168.178.16/rpc/script.eval?id=<Skript Id>&code="htTest()"

Vermutlich liegen auf deinem Plus 1 noch keine Skripte. Dann ist die Id dieses kleinen Skripts die 1.

Andernfalls kannst du die Id per RPC Methode script.list herausfinden.

Du solltest die Web UI (nur direkt vom Plus 1, keine App oder Cloud) mit geöffnetem Skript laufen lassen.

Auch kannst du mit den Zeiten experimentieren, solange die Actions erhalten bleiben.

Immer dann, wenn der H&T die Actions ausführt, wird im Protokollfenster der Text "htText wurde aufgerufen." mit Uhrzeit (rechts) erscheinen.

So kannst du ablesen, wann der H&T dbzgl. aktiv wurde.

Das ist nur ein erster Schritt zur Fehleranalyse. Es gibt bessere Protokollmöglichkeiten, die aber erheblich aufwändiger sind.

Ich bin gespannt, was du herausfindest. Irgendwie werden wir dein Anliegen implementieren können, evtl. durch ein Plus AddOn.

Zitat von DIYROLLY

Ich meinte, was ist am 10.03. und 11.09.?

Ich denke, du solltest den gesamten Thread einmal sorgfältig lesen. Dann kannst du hoffentlich erkennen, dass ich versuchte, das Prinzip zu klären, mit welchem der TE nicht komplette Monate in Zeitplänen unterbringen kann. #9 erhebt keinesfalls den Anspruch, alle Zeitpläne aufzulisten. Da ich noch immer nicht weiß, was der TE von März bis September genau erreichen will, habe ich nicht noch mehr investiert.

Außerdem halte ich wenig davon, komplette Lösungen so zu präsentieren, dass ein Fragender nicht mehr selbst denken muss.

DIYROLLY

Warum stellst du das Anliegen des TE in Frage?

Ich bevorzuge selbst statische IP Adressen und habe sie per /16 in verschiedene Bereiche eingeordnet.

Das ergibt tatsächlich eine gewisse Ordnung, die per DHCP und feste Vergabe nicht erreichbar ist.

Die vorgegebenen /24 Netzwerke beizubehalten, halte ich auch für eher unflexibel. Solche Subnet Masken bieten für eigene IP Adressen und deren Sortierung kaum Spielraum.

Smartscha

Vermutlich greift die Cloud auf die Shelly per IP Adresse zu.

Ich hatte bei einer Änderung das gleiche Problem.

Entferne solche Geräte aus der Cloud und binde sie neu ein. Das ist etwas arbeitsintensiv, sollte aber gelingen.

DIYROLLY

Im Ernst?

Na gut.

Zitat von DIYROLLY

Was passiert am 10.03 und am 11.09

Am 10.03. wirkt der erste Zeitplan.

Am 11.09. wirkt keiner dieser drei Zeitpläne. Dafür sind andere Zeitpläne zuständig.

Zitat von DIYROLLY

Ich schaffe es als Rentner noch 3-4x im Jahr die Vorlauf- und Nachlaufzeit etwas zu ändern wenn die zu früh auffahren bzw. wenn die im Sommer später zufahren sollen.

Sage das mal dem TE!

Zitat von DIYROLLY

Ich meine das Datum passt nicht.

Welches?

Von Skripten war in #9 nicht die Rede.

Zitat von Seiko

PS: Die 2 Jobs habe ich. Aber wie stell ich die Tage ein?

Das war das letzte Problem des TE. Ich weiß noch immer nichts genaues, die 7:00 Uhr und den Sonnenaufgang von März bis September betreffend. Vielleicht ist es irrelevant bei dieser Uhrzeit. Ich dachte (kreativ) über eine Realisierungsmöglichkeit nach - und fand sogar zwei.

Edit:

Und das, obwohl ich selbst so etwas (als Rentner) nicht brauche.

Seiko

Ich fand hier nichts, was genau zu deinem Anliegen passt. Afaik können zwar in jedem der 6 Felder von timespec Bereiche ( von-bis) angegeben werden, aber nicht kombiniert über Felder hinweg.

Das bedeutet, dass dein Ziel vermutlich nur über weitere Schedule Jobs erreichbar ist.

Dazu kannst du folgende Jobs einrichten.

1. Für März, 10. bis 31.
2. Für April bis August, alle Tage.
3. Für September, 1. bis 10.

Bin gespannt, ob es einfacher gelingen kann.

Seiko

Das gelingt mit "Schedule type": Advanced schedule.

Dort finden sich viele Einstellmöglichkeiten. Wähle darin "Use sunset or sunrise offset"!

Vielleicht lassen sich dort die Daten nicht ganz wie gewünscht einstellen.

Ich werde mal nachsehen, wie es trotzdem gelingt.

Zitat von MIHO

Alexa Notification

Kannst du mal aufzeigen, wie eine solche Notificaten (per Action) zu strukturieren ist?

Zitat von Seiko

vom 10.3-10.9 soll der Rollladen um 7 Uhr geöffnet werden.

Moment mal. Soll in dieser Zeitspanne immer um 7 Uhr geöffnet werden, also unabhängig vom Sonnenaufgang?

Ich verstand es anders.

Vielleicht kann es doch ausschließlich mit Schedule Jobs gelingen, also ohne Skript.

Dazu folgendes Konzept:

Es werden insgesamt fünf Jobs kreiert. vier Jobs gelten ausschließlich für die Zeitspanne 10.03. bis 10.09., der fünfte während der komplementären Zeitspanne.

Der fünfte Job ist leicht per UI einzurichten, ich gehe deshalb nur auf die anderen vier Jobs ein.

Job 1 mit sunrise gibt Job 2 (mit Uhrzeit) frei. Liegt sunrise vor Uhrzeit, wird per Job 2 geöffnet, andernfalls geschieht nichts.

Job 3 mit Uhrzeit gibt Job 4 (sunrise) frei. Liegt Uhrzeit vor sunrise, wird per Job 4 geöffnet, andernfalls geschieht nichts.

Eines von beiden trifft immer zu, wenn die Zeiten zueinander passend gewählt sind.

Beispiel:

Job 2 mit 07:01 Uhr, Job 3 mit 07:00 Uhr.

sunrise < 07:01 => per 07:01 wird geöffnet.

sunrise > 07:00 => per sunrise wird geöffnet.

Nicht getestet, sollte aber funktionieren.