Beiträge von Rexton

Ich vermute von dem Problem auch betroffen zu sein. Ich habe seit Anfang 2021 15x Shelly 2.5 als Rollladensteuerungen im Einsatz und mittlerweile starten sich 7 Stück von denen regelmäßig neu. Einige schaffen 6 Stunden Uptime, andere keine Stunde mehr.

Durch die Häufigkeit der Neustarts hatte ich schon die ersten spürbaren Ausfälle und Befehle zum Hoch- oder Herunterfahren konnten nicht ausgeführt werden. Da ich noch keinen Shelly aus der Dose ausgebaut und geöffnet habe, weiß ich nicht welche Elkos verbaut sind.

Was würdet ihr machen? Macht es Sinn nach der langen Zeit den Support von Allterco zu kontaktieren? Reparieren traue ich mir nicht zu. Oder neue Shelly Plus 2PM kaufen und nach und nach ersetzen und hoffen, dass das Problem mit den neuen nicht mehr auftritt?

Hier findest du noch die URL der letzten stabilen und Beta Firmware am Beispiel des PlusPlugS: https://updates.shelly.cloud/update/PlusPlugS

Mich wundert aber, dass dort noch die 0.14.4 als stabile Version angezeigt wird.

Ich habe seit 2 Jahren 16x 2.5 Shellys im Haus und seitdem es möglich ist, sind alle im Eco-Modus. Bei mir laufen seit ein paar Tagen alle mit der neuen 1.13.0 Firmware und ich habe eben nachgeschaut: alle Temperaturen liegen zwischen 42 und 48 Grad. Bei mir tritt das Problem also nicht auf.

Vielleicht interessant: meine Shellys sind per MQTT mit ioBroker verbunden (an der Polling-Rate habe ich nichts angepasst) und CoIoT ist deaktiviert. Ansonsten ist die LED abgeschaltet, aber die sollte eigentlich keine Wärme erzeugen.

Wo kann man die Changelogs zu dem Update denn finden?

Ich hatte das gleiche Problem mit 0.14.0 auf einem Plus i4 in Verbindung mit ioBroker: nach ein paar Tastenbetätigungen wurde als Status des Buttons nur noch ein Fehler gemeldet, etwas in der Art "exceeded rate limit" oder so ähnlich. Zurück auf 0.13.0 war das Problem nicht da. Mit dem Update auf 0.14.1 kommt die Fehlermeldung nach ca. 10-15 mal drücken, was in der Praxis nicht vorkommen sollte.

Dennoch frage ich mich nach dem Sinn dieser Beschränkung? Auf zu häufige Requests von "außen" irgendwann nicht mehr zu reagieren, halte ich für Shellys mit Relais auch für sinnvoll, um den Shelly und dessen Relais zu schützen. Aber wenn wenn jemand den Button eines i4 übermäßig häufig drückt?

Weiß jemand mehr zu dem Hintergrund? Oder habe ich bzgl. dieses Schutzes etwas falsch verstanden? Interessiert mich einfach ...

Evtl. für den einen oder anderen interessant:

Über den klassischen Endpoint "/ota" kann ich auf 0.13.0 upgraden als auch wieder zurück zu 0.12.0 downgraden. Das Wechseln der Firmware braucht im Vergleich zur 1. Generation deutlich länger - nicht nur wenige Sekunden, sondern 1-2 Minuten bevor sich der Shelly mit der neuen Firmware meldet. Man darf also nicht ungeduldig sein.

"Shelly.Update" hat bei mir in keine der beiden Richtungen funktioniert - entweder habe ich etwas falsch verstanden oder gemacht oder es geht nicht.

Mir persönlich reicht die OTA-Lösung und ich bin froh die 2. Generation auch in mein komplett abgetrenntes VLAN integrieren zu können.

Zitat

gw "192.168.0.99"

Ich bin kein Netzwerk-Experte, aber mir kommt es komisch vor und deswegen die Frage: darf ein Gateway eine andere als die erste IP-Adresse in einem Subnetz haben? In diesem Fall bei der Maske 255.255.255.0 müsste das doch 192.168.0.1 sein? Wieso gibt sich die Fritzbox (ich vermute als Router) die "99"? Oder ist der Aufbau des Netzwerks hier doch anders?

Hallo @dekat win,

ich finde es immer toll, wenn Software Entwicklungen (egal ob als Hobby oder professionell) einen Weg in die Öffentlichkeit finden und mit anderen zur gemeinsamen Nutzung und/oder Verbesserung geteilt werden. Mir ist aufgefallen, dass dies nicht dein erstes Skript ist und wahrscheinlich auch nicht dein letztes gewesen sein wird.

Damit dein Skript anderen Leuten helfen kann (entweder in Teilen oder ganz), ist Lesbarkeit und Wartbarkeit sehr wichtig. Schlecht verständlicher Code wird ganz schnell ignoriert und es wird sich nach etwas anderem umgesehen, obwohl es vielleicht die perfekte Lösung zu einem Problem ist.

Es gibt viele Wege und Arten Code zu formatieren und genauso viele Ansichten, was "richtig" ist - deswegen möchte ich eine solche Diskussion nicht beginnen. Ich würde dir aber gerne einen Denk-Anstoß geben, um selbst festzustellen, was und wieviel es nicht nur anderen, sondern auch dir selbst bringt, wenn du dir den Code in ein paar Wochen oder Jahren noch mal ansiehst (oder ansehen musst, weil ein Fehler drin steckt).

Es gibt Anweisungen, die lassen sich nicht in die empfohlenen Maximallänge von 70-80 Zeichen packen - dann sind auch 100 Zeichen mal ok. Aber die folgende Zeile lässt sich mehrmals umbrechen und dadurch viel besser lesbar machen.

...
if(Shelly.getComponentConfig("switch:"+JSON.stringify(cID)).initial_state === "match_input"){Shelly.call("Switch.SetConfig",{id: cID,config: {initial_state: "restore_last"}});print("Invalid inital_state!, changed switch:id", cID, " inital_state to restore_last");}
...

Hier mal eine von mir empfohlene Formatierung - natürlich lassen sich noch mehr oder weniger Umbrüche einbauen, aber durch die folgende Formatierung wird auf einen Blick klar, dass wir eine Bedingung mit zwei Anweisungen haben und sehen auch schnell, um welche Funktionsaufrufe es sich bei den beiden Anweisungen handelt.

...
if(Shelly.getComponentConfig("switch:"+JSON.stringify(cID)).initial_state === "match_input"){
    Shelly.call(
        "Switch.SetConfig",
        {
            id: cID,
            config: {initial_state: "restore_last"}
        }
    );
    print("Invalid inital_state!, changed switch:id", cID, " inital_state to restore_last");
}
...

Der Nachteil ist, dass man im Endeffekt mehr scrollen muss. Aber die Vorteile - vor allem bei der Fehlersuche und für jemanden, der den Code zum ersten Mal sieht - sollten überwiegen.

Ich persönlich gehe für die Lesbarkeit sogar noch einen Schritt weiter und füge mehr Leerzeichen ein, um "Blöcke" schneller zu erkennen. Ist aber Geschmackssache und bei uns in der Abteilung hat sich das vor ein paar Jahren durchgesetzt.

...
if ( Shelly.getComponentConfig( "switch:" + JSON.stringify( cID ) ).initial_state === "match_input" ) {
...

Abgesehen davon noch ein paar weitere Anmerkungen:

if (event.info.state === true) { ...

ist das gleiche wie

if (event.info.state) { ...

Und:

if (status === !invDelayModus) { ...

schreibt man besser

if (status !== invDelayModus) { ...

Ich möchte dir in keinem Fall vorschreiben, wie du den von dir selbst geschriebenen und veröffentlichten Code darzustellen hast. Aber wenn man mehr und mehr Code schreibt und auch mal verbessern oder korrigieren muss, kann das viel Zeit und Kopfzerbrechen sparen.

Zitat

die ganzen Kombis kann sich doch eh keine Sau merken Intuitive Scripte, die auf Ereignisse oder Zustände angepasst sind, sind da wesentlich effektiver

Da hast du vollkommen Recht und ich möchte mir auch nicht neun oder mehr Kombinationen merken! Ich dachte durch den Smiley "" wird die Ironie in meiner Aussage ausreichend deutlich.

Danke für die Info, das gefällt mir!

Jetzt muss Allterco nur noch die Kombinationen aus Kurz- und Lange-Drücken als I/O-Aktionen ermöglichen und meine Frau dreht mir den Hals um, wenn ihr ihr erkläre, dass man zuhause nun alles mit nur einer Taste steuern kann!

Weißt du, dass das Zertifikat überprüft wird? Oder ignorieren es die Shellys einfach?

Ich habe nur irgendwann im Laufe des letzten Jahres festgestellt, dass sich die Download-URL für die Shellys der ersten Generation geändert hat und das Zertifikat nicht mehr von offizieller Stelle kommt.

Ich habe meinen Plus i4 mittlerweile erhalten und warte jetzt auf eine neue Firmware, damit ich Update und Downgrade austesten kann.

In der Dokumentation finde ich mittlerweile zwei Möglichkeiten eine beliebige Firmware einzuspielen.

1. Klassisch: "Endpoint: /ota" (https://shelly-api-docs.shelly.cloud/gen2/Component…tp-endpoint-ota)
2. Nur Gen 2: "Shelly.Update" (https://shelly-api-docs.shelly.cloud/gen2/Component…ly#shellyupdate)

Bin gespannt, ob und wie gut beide Wege funktionieren.

Ich habe die aktuelle Firmware für den Plug S und 1PM verglichen: sie sind sich zwar sehr ähnlich und der Name für den Plug S hat mich zuerst auch irritiert, aber es handelt sich nicht um den gleichen Download.

Als erstes gibt es einen Unterschied im Build-Timestamp, wie man schon im Namen der zip-Datei erkennen kann. Des Weiteren passen die Namen im Manifest der Firmware und die der bin-Dateien zu dem jeweiligen Gerät. Deswegen gehe ich nur davon aus, dass der Name des Downloads sehr, sehr unglücklich gewählt wurde, evtl. ist es ein Versehen.

Dort findest du die URL: https://updates.shelly.cloud/update/Plus1

Das Zertifikat des Webservers scheint irgendwie kaputt zu sein, zeigt mein Firefox zumindest an.

Ja, das ist der GET Request, der funktioniert per Browser oder curl. Aber die dokumentierten POST Requests liefern immer die genannte Fehlermeldung.

Hallo,

ich versuche per curl und POST Requests beispielhaft den Namen meines Plus i4 zu ändern. Ich kann dies erfolgeich per GET machen, aber die in der Doku gezeigten POST Befehle (https://shelly-api-docs.shelly.cloud/gen2/Component…tconfig-example) funktionieren bei mir nicht.

Aufgefallen ist mir als erstes, dass sogar ein einfaches "GetConfig" nicht per POST funktioniert. Ich bekomme als Antwort "Invalid request".

curl -X POST -d '{"id":1,"method":"Sys.GetConfig"}' http://10.2.2.81/rpc

Invalid request

Auch andere Befehle funktionieren nicht und liefern das gleiche "Invalid request". Mache ich etwas falsch oder ist das ein Fehler in der aktuellen Firmware (20221206-142532/0.12.0-gafc2404)?

Super, danke. Für einen Shelly Plus i4 habe ich diese URL gefunden: https://updates.shelly.cloud/update/PlusI4

Jetzt wäre noch interessant zu wissen, ob über das UI auch ein Downgrade möglich ist.

edit: Ich habe mir jetzt einen Plus i4 zusammen mit einem 4er Wall Switch und Rahmen bestellt und werde es austesten, wenn es das nächste Firmware-Update gibt. Wenn es aber schon jemand weiß oder ausprobieren möchte, würde ich mich trotzdem darüber freuen.

Danke, ich selbst habe noch keinen Shelly Gen 2 und keine Möglichkeit mir das UI anzusehen, deswegen frage ich.

Woher hast du denn die URL bzw. den Hash?

Zitat

nur bei den Gen2 Devices gibt es jetzt gerade mal seit den zwei letzten Firmware Updates die Möglichkeit einen Link zu einer Firmware anzugeben

Das klingt sehr vielversprechend. Wo hast du diese Möglichkeit entdeckt? Im UI und/oder per API Aufruf? Ich habe im API noch nichts dazu gesehen.

Das Speichern der letzten Firmware-Versionen meiner Shellys mache ich ja für mich selbst, das ist für mich kein Thema.

Auch wenn Deaktivieren und Aktivieren der Firewall keinen regulären Prozess darstellen sollte, wäre das eine Möglichkeit, ja. Aber es ist und bleibt ein One-Way-Ticket und wenn ich das höre, sträuben sich bei mir die Haare:

Es gab bei mir in den letzten zwei Jahren zwei Mal den Fall, dass nach einem Shelly Update die Shellys nicht mehr so funktionierten, wie sie sollten. In beiden Fällen war nicht Allterco Schuld, aber der Rollback auf die letzte Version war kurzfristig die einzige Möglichkeit die Shellys wieder korrekt funktionieren zu lassen.

Bei ersten Mal war ich durch ein geändertes Verhalten beim Melden der Rollladen-Positionen gezwungen meine Node-Red-Skripte anzupassen. Keine große Sache, aber mit Job, Frau, Kindern und Hobbies all derer brauchte ich zwei Wochen, bis ich Abends die Zeit dazu fand, mir das neue Verhalten genauer anzusehen und die nötigen Anpassungen zu machen. Durch das Downgrade hatte ich keinen Stress das schnellstmöglich zu machen.

Beim zweiten Mal konnten sich die Shelly 1 nach dem Update nicht mehr per WiFi mit Ubiquiti Unify APs verbinden - haben keine IP mehr bekommen. Dadurch funktionierten die betroffenen Shellys überhaupt nicht mehr. Durch das Downgrade (zugegeben etwas aufwändiger, weil kein Zugriff per WiFi mehr) konnte ich die Shellys weiterhin betreiben und jede Menge Support-Logs (vor und nach dem Update) an Ubiquiti senden, bis ca 10 Wochen später endlich ein funktionierendes Update für die APs kam und die Shellys auch in der damals aktuellen Version wieder liefen.

Deswegen versuche ich so weit wie nur irgendwie möglich selbst Herr über die Software- und Firmware-Versionen meiner Geräte zu bleiben und im Notfall auch zurückgehen oder ein Backup einspielen zu können.