Also bei mir funktioniert der Link:
http://<shellyIP>/ota?url=<url zur firmware .zip>
allerdings bekommt man beim Aufruf nicht wirklich eine brauchbare info.
Und die Firmware habe ich nach dem Download noch in .zip umbenannt.
/ota funktioniert übrigens erst ab 0.10.
Ich aktualisiere meine inzwischen mit dem /ota Befehl über einen lokalen Webserver.
Klappt ganz gut.
Die Firmware Updates findet man über:
https://updates.shelly.cloud/update/<Porduct>
also z.B.
Ein kurzes Update,
nach einer Support Anfrage bei Ubiquiti kam raus, dass nur bei den beiden Plus2PM der TX Wert (in der Controller UI) konstant bei 5 Mbps war.
Andere Shellys hatten hier deutlich höhere Werte.
Letztendlich hat wurden die beiden Shellys ersetzt. Die neuen haben das Problem nicht mehr.
Ich bin zwar nicht tichachm, aber trotzdem:
Also, wenn du Wrong Parameter! im Browser siehst, dann läuft das Skript ja bereits erfolgreich.
Der richtige URL ist:
http://<ipvonNAS>/timezone/tzinfo?tz=Europe/Berlin&time=1648363919
wobei bei time= der aktuelle Unix-Timestamp einzutragen ist.
Danke Hiegeix7,
das stimmt, Wrong Parameter! ist ein gutes Zeichen.
Zusätzlich muss man noch bedenken, dass ein Webserver meisten so konfiguriert ist, dass er anhand der Dateiendung entscheidet wie eine Datei interpretiert wird.
Soll bedeuten:
mit tzinfo.php funktioniert es, bei tzinfo (ohne .php) dann nicht mehr.
Damit das auch läuft muss man eine Rewrite Regel erstellen, am Beispiel von Apache:
How to remove .php, .html, .htm extensions with .htaccess (alexcican.com)
Hallo, und wie baut man so etwas nach. Nach was muss man im www suchen? Danke.
Ich hab mir ein schnelles und einfaches php Script gebastelt.
Dieses muss dann unter http://api.shelly.cloud/timezone/tzinfo (ohne .php!) erreichbar sein.
Also ich hatte das Problem auch, da ich ebenfalls die Shellys nicht ins Internet lasse und beim TRV den Zeitplan nutze.
Deshalb habe ich mir diese Seite nachgebaut und den DNS umgebogen:
api.shelly.cloud/timezone/tzinfo?tz=Europe/Berlin&time=1648363919
und im Shelly auf
Daylight saving time offset AUTO (requires internet connection)
gestellt.
Es sieht ganz gut aus, der Shelly frägt regelmäßig ab und merkt sich den Wert.
Das ganze gilt nur für Gen1 Geräte!
Hallo,
meine hatten nach einem Tag das Update geladen.
Also am besten mal das Update über den /ota link anstoßen und einen Tag abwarten (wichtig in der Zeit keinen reboot durchführen).
Dann sollte das Update durchlaufen.
Es gäbe auch noch die Möglichkeit ein Smarthome Template (welches dann die Telefone klingeln lässt) per Fritz Box API auszulösen:
AHA-HTTP-Interface.pdf (avm.de)
(Siehe: applytemplate)
Denke aber nicht dass es sich ohne Script oder zusätzliches System umsetzen lässt.
Hallo Thomas,
"/rpc/Shelly.Update" funktioniert bei mir auch nicht.
Mit "/ota?url=" lassen sich die Shellys aber gut aktualisieren (das gibt es ab Version 0.10).
Hallo, hier ein kurzes Update:
Ich denke es gibt ein Problem im Zusammenhang mit meinem Accesspoint (U6-LR). Das gab es ja auch schon mal mit den Gen 1 Geräten.
Mir ist folgendes aufgefallen.
Läuft der Download der neuen Firmware über den Accesspoint (Unifi U6-LR) ist dieser sehr langsam (~10% pro Stunde).
Verbinde ich den Shelly mit deinem Wifi Accesspoint meines Handys ist das Update in 30s durch.
Plus1, Plus1PM und PlusI4 lassen sich such über U6-LR "schnell" updaten.
Mit der beta5 besteht das Problem weiterhin.
Danke fürs testen, dann ist das wohl ein Sonderfall bei mir.
Uhrzeit ist korrekt ich habe es auch mit Internetzugang versucht.
Hallo Zusammen,
ich versuche gerade meine beiden Shelly Plus2PM auf die aktuelle Firmware 0.10.0-beta5 zu aktualisieren (sie wurden mit 0.10.0-beta3 geliefert).
Weder über das Webinterface noch über "/rpc/shelly.update?url=" oder "/ota?url=" (neu set 0.10.0) scheint es zu funktionieren.
Im Webinterface wird die Meldung "Updating device. Will be back online in about 30-60 seconds." angezeigt, nach 10 Minuten ist aber immer noch beta3 drauf, ein manueller Reboot hat das auch nicht verändert
Mit Aufruf der URL "/rpc/shelly.update?url=" erhalte ich eine Fehlermeldung:
"code": -114,"message": "Resource unavailable: FW stage stable not found!"
Mit Aufruf der URL "/ota?url=" verhält es sich wie im Webinterface.
Ich habe als URL sowohl einen lokalen Web Server, als auch https://updates.shelly.cloud/fw/Plus2PM/0f5…3673e273486389a ausprobiert.
Im Debug Log sieht man auch, dass er anfängt die Firmware zu laden, aber wohl sehr langsam.
Nach ca. 2 Minuten gerät der Download dann ins Stocken:
mgos_ota_core.c:685 2.91% total, fs.img 31744 of 458752
mgos_ota_core.c:685 2.85% total, fs.img 30720 of 458752
mgos_ota_core.c:685 2.78% total, fs.img 29184 of 458752Mit einem Plus1 und Plus1PM gibt es diese Probleme nicht.
Hat sonst noch jemand Probleme mit dem Update, oder ist das bei mir ein Einzelfall?
Hier gibt es den Changelog:
das ist im Prinzip kein Fehler, das Web-Ui stellt keine Werte mit Nachkommastellen dar und es wird großzügig aufgerundet.
Das Problem scheint auch nicht im Webinterface zu liegen.
Die 0.23W sind ja schon falsch.
Hier die Werte die ausgegeben werde:
LEDs an (Helligkeit/Farbe egal) immer 0.23W
LEDs aus immer 0W
Also ich habe das Problem nur mit dem RGBW2.
Firmware 1.11.7
Nach dem Einschalten wird im Webinterface 1W angezeigt.
Über die API sind es 0.23W.
Unabhängig von Farbe und Helligkeit.
Hallo, gibt es hierzu schon etwas neues?
Ich habe das Problem mit der neusten Firmware immer noch.
Hast du bei dir eine neue erstellt und alle WLANs neu angelegt?
Ja, ich habe mich nicht getraut die Seite zu kopieren, nicht dass ich Fehler mitnehme.
Bei mir ist es immer noch so, auch mit dem aktuellen 6.1 er Controller.
Hallo @vistalba
man kann Accesspoints auch auf andere Seiten verschieben,. Das geht in den AP Einstellungen bei Manage Device -> Forget this device -> Move this deviec to...
tichachm Jetzt machst du mich aber neugierig.
Also... du willst mir sagen, eine andere Site löst das Problem? Dann wird da wohl auf der alten Site irgend eine Einstellung sein (oder wurde nicht korrekt entfernt?) welche das verursacht. Oder was hätte sonst so einen Effekt?
Sind damit auch die TCP Retransmissions weg?
Ja, habe bei den Stichproben keine Retransmissions mehr im Log gesehen. (auch meine anderen ESP8266 laufen besser)
Ich bin mir recht sicher das da keine alte Fehlkonfiguration irgendwo rumfliegt.
Das habe ich mir ja zuerst auch gedacht, deshalb habe ich den Controller neu installiert und alle Einstellungen (ohne ein Backup wiederherzustellen) neu gesetzt.
Dann sind die Probleme mit dem langsamen WebInterface und Retransmissions wieder da.