Beiträge von eiche

    Ich nutze als übergeordnetes System ausschließlich Node-RED und dessen Flows, also kein ioBroker, Home Assistant, ...

    Mal angenommen, davon schrieb der TE nichts, die Kommunikation findet per MQTT statt und der Shelly sendet eine MQTT Nachricht mit gesetztem Retain Flag. Und angenommen, im ioBroker wird an zumindest einer Stelle das Subscribing wiederholend aktiviert. Dann erhält der ioBroker in irgendwelchen Zeitabständen wiederholt denselben Wert. Falls darin auch ein Zeitstempel steckt, ließe sich so etwas herausfinden.

    Damit will ich keinen konkreten Verdacht äußern. Damit will ich nur darstellen, dass es viele mögliche Quellen für Irritationen gibt.

    Schon deshalb sollte man in solchen Fällen den ioBroker, die App und die Cloud außen vor lassen, um erste und grundlegendste Erkenntnisse gewinnen zu können.

    Eine Cloud ist als Zusatzluxus geeignet, sollte aber nie zum regeln oder steuern genutzt werden.

    Ich kann nicht anders, als dich davor warnen.

    Ich empfehle dir, dich dafür zumindest mit Actions (=Webhooks) zu beschäftigen. Diese sind ebenfalls per klicken in der Web UI (nach wie vor die beste Möglichkeit zum konfigurieren und beobachten) zusammenstellbar.

    Wenn du damit nicht zu deinem Ziel kommen solltest, kann dir voraussichtlich noch per Skript (am ausfallsichersten) oder einem übergeordneten System geholfen werden.

    ToLa62

    Gibt es keine Endlosschleife oder sollte es keine geben? Mit Letzterem würde ich dir recht geben.

    Nun ja, es darf keine Endlosschleife geben. Siehe auch https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…cking-execution

    Außerdem ist eine Endlosschleife in einem Shelly Script sinnfrei, weil per Skript kein Polling zielführend ist. Die Firmware verwaltet das Abfragen von Messwerten und Eingangssignalen. Sie teilt solche Werte periodisch oder bei Wertänderungen einem Skript an registrierte callback Funktionen als Event-, Status- oder TimerHandler mit - Letzteres ist faktisch der Fall, auch wenn es in der Dokumentation nicht so genannt wird. Zusätzlich gibt es Schedule Jobs, mit welchen eine periodische Abfrage von Werten per RPC möglich ist. Das sind wesentliche Grundlagen beim programmieren von Shelly Skripten.

    Für die Verarbeitung von eintreffenden Nachrichten sind ebenfalls zu registrierende callback Funktionen als MQTT Subscriber oder HTTPServer Endpoints geeignet.

    Bei den Versuchen etwas mit Timern zu machen, hab ich einen Fehler gemacht ... und schon kam ich nicht mehr ran.

    Wie gelang dir solches? Hast du als ersten Parameter im Aufruf von Timer.set() eine 0 oder gar einen negativen Wert eingetragen? So etwas war ich noch nie versucht zu testen ...

    Oder hast du in der callback Funktion des Timers eine Endlosschleife eingebaut? ;)

    Mit nur jeweils dem einen Shelly bekomme ich das hin, aber es muss ja eine Reihenschaltung sein bei den 2. Erst wenn beide ON sind, dann Alarm.

    Vermutlich meinst du eine "logische Reihenschaltung" und keine elektrische. Für eine elektrische Reihenschaltung müsstest du ja die Ausgänge beider Shelly in Reihe schalten, wozu deren Signal ausgewertet werden müsste. Letzteres ist vermutlich nicht von dir beabsichtigt.

    Du kannst bspw. den Regensensor-Shelly per Action dazu bringen, eine Nachricht (URL) an den Fenster-Shelly zu senden - oder umgekehrt. Der empfangende Shelly sollte auf Grund der Nachricht seinen Ausgang einschalten, was in der Cloud registriert wird. Dort sollte es per Szene möglich sein, eine Push Nachricht zu senden. Das soll aber auch per Skript und ohne Cloud gelingen. Zu beiden kann ich nichts beitragen, weil ich solche Push-Nachrichten bisher nicht nutze. Wenn du eine Push-Nachricht per Skript senden lassen möchtest, braucht hierfür der Ausgang des lokal empfangenden Shelly nicht geschaltet zu werden.

    Nutze für das Einrichten einer Push-Nachricht einfach mal die Forensuche! Dazu gibt es reichlich Beiträge.

    Die AP eigene IP Adresse ist ja auch ausschließlich zum Einrichten oder für Notfälle geeignet. Damit kann kein Shelly im sonstigen WLAN sichtbar sein.

    Die App ist im Zweifelsfalle nicht zu verwenden, stattdessen die Web UI. Per letzterer hat man den direkten Zugriff auf den Shelly.

    Vergiss also temporär diese App und versuche, per Web UI weiterzukommen!

    im Netzwerk war er auch nicht zu sehen und mit seiner IP konnte ich ihn auch nicht erreichen, das ist ja das verrückte.

    Wenn du bisher ausschließlich die App verwendetest, hast du fast noch nichts versucht.

    wie kann ich die Daten für Energie getrennt halten

    Ich habe keine Pro 3EM. Nach meiner Erfahrung werden Daten bezogen auf ein Gerät aufgezeichnet. Mich wundert deine Frage, weil du demnach nicht versucht hast, beide Pro 3EM in dieselbe Cloud zu kriegen. Oder hast du es versucht und festgestellt, dass die Daten beider Shelly zusammengefasst werden? Letzteres wäre zumindest verwunderlich.

    Kontrollfragen:

    1. Was soll geschehen, wenn die gemessene Leistung (am O1) 25s lang über 200W liegt?
    2. Was soll geschehen, wenn diese Leistung bspw. 31s lang über 100W liegt, aber zwischenzeitlich für 2s unter 100W sinkt?
    3. Damit das Skript brauchbar arbeiten kann, ist eine Hysterese der Limits (du schreibst 100W) erforderlich, bspw. unter 95W -> ausschalten, über 105W (30s lang) -> einschalten.
      Wie wären deine bevorzugten Schwellwerte?
    4. Wie lange soll O2 mindestens eingeschaltet bleiben, bevor er ausgeschaltet wird?
    5. Welche Verläufe der gemessenen Leistung über O1 sind realistisch?

    allerdings kann es beim Einschalten nicht verzögern

    Ja klar, die von dir gewünschte Mindestdauer von 30s kannte ich ja noch nicht.

    Und 2 komplett getrennte Orte (zB zweite Wohnung im Gebäude mit eigenem Zähler) lässt sich wohl nur über 2 getrennte Cloud Konten verwalten oder ?

    Ist die zweite Wohnung mit deinem (W)LAN verbunden?

    Wenn nicht, bliebe wie Martin bereits schrieb, eine VPN Verbindung zwischen beiden LAN.

    Vielleicht ginge auch eine Kopplung über eine DMZ (DeMilitarisierte Zone), womit ich mich aber kaum auskenne.

    Szenen sind Cloud gebunden.

    Lokal heißen solche Dinge Webhook oder Action (synonym).
    Zu Szenen kann ich wenig sagen ...

    Wenn Webhooks das Ziel erreichen lassen, sollte man diese verwenden. Eine Cloud ist als Zusatzluxus geeignet, sollte aber nie zum regeln oder steuern genutzt werden.

    Per 127.0.0.1 kann ein Webhook auch lokal genutzt werden. Per komplexerer URL lassen sich auch Webhooks anlegen, die nicht per Web UI angelegt werden können.

    Kurz: Die API ist erheblich cooler als die Web UI, nur nicht so "schön". ;)

    Und, es wird wohl niemanden überraschen, das High End ist schließlich ein Skript (oder zwei ...). Damit gehen Dinge, die nicht per Cloud (Szenen) oder Webhooks gelingen. Auch dann, wenn kein übergeordnetes System verfügbar ist. 8o

    Dann kann ja trotzdem noch zusätzlich die Cloud genutzt werden - oder ein übergeordnetes System.

    Ich habe so etwas realisiert, mit einem Skript, aber mit einem Motion (ohne Blu).

    Das Skript läuft auf einem Shelly Plus 1, es wird somit auch auf dem Mini laufen.

    Ein Problem wird der Blu Motion sein, weil hierfür ein zusätzliches Skript erforderlich wird, welches ich mangels Blu nicht nutze.

    Mein Motion erhält einen Action Eintrag mit

    Code
    http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Einschaltdauer>
    also bspw.
    http://<IP Adresse des Schalt-Shelly>/script/1/on?60

    Sobald per Schalter eingeschaltet wird, wird das Ausschalten per Motion deaktiviert. Dann muss per Schalter ausgeschaltet werden. Das gelingt auch, wenn zuvor per Motion eingeschaltet wurde.

    Irgendwo hier im Forum habe ich eine noch etwas flexiblere Lösung gepostet, die ich aber noch finden muss.

    Vielleicht kann jemand das hinzuzufügende Bluetooth Gateway Skript beifügen. Mir ist dies nicht möglich, weil ich weder Erfahrung damit habe noch testen kann.