Beiträge von chrissiboy

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.

    bp4willi : Nach meinen Erfahrungen merkt sich das TRV die Temperaturänderungen während das Fenster geöffnet ist und führt sie augenscheinlich nicht aus. Erst nach dem Schließen des Fensters werden die Änderungen wirksam. Ich denke, das Verhalten ist auch richtig, denn das geöffnete Fenster übersteuert die Solltemperatur bis die Zeit abgelaufen oder das Fenster geschlossen ist. Das Problem an dieser Stelle ist, dass der Fensterzustand nicht beim TRV ankommt. Hättest du das durch Fenster öffnen/schließen korrigieren können, wäre die neue Temperatur auch ohne Reboot verwendet worden.

    Ich überprüfe noch visuell, da ich den Eindruck habe, dass es stabil läuft. Das gilt übrigens auch für die externe Temperatur, die ich von den H&T übernehme und an die TRVs weitergebe. Da könnte man die Error-Variable im Auge behalten, denn wenn die externe Temperatur eine Weile nicht ankommt, gibt es eine Rückmeldung "ext. Temp. missing". Dann hilft meiste ein Reboot des TRV (nicht des Gateways). Aber diese Reboots kann man ja auch aus Symcon starten.

    Also ich habe das auch über Symcon gesteuert - allerdings mache ich das mit SetOverride/ClearOverride und spare mir dadurch die Zwischenspeicherung der Ursprungstemperatur. Das hat auch den Vorteil, dass wenn man diese bei offenem Fenster verändert, beim Schließen des Fensters die geänderte Solltemperatur benutzt wird. Bei neuester FW von Gateway und TRV funktioniert das auch ziemlich stabil.

    Eine deutsche Firma, wie zb. Bosch oder AVM, würde solche unfertigen Sachen nicht auf den Markt werfen.

    Dann kauf dir mal die Thermostate von Bosch und schau dort ins Forum. Die hatte ich nach 2 Heizperioden rausgeworfen, weil sie noch schlechter waren als die BLU TRV und die Forums-Moderatoren sich nur gemeldet haben wenn die Kunden unfreundlich wurden. Verbesserungen an der FW gab es sowieso nicht.

    Ich habe auch AM2302 am AddOn hängen und hier habe ich das Problem, dass die Werte einige Zeit kommen und irgendwann stehen Temperatur und Feuchtigkeit auf Null. Hier hilft dann leider nur noch stromlos machen, denn nach einem Reset wird es nicht besser. Ich kann mich allerdings dunkel daran erinnern, dass die AM230x nicht offiziell als kompatibel gekennzeichnet sind. Da die AM230x jedoch mit einem ordentlichen Gehäuse daherkommen (im Gegensatz zu den kompatiblen DHT22 werde ich weiterhin bei denen bleiben und halt die Shellies kurz stromlos schalten. (Das gilt übrigens sowohl für die alten als auch die neuen AddOns. Vlt. schafft es Shelly eines Tages, auch die AM230x in die Kompatibilitätsliste aufzunehmen. So schwer kann das nicht sein sein.

    Also ich steuere die Ventile grundsätzlich über die API an, z.B. um die Solltemperatur zu setzen, wenn ein Fenster geöffnet wird oder um die externe Temperatur zu setzen. Nachdem die Befehle nur hin- und wieder funktioniert habe, habe ich mir mal parallel das Log des Gateways angeschaut und siehe da, dort wurde als Rückmeldung "NULL" angezeigt, was eigentlich bedeutet, dass das TRV den Befehl erhalten und quittiert hat doch ausgeführt hat das TRV den Befehl nicht.

    Daher sehe ich nur zwei Möglichkeiten: Entweder das TRV meldet ein OK obwohl der Befehl nicht erfolgreich war (dann liegt es an der TRV-FW) oder das Gateway interessiert sich nicht für die Rückmeldung und meldet einfach mal NULL zurück (halte ich eher für unwahrscheinlich). Ich denke, der Fehler liegt eher in der TRV-FW.

    Bei der externen Temperatur kommt es auch ab und zu vor, dass irgendwann die Fehlermeldung "ext. Temp missing" im Gateway angezeigt wird. Da hilft meist ein Reboot des TRV, was auch eher darauf deutet, dass am TRV der Fehler hängt. Ein Reboot des Gateways nützt das meist nichts.

    Also das verstehe ich nicht .. einige haben berichtet, dass die BLU TRVs auf Befehle nicht immer reagieren (kann ich bestätigen) und teilweise sind wohl auch Tickets erstellt worden. Wenn ich jetzt das Log der neuen FW lese, finde ich überhaupt nichts zur Behebung der Probleme. Werden Korrekturen nicht aufgelistet oder interessiert sich bei Shelly niemand dafür ?

    Ich habe das Gefühl, dass der Entwicklungsfokus derzeit nur auf neue Generationen und Features gelegt wird - egal ob die Software dann verlässlich funktioniert oder nicht.

    Ich denke auch, dass für eine Steuerung der Regensensor nicht das leistet, was man erwarten würde. Allerdings sind die 0,2 bzw. 0,4 mm kein Wert pro Stunde sondern die Gesamtmenge, die von der WS 90 auch nicht zurückgesetzt wird. Bezüglich der Regenmenge bin ich mir noch nicht schlüssig, ob das Fantasiewerte sind oder ob das hinkommt. Ich habe parallel noch einen mechanischen Regenmesser, der meist mehr anzeigt, allerdings liegen sie auf Dauer immer wieder recht Nahe beieinander. Das müsste man mal genauer verfolgen, wenn es mal wieder mehrere Tage regnet.

    Also ich habe ein Kabel bei Ama.... gekauft mit der Bezeichnung "FVTLED 5 pcs 2M 2Pin Verlängerungskabel für einfarbige LED Leuchten". Das waren 5 Verlängerungskabel mit jeweils 2m. Zwar hat der Schraubverschluss nicht gepasst aber die PINS stecken vernünftig zusammen und mit einem normalen 12V-Netzeil funktioniert auch die Heizung.

    ...und ja, es ist ein schwarzes und ein rotes Kabel vorhanden, wenn man einen Stecker abschneidet.

    Da der Regenstatus tatsächlich schon durch Nebel-Feuchtigkeit auslöst und sich erst wieder beruhigt, wenn die Nässe auf dem Sensor weg ist (nach dem Regen bleibt das Wasser stundenlang darauf stehen) , wirst über diesen Sensor nicht feststellen, ob es wirklich regnet oder bereits aufgehört hat. Die eingebaute Heizung sorgt auch nur dafür, dass die Windsensoren eisfrei sind - die Regensensoren auf der Oberfläche werden dadurch weder eisfrei gehalten noch getrocknet. Der Regenmengensensor stellt sich nur zurück, wenn man die Reset-Taste drückt. Das bedeutet, wenn du die Regenmenge für einen bestimmten Zeitraum wissen willst, muss das über die APP oder ein Backendsystem, welches die Daten auswerten kann, gelöst werden.

    Also die vielen Klammeraffen sind nicht im Original - ich weiß nicht. wie die da reinkommen. Ich habe die Funktion Code-Block benutzt und dann waren sie auf einmal da :/. Ansonsten ist das ein Original-Script aus Github. Hier ein zweiter Versuch:

    Hallo ihr beiden,

    hat zwar jetzt etwas länger gedauert und ich weiß nicht, ob das die optimalsten Stellen sind, aber es funktioniert. Die Änderungen habe ich markiert.

    Vielen Dank nochmal :) .

    Ich benutze das Gateway Gen 3 - da benötigt man kein Script und kann dann über das WebUI des Gateway zugreifen. Ab da geht es dann per MQTT weiter. Firmwareanpassungen laufen über die BLE Debug-App.

    Die vielen Einstellung, die über die Shelly App funktionieren sollen, gibt es im WebUI nicht. Allerdings hatte ich die Station auch schon in der App und habe trotzdem nur auf die Sensorwerte lesend zugreifen können. Das Einstellen irgendwelcher Offsets war nicht möglich.

    Grundsätzlich finde ich es sowieso nervig, dass es immer mehr Einstellungen und Funktionen nicht mehr im WebUI gibt, sondern dass man immer mehr unterschiedliche Apps benötigt, um alles einstellen zu können. Aber das ist ein anderes Thema.