Beiträge von Lapu-Lapu

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.

    Was willst du wissen?

    Ob es mit der 2.2.4 verschlimmbessert wurde?

    Ich habe nur zwei im Einsatz. Der eine tut, was er soll und der Akku ist nach ca. 3 Monaten bei 60%, dann lade ich ihn. Der zweite ist direkt daneben und wird doppelt so schnell entladen.

    Die Bedingungen (RSSI) sind identisch, sie hängen direkt nebeneinander an zwei Heizkörpern.

    Oder bin ich da geistig fehlgeleitet.

    Nein, bist Du nicht. 😉 Ich hab mich zu Beginn auch enttäuscht aufgeregt darüber. Aber letztendlich muss ich akzeptieren, was ich nicht ändern kann. Dann wurde mein Ehrgeiz geweckt, eine mögliche Lösung zu finden und der ist noch nicht wieder eingeschlafen.

    Zumindest bei mir ist das ganze Smarthome Gedöns vor allem Spielzeug für den Mann im fortgeschrittenen Alter und es wäre verdammt langweilig, wenn alles auf Anhieb funktioniert. Ja, die Grenze zur wütenden Verzweiflung ist nie weit weg. Aber wenn dann mal wieder was funktioniert, ist es auch schön. Meine Frau sagt: "Mach nur, dann bist Du weg von der Straße" 😜 Da ist was dran...

    Hier wird nur etwa jedes 3. bis 4. Telegramm registriert.

    Wenn das Timing der Beacon Signale beim BluMotion anders ist als beim Blu H&T, könnte das passieren. Man müsste mal versuchen zu sniffen, was da genau gesendet wird. Möglicherweise muss man das Gateway für BluMotion im Beacon Modus mit anderen Scanner Einstellungen starten, um ein optimales Ergebnis zu bekommen.

    So, als ob das Gateway dann für eine kurze Zeit keine weiteren Geräte verarbeiten könnte.

    Ich nutze unterschiedliche Gateways für Blu H&T (modifiziertes Scanner Timing) und andere BLU Shelly (BluMotion und BluButton ohne Beacon Mode) mit Default Scanner Timing. Da kollidiert scheinbar nichts. Allerdings empfangen ganz sicher alle Gateways alles, was da kommt aufgrund der geringen Entfernung untereinander. Ich filtere über die Blacklist des MQTT Scripts, damit jeweils nur eine MQTT Nachricht pro Blu Gerät erzeugt wird. Das funktioniert im Moment tadellos.

    welche Werte sind seitens der Methode erlaubt ?

    Shelly schreibt dazu in seinen Script Definitionen:

    Scan options allow tuning for scan timings, but some restrictions apply:

    • scan window cannot be longer than 1/3 of scan interval
    • the maximum scan window is 50 ms, but 30 ms seems to be optimal
    • duration must be at least 3 scan intervals long

    If these conditions are not met scanning will not start. In the future, some of these options may not be tunable or the device may choose to modify them for performance and compatibility with other firmware features. It is best to use defaults.

    In diesem Rahmen muss man also sein Optimum finden. Für die BLU H&T scheint 200/50 dieses zu sein. Bei mir laufen jetzt 9 Stück wie ein Uhrwerk an beliebigen Shelly als Gateway mit dem Script und liefern zuverlässig Daten per MQTT.

    Im Abgesang lese ich zwischen den Zeilen "keine neue Firmware aufspielen, wenn es funktioniert", weil sie die Freiheit eventuell weiter einschränken. Dass man am besten die Standard Werte nutzt, ist aber schon mal widerlegt. Mit "default" sind die BLU H&T nicht nutzbar.

    Wer kann mir hier helfen bzw. das Script anpassen?

    Ich habe diese Buttons nicht im Einsatz bzw. gekauft und kann mir folglich nicht anschauen, was die senden. Der ursprüngliche Schöpfer des Scripts ist leider nicht mehr im Forum aktiv. Die Anpassung ist aber keine Raketenwissenschaft. Wenn Du Dir vom Gateway die Debug Logs anschaust, kriegst Du es möglicherweise selbst hin.

    vom GW wird ein Neustart dafür gefordert.

    Wenn man die GW Funktion aktiviert/deaktiviert, will der Shelly immer durchgestartet werden, weil diese Änderung nur dann ausgeführt wird. Nimm den GW Haken raus und klick nach dem Speichern auf Reboot. Danach kannst Du das Script starten und der BLE Scanner läuft mit den Script Settings. Setz das Script auf Auto Start, dann läuft es nach einem Reboot automatisch.

    Das hier läuft bei mir...

    Ich habe da was hingebogen...

    Lapu-Lapu
    13. Oktober 2024 um 16:15

    Hier habe ich neue Erkenntnisse vermeldet...

    Lapu-Lapu
    13. Oktober 2024 um 16:15

    Über das US-Forum zu Shelly bin ich auf eine interessante Idee gestoßen, die einen echt brauchbaren Workaround zu bieten scheint, um die BLU Beacon Geräte zuverlässig an BLU Gateways der verschiedenen Shelly zu binden.

    Dort hat jemand ermittelt, dass echte BLU Events (Tastendrücken, Fenster Auf/Zu, Motion Detection etc.) einen Schwarm von 40 BT Signalen im Intervall von 20-40 Millisekunden erzeugen. Dagegen: Regelmäßige Beacons der BLU H&T oder anderer Geräte mit aktivem Beacon Mode erzeugen nur 6 BT Signale mit ca.150 Millisekunden Intervall (das spart Strom).

    Ein aktiviertes Shelly Gateway in einem Plus oder Pro wird mit einem Standard Scanner Window gestartet, welches vermutlich alle 320ms für 30ms den Scanner lauschen lässt. Die beiden Fenster für Scanner und Beacons übereinander gelegt zeigt, dass es regelmäßig dazu kommen muss, dass Beacons überhört werden, während echte Events nicht überhört werden können. Die beiden Fenster verschieben sich über die Zeit gegeneinander und erzeugen den beobachteten Effekt, dass einen Zeitraum Beacons empfangen werden und dann einen Zeitraum wieder nicht. Die Minis scheinen ein anderes Standard-Scanner-Fenster zu nutzen, weshalb bei Ihnen kleine Lücken ohne große Pausen entstehen.

    Wenn man den Haken für die Gateway Funktion in den BT Settings nicht setzt, kann man den Scanner per Script starten und dabei auch das Scannerverhalten modifizieren. Ich habe im Shelly Script "Blu_to_MQTT" den Scanner auf "duration: -1 (unendlich), active: false, window_ms: 50, interval_ms: 200" eingestellt und das läuft jetzt schon eine Weile.

    Ergebnis: Es wird fast kein Beacon mehr überhört und das ganze funktioniert auch unter Verwendung bisher für Beacons unbrauchbarer Gateways wie dem Plus Plug S, Plus UNI oder dem USB BT Gateway.

    Ich vermute, dass dies auch für Cloud-Nutzer funktionieren könnte, die bisher keine Scripts einsetzen. Man kann den Gateway Scanner auch ohne alles weitere per Script modifiziert starten, wenn man die Gateway-Funktion per GUI nicht aktiviert. Müsste mal jemand testen, der die Shelly Cloud einsetzt.

    Hab beim Shelly Support nochmal nachgefragt, ob es zu meinem Ticket in der Sache etwas neues gibt. Antwort...

    As multiple Times said:

    We have reported the problem directly to our developers, as soon as we receive further information we will let you know immediately.

    Best Regards,

    Shelly Support Team

    Ich geb da jetzt keinen Pfifferling mehr drauf. Ich hab inzwischen eine Lösung per Raspberry Pi Zero gebastelt und mit Shelly Mini als Backup komme ich klar. Dann schauen wir mal...

    dass die offizielle Bluetooth Gateway Schnittstelle per Cloud diese Problematik nicht hat

    Inzwischen geht das Problem längst viral. Nicht nur hier, auch im USA Shelly Forum auf Reddit, in der Shelly Community und bei Amazon häufen sich die Klagen und Beschwerden. Ich habe nur zwei Betroffene mal kontaktiert, beide nutzten Shelly Plus Geräte ohne Scripte direkt mit der Cloud.

    Die Tickets beim Shelly Support häufen sich dazu scheinbar auch und Shelly gewährt offenbar Geld zurück für Käufe direkt bei Ihnen, zumindest in einem mir bekannten Fall.

    Das alles verbunden mit der langen Wartezeit auf eine Lösung lässt nichts gutes erahnen. Shelly hat inzwischen eingeräumt, dass es ein Problem mit den Gateways gibt und dass nur wenige Shelly dafür taugen, dem BLU H&T ein Gateway zu geben. Shelly Mini sind bei mir aktuell noch die besten. Sie liefern kontinuierlich mit nur sehr kurzen Pausen <5 Minuten.

    Offensichtich hat der Fehler System...

    Definitiv... und inzwischen habe ich Zweifel, dass die Jungs und Mädels bei Shelly das fixen können.

    Mit identischer Firmware laufen die Mini Gen2 und Gen3 scheinbar zuverlässig, zumindest bei mir. Kurze Pausen von zwei bis drei Minuten sind verschmerzbar. Wenn aber die gleiche Firmware auf unterschiedlicher Hardware so verschiedene Ergebnisse bringt, ist wohl eher die Hardware das Problem. Wenn dann über so lange Zeit kein Firmware Fix erfolgt, darf man Zweifel haben, ob es überhaupt machbar ist.

    Wie kann ich denn die Sensoren per MQTT anbinden?

    Ich habe dafür ein Script auf dem Shelly laufen, der als Gateway konfiguriert ist.

    Lapu-Lapu
    2. Juni 2024 um 11:28

    Mit den BLU H&T funktioniert es am besten über einen in der Nähe platzierten Mini1 Gen 3 oder Gen 2 für kleines Geld. Wenn ich das USB Gateway oder Shellies der Plus Serie benutze, hab ich auch die von Dir beobachteten langen Sendepausen.

    ...wird denken können, dass das keine zusätzliche Hardware ist.

    Allerdings weckt Allterco die Erwartung, dass Shellies mit der eingebauten Bluetooth-Scanner-Funktion leisten können, was Du mit einem RasPi und BLU_Parser hinbekommst. Dies ist aktuell erst einmal widerlegt. Enttäuschung ist immer das Ergebnis unerfüllter Erwartungen (= Ende der Täuschung). Diese Enttäuschung sollte Allterco beenden, entweder indem sie es zum Funktionieren bringen oder indem sie die Erwartung nicht mehr wecken und sagen "sorry, funktioniert nicht".

    Nebenbei erwähnt - Allterco stellt für die Shellies eigene Scripts in einer Library bereit, die am gleichen Thema scheitern. Insofern versuchen sie gar nicht erst, an 3rd party Scripten zu zweifeln, zumindest nicht mir gegenüber. Eigene Scripts sind natürlich nicht Gegenstand ihres Supports. Aber sie haben wohl längst selbst gemerkt, dass da was klemmt...