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.
-
Auch dort kann’s wichtig sein.
Das führt weg vom Thema. Hat den BLU TRV schon jemand in den Händen gehalten oder sogar ausprobiert? Zum Beispiel auf der IFA?
Mich interessiert von allem dies: Es gibt ja zahlreiche preiswerte Bluetooth Steller für diesen Zweck, aber bei denen ist die Schnittstelle in der Regel zu einer App oder Cloud. Da wäre Shelly natürlich besser, wenn sie die Schnittstelle zu ihrem Steller per WiFi und ohne Cloud möglich machen.
Übrigens ist der Text auf der Webseite deutlich:
Smartes, Bluetooth-gesteuertes und WLAN-fähiges* Themostatventil für präzise Raumtemperaturregelung
*Ein Gateway ist erforderlich
-
Für jedes Bluetooth-Gerät von Shelly braucht man ja einen Gateway
Ein Gateway ist in der Regel bidirektional. Das ist aber bei einigen Shelly BLU Geräten gar nicht erforderlich. (Beispiel: BLU Motion)
Allerdings bei einem Heizkörper-Steller schon. Und da wäre es angenehm, wenn das Gateway eine transparente Schnittstelle zum Steller bildet, sozusagen das Gerät ist.
-
Auf der von mir im ersten Beitrag verlinkten Seite (Shelly BLU TRV Single pack) wird in zweiten Foto von links deutlich, dass es offenbar immer eine Kombination aus zwei Teilen ist. Das wäre mir auch völlig egal (zumal die Kombination preiswerter ist als das vorherige WiFi-Modell alleine), wenn es denn möglich ist, beide Teile als ein Gerät zu behandeln und das natürlich ohne Cloud.
Wenn man also mit dem Gateway spricht wie mit einem gängigen Shelly-Wifi-Gerät, und das Gateway einfach die Kommunikation in Bluetooth übersetzt und zum Steller schickt (und holt), so dass die Kommunkation mit dem Gateway erfolgt als wäre es das Shelly-Gerät.
-
Offensichtlich irrt die Knowledge Base an dieser Stelle.
Wenn ich es richtig verstehe, kauft man den Steller, der nur Bluetooth kann, immer zusammen mit einem speziellen Gatway, das die Daten dann so aufbereitet, dass beide zusammen wie einen Shelly-übliches Wifi-Gerät funktionieren?
-
Der Shelly BLU TRV ist laut der Shelly Webpage verfügbar.
https://www.shelly.com/de/products/shop/1xsblutrv
Hat den schon jemand ausprobieren können?
-
Warum googeln, wenn es doch hier noch schneller geht mit einer Antwort..
-
Wie im Betreff geschrieben:
Was bedeutet "Type F" auf der Schachtel beim Plus Plug S?
Danke für Infos.
-
Es sind 120A-Stromwandler!
Ist das eigentlich störend (dh werden die Ergebnisse ungenauer oä.) wenn die Wandler-Öffnungen so gross sind bei kleineren Leitungen?
-
Es wäre natürlich schade und keine gute Sache bei Shellys, wenn die Entladung der Batterie dort anders geprüft und übermittelt würde, als es bei anderen einfachen BLE-Geräten der Fall ist, wie zum Beispiel von Xiaomi Mi Thermometern, die das sehr präzise tun. Tja, auch wenn hier einige offenbar so negative Erfahrungen in dieser Hinsicht mit Shellys gemacht haben, bleibt das erst einmal abzuwarten.
-
Sorry, aber hier geht es ja auch um ein Shelly-Problem? Da es offensichtlich Softwaremängel gibt, sind die zu beheben und nicht durch zusätzliche Hardware zu umschiffen.
Genau das meine ich: Hier gibt es kein "Shelly-Problem". Hier funtioniert alles wie es soll und gewünscht ist. Es wird hier weder etwas "umschifft" noch treten hier "Softwaremängel" zutage. Das ist alles nur dann relevant, wenn man sich im Shelly-Kosmos bewegt. Und noch ein wichtiger Hinweis an Leute, die in diesem Thread landen sollten via Suchmaschine: Der Shelly BLU-Motion Bewegungsmelder hat keinerlei Softwaremängel, er hat keinerlei "Shelly-Problem", er funktioniert einwandfrei und ist sehr zu empfehlen. Die Batterie wird auch nicht durch den Beacon-Mode über Gebühr belastet, im Gegenteil: die Batterie ist nach 1 1/2 Monate Betrieb immer noch im selben Ladezustand wie zu Anfang..
Die anfängliche Behauptung in diesem Thread war ja (IIRC), dass der BLU-Motion seine Beacons nicht sauber kontinuierlich einen nach dem anderen ohne Pausen und Lücken sendet: Diese Vermutung/Behauptung war und ist falsch: Der BLU-Motion macht keine Fehler beim Beacon-Senden.
Und was sogenannte "zusätzliche Hardware" anbetrifft: die ist bei eine BLE-Gerät immer erforderlich. Nur wer sich offenbar ausschliesslich im Shelly-Kormos bewegt und Shellys mit einer Bluetooth-Gateway-Funktion sowieso besitzt, wird denken können, dass das keine zusätzliche Hardware ist.
-
Ich hab Shelly noch nicht abgeschrieben.
Ich natürlich auch keinesfalls. Vor allem weil Shellys (ua mit Tasmota, aber eben auch bereits mit der eigenen Firmware) ohne Cloud funktionieren, oder besser ausgedrückt: lokal funktionieren. Und WLAN statt Zigbee ist hier auch in einigen Fällen unabdingbar.
-
Jenseits des Atlantik ist das Thema auch angekommen. Die dort vermutete Ursache klingt recht einleuchtend. Wenn im Shelly BLE Scanner eine "Ignore Packets" Funktion fehlerhaft implementiert ist, kann sowas natürlich passieren.
Danke, dass du dich um das Thema so bemühst. Die Ursachenforschung ist ja schön und gut, aber die Lösung ist doch genauso einfach: Einfach Shelly Shelly sein lassen und einen anderen Beacon-Empfänger verwenden. Versuche es einmal...
-
BLU H&T schläft ein
In dem Faden warst Du auch aktiv...
Nunja, hier im Forum.... Das ist nicht das was ich meinte. Das ist ja im Mustopf. Irgendwo anders dachte ich. Hier dreht sich ja immer alles nur im Shelly-Universum.
-
wäre mein Vorschlag, dass ihr mal
"Ihr"? Da hast du etwas falsch verstanden: Ich brauche und nutze keinerlei Shelly-Bluetooth-Gateway-Funktionalität. Ich halte das und auch Scripte dazu auf Shellys für nicht sinnvollen Spielkram, der ja offensichtlich auch nicht zuverlässig funktioniert. Ich habe bessere, vor allem dauernd funtionierende Beacon-Empfänger unabhängig von Shelly zur Verfügung. Und Shelly hat ja dankeswerterweise den Beacon-Mode in seinen BLE-Geräten korrekt implementiert, so dass irgendwelche Shelly-Gateways nicht erforderlich sind.
-
Cloud Nutzer scheinen die "Denkpausen" der Gateways auch zu beobachten
Wo findet man diese Information? (URLs?)
Was aber letztlich nur bestätigt: Scripte auf den Shellys sind aus meiner Sicht nichts Sinnvolles. Viel zu viel dezentrale Pflege, Fehler usw... Das gilt offenbar auch für die Gateway-Funktion.
-
-
Danke nochmal. Die Firma (in Duisburg) gibt es erst sein 2010- Wie war das denn vorher. Da muss es doch auch schon Hersteller für sowas gegeben haben? Sozusagen ein Altetnativ-Lieferant, so dass man Eigenschaften checken und vergleichen kann und weiss,worauf man achten muss.
Vielleicht in einen Vakuum-Beutel verpacken?
-
Dazu würden mich die Details interessieren. Wie hast Du das konkret umgesetzt? Ich hab ja auch einen RasPi am Start. Den müsste ich dann anderes platzieren, aber daran wird es nicht scheitern. Magst Du das hier verraten oder auf die Stelle im Forum verweisen, wo es eventuell erklärt ist?
Das habe ich hier im Forum nun schon mehrfach geschrieben. Ich suche die Faden mal raus und füge die Verweise dahin hier ein (wenn ich sie rausgesucht habe....)
Ich würde vermuten, dass das Problem im Script liegt (ohne das überprüft zu haben), denn Shellys eigene Software scheint mir eher gut zu sein. Ich sage es ehrlich, du betreibst ja ziemliches Shelly-Bashing. Aber was soll der Shelly-Support auch zu einem Script sagen, das sie nicht selbst erstellt haben. Allerdings ist es schon sehr misslich, dass das sogenannte Bluetooth-Gateway auf Shellys keine eigene mqtt-Schnittstelle zum Weiterleiten an einen mqtt-Broker zur Verfügung stellt. Aber das alles ist mir "Wumpe", weil ich niemals auf eine Cloud oder eine Lösung/Verarbeitung von Daten auf einem IoT-Entgerät setzen würde, wie es alle Shellys für mich sind.
Link1: RE: Beacon Mode aktivieren Stichwort: ble_parser (Beitrag #31 vom 15. Mai 2024)
Link2: RE: Beacon Mode aktivieren Im selben Thread Beitrag #36 vom 9. Juni 2024
Link3: https://github.com/Ernst79/bleparser (kann BTHOME-Daten verarbeiten und per mqtt versenden)
-
Danke.
Und bewahre es nach Anbruch im Kühlschrank auf, sonst trocknet es rasend schnell aus.
Ja, das ist das Problem mit vielen Klebern. Mehrere kleinere Tuben statt einer grossen wären sinnvoller für den Hausgebrauch.
Wie lange ist er dann mit Kühlschranklagerung etwa haltbar?
-
Das wäre für mich der bessere Fall. Bei meinen bisherigen Tests zerfällt das Testfeld in zwei Welten. Entweder bekomme ich im Beacon Mode sehr gleichmäßig alle Daten, dann aber nur eine Zeit lang und danach lange gar nichts mehr, bevor es wieder losgeht. Oder ich bekomme die Daten mit kleinen Pausen, dann aber kontinuierlich.
Das kann ich nicht bestätigen: Hier sendet ein BLU Motion im Beacon Mode seit vielen Wochen absolut zuverlässig und ohne jede Pause (was an den empfangenden, aufsteigenden Packenummern lückenlos *) zu sehen ist) alle 30 Sekunden ein Beacon aus.
Ich würde die Ursache von vermeintlichen Pausen und Lücken ausschliesslich in den Empfängern (Gateways) suchen. Die Beacons werden hiier von einem Raspi empfangen und lokal verarbeitet und als mqtt-Daten weiter gesendet, also unabhängig von Shelly-Gateways und Scripten (dort würde ich auch eventuelle Fehler/Lücken/Pausen/Delays suchen....)
Wie gesagt: der BLU Motion im Beacon Mode arbeiet hier fehlerlos und zusätzlich kann man noch festhalten: Der BLU Motion wurde hier mit 98% Batterie angeliefert und nach 6 Wochen im Beacon Mode ist die Batterie immer noch auf 98%. Ich bescheinige dem BLU Motion im Beacon Mode deshalb eine fehlerlose Leistung.
*) nicht ganz richtig wurde dabei von Shelly die Routine beim Rücksetzen der Paketnummer von 255/256 auf 0/1 implementiert, aber naja...
