Weiß jemand, ob dies als Gateway fungieren kann? Oder brauche ich noch eines extra? Dann wäre es ein Ausschlusskriterium für mich.
Für mich wäre das kein Ausschlusskriterium. Aber die Geschmäcker sind verschieden...
Es wurde ja am bisherigen Shelly TRV kritisiert, dass kein Frostschutz-Modus im Gerät vorhanden war. Ich gehe davon aus. dass Shelly das nun im Gerät selbst implementiert hat...
Hier gibts Taufrisch ab 3:39 News und auch Bestätigung der technische Limitierungen zu dem TRV BLU...
Überhaupt nicht.... Werde ich mir nicht weiter antun, das Gejammere...
Ich hoffe, dass sich Shelly für diese nicht unheikle mechanische Sache externes Knowhow geholt hat oder sogar eingekauft hat.
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 erforderlichFü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?
Googeln hilft…
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...
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?
