Neues Modul für Abfallkalender ABFALL

Begonnen von uniqueck, 27 Januar 2016, 01:02:41

Vorheriges Thema - Nächstes Thema

Otto123

ZitatUi, dann werde ich mal eine Leiche ausgraben,
für mich steht eben die Frage ob man weiter schminkt. Ich wollte nur auf das Problem hinweisen: auch die schönste Leiche fängt irgendwann an ...
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

yersinia

Zitat von: OdfFhem am 14 November 2022, 18:51:59Angenommen, Dich interessieren nur die Abfallsorten-Readings für die jeweils nächste Abholung, dann könnte CALVIEW hilfreich sein.
Ich habe mich in einem ähnlichen Kontext (aber eher rudimentär) mit CALVIEW beschäftigt und konnte nicht wirklich eine Funktion analog zum ABFALL-Modul feststellen. Kann CALVIEW mir pro Abfall-Art ein reading zur Verfügung stellen? Ich erwarte keine kalendarische Ansicht oder Auflistung wie im Wiki gezeigt. Next wäre auch charmant, benötige ich persönlich aber nicht.

Zitat von: betateilchen am 14 November 2022, 20:07:49Wo ist das Problem?
Gemessen an dem, was und wie das ABFALL-Modul es zur Verfügung stellt, ist dein Vorschlag (noch) keine alternative Lösung. Ja, ich kann damit aus den Kalendereinträgen readings generieren; allerdings bekomm ich für jeden Termin ein reading - interessanterweise auch für Termine, welche laut hideOlderThan (1d) und hideLaterThan (43d) gar nicht auftauchen sollten in diesem Zusammenhang habe ich gleich cutoffOlderThan und cutoffLaterThan kennengelernt; trotzdem würde ich erwarten, dass Termine älter als 1d rausgefiltert werden (cutoffOlderThan=1d):
2022.11.15 09:09:42 1: DEBUG>setreading garbage gelberSack_date 03.11.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Papier_date 24.11.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Papier_date 27.10.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Restmuell_date 14.12.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Restmuell_date 16.11.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Restmuell_date 19.10.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Restmuell_date 03.11.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Restmuell_date 06.10.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Restmuell_date 30.11.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage gelberSack_date 19.10.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage gelberSack_date 16.11.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage gelberSack_date 06.10.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage gelberSack_date 14.12.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage Papier_date 22.12.2022
2022.11.15 09:09:42 1: DEBUG>setreading garbage gelberSack_date 30.11.2022


Darüber hinaus habe ich wieder myUtils-Code, der hier unterstützen muss. Bis hierher ist das ABFALL-Modul noch einfacher zu nutzen. Auch wenn es gut gereift ist.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

betateilchen

Zitat von: yersinia am 15 November 2022, 09:43:10
allerdings bekomm ich für jeden Termin ein reading
trotzdem würde ich erwarten, dass Termine älter als 1d rausgefiltert werden (cutoffOlderThan=1d):

Falsche Erwartungshaltung, die daraus resultiert, dass Du die Arbeitsweise des Calendar-Moduls noch nicht ganz verstanden hast.

Zitat von: yersinia am 15 November 2022, 09:43:10
Darüber hinaus habe ich wieder myUtils-Code, der hier unterstützen muss. Bis hierher ist das ABFALL-Modul

What the fuck ???

Kurzer Code in myUtils unter Deiner eigenen Kontrolle oder ein uraltes Modul, das keiner mehr pflegt - was ist Dir lieber?
Und wo ist eigentlich der Unterschied - beides ist Code außerhalb des Calendar-Moduls.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

yersinia

Zitat von: betateilchen am 15 November 2022, 11:18:04Falsche Erwartungshaltung, die daraus resultiert, dass Du die Arbeitsweise des Calendar-Moduls noch nicht ganz verstanden hast.
Das mag sein. Aber möglicherweise kannst du mir dann erklären, wie bei
ZitatcutoffOlderThan <timespec>
cutoffLaterThan <timespec>
Diese Attribut schneidem alle Termine weg, die eine Zeitspanne cutoffOlderThan vor bzw. cutoffLaterThan nach der letzten Aktualisierung des Kalenders enden. Der Zweck dieses Attributs ist es Speicher und Verarbeitungszeit zu sparen. Auf solche Termine kann gar nicht mehr aus FHEM heraus zugegriffen werden.
mit cutoffOlderThan 1d sowas passiert:
2022.11.15 09:09:42 1: DEBUG>setreading garbage Papier_date 27.10.2022

Meine Erwartungshaltung am Calendar-Modul ist, dass es, grob umschrieben, Kalender-Informationen in FHEM zur Verfügung stellt. Nicht mehr und nicht weniger. Ich erwarte nicht, dass es spezifische Termine out-of-the-box rausfiltert und wie auch immer optimiert zur Verfügung stellt.

Zitat von: betateilchen am 15 November 2022, 11:18:04What the fuck ???

Kurzer Code in myUtils unter Deiner eigenen Kontrolle oder ein uraltes Modul, das keiner mehr pflegt - was ist Dir lieber?
Und wo ist eigentlich der Unterschied - beides ist Code außerhalb des Calendar-Moduls.
sigh, ja, wieder das Thema fhem für nerds vs fhem auch für anfänger. Nicht jeder ist Perl-Crack. Ja, kurzer Code in myUtils, der aber nicht die gleichen Readings wie das ach-so-tote ABFALL-Modul zur Verfügung stellt. Zumindest bis jetzt nicht. Für den Anwendungsfall habe ich bisher keinen Ersatz gefunden: ein(e) reading(sgruppe) der Abfallarten mit (nur!) der nächsten Abholung. Nicht alle Abholungen. Keine vergangenen Abholungen.
Kann dies das Calendar Modul? Ich weiss es nicht. Soll es das überhaupt können? Ich wage es zu Bezweifeln.
Wäre CALVIEW eine Option? Scheint mir bisher nicht so. Aber da hätten wir ja wieder das Thema, dass man dafür ja ein weiteres Modul neben dem Calendar-Modul nutzen würde - da kann man bei dem, bisher imho dennoch gut funktionierendem, ABFALL-Modul bleiben.

Möglicherweise entspricht meine Meinung auch hier nicht der mehrheitlichen Ansicht.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

betateilchen

Zitat von: yersinia am 15 November 2022, 11:51:43
keinen Ersatz gefunden: ein(e) reading(sgruppe) der Abfallarten mit (nur!) der nächsten Abholung. Nicht alle Abholungen. Keine vergangenen Abholungen.
Kann dies das Calendar Modul?

Das Calendar Modul kann zumindest alle nach dieser Vorgabe relevanten events zurückliefern.
Was der Anwender dann daraus macht, bleibt völlig dem Anwender überlassen.

Zitat von: yersinia am 15 November 2022, 11:51:43
Das mag sein. Aber möglicherweise kannst du mir dann erklären, wie beimit cutoffOlderThan 1d sowas passiert:
2022.11.15 09:09:42 1: DEBUG>setreading garbage Papier_date 27.10.2022

Völlig logisch, falls Du das über den von mir genannten Codeschnipsel probiert hast: onCreateEvent wird vor der Auswertung der definierte Zeitgrenzen ausgeführt.

Genau deshalb hatte ich geschrieben, dass man nicht den kompletten Kalender bis 2030 importieren sollte, weil sonst für jeden Termin, der im Kalender steht, ein onCreateEvent ausgeführt wird.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: yersinia am 15 November 2022, 11:51:43
sigh, ja, wieder das Thema fhem für nerds vs fhem auch für anfänger.

Zugegeben: onCreateEvent ist eine Funktion, die eher für nerds hilfreich ist. Aber man kann damit wirklich ALLES umsetzen, was man gerne mit einem Kalendereintrag tun möchte und nicht out-of-the-box funktioniert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

yersinia

Zitat von: betateilchen am 15 November 2022, 12:43:27Das Calendar Modul kann zumindest alle nach dieser Vorgabe relevanten events zurückliefern.
Was der Anwender dann daraus macht, bleibt völlig dem Anwender überlassen.
Korrekt. Dies entspricht auch meinem Verständnis.

Zitat von: betateilchen am 15 November 2022, 12:43:27Völlig logisch, falls Du das über den von mir genannten Codeschnipsel probiert hast: onCreateEvent wird vor der Auswertung der definierte Zeitgrenzen ausgeführt.
Interessant, ich habe die commandref dahingehend anders verstanden. Wahrscheinlich eher eine philosophische Frage, ob man erst für alle Termine jeweils ein Event erzeugt und dann den Zeitraum einschränkt oder erst den Zeitraum einschränkt und dann nur Events für die Teilmenge aller Termine erstellt. Ist auch hier OT.

Zitat von: betateilchen am 15 November 2022, 12:43:27Genau deshalb hatte ich geschrieben, dass man nicht den kompletten Kalender bis 2030 importieren sollte, weil sonst für jeden Termin, der im Kalender steht, ein onCreateEvent ausgeführt wird.
Zumal Calendar wildcards kann und man nichtmal das Jahr manuell nachpflegen müsste.

Zitat von: betateilchen am 15 November 2022, 12:49:58Zugegeben: onCreateEvent ist eine Funktion, die eher für nerds hilfreich ist. Aber man kann damit wirklich ALLES umsetzen, was man gerne mit einem Kalendereintrag tun möchte und nicht out-of-the-box funktioniert.
Ja, das ist auch nicht schlecht. Und kann man, bei guter Doku, auch einem Anfänger zumuten. Mir scheint als würde aber für jeden Termin ein Event generiert und dann diese Funktion aufgerufen. Das ABFALL-Modul fragt die Termine über ein get events ab:
get calendar events format:custom="$U" series:next
um diese weiter zu verarbeiten.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

OdfFhem

Zitat von: yersinia am 15 November 2022, 09:43:10
Ich habe mich in einem ähnlichen Kontext (aber eher rudimentär) mit CALVIEW beschäftigt und konnte nicht wirklich eine Funktion analog zum ABFALL-Modul feststellen. Kann CALVIEW mir pro Abfall-Art ein reading zur Verfügung stellen? Ich erwarte keine kalendarische Ansicht oder Auflistung wie im Wiki gezeigt. Next wäre auch charmant, benötige ich persönlich aber nicht.

Ich benutze folgende FHEM-Devices und erhalte alle Informationen, die ich pro Abfallart für eine (readingGroup, FTUI, ...)-Darstellung benötige:


defmod Abfallkalender Calendar ical file FHEM/abfall.ics.cfg 86400
attr Abfallkalender hideLaterThan 40d
attr Abfallkalender hideOlderThan 1s



defmod AbfallView4Bio CALVIEW Abfallkalender 1
attr AbfallView4Bio event-on-change-reading .*
attr AbfallView4Bio filterSummary Abfallkalender:.*Bio.*
attr AbfallView4Bio maxreadings 1
attr AbfallView4Bio modes next
attr AbfallView4Bio weekdayformat de-short

...

defmod AbfallView4Papier CALVIEW Abfallkalender 1
attr AbfallView4Papier event-on-change-reading .*
attr AbfallView4Papier filterSummary Abfallkalender:.*Papier.*
attr AbfallView4Papier maxreadings 1
attr AbfallView4Papier modes next
attr AbfallView4Papier weekdayformat de-short



defmod rg_Abfallkalender readingsGroup <>,<Datum>,<Tag>,<Termin>\
NAME=AbfallView.*:t_001_bdate,t_001_weekdayname,t_001_summary


bartman121

#1418
irgendwie gleitet die Diskussion ab ....

Yersinia meint, dass es easy mit Wildcards zu lösen ist die Kalender URL zu nutzen um die nicht im def zu tauschen.

Sorry Kollege, du wirst genau dort Schwierigkeiten kriegen, wenn du das Enddatum bei meiner URL angeben musst. Die tollen Wildcards geben nur das aktuelle Datum wieder. Egal wie ich es drehe, es wird immer einen Zeitpunkt geben, wo der Kalender nicht lang genug ist. Wenn ich zum Beispiel das Jahr mit Wildcard schreibe, dann werden definitiv in der letzten Woche des Jahres Termine fehlen. Es gibt kein "%G + 1", oder doch?

Ich löse das jetzt über ein AT und "defmod -silent"

Jetzt kommen hier  Leute um die Ecke und zeigen wie einfach das doch mit x-Devices geht .... Kollege, du hast zwei verschiedene Tonnen eingebunden, deine Lösung wird genau dann zum Problem, wenn dein Entsorger mehrere Tonnen in einen Termin schreibt (wie bei mir). Schwachsinn ist es trotzdem, Calendar->x-Calview->Readingsgroup .... zumal die ReadingsGroup vermutlich nicht mal events liefert auf die man triggern könnte, also nochmal ein notify hinten dran, mit breitem-regexp

Fhem lebt doch davon, dass einige kluge Menschen Module für Anwendungsfälle bauen, die einem das "Selbstgecode" abnehmen sollen. Nach eurer Logik könnte man doch auch gleich alle http-API-basierten Protokolle abschaffen und auf HTTPMOD verweisen?
Natürlich kann man jeden Anwendungsfall auch selbst entwickeln, aber wenn das das Ziel von fhem sein soll, dann empfehle ich die Entwicklung einzustellen, die User laufen bereits jetzt weg, weil es deutlich einfachere Lösung gibt. Ich freue mich auch über den thread zu dem Thema ob fhem für Anwender oder nerds entwickelt wird. Ich persönlich sehe mich als nerd und lasse mich durchaus darauf ein neue Wege zu gehen, aber der Großteil der Anwender wird damit eher Probleme haben.

Ich für meinen Teil werde die Lösung von Betateilchen umsetzen, er hat das sehr schön beschrieben und konstruktiv beigetragen.

Ansonsten nochmal großen Dank an den Schöpfer des Abfall-Moduls, eigentlich wäre es cool, wenn das Modul irgendwie ins offizielle fhem findet, natürlich mit einem aktuellen maintainer.

Grüße
Andreas


OdfFhem

Zitat von: bartman121 am 15 November 2022, 21:39:32
Kollege, du hast zwei verschiedene Tonnen eingebunden, deine Lösung wird genau dann zum Problem, wenn dein Entsorger mehrere Tonnen in einen Termin schreibt (wie bei mir).
Der reguläre Ausdruck kommt auch damit klar ...

Zitat von: bartman121 am 15 November 2022, 21:39:32
Schwachsinn ist es trotzdem, Calendar->x-Calview->Readingsgroup .... zumal die ReadingsGroup vermutlich nicht mal events liefert auf die man triggern könnte, also nochmal ein notify hinten dran, mit breitem-regexp
readingsGroup erleichtert einem nur einen "Kontrollblick" - hat ansonsten keinerlei Bedeutung. CALVIEW liefert bei Änderungen Events ... Verwertung erlaubt ...

yersinia

Zitat von: bartman121 am 15 November 2022, 21:39:32Yersinia meint, dass es easy mit Wildcards zu lösen ist die Kalender URL zu nutzen um die nicht im def zu tauschen.

Sorry Kollege, du wirst genau dort Schwierigkeiten kriegen, wenn du das Enddatum bei meiner URL angeben musst. Die tollen Wildcards geben nur das aktuelle Datum wieder. Egal wie ich es drehe, es wird immer einen Zeitpunkt geben, wo der Kalender nicht lang genug ist. Wenn ich zum Beispiel das Jahr mit Wildcard schreibe, dann werden definitiv in der letzten Woche des Jahres Termine fehlen. Es gibt kein "%G + 1", oder doch?
Dies ist nicht meine Aussage gewesen. Und ja, du kannst begrenzt mit wildcards arbeiten, hast aber an den Rändern definitiv Probleme mit Terminen. Ich dachte bezgl Wildcards eher an dieses Format:
https://stadtplan.dresden.de/project/cardo3Apps/IDU_DDStadtplan/abfall/ical.ashx?STANDORT=2380&DATUM_VON=01.%m.%Y&DATUM_BIS=31.12.%Y
Klar, wenn du am 28.12. wissen willst, ob am 2.1. abgeholt wird, hast du mit dieser Definition ein Problem.

[OT]
Zitat von: bartman121 am 15 November 2022, 21:39:32Jetzt kommen hier  Leute um die Ecke und zeigen wie einfach das doch mit x-Devices geht .... Kollege, du hast zwei verschiedene Tonnen eingebunden, deine Lösung wird genau dann zum Problem, wenn dein Entsorger mehrere Tonnen in einen Termin schreibt (wie bei mir). Schwachsinn ist es trotzdem, Calendar->x-Calview->Readingsgroup .... zumal die ReadingsGroup vermutlich nicht mal events liefert auf die man triggern könnte, also nochmal ein notify hinten dran, mit breitem-regexp

Fhem lebt doch davon, dass einige kluge Menschen Module für Anwendungsfälle bauen, die einem das "Selbstgecode" abnehmen sollen. Nach eurer Logik könnte man doch auch gleich alle http-API-basierten Protokolle abschaffen und auf HTTPMOD verweisen?
Natürlich kann man jeden Anwendungsfall auch selbst entwickeln, aber wenn das das Ziel von fhem sein soll, dann empfehle ich die Entwicklung einzustellen, die User laufen bereits jetzt weg, weil es deutlich einfachere Lösung gibt. Ich freue mich auch über den thread zu dem Thema ob fhem für Anwender oder nerds entwickelt wird. Ich persönlich sehe mich als nerd und lasse mich durchaus darauf ein neue Wege zu gehen, aber der Großteil der Anwender wird damit eher Probleme haben.
Amen.
[/OT]

Zitat von: bartman121 am 15 November 2022, 21:39:32Ansonsten nochmal großen Dank an den Schöpfer des Abfall-Moduls, eigentlich wäre es cool, wenn das Modul irgendwie ins offizielle fhem findet, natürlich mit einem aktuellen maintainer.
Ist das eine Bewerbung?



@OdfFhem: wie bindest du dies in FTUI3 ein? Über calview component oder auch via icons?
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

bartman121

#1421
Zitat von: OdfFhem am 16 November 2022, 00:29:24
Der reguläre Ausdruck kommt auch damit klar ...

Sicher?
Die Frage ist hier vermutlich was klarkommen bedeutet:
Mein Entsorger schreibt mehrere Tonnen in einen Termin, damit ergibt sich als Summary zum Beispiel: "Bio-Tonne, Papier-Tonne"

Bei deinem Beispiel würden beide Calview-Devices diesen Termin bereitstellen, mit dem Ergebnis, dass du zweimal das gleiche Ereignis-triggern würdest, falls du hinten dran Automatismen hättest. Natürlich kann man das alles gegeneinander verriegeln, aber günstig wäre, wenn man vorher alle Eventualitäten ausschließen könnte.


Zitat von: yersinia am 16 November 2022, 08:43:04
Ist das eine Bewerbung?
Ich denke eher nicht, dass mein Wissen hierzu ausreicht, im Gegensatz zu scheinbar vielen anderen gehört die Commandref nicht zu meiner Abendlektüre. Auch Perl ist keine meine besonderen Stärken.

Falls es noch Jemanden interessiert:
hier der Code:

sub waste_createReadings {
  use POSIX qw( strftime );
  use Time::Local;
  use Switch;

  my $e_start   = shift;
  my $e_summary = shift;
   $e_summary =~ s/Leerung //g; #Erstmal Prefix in Summmay löschen
     $e_summary =~ s/, /KOMMA/g; # , durch das Wort KOMMA ersetzen
$e_summary =~ s/ /_/g; #Leerzeichen durch Unterstrich ersetzen
  my $dt = strftime("%d.%m.%Y", localtime($e_start)); #Nur Darum des Events ermitteln
  my @tonnen = split(/KOMMA/,$e_summary); #shift @tonnen; #Events splitten falls durch KOMMA getrennt
 
  #beutzte Variablen deklarieren
  my $reading_date;
  my $reading_name;
  my $reading_epoch;
  my $reading_days_left;
  my $reading_weekday;
  my $days_left;
  my $weekday;
 
  my $calendar="BALU4.WASTE";
 
  foreach my $a (@tonnen) {
 

  #Reading-Namen zusammensetzen
$reading_date = "waste_".$a."_date";
$reading_name = "waste_".$a."_name";
$reading_epoch = "waste_".$a."_epoch";
$reading_days_left = "waste_".$a."_days_left";
$reading_weekday= "waste_".$a."_weekday";
#Wochentag ermittelm
$weekday = strftime("%A",localtime($e_start));
switch($weekday) {
case "Monday"  {$weekday = "Montag"}
case "Tuesday" {$weekday = "Dienstag"}
case "Wednesday" {$weekday = "Mittwoch"}
case "Thursday" {$weekday = "Donnerstag"}
case "Friday" {$weekday = "Freitag"}
case "Saturday" {$weekday = "Samstag"}
case "Sunday" {$weekday = "Sonntag"}
else { $weekday = "undef" }
}

#Wenn Readings nicht existiert oder $e_start < aktuell eingetragenes Datum
if ((ReadingsNum($calendar,$reading_epoch,0) > $e_start) || (ReadingsNum("BALU4.WASTE",$reading_epoch,0) == 0)) {
fhem("setreading BALU4.WASTE $reading_epoch $e_start");
fhem("setreading BALU4.WASTE $reading_name $a");
fhem("setreading BALU4.WASTE $reading_date $dt");

# days left berechnen
$days_left = int(($e_start - time)/86400);
fhem("setreading BALU4.WASTE $reading_days_left $days_left");
fhem("setreading BALU4.WASTE $reading_weekday $weekday");
}


}
 

  }


Ich bin mi sicher, dass man den Code auch noch deutlich schöner schreiben kann, bitte aber um Rücksicht, dass das eben nicht mein Spezialgebiet ist.

Dazu aber folgende Fragen:
Ich lösche die Readings beim event "retrieved" vom Calendar-Device ... gibt es einen schöneren Weg?

Danach wird ja meine Sub aufgerufen, weil die Events EINZELN created werden, dummerweise kann ich keine wirkliche Reihenfolge erkennen in welche die Termine reingeschoben werden, kann man die Reihenfolge beeinflussen? Wenn ja, dann könnte man sich das dämliche Mehrfachändern der Readings sparen.

Aktuell habe ich halt das Problem, dass durch die Mehrfachänderung der Readings halt auch mehrfach events ausgelöst werden. Das würde eine eventuell nachfolgende Automatisierung ziemlich nerven.

Ansonsten ist die Berechnung von days_left noch nicht korrekt. Hat dazu Jemand einen eleganteren Ansatz?

Grüße

Andreas




the ratman

Zitat von: bartman121 am 15 November 2022, 21:39:32Ansonsten nochmal großen Dank an den Schöpfer des Abfall-Moduls, eigentlich wäre es cool, wenn das Modul irgendwie ins offizielle fhem findet, natürlich mit einem aktuellen maintainer.
da schließ' ich mich vollumfänglich an ...
→do↑p!dnʇs↓shit←

yersinia

@bartman121: danke, dass du trotz der Hürden dennoch deine Erfahrung/Erkenntnis mit uns teilst. :)
Zitat von: bartman121 am 16 November 2022, 09:38:54Falls es noch Jemanden interessiert:
hier der Code:
Ich bin auch nur noob und kann kluk (pun intended) zusammenkopieren - finde deinen Ansatz allerdings interessant. Ich habe mir erlaubt, es etwas anzupassen - vlt kannst du es unter deinen Bedingungen testen? Im Grunde habe ich nur Kleinkram geändert und mich vom ABFALL-Modul inspirieren lassen:
sub garbage_pickup_readings {
# onCreateEvent => {main::garbage_pickup_readings("<DEVICENAME>",$e->start,$e->summary)}
  use POSIX qw( strftime );
  use Time::Local;
  my $caldev = shift;
  my $e_start   = shift;
  my $e_summary = shift;
  my $dt = strftime("%d.%m.%Y", localtime($e_start)); #Nur Datum des Events ermitteln
  my $devhash = $defs{$caldev};
   
  my %replacement = ("\\ " => "_", "\\," => "KOMMA", "ä" => "ae", "Ä" => "Ae", "ü" => "ue", "Ü" => "Ue", "ö" => "oe", "Ö" => "Oe", "ß" => "ss", "Leerung " => "");
  my $replacementKeys = join ("|", keys(%replacement));
  $e_summary =~ s/($replacementKeys)/$replacement{$1}/eg;
  #$e_summary =~ tr/a-zA-Z0-9\-_//dc;

  my @tonnen = split(/KOMMA/,$e_summary); #shift @tonnen; #Events splitten falls durch KOMMA getrennt

  #beutzte Variablen deklarieren
  my $reading_date;
  my $reading_name;
  my $reading_epoch;
  my $reading_days_left;
  my $reading_weekday;
  my $days_left;
  my $weekday;
  my %wdDE = ("Monday" => "Montag", "Tuesday" => "Dienstag", "Wednesday" => "Mittwoch", "Thursday" => "Donnerstag", "Friday" => "Freitag", "Saturday" => "Samstag", "Sunday" => "Sonntag");
  my $wdDEKeys = join ("|", keys(%wdDE));

  readingsBeginUpdate($devhash);
 
  foreach my $a (@tonnen) {
  #Reading-Namen zusammensetzen
$a = makeReadingName($a);
$reading_date = "waste_".$a."_date";
$reading_name = "waste_".$a."_name";
$reading_epoch = "waste_".$a."_epoch";
$reading_days_left = "waste_".$a."_days_left";
$reading_weekday= "waste_".$a."_weekday";

#Wenn Readings nicht existiert oder $e_start < aktuell eingetragenes Datum
#days left berechnen - wenn days left < 0 => skip
$days_left = int(($e_start - time)/86400);
if (($days_left >= 0) &&
((ReadingsNum($caldev,$reading_epoch,0) >= $e_start) || (ReadingsNum($caldev,$reading_epoch,0) == 0))) {

#Wochentag ermitteln
$weekday = strftime("%A",localtime($e_start));
$weekday =~ s/($replacementKeys)/$replacement{$1}/eg;

readingsBulkUpdate($devhash, $reading_epoch, $e_start);
readingsBulkUpdate($devhash, $reading_name, $a);
readingsBulkUpdate($devhash, $reading_date, $dt);
readingsBulkUpdate($devhash, $reading_days_left, $days_left);
readingsBulkUpdate($devhash, $reading_weekday, $weekday);
}
  }
  readingsEndUpdate($devhash, 1);
}

Die Funktion erwartet als erstes den Devicnamen als Parameter wenn du es über onCreateEvent aufrufst:
{main::garbage_pickup_readings("BALU4.WASTE",$e->start,$e->summary)}
Das ganze geht sicher auch eleganter. ::)

Zitat von: bartman121 am 16 November 2022, 09:38:54Ich lösche die Readings beim event "retrieved" vom Calendar-Device ... gibt es einen schöneren Weg?

Danach wird ja meine Sub aufgerufen, weil die Events EINZELN created werden, dummerweise kann ich keine wirkliche Reihenfolge erkennen in welche die Termine reingeschoben werden, kann man die Reihenfolge beeinflussen? Wenn ja, dann könnte man sich das dämliche Mehrfachändern der Readings sparen.

Aktuell habe ich halt das Problem, dass durch die Mehrfachänderung der Readings halt auch mehrfach events ausgelöst werden. Das würde eine eventuell nachfolgende Automatisierung ziemlich nerven.
Diese Fragen stellen sich mir auch schon seit die Diskussion hier Fahrt aufnahm; und die Bedenken (der weiteren Verareitung) teile ich ebenso. Wie schon erwähnt - ist das Calendar-Modul überhaupt für diese Thema geeignet? Ich bin mir nicht sicher. Alternativen (exkl ABFALL)?  Keine Ahnung. :(

Zitat von: bartman121 am 16 November 2022, 09:38:54Ansonsten ist die Berechnung von days_left noch nicht korrekt. Hat dazu Jemand einen eleganteren Ansatz?
Die ist mMn in Ordnung, übersehe ich was?
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

bartman121

#1424
woop, danke erstmal fürs aufhübschen, funktioniert FAST:

  • die ReadingNamen sind minimal anders, aber das ist kein Problem ....
  • das Splitten bei "," geht nicht, das "," wird bei deiner Version nicht durch KOMMA ersetzt. Ersetze ich das Komma vorher, wie in meinem Beispiel dann läuft es
die ReadingNamen sind minimal anders, aber das ist kein Problem ....

Zum Thema days_left:
bei meinem Kalender startet der Termin um 7:00Uhr.

Nehmen wir als an: 18.11.2022 07:00Uhr ist $e_start
Es ist aktuell 16.11.2022 12:45Uhr

Bei meiner Rechnung kommt dann 1,xx raus, durch die Konvertierung zu int kommt halt 1 raus. Jetzt kann man das drehen wie man will, 1 Tag ist definitv falsch. Außerdem ziehen wir die Startzeit heran, am Tag der "Abholung" wird dadurch days_left negativ werden, bewirkt die konvertierung. Mit der Prüfung ob days_left <= 0 ist wir der Termin dann bereits ignoriert, das kann gewünscht sein, würde ich aber so nicht machen wollen.

Richtig wäre:
man müsste sowohl "jetzt" und "$e_start" auf das Datum reduzieren. Das Könnte man vermutlich so machen, indem man den Zeiten "normiert"...also in etwa so:
$days_left = int((time_str2num(strftime("%Y-%m-%d", localtime($e_start))." 00:00:00") - time_str2num(strftime("%Y-%m-%d", localtime(time)). " 00:00:00"))/86400);

Auch hier wieder der Hinweis, dass das sicher auch schöner geht .....

Ansonsten noch ein Kleiner Copy&Paste-Fehler:
falsch:
$weekday =~ s/($replacementKeys)/$replacement{$1}/eg;
richtig:
$weekday =~ s/($wdDEKeys)/$wdDE{$1}/eg;
Aus meiner Sicht, sollte man sich aber nicht an die "onCreateEvent"-Geschichte anhängen, sondern eigentlich müsste man ein notify verwenden, alle Events holen und dabei "sinnvoll sortieren", die Events dann mit einer Routine (ähnlich zu dieser) durchrattern. Dann würde man sich Mehrfach-Änderungen der Readings sparen. Weiterhin kann man so auch auf das löschen der Readings verzichten. Aber genau dann wird die Unterscheidung zwischen myUtils und eigenem Modul nicht mehr eindeutig ;)

Ich würde gern Yersinia als neuen Maintainer ins Rampenlicht schieben :P

Danke schonmal