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.
Nach meinen Recherchen bräuchte ich eine HW auf der der MQTT Borker läuft und eine HW die die Daten vom Broker abruft, da er keine Daten sammeln kann.
Das ist Quatsch. Beides kann auf einem System laufen und tut es in der Ragel auch.
Und sehe da keine grossen Unterschiede. Trotzdem würde mich ein Link zu den Beiträgen im "anderen Forum" interessieren.
Nachdem ich wohl mit MQTT nicht weiterkomme
Warum das denn nicht? MQTT kann ohne jedes zusätzliche System verwendet werden und ist perfekt für eine einfache Anwendung. Wenn es einen MQTT-Server auch für Windows gibt (was ich nicht weis, ich nutze MQTT-Server unter Linux, aber für sehr wahrscheinlich halte), dann kann man den MQTT-Server (den sogenannten Broker) im Hintergrund laufen lassen und zusammen mit einem MQTT-Client verwenden und alle Datensätze selbst auswerten. Einfacher und sparsamer geht es nicht. Es ist dabei keinerlei Smarthome-System erforderlich, die Auswertung und Verarbeitung der Daten liegt in der eigenen Hand.
Voraussetzung ist natürlich, dass die Geräte (H&T Gen3) MQTT über WLAN unterstützen, was ich nicht beurteilen kann, ich kenne die Geräte nicht, dazu wissen andere hier mehr.
Hier (im Vorgang auf die entsprechende Dokumentation, die demnächst bei Shelly erscheinen wird) Befehle mit denen man via HTTP über das Gateway Gen3 das BLU TRV abfragen und einstellen kann (ohne Cloud und App):
Abfrage (erste _BluTrvID_: 200):
http://GatewayIP/rpc/BluTrv.GetRemoteStatus?id=_BluTrvID_"
Einstellen (erste _BluTrvID_: 200, _Temp_:4.0 - 30.0):
http://GatewayIP/rpc/BluTrv.Call?id=_BluTrvID_&method=Trv.SetTarget¶ms={"id":0,"target_C":_Temp_}
Damit kann man eine lokale Fenster-Auf/Zu-Routine perfekt realisieren, auch wenn man den Fenster-Zustand woanders (Kamera, Relais usw) her bezieht.
HTH
Jo_Be
Kann man den Bacon Mode per Shelly Script steuern?
Wie ist das gemeint? Was könnte man da steuern wollen? Da muss man doch überhaupt nichts steuern.
Kann man diesen Thread, der inzwischen völlig daneben ist (lesen und gucken ist offenbar nicht die Stärke von jedem), einfach endlich beenden. Danke. Ich jedenfalls warte jetzt erst einmal Erfahrungsberichte ab (und keine Videos, die ein Bild der Webseite zeigen und das als Information verkaufen wollen).
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...
