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.
dann musst einmal ausschalten und wieder ein. Habe das selbe mit der Terrassenbeleuchtung gemacht und dann den Schalter gegen einen Taster getauscht. (mit entsprechender Anpassung des Inputs - von Schalter auf Taster)
Genau, und ich lasse das so mit dem normalen Schalter, der schon vorhanden ist. Man gewöhnt sich schnell daran, das man statt ein, ggf aus und ein schalten muss.
Hinweis: ich bin weder Angesprochener noch Betroffener von diesem Privatstreit. Der spielte sich nur um meinen Beitrag herum ab. 
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.
Und bezüglich deiner anderen Frage: Mutige Shelly Nutzer probieren sowas einfach mal aus
Dazu bin ich zu arm... Man nennt es "bricken" oder so
Der Befehl mit Curl zur Einstellung der Temperatur auf 20 Grad des TRV lautet in Windows-Batch:
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>/rpcIn 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):
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>/rpcHinweise 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):
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>/rpcWindows 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)
unübersichtlich
Stickwort unübersichtlich: Ich kann doch wohl die Zips so umbenennen. wie ich will (wegen der Übersichtlichkeit ), ohne dass das dies den Updater stört, oder?
Immerhin haben die meisten Nutzer Auto-Update an,
Ich gehöre zu denen, die Autoupdate immer und überall (und da meine ich wirklich überall) auf "off" hat...
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.
PS: eventuell sollte man diese Diskussion hier abtrennen und in den passenden Thread verschieben.
Das befürworte ich auch.
Noch einmal nachgefragt: Die heruntergeladenen Zips wirf man so dem Updater vor? Man gibt also diese Zips im Updater via File an und entpackt vorher nichts?
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.
Naja, die Seite hier im Forum... den Link habe ich natürlich im Thread direkt unter meinem Beitrag auch gelesen. Aber mich interessierte ein Link zu einer Liste mit allen Downloads-Links zu allen Firmwaren auf einer offiziellen Shelly Seite. Gibt es den?
Welche hast du?
Bei der 7590 gibt es vermehrt Probleme mit den WLAN Modulen (2,4Ghz)
Es ist doch wünschenswert, bei so etwas die Quellen anzugeben, für Leute, die nicht ständig IT-News für Privatverbraucher lesen, oder?
Zu Beispiel von Günter Born hier: https://www.golem.de/news/fritzbox-…505-196647.html
bzw ein Jahr vorher: https://www.golem.de/news/wlan-rout…405-185377.html
Shelly plugS Gen3 scheint überhaupt ein komisches Stück: lässt sich zum Beispiel auch nicht mit Tasmota flashen, wenn ich es richtig mitbekommen habe....
Der wird hier deshalb vermieden und auf das preiswerte Angebot von Hornbach im Baumarkt gesetzt (solange es das noch gibt): 2 PlusPlugS für 25 Euro (in schwarz *)).
*) Vermutlich wollte die keiner in schwarz, deshalb haut Shelly die über diese Schiene raus.
Der Shelly plus PlugS ist ein schlechtes Beispiel,
? Der hat doch eine Taste. Die möchte ich deaktivieren.
Wenn ich es richtig sehe, ist das also nicht unter Settings, sondern unter dem "Gerät" zu finden? Bei PlusPlugS mit Version 1.6.2 zum Beispiel hier?
-- Hinweis Moderation -- Beitrag und Antworten wurden hierin verschoben ---
dann auf der Update Website geschaut.
Aha, welche Seite ist das denn (Link)?
Problem bei mir ist aber das Gerät. Die 1.6.3 Beta mit Zigbee installiert ebenfalls nicht.
Hier ist das Update auf 1.6.3-beta1 problemlos installiert worden, allerdings nicht per File sondern per OTA Update innerhalb der WebUI des Mini 1PM Gen4.
Ein Update OTA läuft ja nur durch, wenn das Device im lokalen WLAN angemeldet ist und darüber ins Internet kann, und wenn man die WebUI über die im WLAN angezeigte IP aufruft. Vielleicht ist es sinnvoll, den AP-Mode im Device ganz abzuschalten. Und den Umweg über das Zurückgehen von einer Beta auf die ältere Stable zu gehen.
In 1.6.3-beta1 ist der Wechsel zwischen Zigbee und Matter sehr gut und sehr übersichtlich gelöst. Alle Wechsel-Probleme sollten damit gelöst sein.
Es fehlt bei Zigbee in der WebUI weiterhin der Button zum Starten des Pairings.
Es fehlt bei Zigbee weiterhin die Möglichkeit zum ZLL-Mode zu wechseln.
... installieren. https://updates.shelly.cloud/update/S1PMG4 in meinem Fall. ...
Das ist ja ein toller Link. Wo stammt der denn her? Sind die Zips, die man damit herunterladen kann, die vielvermisste Firmware, die man so komplett als Firmware-Datei in den Shellys angeben kann? Oder muss damit erst noch etwas anstellen (entpacken usw)? Fragen über Fragen. Wie lauten die Amntworten, bitte.
Nebenbei, was bedeute die Option "Aktivieren" in der App Ansicht?
Kann man diese Einstellung auch irgendwo in der WebUI finden (ich verwende nich die App und habe sie auch nicht installiert), bzw wie lautet der Befehl via http?
Bei Zigbee gilt: Jedes Zigbee-Gerät ist immer gleichzeitig auch ein Router, der Pakete von anderen Devices weiterleiten kann. Das ist Teil der Zigbee-Spezifization und wird in den Shelly-Geräten wahrscheinlich automatisch von Espressif selbst erledigt, die ja das Zigbee in ihren Devices - die Shelly für ihre Devices verwendet - implementiert haben. (Deshalb eventuell auch ist ZLL nicht implementiert, weil Shelly selbst wenig Ahnung von Zigbee hat)
