Du kannst doch den Blu Button als virtuelle Komponente in den 1 Mini gen3 direkt integrieren.
dann brauchst du kein Skript um den Shelly 1 mini zu steuern.
Einrichten/einbinden geht aber nur über die Weboberfläche. Nicht über die App
VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Du kannst doch den Blu Button als virtuelle Komponente in den 1 Mini gen3 direkt integrieren.
dann brauchst du kein Skript um den Shelly 1 mini zu steuern.
Einrichten/einbinden geht aber nur über die Weboberfläche. Nicht über die App
entscheidend sind die technischen Spezifikationen und die Normgerechte Auslegung.
Normen sind in Deutschland nicht öffentlich frei zugänglich, sondern müssen erworben werden.
Niemand wird alle mit seinem Hausbau inkl. Elektronistallation zutreffenden Normen erworben haben und kennen.
Und weil damit der Laie keine Ahnung davon hat, dass eine Steckdose zwar mit 16A LS abgesichert ist, aber nur 10-12A Dauerstrom belastet werden darf,
sind üblicherweise nur Elektrogeräte mit maximal 2kW Dauerleistung zur Verwendung an Schukosteckdosen im Verkauf.
= keine Überforderung des Laien oder der Steckdose.
Alle sonstigen verkehrsüblichen Zwischenstecker sind auch für diese 16A Kurzzeitleistung freigegeben.
Wenn jetzt Shelly meint, man könne auch einen 8A Zwischenstecker "Plug" in Umlauf bringen, ist das einfach lebensfremd.
Vielleicht ist man da in anderen Ländern fehlertoleranter.
Die Elektrofachkraft hat im Rahmen der Planung und Installation sicherzustellen,
Devil das trifft aber nicht für die von Shelly vertriebenen plugs zu. Diese sind ja implizit dafür vorgesehen, von Laien in schukosteckdosen gesteckt zu werden. Und Laien haben von 8A oder ohmscher Last keine Ahnung. Also müssen solche Plug&Play Geräte Laiensicher sein.
Insofern stimme ich borsti0 zu.
Alles andere gehabe von Shelly ist scheinheilig.
Zum Löschen ist ein Supportticket notwendig mit Angabe von Wunschzeitraum und Geräte-ID.
Angel danke, das mit dem Ticket hat überraschend gut und schnell funktioniert. Daten sind bereinigt.
Das habe ich dann auch lobend positiv mit meinem dank in der Antwort an den Shelly Service vermerkt.
PS. Die anderen Shelly habe ich manuell auf die neueste Version aktualisiert. Hoffe es hilft.
Auf welcher Firmware läuft der Gen3 Mini? Es gab da eine Bug der mit 1.7.4 (beta oder stable) behoben sein sollte.
Angel Aha, danke. Der Mini läuft auf 20250924-062710/1.7.1-gd336f31 obwohl automatische Updates aktiviert sind.
Warum funktioniert der automatische Update nicht?? Wieder so ein unfassbarer, ungelöster Shelly Bug.
Gibt es einen workaround, um die automatischen Updates effektiv zu aktivieren??
PS. Support Ticket zum fehlerhaften Messwert werde ich dann noch erstellen . Danke.
Hi,
Ein Shelly Mini gen3 EM hat kürzlich einen offensichtlich fehlerhaften Verbrauchswert in die Cloud hochgeladen. Dieser Wert zerschießt mir jetzt die ganze Statistik. Wie bekomme ich den gelöscht??
Im Bild: 3,6 MWh Verbrauch in einer Stunde; wären kontinuierlich 15,6kA ;-))
Nach meinen Erfahrungen merkt sich das TRV die Temperaturänderungen während das Fenster geöffnet ist und führt sie augenscheinlich nicht aus. Erst nach dem Schließen des Fensters werden die Änderungen wirksam. Ich denke, das Verhalten ist auch richtig, denn das geöffnete Fenster übersteuert die Solltemperatur bis die Zeit abgelaufen oder das Fenster geschlossen ist.
Da kann man geteilter Meinung sein
Aus meiner Sicht sollte eine manuelle Einstellung alle anderen Automatismen überschreiben.
Wenn du die Ventilsteuerung manuell von extern Stern willst, hast du denn auch bei den Einstellungen , 'Verhalten', die automatische Temperatursteuerung deaktiviert?
Ganz genauso habe ich es auch immer gemacht! Und nichts anderes als Fenster auf und wieder zu hat geholfen!
Sasch600xt habe jetzt festgestellt, dass es wohl wirklich die TRV sind, die die Probleme machen, und nicht der GW.
Abgeleitet aus folgender Situation:
TRV zeigt in App und Web ui an, dass das verknüpfte Fenster offen wäre. Der Blu Door selbst wird als geschlossen angezeigt. Habe diesmal nicht das Fenster geöffnet und geschlossen, um das settings wieder zu synchronisieren. Stattdessen habe ich versucht die Zieltemperatur des TRV manuell neu zu setzen. Sowohl in der App, wie auch in der Web ui. Und das mehrfach. Der TRV hat diese Steuerbefehle einfach nicht angenommen.
Erst nach einem reboot des TRV über die web ui hat der TRV den vorher über App und GW eingestellten neuen wert für die Zieltemperatur übernommen.
Es scheintt also, dass die TRV nach einer bestimmten Betriebszeit oder eine bestimmten Betriebskonstellation, keine Änderungen der Zieltemperatur oder des Blu Door Status mehr übernehmen.
Kann das irgendjemand nachvollziehen?
Wie kann man das der Shelly Entwicklung in einem Ticket eindeutig belegen??
Wenn in der Zwischenzeit während des Reboots des GWs das Fenster geöffnet wurde, wärs auch wieder falsch.
schreckus das ist nonsense, denn ein Blu device kann mehrere GW haben, die seine Status Messages in die Cloud hochladen. Ist bei mir so eingerichtet. Also slebst, wenn ein GW rebootet, sollte nichts verloren gehen. Und damit ist die Statusübernahme aus der Cloud immer die bessere Wahl.
borsti0 , tvbshelly
Hi, wie borsti schreibt, kann es bei den Blu HT in der Regel egal sein, wie oft eine BLE Nachricht nicht durchkommt. Dann tut es halt die Nächste.
Aber für Steuerungsaufgaben sollte Shelly unbedingt ein Handshakeprotokoll benutzen, dass den Empfang der Nachricht quittiert.
Das ist auch der Batterielaufzeit garnicht so sehr abträglich. Die Zahl der Nachrichten wird ja nur verdoppelt, ggf. verdreifacht.
Das ist aber alles noch Peanuts gegenüber der Anzahl der verschwendeten Nachrichten und verschwendeten Batteriekapazität, durch "Battery Low" messages, die zum vermuteten Lebensende der Batterie zu Tausenden (!!!) versendet werden.
Mit dieser verschwendeten Batteriekapazität hätte die Shelly Blu Komponente noch über Monate weiterbetrieben werden können. Auch unter Einsatz eines Handshake Protokolls !
BLE Broadcast Protokoll für Komponenten in Steuerungen einzusetzen ist einfach großer Mist von Shelly.
Sasch600xt Hi, ich hatte erst den TRV GW rebooted. Half nichts. Dann habe ich den TRV rebooted. Half nichts. Dann habe ich den Blu Door nochmals geöffnet und geschlossen. Dann hat es funktioniert.
Was mich aber wundert ist, dass auch die beiden Reboots nicht dazu geführt haben, dass zumindest der TRV GW sich nochmal den tatsächlichen aktuellen "closed" status des Blu Door aus der Cloud gezogen hat. Denn in der App wurde der Blu Door ja als "closed" angezeigt. Sogar mit der letzten Meldung ("last Reporter") über den besagten TRV GW !!
Die Bluetooth Kommunikation zwischen den Shelly Komponenten funktioniert äußerst unzuverlässig, und ist nichtmal unter den shelly Komponenten Darstellungen synchron; divergierende Anzeigen treten auf zwischen Blu Door (closed) und Blu TRV (door open). Das ist leider ungenügend.
Alle Komponenten befinden sich auf derselben Etage in Sichtweite mit max 1 Wand dazwischen. Empfangsleistung ist, wo angegeben, gut. Es befinden sich 12+ Bluetooth Komponenten auf derselben Etage. Sollte das ein Problem sein? (dann taugt das Shelly Konzept nicht)
Nun zum eigentlichen:
ich beobachte auch andere, vermutlich Bluetooth induzierte Fehler:
Habe eine Szene definiert, die mich informiert, sobald in einer batteriegestützten Komponente die Batterie unter 40% fällt.
Dieser Alarm kommt gelegentlich, - und eben auch, wenn gemäß Durchsicht in der App keine Batterie unter 40% ist (nichtmals nah dran).
Das WD berichtet ähnlich fehlerhafte Batteriewerte zu seinem externen Sensor, obwohl nicht zutreffend.
Kann es durch Überlagerung von Bluetooth Nachrichten auf der Funkschnittstelle zu solchen Fehlinformationen kommen?
Danke, falls ihr etwas dazu wißt.
Noch mehr Evidenz zu den Bluetooth Problemen der Shelly Komponenten, besonders TRV und TRV GW.
Heute beobachtet:
D.g. Obwohl vom TRV GW selber, der Blu Door als geschlossen gemeldet wurde,
ist der Blu TRV immmer noch der Ansicht, dass der Blu Door geöffnet wäre,
und bleibt deshalb auf der "Fenster offen"-Soll-Temperatur.
Dieser diskrepante Zustand dauerte mehrere Stunden an,
bis ich manuell eingriff.
Die Bluetooth Kommunikation zwischen den Shelly Komponenten funktioniert äußerst unzuverlässig, und ist nichtmal unter den shelly Komponenten Darstellungen synchron.
Das ist leider ungenügend.
PS alle Komponenten befinden sich auf derselben Etage in Sichtweite mit max 1 Wand dazwischen. Empfangsleistung ist, wo angegeben, gut. Es befinden sich 12+ Bluetooth Komponenten auf derselben Etage. Sollte das ein Problem sein? (dann taugt das Shelly Konzept nicht)
PPS. ich beobachte auch andere vermutlich Bluetooth induzierte Fehler: Habe eine Szene definiert, die mich informiert, sobald in einer batteriegestützten Komponente die Batterie unter 40% fällt. Dieser Alarm kommt gelegentlich, - und eben auch, wenn gemäß Durchsicht in der App keine Batterie unter 40% ist (nichtmals nah dran). Das WD berichtet ähnlich fehlerhafte Batteriewerte zu seinem externen Sensor, obwohl nicht zutreffend. Kann es durch Überlagerung von Bluetooth Nachrichten auf der Funkschnittstelle zu solchen Fehlinformationen kommen?
Fakt ist, die Teile tun nicht das was Sie sollen!
Korrekt. Das kann ich bestätigen.
Die Blu TRV sind eine Katastrophe. Regelverhalten absolut ungenügend. Zb. Solltemperatur überschritten und Ventil bleibt auf 100%. Und Vice versa.
Der Blu TRV GW ist ebenso eine Katastrophe, da er immer mal aufhört, mit den Blu TRV zu kommunizieren (keine Status Updates der TRV).
Die Blu Door sind auch eine Katastrophe, weil zum einen deren Signale immer wieder Mal vom TRV GW oder den TRV selbst nicht verarbeitet werden. Und deshalb Fenster auf/zu nicht beim TRV umgesetzt wird.
Zum anderen ist die FW der Blu Door so schlecht implementiert, dass sowohl im Fenterkippmodus wie auch bei nachlassender Batterie, die Batterie im letzteren durch 4000-8000 Bluetooth Nachrichten innerhalb eines Tages leergesaugt wird.(Wo sie sonst noch über Monate gereicht hätte.)
Die Blu Komponenten von Shelly sind leider komplett ungenügend.
Eine deutsche Firma, wie zb. Bosch oder AVM, würde solche unfertigen Sachen nicht auf den Markt werfen.
Ich überlege die Blu TRV wieder rauszuwerfen. Die simplen Aldi Geräte hatten zuvor 20 Jahre stabil und vernünftig funktioniert. Ggf würde ich auf Fritz Thermostate wechseln.
tvbshelly Hi, dürfte ich deinen Screenshot als Ergänzung im Ticket an die Shelly R&D nutzen?
Strom sehe ich jetzt nicht so problematisch an. Der Shelly benötigt ca. 0,3A die Stunde - d.h. bei 100Ah Batterie komme ich über 30 Tage klar.
pixelpart Hmm wie hast du das gerechnet? meintest du 0,3Ah pro Stunde ? x 24h x 30Tage = 216Ah
Bleibatterien sollen nur max 50% entladen werden, weil sie sonst zum Sulfatieren neigen (unwiederbringlicher Kapazitätsverlust).
Afaik hat ein Shelly eine Leistung von ca 1W, D.h. bei 12V ca 0,08A , x 24h = 2Ah/Tag, d.h. bei 100Ah Batterie und 50% Entladung max 25 Tage.
Aber die bordeigene Elektrik braucht auch Strom im Stand-by. D.h. real wird die Batterie schon deutlich früher leer sein.
Jede 10mA mehr sind da schon bedeutend.
------------------
Den Shelly im Womo kannst du auch lokal ohne WLAN-Router über die App steuern, wenn du dein Smartphone als Hotspot nutzt, und deinen Handy Hotspot als WLAN2 im Shelly einträgst. Dann verbindet sich der Shelly über dein Smartphone Hotspot WLAN mit der Cloud, und mit der App kannst du ihn steuern und konfigurieren.
-----------------
Den Blu button hattest du als Virtuelle Komponente mit dem Shelly 1 gekoppelt?
----------------
Ich hatte überlegt, den Shelly1 in ähnlicher konfiguration mit dem Innenlicht zu koppeln. D.h. der Shelly verbraucht nur strom, wenn das Licht angeht.
Hast du denn den Bacon Modus am Blu Button schon aktiviert??
Ggf dann nochmal schauen, ob die Anwesenheit in Szenen genutzt werden kann.
Oder ggf wenn du den Blu Button an einem anderen Shelly als virtuelle Komponente anmeldest und über die web ui gehst?
Danke.
Schaut ja schon ähnlich aus , wie bei meinen Blu door Shelly s.
Du kannst doch einfach Mal beim Test, den blu door auf einer schrägen Unterlage ablegen und beobachten.
Wenn die Meldungen dann auch weiterhin im Minutenabstand kommen,
haben wir den Beleg, dass das Verhalten reproduzierbar ist, mit beliebigem Blu door.