Hier habe ich neue Erkenntnisse vermeldet...
Beiträge von Lapu-Lapu
-
-
Ü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.
-
ihr eigenes System auf Cloud-Basis und hier scheint ja die Bluetooth Gateway Funktion einwandfrei zu laufen.
Nein, auch dort sieht man die "Sendepausen".
-
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.
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.
-
Option BCN wird mir nicht angezeigt
BCN ist bei den BLU H&T immer an, daher siehst Du in der App die Option nicht. Man kann BCN nicht an- oder ausschalten.
-
Als ich am Wochenende von der 1.4.0-beta1 las und unter https://shelly-api-docs.shelly.cloud/gen2/changelog/#fixed "BLE Scanner Fix lifetime issues" fand, hatte ich kurz Hoffnung.
Leider vergebens, es läuft nach wie vor nicht richtig. Die Schlaf-Phasen treten immer noch auf. Falls also noch jemand mit dem Gedanken spielt - bringt nichts. Weiter auf ein Fix warten...
-
...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...
-
Versuche es einmal...
...bin schon auf dem Weg dorthin. Meine eigene Lösung ist das eine. Da werde ich wohl Deinem Weg folgen, auch weil ich Spaß am Ausprobieren habe und die RasPis mag. Ein Zero W ist aber noch auf dem Weg hierher, hatte keinen rumliegen.
Aber ja, ich habe auch ein Interesse, dass das mit den Shellies besser wird. Wenn die "Community" das nicht mit antreibt, sondern nur nach "externen Workarounds" sucht, dauert das länger oder kommt nie. Ich hab Shelly noch nicht abgeschrieben. Vielleicht ist meine "Zweigleisigkeit" nachvollziehbar.
-
Irgendwo anders dachte ich.
Aus der Community ShellyUSA auf RedditEntdecke diesen Beitrag und mehr aus der Community ShellyUSAwww.reddit.comJenseits des Atlantik ist das Thema auch angekommen. Die dort vermutete Ursache klingt recht einleuchtend. Wenn im Shelly BLE Scanner eine "Ignore Packets" Funktion fehlerhaft implementiert ist, kann sowas natürlich passieren.
-
Das ist nicht das was ich meinte
Shelly BLU H&T- Update logic and battery lifetime in beacon modeHello, I have two questions: Does the device automatically send updates if either the temperature or humidity does change within a threshold frame, e.g. change…community.shelly.cloudDas hier in der "offiziellen" Shelly Community liest sich doch sehr ähnlich...
-
Wo findet man diese Information?
In dem Faden warst Du auch aktiv...
In den Bildern und Posts von DIYROLLY sieht man, dass sein BLU H&T mit den gleichen kurzen Pausen die Cloud versorgt, wie ich es mit einem Mini 1 G2 als Script-Gateway sehe. Er nutzt ein Shelly Wall Display als Gateway. Das ist noch der brauchbarste Fall, weil "kontinuierlich mit kurzen Pausen" besser ist als "minütlich mit langen Pausen".
Ich werde mir jetzt einen Raspi Zero W beschaffen und Deine Lösung versuchen. Shelly BLE Gateways sind nicht das Gelbe vom Ei - da muss ich Dir schweren Herzens beipflichten. Ich möchte das ganze entweder zuverlässig oder gar nicht. Mit Deiner Lösung kann ich dann auch auf mehr Vielfalt bei BLE setzen. Noch ein Vorteil mehr...
Meinen Raspi 4 sollte ich sicher nicht für den BLE_PARSER nutzen, weil der im Argon Gehäuse vermutlich nicht mehr empfindlich genug ist für den Empfang.
-
Danke Dir dafür, das werde ich ausprobieren. Es klingt danach, dass es meine Anwendungsfälle löst.
du betreibst ja ziemliches Shelly-Bashing
Ich bin auch enttäuscht. Als ich mit dem Smarthome Thema begonnen habe und u.a. auf Shelly setzte, war das durchaus brauchbar. Mir war immer klar, dass ich keine Cloud Lösung möchte, wo irgendwelche IoT Dinger in meinen vier Wänden nach Hause telefonieren und fremdbestimmt werden können. Das hat mit Shelly recht zufriedenstellend funktioniert.
Inzwischen habe ich aber den Eindruck, dass man sich dort viel Mühe gibt, Leute an die Cloud Lösungen zu bekommen und Cloud Verweiger verächtlich betrachtet. Wenn ich den Support bemühe und mich als "cloudless" oute, schalten sie spürbar auf Sparflamme. So toll finde ich das jetzt nicht...
dass das Problem im Script liegt
Cloud Nutzer scheinen die "Denkpausen" der Gateways auch zu beobachten. Wenn aber genügend Gateways nach Hause Daten senden, lässt sich das wegpolieren. Ein MQTT Script auf einem Gateway ohne Cloud legt es offen. Wenn das Script fehlerhaft wäre, sollte es auf allen Gateways die gleichen Probleme erzeugen. Ein identisches Script mit so unterschiedlichen Ergebnissen auf verschiedenen Shellies... was soll da am Script falsch sein? Wenn das Script vom BLE Scanner nichts bekommt, liefert es nicht. Im Debug ist einfach Stille... Da schließe ich das Script als Ursache aus.
-
Wie gesagt, nur ein Gedanke, weil ich nicht wüsste, warum ein Gateway, Script etc. sich so unzuverlässig anders verhalten sollte, wenn im Beacon Modus alle Telegramme ansonsten exakt gleich aufgebaut sind wie jene, die durch Ereignisse getriggert werden.
Ich wüsste auf diese Frage auch gern eine Antwort. Der Shelly Support hat mir nicht darauf geantwortet...
-
Ich würde die Ursache von vermeintlichen Pausen und Lücken ausschliesslich in den Empfängern (Gateways) suchen.
Das sehe ich (inzwischen) genauso. Ich habe jetzt BLU H&T und Motion im Beacon Mode mit verschiedenen Shellies zeitgleich als Gateway laufen lassen. Auf allen habe ich das MQTT-Script laufen und jedes Gateway hat ein spezifisches Topic aus den empfangenen Daten gemacht. Das habe ich übereinander gelegt und geschaut, welches Gateway welche Beacons empfangen und verarbeitet hat, sind ja alle durchnummeriert. Es fehlen über alle Gateways gesehen keine, d.h. die BLU-Geräte senden zuverlässig. Nicht jedes Gateway erkennt ausnahmslos alle. Manche erkennen erstmal alle und machen aber zwischendurch länger Pause, andere machen keine langen Pausen, aber erkennen nur jedes dritte/vierte Beacon.
Die Beacons werden hiier von einem Raspi empfangen und lokal verarbeitet und als mqtt-Daten weiter gesendet
Dazu würden mich die Details interessieren. Wie hast Du das konkret umgesetzt? Ich hab ja auch einen RasPi am Start. Den müsste ich dann anderes platzieren, aber daran wird es nicht scheitern. Magst Du das hier verraten oder auf die Stelle im Forum verweisen, wo es eventuell erklärt ist?
-
ich bekomme maximal alle 90 Sekunden Daten
Das wäre für mich der bessere Fall. Bei meinen bisherigen Tests zerfällt das Testfeld in zwei Welten. Entweder bekomme ich im Beacon Mode sehr gleichmäßig alle Daten, dann aber nur eine Zeit lang und danach lange gar nichts mehr, bevor es wieder losgeht. Oder ich bekomme die Daten mit kleinen Pausen, dann aber kontinuierlich.
-
Ich nutze die Blu-Geräte aktuell noch immer mit dem Blu to MQTT Script...
Genau so mache ich das auch. Für Trigger-Events meiner BLU Motion und BLU Button funktioniert das perfekt. Das Script läuft hierbei auf verschiedenen Plus Plug S.
BLU Motion im Beacon Mode oder BLU H&T (die sind immer im Beacon Mode) treten die genannten Probleme auf.
-
So langsam nervt das ganze... ich bin kein Fan von Re-Engineering, aber wenn der Shelly Support schweigt, bleibt einem nichts anderes als MUP (Methode unbekümmerten Probierens).
Nächstes Beobachtungsergebnis meiner Tests mit unterschiedlichen Shellies als BLE Gateway für verschiedene BLU Devices im Beacon Mode:
- BLU Button im Beacon Mode liefern an allen bei mir verfügbaren Gen2 Shellies klaglos.
- BLU Motion im Beacon Mode und BLU H&T liefern am Shelly Mini 1 G2 alle 3-4 Minuten Beacons, ohne einzuschlafen. An allen anderen verfügbaren G2 Shellies liefern sie mehrere Stunden regelmäßig, um dann für ein paar Stunden komplett Pause zu machen.
- BLU D/W hab ich nicht verfügbar...
Getestet habe ich jeweils unter Firmware 1.3.2 mit Plus Plug-S, Plus 1, Plus UNI und Mini 1 G2 mit kurzer Distanz (2..3 Meter) zwischen den Spielern. Vermutlich muss ich mir den ganzen Shelly-Bauchladen nach Hause kommen lassen. Meine heimische "Finanzministerin" zieht schon die Stirn in Falten.
Das sollten die bei Allterco eigentlich besser testen können, machen sie aber nicht...
