UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Meister Mopper]

@hmanfred Okay, das funktioniert.

[Meister Mopper]

Habe es jetzt mal ioBroker-seitig gesteuert:

[hmanfred]

@meister-mopper na dann ist zu hoffen, dass die CCU die Umschaltung auf "falsch" noch mit bekommt...

[Meister Mopper]

@hmanfred Auf falsch wird doch gar nicht getriggert. Nach meinem Verständnis werden die Daten gesichert und die CCU fährt runter. Wenn der Strom unterbrochen wird und neu kommt, bootet sie wieder

[hmanfred]

@meister-mopper
Das ist richtig. Aber du setzt sie erst nach 5 Sekunden auf falsch. Ich kenne die Abläufe in deiner CCU nicht, aber wenn die dann schon am Runterfahren ist, bekommt sie das "falsch" nicht mehr mit.

[Meister Mopper]

@hmanfred Die bekommt das falsch so oder so nicht mit, da ja nur nach "ist wahr" getriggert wird.

Spoiler

script

Spoiler

system.Save();
WriteLine("regadom gesichert");
string stdout;string stderr;
string cmd = "/sbin/poweroff"; 
system.Exec(cmd, &stdout, &stderr);
WriteLine("Befehl "#cmd #" abgeschickt");

[hmanfred]

@meister-mopper
Du verstehst offensichtlich die Systemvariablen nicht. Das setzen der SV auf einen bestimmten Wert und das reagieren darauf (triggern) sind zwei Paar Schuhe.

Was bei dir passiert ist folgendes (chronologisch):

• du setzt im ioBroker die SV auf wahr
• iobroker synchronisiert den Zustand im eingestellten Intervall mit der CCU
• die SV wird dadurch in der CCU auf wahr gesetzt
• die CCU fährt (sofort) runter
• du setzt die SV im ioBroker nach 5 Sekunden auf falsch
• die CCU fährt bereits runter, bekommt das "falsch" also nicht mehr mit
• beim runter fahren hat sich die CCU den Zustand der SV (wahr) gemerkt
• wenn die CCU irgendwann wieder hoch fährt, steht die SV auf wahr
• CCU synchronisiert wieder mit ioBroker, hat beim Neuconnect Prio, SV steht im iobroker auf wahr

Damit kann dann mit deiner Konstellation die CCU nicht wieder runterfahren. Der Trigger deines Programmes reagiert "bei Änderung" - das nächste Setzen auf wahr ist keine Änderung, sie steht ja schon auf wahr.

[hmanfred]

@meister-mopper
Ha, noch etwas:

Die Rega, in der die SV verwaltet werden, wird nur alle n Sekunden synchronisiert. Ist in der Konfig des Adapters default sogar auf 30 Sekunden gestellt.

Wenn du also im iobroker die SV auf wahr und 5 Sekunden später gleich wieder auf falsch setzt ist die wahrscheinlichkeit groß, dass das innerhalb der Pause geschieht und die CCU die Änderung gar nicht mitbekommt.

[Meister Mopper]

@hmanfred Danke für Deine Hilfe.
Ich hatte es mit einem reboot-script getestet und dachte, dass dies auch für "poweroff" gilt.
Nach dem reboot steht im ioBroker "ProgrammExecute" auf false

[Homoran]

@hmanfred sagte in Systeme nach USV-Shutdown wieder hoch fahren:

Wenn du also im iobroker die SV auf wahr und 5 Sekunden später gleich wieder auf falsch setzt ist die wahrscheinlichkeit groß, dass das innerhalb der Pause geschieht und die CCU die Änderung gar nicht mitbekommt.

sicher?

ich denke bei der Zeitspanne geht es um das lesen der Rega, nicht um das Schreiben

[hmanfred]

@homoran
Das wäre mal zu prüfen. Will ich nicht ausschließen.
Dennoch bleibe ich bei meiner Meinung, dass das zurücksetzen der SV Sache der CCU sein sollte.

[hmanfred]

@hmanfred
Hab's geprüft. Änderungen von SV im ioBroker werden sofort an die CCU übertragen.

[hmanfred]

@chrunchy sagte in Systeme nach USV-Shutdown wieder hoch fahren:

@hmanfred Ich kenne die QNaps nicht, aber bei meiner Synology gibt es Aufgaben, da kann ich einfach ein Script rein packen, was ein WOL auslöst.

Bei der QNAP gibt es das auch. Das muss man aber auf der Konsole (SSH) aktivieren und dort auch die Scripts editieren. Da werde ich mich mal dranmachen.
Muss nur erst mal prüfen, ob man die CCU überhaupt per WOL aufwecken kann.

[Chrunchy]

@hmanfred Man kann auf der CCU ja durchaus nach einem Systemstart ein paar SV setzten.
Aber generell ist es natürlich immer ein Timing-Problem, wenn mehrere Systemeeine SV unabhängig voneinander verändern können.

[klassisch]

Bedenkt bitte folgendes reales Szenario wie ich es Pfingstmontag 2015 erlebt und notiert habe:

• Stromausfall im Viertel
• USV springt an, Synology fährt nach einigen Minuten rasch runter
• Für den Rest ist noch genügend Ladung in den Akkus
• Nach ca. 1h wird die Spannung wieder zugeschaltet
• Synology fährt wieder hoch, war von mir so eingestellt
• Nach einigen Minuten erneuter Stromausfall. In den nächsten 45Minuten noch ein paar solcher Wiedereinschaltversuche
• Von mir unbemerkt: Die Syno ist leider nicht wieder heruntergefahren. Warum weiß ich nicht. War aber so
• Nach insgesamt 1h46 schaltet die USV ab. Fritte aus, kein Netz mehr. Akustische Meldung eines Gerätes, daß es jetzt auf eigenen Akkus weiterläuft. CCU aus, ioBroker OPi aus.
• Nach insgesamt 1h47 kommt die Spannung endgültig zurück.
• Wäre die Synology auch nach den widerholten Stromausfällen wieder runter gefahren, dann hätte die Kapazität gut gereicht
• Bei echten Fehlern im Netz, ist das mehrfache Wiedereinschalten keine Seltenheit

[Homoran]

@klassisch sagte in Systeme nach USV-Shutdown wieder hoch fahren:

Nach einigen Minuten erneuter Stromausfall.

Danach hatte ich bereits gefragt, bin mir aber nicht sicher, ob da eine Antwort kam
Ebenso wie die Frage -und da war ich von ausgegangen, dass das hier das eigentliche Thema war- was passiert, wenn der Strom wiederkommt ohne dass die USV "leer" war.
die dahinter steckenden (inzwischen abgeschalteten) Zwischenstecker kommen dann nicht wieder hoch

[klassisch]

@homoran sagte in Systeme nach USV-Shutdown wieder hoch fahren:

Ebenso wie die Frage -und da war ich von ausgegangen, dass das hier das eigentliche Thema war- was passiert, wenn der Strom wiederkommt ohne dass die USV "leer" war.
die dahinter steckenden (inzwischen abgeschalteten) Zwischenstecker kommen dann nicht wieder hoch

Ich lasse in einem solchen Fall meine Syno einfach aus bis ich sie manuell wieder einschalte. Kann notfalls auch mal längere Zeit auf die Syno verzichten, da sie nur noch Backup macht. Alltagsdaten hole ich von einer USB-Platte, die an meinem ioBroker Windows- Rechner hängt.

Da ich ioBroker derzeit ja nicht auf einem schicken en vogue NUC Proxmox laufen habe, sondern auf einem langweiligen alten (Bäh-) Win 10 Laptop mit eigenem Akku, wird der länger laufen als der ganze Rest. Wenn dann wieder Power da ist, dann könnte bei mir der ioBroker den Rest hochfahren.
Falls auch der ioBroker Laptop leerläuft, habe ich ohnehin ein Skript, welches mir beim (wieder-) Hochfahren des js-Adapters eine Mail schickt. In dieses Skript könnte ich noch andere Themen integrieren.

Das wäre aus meiner Erfahrung auf meinem System nicht das Problem. Das Problem war bei mir, daß die Syno beim zweiten, dritten etc. Stromausfall nicht wieder runtergefahren, sondern (ich glaube in irgendeinem Meta-Zustand) weitergerumpelt ist und sinnlos Strom verbraucht hat.

Und das sollte man sich anschauen. wenn man der Syno erlaubt, selbstständig hochzufahren.

Meinen ioBroker Laptop fahre ich nicht runter, oder nur, wenn auch dessen eigener Akku fertig ist. Und selbst wenn der hart abschaltet, wird sich Win später wieder hochrappeln. Zumindest war das bei all meinen neueren Win Rechnern so. Selbst mein erstes XP konnte das - wenn auch manchmal etwas mühselig und langwierig.

[hmanfred]

@chrunchy sagte in Systeme nach USV-Shutdown wieder hoch fahren:

@hmanfred Man kann auf der CCU ja durchaus nach einem Systemstart ein paar SV setzten.
Aber generell ist es natürlich immer ein Timing-Problem, wenn mehrere Systemeeine SV unabhängig voneinander verändern können.

Im vorliegenden Fall von meister-mopper ist es eher ein Problem , wenn nur ein System die SV auf true setzt und nach 5 Sekunden - nämlich dann, wenn das keinen mehr interessiert, weil die CCU am runterfahren ist - wieder auf false setzt.

Ich setze die SV im ioBroker auf true und im davon in der CCU getriggerten Programm wieder auf false. ImO die richtige Vorgehensweise.

[hmanfred]

@homoran sagte in Systeme nach USV-Shutdown wieder hoch fahren:

@klassisch sagte in Systeme nach USV-Shutdown wieder hoch fahren:

Nach einigen Minuten erneuter Stromausfall.

Danach hatte ich bereits gefragt, bin mir aber nicht sicher, ob da eine Antwort kam
Ebenso wie die Frage -und da war ich von ausgegangen, dass das hier das eigentliche Thema war- was passiert, wenn der Strom wiederkommt ohne dass die USV "leer" war.
die dahinter steckenden (inzwischen abgeschalteten) Zwischenstecker kommen dann nicht wieder hoch

Ich meine darauf geantwortet zu haben. Kann aber sein, dass wir aneinander vorbei geredet / gedacht haben.

Nach all den Diskussionen und Ausloten der Möglichkeiten sieht mein Konzept nun so aus:

1. Strom fällt aus, QNAP merkt das, ioBroker über den Adapter auch.
   1a. Strom kommt wieder, alles wieder gut -> weiter bei 9.
2. QNAP geht bei 15% Restladung in auto-Protection Mode (Datenträger abgekoppelt, fährt aber nicht runter)
3. ioBroker veranlasst ebenfalls bei 15% Restladung die CCU und den Proxmox-NUC zum Runterfahren
4. Strom kommt wieder
   4a. USV läuft leer -> weiter bei 6.
5. QNAP macht (weil auto protection mode + USV wieder Online) einen Restart und weckt per autorun.sh die CCU und den NUC per WOL wieder auf -> weiter bei 9.
6. QNAP schaltet mangels Spannung ab
7. Strom kommt wieder
8. QNAP bootet neu und weckt per autorun.sh die CCU und den NUC per WOL wieder auf
9. Ende

Edit: lese gerade im Homematic-Forum, dass der Pi3 kein WOL unterstützt. Konzept geht also so nicht.

[Homoran]

@hmanfred sagte in Systeme nach USV-Shutdown wieder hoch fahren:

Kann aber sein, dass wir aneinander vorbei geredet / gedacht haben.

ja kann es ;-)

So sieht das gut aus, aber ich hatte gedacht, gelesen zu haben, dass nach fix x Minuten die Steckdose wieder scharf gemacht wurde.
Wenn dann aber der Strom der USV noch nicht weg war, so dass ein Hochfahren passierte und anschließend die USV endgültig ohne Saft war, hätte das alle vorherigen Anstrengungen zunichte gemacht.

Dann muss ich mir das mal näher ansehen ob ich das irgendwie auch umgesetzt bekomme, wobei es bei mir 2 USV sind(Keller NAS und iobroker - Hier, die piVCCU und die "Spiele SBC").