z. B. Schaltsteckdosen sind Ein.
Nun ist Stromausfall.
Nach Stromwiederkehr fällt die Schaltsteckdose in Aus.
Und meldet so auch zurück.
Das kann ja sinnvoll sein.
Oft möchte man aber den Zustand vor dem Stromausfall haben.
Sprich: der Aktor soll wieder Ein sein wie vorher.
Ist jemandem hier dafür schon eine Lösung eingefallen ?
Welche Schaltsteckdosen sind es denn?
Welche FW?
Bei meinen Homematic "Classic" und Fibaro Steckdosen gibt es das Register powerUpAction.
EDIT: also Register nat. nur beim Homematic. Beim Fibaro ist es eine EinstellungParameter... ;)
Da kann man einstellen was nach Spannungswiederkehr passieren soll...
Bei meinen Zwischensteckern mit Leistungsmessung aber erst mit FW2.5
EDIT: HM-ES-PMSW1-PL ebenso der HM-LC-SW1-PL-DN-R1 mit FW2.6 haben powerUpAction
Gruß, Joachim
Moin,
ja, davon las ich schon.
Da kann man Ein oder Aus fest einstellen nach Stromwiederkehr.
Meine Frage bezog sich eigentlich auf alle Arten von Aktoren.
Die Schaltsteckdose sollte nur als Beispiel dienen.
Bei batteriebetriebenen Aktoren kann man ja puffern,
bei netzbetriebenen hat man dieses Problem.
Man kann ja nicht vorhersehen, in welchem Zustand der Aktor zum Zeitpunkt des Stromausfalls gerade ist.
Und genau den will ich wieder herstellen.
Zitat von: Ralph am 02 Januar 2021, 17:25:35
Moin,
ja, davon las ich schon.
Da kann man Ein oder Aus fest einstellen nach Stromwiederkehr.
Meine Frage bezog sich eigentlich auf alle Arten von Aktoren.
Die Schaltsteckdose sollte nur als Beispiel dienen.
Bei batteriebetriebenen Aktoren kann man ja puffern,
bei netzbetriebenen hat man dieses Problem.
Man kann ja nicht vorhersehen, in welchem Zustand der Aktor zum Zeitpunkt des Stromausfalls gerade ist.
Und genau den will ich wieder herstellen.
nunja, wenn die Aktren es nicht können bleibt ja nur eine externe Lösung wie Fhem.
Grundsätzlich ist das auch in mehreren Variationen möglich. Die sauberste erfordert aber ein sauberes herunterfahren vom Fhemserver - eher nicht gegeben bei Stromausfall - da die Zustände sonst verloren gehen ( fhem.save wird nicht geschrieben )
..... ergo ist hier eine USV sinnvoll, dann ist eine Umsetzung kein Problem.
alternativ müsste man jeden schaltzustand eines aktors bei zustandsänderung
sicher speichern (sd, usb etc ) . ist sicher auch machbar, das würde ich aber meinem aktivsystem nicht zumuten wollen, d.H es müsste ein extrasystem sein - teurer als eine USV
aber ob das der Weisheit letzter Schluss ist .... keine Ahnung.
gruss Thomas
Ok, nicht genau genug gelesen...
Trotzdem: die genannten Homematic ("Classic") können nur on/off...
Meine Fibaro/ZWave Steckdosen können auch: remember (nicht getestet aber klingt nach dem was du willst)...
Ansonsten wie geschrieben halt mit fhem-Mitteln.
Macht aber nur Sinn wenn (wie ebenfalls schon geschrieben) fhem weiter läuft...
Gruß, Joachim
Sorry, hatte vergessen zu erwähnen, dass FHEM natürlich USV-gepuffert bei mir 6 Stunden weiterläuft und sodann ordentlich runtergefahren wird.
Mir geht es hauptsächlich um diese kleinen kurzen Stromausfälle auf dem Land tagsüber,
die auch mit Zappelleien elektronische Geräte verwirren.
Genau um die Merk- und Wiederherstellfunktion geht es.
Ich dächte, dass ich das Rad nicht neu erfinden muss.
... beim ESP könnte ich mir eine Lösung über das interne EEprom vorstellen, bei Homematic fällt mir da im Moment auch nicht´s ein.
Kannst du denn einen Stromausfall zuverlässig detektieren?
Zitat von: Christoph Morrison am 02 Januar 2021, 19:39:15
Kannst du denn einen Stromausfall zuverlässig detektieren?
Na klar, sowohl meine USV als auch mein RasPi merken und protokollieren es.
... hab ich bei einigen meiner Projekte oft genug gemacht ... ist das kleinere Problem.
So aus dem Handgelenk:
DOIF, das als Reading den letzten state bestimmter Geräte speichert und auch triggert, wenn der Strom weg ist. Wenn er dann wieder vorhanden ist, DOIF erneut triggern und die gespeicherten state wieder ins Device schreiben.
Weil ich grad mit einem Shelly "rumspiele" (Shelly1) der kann das auch, also sich den letzten Zustand merken und dann wieder so schalten...
Und eben getestet: er macht es tatsächlich ;)
Gruß, Joachim
Hallo Joachim,
mit der Orignal Software oder TASMOTA / ESPEASY ?
LG
Papa Romeo
ok ... hab´s selber gerade getestet.
Bei TASMOTA merkt er sich die Stellung nicht.
Ausser es gibt eventuell über die Konsole Einstellungen dafür ... hab ich jetzt nicht geschaut.
LG
Papa Romeo
Nö Original...
Bei den Shellys lasse ich Original...
...ist für mich ok, weil ja auch damit schon ohne Cloud etc.
Und was ich machen will geht auch damit sehr gut ;)
Außerdem: das ganze WLAN-Zeugs hab ich mehr zum "Rumspielen" ;)
Bzw. wo ich halt einen kleinen, "simplen" Aktor brauche...
Gruß, Joachim
Auch TASMOTA kann den letzten Zustand vor Stromausfall wiederherstellen. Muss man so einstellen (PowerOnState =3, sollte sogar default sein).
https://tasmota.github.io/docs/PowerOnState/
Eine solche Automatik für FHEM ist mir nicht bekannt. Dürfte aber auch nicht so trivial sein.
Im fhem.save nur nachzusehen könnte hilfreich sein nach einem Reboot des Systems, nicht aber nach einem einfachen Spannungsausfall, weil fhem.save dann schon wieder veraltet sein kann.
Nur als Idee: In anderem Zusammenhang verwende ich eine "Automatik", bei der pro Homematik-Aktor ein gewünschter Schaltzustand aus FHEM ermittelt werden kann: jede aus FHEM gewollte Änderung wird mit "Zwischen-state" "set_..." flankiert, worauf man mit einem notify/DOIF reagieren und den gewünschten Zustand in einem Register des Aktors speichern kann. Wenn man nun noch dafür sorgt, dass auch gewollte Änderungen abseits von FHEM (lokal oder per peer) in diesem Register landen, kann man wiederum einen Soll-Ist-Vergleich nach jedem Stromausfall vornehmen - der Sollzustand würde nach einem sauberen Reboot ja auch aus fhem.save rekonstruiert werden. Mit einer Subroutine in 99_myUtils.pm und einer passenden Schleife, die auf das Vorhandensein eines passenden Registers im Aktor achtet, wäre der Job erledigt, wenn man sich zuvor beim Ablegen des Registers auf jene Aktoren beschränkt, bei denen die Wiederherstellung des Zustandes tatsächlich sinnvoll ist.
Zitat von: Pfriemler am 04 Januar 2021, 12:54:33
Auch TASMOTA kann den letzten Zustand vor Stromausfall wiederherstellen. Muss man so einstellen (PowerOnState =3, sollte sogar default sein).
https://tasmota.github.io/docs/PowerOnState/
ok ... kurz nachgeschaut ... PowerOnState steht auf 3
... aber funktioniert definitiv nicht
... schalte Relais auf "ON" ... ziehe den Stecker ... Stecker wieder in die Dose ... Webseite updaten ... Relais steht auf "OFF"
... es ist auch das "klicken" des Relais, das beim "ON schalten" deutlich zu hören ist, nicht zu vernehmen.
... weitere Test´s zeigen ... anscheinend werden alle PowerOnState-Befehle, zumindest bei TASMOTA 7.1.0, ignoriert oder es sind weitere Einstellungen erforderlich.
... werde bei Gelegenheit mal ein Testmodul mit aktuellerem TASMOTA auf diese Sache hin testen
LG
Papa Romeo
Moin,
habe ein wenig gefummelt.
Meine etwas umständliche Lösung, wer es besser kann, der möge es besser kundtun.
Stromnetzüberwachendes Element ist ein FS20-KSE Klingelsignaldetektor,
dem sind 3 Optokopplerschaltungen für 3 Phasen vorgeschaltet. Schaltplan siehe Nachtlichter.
Normal ist der ON, eine Phase oder mehr weg = OFF
defmod U_KSE FS20 ......
attr U_KSE IODev CUL_0
attr U_KSE room Internet
setstate U_KSE on
setstate U_KSE 2021-01-04 15:39:12 state on
Bei Stromwiederkehr sollen die Schaltzustände sowohl von einem HM als auch von IT-Intertechno und FS20 wiederhergestellt werden.
Bei den HM-Aktoren müssen bei Stromausfall der / die Zustände im FHEM gebunkert werden, bei den anderen ist das nicht nötig.
defmod di_RestoreNetz DOIF ([U_KSE:"^off$"]) {my $pre = ReadingsVal("WoZi_TV","state","0");; fhem("setreading WoZi_TV statepre $pre")} DOELSE ([U_KSE:"^on$"]) {my $pre = ReadingsVal("WoZi_TV","statepre","0");; fhem("set WoZi_TV $pre");; my $pre1 = ReadingsVal("IT_V3_1","state","0");; fhem("set IT_V3_1 $pre1");; my $pre2 = ReadingsVal("IT_V3_2","state","0");; fhem("set IT_V3_2 $pre2");; my $pre3 = ReadingsVal("FlurLED","state","0");; fhem("set FlurLED $pre3")}
attr di_RestoreNetz do always
attr di_RestoreNetz room Events
attr di_RestoreNetz wait 0:5 # die Verzögerung ist nötig, da der HM-Aktor erst empfänglich sein muss
defmod WoZi_TV CUL_HM ...
attr WoZi_TV .mId ....
attr WoZi_TV IODev HmUART
attr WoZi_TV IOgrp VCCU:HmUART
attr WoZi_TV autoReadReg 4_reqStatus
attr WoZi_TV expert rawReg
attr WoZi_TV firmware 2.6
attr WoZi_TV model HM-LC-SW1-PL-DN-R1
attr WoZi_TV room Events,RM_HM
attr WoZi_TV subType switch
attr WoZi_TV webCmd on:off
setstate WoZi_TV 2021-01-04 15:39:18 state on
setstate WoZi_TV 2021-01-04 15:37:56 statepre on
defmod FlurLED IT .................................
attr FlurLED IODev CUL_433
attr FlurLED room Events,RM_433
setstate FlurLED on
setstate FlurLED 2021-01-04 15:11:31 group 0
setstate FlurLED 2021-01-04 15:11:31 protocol V3
setstate FlurLED 2021-01-04 15:39:17 state on
Zitat von: Ralph am 04 Januar 2021, 16:21:32
defmod di_RestoreNetz DOIF ([U_KSE:"^off$"]) {my $pre = ReadingsVal("WoZi_TV","state","0");; fhem("setreading WoZi_TV statepre $pre")} DOELSE ([U_KSE:"^on$"]) {my $pre = ReadingsVal("WoZi_TV","statepre","0");; fhem("set WoZi_TV $pre");; my $pre1 = ReadingsVal("IT_V3_1","state","0");; fhem("set IT_V3_1 $pre1");; my $pre2 = ReadingsVal("IT_V3_2","state","0");; fhem("set IT_V3_2 $pre2");; my $pre3 = ReadingsVal("FlurLED","state","0");; fhem("set FlurLED $pre3")}
attr di_RestoreNetz do always
attr di_RestoreNetz room Events
attr di_RestoreNetz wait 0:5 # die Verzögerung ist nötig, da der HM-Aktor erst empfänglich sein muss
vielleicht täusche ich mich, aber es könnte dir das Leben erleichtern, wenn du an der Stelle im DOIF mit einem Template arbeitest (https://wiki.fhem.de/wiki/DOIF/Templates)
Zitat von: kjmEjfu am 04 Januar 2021, 16:30:13
vielleicht täusche ich mich, aber es könnte dir das Leben erleichtern, wenn du an der Stelle im DOIF mit einem Template arbeitest (https://wiki.fhem.de/wiki/DOIF/Templates)
Danke, vermutlich hast Du recht. Habe es angeschaut, verucht zu verstehen, es blieb beim Versuch. Ist mir zu hoch, schade.
Zitat von: Papa Romeo am 04 Januar 2021, 13:56:44
ok ... kurz nachgeschaut ... PowerOnState steht auf 3
... aber funktioniert definitiv nicht
Hast Du evtl. zum Schonen des Flashspeichers SetOption0 generell abgeschaltet?
edit: Nachtrag zur Info: Je eine Gosund SP1 mit Tasmota 8.x und 6.7.1 und ein OBIplug (auch 8.x) restoren einwandwandfrei.
ok, danke für den Tip ...schau ich gleich mal nach, der Shelly hängt noch am Trenntrafo.
LG
Papa Romeo
Zitat von: Pfriemler am 04 Januar 2021, 19:01:02
Hast Du evtl. zum Schonen des Flashspeichers SetOption0 generell abgeschaltet?
... nee .. is "ON"
Und ich dachte immer, in diesem Strag ginge es (nur) um Homematic ?
..stimmt, sehe gerade du hast es unter der Rubrik "Homematic" eingestellt ... sorry hab ich nicht darauf geachtet ... aber bei anderen gibt´s das Problem bestimmt auch ...
also, bin hier dann mal raus ...
LG
Papa Romeo
Zitat von: Ralph am 04 Januar 2021, 16:21:32
Stromnetzüberwachendes Element ist ein FS20-KSE Klingelsignaldetektor, dem sind 3 Optokopplerschaltungen für 3 Phasen vorgeschaltet. Schaltplan siehe Nachtlichter....
Mein nächstes Bastelprojekt :-)
ZitatBei Stromwiederkehr sollen die Schaltzustände sowohl von einem HM als auch von IT-Intertechno und FS20 wiederhergestellt werden.
Also doch nicht nur HM :-) ... aber gut, Tasmota ist nun nicht dabei. Ich konnte nur Papa Romeos Einwand, Tasmota könne den vorherigen Schaltzustand nicht allein wiederherstellen, nicht unwidersprochen stehen lassen, weil ich eben aus der Praxis genau das kenne.
ZitatBei den HM-Aktoren müssen bei Stromausfall der / die Zustände im FHEM gebunkert werden, bei den anderen ist das nicht nötig.
edit: jetzt verstanden. In Deinem Codebeispiel bedienst Du Dich an den letzten Zuständen die FHEM kannte und schickst sie den Geräten. Bei HM funktioniert genau das nicht, weil der Status der Geräte nach Stromwiederkehr aktualisiert wird und der gewünschte Schaltzustand so verlorengeht. Also ist es ein HM-spezifisches Problem.
"Wozi_TV" ist ein HM-Gerät? ja, s.o. im List (facepalm).
Nachtrag: perl "foreach" im normalen DOIF-Ausführungsteil? ungetestet, als Idee (gefundene Fehler dürfen behalten werden)
{foreach my $devicename("IT_V3_1","IT_V3_2","FlurLED") {fhem("set $devicename ".ReadingsVal($devicename,"state","off");} }
ZitatOft möchte man aber den Zustand vor dem Stromausfall haben.
Sprich: der Aktor soll wieder Ein sein wie vorher.
Ist jemandem hier dafür schon eine Lösung eingefallen ?
Anderer Ansatz, als es der Schaltsteckdose zu überlassen:
irgendwelche Bedingungen haben dafür gesorgt, dass fhem die Schaltsteckdose eingeschaltet hat. Nun ist Stromausfall, die Steckdose aus, Strom wieder da, Steckdose bleibt aus, fhem startet neu oder die USV meldet, dass wieder Strom da ist: Jetzt müssen die Bedingungen erneut geprüft werden und die Steckdose wieder so schalten wie sie sein soll (was bei nicht allzu langem Stromausfall vermutlich dem Zustand entspricht wie vor dem Ausfall, und wenns länger dauert und die Steckdose dann eigentlich aus sein soll wird auch das wieder richtig geschaltet). Also eine Art "State-machine"
Viel Erfolg!
für manuell eingeschaltete verbraucher funktioniert das aber nicht ohne weiteres.
Zitat von: frank am 06 Januar 2021, 11:13:07
für manuell eingeschaltete verbraucher funktioniert das aber nicht ohne weiteres.
Doch, sofern sie über die HM-Schaltsteckdose manuell eingeschaltet wurden.
Genau darum geht es hier.
Zitat von: Ralph am 06 Januar 2021, 11:16:43
Doch, sofern sie über die HM-Schaltsteckdose manuell eingeschaltet wurden.
ich meine den vorschlag von @Sany mit der statemachine.
die methode des speicherns der zustände vor dem blackout funktioniert auch nur bedingt für homematic.
alle timer in den aktoren bleiben dabei unberücksichtigt.
beispiel:
ein kurzer druck am device schaltet das device für 10min ein. nach 5min kommt ein blackout von 1min.
jetzt müsste das device eigentlich mit einem on-for-timer 4min nach dem blackout eingeschaltet werden.
Wie man sieht, kann die automatische Wiederherstellung nur eine Krücke sein. An die von frank genannten Fälle mit autark laufenden Timern in Homematic-Geräten habe ich noch gar nicht gedacht. Dass es Timer gibt, kann ja zumindest am Register timedOn gesehen werden. Das ist teilweise sehr wichtig, weil viele meiner Schaltfunktionen tatsächlich so arbeiten, mindestens als Sicherheitsfunktion. Meine Technik ist diesbezüglich noch in keinster Weise "gehärtet", wohl auch weil Stromausfälle bisher hier absolut kein Thema sind (ich kann mich kaum erinnern wann der letzte war). Ich müsste hier für mich auch ganz fallweise entscheiden was und nach welcher Ausfallzeit von den entsprechenden Zuständen überhaupt wiederhergestellt werden müsste. Dabei ist auch nicht gesagt, ob eine Restlaufzeit sinnvoll ist oder ob der Vorgang nicht komplett neu gestartet werden müsste.
Wirklich wichtige Dinge wie etwa ein Homematic-Powermeter, die wirklich immer eingeschaltet werden müssen, damit der Kühlschrankinhalt nicht verdirbt, löse ich ohnehin per powerUpAction.
Ralphs Fragestellung richtet sich aber gezielt auf kurze "Wischer" in der Versorgung. Man kann die automatische Wiederherstellung ja auch zeitabhängig gestalten.
Solche Dinge wie uhrzeit- oder situationsabhängige Schaltungen kann man, geschickte Programmierung vorausgesetzt, bei DOIFs etwa auch gezielt mit einem "set ... checkall" anstoßen, von alleine machen die das aber nicht. Funktioniert natürlich nicht bei eventbasierten Auslösungen.
Insofern ist die gute alte Methode "speichere den Schaltwunsch in einer Variablen und sorge mithilfe deren Überwachung für die richtigen Aktionen" irgendwie die bessere Lösung. Dafür muss dann aber auch ggf. der manuelle Schaltvorgang als Wunsch allda registriert werden.
Moin,
habe nochmal eine Runde weitergespielt.
Zur Erklärung:
im konkreten Fall ging es darum, dass ein Modul HM-LC-SW4-BA-PCB 4-fach Aktor zur Anzeige SCHARF , UNSCHARF , CODEMISSBRAUCH
an der Haustür außen in Verwendung ist und nur mit ON / OFF ohne Timerschnickschack, dass das Modul eh nicht kann, arbeitet.
Nach (mehrfachen) Stromausfällen steht man außen vor der Tür und ist blind, weil das Modul ja im OFF-Zustand ist. ! WAF !
Ziel (bei diesem Projekt) ist es, die Anzeige wiederherzustellen.
Und das geht (nur geprüft für dieses Model) noch einfacher als gedacht, nämlich
defmod HM-LC-SW4-BA-PCB CUL_HM ......
attr HM-LC-SW4-BA-PCB IODev HmUART
attr HM-LC-SW4-BA-PCB IOgrp VCCU:HmUART
attr HM-LC-SW4-BA-PCB model HM-LC-SW4-BA-PCB
# Gruppe:
# HM-LC-SW4-BA-PCB,
# HM-LC-SW4-BA-PCB_Sw_01,HM-LC-SW4-BA-PCB_Sw_02,HM-LC-SW4-BA-PCB_Sw_03,HM-LC-SW4-BA-PCB_Sw_04
setstate HM-LC-SW4-BA-PCB 2021-01-06 19:57:01 timedOn off # trigger Chip StromWiederkehr
defmod HM-LC-SW4-BA-PCB_Sw_01
defmod HM-LC-SW4-BA-PCB_Sw_02
defmod HM-LC-SW4-BA-PCB_Sw_03
defmod HM-LC-SW4-BA-PCB_Sw_04
defmod wd_HM-LC-SW4-BA-PCB watchdog HM-LC-SW4-BA-PCB:timedOn:.off 00:00:07 SAME {foreach my $dev("HM-LC-SW4-BA-PCB_Sw_01","HM-LC-SW4-BA-PCB_Sw_02","HM-LC-SW4-BA-PCB_Sw_03","HM-LC-SW4-BA-PCB_Sw_04") {my $pre = ReadingsVal($dev,"state","0");; fhem("set ".$dev." ".$pre);;} }
attr wd_HM-LC-SW4-BA-PCB autoRestart 1
Alles andere voher von mir angesprochene sind nur Randschauplätze.
Viel Vergnügen damit und bis neulich ...
Hm ...ich steige da gerade nicht durch.
Ein HM-LC-SW4-BA-PCB hat im Device kein timedOn. Man kann es manuell setzen, ok. Das machst Du offenbar mit der Stromwiederkehr und das soll ein Event erzeugen, was dann den watchdog triggert und nach 7 Sekunden den noch in FHEM bekannten Status des Aktors kurzerhand als Schaltbefehle an diesen sendet. Wenn das vor der automatischen Statusmeldung des Batterieaktors passiert, kann das klappen, aber sendet der nicht auch einen "Status nach Stomausfall"?
BTW:
Die (Unter/Schalt-)Kanäle können natürlich auch mit Timern arbeiten, mutze ich ja hier ständig im Sommer bei der Beregnung (die Timer geben eine maximale Beregnungszeit vor, je nach Situation wird von FHEM vorher abgeschaltet - hier wäre es sehr fatal, wenn sie nach einem Stromausfall auf Dauer-Ein gingen ...).
Und jetzt kommt die Hardwarelösung des Problems (SCNR :-)):
Der HM-LC-Sw(x)-BA-PTB (gilt gleichermaßen für die 4- und 1-Kanal-Variante) ist so wunderbar sparsam im Betrieb, dass man das Modul allein problemlos längere Zeit von einer Pufferbatterie betreiben kann. Also das Durchschalten der Anzeigen erfolgt ja von einer (Netz-)Versorgung durch die Anzeigen (LED?/Lampen) über die MOSFETs des Aktors nach GND, vermutlich ist die Stromversorgung des Moduls ebenso an der Signalisierungs-Versorgung angeschlossen. Wenn man das jetzt über eine Diode führt und als zweiten Versorgungszweig eine Pufferbatterie mit geringer Spannung nimmt (ebenfalls mit Entkopplungsdiode), dann würde bei einem Stromausfall das Modul von der Pufferbatterie weiterlaufen - die Anzeigen sind freilich so lange aus. Wenn man ledMode auf off setzt (also keine Anzeige des Schaltzustandes mit den onboard-LEDs), dann läuft der Aktor auch mit eingeschalteten Kanälen locker Wochen (wenn nicht gar Monate) weiter, weil die MOSFETs praktisch keine Energie im Ein-Zustand ziehen. Lediglich die 100k am Gate stellen eine Dauerlast dar.
So wird das Modul jedenfalls nie stromlos und vergisst auch keinen Status. Die Anzeigen leuchten nach Stromwiederkehr ohne jedes Zutun wieder auf.