Beiträge von micha06de

Hallo,

ich hatte inzwischen mehrfach die Situation, dass das von mir auf einem Plus Plug S bewusst deaktivierte Bluetooth Gateway wieder aktiviert war, was schlecht ist, weil dann das darauf laufende Skript nicht mehr funktioniert.

Zuerst habe ich an mir gezweifelt, jetzt habe ich aber durch Versuche festgestellt, dass sich das Gateway aktiviert, wenn man auf einem BLU Gerät das betreffende Gerät als Gateway auswählt (was bei einem neu hinzugefügten BLU Gerät versehentlich passieren kann).

Das vor allem als Hinweis an alle, die Skripte im Zusammenhang mit BLU Geräten ausführen.

BTW: Wofür genau ist dieses Bluetooth Gateway gedacht? Bei mir funktioniert alles, auch wenn es deaktiviert ist. Hat jemand ein konkretes Anwendungsbeispiel, das nur mit aktiviertem Gateway funktioniert?

Laut Aktivitätsprotokoll wechselte der Status sekündlich. 🤔

Interessant das Ganze. Ich hatte gestern einen neuen BLU DW installiert und das FW update durchgeführt. Nach Installation sm Fenster meldete er erst dauerhaft „geöffnet“, obwohl es zu war, nach einer Weile meldete er im Sekundentakt auf - zu - auf - zu … Ich dachte erst der Magnet ist zu weit weg und habe einen anderen geholt und direkt angelegt, es ging trotzdem weiter.

Das Update habe ich über die Debug App durchgeführt, in der Shelly Control-App wurde noch die alte Version angezeigt. Ich habe dann hier auch auf „Update“ gedrückt (und dazu wie verlangt den Button am Gerät gedrückt), danach war der Spuk vorbei 😇.

Zitat von AltrKnabe

Nach zwei Minuten gehen die LED aus, und der Rauchmelder geht offline.
Wo liegt denn mein Fehler?

Das ist kein Fehler. Er schläft und wird durch Rauch wieder aufgeweckt. Einmal am Tag wacht er auf und gibt ein Lebenszeichen von sich, das im Aktivitätsprotokoll erscheint s. Screenshot. Warte einfach mal 24 h und schau dann ins Eventlog.

Zitat von towiat

Die einfachste Lösung ist vermutlich, die Version vor diesen Änderungen zu verwenden - die kann man sich aus der Git-Historie herausziehen. Hier ist der entsprechende Link:

towiat Es gibt ein neues Update vom 3. Februar, also einen Tag nach Deinem Post, da kommen die Variablen SCAN_DURATION und ACTIVE_SCAN gar nicht mehr vor (?)! Die Version "vor diesen Änderungen" kann nur die ursprüngliche vom 25. Jan 2023 sein und die enthält den von mir in #9 erwähnten Fehler. Die neue Version habe ich noch nicht getestet, aber falls die alte verwendet werden soll, sollte unbedingt die in https://github.com/ALLTERCO/shell…ples/issues/124 beschriebene Änderung vorgenommen werden, ohne diese Änderung kommt es unregelmäßig dazu, dass sich das Script beendet, seit ich das geändert habe, läuft es stabil.

Danke, das war mir entgangen.

Habe ich das richtig beobachtet, dass sich der „Inhalt“ der App auf dem Smartphone aktualisiert, ohne dass die App aktualisiert wurde (habe 1.5.7 von Anfang Januar, aber die neuen Funktionen scheinen zur Verfügung zu stehen)?

Ok, Danke. Diese Funktion kannte ich noch nicht, ich nahm an, dass jede Szenenauslösung, so wie Schaltvorgänge, protokolliert wird.

Die Szenen funktionieren jetzt, aber im Aktivitätsprotokoll wird keine einzige Szenenaktivität angezeigt.

Szene 1

Szene 2

Aktivitätsprotokoll gefiltert nach Szenen

Die eine Szene funktionierte erst nicht richtig, deswegen habe ich im Aktivitätsprotokoll unter Szenen nachgesehen, aber da erscheint NICHTS, auch nichts von ordnungsgemäß ausgeführten Szenen.

Zitat von MIHO

Hast du in die Szene ein Aktivität Eintrag hinterlegt bei >dann<?

Ja, bei der einen soll eine Meldung abgesetzt werden, die auch kam; bei der andern sollten "dann" mehrere Shelly eingeschaltet werden, was auch passierte.

Hallo,
ich habe gerade neue Szenen eingerichtet und test diese, dabei habe ich festgestellt, dass in der Shelly Control App keinerlei Szenenaktivitäten angezeigt werden, obwohl es einige gab.

Ist das ein Bug oder habe ich die Funktion falsch verstanden?

Du musst in der Kurzbefehle App erstmal einen Kurzbefehl anlegen, der eine URL Aktion an einem Shelly oder in der Shelly-Cloud (z. B. Szene auslösen) auslöst. Als zweiten Schritt musst Du in der Kurzbefehle App eine Automation anlegen, die auf die Nachricht reagiert und den Kurzbefehl ausführt. Die von Dir verwendete Nachrichten-App muss von der Kurzbefehl-App unterstützt werden bzw. umgekehrt, sonst geht es nicht. E-Mail und SMS/i-Message werden unterstützt.

Die folgenden Screenshots zeigen das Prinzip.

Bei dem Kurzbefehl schalte ich einen Shelly Plus Plug S an. Diesen Kurzbefehl führe ich dann über eine Automation aus, wenn ein entsprechender NFC-Tag in die Nähe des Telefons kommt.

Shortcut Shelly URL-Aktion

Automation zur Auslösung des Shortcut

Es muss dann noch darauf geachtet werden, dass eingestellt ist, dass die Aktionen ohne Bestätigung ausgeführt werden (das funktioniert erst seit iOS 17 richtig).

Falls Du ein iPhone hast, geht das mit Kurzbefehlen und URL-Aktionen (bei Android gibt es ähnliches, aber damit kenne ich mich nicht aus).

Die Frage ist, ob die App, von der die Nachricht kommt, Kurzbefehle unterstützt. IFFFT könnte auch eine Lösung sein …

Zitat von horkatz

Z.B. so etwas in einen Shelly PlugS stecken...
https://de.elv.com/p/elv-netzbetr…mhoC8NQQAvD_BwE

Speziell diese Sirene ist (mir) viel zu leise. Außerdem kann das rote Licht störend sein. Ich habe sie deswegen wieder zurück geschickt.

Die Schaltung erfolgt über einen Reedkontakt, deswegen erfolgt diese unabhängig vom Batteriestand. Ausschlaggebend ist der Abstand des Magneten, ist dieser (zu) nah am DW, wird auch bei einem Spalt geschlossen gemeldet. Hier hilft nur experimentieren.

Zitat von Aegelos

Jetzt wird es mir auch angezeigt, scheinbar braucht die Aktivierung des Premiumzugangs einfach etwas.

In der Shelly FAQ steht dazu, dass man sich für diesen Zweck aus- und wieder einloggen soll.

Zitat von Schubbie

Ich lese in den Beiträgen von dem TE nichts von Bluetooth.

Ja, Ok, ich hatte Headset mit Bluetooth assoziiert, meinte aber USB (s. #2).

Aber jetzt, wo ich das Bild vom Headset gesehen habe (Link in #14), ist mir der Grund fürs Brummen auch klar. Wahrscheinlich geht USB nur bis zum Fernbedienungsteil und von dort aus gehts dann weiter analog zu den Hörmuscheln.

Es ist technisch eigentlich unmöglich, dass elektromagnetische Wellen mit einer Frequenz von 50 Hz, Bluetooth so stören, dass im Endgerät ein Netzbrummen zu hören ist. Wenn, dann werden die Wellen auf der Sender- oder Empfängerseite empfangen und damit hörbar. Es wäre interessant zu wissen, ob es Sender oder Empfänger ist. Evtl. mal mit dem Headset in die Nähe des Versuchsaufbaus gehen und dann mit dem Sender und mit dem Headset weiter weg und hören, bei welcher Konstellation das Brummen auftritt.

Das Störsignal stört nicht die USB Übertragung, es wird vermutlich in die NF-Komponenten/-Leitungen im Computer eingestreut. Ist an dem Computer eine externe Audioquelle mit analogem Kabel (Line-In) angeschlossen?