Beiträge von eiche

    Dann wäre dem Shelly (Skript) vom ablesenden Menschen mitzuteilen, welche Zeit die Nebenuhr gerade anzeigt.

    Das lässt sich, bspw. per Dashboard und MQTT/HTTP, implementieren.

    Eine andere Vorgehensweise könnte das manuelle (per Taster) Stellen der Nebenuhr auf die aktuelle Zeit sein.

    Letzteres ist schon deshalb reizvoll, weil dazu keine zusätzlichen Systeme erforderlich sind.

    Nachfrage/Bemerkung:

    Ich kann mir nicht vorstellen, dass eine Nebenuhr nach Power On eine feste Zeit einstellt, wie bspw. 6 Uhr.

    Dass sie ohne zugeführte Pulse stehen bleibt, ist mir sehr verständlich.

    Gibt es dazu noch Hinweise oder habe ich hierzu das Notwendige erfasst?

    thgoebel

    zu (a): klar

    zu (b): Diese kenne ich noch nicht.

    zu (c): Das weiß ich nicht, weil ich solche Nebenuhren bisher nicht kannte und noch keine in den Händen hatte. ;)

    zu 1. Ich weiß nicht, wie die vorliegende Zeitanzeige der Nebenuhr informationstechnisch erfasst werden kann.

    zu 2. Das liegt bereits teilweise im Skript vor - ohne den Status Sommerzeit vs. Normalzeit. Letzteres kann ich derzeit noch nicht wirklich.

    zu 3. Ich verwende im Skript neben dem Zeitstempel (ts=timestamp) als Referenz (auch im NVS gespeichert) ausschließlich relative Werte wie dt (Zeitdifferenz ts - stored ts), nachzuliefernde Pulse als Abwärtszähler.
    Dies hat sich bisher als tauglich bewährt.

    zu 4. Ja, so habe ich es im wesentlichen implementiert.

    Danke für deine Anregungen. Das Projekt hat mich eingefangen. ;)

    Ich bin jederzeit froh über zusätzliche Informationen, da dieses Projekt für mich - zumindest zu Beginn - Neuland ist/war.

    Es ist nach wie vor spannend.

    Btw, eine allzu große Abhängigkeit von Internet Services möchte ich vermeiden, weil so ein halbwegs autarkes System nicht möglich ist.

    Einzig der Zeitserver wird benötigt und diese Synchronisation darf afaik auch mal temporär ausfallen.

    Das obige Dashboard für die Uhrsteuerung bewährt sich.

    Es unterstützt mich beim testen und simulieren von Stromausfällen (fast worst cases).

    Der letzte Test mit einem Stromausfall während der Umstellung auf Normalzeit zeigte bereits einen logischen Skriptfehler, welchen ich nun behob.

    Es folgt der nächste Test per Zeitplanung.

    An dieser Stelle möchte ich einmal mitteilen, dass mir diese Firmware von Allterco Robotics auf Basis des mongoose OS sehr gut gefällt.

    Ich finde das offene System mit vielen Software-Interfaces und der Dokumentation dazu sehr brauchbar - weniger für Endanwender, mehr für Anpasser an spezielle Anwendungen (/wie mich).

    :)

    Ein kleines Dashboard (Node-RED) ist inzwischen fertig. Ich habe es zunächst für mich erstellt, um meine Implementation zur Uhrsteuerung leichter testen zu können.

    Es ist auch bereits für echte Anwendungen einsetzbar - allerdings nicht für DAUs geeignet.

    Man kann damit folgende Einstellungen vornehmen.

    • Datum, Uhrzeit der Umstellung auf Sommerzeit
    • Datum, Uhrzeit der Umstellung auf Normalzeit
    • Uhrzeit und bei Bedarf Datum zum starten des Skript inkl. enable/disable
    • Uhrzeit und bei Bedarf Datum zum stoppen des Skript inkl. enable/disable

    Dies erleichtert den Testbetrieb, weil man für einen solchen Test nicht vor dem Computer sitzen muss.

    Das kann der Shelly alleine.

    Für das Zählen der Pulse habe ich bisher im Skript nichts eingebaut, dies starte ich noch in der Node-RED Programmieroberfläche.

    Grund: Hier ist sehr einfach der Startzeitpunkt inkl. Datum und der aktuelle Zählerstand abfragbar.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Prima. Danke für deine Rückmeldung. So habe ich es implementiert und dann lasse ich es auch so.

    Ich muss noch einmal testen. Evtl. ist sogar bereits ein Stromausfall während der Umstellung unkritisch.

    Das Ruhen von 1 Stunde ist nicht so ganz trivial.

    Der vorhin abgelaufene Test mit Ruhen von einer Stunde war ohne Stromausfall erfolgreich.

    Es sind noch weitere Fälle zu prüfen, die ich bereits berücksichtigte.

    Das sind:

    Die Umstellung erfolgt nach einem Stromausfall und

    • die nachgelieferten Pulse repräsentieren mehr als eine Stunde,
    • die nachgelieferten Pulse repräsentieren weniger als eine Stunde.
    • Während der Umstellung ereignet sich ein Stromausfall.

    Ich habe noch niemals zuvor so ausgiebig mit Schedules gearbeitet. ;)

    Wenn erstmal eine Idee da ist und der Perfektionimustrieb nicht ruht ... ;)

    Die Umstellungen auf Sommerzeit und Normalzeit an Hand zweier Schedule Jobs sind implementiert.

    Umstellung auf Sommerzeit (+60 Pulse) ist getestet und für (vermutlich) gut befunden.

    Umstellung auf Winterzeit (1h Ruhe) läuft gerade und dauert noch.

    Allerdings darf es während dieser Umstellung, insbesondere auf Normalzeit, keinen Stromausfall geben. Darüber werde ich noch nachdenken.

    Auch werde ich ein Node-RED Dashboard erstellen, in welchem man die beiden Tage der Umstellungen per Datum einträgt, woraufhin die beiden Umstellung Schedule Jobs ein Update erfahren.

    Dies will ich per HTTP GET implementieren. Na ja, Node-RED muss halt dazu laufen.

    Mit "nichts" geht halt auch "nichts".

    Zusätzlich (für MQTT) will ich noch einen oder zwei Subscriber im Skript einbauen, damit bspw. solche Updates per Android App "MQTT Dash" vorgenommen werden können.

    Eine vollautomatische Umstellung ist mir noch zu aufwändig.

    Nachtrag: Meine Frau sagt: "Im Herbst muss die Uhr aber nachts um 3 Uhr auf 2 Uhr zurückgestellt werden. Sonst läuft die Uhr ja nicht weiter."

    Hmmm, mal sehen. Das Rückstellen ist selbstverständlich möglich, mit vielen Pulsen. :D

    Und ... es ist auch leichter zu implementieren.

    Zu meinem Skript + Schedule Jobs zwecks Steuerung einer älteren Elektrouhr:

    Ich habe eine längere Messung durchgeführt.

    Die Zeitspanne betrug 64210s. Dazwischen war das Skript einige nicht gemessene Stunden angehalten, was einem Stromausfall entspricht.

    Rechnerisch musste das Skript 61210/60 = 1070 Pulse erzeugen. Und genau das tat es. Ich bin sehr zufrieden.

    Hinweis: Ich habe die Schreibzugriffe in den NVS (non volatile storage) - in der Allterco Dokumentation unter KVS (key value storage) zu finden - während des Nachreichens von Pulsen nach einem Stromausfall reduziert.

    Grund: Der NVS verträgt deutlich weniger Schreibzugriffe als der volatile storage (auch RAM genannt).

    Da die nachgereichten Pulse in relativ dichter Folge erzeugt werden, habe ich das geringere Risiko des Stromausfalls in dieser "Nachreichphase" in Kauf genommen, um die NVS-Schreibzugriffe zu reduzieren. Das ließe sich im Skript leicht ändern, indem der Unix-Zeitstempel auch zu jedem nachgereichten Puls im NVS gespeichert wird.

    Interessant wäre in diesem Zusammenhang eine Energiepufferung für relativ kurze Dauer. Wenn alle Daten bekannt sind, was prinzipiell möglich ist, kann im Skript in der Nachreichphase mehr "Intelligenz" eingebaut werden. Diese würde dafür sorgen, die NVS-Schreibzugriffe zu minimieren, ohne die Funktionssicherheit zu beeinträchtigen.

    Diese Betrachtung ist allerdings schon recht weit fortgeschritten.

    Wenn man für jedes Jahr zwei passende Schedule Jobs einsetzt/aktualisiert, ist das ziemlich einfach.

    Dann ist jeweils der Umstelltag anzupassen, die Uhrzeit bleibt ja gleich. Jeder der beiden Jobs ruft eine Funktion auf.

    Die Funktion toSummer() simuliert einen einstündigen Stromausfall, toNormal() setzt für eine Stunde den Job 1 aus, welcher den Minutentakt bietet.

    Einzig eine Automatisierung der beiden zusätzlichen Jobs ist relativ aufwändig.

    Ich bin allerdings erst bereit, dies in der einfachen Fassung zu implementieren, wenn mein Skript + Schedules tatsächlich Anwender findet.

    Der Unix Timestamp hat weder etwas mit Tag/Nacht noch mit Monaten oder Jahren zu tun und schon gar nichts mit einer doofen Sommerzeit.

    Er ist schlicht die Anzahl Sekunden seit dem 1.1.1970 (0 Uhr?).

    Daraus lässt sich die Uhrzeit sehr einfach ermitteln, wenn man diese braucht. Auch die Shelly Firmware bietet diese bei Bedarf.

    Alleine die Sommerzeit ist aufwändiger zu berücksichtigen.

    Uhrsteuerung per Shelly 2. Generation mit Schedule Jobs und Skript

    Auf ausdrücklichen Wunsch von thgoebel habe ich mich um eine nutzbare Implementation bemüht. horkatz könnte sie auch interessieren.

    Die erste auslieferbare Testfassung ist fertig.

    Ich habe sie getestet mit einem Shelly Plus 1, MQTT Nachrichten, Node-RED zwecks Speicherung in einer Influx Zeitreihendatenbank und Grafana zur Visualisierung.

    Zusätzlich habe ich per Node-RED einen Zähler für die Schaltpulse eingerichtet. Per Inject Node wird der Zählerstand auf 0 gesetzt und der Zeitstempel zu diesem Zeitpunkt gespeichert.

    So kann jederzeit die zur vergangenen Zeit gezählten Pulse erfasst und ausgewertet werden.

    Mein letzter Test zeigte, dass auch nach einem (simulierten) Stromausfall schließlich alle ausgefallenen Pulse nachträglich erzeugt wurden.

    Ich kann nicht ganz ausschließen, dass nach einem Stromausfall evtl. ein Puls zu wenig erzeugt wird, um die Uhr auf die richtige Zeit zu bringen.

    Dies sollte mit einer Uhr, die ich nicht habe, getestet werden.

    Für den praktischen Einsatz ist eine Funktion pulse(duration) so anzupassen, dass die physikalisch geeigneten Pulse erzeugt werden, bspw. mit zwei Ausgängen.

    Das erforderliche Timing der Pulse ist relativ leicht per zwei anzulegender Schedule Jobs einzustellen.

    Die von mir angelegten Schedule Jobs für Testzwecke sind folgende:

    Code
    {"jobs":[
    {"id":1,"enable":true,"timespec":"0 * * * * *","calls":[{"method":"Script.Eval","params":{"id":1,"code":"pulse(5000)"}}]},
    {"id":2,"enable":false,"timespec":"*/5 * * * * *","calls":[{"method":"Script.Eval","params":{"id":1,"code":"pulse(1000)"}}]}
    ]}

    Die beiden Jobs unterscheiden sich im wesentlichen in der Frequenz.

    Job 1 ruft minütlich die Funktion pulse(5000) auf. Es wird somit alle 60 s ein Puls mit einer Dauer von 5000 ms = 5 s erzeugt.

    Job 2 ruft alle 5 s die Funktion pulse(1000) auf, wodurch alle 5 s ein Puls mit einer Dauer von 1000 ms = 1 s erzeugt wird.

    Job 1 ist für den regulären Betrieb zuständig, Job 2 für die Nachlieferung von per Stromausfall nicht gesendeten Pulse, um die Uhr auf die richtige Zeit zu stellen.

    Das Skript aktiviert immer nur einen dieser beiden Jobs, sie sind also nie zugleich aktiv.

    Nun das Skript:

    Es enthält neben debug Ausgaben (print), welche per debug=true aktiviert bzw. debug=false deaktiviert werden, noch zusätzliche Ausgaben, die später entfernt werden können.

    Sie dienen der Beobachtung insbesondere der Pulserzeugung nach Stromausfall.

    Um einen Stromausfall zu simulieren, genügt es, das Skript anzuhalten und es nach der simulierten Ausfalldauer zu starten.

    Selbstverständlich lässt sich der Code auch ein Stück weit objektorientiert verfassen.

    Da ich zu diesem Projekt keine einschlägige Vorerfahrung hatte, habe ich schlicht Wert auf dessen Funktionalität und Funktionssicherheit gelegt.

    Eine Grafana Zeitgrafik zur Pulserzeugung:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Links sind die in dichter Folge erzeugten nach einem Stromausfall gelieferten Uhrstell-Pulse zu sehen, rechts die regulären minütlichen Pulse.

    Bei konkreten Fragen zum Skript und den Schedule Jobs gebe ich gerne Auskunft. Ob ich die Muße finden werde, zum Einsatz eine Anleitung zu verfassen, weiß ich noch nicht.

    Das wird auch vom Kreis der Interessenten abhängen.

    Nun hoffe ich, dass diese Implementation irgendwo ihre Anwendung findet.

    Gruß aus Rheinland-Pfalz

    Es ist spannend.

    Der Shelly schickt derzeit alle 5s missing pulses raus. Es waren 89, da ich zwischenzeitlich am nicht laufenden Skript arbeitete.

    Nun werde ich sehen, ob er irgendwann in den regulären Betrieb übergeht.

    Nach meinen Überlegungen sollten dann erneut Pulse fehlen, aber erheblich weniger - und wieder missing pulses ausgeben.

    Irgendwann sollte dann die Synchronisation in den regulären Betrieb übergehen.

    Ich bleibe "am Ball". Ich bin auch gespannt, ob meine Entwicklung jemand einsetzen wird.

    Ich habe ja keine entsprechende Uhr.

    Ok, solche hardwarenahen Einzelheiten wären ohnehin später noch zu implementieren.

    Dazu muss dann nur noch eine Funktion angepasst werden, welche die Ausgänge steuert.

    Dazu kann ich mir später Gedanken machen.

    Zunächst geht es mir darum, festzustellen, wie viele Pulse fehlen, um die Uhr erneut die aktuelle Zeit anzeigen zu lassen.

    Das ist bereits fertig. Nun fehlt aber noch das Senden der fehlenden Pulse, und dies, ohne von den regulären Minutenpulse dabei gestört zu werden - nicht ganz trivial.

    Und schließlich muss danach wieder der reguläre Betrieb laufen.

    Werter thgoebel ;)

    Das kann ich gerne tun.

    Momentan bin ich noch damit beschäftigt, "missing pulses" zu implementieren. Dies sind zusätzliche Pulse, welche beim zwischenzeitlichen Stromausfall zum stellen der Uhr nachzuliefern sind.

    Mein erster Versuch mit einem Timer, der sich selbst beendet, gelang fast, aber leider nur fast.

    Grund: Das Timer Handle liegt offenbar erst dann vor, wenn der Timer.set Aufruf "durch" ist. Intern wird aber zum beenden des Timers dieses Handle benötigt.

    Hier kommt die sprichwörtliche Katze zu spät, um sich in den Schwanz zu beißen - bzw. den Schwanz abzubeißen.

    Nun will ich statt des Timers, mal wieder, einen zusätzlichen schedule job einsetzen. Ich arbeite gerade daran - bin selbst gespannt.

    Cu later

    Kurze Rückmeldung zur bisherigen Problemlösung

    Ich habe das Skript umgeschrieben und bin damit zufrieden.

    Auch nehme ich die Vermutung (vorläufig) zurück, dass die Firmware ursächlich für das Problem ist.

    Jedenfalls lag die Stelle des Auftretens irgendwo im event handling.

    Mein Skript nutzt nun den ursprünglichen schedule job und zwecks Erfassung des Schaltens das event handling.

    Ich danke Devil und Seven of Nine für ihre Beteiligungen an diesem Thread.

    Bei Interesse an diesem kleinen Projekt stelle ich meine Lösung gerne zur Verfügung.

    Es soll dem Steuern von älteren elektrischen Nebenuhren dienen können.

    Mir stellt sich die Firmware 0.14.1 als instabil dar.

    Warum?

    Folgende Konstellation:

    Schedule Jobs:

    Code
    {"jobs":[
    {"id":1,"enable":false,"timespec":"0 * * * * *","calls":[{"method":"Script.Eval","params":{"id":1,"code":"clockTrigger(5000)"}}]},
    {"id":2,"enable":true,"timespec":"0 * * * * *","calls":[{"method":"Switch.Set","params":{"id":0,"on":true}}]}
    ], "rev":6}

    Ohne ein gestartetes Skript tut der Shelly seinen Job gemäß seines Schedule Job 2. Auch das konfigurierte automatische Abschalten nach 5s funktioniert.

    Dann sperre ich wieder das automatische Abschalten und starte das folgende Skript:

    Nun ereignen sich in kürzeren Abständen, also deutlich unter 1 Minute Ein- und Ausschaltvorgänge - mehrmals hintereinander.

    Ein und sofort danach wieder aus.

    Die Ausgaben per print habe ich zur Sicherheit auskommentiert.

    Zuvor zeigten sie die eintreffenden zu erwartenden Schaltereignisse.

    Ich werde erneut andere typgleiche Shellies testen - mit unterschiedlichen Firmware Versionen.

    Edit:

    Das obige Skript ist nicht gut zusammengestellt. Der Timer sollte Event selektiv gestartet werden.

    Allerdings sah ich ausschließlich die Schaltevents ...

    Ich arbeite weiter daran.

    So, ich habe soeben einen zweiten Schedule Job angelegt mit:

    Code
    http://<ip-address>/rpc/Schedule.Create?enable=true&timespec="0 * * * * *"&calls=[{"method":"Switch.Set","params":{"id":0,"on":true}}]

    Und prompt ereignet sich beim Einschalten der bereits geschilderte Skriptabbruch mit derselben Fehlermeldung.

    Ein Eventhandling zum Einschalten habe ich noch nicht eingebaut.

    Da bleibt mir nur noch der Schluss, dass hier ein Fehler in der Firmware vorliegt.

    Mich würde nun noch interessieren, welche Konstellation dazu führt.

    Ich habe ein anderes Projekt vorläufig erfolgreich abgeschlossen, welches einen Shelly Plus 1 mit Sensor Addon und einem Ventilantrieb als autarken Thermostat betreibt - ohne irgendeinen Skriptabbruch.

    Und jenes Projekt ist deutlich komplexer als dieses hier mit dem von mir oben beschriebenen Skript.

    Inzwischen habe ich den ersten Schedule Job disabled. Trotzdem derselbe Fehler.

    Ich werde nun sukzessive und kleinschrittig ein neues Skript aufbauen, um zu sehen, wann sich dieser Fehler einstellt.

    Ich hatte übrigens auch mal den Shelly gewechselt, also einen typgleichen eingesetzt.

    Ich werde den Schedule Job so ändern, dass er die Methode Switch.Set mit {"id":0, "on":true} aufruft und im Eventhandler die Rückmeldung des Schaltens nutzen, um den Puls zu stoppen.

    Meine bisherige Lösung gefällt mir aber besser, weil man so die Pulsdauer parametrieren kann, ohne das Skript zu manipulieren.

    Wenn dies gelingt, kann ich ja noch Kommunikation einbauen, damit der Anwender die Pulsdauer darüber konfigurieren kann.