Hallo,
ich überarbeite derzeit das Calendar-Modul vollständig und habe es dabei von Grund auf neu konzipiert.
Ein Serientermin erzeugt nun technisch sämtliche Kalenderereignisse der Serie in einem Fenster von +/- 400 Tagen um den aktuellen Zeitpunkt herum, wobei wiederum der Anwender die in mode...-Readings und die mit get ... ausgewiesenen Ereignisse über zwei Attribute in ein kleineres Zeitfenster zwingen kann (um z.B. nur alle Ereignisse von gestern bis in zwei Wochen zu sehen).
Das hat nun zur Folge, dass die UID zu einem Serientermin gleichzeitig z.B. in den Readings modeEnded, modeStarted, modeUpcoming, ... stehen kann (die Serie "Müllabfuhr" erzeugt z.B. Kalenderereignisse in der Vergangenheit, heute, und in der Zukunft).
Stört das jemanden?
Wenn die Müllabfuhr kommt, wird modeStarted getriggert, wenn die Müllabführ da war, wird modeEnded gefolgt von modeUpcoming getriggert. Gibt es irgend jemanden, der die mode...-Readings verwendet?
Ich denke sogar darüber nach, die mode...-Readings zu eliminieren.
Viele Grüße
Boris
Hallo Boris,
Dazu fällt mir schon was ein, aber erst am Wochenende, wenn ich wieder zuhause bin. Vom Tablet aus macht das keinen Spass
- Die uuid in den diversen Readings habe ich bei meinen vielen Kalenderszenarien noch nie benutzt, für mich wären die entbehrlich
- Ein reading "started" mit einer Liste aller gerade laufenden Kalenderevents - darin aber bitte die summary und nicht die uuid- wäre öfters mal hilfreich
- bei "get <name> text ..." wünsche ich mir mehr Flexibiltät, was die Angabe der verschiedenen Datenfelder eines events angeht. Darüber hatten wir vor längerem hier im Forum schon einmal diskutiert.
- Der Zeitraum, für den wiederholende Ereignisse betrachtet werden, sollte m.E. kürzer werden. Beispielsweise brauche ich keine zurückliegenden events und wenn ich Wiederholungen der nächsten 30 Tage sehe, reicht mir das normalerweise auch aus. 400 Tage voraus und zurück als default finde ich jedenfalls extrem viel.
- ... irgendwas fällt mir bestimmt noch ein ...
- als Beta-Tester stehe ich gerne zur Verfügung.
Zitat
Wenn die Müllabfuhr kommt, wird modeStarted getriggert, wenn die Müllabführ da war, wird modeEnded gefolgt von modeUpcoming getriggert. Gibt es irgend jemanden, der die mode...-Readings verwendet?
Ich denke sogar darüber nach, die mode...-Readings zu eliminieren.
ja, einige. alle die calview (und das noch dazugehörige widget für die TUI) nutzen. man steuert über die modes die anzuzeigenden termine.
das modul holt sich erst die uid's aus den angegebenen modes und geht diese liste dann durch unt holt zeiten, summary, location usw
ich würde ehr dazu tendieren das modul ggf bei neuerstellung auch gleich umzubenennen (so dass das alte parallel weiter läuft, nat. phne support)? wenn du es ohne modes -readings in update jagst wird dies bei vielen zu "problemen" führen.
nicht nur die calview nutzer wären erstmal aufgeschmissen, auch die die zb dies nutzen http://www.fhemwiki.de/wiki/Google-Kalender_zur_Steuerung_von_Dummies
wie würdest du den die infos (modereadings) im neuen modul bereit stellen ?
Zitatich würde ehr dazu tendieren das modul ggf bei neuerstellung auch gleich umzubenennen (so dass das alte parallel weiter läuft, nat. phne support)? wenn du es ohne modes -readings in update jagst wird dies bei vielen zu "problemen" führen.
nicht nur die calview nutzer wären erstmal aufgeschmissen, auch die die zb dies nutzen http://www.fhemwiki.de/wiki/Google-Kalender_zur_Steuerung_von_Dummies
Hand heb!
Bitte nicht umbauen! Lieber ein neues Calendar Modul.
Von zwei Kalendermodulen halte ich grundsätzlich nichts, denn das bedeutet für den zuständigen Entwickler doppelten Pflegeaufwand. Die Aussage "ohne Support" läßt sich auch nur bedingt umsetzen, denn wenn es beispielsweise seitens Google wieder irgendwelche Änderungen gibt, die das Modul unbrauchbar machen, muss natürlich darauf reagiert werden. Auch in einer alten Modulversion.
Der Hintergrund des Neubaus ist doch die Tatsache, dass im aktuellen Kalendermodul sachliche Fehler enthalten sind, die beseitigt werden sollen.
Meine Meinung nach lässt sich das auch so umsetzen, dass das neugeschriebene Modul durchaus abwärtskompatibel sein kann. Beispielsweise könnte man die Erzeugung der bisherigen readings per attribut steuerbar machen. Alternativ wäre auch zu überlegen, das Calendar- und das calview-Modul zusammenzuführen.
zusammenführen wäre auch was, ja aber ich denke da geht zu viel an funktion verloren bzw. gibts noch wünsche für calview die in einem separaten modul sicher besser aufgehoben sind.
die 2 calendar-modul lösung halte ich auch für die schlechteste. eine abwärtskompatibilität wäre auch i.o.
mich würde generell erstmal interessieren wie sich boris das neue modul (mit welchen readings usw) vorstellt.
calview bietet zum einen 2 views, dann kommen immer mal wieder userwünsche hinzu. das alles in einem modul wird sicher schwer zu vereinen und eine größere baustelle für boris als nötig. die teilung calendar = rohdaten die jeder verwursten kann wie er es braucht und ander module zur aufberietung find ich schon gut so
Zitat von: chris1284 am 30 November 2015, 18:04:22
die teilung calendar = rohdaten die jeder verwursten kann wie er es braucht und ander module zur aufberietung find ich schon gut so
Genau vor der gleichen Fragestellung standen wir neulich bei der Neugestaltung des GDS Moduls. Damals war die Frage "soll das Modul standardmäßig weblinks analog zu den weblinks im YahooWeather bereitstellen?
Gelost wurde die Fragestellung so:
- Von 55_GDS.pm werden die "Rohdaten" bereitgestellt
- Die Datei GDSweblink.pm stellt die weblinks bereit. Diese Datei befindet sich default in contrib. Wer sie nutzen möchte, muss sie nach FHEM kopieen.
- Das Modul 55_GDS.pm versucht per eval() die Datei GDSweblink.pm zu laden. Wenn das funktioniert, stehen die Funktionen für webinks zur Verfügung. Fehlt die Datei, passiert gar nix.
Das Ganze hat den Charme, dass die Modulpflege auf zwei unabhängig voneinander arbeitende Entwickler verteilt werden können. Eine ähnliche Lösung wäre ja vielleicht auch für das Calendar und das calview denkbar.
Hallo,
Danke für Eure Rückmeldungen. Eine Frage ist damit beantwortet: die mode...-Readings wird es auch künftig geben.
Die state...-Readings beziehen sich auf die VEVENTS im iCalendar. Diese werden verschwinden. Aber ich glaube, dass die wirklich niemand braucht.
Neu ist, dass man vergangene Ereignisse noch eine (einstellbare) Weile sehen kann, kommende Ereignisse bis zu einem (einstellbaren) Zeithorizont sehen kann, und dass aus derselben Terminserie nicht wie bisher nur der aktuelle/nächste Termin sondern innerhalb des (einstellbaren) Zeitfensters alle Vorkommen gezeigt werden. Termine außer der Reihe werden auch funktionieren.
Ansonsten wird das Modul also abwärtskompatibel sein. Es wird keine zwei Module geben. Außerdem werde ich das überarbeitete Modul 4 Wochen zum Testen einstellen (ich bin lernfähig ;-)
Ideen zur Erweiterung:
- get ... text mit benutzerdefiniertem Format
- Präprozessor, der z.B. Müllabfuhrtermine automatisch um Alarme (1 Tag vorher) ergänzen kann
Aber das kommt erst, wenn der aktuelle Leistungsstand des Moduls in der neuen Version wieder hergestellt ist.
Viele Grüße
Boris
Oh ja, das auch!
Alpha-Test gestartet!
http://forum.fhem.de/index.php/topic,46608.0.html (http://forum.fhem.de/index.php/topic,46608.0.html)