Diese beiden Dinge kann ich ausschließen. Es gibt keine zweite Wärmequelle (höchstens tagsüber durch Sonneneinstrahlung) und wenn das Ventil auf 0 steht, ist der Heizkörper kalt. Bei diesem Punkt habe ich aber noch etwas festgestellt, was wahrscheinlich auf einen User-Error zurückzuführen wäre.
Die beiden ersten Punkte wären daher für mich noch offen.
Hm .. das mit den 8 Sekunden kann ich leider nicht bestätigen. Beim ersten Öffnen heute morgen, änderte sich der Neigungswinkel erst nach 30 Sekunden. Da war das Tor schon 10 Sekunden offen. Schlafen die BLU-Geräte auch ohne ECO-Modus ? Danach ging es etwas schneller, aber auch da kam es vor, dass erst 20 Sekunden nachdem das das Tor bewegt wurde, eine erste Meldung kam. Immer TOP funktioniert es beim Schließen.
Hallo,
ich möchte die Stellung meines Garagentor-Schwingtors über einen Shelly BLU D/W kontrollieren. Leider wird der Neigungswinkel doch recht zufällig während der Bewegung gemeldet und
wenn das Tor offen ist, kann es schon gut eine Minute dauern, bis der End-Neigungswinkel gemeldet wird. Gibt es eine Möglichkeit (z.B. per Script), den Status häufiger/schneller zu melden ?
Der Beacon Mode ist eingeschaltet aber leider nicht hilfreich. Zumal der Neigungswinkel dann auch nicht zyklisch gemeldet wird.
Grüße Frank
Hallo,
ich habe mich mit 10 Shelly BLU TRV eingedeckt und sie über MQTT in mein Symcon-System eingebunden. Das funktioniert soweit auch ganz gut, aber bezüglich der Steuerung hätte ich noch ein paar Fragen:
Vielleicht kann einer der Insider etwas dazu schreiben - vielen Dank.
Grüße Frank
In der Hoffnung, dass es irgendwie eine aktualisierte Statusanzeige gibt, habe ich ein Ventil mal aufgemacht und wieder geschlossen, aber der Button-Sensor hatte keinen Ausschlag obwohl nach dem Schließen sofort eine Kalibrierung ausgelöst wurde. Der Taster hat zwar bewirkt was er soll, aber eine Zuordnung zum Button-Sensor besteht wohl nicht.
OK, vielen Dank .. hat also für den normalen Betrieb keine Bedeutung.
Hallo,
ich habe jetzt sehr viel in der Doku nachgeschlagen und aus probiert, aber ich habe noch nicht rausgefunden, was der Sensor "Button" im TRV bedeutet und was man damit anfangen kann. Im Gegensatz zu den D/W und H&T ist das kein Sensor, den man hinzufügen kann. Kennt jemand die Funktion dieses Sensors ?
So, nach weiterer Analyse von /rpc/BTHomeDevice.GetKnownObjects habe ich festgestellt, das obj_id in Zusammenhang mit idx verrät, um welchen Sensor es sich handelt:
ID=1 : Batterie
ID=58: Button
ID=69: Temperatur => idx=0: Solltemperatur, idx=1: Temperatur intern, idx=2: Temperatur extern
Vielleicht helfen folgende beide Möglichkeiten: Sicherung der Programmierung
Habe zwar noch nicht alles ausprobiert, aber scheint die richtige Richtung zu sein - danke
jo, das macht es aber nicht besser ..... die Situation ist durch die Gateways deutlich komplexer geworden und selbst wenn man sich alles schön dokumentiert, sitzt man an einer Wiederherstellung eines Gateways sicher eine längere Zeit.
Schlägt man so eine Verbesserung beim Support vor oder gibt es da einen anderen Kontakt ?
Ich könnte mir vorstellen, dass man das auch ein Script (oder auch zwei) lösen kann, sofern man in der Script-Erstellung erfahren ist.
Hallo zusammen,
ich habe jetzt schon eine Weile herumgesucht, aber nichts gefunden... gibt es eine Möglichkeit, die Konfiguration eines BLU-Gateways incl. der Informationen der angeschlossenen Devices und der evtl. vorhandenen Scripte und Aktionen zu sichern und im Notfall wieder auf ein Gateway zurückzuspielen ?
Bei einem Gateway mit 3-4 TRV's ist das ziemlich aufwändig, zumal wenn man auch noch zusätzliche Variablen und abhängige DW's oder HT's eingebunden hat.
Grüße Frank
OK, danke .. dann werde ich das mal austesten 
Hierzu hätte ich dann doch noch eine Frage (oder auch zwei) ...
Gibt es zu dieser Begrenzung eine offizielle Aussage oder Beschreibung ?
Gilt das nur für TRV's oder ist die Anzahl der Geräte am Gateway grundsätzlich auf 5 beschränkt ?
Ich denke, du musst die Doppelpunkte nach dem Hochkomma schreiben
Also ich hatte das auch 2-3 Mal und musste den Stick rausziehen. Aber seitdem ist die Verbindung stabil. Wenn sich das bei dir nicht bessert, würde ich den Stick zurückschicken.
So, nachdem ein Neustart zunächst keine Besserung brachte, habe ich heute festgestellt, dass nach erneutem Neustart die Funktion jetzt klappt.... warum auch immer
was mir an deinem Bild auffällt ist die Duration Time....wieso stehen da 35 Millionen Minuten drinnen?
Keine Ahnung - war schon so dringestanden. Daran habe ich nichts geändert.
Hat noch jemand eine Idee, was ich evtl. falsch gemacht habe oder liegt hier ein SW-Problem vor ?
Ich benutze die App nicht, aber lt. Web-GUI ist er da :
ja, als eigene Komponente habe ich ihn, aber müsste er nicht als Sensor (so wie z.B. ext. Temperatur) in der Sensorenliste des TRV stehen ? Logisch gesehen ist es ja nichts anderes als ein externer Sensor ..
Beim Shelly.GetComponents steht der Sensor auch drin:
{
"key": "blutrv:200",
"status": {
"id": 200,
"target_C": 21,
"current_C": 21.2,
"pos": 0,
"rssi": -45,
"battery": 100,
"packet_id": 240,
"last_updated_ts": 1740663152,
"paired": true,
"rpc": true,
"rsv": 11
},
"config": {
"id": 200,
"addr": "28:db:a7:b5:d2:b0",
"name": "Patrick 200",
"key": null,
"trv": "bthomedevice:200",
"temp_sensors": [],
"dw_sensors": [
"bthomesensor:212"
],
"override_delay": 1,
"meta": {
}
},
"attrs": {
"flags": 17,
"model_id": 8
}
},beim BTHomeDevice.GetKnownObjects wiederum nicht mehr ...
{
"id": 200,
"objects": [
{
"obj_id": 84,
"idx": 0,
"component": null
},
{
"obj_id": 1,
"idx": 0,
"component": "bthomesensor:200"
},
{
"obj_id": 58,
"idx": 0,
"component": "bthomesensor:201"
},
{
"obj_id": 69,
"idx": 0,
"component": "bthomesensor:202"
},
{
"obj_id": 69,
"idx": 1,
"component": "bthomesensor:203"
},
{
"obj_id": 69,
"idx": 2,
"component": "bthomesensor:204"
}
]
}Das liegt aber wohl daran, dass der Sensor wohl dem blutrv zugeordnet wird aber nicht der HomeDevice. Irgendwie sind die Strukturen noch nicht ganz sauber, aber das gehört nicht zu dem Thema