Beiträge von bp4willi

tvbshelly Hi, dürfte ich deinen Screenshot als Ergänzung im Ticket an die Shelly R&D nutzen?

Zitat von pixelpart

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

Zitat von Jo_Be

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

Zitat von ZwergZwack

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.

Zitat von fmeyer84

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.