Beiträge von eiche

hheck

Du zeigst Code und fragst, ob das funktioniert.

Du solltest deinen Code testen, um zu erkennen, ob es so arbeitet, wie du das haben willst.

Deine dann daraus gewonnenen Erkenntnisse hier zu posten, wäre dann konstruktiv.

Wenn du auf diese Weise vorgehst, kann ich dir vielleicht weiterhelfen.

Allerdings erkenne ich bisher nicht die Gründe der von dir festgelegten Voraussetzungen - keine Einbindung der Shellies in ein WLAN.

Es wäre zielführend, wenn du aufzeigst, warum die Shellies nicht in ein WLAN eingebunden werden sollen.

Ich bin nach wie vor zur Mitarbeit bereit.

Kurzer Zwischenbericht

Mein Uhr-Projekt Shelly mit den aktiven, anwendungsbezogenen Schedule Jobs arbeitet nach wie vor seit 2023-06-11 23:00 Uhr ohne ein Reboot durch - Firmware 1.0.0-beta3.

Sollte ich zwischenzeitlich irgendein Problem feststellen, werde ich dies hier berichten.

Solange ich hier nichts schreibe, bin ich entweder verhindert oder (etwas wahrscheinlicher) der Shelly arbeitet stabil und problemfrei durch.

Edit: 2023-06-22, 09:00 Uhr

Der Uhr-Shelly arbeitet nach wie vor seit dem Firmware Update ohne ein Reboot. Darauf arbeiten drei Skripte und fünf Schedule Jobs verlässlich.

Edit: 2023-07-01, 18:50 Uhr

Der betreffende Shelly arbeitet immer noch ohne ein zwischenzeitliches Reboot - Firmware 1.0.0-beta3

Ich schließe nun meine Berichte ab, da nicht mehr damit zu rechnen ist, dass sich das alte Reboot-Problem ereignen wird.

Ich kann dir eine solche Vorgehensweise nicht empfehlen.

1. Die Shellies sollen vermutlich in deinem WLAN erreichbar sein. Das sind sie nicht über diese IP-Adresse.
2. Das Wechseln der AP-Shellies ist aufwändiger und kostet zusätzlich Wartezeit, beides muss zusätzlich implementiert werden.
3. Vermutlich sollen die beteiligten Shellies durchgehend zugreifbar sein. Das ist mit dieser IP-Adresse nicht möglich.

Wenn du das trotz aller Bedenken implementieren willst, solltest du dich mit den dafür vorgesehenen Bibliotheken genauer beschäftigen.

Auch genügt es dann nicht, eine Verbindung in der setup() Funktion herzustellen, da diese ausschließlich beim booten des Mikrocontrollers einmal abgearbeitet wird.

Du musst dann ja regelmäßig zwischen den Shelly-AP wechseln lassen.

Stimmt, die 192.168.33.1 ist die Standard IP-Adresse jedes Shelly im AP-Modus. Hier ist eine IP-Adresse aus deinem WLAN erforderlich.

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.