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.
Beiträge von bp4willi
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.
-
-
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.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. 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.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
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.
-
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?
-
-
-
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)
-
Mein "Black Friday" Packet is heute nach 10 Tagen aus Bulgarien angekommen.

-
Da lobe ich mir die (österr.) Post - das funktioniert hier 1a und im Zweifel fahr ich lieber zur Postfiliale
Da kennst Du die deutschen Postfilialen nicht.
Da kannst du schon den Bestattervertrag machen, bevor du an den Schalter kommst. ;-))
-
Ob 20 oder 40 MHz finde ich in der Fritzbox keine Info zu.
Ich muss aber mittlerweile meine zwischenzeitlich positive Meldung zurücknehmen.
Ja, mit Kanal 11 im WLAN läuft die Webradio Wiedergabe von WD stabiler. Bricht aber heute auch wieder unregelmäßig nach 20-60 Minuten ab.
Schade.
-
Ich glaube ich komme dem Problem näher.
Fritzbox und repeater waren so eingestellt, dass sie den am wenigsten ausgelasteten WLAN Kanal auswählen. In meinem Fall war das Kanal 6. Als ich gelesen habe, dass sich WLAN und Bluetooth gegenseitig stören können, da beide im 2,4GHz Bereich funken,
habe ich Fritzbox und repeater manuell auf Kanal 11 gezwungen. Seitdem läuft zunächst einmal die WebRadio Wiedergabe über Bluetooth einigermaßen flüssig. Es holpert nur regelmäßig ein zwei Mal wenn man Play aktiviert. Danach lief es zuletzt über zwei Stunden durch.
Da scheint es dann eine gewisse gegenseitige negative Beeinflussung von WLAN und Bluetooth auf dem Funkempfang im Shelly zu geben, wenn WLAN auf Kanal 6 funkt.
Hat sonst jemand ähnliches beobachtet?
-
manchmal reichts den BT-Lautsprecher (JVC-Autoradio) neu zu starten.
Nein, leider nicht. In meinem Fall ist es egal, ob die Ausgabe über BT auf externe Lautsprecher, oder das WD selbst erfolgt, die Webradio Wiedergabe stoppt immer wieder.
Lässt sich irgendwie die interne Auslastung des WD Prozessors auslesen, um zu sehen, ob das ein Auslastungsproblem ist, oder abzugrenzen ob es ein Firmware-Problem ist.
-
Ein kompletter Neustart des Walldisplay hast du auch mal versucht
Ja sicher. Immer wieder Mal. Sind ja in den letzten Wochen auch einige Updates gekommen. Hat bisher aber keine Stabilität der Webradio Wiedergabe gebracht.