Hallo zusammen,
ich habe ein kleines Problem. Meinen Rolladen öffne ich schichtabhängig, zu verschiedenen Zeiten. 2 Dummys dienen der Zeiteinstellung, Derzeit durchsucht Automate meine Handykalender nach der nächsten Schicht, und setzt per http request eine lightscene. Diese lightscene ändert mit modify die Zeit im at. Soweit funktioniert das auch, allerdings werden zwecks backups, nachts alle services beendet und wieder gestartet, also fhem, apache2 u.a. Nach dem Neustart ist das at dann verschwunden. Ich hab es schon mit verschiedenen Namen versucht, bringt aber nichts. Kennt jemand sowas bzw. weiß abhilfe?
Was heißt "ist dann verschwunden?" Ein einmal auszuführendes at verschwindet nach dessen Ausführung immer.
Works as designed.
aber z.b at *8:00 sollte heden tag um 8:00 uhr triggern. Selbst at 8:00 sollte um 8:00 uhr triggern und nicht um 2:00 nachts nachbeinem neustart weg sein.
Hi,
nach einem define bla at *8:00 {} steht das at in der aktiven config. Nach einem modify steht das modifizierte at in der aktiven config.
Es steht beides nicht in der gespeicherten config. Erst nach einem save steht es dort.
Gruß Otto
Ich habe jetzt mal versucht, den Umweg über die LightScene wegzulassen, dazu müsste ich aber per http request den dummy state auslesen.
https://url.zu.fhem:port/fhem&cmd.dummy=dmy_rolloSZ_open%20state&XHR=1
liefert mir aber 200 statt 8:00
Den state eines dummy per http auslesen? Weiß nicht ob es etwas besseres gibt, aber ich würde das per list dummy state machen.
Und wenn Du FHEM die Geschichte machen lässt und den Kalender per Modul Calendar in FHEM einbindest?
@Otto123: Ich hatte das die ganze Zeit problemlos am Laufen, da stand in der LighScene
modify set_rolloSZ_open *13:00 Uhr
So ging das Problemlos auch ohne save hat das at den Neustart übelebt.
Der Code ist jetzt so abgeändert, dass ich die Zeiten mit Dummies frei definiere und beim modify die values genutzt werden.
modify set_rolloSZ_open *{dmy_rolloSZ_open("state"),""}
Ich hatte das damals mit Google Kalender probiert und hatte massive Probleme. Habe jetzt Google verlassen und nutze einen eigenen Nextcloud Server dafür. Wenn ich mal ausreichend Zeit habe wäre das sicher eine Option, Fhem das machen zu lassen.
Edit: list dummy state liefert mir
dmy_rolloSZ_open 2019-04-08 17:00:16 8:00
Wie bekomme ich da nur 8:00?
Ich denke, Du hattest lange kein Update gemacht. Du hattest irgendeine save Routine / Autosave Einstellung - die jetzt nicht mehr funktioniert. Siehe auch hier https://forum.fhem.de/index.php?topic=92793.0
Ich habe keine Ahnung wo Du überhaupt diesen HTTP Request absetzt und in welcher Umgebung Du aus der list Ausgabe die Zeit extrahieren willst. Für Windows Powershell könnte ich es Dir sagen :)
Aber am Ende ist die Antwort ein Array mit Leerzeichen getrennt. Also Ein split und das vierte ( Arrays zählen meist von 0 also Nummer 3 )
wäre es :)
Wenn Du hier nach Nextcloud und Calendar suchst findest Du bestimmt Hinweise für die Umsetzung. Ich mache alles mit Google Kalender und bin auf der gegenüberliegenden Seite von "massive Probleme". Ich denke die Problem sitzen 50 cm vorm Bildschirm ;D
Gute Nacht
Otto
Autosave war auf 1, Updates mache ich schon 1x im Monat mindestens. Kann ich per Script, http request oder über ein at direkt aus fhem ein save ausführen?
Ja und das müsstest Du in deinem Fall auch. Sonst kommt das define des at *8:00 nicht in die config.
Übrigens anders als ein at 8:00 - das wandert in den statefile und da der beim shutdown automatisch gesichert wird, überlebt der auch einen Neustart. ;)
Ouch, hab grad gesehen, dass unter global autosave deaktiviert war. Ich hatte in meinem Leichtsinn unter autocreate geschaut... Soviel zum Thema 50cm vor dem Bildschirm :D
Ich werde aber trotzdem, in dem Script welches fhem stoppt, verwuchen save auszuführen.
*Popcorn*
Leider zu früh gefreut. Sobald das at durch die LightScene modifiziert wird, ist es nach einem Neustart von fhem nicht mehr da.
global autosave=1, und mit
perl fhem.pl 7072 save
gespeichert
Ich habe nochmal etwas rumgespielt. Wenn ich das at anlage, und über die LightScene mit modify *Uhrzeit modifiziere, geht es trotz autosave und speichern per script verloren.
Lasse ich den * weg bleibt es erhalten.
Allerdings löscht es sich ja quasi selbst, nachdem es getriggert hat. Wenn ich dann also abends den Kalender durchsuche und die Rollo Auf Zeit anpassen will, ist das at nicht mehr da.
Mittels der LightScene ein define at *Uhrzeit funktioniert aber scheinbar nicht (oder ich check nicht wie). Alles sehr merkwürdig zumal das ja einige Zeit lang problemlos ging, also das at mit *Uhrzeit aus der LightScene heraus modifizieren und nach dem neustart noch da...
Ich glaube fast, das liegt an der LightScene. Denn ich habe noch andere at, die ich mit einem notify ändere, die bleiben auch ohne autosave und save befehl erhalten.
Mein letzter Versuch, mach mal
{qx(grep save fhem.cfg)} in der FHEM Kommandozeile und poste die Ausgabe.
Vielleicht sieht man da was.
Und ich zitiere nochmal Rudi
ZitatZur Klarstellung:
- es geht um save, was von einem Programmstueck wie at/notify/etc gestartet, und nicht per Anklicken oder anderweitig manuell ausgeloest wird.
- autosave 0 verhindert in diesen Faellen das Speichern.
- autosave wird neuerdings auf 0 gesetzt, falls beim Starten was schiefgegangen ist, damit ein automatisches save (wie manche Module das ungefragt machen) nicht zum Verlust der Teile der Konfiguration fuehrt.
Gruß Otto
Also, irgendwie hat sich attr global autosave immer wieder selbst auf 0 gesetzt. Ich habe das Attribut gelöscht und neu gesetzt, trotzdem ist es wieder auf 0.
Hier die Ausgabe von {qx(grep save fhem.cfg)}:
attr global autosave 0
./log/fhem.save: set_rolloSZ_open already defined, delete it first\
Autosave deactivated
attr global statefile ./log/fhem.save
attr autocreate autosave 1
Wie gesagt global autosave habe ich auf 1 gesetzt und danach per klick auf save gespeichert. Dann das at per LightScene mit modify at verändert, dann neu gestartet.
Entgegen dem hinweis set_rolloSZ_open sei bereits vorhanden, ist es nicht vorhanden.
Lege ich das at frisch an und starte fhem neu, bleibt es vorhanden. Das Verschwinden geschieht immer erst nach dem modify, nicht aber wenn die Zeit durch ein notify geändert wird.
Naja alles klar, denke ich. Steht ja offenbar alles im Klartext in deiner motd Nachricht: ;)
- autosave wird neuerdings auf 0 gesetzt, falls beim Starten was schiefgegangen ist,
./log/fhem.save: set_rolloSZ_open already defined, delete it first\
Autosave deactivated
Es ist was schiefgegangen. ::)
Gruß Otto
Ich habe es jetzt so umgangen, dass ich statt das at mit LightScene zu modifizieren, einen 3. Dummy und ein DOIF verwende.
Wie bisher wird die LightScene auf die entsprechende Schicht gesetzt, das DOIF ließt dann den jeweiligen Dummy für Nachtschicht oder nicht Nachtschicht aus, und überträgt den state an den 3. Dummy.
Auf dessen Änderung lauscht ein Notify welches dann entsprechend die Zeit (mit *) ändert. Da Autosave trotzdem immer wieder auf 0 springt, habe ich in meinem backup-script, bevor ich fhem beende noch den save Befehl eingefügt.
Mehrfache Tests ergaben ein positives Ergebnis, das at bleibt erhalten, die Zeiten werden auch nach dem Neustart behalten, alles so wie es soll (scheinbar - vorerst :D)
P.S. wandelt fhem denn intern ein modify in ein define um? Ein define set_rolloSZ_open wird eigentlich ja nicht abgesetzt, device ist defined und gespeichert, wird mit modify geändert...
Oh man, jetzt wird mir das ganze glaub ich klar:
Ich hab dem keine Bedeutung bei gemessen, aber nach einem Neustart von fhem setze ich mittels notify alle LightScenes auf ihre letzte Werte. Da kam immer die Fehlermeldung
das die Funktion {ReadingsVal("dmy_rolloSZ_open","state","")} eine timespec zurückgeben muss und keinen leeren string (warum zu dem Zeitpunkt leer war-keine Ahnung, sobald ich in die GUI sehen konnte war der Wert da und wurde ab da auch richtig genutzt). Dadurch hat es dann natürlich das autosave auf 0 gesetzt und mein at war weg.
Ich schiebe das mal auf 4 Tage Nachtschicht mit je 8 Stunden S7Graph und KOP/AWL :D
Ich habe noch ein kleines AddOn. Stand mal irgendwo hier im Forum, ist also nicht von mir.
define c_grep cmdalias grep .* AS {qx(grep -i \'$EVENT\' *.cfg FHEM/99*.pm)}
Falls man nach einem Stichwort in seiner Konfiguration suchen will - hilft mir ziemlich oft :)
Gruß Otto