Beiträge von Lapu-Lapu

    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?

    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... X(

    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. :/

    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.

    Meiner sendet laut Zeitstempel alle 1-8 Min.

    Welche Firmware Version läuft auf Deinem BLU H&T?

    Vielleicht ist meiner ja defekt und es liegt gar nicht an der Firmware. Ich finde es auf jeden Fall spannend, dass Du "anders geartete" Lücken beobachten kannst als ich.

    Bitte sieh dir das doch einmal an und berichte hier...

    Wenn ich beobachte, dass ich keine Daten mehr per MQTT empfangen kann, scanne ich mit der Shelly BLE Debug App in der Nähe des Sensors, ob er tatsächlich schweigt. Das ist so. Mit der Taste am Sensor kann ich ihn dann kurzzeitig wecken.

    Ich hatte auch erst das Gateway in Verdacht und habe viel Zeit damit verbracht, das auszuschließen. Ich hatte bis zu vier Gateways auf unterschiedlichen Shelly in der Nähe platziert und ausgewertet, ob alle gleichzeitig nichts mehr empfangen. Inzwischen bin ich aber sicher, dass der Sensor einfach "die Geige einpackt".

    Kann natürlich sein, dass meiner eine Macke hat.

    Also ist Jemand der viele gleiche Werte sieht, glücklicher wie Jemand der wenige gleiche sieht ;)
    Für mich ist gleich gleich und nur ab einer gewissen Änderung macht das Sinn und dann kommt noch die Abweichung hinzu.

    Ich möchte Dir gern zustimmen, aber...

    Ich hab meinen BLU H&T gestern vormittags vom Keller auf einen meiner Balkone verlegt. Der zeigt nach Nordwesten und bekommt daher Abendsonne. Das Einschlafen des Sensors scheint nicht davon abzuhängen, wie klein die Änderungen sind. Im aufgezeichneten Temperaturverlauf sehe ich deutliche Pausen, in denen mutmaßlich recht viel Veränderung geschieht, wenn man schaut, mit welchem Wert es nach der Pause weitergeht. Ich habe den mutmaßlichen Verlauf der Temperatur mal versucht, rot zu interpolieren.

    Die aktuell angezeigten 16.8°C sind jetzt auch schon deutlich überschritten (21°C) und er schläft mal wieder.

    Ich habe dieses Problem dadurch gelöst, dass ich nicht nur die aktuelle Leistung auswerte, sondern auch den Verbrauch der letzten vergangenen Minute(n). Die Shellys liefern diese Info per MQTT und mein OpenHAB wertet es aus, schaltet den Shelly beim Erreichen des Knitterschutzes aus und schickt mir eine Nachricht, dass der Trockner fertig ist. Das funktioniert zuverlässig. Der Verbrauch pro Minute unterscheidet sich signifikant während des Trocknens und des Knitterschutzes.

    Ob sich das auch über die Shelly Cloud Lösung realisieren lässt, kann ich mangels Erfahrung damit nicht sagen. Meine Shellys dürfen nicht nach Hause telefonieren.

    Mit Beacon Mode soll der ja jede Min. senden.

    Der Beacon Mode soll laut Allterco bei BLU H&T immer aktiv sein. Es gibt auch keine Möglichkeit, per Debug App hier was zu ändern, so wie es die BLU Button und Motion per Debug App erlauben. Im neusten Firmware Release hat sich hier leider auch nichts verändert. Also weiter warten...

    Aber mal ehrlich... wenn ich sowas im Keller habe, was kein "Kleingeld" wert ist, käme ich nie auf die Idee mich mit BT zu beschäftigen.
    Du hast ein übergeordnetes System und ich hätte mir was angeschafft, was kontinuierlich Daten sendet und keine 20-30€ kostet ;)
    Ich sehe es grundsätzlich so: Wenn ich mir was qualitativ höherwertiges kaufe kommt da auch nur was passendes dran. An einem 1000€ TV kommt kein 50€ BR Player dran oder guter Receiver und günstig Lautsprecher.

    Da bin ich ganz bei Dir. Ich hab einen Klimaschrank im Keller, den hab ich verkabelt und das tut tadellos seinen Job im Moment. Der Rest ist erst einmal Spieltrieb und Interesse. ;)

    Aber ich kenne da Leute, die haben reichlich von den Dingern am Start (Gastronomen). Auch wenn da ordentlich Werte rumstehen und drin liegen, sind die trotzdem knauserig bzgl. Investitionen. Ich will das gar nicht bewerten. Jeder wie er mag und vielleicht liegt es daran, dass es schwäbische Gastronomen sind. :P

    Also suche ich nach der Lösung mit dem besten Preis-Leistungsverhältnis. Der BLU H&T ist für mich noch nicht aus dem Rennen, wenn an der Firmware noch gestrickt wird. Das Teil ist ja brandneu. Da hab ich keine Eile und der Erkenntnisgewinn macht ja auch eine gewisse Freude. Auch hab ich keinen Schmerz, von der Benutzerseite der Shelly/Allterco-Truppe Input zu liefern, wenn sie es denn mögen und schätzen.

    Zu dem Diagrammen.. was zeigen die denn an?

    Grün 0-70% und wozu >250°C ?

    Grün ist die Packet-ID (0..255), Blau die Luftfeuchte, Gelb die Temperatur. Die Legende ist unten zu sehen. Leider überlagern sich die Skalen für PID und Temperatur auf der rechten Seite, weshalb das nach 250°C aussieht. Die Temperatur schwankt im Bild zwischen 16 und 18°C. OpenHAB kann das leider nicht besser darstellen, wenn man mehr als zwei Werte ins Diagramm packt. Erst über das Monitoring der Packet-ID kann ich sehen, ob kontinuierliche Werte echt sind oder nur aus einem schlafenden Sensor herrühren.

    SInd >0,5°C eine starke Abweichung

    Vor der Haustür sicher nicht. In der Wohnung oder im Keller auch nicht. Aber ich hatte geplant, mit dem BLU H&T Weinklimaschränke zu überwachen, ob sie funktionieren. Die sind dafür gemacht, konstante Werte zu halten und dort schläft der Sensor dann einfach ein. Wenn da aber entsprechend wertvolle Tröpfchen drinnen sind, möchte ich kurzfristige Schwankungen von 0.5°C durchaus gern sehen. Sie wären auf Dauer nicht wünschenswert und könnten außerdem darauf hindeuten, dass mit dem Schrank was nicht stimmt. Sicher ein etwas spezieller Anwendungsfall...

    Kaufe dir doch einfach kontinierlich messende Geräte,

    Aktuell erledigen das auch kabelgebundene Sensoren und Shelly UNI. Die Kabeldurchführung durch die Dichtungen der Türen ist nicht optimal und oftmals störend und ich hatte auf Abhilfe gehofft. H&T G3 hab ich schon probiert. Sie senden bei kleinen Schwankungen nicht bzw. nicht kontinuierlich (ist auch so spezifiziert), sind recht groß (in den Schränken ist nicht viel Platz) und waren daher durchgefallen. Als ich las, dass der BLU H&T im Beacon Mode arbeitet, hatte ich eben Hoffnung...

    Ich bin beruflich gewohnt, dass gegen Spezifikationen getestet wird und diese eingehalten werden. Wenn Shelly hier (https://shelly-api-docs.shelly.cloud/docs-ble/Devices/ht) schreibt: "There are no device specific settings. Beacon mode is always active. It is the main function of the device.", weckt das bei mir die Erwartung, dass es auch so ist. Vielleicht kannst Du diese Haltung ja nachvollziehen.

    Ich gebe zu, dass es "pingelig" klingen mag. Das ist mir so "anerzogen" worden... ;)

    Was mich wundert, man kauft ein Gerät und weiß vorher was es kann und nicht kann und nicht dauernd Werte sendet und meckert rum...

    Genau das ist der Punkt. Ich wusste es nicht, weil die Spezifikation etwas anderes aussagt. Siehe oben...

    Die vom Shelly Support haben sich übrigens gestern gemeldet, dass die Softwerker sich das anschauen und darüber nachdenken, was getan werden könnte. Das macht mir wieder etwas Hoffnung. Ich hatte denen auch versucht zu erklären, was ich mit den Sensoren machen will. Es kann schon mal passieren, dass die Praxis mit Anwendungsfällen um die Ecke kommt, die man nicht auf dem Schirm hat und sich daraus Änderungen am Produkt ergeben. Ich sehe das eher als einen positiven Effekt während einer Produktentwicklung.

    Bisher schweigt der Shell Support zu dem Thema beharrlich und hat meine Tickets zu diesem Thema einfach geschlossen, als ich wohl zu renitent nachgefragt habe, wie ich das beobachtete Verhalten deuten soll.

    Ich schreibe jetzt seit einiger Zeit die gesendeten Messwerte und die Packet ID der Beacons mit und man kann recht gut erkennen, dass der BLU H&T nach einer gewissen Zeit ohne starke Schwankungen der gemessenen Werte keine Beacons mehr sendet. Die stetig linear steigende Kurve der PID verläuft dann horizontal. Bei einer starken Abweichung von >0.5°C oder 5%Punkten wacht er auf und sendet erst mit größeren Lücken (Treppenstufen in der PID-Kurve), bevor dann wieder jede Minute eine Beacon-PID empfangen wird. Die fehlenden PIDs scheinen aber intern hochgezählt zu werden, auch wenn sie nicht gesendet wurden. D.h. gemessen und gezählt wird schon, gesendet irgendwann nicht mehr.

    Ich hab die Kurven hier mal beigefügt. Gemessen wird in meinem Keller. Der liefert stabile Werte, es sei denn, ich lasse mal das Fenster offen oder der Wäschetrockner läuft mal.

    Dass man durch penibles Re-Engineering heraus finden muss, was die da so in ihre Programmcodes reinfrickeln, nervt mich schon gewaltig. Wenn man sie dann damit konfrontiert, machen sie dicht und man wird exkommuniziert. Das hat irgendwie einen schalen Beigeschmack.

    Auf jeden Fall taugt der H&T damit nur unzureichend in stabilen Umgebungen als feinfühliges Messinstrument. Ich würde mir wünschen, dass so eine Batteriesparfunktion abschaltbar ist und man sich bewusst für einen echten Beacon-Mode entscheiden kann, der dann halt die Batterie schneller entleert.

    Ein paar Tage verspätet, doch besser spät, als nie... Ich bin jetzt auch hier.

    Stiller Leser war ich schon eine ganze Weile, jetzt hab ich mich mal aus meiner Lauschecke heraus getraut.

    Mein Smarthome steht am Stadtrand von Schwäbisch Hall, es wurde im Corona-Lockdown geboren, weil ich irgendwas machen musste, um nicht hohl zu drehen. Aktuell sind ca. 70 Shelly-Komponenten am Start - Tendenz immer noch steigend. Nach Hause dürfen die alle nicht telefonieren, sondern werden von einem RaspBerry Pi mit OpenHAB dirigiert. Ich bin zwar kein genereller Cloud-Verächter, aber ich habe keine Lust, dass mir irgendwer, den ich nicht kenne, in meiner Bude rumschalten kann.

    Nach anfänglicher Skepsis meiner Ehefrau ("was bastelt der denn jetzt schon wieder für Zeugs zusammen"), ist der für solche Projekte durchaus entscheidende WAF (Women Acceptance Factor) im positiven Bereich, also darf ich weiter an meinem Smarthome stricken - und das tue ich auch. :S

    Ich war so frech und habe das Skript um den ShellyBLU HT ergänzt. Die vorbereitete Luftfeuchtigkeit war nicht die richtige. Ich hoffe, dass es so passt. Außerdem habe ich eine Blacklist hinzugefügt, damit man je nach Gateway MAC-Adressen blockieren kann, damit die Meldungen nicht mehrfach per MQTT versendet werden. Es funktioniert, aber wahrscheinlich ist es nicht schön gemacht, bin kein Profi.

    Das Blacklist-Feature ist gut, wenn man (so wie ich) mehrere Gateways zur sicheren Abdeckung des gewünschten Areals laufen hat.

    Ich habe mir auch drei Anpassungen erlaubt:

    - In Zeile 18 kann man den Parameter "send_pid" setzen. Damit kann man im sparsamen Sendemodus trotzdem die PID übermitteln lassen. Wenn man prüfen will, ob alle Päckchen tatsächlich ankommen oder welche doppelt zugestellt werden, ist das hilfreich. (In Zeile 312 wird der Parameter ausgewertet.)

    - Zeile 43 sorgt dafür, dass die Temperatur- und Feuchtigkeitsdaten mit der Input-ID "d1" gesendet werden.

    - Zeile 171 hab ich so angepasst, dass auch beim BLU H&T das Alive-Paket mit der Device-ID (beim H&T ist das die 2.3) als Input-ID gesendet wird.

    Damit verhält sich der BLU H&T analog zu den anderen BLU Geräten, wenn sie durch das Script behandelt werden.