Beiträge von eiche

Die Allterco-Dokumentation zu den Shellies der 1. sowie der 2. Generation findest du unter https://shelly-api-docs.shelly.cloud/.

C++ ist eine Programmiersprache, die Objektorientierung unterstützt.

Wenn du absolut keine Ahnung vom programmieren hast, wird es schwierig.

Andernfalls könnte ich dir vielleicht helfen, ich nutze allerdings schon länger die Arduino Entwicklungsumgebung (IDE=Integreted Development Envirinment) nicht mehr.

Die zweite bzw. neue/andere Instanz ist eine Variable bzw. Referenz auf ein Objekt, zu welchem eine sog. Klasse die Vorlage (eine Art Schablone) ist.

Eine solche wurde in der Zeile 35 "deines" Codes bereits angelegt, um mit einem Shelly zu kommunizieren.

Ein weiteres Objekt für einen ebensolchen Zweck kannst du anlegen mit

HTTPClient http2; // http2 ist der Instanzname, der auch anders lauten darf, bspw. shelly2.

Ok, wir werden sehen ...

Ansonsten ... halte die Ohren steif!

schlotzi

Die AP können nur begrenzt mit Clients kommunizieren, Falls, aus welchem Grund auch immer, plötzlich mehr Clients auftauchen, kann der AP diesen den Zugriff verwehren.

Du könntest, zumindest zum testen, mal einen zweiten AP installieren und einige deiner Shellies mit diesem verbinden.

...

Ich täte es zunächst mit einer zweiten HTTPClient Instanz (zweites Objekt der Klasse HTTPClient) versuchen.

Da es sich hier um C++ handelt, sollte es gelingen, mehrere solcher Verbindungen aufzubauen.

Allerdings kenne ich die zugrunde liegende Bibliothek nicht.

Einen Versuch ist es aber allemal wert.

Btw. in deinem Code oben sind die Operatoren-Zeichen (=, <=, >=, ...) schlecht lesbar, weil grau hinterlegt.

Edit: Die HTTP-Kommunikation hat Allterco dokumentiert. Dort solltest du hinreichend fündig werden. Der Rest ist experimentieren.

Sonnenanbeter 2.0

Da ich keine dafür geeigneten Lötwerkzeuge besitze, kenne ich nur den thgoebel, der deinen Shelly Plus 1 wiederverwendbar machen kann.

thgoebel

Wenn man die Dose neu setzt, wird vermutlich eine tiefe Dose genügend Platz bieten.

Oder siehst du das anders?

Für den TE dürfte das genannte Verfahren bereits wegen der Kosten wenig interessant sein.

Von daher werden ihm diese Infos allenfalls theoretisch nützen.

ostfriese

Ich wollte hier vorsichtig agieren und nicht als Marktschreier.

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.