NAS kurz vor TV-Aufnahme starten

Strampi5 · 11 September 2019, 22:20:11

Gelesen habe ich das wobei nicht richtig verstanden, da ich die beiden Begriffe vertauscht/vermischt habe.

Aber nochmals vielen Dank für deine Geduld!!!!

Nun habe ich die at Funktion noch in ein Notify gepackt und sobald ein neuer Timer gesetzt wird, erzeugt FHEM ein at mit dem Namen ENIGMA2NAS um das Nas zur bestimmten Zeit aufzuwecken. Nun muss ich mich nur noch mit der Namensgebung des at spielen.

Falls jemand am fertigen Def interessiert ist

Code Auswählen

defmod ENIGMA2NAS_WOL notify ENIGMA2:recordings_next.* {my $time=ReadingsVal("ENIGMA2","recordings_next","")-3*60;;fhem("define ENIGMA2NAS at $time set WOLOMV on")}

Otto123 · 11 September 2019, 22:40:59

Ich habe den Wiki Artikel nochmal anders strukturiert. Vielleicht ist es so besser?

Strampi5 · 12 September 2019, 06:52:12

Danke sieht gut aus. Ich glaube so ist es leichter als wenn es nur in Stichworten steht.

Edit:

Ist es eigentlich möglich das at auch mit einem dynamischen Namen zu definieren

in etwa so?

Code Auswählen

ENIGMA2:recordings_next.* {(my $name=ReadingsVal("ENIGMA2","recordings_next_name",""));;(my $time=ReadingsVal("ENIGMA2","recordings_next","")-3*60);;fhem("define $name at $time set WOLOMV on")}

Ich bekomme keine Fehlermeldung, leider passiert auch nichts.

Otto123 · 12 September 2019, 22:29:40

Der Ansatz ist richtig, die Umsetzung erstmal problematisch: Beispiel aktuell:
{(my $name=ReadingsVal("VUPLUS1","recordings_next_name",""))}
ergibt
SOKO Wien

Damit kann define $name at nichts anfangen. Ich habe keine spontan Idee außer zu sagen: so geht es nicht.

Gruß Otto

Strampi5 · 12 September 2019, 23:40:45

Hmm. Das Problem liegt darin: wenn einmal ein at definiert ist und ich einen !früheren! Timer setzte wird das at nicht verändert. Somit müsste ich das at immer löschen wenn eine frühere Aufnahme gestartet werden soll damit es später neu angelegt werden kann.

Ev könnte man noch ein zusätzliches notify machen welches die Triggerzeit des at korrigiert. Aber das ist ja auch mit der Kirche ums kreuz

Strampi5 · 12 September 2019, 23:44:33

Oder könnte es funktionieren wenn man die Leerzeichen entfernt bzw nur Buchstaben zulässt? Das sollte ja in Pearl mittels eines Filter oä machbar sein. Der Sinn hinter dem ganzen ist ja lediglich, das mehrere Timer erstellt werden können welche sich im Namen unterscheiden

Otto123 · 13 September 2019, 09:13:07

Und wenn Du das at anstatt mit define mit defmod erzeugst? dann wird doch einfach überschrieben und bei Bedarf neu angelegt.

MadMax-FHEM · 13 September 2019, 09:40:47

Zitat von: Otto123 am 13 September 2019, 09:13:07
Und wenn Du das at anstatt mit define mit defmod erzeugst? dann wird doch einfach überschrieben und bei Bedarf neu angelegt.

Lese ja fleißig mit

Da habe ich auch schon dran gedacht.
Aber was, wenn er mehrere Aufnahmen plant.
Die muss/will er auseinanderhalten!?

Andere Frage: "wer" schaltet "wann" das NAS wieder aus?

Bei autom. aus (habe ich auch, ein Script prüft, ob NAS [noch] benötigt wird und wenn nicht: fährt es runtet) musst du aber auch prüfen, dass nicht demnäxt (paar minuten/sekunden) eine Aufnahme starten soll, sonst könnte es passieren:

NAS fährt runter
WOL für nächste Aufnahme (läuft aber "ins Leere", weil NAS ja noch läuft aber halt schon "plant" runterzufahren

)
NAS bleibt aus...

Musst du die at "identifizieren" können (verm. wenn eins geändert werden soll) ansonsten: einfach an ein Prefix Datum/Uhrzeit im Unixformat dranklatschen...

Oder einfach Namen mit Nummern und dann in Arrays oder Hash: Zuordnung von at-Nummer zu Sender/Aufnahme bzw. ja andersrum

Gruß, Joachim

Otto123 · 13 September 2019, 10:22:11

Zitat von: MadMax-FHEM am 13 September 2019, 09:40:47
Aber was, wenn er mehrere Aufnahmen plant.
Die muss/will er auseinanderhalten!?

Dieser Part sollte eigentlich funktionieren, aber man müsste sich vielleicht mal ein Bild durch ein Log machen.
Das Reading enthält ja immer nur die nächste Aufnahme, d.h immer wenn es aktualisiert muss das das at gemacht/aktualisiert werden.
Mehrere Aufnahmen handelt ja die Timerliste des Receivers, da muss man sich hier nicht kümmern, nur die nächste ist relevant und die kann sich aber auch ändern.
Und wenn er mal WOL schickt und die NAS läuft schon ist ja nicht so schlimm

MadMax-FHEM · 13 September 2019, 10:41:16

Zitat von: Otto123 am 13 September 2019, 10:22:11
Dieser Part sollte eigentlich funktionieren, aber man müsste sich vielleicht mal ein Bild durch ein Log machen.
Das Reading enthält ja immer nur die nächste Aufnahme, d.h immer wenn es aktualisiert muss das das at gemacht/aktualisiert werden.
Mehrere Aufnahmen handelt ja die Timerliste des Receivers, da muss man sich hier nicht kümmern, nur die nächste ist relevant und die kann sich aber auch ändern.

Außer: er löscht eine geplante Aufnahme...
Dann sollte er das at ja wiederfinden können und auch löschen!?

Oder der Termin einer geplanten Aufnahme ändert sich kurzfristig -> Sondersendung wegen Katastrophe o.ä. vorher

Dann muss das at ja vielleicht angepasst werden...
...gut der Fall ist nicht so schlimm, läuft das NAS halt etwas früher los

AUSSER: die autom. Auschaltlogik des NAS (sofern vorhanden) erkennt, dass (noch) gar keine Aufnahme läuft/aktiv ist und fährt dann runter...

Zitat von: Otto123 am 13 September 2019, 10:22:11
Und wenn er mal WOL schickt und die NAS läuft schon ist ja nicht so schlimm

Oh, Otto!

Nicht genau genug gelesen (oder nicht genau genug geschrieben)...
...schon klar, dass wenn es schon läuft und ein WOL kommt das nichts macht...

ABER (ja der Zeitstreifen ist sehr gering aber gegeben! Murphys Law wird aber mindestens 1x zuschlagen

): das NAS fährt grad runter und der WOL kommt für die nächste Aufnahme -> da fährt das NAS einfach weiter runter und nix mehr hoch (weil der WOL schon durch ist im "falschen" Moment)...

Ja, ich weiß: sehr konstruiert...
...ich mache autom. Backups auf's NAS und vom NAS selbst.
Ich fahre mein NAS bei nicht Nutzung (Script erkennt das) runter und da hatte ich das schon mal

Daher ja die Frage: wie/wo/wer schaltet das NAS denn wieder aus....

Gruß, Joachim

Strampi5 · 13 September 2019, 16:09:01

Das Defmod das at überschreibt wusste ich nicht. Das wäre dann als Lösung ja bereits ausreichend.

ZitatDa habe ich auch schon dran gedacht.
Aber was, wenn er mehrere Aufnahmen plant.
Die muss/will er auseinanderhalten!?

Andere Frage: "wer" schaltet "wann" das NAS wieder aus?

Bei autom. aus (habe ich auch, ein Script prüft, ob NAS [noch] benötigt wird und wenn nicht: fährt es runtet) musst du aber auch prüfen, dass nicht demnäxt (paar minuten/sekunden) eine Aufnahme starten soll, sonst könnte es passieren:

Mehrere Aufgaben planen geht eigentlich nicht (also in FHEM) da der Receiver nur die nächste Aufnahme als Reading ausgibt. Man könnte natürlich mit der am weitesten in der Zukunft liegenden Aufnahme anfangen, "at" erstellen, dann die Aufnahme davor, "at" erstellen usw. Die Benennung wäre eben nur deswegen nötig, da das "at" mit define nicht überschrieben wird.

Das NAS (OpenMediaVault) schaltet sich selbst bei Nichtbenützung aus. Eigentlich greife ja nur ich darauf zu und sonst niemand. Also ist das NAS ja definitiv ausgeschaltet wenn ich nicht zu Hause bin. Natürlich ein paar konstruierte Möglichkeiten fallen mir schon ein wo das WOL ins leere fährt.
Wenn dem NAS das gelingt, dann darf es auch schlafen gehen und muss nicht mehr weiter arbeiten

.

Ne Spaß bei Seite, es ist ja nur eine Fernsehaufnahme und sowas mache ich eigentlich ja auch nur relativ selten.

Und in dem Fall das eine Aufnahme gelöscht wird bleibt das "at" ja bestehen. Hier könnte man ev ein notify einrichten welches das "at" löscht, sobald "recordings_next" leer ist.

MadMax-FHEM · 13 September 2019, 16:31:00

Dass das Modul nur immer die nächste Aufnahme "verwaltet"/"anzeigt" hat doch mit meinem beschriebenen "Mechanismus" nichts zu tun

Aktuell legst du ein at an, wenn eine neue Aufnahme angelegt wird!?

Wenn du immer denselben Namen nimmst und defmod, dann änderst du ja immer dasselbe at -> ergo nur eine Aufnahme bzw. wird das NAS nur für die letzte angelegte Aufnahme gestartet...
...außer es ist zufällig die zeitlich erste und das NAS läuft einfach durch (kommt halt auf den "Ausschaltmechanismus" an)...

Wenn du das so machen würdest wie vorgeschlagen ("schlimmstenfalls" in einem Dummy

), also Infos zur Sendung (zum "Wiederfinden") und einen jeweils neu generierten Namen für ein at in Arrays oder hashes speicherst, dann kannst du auch geplante Aufnahmen (und zugehörige "Anschaltzeiten" des NAS) wiederfinden, löschen und ändern.

Also eine simple eigene "Verwaltung"

Habe ich also vom Prinzip her zur "Umsetzung" von Sendernamen auf Kanalnummern...
...also ein Array mit den Sendernamen (das wäre dann das Array mit den Sendungsinfos) und ein Array mit den Kanalnummern (das wären bei dir dann die zugehörigen at)...

Wenn ich dann einen Kanalnamen (von Alexa

) genannt bekome, suche ich im SendernamenArray nach dem Sendernamen und mit dem Index weiß ich dann aus dem KanalnummernArray welche Kanalnummer dazu gehört

Aber wenn immer eine geplante Aufnahme reicht und du mit dem defmod zum "Anpassen" des at schon zufrieden bist...

Gruß, Joachim

Strampi5 · 13 September 2019, 16:54:46

Ich glaube ich habe das etwas unverständlich beschrieben. Das ENIGMA2 Modul gibt mir immer nur die zeitlich nächste Aufnahme aus. Somit wird das "at" angelegt sobald sich der Wert der zeitlich nächsten Aufnahme "recordings_next" ändert. Lege ich eine weitere Aufnahme z.B. für den nächsten Tag an, bleibt das "recordings_next" dasselbe und das "at" bleibt so lange bestehen, bis das Event ausgelöst wurde.

Code Auswählen

 2019-03-30 19:43:45   recordings_error 0
     2019-09-11 21:12:47   recordings_finished 4
     2019-09-13 16:47:07   recordings_next 0
     2019-09-13 16:47:07   recordings_next_counter 0
     2019-09-13 16:47:07   recordings_next_counter_hr -
     2019-09-13 16:47:07   recordings_next_hr -
     2019-09-13 16:47:07   recordings_next_name -
     2019-09-13 16:47:07   recordings_next_servicename -

Das sind sämtliche Attribute über die Aufnahmen. Damit kann ich so wie so nur ein einzelnes "at" verwalten, außer ich programmiere die Aufnahme von chronologisch von der am weitesten in der Zukunft liegenden bis zur zeitlich nächsten.

ODER ich habe nicht verstanden was du gemeint hast

Das mit passenden Namen zur Aufnahme macht das ganze natürlich ansehnlicher, ist für mich jedoch irrelevant da es ja eh nicht so viele Aufnahmen gibt. Und ehrlich gesagt kann ich das auch nicht aus dem Stehgreif, da ich mit Perl eigentlich nichts am Hut habe. Somit kümmere ich mich erst um andere Sachen bevor es ans "aufhübschen" geht.

Ich habe nun ein zusätzliches DOIF erstellt welches ein ev. angelegtes "at" löscht, wenn mal eine Aufnahme korrigiert wird. Das kann man bestimmt auch mit einer if ... else ... Funktion im ersten Notify inkludieren.

MadMax-FHEM · 13 September 2019, 17:11:12

Vermutlich nicht verstenden was ich meinte

Also du legst eine Aufnahme an: Reading recordings_next ändert sich!? -> Notify wo du ein at anlegst!? Bzw. (neu) mit defmod immer wieder dasselbe anlegst/änderst!?

So der aktuelle plan!?

Meine Idee:

das notify legt/modifiziert nicht nur das at sondern sucht, ob es schon ein at zu der Sendung gibt (Array Sender/Aufnahme-Info).
Wenn ja, wird das dazu gehörige at (gleicher "index" in dem Array für at) entsprechend modifiziert (oder gelöscht, wenn man im notify oder bei Enigma [kenne ich nur dem Namen nach

] feststellen kann, dass die Aufnahme gelöscht wurde).

Dieser Teil, also das mit vorher oder "generell" suchen etc. ist "optional" und nur falls du geplante Aufnahmen (und zugehörige Einschaltzeiten des NAS) verändern oder löschen willst...

Wenn es noch kein at bzw. keine Info zu Sendung/Aufnahme gibt, wird eben in das Array mit Senderinfos ein neuer Eintrag erzeugt und ein neues at angelegt (dazu kann man auch gleich defmod nutzen) und der Name das at halt einfach atEnigmaAufnahmen PLUS aktuelle DatumUhrzeit im Unix-Format (ist ja nur eine Zahl) "hinten dran geknallt" (Prefix ist nat auch optional macht aber eine "Zurdnung" bei list TYPE=at einfacher/möglich

)...

Damit sind in den Arrays die Aufnahmeinfos und zugehörigen at zu finden/"verwaltet"...
...wenn man das in einen Dummy schreibt kann man sich das sogar anzeigen lassen

Wenn nun das at auslöst, wird nicht nur das NAS gestartet sondern eben auch die zugehörigen Einträge in den Arrays (und/oder Dummy) gelöscht...
...sonst läuft ja irgendwann die "Liste" voll

Aber wie geschrieben: ist mir beim (Mit)Lesen hier nur so durch den Kopf gegangen

Gruß, Joachim

Strampi5 · 13 September 2019, 22:04:18

Hier mal meine Konfiguration

Code Auswählen

defmod ENIGMA2NAS_WOL notify ENIGMA2:recordings_next_hr.* \
{(my $time=ReadingsVal("ENIGMA2","recordings_next","")-3*60);;;;fhem("defmod ENIGMA2NASTimer_WOL at $time set WOLOMV on")}

erzeugt das notwendige "at"

Code Auswählen

defmod ENIGMA2NASTimer_delete DOIF ([ENIGMA2:recordings_next] == 0)\
{fhem "delete ENIGMA2NASTimer_WOL"}\

löscht ein "at" wenn die Aufnahme am Receiver wieder gelöscht wird. "recordings_next" hat dann den Wert 0.

Zitatdas notify legt/modifiziert nicht nur das at sondern sucht, ob es schon ein at zu der Sendung gibt (Array Sender/Aufnahme-Info).
Wenn ja, wird das dazu gehörige at (gleicher "index" in dem Array für at) entsprechend modifiziert (oder gelöscht, wenn man im notify oder bei Enigma [kenne ich nur dem Namen nach ] feststellen kann, dass die Aufnahme gelöscht wurde).

Dieser Teil, also das mit vorher oder "generell" suchen etc. ist "optional" und nur falls du geplante Aufnahmen (und zugehörige Einschaltzeiten des NAS) verändern oder löschen willst...

Bei dem Zitat blicke ich noch immer nicht ganz durch wie das funktionieren soll. (Array und Zuordnung ist mir prinzipiell schon klar). Ich weiß nur nicht wie man die "Liste" befüllen soll. Es könnten nur mehrere "at" angelegt sein wenn man in verkehrt chronologischer Reihenfolge (heißt das wirklich so?) die Timer programmiert.

Angenommen es gibt einen Timer für 16:00 Uhr. Dann steht in recordings_next: 16:00 Uhr. Für Timer die nach 16 Uhr programmiert werden gibt es kein Reading. Natürlich würde eine Liste entstehen wenn der Timer der am weitesten in der Zukunft liegt als erstes programmiert wird, aber wer macht das schon? Und ich glaube dass es auch nur alle 30 Sekunden eine Aktualisierung der Readings gibt. Somit müsste man die Timer auch relativ "langsam" anlegen.

Somit würde die Liste in einem Großteil der Fälle nur aus einem Eintrag bestehen.

Bitte nicht steinigen falls ich deine Idee noch immer nicht durchschaut habe.