Beiträge von eiche

Ich vergebe, wenn überhaupt, nur ein Passwort, wenn ich es mir notiere oder eines meiner Standard-Passwörter ist.

Ein Passwort per "Automatik" speichern zu lassen, halte ich eh für problematisch.

Nun aber zu dir.

Afaik werden solche Passwörter nicht (als leer) rückgesetzt, wenn du die Konfiguration auf Auslieferungszustand rücksetzt.

Es gibt aber einen Forum-Teilnehmer, der nach Ausbau des entsprechenden Speicherchips das Passwort finden kann, was zwar eine bedenkliche Implementation in der Firmware ist, hier dir aber helfen könnte.

Bei Interesse könnte ich dir den Teilnehmer per PN nennen, wenn er sich hierzu nicht selbst meldet.

Das Verfahren ist etwas aufwändig, zumal du dafür deinen Shelly versenden müsstest. Die Frage der Kosten magst du selbst abschätzen!

Vorher magst du den Versuch des Rücksetzens vornehmen, was jedoch afaik nicht helfen wird.

Die in meinen Implementationen genutzten Schedule Jobs sind genauso konfiguriert wie die, welche per Web UI und klicken erstellt werden.

Das lässt sich leicht überprüfen per

http://<ip-address>/rpc/schedule.list

Meine selbst zusammengestellten Jobs werden nur nicht in der Web UI angezeigt, was verständlich ist, weil ich darin zwar dokumentierte aber nicht zum vorgegebenen Standard gehörende Methoden verwende.

Diese Jobs sind vielseitiger nutzbar, als es die Web UI zur Verfügung stellt - und sie funktionieren bestens.

Man kann damit viel mehr tun lassen als nur in wöchentlichen Zyklen Ausgänge schalten.

Ich habe im Zusammenhang mit dem Firmware Update auf 1.0.0-beta3 weder meine Skripte noch meine Schedule Jobs verändert.

Das vorherige Fehlverhalten (zyklische reboots) liegt offenkundig an der vorherigen Firmware, denn seit dem Update gibt es seit dem 2023-06-11 23:00 kein solches Fehlverhalten mehr.

Ich darf noch erwähnen, dass ich in den Zusammenstellungen sowohl der Skripte als auch der Schedule Jobs sehr sorgfältig plante und umsetzte.

Auf diese Weise erreiche ich, dass die Dichte von RPC soweit wie möglich reduziert ist, weil sie zeitlich verzahnt erfolgen.

Wie der aktuelle Testbetrieb zeigt, arbeiten meine Implementationen bisher sehr robust.

Auch habe ich nichts anderes verwendet als das, was seitens Allterco dokumentiert ist.

Diese Dokumentation mag anfangs gewöhnungsbedürftig sein, inzwischen finde ich sie aber sehr gut und fast komplett.

Ich fand darin bisher nur einen erheblichen Fehler, vermutlich durch Copy & Paste hervorgerufen.

Fazit:

Die Firmware war anfangs noch etwas "Bananen" lastig - sie reifte beim Kunden. In der aktuellen Beta-Fassung überzeugt sie mich bisher aber vollständig.

Ich hoffe, dass seitens Allterco weiterhin eine solche Pflege praktiziert wird.

Das sind anwendungsbezogene Schedule Jobs, per RPC angelegt. Sie funktionieren ausschließlich auf Grundlage eines bzw. zweier Skripte.

Wenn du dich immer noch damit beschäftigen willst, verweise ich auf meine dbzgl. Projekt Website.

Alle drei Artikel mit dem Wort "Hauptuhr" im Titel beziehen sich darauf.

Auch gibt es drei HTML-Dateien (Webseiten) zum Anlegen der Schedule Jobs ...

Diese meine ungewollten Reboots ereigneten sich auf denjenigen Shellies, auf welchen ich Schedule Jobs verwende.

In meinem Uhrprojekt arbeiten im Regelbetrieb zwei Schedule Jobs je Minute, zeitlich verzahnt.

Vermutlich fördern solche Jobs die Reboots, allerdings alle ca. 10h.

Und mit der 1.0.0-beta3 arbeitet der Uhr-Shelly seit ca. 60h ohne Unterbrechung und ohne Reboot.

Das ist auffällig.

Auf einem anderen Shellie sind die zeitlichen Abstände der Schedule Jobs erheblich länger.

Trotzdem ergaben sich auch dort regelmäßige Reboots.

Auch dieser Shelly arbeitet seit dem Firmware update bisher ohne Unterbrechung.

Bei Netzbetrieb sendet der alte Shelly H&T alle 5 Minuten.

Nach meiner Erfahrung tut das der Plus H&T so nicht.

Dieser sendet meiner Erinnerung nach bei USB-Versorgung in größeren Zeitabständen, wenn die Änderungsschwelle (min. 0,5°C) nicht erreicht wird.

Ich nutze Shelly Plus 1 und 2 mit Skripten.

Diese Shellies rebooteten nach jeweils ca. 10h ohne konstante Periode.

Seit ich auf Firmware 1.0.0-beta3 aktualisiert habe, gab es bisher keine Reboots.

Ich vermute in den älteren Versionen Stack- und/oder Buffer-Überlauf.

Das Changelog lässt vermuten, dass seitens Allterco zur neuen Version sorgfältiger mit Stack und/oder Buffer gearbeitet wird - ohne Überläufe.

Du kannst den Accesspoint Modus des Shelly deaktivieren.

Schau dazu nach unter Setting -> Access Point und deaktiviere "Enable AP Network"!

Das geht bei meinem Shelly Plus 2 und sollte beim Plus S ebenso der Weg sein.

Allerdings solltest du unabhängig vom Shelly die Verbindung zu deinem WLAN automatisch herstellen lassen können.

Dann sollte der Plus S nicht stören.

Au ja. Danke

Habe ich das nicht von dir übernommen?

Ich korrigiere.

So, nun noch eine Skriptalternative zum Entwurf von ostfriese .

Ich verzichte hier auf das Suchen von Skriptnamen und setze in Config.scripts direkt deren Id ein.

let Config = {
  scripts         : [2, 3, 4],
  wait_seconds    : 10
};

let t = null;
let i = 0;

function start_script(){
    if(i>=Config.scripts.length) {
        Timer.clear(t);
        Shelly.call("script.stop", {"id":Shelly.getCurrentScriptId()});
        return;
    }
    Shelly.call("script.start", {"id":Config.scripts[i]});
    i++;
}

t = Timer.set(Config.wait_seconds*1000, true, start_script);

Vielleicht kann es nützlich sein.

Nachdem ich nun alle Beiträge dieses Threads las, versuche ich mal den Entwurf von ostfriese etwas zu beleuchten bzw. geringfügig zu korrigieren.

let Config = {
//############# comfig ##########################################################
  scripts         : ["skript1","skript2","skript3"],
  wait_seconds    : 10
//###############################################################################
};

function get_script_id(){ // Ich halte start_scripts() für passender.
    Shelly.call("Script.List","",
        function(result, error_code, error_message){
            let a = result["scripts"];
            for (let i=0; i<a.length; i++) {
                for (let j=0; j<Config.scripts.length; j++) {
                    let name = Config.scripts[j];
                    if (a[i]["name"] === name) {
                        let script_id = a[i]["id"];
                        console.log("Script " + name + " start...");
                        Shelly.call("script.start", {"id":script_id});
                        // Die folgende Zeile muss am Ende der callback Funktion stehen, weil hier das Skript sofort gestoppt wird.
                        // Shelly.call("script.stop", {"id":Shelly.getCurrentScriptId()}); 
                    }
                }
             }
             Shelly.call("script.stop", {"id":Shelly.getCurrentScriptId()});
        }
    );
};

let t = Timer.set(Config.wait_seconds,false,get_script_id);

Problem:

Da die Ausführungen der RPC bzw. Shelly.call() asynchron ablaufen, erscheint mir die Reihenfolge der Skriptstarts nicht wie in Config.scripts aufgeführt sichergestellt.

Hier könnte ein Objekt "Start" Abhilfe schaffen, dessen Methode Start.next() per Timer wiederholt aufgerufen wird, bis alle Skripts (oder Skripte ;-)) gestartet wurden.

Ich täte ein anderes Verfahren bevorzugen:

Die letzte Anweisung von Skript1 startet per Timer Skript2, dessen letzte Anweisung per Timer Skript3 startet. Dazu ist kein zusätzliches Skript erforderlich.

Oder:

Für jedes Skript einen Schedule Job anlegen, welcher ein Skript startet. Diese Jobs sind zeitlich zu verzahnen bspw. "10 * * * * * ", "20 * * * * *", "30 * * * * *".

Entweder man lässt diese Jobs aktiv, wodurch die Skripte periodisch gestartet werden, oder jedes gestartete Skript disabled seinen Schedule Job.

Edit: Für letztere Variante wäre ein zusätzliches Skript erforderlich, welches nach einem reboot die drei Jobs enabled. Hm ...

Ich stelle allerdings auch gelegentlich fest, dass Shellies fast periodisch rebooten oder ein Skript gestoppt wird, obwohl dieselben Funktionen darin zuvor viele male fehlerfrei abgearbeitet wurden.

Hier gibt es offenbar in der Firmware noch Verbesserungsbedarf. Ich habe Stack Overflow oder/und Buffer Overflow in Verdacht ...

Nach meiner Erfahrung können bis zu drei Skripts parallel laufen.

ostfriese

die Quelle liegt als Screenshot vor. Ich werde das Bild nicht abtippen. In der Quelle (bereits in #7) steht das Folgende ohne das führende let.

let name = Config.scripts[j];

Aber tatsächlich wird diese Variable nicht gebraucht, da in Zeile 15 statt name auch Config.scripts[j] verwendet werden kann.

@AlexAn zu #9, Zeile 14

name ist nicht deklariert.

Setze ein let davor oder nimm den rhs Ausdruck direkt in die nächste Zeile!

Falls dies bereits geklärt war, bitte ich um Entschuldigung.

Btw, Fehlersuche sollte man kleinschrittig durchführen.

D.h. Erst einmal alle Shellies von der Versorgung nehmen und dann eines nach dem anderen versuchen, ins WLAN zu bringen - immer nur ein Shelly versorgt.

Jo, da treffen wir uns.

Dazu täte ich nur unter Beisein meines Anwalts eine Aussage treffen.

Vielleicht.

Geräte, die per WLAN funken, können sich gegenseitig stören.

Es ist zumindest einen Versuch wert, die Shellies weiter auseinanderzulegen.

Ohne Schaltplan kann ich dir nun nicht weiterhelfen.

Ob der Schaltplan irgendwelche Aufschlüsse ergeben täte ist selbstverständlich ungewiss.

Ähnliche MAC-Adressen ist unerheblich, solange sie nicht gleich sind.

Sollten diese gleich sein, wäre dies ein Reklamationsgrund. Und das wäre ein Grund, Hornbach zutiefst zu misstrauen.

Aber solches ist mir noch nie untergekommen.

Wenn ich die fehlende Information benennen könnte, hätte ich bereits einen weiteren Tipp für dich.

So bleiben ausschließlich deine Analysen.

Genau deshalb fragte ich nach eigendeinem Unterschied in deinen Anwendungen der Shellies - inkl. Beschaltung.

Kannst du irgendeinen Unterschied zwischen dem eingebundenen Shelly und den anderen feststellen?

Dann sind das die alten Shellies. Diese täte ich nicht mehr kaufen.

Sie tun aber in vielen Fällen das, was sie sollen.

Und wenn "dein" Hornbach diese jetzt erst anbietet, dürften es wohl keine Ladenhüter sein.