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.

Zitat von eiche

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

Zitat von 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.

Zitat von ToLa62

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?

ostfriese hat zum senden einer Nachricht per Messanger "Signal" ein Skript erstellt.

ALARM AN SIGNAL FÜR FAST ALLE SHELLY

Zitat von cyberdoro

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!

Zitat von Balu67

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.

Interessant.

Nur ein Verdacht, kann total daneben liegen: Hast du mal diesen Appliance type geändert und dann Selbiges überprüft?

Was wird denn unter Appliance type zur Auswahl angeboten?

Zitat von SvenT

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?

Zitat von deebeo

allerdings kann es beim Einschalten nicht verzögern

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

Habe ich das nicht erst in einem anderen Thread beantwortet?

Wie auch immer, hier der Link zu meiner Lösung, aber mit Motion ohne Blu:

Automatisirtes Schalten temporär deaktivieren

Zitat von SvenT

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.

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

Ich habe es auf einer meiner Websites dokumentiert.

Hier der Link: Automatisiertes Schalten temporär deaktivieren

Wie bereits zuvor mitgeteilt, ein Skript zur Verwendung eines Blu Motion fehlt noch.

Dieses ist erforderlich, damit der Blu den Shelly triggern kann.

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.

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);
  }
});

Mein Motion erhält einen Action Eintrag mit

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.

deebeo

API calls sind immer erforderlich, lokal braucht man dazu aber keinen URL.

Das gelingt mit einem registrierten EventHandler oder StatusHandler. Auf Grund des Messwertes und einer oder zwei Schwellen (Hysterese!) kann geschaltet werden.

Dies gelingt bereits mit einem kleinen Skript. Ungetestet, da ich derzeit nur einen Rollladen-Shelly Plus 2PM zum testen verwenden kann.

let Messausgang = 0, // An welchem Ausgang soll der Messwert herangezogen werden?
Schaltausgang = 1, // Welcher Ausgang soll geschaltet werden?
Level1 = 30, // unteren Wert zum schalten eintragen
Level2 = 40; // oberen Wert zum Schalten eintragen

function processStatus(status) {
  if(status.component === "switch:" + Messausgang
    && status.delta !== undefined
    && status.delta.apower !== undefined) {
      print(status.delta.apower);
      if(status.delta.apower < Level1)
        Shelly.call("switch.set", {id:Schaltausgang, on:true}); // Schaltausgang einschalten
      else if(status.delta.apower > Level2)
        Shelly.call("switch.set", {id:Schaltausgang, on:false}); // Schaltausgang ausschalten
    }
}

Shelly.addStatusHandler(processStatus);

Für ein zielgerichteteres Skript ist eine genauere Beschreibung deines Ziels erforderlich.

Zitat von Balu67

mit seiner IP konnte ich ihn auch nicht erreichen

Was hast du denn bisher versucht?

Wenn du sein eigenes WLAN, wegen seines aktiven Access Point, auf dem Handy siehst, dann kannst du folgendes tun.

1. Das Handy, Tablet oder Notebook, etwas mit WLAN Adapter, mit dem WLAN des EM verbinden.
2. Mit einem Web Browser die IP Adresse 192.168.33.1 nutzen.
3. Hat 2. keinen Erfolg, ein ping 192.168.33.1 absetzen - immer auch prüfen, ob dein Endgerät noch mit dem EM WLAN gekoppelt ist!

Berichten, was du erlebt hast.

leon2k6

Wenn über die Taster keine externe Spannung geführt werden darf, ist zunächst , ohne es zu wissen, anzunehmen, dass die Taster zwei Eingänge der Steuerelektronik (braun, weiß) auf Bezugspotential (vielleicht Ground, Masse, ...) legen sollen.

Mit dem, was dir vorliegt, kann entweder keine Fehlersuche durchgeführt werden oder dies nur mit viel Erfahrung mit solcher Steuerelektronik erfolgen kann. Ob der Hersteller/Vertreiber dir als Anwender mehr Unterlagen zusenden wird, bleibt offen. Ein Elektro-Betrieb sollte jedenfalls mehr erhalten können.

Ohne weitere Unterlagen bliebe tatsächlich nach messen noch "aufschrauben" und analysieren, wie es thgoebel täte.

Jedenfalls solltest du keine externe Spannung über die Taster schalten lassen!

Es bleibt zu hoffen, dass dir bald bessere Unterlagen vorliegen werden.

rickert

Auch eine solche Maßnahme erscheint mir nicht als erstrebenswert. Falls so etwas nur einmal genügt, um die Funktionalität herzustellen, ist das noch akzeptabel.

Da mit Bewegungsmeldern keine hinreichende Funktionssicherheit erreichbar ist und du möglicherweise in Haftung treten musst, wenn etwas unerwünschtes geschieht, wäre vermutlich ein Notlicht hilfreich.

uli57

Um solches zu prüfen, kannst du mal per Actions (=Webhooks) zwischen den Dreien senden lassen.

Richte dafür einfach Actions ein, die auf dem jeweiligen Zielgerät etwas auslösen und welche du selbst, bspw. per Taster/Schalter auf dem sendenden Gerät auslösen kannst.

Wenn du dabei Hilfe suchst, darfst du dich gerne an mich wenden.