57_SSCal - Modul für den Synology Kalender

Begonnen von DS_Starter, 03 Januar 2020, 09:54:09

Vorheriges Thema - Nächstes Thema

DS_Starter

Ich habe die Tabellendarstellung noch um eine zuschaltbare Spalte "Symbol" erweitert. Damit kann man eine ganze Terminzeile grafisch kennzeichnen. Je nach Kalendermodel (Diary oder Task) wird ein anderes Standardicon angezeigt. Man kann das natürlich wieder seinen Wünschen entsprechend anpassen.

Wiki -> https://wiki.fhem.de/wiki/SSCal_-_Integration_des_Synology_Calendar_Servers#Gestaltung_der_Spalte_.22Symbol.22

Eine allgemeine Frage in die Runde ...

Bei der Beschäftigung mit dem Kalender ist mir eine Schwäche aufgefallen, die jetzt nicht SSCal-typisch ist, sondern sich vermutlich auch bei 57_Calendar findet.

Es geht dabei um die Events die ein Kalender erzeugt um darauf reagieren zu können. Einen Kalender updated man ja üblicherweise nicht so oft, also vielleicht nur stündlich oder jeden halben Tag usw.
Bei jedem Update werden selbstverständlich die Events generiert, d.h. z.B. ob ein Eintrag den Status upcoming, ended, started oder alarmed hat. Darauf kann man reagieren und andere Devices schalten. Aber in der Zeit zwischen den Updates können ja die Statuszustände wechseln ohne das ein Event generiert wird und somit z.B. die minutengenaue Steuerung von Devices über einen Kalender nicht funktioniert.

Vielleicht bin ich ja mittlerweile etwas betriebsblind geworden, aber wenn ich recht habe, würde ich SSCal eine Funktion spendieren die alle X Minuten (einstellbar) die Zeiten / Alarmzeiten der Kalendereinträge checkt und den Statuswechsel durch Readingaktualisierungen und Events signalisiert.

Dadurch könnte man recht leicht kalendergestützte Steuerungen aufbauen.

Habe ich bei dieser Betrachtung etwas übersehen oder ist es tatsächlich eine Lücke die es zu schließen gilt ?

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wzut

Thema Events : finde ich gut ( geht ja in die Richtung die ich im Hinterkopf hatte mit Thermostate steuern)
Was mir nur unklar ist , wann genau willst du den Event erzeugen ? Direkt schon beim einlesen oder erst dann wenn dir Anfangsuhrzeit erreicht ist ? 
Die Anfangsuhrzeit hätte schon Charme weil man quasi Module wie weekdaytimer komplett damit ersetzen könnte, frei nach dem Motto ich trag einen beliebigen FHEM Befehl in den Kalender ein und wenn es soweit ist wird er blind ausgeführt , Syntaxprüfung und Fehlermeldung macht das Ziel Device

Ich bin eben mal durchs Wki gegangen, das wird langsam mit den Möglichkeiten der Darstellung echt komplex ....
und gleich mal ausprobiert (copy & paste) und FHEM abgeschossen :)
editier im Wiki dein Beispiel für columnSymbolIcon bei den Wochentagen und setze wie das Beispiel darüber den Block in geschweifte Klammern.
sonst gibt es Mecker im Log
Can't use string (""columnSymbolIcon" => [
        "...) as a HASH ref while "strict refs" in use at ./FHEM/57_SSCal.pm line 3262.


und was muß ich im Kalender eintragen um die Wochentage zu bekommen ? Die Spalte ist bei mir leer
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Hi Wzut,

bin grad unterwegs und melde mich später nochmal.

Aber du musst das aktuelle Modul nochmal aus dem contrib ziehen und restarten.
Ich habe alle Beispiele aus dem Wiki bei mir durchgetestet.  :)

Wenn es dann immer noch Probleme geben sollte ... gucken wir später ...

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wzut

nein das Modul ist das Neuste , der Fehler ist im Wiki nur in dem einen Bespiel fehlen die {}
Wochentage habe ich jetzt auch , musste den Kalender neu abholen.
Und eins ist mir aufgefallen : Die Header Zeile für die Uhrzeit -> ----
a. brauchst du da keine language Unterscheidung da du immer die vier - ausgibst.
b. wäre schön wenn die auf '' gesetzt werden würden wenn die aktuelle Ausgabe nur Tagestermine enthält  und die beiden Spalten eh leer sind
(habs bei mir mal rausgworfen , sieht der Abfallkalender nun richtig schön aus)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

ok, Uhrzeit lässt sich leicht entfernen wenn ich smalscreen definiere.
Aber ich hätte noch etwas : geh mal dein $out durch nach dem letzten möglichen header Feld <td>ID</td>
müsste noch ein
$out .='</tr>'
da du später in der Schelife (odd/even) ja wieder neu mit <tr> beginnst ( die meisten Browser verzeihen aber diesen HTML Fehler )
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

#65
Hi Wzut,

so ... das Wiki-Beispiel habe ich korrigiert.  :o
Aber weil solche Fehlkonfigurationen immer vorkommen können, habe ich das Modul gleich noch "gehärtet" und in attrFn die Prüfung verschärft.

Das "$out .='</tr>'" ist auch ergänzt. 

Zitata. brauchst du da keine language Unterscheidung da du immer die vier - ausgibst.
Ja, habe ich extra so gelassen falls ich doch mal an dieser Stelle etwas anderes einfüge.

Danke dir für deine checks  :)

Thema Events ...

ZitatWas mir nur unklar ist , wann genau willst du den Event erzeugen ? Direkt schon beim einlesen oder erst dann wenn dir Anfangsuhrzeit erreicht ist ?
Idee ist folgende. Jeder Termineintrag hat ja das Reading "x_17_Status". Dieses Reading wird initial beim Einlesen des Kalenders abhängig  von seinen Daten bezüglich Begin/Endzeit und auch eventuell vorhandenen Erinnerungsterminen (x_x_x_notifyDateTime) auf einen Status upcoming, ended, started oder alarmed gesetzt. Dabei wird auch ein Event generiert.

Im Hintergrund läuft ein internal Timer der z.B. alle 60 Sekunden die Readings x_05_Begin, x_10_End und evtl. vorhandene x_80_x_notifyDateTime mit der aktuellen Zeit vergleicht. Sollte sich entsprechend der Bedingungen der Status ändern, wird das Reading "x_17_Status" entsprechend angepasst und auch ein Event mit dem neuen Status erzeugt.
Den Aufbau des Events müsste ich mir noch genau überlegen, sodass man aus dem Event neben dem Status gleich den Inhalt (Summary) erkennt.

Zum Beispiel:


2020-02-12 22:30:21.305 SSCal 02_17_StatusLong: alarmed||AZ Licht on
2020-02-12 22:30:21.305 SSCal 02_17_StatusLong: started||AZ Licht on
2020-02-12 22:30:21.305 SSCal 02_17_StatusLong: ended||AZ Licht on


Alarmed heißt das bald etwas losgehen soll. Der "started" Event bedeutet das AZ Licht einschalten. Dementsprechend wäre bei "ended" der mit "AZ Licht on" gestartete Vorgang beendet. Wenn man diese Prüfung im SSCal jede Minute laufen lässt, ließe sich damit eine minutengenaue Steuerung realisieren.

So die Theorie  ;)

Edit: Geht etwas einfacher. Man erstellt sich zwei Termine, einen mit "on", den zweiten mit "off". Der interne Timer würde dann die Events beim Statuswechsel erzeugen:


2020-02-12 22:30:00 SSCal 02_17_StatusLong: alarmed||AZ Licht on    -> keine Reaktion, ggf. "Vorbereitungen"
2020-02-12 22:30:00 SSCal 02_17_StatusLong: started||AZ Licht on      -> darauf reagiert man und schaltet das D on
2020-02-12 23:30:00 SSCal 02_17_StatusLong: ended||AZ Licht on        -> keine Reaktion
2020-02-12 23:30:00 SSCal 02_17_StatusLong: started||AZ Licht off      -> darauf reagiert man und schaltet das D off
2020-02-12 23:40:00 SSCal 02_17_StatusLong: ended||AZ Licht off       -> keine Reaktion


Grüße,
Heiko


ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wzut

ok, Thema Events :
Ich denke wenn ich das schreiben müsste würde ich nicht auf einen extra Internal Timer setzen.
Bsp : Das beliebte command.ref "set lamp on" , man erstellt einen Kalendereintrag mit folgender Zeile
{ set lamp on }
erstes Zeichen { letzte Zeichen } bedeutet FHEM Befehl, nun würde ich beim Update wenn ich diese Bedienung finde ein temp at erstellen (room = hidden) mit der Anfangszeit und dem Befehl ohne die Klammern. Weiter tun must du dann gar nichts mehr , das at übernimmt ja den kompletten Rest.

Attribut tableSpecs
Ist nun sehr mächtig geworden und gut das du nun zusätzliche Prüfung eingebaut hast damit der User bei Fehleingaben nicht sein FHEM in den Keller zieht.
Aber : für dich elegant mit nur einem Attribut so viel erschlagen zu können, aber hoffentlich sind gerade mit der Syntax nicht die User überfordert 

HTML :
zum einen hätte ich einen Wunsch, entweder als Attribut oder als Schlüsselwort für tableSpecs  -> noHeader um die Header Zeile ganz zu unterdrücken.
Dann habe ich mal die HTML Ausgabe via Weblink vom Device abgekoppelt ( siehe Screenshot )
Ohne die äussere Device Table nimmt sich table gleich den ganzen Bildschirm statt sich mit dem Platz zufrieden zu geben der nötig ist.
Das war beim SMA Portal auch mal so , ich muß mal schauen mit welcher table class sich das unter Kontrolle halten lässt.
Desweiteren zeigt der Screenshot auch schön was passiert wenn im Header ein anderes align benutzt wird als in der TD darunter -> Status nach rechts verschoben in Bezug zum Datum 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Zitat
Bsp : Das beliebte command.ref "set lamp on" , man erstellt einen Kalendereintrag mit folgender Zeile
Code: [Auswählen]

{ set lamp on }

erstes Zeichen { letzte Zeichen } bedeutet FHEM Befehl, nun würde ich beim Update wenn ich diese Bedienung finde ein temp at erstellen (room = hidden) mit der Anfangszeit und dem Befehl ohne die Klammern. Weiter tun must du dann gar nichts mehr , das at übernimmt ja den kompletten Rest.
Ja stimmt, dann reicht ja eigentlich der eine Event beim Einlesen. Es bliebe nur noch die Sache mit den Event-Notifies. Damit meine ich die Terminerinnerungen die man im Kalender setzen kann. Also dass man sich 1 Tag + 2 Stunde + 1 Stunde + 5 Minuten vorher benachrichtigen lassen kann.  Vielleicht wäre dafür eine solche Routine hilfreich, mal überlegen ...

Zitataber hoffentlich sind gerade mit der Syntax nicht die User überfordert 
Ja, mal schauen was die User sagen. Aber ich hatte vermutet da diese Notation in readingsGroup schon sehr verbreitet/etabliert ist kommen die User gut mit zurecht.  :)

Zitatzum einen hätte ich einen Wunsch, entweder als Attribut oder als Schlüsselwort für tableSpecs  -> noHeader um die Header Zeile ganz zu unterdrücken.
Sehe ich mit vor.

ZitatDas war beim SMA Portal auch mal so , ich muß mal schauen mit welcher table class sich das unter Kontrolle halten lässt.
schau mal bitte gleich mit wie die Farbe im Header durch das Style gesteuert werden muss. Zur Zeit sind die Überschriften im default-Style schwarz, müssten m.M. nach aber im default-Style (fett) grün sein. Kann mich aber auch täuschen.

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Ich habe übrigens auch mal ein weblink angelegt mit


defmod SynCal.Abfall.WBL weblink htmlCode { SSCal_calAsHtml ("SynCal.Abfall",".*") }
attr SynCal.Abfall.WBL room Dienste->Kalender


... also ohne Gruppenzuordnung. Im default-Style sieht es noral aus, nur im dark-Style wird die Breite so ausgenutzt wie es bei dir zu sehen ist.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#69
Habe noch Einstellmöglichkeiten für noHeader und Align vorgenommen.


  "cellStyle"             => {
                               "noHeader"    => "1",                # 0 (default)  oder 1
                               "headerAlign" => "center",
                               "columnAlign" => "left",
                             },


siehe -> https://wiki.fhem.de/wiki/SSCal_-_Integration_des_Synology_Calendar_Servers#Allgemeine_Gestaltung_des_Tabellenheaders_und_der_Spalten
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wzut

#70
Zitat von: DS_Starter am 13 Februar 2020, 10:06:42
... also ohne Gruppenzuordnung. Im default-Style sieht es noral aus, nur im dark-Style wird die Breite so ausgenutzt wie es bei dir zu sehen ist.

Wirf mal einen Blick ins SMAPortal , ich hatte genau für den Fall sogar einen Kommentar hinterlassen :
Zitat
# Tabellen Ausgabe erzeugen
# Wenn Table class=block alleine steht, zieht es bei manchen Styles die Ausgabe auf 100% Seitenbreite
# lässt sich durch einbetten in eine zusätzliche Table roomoverview eindämmen



$out  .= "<table class='roomoverview'><tr><td style='text-align: center; padding-left:1px; padding-right:1px; margin:0px'><table class='block'>";
$out .= "</table></td></tr></table>";
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Hi Wzut,

die Änderung ist jetzt auch drin. Danke dir ...

Sag mal ... kennst du eine Routine, die eine HTML-Augabe in ein Bild überführt ? Also ähnlich dem svg2png im SVG.
War der Meinung es hier schonmal gelesen zu haben.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wzut

ähh jetzt hast du mich auf dem linken Fuß erwischt, meine auch mal was hier im Forum gelesen zuhaben in irgend einem Zusammenhang mit RSS , als es noch kein TabletUI und Brüder gab ? oder ich verwechsele es jetzt auch mit svg2png
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Um die Verwendung des Kalenders für den Anwender bezüglich der Ableitung von FHEM Aktivitäten aus Kalendereinträgen zu erleichtern, erstellt die Version 1.11.0 (contrib) nun zusätzlich sogenannte composite-Events, z.B.:


2020-02-14 13:19:11.742 SSCal SynCal2 composite: 1983 2020-02-14T13:15:00 started {set lampe on}         
2020-02-14 13:19:11.811 SSCal SynCal2 composite: 1984 2020-02-14T15:15:00 alarmed {set lampe off}         
2020-02-14 13:35:31.082 SSCal SynCal2 composite: 1985 2020-02-14T18:00:00 upcoming {{ <Perl-Routine> }}   


Daraus kann man nun sehr einfach mit notifies o.ä. Werkzeugen ein at-Device erstellen/modifizieren um in FHEM Schaltvorgänge auszulösen.

Das Verfahren und ein konkretes Beispiel habe ich im Wiki beschrieben:
https://wiki.fhem.de/wiki/SSCal_-_Integration_des_Synology_Calendar_Servers#Reagieren_auf_Events_und_eine_FHEM-Aktivit.C3.A4t_erstellen

Ein großer Vorteil der beschriebenen Arbeitsweise ist, dass man einen Kalendereintrag auch nachträglich ändern kann und sich diese Änderung direkt auf das bereits erstellte at-Device auswirkt.

Prinzipiell könnte ich sogar die gesamte Funktionalität direkt im SSCal-Device abbilden und dem Nutzer den Umweg über das notify abnehmen. Das hätte sogar noch den Charme das ich ein bereits erstelltes at-Device wieder löschen könnte wenn man den Kalendereintrag entfernt. Momentan muss der Nutzer selbst dafür Sorge tragen.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter