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.
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.
https://www.reddit.com/r/ShellyUSA/co…g_transmission/
Jenseits 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
https://community.shelly.cloud/topic/1301-she…e/#comment-6328
Das 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:
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... 
Funktioniert bei mir nur auf einem Mini1-Gen3 zuverlässig. Alle Plus und Pro Shellys machen Probleme und pausieren mehrmals am Tag 60-90 Minuten, bevor sie wieder Daten empfangen. Dabei kommen die Einzel-Events (Tür auf/zu) zuverlässig an, nur der Beacon-Mode ist betroffen.
Wie schaut es mit dem USB Bluetooth Gateway aus? Funktioniert das zuverlässig für den Beacon Mode?
Schalte den Beacon Mode mal ab, bekommst ja nicht mehr Daten.
Geht beim H&T nicht, der kann nur Beacon.
Ich beschäftige mich gerade mit BLU H&T und bin auch in die Falle getappt. Hier mein Text im anderen Forums Faden...
Fazit für jetzt: Als Gateway taugt nicht jeder Shelly-Typ gleichermaßen gut, wenn man Beacons empfangen will. Meine BLU Motion und BLU Buttons laufen nicht im Beacon Mode und es gab bisher keine Probleme. Alle nutzen Plus Plug-S als Gateway.
Muss man jetzt ausprobieren, welche Shelly als Gateway für Beacons taugen? Der Shelly Support schweigt beharrlich dazu... 
Gestern hab ich einen zweiten BLU H&T platziert und mit dem Plus Plug-S als Gateway verheiratet. Beide H&T haben dann dieses Verhalten gezeigt. Alle paar Stunden wechselten die Phasen aus minütigen Daten und völliger Ruhe - aber nicht synchron!
Gestern Abend hab ich dann die Gatewayfunktion auf einen Mini 1 geschwenkt. Entfernung nahezu identisch, Firmware identisch. Der eine H&T hat danach 20 Minuten lang jede Minute Daten geliefert, der andere knapp 40 Minuten lang. Seitdem empfange ich von beiden alle 4..5 Minuten eine Nachricht. Es gibt seltene Ausnahmen mit kürzeren Intervallen. Jede Minute definitiv nicht mehr, aber eingeschlafen ist es bis jetzt auch nicht mehr.
Fazit für jetzt: Als Gateway taugt nicht jeder Shelly-Typ gleichermaßen gut, wenn man Beacons empfangen will. Meine BLU Motion und BLU Buttons laufen nicht im Beacon Mode und es gab bisher keine Probleme. Alle nutzen Plus Plug-S als Gateway.
Plus Plug-S und Mini 1 sind beide Gen2. Gen 3 Shelly hab ich im Moment keinen. Ich hab noch ein paar andere Gen2 da. Jetzt werde ich mal anfangen zu vergleichen.
Was ich noch nicht verstehe: in den "Sendepausen" empfange ich auch mit der BLE Debug App auf dem Smartphone keine Beacons, d.h. die H&T hören wirklich auf zu senden. Auf welche Weise beeinflusst das Gateway den Beacon Sender in seinem Verhalten? Ich war der Auffassung, Beacons sind unidirectional und best effort, also senden und vergessen. Statt dessen scheint es so zu sein, dass die Beacon Sender irgendwas vom Gateway bekommen, das sie ihr Sendeverhalten ändern lässt.
das WD in der Nähe
(vielleicht ist die Frage dumm) Was bedeutet "WD"?
Ich vermute es gibt evtl. ein anderes Problem, mein H&T funktioniert problemlos seit ca. 3 Monaten.
Ich bin gerade auf diesen Faden im Forum gestoßen und die Antwort von Norbert an zweiter Stelle lässt mich aufhorchen.
Funktioniert bei mir nur auf einem Mini1-Gen3 zuverlässig. Alle Plus und Pro Shellys machen Probleme und pausieren mehrmals am Tag 60-90 Minuten, bevor sie wieder Daten empfangen. Dabei kommen die Einzel-Events (Tür auf/zu) zuverlässig an, nur der Beacon-Mode ist betroffen.
Ich werde mich doch noch einmal bemühen, statt meiner Plus Plug S andere Shelly als GW zu verwenden. Das klingt irgendwie nach meinem Thema mit den plötzlich ausbleibenden Beacons von meinem H&T.
