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.
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.
WENN temp > 25grad DANN schalte shelly (tor fährt hoch) & 2 sekunden später schalte shelly wieder (tor bleibt in der position stehen)
Wenn du mit Schalten meinst, dass der Shelly jeweils nur einen Impuls abgibt für Antrieb Start bzw Stop, dann kann das funktionieren. Mußt dir nur überlegen, wie du den shelly 2x nacheinander den Impuls geben läßt.
meine TRV GW haben diese FirmW und keine Probleme: 20250924-062652/1.7.1-gd336f31
Cannondalefan warum glaubst du dass Chat GPT dir irgendeine qualifizierte Antwort gibt ?? Chat GPT Antworten sind in der regel unpräzise und im Zweifel frei erfunden. Das ist bekannt.
FrankS wenn du die Web ui des TRV Gateway aufrufst, welche Verbindungsqualität wir dort je TRV angezeigt ? Good oder Weak ? Bei Weak, mußt du für den TRV GW einen besseren Standort finden.
FrankS in der Web ui des trv GW ist für die trv noch ein Parameter der Zeitverzögerung in Sekunden einstellbar. Default 30sek. Wir das Fenster geöffnet regelt der trv nach dieser Zeit runter.
Den Wert habe ich jetzt für 3 trv auf 2 Sekunden geändert, damit die Regelung zeitnah anspricht.
Auf einem trv habe ich die 30 Sekunden belassen , weil wir dort die Türe immer mal wieder kurz öffnen. Da soll nicht jedesmal der trv anlaufen.
In der App ist dieser Parameter nicht sichtbar. Hat Shelly wohl bisher versäumt, dort zu replizieren.
Halber Kram. Es gibt einfach zuviel unnötige Differenzen zwischen dem, was man in der App bzw der Web ui einstellen kann, bei den diversen Shelly Geräten. Da sollte eine Shelly interne Projektgruppe mal aufräumen.
Denselben Fehler beobachte ich auch.
Nach einem reboot geht es dann temporär wieder . Aber am Folgeabend wieder nicht.
SW Pflege muss Shelly noch besser strukturieren.
joma0815 leider hat es nichts genutzt. Ist die winkelberichtsschwelle auf 90 Grad, kamen gar keine Kippmeldungen mehr vom Fenster, was ja auch der Funktion entspricht. Setze ich die WBS auf 0 Grad zurück kommen wieder die unerwünschten minütlichen statusupdates.
tvbshelly ich habe auch mal per Shelly ble debug app den beacon modus geprüft, war ausgeschaltet. Habe dann auch mal über die ble debug app den beacon modus ein und wieder ausgeschaltet. Kein Effekt. Die Statusberichte kommen immer noch minütlich, bei gekipptem fenster.
Ich finde dass ist 1. ein fehlerhaftes Verhalten , wenn der Kippwinkel sich nicht ändert, sollte auch kein neuer Status gesendet werden. 2. brauchen die zusätzlichen statusupdates unnötig Batterie.
Und nicht alle Blu Door Kontakte arbeiten so. Manche arbeiten normal, wie erwartet, mit nur einem Status wenn Fenster gekippt. Alle haben denselben SW Stand und selbe konfiguration
Was für ein SW Müll ist das wieder von Shelly. Die Blu Komponenten sind echt nervig.
Gibt es noch andere Ideen, woran das liegen kann, oder wie man das abstellt??
Danke euch beiden.
Werde es mal mit der 90 Grad Berichtsschwelle versuchen.
Ich habe jetzt 8 Blu Door Window Kontakte im Einsatz.
Manche liefern wie gewünscht je einmal einen Bericht ab, wenn geöffnet oder geschlossen wird. Sonst nicht.
Andere liefern jedoch, wenn geöffnet, jede Minute einen Open Bericht ab. Das kostet natürlich Batterie.
Woher kommt das? Wie kann ich das abstellen?
Alle Blu Door sind identisch eingestellt. Kein beacon modus. Winkelberichtsschwelle 2grad.
Auf der web ui des trv GW erscheint die Open closed Meldung des Fensterkontaktes ebenso schnell, wie auch in der App. Aber mal stellt der trv die Temperatur nicht runter, mal nur mit erheblicher Verzögerung.
Unerklärlich.
Habe jetzt nochmal den 2,4ghz WLAN Kanal geändert. Vielleicht kollidiert das mit der Bluetooth Kommunikation.
Die Zeitpläne in der App für den trv sind in der Web ui nicht zu finden. Heißt dass , das alle App Einstellungen über die Cloud abgewickelt werden? D.h. wenn die trv auch ohne Internet funktionieren sollen, muss ich die Zeitpläne und Fenster Reaktionen entsprechend in lokalen Aktionen auf dem trv GW abbilden??
Als erstes immer im Loggbuch des Gateway schauen (Menü: Diagnostics ). Dort muss sofort die Öffnung angezeigt werden ("data": "shelly_blutrv.cpp:1503 'blutrv:200' - WindowsOpened, delay=15",)
Zumindest beim TRV wird in der App das Fenster als offen angezeigt . TRV reagiert aber nicht.
