Beiträge von bp4willi

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.

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??

Zitat von pinie_pinie

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.

Zitat von MIHO

Hast du das aktiviert beim nicht reagieren Shelly BLU TRV?:

Ja , hab ich in der App aktiviert.

In der Web ui werd ich nochmal kontrollieren.

Mit unschöner Regelmäßigkeit verzweifle ich an der NichtFunktion der Shelly Geräte.

Heute habe ich zwei Shelly Blu TRV mit einem TRV Gateway gekoppelt.

Dann den einen TRV mit drei Blu Door gekoppelt. Wird eines der Fenster geöffnet, wird im TRV (mit deutlicher Zeitverzögerung) die Temperatur gedrosselt.

Den zweiten TRV am selben Gateway habe ich mit nur einem Blu Door gekoppelt. Hier passiert am TRV garnichts, wenn ich das Fenster öffne. Obwohl in der App in den TRV Einstellungen klar zu sehen ist, dass die Mitteilung des Blu Door zum offenen Fenster einwandfrei ankommt.

Temperaturänderungen über die App nimmt der TRV problemlos an.

Was läuft hier wieder falsch?

Habt ihr Tipps, welche Einstellung ich nochmals kontrollieren oder korrigieren sollte?

Wenn man Audiodateien über Aktionen abspielen lässt mittels Http Befehl funktioniert die Wiedergabe einer einzelnen Audiodatei einwandfrei.

Nur eben nicht über Szenen. In Szenen wird die gewählte Audiodatei und alle in der Auflistung nachfolgenden nacheinander abgespielt.

Hi,

mir ist aufgefallen, wenn ich den Mediaplayer des Walldisplay in einer Szene einsetze, um eine Audio Datei abzuspielen, macht der WD Mediaplayer einen Fehler.

Ausgangssituation: über das WD Webinterface sind mehrere mp3 Audiodateien für den Mediaplayer hochgeladen; die Audios sollen einzeln zu verschieden Zwecken in Szenen genutzt und vom WD Mediaplayer abgespielt werden. Die Nummerierung der ID's der Audiofiles ist nicht identisch mit der Reihenfolge der Darstellung im Webinterface. Im Beispiel im Webinterface Reihenfolge 1.Datei=ID16 ; 2.Datei=ID5 ; 3.Datei=ID4

Fehlerbild:

• in einer Szene soll nur die 2. Audiodatei wiedergegeben werden (ist so in der Szene ausgewählt und gespeichert) >>> stattdessen werden das 2.+3. File nacheinander abgespielt !!
• in einer Szene soll nur die 1. Audiodatei wiedergegeben werden >>> stattdessen werden alle 3 Files nacheinander abgespielt !!

Das ist nicht schön, nicht hilfreich.

Ist das sonst noch jemandem aufgefallen ??

(Die Suchfunktion brachte zum Begriff "Mediaplayer" kein Ergebnis)