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.
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.
Hi,
text des o.g. tickets an Shelly:
When angle report threshold value x of Blu DoorWindow (set in the app or WebUI) is exceeded, the Blu DoorWindow starts sending bthomesensor:203 rotation messages every minute !
This behaviour excessively drains the CR2032 battery.
Instead,
when angle report threshold value x is exceeded, the Blu DoorWindow should only once send the rotation message bthomesensor:203 with angle value #.
And it should only repeat/refresh the angle report by a new rotation message bthomesensor:203 again, when the angle # value changes more than the angle report threshold value x.
und weiter:
A) whenver the rotation angle reporting threshold for the Blu Door device is set to 90° ,
>> the Blu Door device sends just 1 BT message when "open", and just 1 BT message again, when "closed". This is correct behaviour.
Pls see attached screenshots, listing a sequence of closed/open/closed statuses; note the timestamps of the logging; compare with the actual time of screenshot top left corner; note that all logs have rotation angle 0° ,despite the window was tilted by 6°. (this is incorrect rotation angle reporting ! and should be corrected too. but is not the main complaint in this ticket)
B) whenever the rotation angle reporting threshold for the Blu Door device is set to 2° (or any other value lower than the window tilt angle) ,
>> the Blu Door device sends ~every minute a BT message when "open", over and over again = BT Message avalanche, despite the window position was not changed.(>> this is the bad SW/feature implementation which should be corrected)
Pls see attached screenshots, listing a sequence of open/open/open/open/open statuses; note the timestamps of the logging; compare with the actual time of screenshot top left corner; note that all logs have a correct rotation angle ~6° (despite the window was tilted by 6°)
C) what the implementation should work like: only when the rotation angle changes to an extend larger than the rotation angle threshold, only then, a BT message with new rotation angle should be send !!
How this could be implemented better:
e.g. Rotation angle threshold 20° would result in a new BT message with new rotation angle report only, when the actual tilt angle changes from previous position for more than the threshold.
e.g.
old angle 0°, new angle 5° (<20° change threshold) >>> no BT Message sent
old angle 0°, new angle 25° (>20° change threshold) >>> yes, new BT Message sent
old angle 40°, new angle 25° (<20° change threshold) >>> no BT Message sent
old angle 40°, new angle 15° (>20° change threshold) >>> yes, new BT Message sent
Finale (unbefriedigende) Antwort des Shelly support:
We have reviewed your case carefully and tested the same scenario internally using Shelly BLU Door/Window devices with the same firmware version and different rotation angle threshold values. At this time, we are unfortunately not able to reproduce the repeated rotation reports and rapid battery drain behavior in our test environment.
When testing with thresholds below the actual tilt angle, the devices behave as expected on our side and do not generate periodic rotation messages unless the angle changes further. Because of this, we cannot currently confirm a firmware defect based on our internal testing alone.
hmm,
kann mir kaum vorstellen, dass ich der einzige bin,
der dieses Verhalten, wie im 1. Screenshot dokumentiert, beobachten kann.
Immerhin ist das Verhalten bei meinen Blu Door Shellys immer gleich.
>>> Frage: Wer mag denn mal seinerseits an seinem Blu Door, die Winkelberichtsschwelle auf 2° einstellen, und dann das Fenster auf Kipp stellen (~6°), und dann schauen, ob die Bluetooth Statusmeldungen des Blu Door ungefähr im Minutentakt reinkommen ? (Zeitstempel)
Danke.
Ich wäre daran interessiert, wie man dasselbe ohne lokales WLAN im Womo realisieren kann. Es scheint da eine Möglichkeit zu geben, aber ich hab's noch nicht verstanden. Vielleicht hat jemand einen Link zu einem entsprechenden Artikel oder hat direkte Info.....
Danke
Das nur so wenige Meldungen eine Batterie in einem Tag leeren sollen, halte ich für völlig unmöglich. Da stimmt etwas anderes nicht.
Jo_Be Doch doch, das stimmt schon. Die letzte Batterie war eine Varta Markenbatterie, und die war auch nach 7852 'bthomesensor' meldungen leergesaugt, im wesentlichen durch die battery meldungen, an nur einem Tag.
Also nochmal, für die, die nicht aufmerksam lesen:
es geht nicht darum, das die Batterie nur einen Tag gehalten hätte.
die Batterien sind über mehrere Wochen/Monate gelaufen.
Aber sobald am Ende die battery Meldungslawine startet, sind die Batterien in einem Tag leergesaugt.
Wo sie doch eigentlich mit der Restkapazität noch über Monate hätten weiter betrieben werden können.
Da liegt das Problem.
Weil sich hier nichts mehr tut, und es anscheinend keine Abhilfe gibt,
habe ich jetzt bei Shelly ein ticket dazu aufgemacht: # 267149
So nun habe ich endgültig Klarheit über den Übeltäter, der die CR2023 Batterie im Blu DW Sensor so superschnell "plötzlich" leer zieht.
Nach dem letzten Batteriewechsel, habe ich die Skripte auf dem Shelly erweitert, der als Bluetooth GW für den Blu DW dient.
Dort werden jetzt die 'bthomesensor' messages des Blu DW weiter aufgedröselt in die vier gesendeten Sensor Kategorien:
200: battery
201: illumination ('light')
202: open
203: rotation ('angle')
Anfangs wuchs nur die Zahl der Meldungen zu open, und gelegentlich illumination. Aber keine Meldungen zu battery und rotation (den MindestWinkel für rotation hatte ich auf 90Grad gesetzt, weil ich den nicht brauche, und der sonst unnötig in 1 Minuten Intervallen weitere Meldungen raushaut und die Batterie auch leer macht)
Irgendwann, zu einem battery Wert x% startete der Blu DW mit einer Lawine von Meldungen 'bthomesensor:200' = battery.
Diese Meldungen kamen im Abstand von Sekunden, und saugten die Batterie in weniger als einem Tag leer !!
(schön zu beobachten unter "last Reporter" in der App)
man beachte die Zeitstempel der Screenshots:
1.1.26 15:37 (beginn der Meldungen "Battery <40%") == 23 battery Meldungen
2.1.26 00:24 Die bthomesensor:200 battery Lawine schreitet fort == 1421 battery Meldungen
2.1.26 00:49 Lawine saugt immer deutlicher per Bluetooth Meldungsflut die Batterie leer == 1612 battery Meldungen
Gleichzeitig ist zu beobachten, dass die illumination Werte absoluter Nonsense sind, im Verlauf der bthomesensor messages Lawine. Es wird dort immer 10000lx als Lichtstärke gemeldet. Was ganz klar unplausibel ist, denn der Sensor liegt im Dunkeln.
2.1.26 09:30 kurz bevor die Batterie total entleert ist == 4745 battery Meldungen
Fazit:
von letztlich insgesamt 4979 bthomesensor Meldungen des Blu DW
sind nur 211 für "open/closed" verwendet worden,
aber 4768 Meldungen sind für "battery low" unnötig verschwendet worden !!!
Mit diesem Puffer von 4768 potentiellen "open/closed" Meldungen hätte der Blu DW Sensor noch über Monate laufen können !!!
Was für eine schlechte SW Implementation. Beschämend.
Das muss Shelly unbedingt in der Blu DW SW korrigieren !!
Hat Niemand sonst dass beobachtet?
Habe jetzt ein Ticket bei Shelly dazu aufgemacht: #267146
Du kannst in der Szene ein virtual device einfügen, das den HTTP-Befehl für eine einzelne Audiodatei ausführt.
ZwergZwack Das ist leider nicht hilfreich.
a) ich nutze die kostenlose Shelly account Version, in der nur eine Virtuelle Komponente in Szenen genutzt werden kann (und die ist schon belegt)
b) warum soll ich mir Gedanken um einen Workaround machen, und mir "von hinten durch die Brust ins Auge schießen", wie man so sagt,
um eine Funktion zu imitieren, die Shelly bitteschön doch gleich korrekt in der App hätte implementieren können.
Shelly SW hat leider unfaßbar viele Fehler und Schwächen von halb und falsch implementierten Funktionen. Ist immer wieder unschön.
Werde heute mal wieder ein paar Tickets bei Shelly aufmachen.
für dieses Thema >>> Ticket: 267078
borsti0 hi,,
Die packet id habe ich in der Ble debug app gesehen. Aber noch nicht in den bthomesensor Messages.
Hast du mal eine vollständige Darstellung der üblicherweise übertragenen Nachrichten ??
So, um dem Verursacher der viel zu schnellen Batterieentleerung auf die Schliche zu kommen, habe ich jetzt 4 zusätzliche Counter eingerichtet, um die Bluetooth Nachrichten zu zählen, die vom jeweiligen Sensor im Shelly Blu Door ausgehen (battery; illumination; open; rotation). Sieht bisher so aus:
Hi,
ich muß die Erfahrung aus diesem Post #10 aus diesem Thread nochmal wieder hochholen. Denn es verdichten sich die Indizien, dass die Shelly Blu DW SW hier der Übeltäter ist, und einfach schlecht implementiert (wieder mal).
Ich hatte beschrieben, dass die Shelly Blu DW, sobald die Batterie leerer wird, anfangen im 15s Takt Bluetooth messages rauszuhauen. Das macht natürlich die Batterie nochmal umso schneller leer. Also ein ganz fatales Verhalten.
Shelly sollte sich besser daran orientieren, wie das bei handelsüblichen Rauchmeldern mit 9V Alkali-Batterie gelöst ist !!
Periodische Meldungen, erst im Tagesrythmus, dann Stundenweise, dann alle 5Minuten.
Aber bitte doch nicht alle 15s ab x% Wert. Das ist dumm.
Indikatoren:
Ich habe den fraglichen Shelly Blu DW, bei dem imer schnell die Batterie leer ist, als Virtuelle Komponente an einen anderen Shelly gekoppelt; dann kann ich die Shelly Blu DW Meldungen per Skript weiterverarbeiten.
Wir haben jetzt 2 Skripte auf diesem Shelly angelegt.
1) Eines zählt in eine Counter als virtueller Komponente die "Open"/"Closed" messages ("bthomesensor:202"), wenn sich dieser Status ändert.
>> die CR2032 Batterie hat durchgehalten, bis die Tür 2139x geöffnet/geschlossen wurde.
2) Das andere zählt grundsätzlich alle Nachrichten vom Blu DW , die "bthomesensor" beinhalten ; denn es gibt ja noch den Batteriewert, den Winkel und die Taste deren Zustand übermittelt wird.
>> die CR2032 Batterie hat durchgehalten, bis die 7852 bthomesensor Nachrichten versendet waren.
Das ist fast die 4-fache Zahl an Bluetooth Nachrichten, die der Blu DW geschickt hat, als für den Zweck (open/Closed) für den ich ihn eigentlich einsetze !!
D.h. ohne die dumme Eskalation an Batteriestandsmeldungen, hätte der Blu DW mit einer CR2032 wohl ein ganzes Jahr durchgehalten; jetzt leider nur ein Quartal, dank dieser schlechten SW Implementation bei Shelly.
Denn,
über fast die gesamte Batterielebensdauer, sind beide Counter synchron gelaufen. D.h. es gab ausschließlich die Open/Closed Meldungen unter "bthomesensor" und "bthomesensor:202" . Also keine separaten Übertragungen zu Winkel, Taste oder Batteriestand.
Erst zum Lebensende der Batterie, hat der Blu HT einen Schwall an "bthomesensor" messages (vermutlich zum schwindenden Batteriestand = "bthomesensor:200") rausgehauen, und damit erst recht die Batterie platt gemacht.
Und dass innerhalb eines Tages !!! (7852-2139)*15s >> ~24h
Sorry, aber ich könnt heulen.
Ich hoffe einer der Senior Experten hier versteht das Problem, kann es nachvollziehen, und weiß dann, wie man das den Shelly Entwicklern klar machen kann, was sie da korrigieren müssen. Mir fehlt dazu leider die Fachkompetenz.
nach meiner Beobachtung muss man den Shelly bluetooth Sachen immer bis zu 30s zur Aktualisierung in Web UI oder App Zeit geben. Das is alles nicht superschnell und Echtzeit. Und wenn dann leider auch noch WLAN und Bluetooth im 2,4GHz Band kollidieren, kann eine Aktualisierung auch mal verloren gehen. Ich bin mit dieser Shelly Blu Lösung auch nicht so zufrieden.
Ich werde das auf den 4 TRV über den Winter mal beobachten. Ggf. fliegen die Shelly zum kommenden Winter dann wieder raus.
