Zugriff auf Muellkalender

[TomK57]

Hallo Jannis,
ich habe mir die Programme und den Ablauf angeschaut. Aus meiner Sicht spricht nichts dagegen, dass die Anwender den Kalender selber herunterladen und in die Programmumgebung einbinden. Das muss nur einmal bzw. am Anfang des Jahres gemacht werden. Damit wäre auch das https Zugangsproblem umgangen.
Viele Grüße
Thomas

[jdohm]

Das geht leider nicht.
Je nach Stadt ist dein Vorschlag perfekt (und wird auch bereits so gemacht), leider bieten aber nicht alle Städte einen Kalender an, sodass es die Lösung mit Zugriff über das Internet für die Teilnehmer braucht die keinen Kalender haben.

[TomK57]

Mein Thunderbird Kalender kann .ics Kalender exportieren.
Im Anhang ein fiktiver Müllkalender für graue Tonne alle zwei Wochen montags. Händisch erstellt in 5 Minuten. Für alle Tonnen und das ganze Jahr vielleicht eine halbe Stunde Arbeit, wenn die Termine bekannt sin
Muellkalender_1.ics.zip
d.
Das ist nicht elegant aber pragmatisch, oder?

[jdohm]

Super, würde sagen machen wir für alle Städte wo wir keine bessere Lösung haben so!

[TomK57]

So, D1 Mini und LEDs kamen vor ein paar Tagen und jetzt läuft die Software "im Prinzip".
Auffälligkeiten:

1. Die SPIFSS Library is deprecated, neue Library heisst LittleFS.
2. Die Konstruktion strcat("/",DatabaseURL) in ICSParser funktioniert bei mir nicht. Wenn ich den Dateinamen direkt mit dem / übergebe, z.B. "/file.ics" , ist es i.O.
3. ICSParser: Der Search string für das Datum ist Kalender abhängig unterschiedlich. Für meinen Ort ist es "DTSTART:" ohne date = value.
   Meinen Kalender habe ich als Referenz angehängt.
   arb.ics.zip
4. ICSParser: Suchen nach einem Pattern wie "Bioabfall" in meinem Kalender funktioniert nicht.

Verbesserungsvorschläge:

1. Häufigen Zugriff auf Timeserver reduzieren
2. Stromverbrauch reduzieren

Ich schaue mir mal die Powersave Optionen des ESP8266 an und die Verwendung der Realtime Clock.
Ergebnisse demnächst hier, es sei denn Du hast Einwände.

[jdohm]

1. kann gut sein,
2. liegt vermutlich am Wechsel aus 1.
3. müssen wir eventuell Einstellbar machen, scheinbar ist der ICS Standard nicht genau genug (oder wir schauen welche Varianten nach Standard möglich sind und decken diese ab). Zur Not könnte man auch vorher mit suchen und ersetzen zum gleichen Standard kommen.
4. Hast du vor diesem Versuch den Fehler aus 3. Behoben? Es wird immer erst nach dem Tag und dann nach dem Suchbegriff gesucht. Wird kein Tag gefunden, werden auch keine Suchbegriffe überprüft (da kein Tag vorhanden ist, an dem der Suchbegriff überprüft wird).
   Wenn Ja, könntest du mir den Serial log zukommen lassen? Eigentlich sehe ich an dieser Stelle kein Problem. Btw, das sieht man hier: link

Was die Zugriffe angeht, gern kannst du schauen ob du diese reduzieren kannst, Die Clock muss auch nicht mehr als auf ca. 1h genau gehen.
Allerdings darf dies aus meiner Sicht nicht die Komplexität des Projekts erhöhen, das primäre Ziel ist ja kein effektives System sondern Kindern und Jugendlichen Technik näher zu bringen :)

[TomK57]

Fehler aus 3. behoben und hier der Serial Log:

Connected, IP address: 192.168.1.18
date: 22.8.2021
Time: 11:50:53
Bioabfall
print Char:DTSTART:20210906
found Date!, looking for String
Bioabfall
print Char:DTSTART:20210906
heute kein Bioabfall

und hier der Source Code aus dem Programmteil:
------> snip ----->
if(ICSParsery.CheckDate("Bioabfall", 6,9,2021)){
Serial.println("Heute Bioabfall!");
pixels.setPixelColor(2, pixels.Color(15, 15, 15));
pixels.setPixelColor(3, pixels.Color(15, 15, 15));
}
else Serial.println("heute kein Bioabfall");

[jdohm]

Ich nehme an du hast nicht den Beispielkalender genutzt, den du oben hochgeladen hast. (Dort gibt es nur einen Eintrag für den 20210906 und der Log zeigt zwei.)

Dein Kalender ist gänzlich anders strukturiert als die, die ich getestet habe.
In deinem Kalender steht der Abfall vor dem Datum, deswegen kann die Library beim weitersuchen den Eintrag nicht finden.

Ich denke wir müssen uns wirklich noch einmal sehr genau anschauen wie die Kalender aufgebaut sind, ich hatte zwar mehrere getestet, aber scheinbar ist das doch sehr unterschiedlich.
Bei deinem Fall könntest du hier
_file.seek(_file.position()-3,SeekSet); (geht nach gefundenem Datum 3 Zeilen hoch, um wieder vor dem gesuchten Text zu sein)
ergänzen und es würde vermutlich damit zuverlässig laufen, aber wir können ja nicht bei jedem Kalender die library komplett neu schreiben.

[TomK57]

Änderung eingepflegt ->

bool ICSParser::_CheckDateRekursiv(int StartIndex){
_file.seek(StartIndex,SeekSet); //set position to StartIndex bytes from the beginning
Serial.println(_SearchFor);
Serial.print("print Char:");
Serial.println(_StartSearchC);
if(_file.find(_StartSearchC)){ //search for event on the given day
Serial.print("found Date!, looking for String: ");
Serial.println(_SearchFor); // 210821 to check whether pattern is correct
_file.seek((_file.position()-4),SeekSet); // 210821 , tried -3 and -4
if(_file.findUntil(_SearchFor,"END:VEVENT")) return true; //if searced String is in event return true
else return _CheckDateRekursiv(_file.position()) ; //start rekursion, look for next event -> check for String ...
}
return false;
}

Geht aber nicht, pattern wird nicht gefunden. Kalender zum Testen ist "arb.ics"

[jdohm]

Ich kann nur den Tipp geben mit Serial.print() zu arbeiten und zu schauen: in welche Zeile wird gesprungen? Funktioniert es mit dem Kalender von mir? hier ist ein Kalender von Müllmax aus Bochum
Leider habe ich noch nicht alles vom Umziehen am neuen Wohnort & Sortiert und eingeräumt, sodass ich leider gerade keinen ESP8266 finde (ich habe noch welche) um dir zu helfen in dem ich selbst teste.
Gern können wir aber über Zoom/Jitsi daran arbeiten.

[TomK57]

Wenn man erst mal rausgefunden hat, dass der offset für die position in bytes und nicht in Zeilen gerechnet wird, hat man schon gewonnen.
(Steht auch so in der Doku).
Punkt ist erledigt.

[TomK57]

Bis jetzt habe ich folgende allgemeine Suchvorschrift, die passt:
Wenn sich zwischen BEGIN:VEVENT und END:VEVENT eine Zeile mit "DTSTART" UND "Suchdatum" befindet UND eine Zeile mit dem "Suchbegriff", dann haben wir ein gültiges Ereignis gefunden.

[TomK57]

Soll ich die Suche mal entsprechend verallgemeinern?

[jdohm]

Kannst du gern mal probieren. Mein Vorschlag wäre:
Speichern an welcher Position BEGIN:VEVENT gefunden wird, wenn DTSTART gefunden wird bis zum Zeilenumbruch nach dem "Suchdatum" suchen, wird es gefunden zurückspringen zur Position die gesichert wurde und nach dem "Suchtext" suchen bis END:VEVENT.

Ist aber nur ein Gedanke von mir, es gibt sicher auch andere gute Lösungen!

[TomK57]

Vorschlag umgesetzt und getestet mit bochum.ICS und meinem lokalen Kalender.
Dateien angehängt. Schau mal drüber.
ICSParser.zip

[jdohm]

sieht auf den ersten Blick gut aus, machst du einen PR?

[TomK57]

PR = PullRequest? Dabei musst Du mir helfen. Ich habe noch nicht mit Github als Versionsverwaltung gearbeitet. Am besten Du lädst zu einer online session ein, wenn Du abends Zeit hast.