LoxBerry: CalDAV-4-Lox Plugin verfügbar.

[svethi]

fwDays heißt ja nicht, dass da Tage übersprungen werden. fwDays ist ja nur eingefügt um einen Termin auch schon Tage vorher anzeigen und behandeln zu können. Entstanden ist das Script seinerzeit wegen eines Müllkalenders. So kannst Du Dir schon Tage vorher anzeigen lassen was am Abfuhrtag abgeholt wird. In Deinem Fall ist dies, wie Christian schon sagte, problematisch. Ebenso problematisch ist die einmalige Kalenderabfrage um 18:00Uhr. Da kannst Du ja gar nicht flexibel an Änderungen reagieren. Das sollte eigentlich der Vorteil der Kalenderanbindung sein. Das ist aber letztlich Deine Sache. Ebenso scheint diese Prüfung dann ja nicht vom Miniserver aus zu laufen, denn da kannst Du das ja gar nicht so genau steuern.
Vorgesehen ist das eigentlich eher so, dass Du z.B. stündlich im MiniServer den Kalender befragst. Nur so funktioniert auch überhaupt der Delay-Wert. Dann könntest Du auch nach fwDay=0 fragen, da ja dann morgens zum Sonnenaufgang die Nachtschicht auch noch aktiv ist und die Jalousien unten bleiben. Nach 7:00Uhr + Delay bekommst Du dann die nächste Nachtschicht angezeigt.
Wenn Du unbedingt nur einmal am Tag abfragen willst, dann würde ich das aber kurz der gewünschten Aktion machen, damit Deine Schaltung auch noch kurzfristige Änderungen mitbekommt. Also morgens um 4:00Uhr oder so. Dann nach fwDay=0 fragen und dann sollte das auch klappen.

[Gast]

Danke Svethi

=fwDays ist ja nur eingefügt um einen Termin auch schon Tage vorher anzeigen und behandeln zu können.

Genau das wollte ich. Tage vorher behandeln, und funktioniert ja auch, bis auf bei gleichnamigen Terminen

Ebenso problematisch ist die einmalige Kalenderabfrage um 18:00Uhr. Da kannst Du ja gar nicht flexibel an Änderungen reagieren.

so frag ich auch nur nach der Nachtschicht via &event=Nachtschicht ab.18:00 Uhr ist damals gewählt worden damit ich auch vor dem Schlafen gehen sehe, ob Sperre aktiv oder nicht.
Andere Events frag ich mehrmals Täglich ab.

Ebenso scheint diese Prüfung dann ja nicht vom Miniserver aus zu laufen, denn da kannst Du das ja gar nicht so genau steuern.

Richtig, die Prüfung macht der GiraHS, Soweit ich weiß geht die direkte Google Kalender Abfrage dort aber auch nicht. Da der Loxberry sowieso läuft, und das auch sehr gut,
warum dann nicht einfach die Möglichkeiten kombinieren.

Fazit: Dachte es wäre möglich,und einfach zu intigrieren, evtl auch für andere Aktionen interessant, das man auch wiederkehrende Termine anzeigen und auch auswerten kann ala &serie=1.

Bis so etwas vll kommt, werd ich der zweiten Schicht einen anderen Namen geben.

Danke noch einmal für euren Einsatz am und rund um den Loxberry. Auf das noch viele Plugins kommen!

[svethi]

Es geht ja bei dem Plugin darum Dinge mit dem MiniServer zu behandeln/schalten. Ebenso geht es um die Verwendung im MiniServer. Serien/Arrays zu übergeben, macht keinen Sinn, da man diese im Miniserver nur schwer bis gar nicht verwalten kann. Daher wird stets der nächste Termin ausgegeben.
Auch für Deinen Fall würde das ja korrekt funktionieren wenn Du nicht noch einen Tag vorher die Funktion kontrollieren wölltest. Und Du kontrollierst dann stets ob alles richtig gesetzt ist? Das hat dann auch wenig mit Automation zu tun und ebenso könntest Du es dann auch gleich manuell aktivieren. Es gibt unzählige Einsatzgebiete. Man kann es leider nicht für alle Fälle perfekt machen. Manchmal muss man sich einfach arrangieren.

[Gast]

Den Abfallkalender unserer Müllabfuhr bekomme ich mit ganztägigen Terminen geliefert.
Wenn heute Gelbe Säcke abgeholt werden und morgen Restmüll dann liefert mir das Plugin bei der Abfrage um 22:00 Uhr immer noch Gelbe Säcke.
Ist auch klar, denn 22+Delay von 60 = heute 23 Uhr, also Gelbe Säcke. Aber wie bekomme ich heute um 22:00 heraus, dass morgen Restmüll abgeholt wird?
Ich bin der Meinung dass das schonmal funktioniert hat,. Oder liegt es an den ganztägigen Terminen?

[svethi]

Hallo Thotti,

Du hast also einen ganztägigen Termin. Mir ist nicht ganz klar, was das mit 22:00Uhr zu tun haben soll. Ein ganztägiger Termin geht von 0:00Uhr bis 23:59:59Uhr. Und wird auch 23:59:59Uhr noch angezeigt. Das Delay hat damit auch nichts zu tun, denn dass sorgt dafür, dass der Termin nach dessen Ende noch für die Delayzeit angezeigt wird. Bei einem Delay von 60 als bis 0:59:59Uhr des Folgetages. Bei den meisten kommen die Abholungen im wöchentlichen Wechsel, da würde der Ganztagstermin kein Problem machen, wenn es um den Folgetag geht ist ein ganztägiger Termin natürlich ein Problem. Ich kenne die Termine ja nicht, aber vielleicht kannst Du die gelben Säcke und den Restmüll auch getrennt abfragen. Dann hast die zwar im MiniServer beide Abfuhren gleichzeitig, aber Du hast sie. Ansonsten musst Du die Termine dahingehend ändern, dass dies keine Tagestermine sind sondern nur von 6:00Uhr - 16:00Uhr.
Bei einem waren die Termine mal nur als 1 Sekunde lang eingetragen. Das geht auch mit dem richtigen Zeitpunkt der Abfrage.
Das Kalenderplugin kann natürlich nur mit den Terminen so arbeiten wie sie im Kalender stehen.

[Friedolin]

Hallo zusammen,

erst einmal das obligatorische Dankeschön für das grandiose Loxberry Projekt und natürlich auch für das Caldav Plugin (und die weiteren Plugins).
Ich bin seit kurzem Miniserver-Besitzer und spiele mich nun auch stark mit Loxberry.
Das Caldav Plugin hat mir allerdings den heutigen Büro-Nachmittag versauert. Mal kurz einen Kalender ausprobieren artet gerade in lange Tüffteleien aus.

Ich würde gerne den Münchner Abfuhrkalender abonnieren, aber es will nicht funktionieren.
Das Ding hat erst einmal sehr viele Parameter, aber wenn ich´s encode, dann frisst es das Plugin, denke ich.

https://www.awm-muenchen.de/index/ab...hrkalender_pi1[section]=ics&tx_awmabfuhrkalender_pi1[standplatzwahl]=true&tx_awmabfuhrkalender_pi1[singlestandplatz]=false&tx_awmabfuhrkalender_pi1[strasse]=Maximilianstr.&tx_awmabfuhrkalender_pi1[hausnummer]=10&tx_awmabfuhrkalender_pi1[stellplatz][restmuell]=70020427&tx_awmabfuhrkalender_pi1[stellplatz][papier]=70020427&tx_awmabfuhrkalender_pi1[stellplatz][bio]=&tx_awmabfuhrkalender_pi1[leerungszyklus][R]=003;G&tx_awmabfuhrkalender_pi1[leerungszyklus][P]=001;G&tx_awmabfuhrkalender_pi1[leerungszyklus][B]=&tx_awmabfuhrkalender_pi1[year]=2017

Wenn ich das Ding in Google Kalender importiere und es über Google laufen lasse, dann geht es.
Google will ich aber nicht verwenden.
OwnCloud hab ich auch versucht, da bricht allerdings erstmal gleich der Import ab.

Hat jemand einen Tipp? Oder muss es dann doch Google sein und ich muss den Kalender immer mal wieder importieren?

[svethi]

Ich bin mir nicht ganz sicher was Du jetzt genau möchtest. Das CalDAV Plugin kann nur mit einem CalDAV Kalenderserver kommunizieren oder halt mit Google. Ein Kalender über eine Webabfrage oder dergleichen funktioniert nunmal nicht und das wird auch nirgends so kommuniziert. Da kannst Du versuchen was Du willst. Du musst schon den Kalender in Google oder einen CalDAV Server importieren.

[freeride24]

Hallo Svethi,

ich benutze Dein grossartiges CalDAV Plugin für Loxberry in Verbindung mit einem Google Kalender. Dabei habe ich einige Serinetermine angelegt. Es gibt allerdings auch "Ausreissertermine" der Serie. Diese habe ich manuell verschoben. Im Kalender selbst werden diese auch korrekt angezeigt. Frage ich diese aber über das Plugin ab kommt als Termin der Wert für den ursprünglichen Serientermin zurück. Hab mir daher einmal die ics Datei selbst angeschaut:

BEGIN:VEVENT
DTSTART;VALUE=DATE:20170505
DTEND;VALUE=DATE:20170506
DTSTAMP:20170507T074025Z
UID:*************@google.com
RECURRENCE-ID;VALUE=DATE:20170504
CREATED:20161229T082036Z
DESCRIPTION:Wertstofflehrung "Grüne Tonne"

In diesem Fall wurde das rot markierte Datum 04.05.2017 (der ursprüngliche Wert des Serientermins) vom Plugin übergeben. Richtig wäre der grüne Wert 05.05.2017 (der manuell verschobene Termin der Serie).

Kann ich dieses Problem irgendwie umgehen (ohne dass ich jeden Termin einzeln erstellen muss)?

Vielen Dank,
freeride24

[svethi]

Hallo freeride24,

Das Problem ist, dass es viele verschiedene Möglichkeiten im CalDAV gibt Termine zu verschieben. Der eine Client benutzt den einen Weg ein Anderer einen Anderen. Die Library, die ich benutze, ist schon ein paar Tage alt und ist nach meinem letzten Stand nicht mehr aktualisiert worden. Einige spezielle Angaben kennt er einfach nicht. Ich mache es so, dass ich die ganz normalen wiederkehrenden Termine anlege und bei Verschiebungen lösche ich den einzelnen Termin und lege dafür dann einen einzelnen neuen an. Damit kann ich gut leben.
Ich hatte auch schonmal nach einer anderen Library Ausschau gehalten, doch die sind alle total anders aufgebaut und das Plugin müsste komplett umgeschrieben werden.

Gruß Sven

[freeride24]

Also löschen und neu anlegen anstatt verschieben. Ich denke damit kann ich auch leben. Vielen Dank

[Christian Fenzl]

Ich verwende direkt Google Calendar. Wenn ich dort einen Termin verschiebe, fragt mich Google, ob das für alle oder den einzelnen ist, und verschiebt dann nur den Einzeltermin. Damit hat Svens Caldav-Integration nach meinem Gefühl keine Probleme. Zumindest wäre mir nie ein verschobener Termin als falsch bewusst geworden.

[svethi]

Das kommt auf den Client an. Ich glaube Thunderbird löscht auch den einen und legt einen neuen an. Scheinbar gibt es in den RFC's auch die Möglichkeit einen Termin zu verschieben. Der Termin bleibt dann genauso bestehen und es wird nur in den Eigenschaften die Verschiebung angegeben und dann geht's schief. Daher mach ich's jetzt halt herkömmlich mit entsprechenden Termin löschen und neu anlegen. Dann isses kompatibel

[Liver_64]

Hallo zusammen,
ich habe das Problem dass bei einem ganztägigen Termin der z.B. am 4.10.2017 beginnt und endet dieser Termin mit Start bereits am 03.10.2017 angezeigt wird, was in fwDay=0 resultiert, aber 1 sein müsste. Von daher kommt meine Abfallansage (basierend auf Google Kalender) einen Tag zu früh. Ich war mir eigentlich sicher das es beim Testen funktionierte, aber jetzt auf einmal nicht mehr :-( Evtl. eines der 80% IT Probleme zwischen Rückenlehne und Tatstatur?
vielen Dank vorab
Gruß Oliver

[svethi]

Bevor ich den Screenshot gesehen habe, dachte ich noch an ein Zeitzonenproblem. Aber in der Rückgabe beginnt der Termin ja schon einen Tag vorher um 0:00Uhr.
Achso, könnte dennoch sein. Ist ja trotzdem nur ein Tag. Halt nur zu früh. Wenn Dein Termin als ganztags angegeben ist und durch eine falsche Zeitzone am Vortag um 23:00Uhr wird das sicher so angezeigt. Du müsstest also auf die richtige Zeitzone im Googlekalender, im Loxberry und im Client achten, mit dem Du den Termin anlegst.
Kannst Du mal den Termin exportieren, damit ich den als Quelltextausgabe von Google sehe?!

[Liver_64]

Hi Sven,
das hatte ich mir auch schon angesehen. Der LB steht auf Zeitserver und Google auf GMT+2, die Uhrzeiten sind gleich. Habe dir mal den ganzen Kalender exportiert und Screenshots angehängt.
danke dir vorab.

[Liver_64]

Hi Sven,
ich habe auch nochmal Zeit investiert und mir die ICS Dateien angesehen, kann hier aber keine Unstimmigkeiten erkennen. Vom Prozess her sieht es folgendermaßen aus: Ich lade die ICS Datei von unserem Abfallprovider, ändere mit Notepad++ Summary und Description und importiere Sie in den Google Kalender. Basierend auf dem Kalender startet dann der entsprechende Ganztagestermin einen Tag zu früh. Füge ich nun manuell dem Kalender einen Ganztagestermin hinzu stimmt es. Wenn ich dann den Kalender wieder exportiere sieht der manuelle Eintrag in den Feldern DTSTART und DTEND genauso aus wie bei dem importierten Terminen, nur stimmt dann fwDay!
Habe die mal beide Kalender angehängt, vielleicht findest du ja doch noch was!!

Ziel ist es das ganze für Sonos4Lox ohne den MS sprechend zu machen (was schon funktioniert), nur nicht korrekt.
Danke dir.
Gruß Oliver

[svethi]

Hallo Oliver,

ich habe mir soeben den Kalender mal angesehen und es ist ganz klar, dass hier der Eintrag falsch und Schuld ist.

DTSTART;VALUE=DATE:20171003
DTEND;VALUE=DATE:20171004

Der Starteintrag sagt, dass es sich um einen Tagesevent handelt (VALUE=DATE). Daher steht auch keine Uhrzeit dahinter. Weiter wird angegeben, dass der Starttag der 3.10.2017 ist.
Der Endeintrag sagt ebenso das es sich im Tagesevent handelt und der 4.10.2017 ist.
Für mich ist das eigentlich logisch so, doch die Kalender interpretieren das ganz offensichtlich anders. Google und auch OwnCloud zeigen den Termin nur am 4.10. Offensichtlich geht neuerdings Beides, denn als ich das programmiert habe, gab es keine Probleme. Und wie Du selbst sagst, werden selbst eingetragene Termine richtig angezeigt. Das muss ich mir mal ansehen und bei einem Ganztagestermin dann das Terminende verwenden.

[svethi]

Liver_64 ich habe da schonmal in die Programmierung reingesehen, allerdings kommt mir da einiges merkwürdig vor. Ich muss da mal ein bißchen debuggen und testen. Wird also nicht sofort was mit dem Update.

[Liver_64]

wahrscheinlich war es wohl ein temporäres Google Problem.
Btw hätte ich noch einen Feature Wunsch was die Termine angeht: Wäre es möglich nicht nur den nächsten gültigen Termin, sondern alle Termine für einen Tag als Output zu erhalten? Hintergrund ist das ich über das Sonos Plugin gerne alle Termine eines Tages als T2S ausgeben möchte.

Ist zwar für die Alexa Nutzer uninteressant, aber für die Non Alexa Nutzer um so interessanter

Wie gesagt, wäre ein Nice-to-have
Danke für deine Mühe
Gruß aus Hesse, Oliver

[svethi]

Letztlich ist alles möglich, doch wir haben hier einen Loxberry und keinen Sonosberry und im Miniserver kannst Du damit nicht wirklich etwas anfangen.
Ich sehe da nicht wirklich Sinn drin, da es bei dem Plugin auch darum geht Dinge Kalender gesteuert zu schalten etc. Es ist nunmal kein Übersichtskalender

[svethi]

Hi Oliver,

so, ich habe jetzt ein bißchen Zeit gefunden und das Plugin überarbeitet. Jetzt wird auch RDATE unterstützt und somit funktioniert auch Dein Müllkalender.
Wie meinst Du denn genau die Termine an einem Tag?
Du bekommst doch alle Termine genannt nach denen Du suchst und es werden Dir für jeden Termin der nächstzutreffende genannt.

[svethi]

Liver_64 Hi Oliver, nachdem ich nun stundenlang die RFC's nochmal studiert habe und von der Richtigkeit meiner Ausgabe überzeugt war, habe ich mir Deinen Termin nochmal genau angesehen und dabei ist mir klar geworden, was hier schief gegangen ist. Der Termin ist richtigerweise eigentlich am 3.10. gewesen, so wie mein Tool es auch erkannt hat. Nun ist es aber so, dass dies ein sich wiederholender Termin ist und auch noch ausgerechnet der Starttermin auch noch ausgeschlossen wurde. Damit hatte ich nicht gerechnet. Nachdem ich dieses Problem in den Griff bekommen habe, kommt aber auch gleich das Nächste zum tragen, was ich aber so nicht so einfach lösen kann, da dies ein Problem der verwendeten iCal-Class ist. Diese verarbeitet keine "verschobenen" Termine. Mit der Angabe von RDATE kann man der "Reihe" weitere "Außerderreihetermine" hinzufügen. Dies verarbeitet die Class aber nicht. Somit ist jetzt das Ergebnis, dass der 3.10. korrekt nicht mehr angezeigt wird, aber halt auch nicht der 4.10. sondern erst der Nächste. Da ich die Termine immer selbst eingebe, habe ich es bisher immer so gemacht, dass ich keine Termine verschiebe, sondern einzelne Termine aus der Serie nur rauslösche und einen Einzeltermin an dem entsprechenden Ausweichtermin erstellt habe. Das ist natürlich bei Terminen, die von extern so kommen nicht so schick.
Das Problem ist halt, dass ich entweder die vorhandene Class selber umbauen/erweitern müsste, oder auf eine andere Class o.ä. umbauen müsste. Bisher hatte ich da noch nichts gefunden, was so ähnlich in der Benutzung war wie die derartige Class. Das würde bedeuten, dass das ganze Plugin komplett umgestrickt werden müsste. Dazu habe ich aber keine Zeit. Ich will mir die bisherige Class mal ansehen, ob man da das RDATE relativ schmerzfrei einbau kann.