Afaik hatte Mike2024 in einem anderen Thread bereits die Frage nach dem remote Lesen eines Wertes gestellt. Wenn ich damit richtig liege, liegt meine Vermutung nahe.
Ansonsten pflichte ich dir vollständig bei.
Afaik hatte Mike2024 in einem anderen Thread bereits die Frage nach dem remote Lesen eines Wertes gestellt. Wenn ich damit richtig liege, liegt meine Vermutung nahe.
Ansonsten pflichte ich dir vollständig bei.
Vermutlich denkt Mike2024 an eine Datei außerhalb des Shelly.
Dazu müssten wir zunächst wissen, welcher Kommunikationspartner dem Shelly hierfür zur Verfügung steht.
Der 3EM kann aber keine Skripte.
Das stimmt.
Ich hätte noch erwähnen sollen, dass auch Lösungen möglich sind, die per Skript auf einem Shelly Generation 2+ implementiert sind. Dies ist dann allerdings ähnlich ausfallsicher wie ein übergeordnetes System.
Hallo Thomas.
Das Versprechen seitens "Sofia" ist recht hochgehängt. Trotzdem sollte ein Werksreset vor allem anderen liegen und alle Skripte auf disabled stellen. Ich denke, dass seitens "Sofia" dies durchaus möglich ist.
Dann könnte meine Lösung zum aufzeichnen von Messwerten im nichtflüchtigen Speicher interessant sein.
Wenn du magst, kann ich dir das bisherige Skript zukommen lassen, welches für deine Protokollierung anzupassen wäre.
In diesem Fall benachrichtige mich bitte per PN!
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.
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? ![]()
ostfriese hat zum senden einer Nachricht per Messanger "Signal" ein Skript erstellt.
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.
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?
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:
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. ![]()
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);
}
});
Alles anzeigen
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.