Support-Thread zum iCal Plugin

[Maexle]

Onkelandy
Danke Dir

[Onkelandy]

Maexle Smartvisu zeigt den Kalender ja nur an. Mit dem Plugin kannst du ihn für Logiken und Automatisierungen nutzen. Was auch immer... Heizungssteuerung abhängig von Anwesenheit am nächsten Tag, smarter Weckruf, Messages/Mails bei bestimmten Ereignissen (Müllkalender, etc.)

[Morg]

BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:MESZ
DTSTART:20000326T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:MEZ
DTSTART:20001029T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE

Parsing wäre für - einzelne - Sonderfälle sicherlich möglich, aber nicht schön. Besser wäre, wenn die Importroutine die in der ICS angegebenen Zeitzonen auch berücksichtigen würde...

[Maexle]

Hallo zusammen,

Eine Frage zum Kalender:
Smartvisu bietet auf der Config-Seite ja bekanntermaßen die Möglichkeit Kalender einzubinden. (bei mir eine lokal abgelegt .ics Datei) dieser Kalender wird mir auf der "Hauptseite" angezeigt (3 Kalendereinträge für die Mülltonnen).
Im SHNG-Admin unter Plugin habe ich kein "ical Plugin" eingerichtet. Für was benötige / kann das Plugin genutzt werden?
Die Doku schreibt "Das iCal Plugin dient dazu, Kalender (online oder offline) einzulesen und nach Einträgen zu durchsuchen." Wie kann ich mir das vorstellen?

Danke euch

[Onkelandy]

Ich hab jetzt ein Problem mit der Zeitzone entdeckt. Dürfte in der Praxis nicht sonderlich relevant sein - würde es dennoch gerne sauber lösen.
Problem 1: In manchen Einträgen (Einladung von extern über Google) wird als Zeitzone "//Microsoft/utc" angegeben. Das führt auch zu einem Error im Plugin.
Problem 2: In allen anderen Einträgen hab ich "W. Europe Standard Time" und nicht ein von dateutil.tz verstandene Zeitzone.

Hab mal bisschen recherchiert, die Auflösung von Problem 2 ist standardmäßig nur auf Windowsmachinen möglich. Ansonsten kommt über tzget None retour. Nun gibt es zwei Problemlösungen:
a) die "speziellen" Zeitzonenbeschreibungen im Plugin entsprechend auflösen, zB "W. Europe Standard Time" = UCT+1:00
b) Die Infos aus der ICS Datei übernehmen. Dort stehen nämlich zu Beginn nach BEGIN:VTIMEZONE entsprechende Infos drin, va. zur Sommerzeit. Was ja bei Lösung a nicht der Fall wäre.

Meine konkrete Frage: sind in euren ICS Dateien anfangs Zeitzonen definiert? Habt ihr bei euren Events überall eine saubere Zeitzone wie "Europe/Berlin" oder was tut sich da so? Entsprechende Codeauszüge wären hilfreich. Gerne auch sachdienliche Hinweise zum korrekten Einbinden der Sommerzeit.

[Morg]

Oder lass das plugin die iCal-Datei per shell('wget...') holen...

[Onkelandy]

Das ist echt ganz komisch. Jeden Tag failt jeder zweite Verbindungsversuch (im Stundentakt). Ich dreh glaub auch mal den Cycle hoch und schau, was dann passiert. Immer, wenn ich manuell wgette, klappt es.

[Morg]

Läuft bei mir jetzt seit ca. 2 Wochen, aktualisiert (unnötigerweise) alle 5 Minuten, und ich habe noch nicht einen Fehler bekommen.

Gegenstelle ist eine selbst gehostete NextCloud-Instanz, nginx, https, basic auth (Anmeldung schon per https, danach nochmal an der Cloud).

Grundsätzlich könnte man unterstellen, dass die "großen" Cloudservices in der derzeitigen Homeoffice-Schwemme vielleicht eher Probleme haben - aber wenn du manuell beliebig oft zugreifen kannst, klingt das als Argument etwas dünn

[Onkelandy]

Bin ich eigentlich der Einzige, der mit dem periodischen Download des Kalenders Probleme hat? Ich rufe im 2-Stunden-Takt eine URL https://outlook.office365.com/owa/calendar/... auf. Mit curl und wget habe ich kein Problem, die Datei herunter zu ziehen. Vom Plugin bzw. Network lib bekomme ich aber regelmäßig diesen Fehler:

2020-04-21 13:46:26 WARNING lib.network Error sending GET request to https://outlook.office365.com/owa/calendar/.../reachcalendar.ics: HTTPSConnectionPool(host='outlook.office365.com', port=443): Read timed out. (read timeout=60)

Hab das nochmals beobachtet. Jede 2. Stunde gibt es ein Problem, dazwischen klappt es. Da ich aber manuell dazwischen beliebig oft per wget zugreifen kann, ist mir das echt ein Rätsel, warum das so passiert..

[Onkelandy]

danke, scheint mir ne gute Lösung zu sein.

[Morg]

Nur zur Info: ich bin darüber gestolpert, dass in meinem Log die Logindaten aus der Kalender-URI (https://userass@domain.tld/...) aufgetaucht sind. Das fand ich etwas ungünstig, darum habe ich dazu ein Update geschrieben und als PR eingestellt.

[aschwith]

Hallo zusammen,

ich bin endlich mal dazu gekommen, mir das Problem bei der Extraktion der verschiedenen Zeitzonen für Start und End Zeitpunkte anzuschauen. KHome hatte den Effekt auch schon beobachtet und einen Fix vorgeschlagen. Ich habe das Plugin diesbezüglich überarbeitet. Die Zeitzonen von Einzelterminen, Serienterminen und ganztägigen Terminen werden von Google im iCAL Format unterschiedlich repräsentiert. Sie sollten jetzt alle korrekt decodiert und in die lokal für smarthomeNG definierte Zeitzone konvertiert werden. Rückmeldungen von Testern sind willkommen. Der Fix liegt im Develop-Repo.
VG
Alex

[Msinn]

from lib.network import Http
File "/usr/local/smarthome/lib/network.py", line 1045
async def __handle_connection(self, reader, writer):

Das Netwok Plugin benötigt wie man in der Fehlermeldung sieht asyncio. asyncio gibt es erst ab Python 3.5.

Zwei Lösungsmöglichkeiten:

• Eine ältere Version des network Plugins einsetzen, welche kein asyncio benötigt.
• Eine neuere Python Version einsetzen. Vorzugsweise Python 3.6 oder 3.7 (Die aktuelle Version ist zwar bereits Python 3.8, allerdings ist SmartHomeNG noch nicht gegen Python 3.8 getestet.

[bmx]

Ja, das mit der Kompatibilität hatte ich vermutet. Das kommende 1.7 wird sicher ein Python 3.6 benötigen. Wenn Du also zukunftssicher aufgestellt sein willst, dann wäre ein Buster schon sinnvoll. Ich weiß allerdings nicht, inwieweit das für den Beaglebone Black geht. (z.B. hier im Blog)
Alternativ kann man auch Python 3.6 losgelöst vom System installieren, aber das können wir natürlich nicht leisten das alles zu dokumentieren.

[GHild]

Habe gerade gesehen, dass Python 3.4 nicht mehr von der aktuellen SmarthomeNG (V 1.6) unterstützt wird. Es ist dann scheinbar das erste Mal, dass ich in diese Inkompatibilität gelaufen bin.

Ich gehe also zunächst auf ein älteres SmarthomeNG Release zurück und aktualisiere bei Gelegenheit mein Debian 8.11/Jessie System auf meinem BeagleBone Black. Damit sollte diese Inkompatibilität ja behoben sein.