Beiträge von hcguersoy

Zitat

Na Fritz!Repeater mit der FW vom TRV 😎

Habe ja extra Zitiert

Die FW v2.2.1 funktioniert aber bei mir

Hmm, erschließt sich mir immer noch nicht ganz aber anyway

Ja, v2.2.1 sah bei mir auch gut aus.

Allerdings hat nun mein DW2 den Löffel abgegeben (bzw. der Reed-Sensor), so dass ich da nicht mehr weitermachen kann

Die netten Leute vom Shelly Support senden mir nun eine BLU DW zu. Mit dem kann ich allerdings nun nichts anfangen, da allem Anschein nach diese nicht ein Plus H&T als BT-Gateway nutzen kann.

Zitat

Ganz schlechte Konstellation 🤪

Vielleicht liest du den Beitrag von hinten nach vorne

Hallo,

vielleicht habe ich es schlicht übersehen, aber den Hinweis, den Du mir gebe wolltest, nicht ergründenden können.
Welchen Kommentar meinst Du in diesem inzwischen sehr langen Thread?

Moin allerseits, ich habe unsere DW2 mal aus der Kiste wieder hervorgekramt da ich diesem Thread entnehmen konnte, dass es doch einige Änderungen gibt.

Ich war ebenfalls mit dieser Unzuverlässigkeit der Status-Übermittlung konfrontiert.

TLDR;

Es hat sich leider nichts geändert.

Mein Setup: es sind zwei TRV in einem Raum verbaut. Beide über eine feste IP im WIFI an einem kabelgebundenem Fritz!repeater.

TRV FW: 20230929-074416/v2.2.0@3699b77a

DW2 FW: 20230913-112843/v1.14.0-gcb84623

Eine direkte Übermittlung des Sensor-Zustandes DW2 -> TRV ist wie gehabt extrem unzuverlässig. Mal kommt das Signal bei keinem TRV an, mal bei dem einen, mal bei dem anderen.

Der Umweg über die Szenen zeigt sich für mich leider ebenfalls als unzuverlässig. Auch dort wird der Status nicht zuverlässig übermittelt. Bei all meinen Versuchen heute hatte ich kein einziges Mal die Situation, dass bei beiden TRV's das entsprechende Flag gesetzt wurde.

Ich den Status auch immer über curl nachgeprüft, da ich der Cloud-App nicht so vertraue.

Um ganz sicher zu gehen, dass ich hier keinen Dreher drin habe: wie habt ihr diese Szenen konfiguriert?

Meine Szenen sehen so aus:

Bedingung:

"Wenn Tür-/Fenstersensor ist offen" (bzw. geschlossen)

Ausführen der Szene: bei jeder Änderung (-> hier war ich mir recht unsicher, da die Dokumentation auch nicht viel hergibt)

Machen:

Senden "Fenster geöffnet" (bzw. geschlossen)

Zeitplan habe ich auf Default gelassen.

Moin allerseits,

just for the records, vielleicht hilft es ja, das Problem etwas weiter einzugrenzen.

Heute morgen hat mich ein TRV (von zwei) ebenfalls mit der Offline-Meldung überrascht.

Mein Setup:

- Fritz!Box 7490 mit 2x Fritz!Repeater 1750 im Mesh (die Repeater sind über Kabel mit der Box verbunden), die TRV verbinden sich meistens mit einem der 1750'er

- Beide TRV haben eine reservierte IP

- Beide haben eine Mac-Adresse die mit 60A4 beginnt

- Beide TRV sind auf der Firmware 20220811-152343/v2.1.8@5afc928c

- Kein MQTT, Cloud enabled

- Externe Temp über eine Shelly Plus H&T (beliefert beide TRV da in einem Raum)

Die Statusabfrage am Gerät meldete St für 'Station Mode'.

Was mir aufgefallen ist: es wurde ebenfalls ein E2 (= Temperature sensor problem) gemeldet.

Ich konnte das Problem durch den Wechsel in den AP-Modus (drücken des Schalters am TRV) und einem Reboot über die REST-API lösen.

Ein Zugriff auf die UI war auch im AP-Modus nicht möglich!

Zitat

Hi!

I need to upvote this! This is too important.

I have six radiators in my living room with six TRVs.

It is not only cumbersome but painful.

Please improve this, Allterco

I'm in a similar situation and even I've only two TRV it's not understandable for me why these key features are missing.
Meanwhile I wrote a small shell script to sync the schedules on my TRV's:

#!/bin/bash

# Configures the timer for a set of TRV's

# TRV IP addresses
# add your IP's here
trv_ips=(
  192.168.178.10
  192.168.178.11
)

shedule_profile_name="living-v1"
shedule_profile=1
shedule_rules="0550-01234-19,2200-01236-18,0800-01234-19,1230-01234-20,0715-5-21,2330-54-18,0730-6-21"

timeout=2

# Check if httpie (https://httpie.io) is installed
if ! command -v http &> /dev/null
then
    echo "http could not be found"
    echo "Please install from httpie.io"
    exit
fi

for trv in "${trv_ips[@]}"
do
  echo "Setting up TRV at ${trv}"
  for retry in {0..2}; do
    echo "Retry: ${retry}"
    http --timeout=${timeout} --check-status \
      http://"${trv}"/settings/thermostats/0 \
      schedule_profile==${shedule_profile} \
      schedule_profile_name==${shedule_profile_name} \
      schedule_rules==${shedule_rules}
    last_exit=$?
    case $last_exit in
        0)
          echo "OK!"
          break
          ;;
        2) echo 'Request timed out!' ;;
        3) echo 'Unexpected HTTP 3xx Redirection!' ;;
        4) echo 'HTTP 4xx Client Error!' ;;
        5) echo 'HTTP 5xx Server Error!' ;;
        6) echo 'Exceeded --max-redirects=<n> redirects!' ;;
        *) echo "Other Error: ${last_exit}" ;;
    esac
  done
done
echo "Finished"

Side note: there is currently a bug in the TRV firmware (I use v2.1.8): even then you program a decimal temperature value, e.g. 19.5, it only takes the integer part (in this case 19).

Hallo, soweit ich es sehen kann, kannst Du 5 Heizpläne speichern.

Was leider nicht geht (oder ich war zu doof diese Funktionalität zu finden) ist, für eine Gruppe von TRV's gemeinsame Heizpläne zu hinterlegen.

Und da es etwas mühselig ist, diese über die UI per Hand anzulegen habe ich auch einen 'Oneliner', mit dem ich die Heizpläne an die TRV's vom Rechner aus senden kann.

Hallo,

ich habe keine Ahnung was dieses "M5Stack Core2" so alles kann, aber wenn Du damit auf eine URL zugreifen kannst und dann eine JSON (z.B. jq) ausfiltern kannst, könntest Du z.B. über den /thermostats/0-Endpoint auf die aktuelle Temperatur zugreifen.

Und dann mit dem Endpoint /settings/thermostats/0 die Zieltemperatur setzen.

Die TRV-API findest Du hier beschrieben: https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv

Dieses Verhalten ist mir auch bereits aufgefallen... ich finde sowohl diese "Trägheit" bei der Anzeige der aktuellen Temperatur als auch den Melde-Schwellenwert sehr verbesserungswürdig.
Ich habe auch den Luftfeuchtigkeits-Schwellenwert auf das Minimum gesetzt in der Hoffnung, dass auch dann das Senden der Temperaturwerte an die TRV's getigert wird.

Hat jemand diesbezüglich auch schon Erfahrungen mit MQTT gesammelt? Werden die Daten auch so selten gesendet?

Ich überlege, mir mit einem Raspi etwas zurecht zu basteln (wenn ich mal an eine ohne Wucherpreise zahlen zu müssen dran käme). Da habe ich aktuell "Home Assistant" im Auge, alternativ etwas kleines selbst gebautes.

Ich habe eben mal ein Ticket aufgemacht. Die Beobachtungen kann ich bestätigen, dass die TRV's nicht immer sofort reagieren und anscheinend ein zwei Sekunden benötigen, um aufzuwachen. Ein Ausweg wäre ein längeres (oder sogar konfigurierbares) Timeout in der DW2 oder IMHO besser, wenn dort ein retry-Pattern implementiert wäre und wir die Anzahl der Retries konfigurieren könnte.

Zitat

I've a combination of a TRV and a DW2 but observed that the TRV doesn't react reliable to the according REST calls on the API.

I checked that the DW2 tries immediately to access the configured URL (started a local http client on my desktop) in a correct way.

And I've observed that I run often into a timeout then I try to access the TRV from my desktop, e.g. using httpi:

Code

http --timeout=1 http://192.168.178.22/window\?state\=close
http: error: Request timed out (1.0s).

So, please give us the possibility to configure the timeout on the devices, especially on the DW2.

BTW, I've not found any documentation how long the timeout is currently in DW2 while calling an action URL.

Zitat

Ich würde mich so sehr freuen, wenn es doch noch einen Tipp oder Trick gibt, wie die Kommunikation des DW2 mit dem TRV verbessert werden kann.

Ich schlage mich heute auch schon etwas mit dem Thema herum und bin bei der Recherche nun auch über Deinen Thread gestolpert.

Bei mir ein ähnliches Verhalten: mal wird ein Öffnen registriert, aber das Schließen dann doch nicht mehr. Ziemlich unzuverlässig.

Aber es gibt die Möglichkeit, dass man mehrere Actions eintragen kann. Ich habe nun die URL's zweifach eingetragen. Sprich, zweimal die gleiche URL für jede "Open-Action", und zweimal für die "Close"-Action. Die die API-Calls idempotent sind, sollte dies kein Problem darstellen.

Nun habe ich etwas danach herum getestet und es scheint nun halbwegs zuverlässig zu funktionieren.

Dürfte allerdings etwas zu Lasten des Batterie-Verbrauches gehen.

Der Augenschein trügt manchmal und in diesem Fall war ich wohl zu hoffnungsvoll.

Nach einigen Minuten der Ruhe und erneutem Herumprobieren kommen die Signale wieder nicht beim TRV an.

Und was mir auch aufgefallen ist: manchmal bleibt die Temperatur auf 8 (value_op) obwohl ein Close registriert wird.

Kleiner Hinweis: in der App bzw. Cloud-App konnte ich die Mehrfach-Einträge nicht vornehmen, nur direkt auf der DW2. Also einmal kurz den Taster auslösen, damit man sauber auf die Oberfläche kommt.

Zitat

und was falsches wie 10.90.90.90 eintragen. Also vorerst!

Hmm, vielleicht dann doch den lokalen DNS vom Router eintragen? Oder den Google-DNS? (8.8.8.8)

Zitat

http://0.0.0.0/ota?url=http:/…RV-01_build.gbl

0.0.0.0 mit der IP austauschen

Das Eingeben, dann funktioniert das Update.

Danke. Als Shelly-Neuling hat dieser Aufruf mir den Tag gerettet!

BTW, wo bitte findet man solche Information bzw. wo findet ihre welche URL, welche Endpoints usw.? Steht alles in den Entwickler-Doc's drin?