FHEM und Perl 5.16.0 inkl. SSL auf Synology DiskStation / RackStation

[Martin Fischer]

Hi @all,

für alle Interessierte habe ich eine neue Release von FHEM für Synology
DiskStation / RackStation bereitgestellt. Neben den notwendigen Kernel-
Treibern (cdc-acm, ftdi_sio, pl2303, usbserial) für diverse Hardware wie z.B.
CUL, FHZ1000, FHZ1300, 1-Wire Busmaster, TUL, u.a., stelle ich auch ein Paket
mit Perl 5.16.0 inkl. OpenSSL Unterstützung (Extra Paket) zur Verfügung.

FHEM selbst steht in zwei Varianten zur Auswahl:

Einmal mit Abhängigkeit zu den Kernel-Treibern zum Einsatz auf DiskStation /
RackStation mit Marvell 6281 / 6282 Chipsatz.

Und zum Zweiten eine "noarch" Version, die auf allen anderen DiskStation /
RackStation ohne Marvell Chipsatz zum Einsatz kommen kann. Hierfür stelle ich
allerdings keine aktuelle Perl-Version sowie Kernel-Treiber zur Verfügung.

Alle Pakete lassen sich auf einer unmodifizierten DiskStation / RackStation
installieren. Es besteht keine Abhängigkeit z.B. zu Optware!

Durch die neue Perl-Version werden alle zur Zeit von FHEM genutzten Module
voll unterstützt. Evtl. vorher installierte Pakete von FHEM, Perl und Kernel-
Treiber sollten komplett deinstalliert werden, da ich neben der Versionierung
auch einige interne Routinen geändert habe. Die Wartezeit beim Upload
(besonders bei Perl) ist normal: es handelt sich um einen HTTP-Upload und das
dauert bei ca. 22 MByte (Perl Modul) nun mal etwas Also Geduld!

Mehr dazu unter:
http://www.fischer-net.de/hausautomation/fhem/47-fhem-mit-perl-5-16-0-auf-synology-diskstation.html

Gruß Martin

P.S.:
Da es nach wie vor Probleme seitens des DSM 4.x von Synology beim Upload
mittels Firefox / Chrome gibt (Upload hängt in Endlosschleife), müssen die
Pakete als Work-around mit einem Internet Explorer hochgeladen werden. Dies
ist _kein_ Problem mit meinen Paketen, sondern hängt vermutlich mit einem
fehlerhaften Flashplugin der Browser zusammen. Lösungsvorschläge hierzu sind
willkommen!

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[borsti67]

                                                 

Moin zusammen,

ich wollte mich demnächst einmal der Nutzung des Kalender-Moduls widmen.
Das Einbinden hat geklappt, schon mal viel wert.

Dann habe ich ein Test-Event angelegt und mir angeschaut, was so im
Event-Monitor passierte. Dabei fiel mir auf, dass die Events jeweils
nicht (exakt) zur geplanten Zeit ihren Mode-Change bekommen, sondern den
Status ausschließlich beim Kalender-Update ändern. Je genauer ich also
den Schaltpunkt brauche, um so öfter muss ich den Kalender aktualisieren
lassen. Ist das richtig, oder habe ich was falsch gemacht? Wenn richtig,
ist das dauerhaft so beabsichtigt, oder gibt es ggf Planungen, die
Events z.B. - sobald erkannt - mittels AT-Befehlen genauer zu verarbeiten?

Die nächste Frage bezieht sich auf die optimale Auswertung.
In den generierten Events steht ja nur die Kalender-Event-ID drin, den
Titel muss man sich bei Bedarf erst noch dazu holen.
Nun verstehe ich die Idee der Kalendersteuerung (ganz besonders, so
langesich wiederholende nicht implementiert sind) doch eher so, dass ich
in meinem Kalender Ereignisse eintrage mit einem speziellen Titel,
aufgrund derer FHEM dann etwas erledigt. Die ID dazu will ich
logischerweise nicht erst manuell heraussuchen, um dann ein spezifisches
Script zu schreiben - dann bräuchte ich den Kalender nicht.

Meine logische Schlussfolgerung ist, dass ich ein Notify brauche,
welches einfach nur auf Kalender-Start und -End-Ereignisse lauscht und
die entsprechende ID dann vorzugsweise an ein Modul gibt. Dieses
wiederum holt sich den Titel dazu, wertet die Stichworte aus und löst
ggf die Funktionen aus.
Ist das korrekt? Wenn ja, hat da schon einer was, worauf ich aufbauen
kann? Oder denke ich viel zu weit um die Ecke, und es ginge viel einfacher?

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[borsti67]

                                                 

Hallo Boris,

> Bist Du sicher, daß es bei Dir nicht klappt? Dann bräuchte ich ein einfaches
> generisches Beispiel, um es nachzustellen.

Ich hatte folgendes ausprobiert (der Kalender wird mit
Standard-Einstellungen geladen):
- ich habe ein Test-Event eingetragen mit Beginn 06:40 und Ende 06:42
- um ca. 06.38 habe ich den Kalender manuell aktualisieren lassen und
danach den Monitor gestartet
- um 06:40 rasselten die Start-Einträge durch
- bis 06:45 kam nichts, dann habe ich manuell aktualisiert, um mir die
generierten Ereignis-Zeilen zur späteren Auswertung abzuspeichern
(wobei ich in der Eile Datei dann doch ohne SAVE geschlossen habe -
man sollte sowas nicht "noch mal eben" vor der Arbeit machen)

Mir fehlte die Zeit, um den nächsten regulären Kalender-Reload abzuwarten.
Ich kann das Experiment aber gern wiederholen - würdest Du ggf mehr
Details brauchen? Wenn ja, welche?

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

genausowas habe ich auch getestet, wobei ich mit notify alle Ereignisse ins Log habe schreiben lassen (siehe commandref). Ich schaue es mir am Wochenende an.

Viele Grüße
Boris



Tom schrieb:

Hallo Boris,

> Bist Du sicher, daß es bei Dir nicht klappt? Dann bräuchte ich ein einfaches
> generisches Beispiel, um es nachzustellen.

Ich hatte folgendes ausprobiert (der Kalender wird mit
Standard-Einstellungen geladen):
- ich habe ein Test-Event eingetragen mit Beginn 06:40 und Ende 06:42
- um ca. 06.38 habe ich den Kalender manuell aktualisieren lassen und
danach den Monitor gestartet
- um 06:40 rasselten die Start-Einträge durch
- bis 06:45 kam nichts, dann habe ich manuell aktualisiert, um mir die
generierten Ereignis-Zeilen zur späteren Auswertung abzuspeichern
(wobei ich in der Eile Datei dann doch ohne SAVE geschlossen habe -
man sollte sowas nicht "noch mal eben" vor der Arbeit machen)

Mir fehlte die Zeit, um den nächsten regulären Kalender-Reload abzuwarten.
Ich kann das Experiment aber gern wiederholen - würdest Du ggf mehr
Details brauchen? Wenn ja, welche?

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

Am 02.08.2012 12:11, schrieb Tom:
> Ich hatte folgendes ausprobiert (der Kalender wird mit
> Standard-Einstellungen geladen): - ich habe ein Test-Event eingetragen
> mit Beginn 06:40 und Ende 06:42 - um ca. 06.38 habe ich den Kalender
> manuell aktualisieren lassen und danach den Monitor gestartet - um
> 06:40 rasselten die Start-Einträge durch - bis 06:45 kam nichts, dann
> habe ich manuell aktualisiert, um mir die generierten Ereignis-Zeilen
> zur späteren Auswertung abzuspeichern (wobei ich in der Eile Datei
> dann doch ohne SAVE geschlossen habe - man sollte sowas nicht "noch
> mal eben" vor der Arbeit machen)

es gab noch Fehler, die ich jetzt hoffentlich behoben habe. Im SVN
eingecheckt und morgen im Laufe des Tages per update verfügbar.

Viele Grüße
Boris




--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[borsti67]

                                                 

Hallo Boris,

ich habe vorhin noch einmal herumexperimentiert.
Die direkte Steuerung von Aktoren von Aktoren wie in commandref
beschrieben fand ich doch etwas zu gewagt.
Daher wollte ich erst einmal das Beispiel zum Loggen verwenden und mir
dann ein passendes Modul schreiben, welches auf ganz konkrete Ereignisse
reagiert.

Ich habe das Beispiel also mal so übernommen:

define n_LogCalEvents notify TGCal:mode(Started|Ended).* { \
  my $reading="%EVTPART0";; \
  my $uid="%EVTPART1";; \
  my $actor=fhem("get TGCal summary $uid");; \
  Log 1, "Actor: $actor, Reading $reading" \
}

(wobei mir auffiel, dass in der commandref  hinter dem Wort "notify"
etwas anderes steht als hinter "get" - war das Absicht?)

Dann habe ich ein Test-Event im Kalender angelegt, welches um 11:20
beginnen soll. Dieses hieß "Test-Event 2". Im Log stand dann:

Use of uninitialized value in concatenation (.) or string at (eval 7963)
line 1.
2012.08.10 11:20:00 1: Actor: , Reading modeStarted:
Use of uninitialized value in concatenation (.) or string at (eval 7964)
line 1.
2012.08.10 11:20:00 1: Actor: , Reading modeEnded:

...das sieht mir so aus, als würden mehrere Worte im Subject nicht
funktionieren? Habe das Event dann einfach in "Testevent" umbenannt und
neu einlesen lassen.

Use of uninitialized value in sprintf at
/usr/syno/synoman/webman/3rdparty/fhem/FHEM/57_Calendar.pm line 389.
2012.08.10 11:25:00 3: get TGCal summary
m04pdtombtc67f0lqcrhmkg2pogooglecom : Testevent
2012.08.10 11:25:00 1: Actor: Testevent, Reading modeStarted:
Use of uninitialized value in concatenation (.) or string at (eval 1367)
line 1.
2012.08.10 11:25:00 1: Actor: , Reading modeEnded:
Use of uninitialized value in concatenation (.) or string at (eval 1368)
line 1.
2012.08.10 11:27:00 1: Actor: , Reading modeStarted:
Use of uninitialized value in concatenation (.) or string at (eval 1369)
line 1.
2012.08.10 11:27:00 1: Actor: , Reading modeEnded:

das sieht zwar besser aus, aber noch nicht gut. Woher kommen die
"uninitialized values"? Es wird offensichtlich kein "Actor" aus dem
Event herausgelesen, aber warum nicht?

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Martin,
habe eine 209 mit DSM 4.0. und fhem.
Welchen Vorteil bietet Dein neueres Perl? Das weather Modul geht ja nicht,
ich setze es zwar nur testweise ein, aber das wird sich ändern.
Hast Du schon das neue DSM 4.1 Beta ausprobiert? Funktionieren da Deine
Kernelmodule noch? Eigentlich muesste es tun, bei den meisten DSen gab es
keine Kernel Änderung.
Funktioniert bei Dir der automatische Start von fhem? Bei mir nicht.

LG Joachim

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[borsti67]

                                                 

Hi Boris,

> define n_LogCalEvents notify TGCal:mode(Started|Ended).* { \
>   my $reading="%EVTPART0";; \
>   my $uid="%EVTPART1";; \
>   my $actor=fhem("get TGCal summary $uid");; \
>   Log 1, "Actor: $actor, Reading $reading" \
> }
>
> (wobei mir auffiel, dass in der commandref  hinter dem Wort "notify"
> etwas anderes steht als hinter "get" - war das Absicht?)

> 2012.08.10 11:25:00 1: Actor: , Reading modeEnded:
> Use of uninitialized value in concatenation (.) or string at (eval 1368)
> line 1.
> 2012.08.10 11:27:00 1: Actor: , Reading modeStarted:
> Use of uninitialized value in concatenation (.) or string at (eval 1369)
> line 1.
> 2012.08.10 11:27:00 1: Actor: , Reading modeEnded:
>
> das sieht zwar besser aus, aber noch nicht gut. Woher kommen die
> "uninitialized values"? Es wird offensichtlich kein "Actor" aus dem
> Event herausgelesen, aber warum nicht?

nachdem ich das nun noch ein paar Tage beobachtet habe, sieht es für
mich so aus, als wenn bei jedem Update des Kalenders die Events
"Started" und "Ended" getriggert werden - also auch dann, wenn gar
kein Ereignis zu triggern war (daher der Fehler, es stand halt nichts
hinter dem Doppelpunkt)!
Ist das so beabsichtigt oder doch eher ein Käfer?

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo, das werde ich mir wohl ansehen müssen. Viele Grüße, Boris
--
sent from my WePad - apologies for brevity

_____________________________________________
Von: Tom
Gesendet: Wed Aug 29 21:15:28 MESZ 2012
An: fhem-users@googlegroups.com
Betreff: Re: [FHEM] Calendar


Hi Boris,

> define n_LogCalEvents notify TGCal:mode(Started|Ended).* { \
> my $reading="%EVTPART0";; \
> my $uid="%EVTPART1";; \
> my $actor=fhem("get TGCal summary $uid");; \
> Log 1, "Actor: $actor, Reading $reading" \
> }
>
> (wobei mir auffiel, dass in der commandref hinter dem Wort "notify"
> etwas anderes steht als hinter "get" - war das Absicht?)

> 2012.08.10 11:25:00 1: Actor: , Reading modeEnded:
> Use of uninitialized value in concatenation (.) or string at (eval 1368)
> line 1.
> 2012.08.10 11:27:00 1: Actor: , Reading modeStarted:
> Use of uninitialized value in concatenation (.) or string at (eval 1369)
> line 1.
> 2012.08.10 11:27:00 1: Actor: , Reading modeEnded:
>
> das sieht zwar besser aus, aber noch nicht gut. Woher kommen die
> "uninitialized values"? Es wird offensichtlich kein "Actor" aus dem
> Event herausgelesen, aber warum nicht?

nachdem ich das nun noch ein paar Tage beobachtet habe, sieht es für
mich so aus, als wenn bei jedem Update des Kalenders die Events
"Started" und "Ended" getriggert werden - also auch dann, wenn gar
kein Ereignis zu triggern war (daher der Fehler, es stand halt nichts
hinter dem Doppelpunkt)!
Ist das so beabsichtigt oder doch eher ein Käfer?

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

Am 29.08.2012 21:15, schrieb Tom:
>
> (wobei mir auffiel, dass in der commandref  hinter dem Wort "notify"
> etwas anderes steht als hinter "get" - war das Absicht?)
nein Fehler, eben korrigiert.
> nachdem ich das nun noch ein paar Tage beobachtet habe, sieht es für
> mich so aus, als wenn bei jedem Update des Kalenders die Events
> "Started" und "Ended" getriggert werden - also auch dann, wenn gar
> kein Ereignis zu triggern war (daher der Fehler, es stand halt nichts
> hinter dem Doppelpunkt)! Ist das so beabsichtigt oder doch eher ein
> Käfer? Gruß Torsten

Durch langes Starren auf die Ergebnisse, die sich bei meinem eben
durchgeführten Test im Log ansammeln, habe ich nur Leere gesehen. Die
Leere erklärt sich wie folgt:
1. Das Reading modeStarted wird aktualisiert (von nichts auf nichts).
2. Ein Event wird ausgelöst.
3. Der Eintrag "modeStarted: " wird ins Log geschrieben.

Es ist jetzt allerdings keine Lösung, das Reading nur zu aktualisieren,
wenn es Events in modeStarted gibt. Das Reading wird immer aktualisiert.
Wir wollen auch ein Event, wenn modeStarted von irgendwas auf leer geht.
Du kannst Dir helfen, indem Du das Attribut event-on-change-reading
entsprechend setzt. Du wirst dann nur bei Änderungen des Readings ein
Event bekommen. Allerdings immer auch das, wenn modeStarted auf leer
geht. Das mußt Du also immer abfangen.

Ich muß mich mal gelegentlich damit befassen, synthetische Events zu
generieren, in der Form:

    :

Ich glaube, das ist mehr das, was man erwarten würde.

Grüße
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[borsti67]

                                                 

Hi Boris,

>> mich so aus, als wenn bei jedem Update des Kalenders die Events
>> "Started" und "Ended" getriggert werden - also auch dann, wenn gar
>> kein Ereignis zu triggern war (daher der Fehler, es stand halt nichts
>> hinter dem Doppelpunkt)! Ist das so beabsichtigt oder doch eher ein
>> Käfer? Gruß Torsten
>

> Leere erklärt sich wie folgt:
> 1. Das Reading modeStarted wird aktualisiert (von nichts auf nichts).
> 2. Ein Event wird ausgelöst.
> 3. Der Eintrag "modeStarted: " wird ins Log geschrieben.
>
> Es ist jetzt allerdings keine Lösung, das Reading nur zu aktualisieren,
> wenn es Events in modeStarted gibt. Das Reading wird immer aktualisiert.
> Wir wollen auch ein Event, wenn modeStarted von irgendwas auf leer geht.

Die Event-Steuerung verstehe ich hier nicht so ganz.
Für mich heißt ein ausgelöstes "modeStarted" dass _irgendein_
Kalendereintrag begonnen hat. "Leer" ist also keine Option.
Das Reading zu aktualisieren (also klarstellen, dass "started" nicht
länger zutrifft) ist ja für mich ok, aber das sollte keinen Eintrag im
Log erzeugen, so dass bei "leer" das Notify nicht getriggert wird.
Oder wo ist da jetzt mein Denkfehler?

> Du kannst Dir helfen, indem Du das Attribut event-on-change-reading
> entsprechend setzt. Du wirst dann nur bei Änderungen des Readings ein

ich glaube, das muss ich in der Tat machen.
So, wie ich bisher glaubte, funktioniert es möglicherweise gar nicht -
ich hatte vor, bei "started" und "ended" bestimmte Befehle abzusenden
und ging davon aus, dass die exakt EIN Mal getriggert werden (es sei
denn, man ändert in der Zeit dazwischen was im Kalender ).
Oder ist das doch so, und ich habe dazwischen lediglich die
Leer-Ereignisse? Mist, ich muss wohl noch mal ein Test-Event anlegen
und gucken.

> Event bekommen. Allerdings immer auch das, wenn modeStarted auf leer
> geht. Das mußt Du also immer abfangen.

Im Moment stellt sich das für mich so dar, dass ich im Notify-Code
nicht einfach die EVTPARTs zusweisen kann/darf, da diese auch "null"
sein könnten. Das muss ich mir mal austüfteln, wie man das korrekt
abfängt. Nur dann, wenn was "übrig bleibt" würde ich in eine Funktion
verzweigen.

>
> Ich muß mich mal gelegentlich damit befassen, synthetische Events zu
> generieren, in der Form:
>
>     :
>
> Ich glaube, das ist mehr das, was man erwarten würde.

Klingt auch interessant. *g*

Danke und Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[borsti67]

                                                 

Hi nochmal,

habe das notify gestern mal so geändert:

define n_LogCalEvents notify TGCal:mode(Started|Ended).* { \
  my $reading="%EVTPART0";; \
  my $uid="%EVTPART1";; \
  my $actor=fhem("get TGCal summary $uid");; \
  if(defined $actor) { \
    Log 1, "Actor: $actor, Reading $reading" \
  } \
}

das ergab dann keine Fehler mehr und dieses eine Mal wurde der Trigger
aktiviert:

2012.08.31 01:32:48 3: get TGCal summary
pl1srue5g7738u7su9g148b26cgooglecom : Testevent
2012.08.31 01:32:48 1: Actor: Testevent, Reading modeEnded:

Das Event war allerdings eigentlich schon 01:00 zu Ende. Das ist also
wieder erst ausgelöst worden, als der Kalender "refreshed" wurde.
Eingetragen hatte ich es so gegen 19:00 mit Startzeit 21:00, musste aber
'ne ganze Zeit basteln, bis ich das mit dem "defined" raus hatte und
habe daher bis ca. 23:30 immer wieder manuell "geupdated".

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo an alle
ich habe auf meiner DS411 auf DSM 4.1 aktualisiert.
Nach dem Update wurde mein Cul nicht mehr erkannt, also dachte ich mir
alles runter und nochmal frisch drauf.
Das war ein Fehler, jetzt kann ich kein Paket mehr hochladen.
Es kommt immer die Fehlermeldung "'Die Datei konnte nicht hochgeladen
werden. Bitte überprüfen sie Ihre Netzwerkverbindung.

Hat jemand die Kombination DSM 4.1 und Cul am laufen und kann mir event.
einen Tipp geben.

MFG
Tobi


Am Mittwoch, 1. August 2012 18:56:30 UTC+2 schrieb Martin Fischer:
>
> Hi @all,
>
> für alle Interessierte habe ich eine neue Release von FHEM für Synology
> DiskStation / RackStation bereitgestellt. Neben den notwendigen Kernel-
> Treibern (cdc-acm, ftdi_sio, pl2303, usbserial) für diverse Hardware wie
> z.B.
> CUL, FHZ1000, FHZ1300, 1-Wire Busmaster, TUL, u.a., stelle ich auch ein
> Paket
> mit Perl 5.16.0 inkl. OpenSSL Unterstützung (Extra Paket) zur Verfügung.
>
> FHEM selbst steht in zwei Varianten zur Auswahl:
>
> Einmal mit Abhängigkeit zu den Kernel-Treibern zum Einsatz auf DiskStation
> /
> RackStation mit Marvell 6281 / 6282 Chipsatz.
>
> Und zum Zweiten eine "noarch" Version, die auf allen anderen DiskStation /
> RackStation ohne Marvell Chipsatz zum Einsatz kommen kann. Hierfür stelle
> ich
> allerdings keine aktuelle Perl-Version sowie Kernel-Treiber zur Verfügung.
>
> Alle Pakete lassen sich auf einer unmodifizierten DiskStation /
> RackStation
> installieren. Es besteht keine Abhängigkeit z.B. zu Optware!
>
> Durch die neue Perl-Version werden alle zur Zeit von FHEM genutzten Module
> voll unterstützt. Evtl. vorher installierte Pakete von FHEM, Perl und
> Kernel-
> Treiber sollten komplett deinstalliert werden, da ich neben der
> Versionierung
> auch einige interne Routinen geändert habe. Die Wartezeit beim Upload
> (besonders bei Perl) ist normal: es handelt sich um einen HTTP-Upload und
> das
> dauert bei ca. 22 MByte (Perl Modul) nun mal etwas Also Geduld!
>
> Mehr dazu unter:
>
> http://www.fischer-net.de/hausautomation/fhem/47-fhem-mit-perl-5-16-0-auf-synology-diskstation.html
>
> Gruß Martin
>
> P.S.:
> Da es nach wie vor Probleme seitens des DSM 4.x von Synology beim Upload
> mittels Firefox / Chrome gibt (Upload hängt in Endlosschleife), müssen die
> Pakete als Work-around mit einem Internet Explorer hochgeladen werden.
> Dies
> ist _kein_ Problem mit meinen Paketen, sondern hängt vermutlich mit einem
> fehlerhaften Flashplugin der Browser zusammen. Lösungsvorschläge hierzu
> sind
> willkommen!
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

eine Teilantwort: Calendar stellt einen Timer, der jeweils zum nächsten Zeitpunkt auslöst, an dem etwas passieren wird. Dann werden alle Kalenderereignisse durchgeprüft, ggf. im Zustand geändert und die fhem-Events generiert. Das passiert zusätzlich und unabhängig beim Update. An einfachen Beispielen habe ich getestet, daß das auch so funktioniert. Bist Du sicher, daß es bei Dir nicht klappt? Dann bräuchte ich ein einfaches generisches Beispiel, um es nachzustellen.

Ich würde mir eine Perl-Anweisung schreiben, die auf evtpart zugreift (siehe Beispiele in commandref), um abhängig vom Titel eine Aktion auszulösen.

Viele Grüße
Boris



borsti schrieb:

Moin zusammen,

ich wollte mich demnächst einmal der Nutzung des Kalender-Moduls widmen.
Das Einbinden hat geklappt, schon mal viel wert.

Dann habe ich ein Test-Event angelegt und mir angeschaut, was so im
Event-Monitor passierte. Dabei fiel mir auf, dass die Events jeweils
nicht (exakt) zur geplanten Zeit ihren Mode-Change bekommen, sondern den
Status ausschließlich beim Kalender-Update ändern. Je genauer ich also
den Schaltpunkt brauche, um so öfter muss ich den Kalender aktualisieren
lassen. Ist das richtig, oder habe ich was falsch gemacht? Wenn richtig,
ist das dauerhaft so beabsichtigt, oder gibt es ggf Planungen, die
Events z.B. - sobald erkannt - mittels AT-Befehlen genauer zu verarbeiten?

Die nächste Frage bezieht sich auf die optimale Auswertung.
In den generierten Events steht ja nur die Kalender-Event-ID drin, den
Titel muss man sich bei Bedarf erst noch dazu holen.
Nun verstehe ich die Idee der Kalendersteuerung (ganz besonders, so
langesich wiederholende nicht implementiert sind) doch eher so, dass ich
in meinem Kalender Ereignisse eintrage mit einem speziellen Titel,
aufgrund derer FHEM dann etwas erledigt. Die ID dazu will ich
logischerweise nicht erst manuell heraussuchen, um dann ein spezifisches
Script zu schreiben - dann bräuchte ich den Kalender nicht.

Meine logische Schlussfolgerung ist, dass ich ein Notify brauche,
welches einfach nur auf Kalender-Start und -End-Ereignisse lauscht und
die entsprechende ID dann vorzugsweise an ein Modul gibt. Dieses
wiederum holt sich den Titel dazu, wertet die Stichworte aus und löst
ggf die Funktionen aus.
Ist das korrekt? Wenn ja, hat da schon einer was, worauf ich aufbauen
kann? Oder denke ich viel zu weit um die Ecke, und es ginge viel einfacher?

Gruß
Torsten

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Hiya Joachim,

Am Freitag, 10. August 2012, 04:34:21 schrieb Joachim:
> [...]
> habe eine 209 mit DSM 4.0. und fhem.
> Welchen Vorteil bietet Dein neueres Perl? Das weather Modul geht ja nicht,
> ich setze es zwar nur testweise ein, aber das wird sich ändern.

die neue perl version sollte nun _alle_ fhem module unterstützen.. _DAS_ ist
der wesentliche vorteil

> Hast Du schon das neue DSM 4.1 Beta ausprobiert? Funktionieren da Deine
> Kernelmodule noch? Eigentlich muesste es tun, bei den meisten DSen gab es
> keine Kernel Änderung.

nein, dsm 4.1 habe ich noch nicht drauf.. wenn der kernel sich nicht geändert
hat, sollten sie auch weiterhin laufen.. ansonsten muss ich neue kernelmodule
nachliefern...

> Funktioniert bei Dir der automatische Start von fhem? Bei mir nicht.

mein fhem läuft auf einem dicken server.. die synology pakete habe ich primär
nur für die community bereitsgestellt..

da ich die scripte bei den neuen paketen komplett überarbeitet habe, solltest
du diese mal testen. diese sollten sogar ein update überleben.

und starten sollten sie eigentlich auch, wenn nicht, dann bitte nochmal eine
rückmeldung und ich muss das auf meinem weiteren "entwicklungs nas"
nachstellen..

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com