Beiträge von Jo_Be

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.

    Was passiert, wenn nicht [OK] sondern stattdessen [Abbrechen] gedrückt wird? Nach meinem Verständnis würde das bedeuten, dass nichts verworfen und es noch einmal mit den gespeicherten Einstellungen versucht wird.

    Das wäre aus meiner (Entwickler-)Sicht logisch (muss aber nicht der Shelly-Entwickler-Denke entsprechen):

    [OK] bedeutet dann also etwas das: Ja, ok, stimmt, WLAN gibt es so nicht mehr und muss jetzt neu eingegeben werden. Also werden die nicht erfolgreichen Einstellungen gelöscht (was sehr gut ist).

    [Abbrechen] bedeutet dann: Bitte zurück in die Warteschleife und versuch es noch einmal mit den Einstellungen, die gespeichert sind

    Dieser Dialog erscheint scheinbar erst nach längeren Connect-Versuchen und soll zwei Dinge bewirken:

    - den User auf ein (andauerndes) Problem aufmerksam machen

    - verhindern, dass das WD es ewig weiter versucht, sich zu verbinden.

    Ich nutze IOBroker nicht. Deshalb kann ich zur Kombination vom Ventil und IOBroker nichts sagen. Aber - wenn ich mich richtig erinnere - ist das Einstellen der Solltemperatur von extern hier schon besprochen und beschrieben worden.

    Es geht zum Beispiel so:

    curl -X POST -d '{"id":1,"method":"BluTrv.Call","params":{"id":200,"method":"TRV.SetTarget","params":{"id":0,"target_C":26.0}}}' http://IP-Gateway3/rpc

    26.0 ist hier die Solltemperatur
    "id":200 ist die ID des Ventils (die ID war, wenn ich mich richtig erinnere, Teil der Fragen an mich, nachdem ich dies hier veröffentlich hatte)
    IP-Gateway3 hier die IP des Gateway3 eintragen

    Was würde ich benötigen, um die Daten über InfluxDB oder Grafana auszulesen?
    Ist da ein andere Lux Sensor sinnvoller?

    Unter Linux: ... installieren von influxdb und grafana ggf noch mosquitto
    und natürlich (auch mit HA) einen Empfänger für die Beacons, der die dann weiterleitet/verarbeitet.

    HA ist was für Anfänger. Die eigene Verarbeitung via influxdb und Grafana ist natürlich viel anspruchsvoller und flexibler.

    Bei mosquitto (In /etc/mosquitto/mosquitto_conf) im zweiten Broker, der die Daten auch haben will:

    connection beliebiger_(sprechender)_name
    address IP_des_ersten_Brokers_der_die_Daten_vom_Shelly_erhaelt:1883
    topic # in

    Fertig! *)

    *) Also drei Zeilen: connection NAME /address IP:PORT/topic XYZ in (# = alle Topics, in = nur Empfang)

    Dieser zweite Broker meldet sich also dann bei ersten Broker an und sagt: Jip mir allet, was du bekommst, und der erste Broker macht dann - freundlicherweise - worum er gebeten wurde....

    Das kamm man bei Smarthome-Systemen garantiert auch in irgendeiner Conf (ggf. händisch) eintragen....

    Nennt sich "Bridge" siehe ua: https://mosquitto.org/man/mosquitto-conf-5.html

    Das WLAN wird nicht verfügbar sein und da bleibt nur noch ausbauen, Reset oder zurück auf Matter per Taster (falls das noch geht). Gefällt mir ehrlich gesagt auch nicht da die Vergangenheit gezeigt hat dass man immer wieder einen Zugriff braucht.

    Das ist einfach ein Falschaussage. WLAN funtioniert nämilch problemlos. Der Shelly ist also problemlos im lokalen Netz mit seiner IP erreichbar, die er ím lokalen Netz hat. Nur als AP ist er nicht mehr erreichbar, was aber verschmerzbar ist.

    Der Befehl mit Curl zur Einstellung der Temperatur auf 20 Grad des TRV lautet in Windows-Batch:

    Code
      curl -X POST -d "{\"id\":1,\"method\":\"BluTrv.Call\",\"params\":{\"id\":200,\"method\":\"TRV.SetTarget\",\"params\":{\"id\":0,\"target_C\":20.0}}}" http://<IP-TRV-Gateway>/rpc

    In einem script ist es etwas einfacher, weil die \ (als Escape für die ") wegfallen (die müssen in der Batch sein, weil der Befehl in ".." stehen muss, statt bequem in '...' wie im linux script):

    Code
    curl -X POST -d '{"id":1,"method":"BluTrv.Call","params":{"id":200,"method":"TRV.SetTarget","params":{"id":0,"target_C":20.0}}}' http://<IP-TRV-Gateway>/rpc

    Hinweise für beide Varienten: ggf. muss die id 200 angepasst werden. target_C kann zwischen 4.0 und - ich glaube - 30.0 eingestellt werden (ich selbst benutze 4.0 und zb.: 28.0 nach der Fensterstatus-Erkennung, die Shelly-unabhängig abläuft)

    Die Abfrage der Einstellung sollte erst etwas später erfolgen (wg der motorischen Verstellung des TRV):

    Code
    batch :curl -X POST -d "{\"id\":1,\"method\":\"BluTrv.GetRemoteStatus\",\"params\":{\"id\":200}}" http://<IP-TRV-Gateway>/rpc
    script:curl -X POST -d '{"id":1,"method":"BluTrv.GetRemoteStatus","params":{"id":200}}' http://<IP-TRV-Gateway>/rpc

    Windows hat - glaube ich - inzwischen curl vorinstalliert, unter den meisten Distros muss man curl erst installieren.

    Bei der Status-Abfrage wird jede Menge zurückgeliefert, während der eigentliche Einstell-Request bei Erfolg nur kurz mit einem "result":null *) quittiert wird.

    *) Die Shelly-Entwickler wissen immer wieder zu überraschen: Wobei mir nicht klar ist, ob das 'null' ein Irrtum in der Implementierung ist, oder Absicht, oder etwas Vergessenes, oder die ernsthafte Antwort (im Sinne von: es ist nix falsch an deinem Request, lieber User)

    Ja, genau, direkt das Zip.

    Ich verstehe nun besser warum Shelly nicht anbietet, dass man die Firmware herunterladen und selbst installieren kann. Wenn jemand in den Zips herumfummelt, kann es für den Support unübersichtlich werden. AVM hat ja irgendwann auch versucht, die Sache dicht zu machen... Und die wenigen, die die Links zum Download kennen, werden wohl genug Übersicht haben, zu wissen was sie tun.

    Wenn du den verlinkten Beitrag nochmal durchliest, wird hoffentlich auch deutlich, warum Shelly das nicht anbietet.

    Nö, das wird eigentlich nicht deutlich in dem Thread. Was ich in dem Thread unter anderem finde ist

    "Im Grunde ist das was ihr hier postet kein Problem. Wird ja alles offiziell von den Shelly Servern gezogen"

    "So wie ich das verstanden habe, ist alles ok, was auf die jeweils aktuelle Firmware zeigt"

    "Direkte Links sind nicht gern gesehen, wobei diese bei alter Firmware sowieso ins Leere laufen"

    "...Links zu 1.6.0 zu. Hier möchte Shelly selber steuern, wer die bekommt"

    Das "Warum" finde ich da nicht. Nur beim letzten Punkt wird ein Grund angegeben.