Beiträge von Rexton

Vielen Dank für die Antworten.

Da ich bereits ein Ticket bei Shelly erstellt hatte, habe ich deren Antwort abgewartet. Das Ergebnis nach einem Beweisvideo ist, dass sie mir einen neuen Shelly Plus Plug S zusenden.

Vielen Dank für die Antwort. Damit ist Öffnen definitiv keine Option, sehr ärgerlich. Ich habe ein Ticket eröffnet und warte jetzt auf eine Antwort.

Ich kann leider nicht mehr sagen, wann ich den Shelly gekauft habe und ob ich noch Garantie hätte, weil ich immer wieder welche bestellt habe (zuletzt erst vor ca. einem Monat) und die Shellys dann öfter auch mal die Plätze im Haus getauscht haben. Kann man bzw. ich anhand der ID eines Shellys dessen Produktionsdatum herausbekommen?

Hallo,

Ich habe heute einen Shelly Plus Plug S nach langer Zeit (Februar diesen Jahres) wieder eingesteckt und als erstes ein Firmware-Upgrade gemacht. Ich habe nicht darauf geachtet, von welcher Version er gestartet ist, aber das Ziel war die aktuelle Version 1.4.4.

Nach ein bisschen rot blinkenden LEDs ist der Shelly ausgegangen und ist seitdem komplett tot.

Wenn ich ihn einstecke, passiert nichts: kein Geräusch, keine LEDs und einen Reset mit 10 Sekunden (und mehr) Taste drücken, habe ich schon mehrfach probiert. Keine Reaktion mehr.

Das ist das erste Mal, dass ich mit einem Firmware-Upgrade eines Shellys Probleme habe.

Habt ihr eine Idee, was ich noch probieren könnte? Ich würde den ungern einfach aufgeben, aber ich befürchte die Antwort wird ein Öffnen des Shellys und ein Flashen der Firmware bedeuten und das könnte meine Fähigkeiten übersteigen.

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.