Modul für Terminansicht CALVIEW

[chris1284]

mmm mit den alten readings macht das wenig sinn ( da man das in der readingsgroup nicht wirklich rausfiltern kann).
ich hab's in post 1 geändert, einmal neu laden!

mit den default-readings bleiben State, c-today, c-tomorrow und c-term drin (wegen der readingsgroup -> post 1)

[tagedieb]

wow!!!
Du bist ja schnell 
Dankeschön ,ich werde es gleich anwenden



Funktioniert hervorragend 

[klausw]

hier die Lösung für eine Readingsgroup für Termine im neuen Syle

Ah so geht das. Danke für den Tipp, klappt super

leider klappt es mit dem Notify nicht (ich nutzen den gleichen code wie vorher im at)

das steht dann im def vom readingsproxy:

Code Auswählen Erweitern


<Datum>,<Uhrzeit>,<Text>,<Endet am>,<End um> View_Kalender_Daniela:<Morgen>,tomorrow_c-today: 103d_btime,tomorrow_c-today: 103d_summary,tomorrow_c-today: 103d_edate,tomorrow_c-today: 103d_etime View_Kalender_Daniela:<Heute>,today_c-today: 103d_btime,today_c-today: 103d_summary,today_c-today: 103d_edate,today_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime View_Kalender_Daniela:t_c-today: 103d_bdate,t_c-today: 103d_btime,t_c-today: 103d_summary,t_c-today: 103d_edate,t_c-today: 103d_etime
es macht den Eindruck als würde sprintf nicht gehen.
Seltsamerweise funktioniert es ja im at.

mir ist nochwas aufgefallen:
Termine, die über Mitternacht hinausgehen scheinen um Mitternacht zu verschwinden (z.B. 11.1. 18:00 - 12.1. 8:00)

und gleich noch etwas:
mein logfile wir mit verbose 3 Einträgen gefüllt:

Code Auswählen Erweitern

2015.01.12 01:06:50 3: get Kalender_Daniela start v9vr5iztfiztfp3idfbbfia04googlecom : 27.02.2015 08:00:00
2015.01.12 01:06:50 3: get Kalender_Daniela summary v9vr5iztfiztfp3idfbbfia04googlecom : Tagschicht
2015.01.12 01:06:50 3: get Kalender_Daniela end v9vr5iztfiztfp3idfbbfia04googlecom : 27.02.2015 18:00:00
obwohl ich im modul calendar als auch im calview verbose auf 1 stehen habe.

[klausw]

Hallo Chris

und gleich noch etwas:
mein logfile wir mit verbose 3 Einträgen gefüllt:

Code Auswählen Erweitern

2015.01.12 01:06:50 3: get Kalender_Daniela start v9vr5iztfiztfp3idfbbfia04googlecom : 27.02.2015 08:00:00
2015.01.12 01:06:50 3: get Kalender_Daniela summary v9vr5iztfiztfp3idfbbfia04googlecom : Tagschicht
2015.01.12 01:06:50 3: get Kalender_Daniela end v9vr5iztfiztfp3idfbbfia04googlecom : 27.02.2015 18:00:00
obwohl ich im modul calendar als auch im calview verbose auf 1 stehen habe.

das schein zu passieren wenn fhem() im Modul aufgerufen wird.
Wenn ich get in der Eingabezeile ausführe wird nix geloggt, aber wenn ich { fhem("get ...") } ausführe dann wird es geloggt.
Im Verbose 3 stört das ein bisschen :/
Kannst du anstelle von

Code Auswählen Erweitern

fhem("deletereading $name .*");
nicht

Code Auswählen Erweitern

delete ($hash->{READINGS}{<readingname>})
verwenden? Das ist vermutlich auch schneller, da du direkt im Modul bleibst.
Für

Code Auswählen Erweitern

fhem("get $calendername start $uid");
könntest du

Code Auswählen Erweitern

CallFn($calendername, "GetFn", $calendernamehash, "$calendername start $uid");
nehmen.

[chris1284]

so tief stecke ich in den fhem-internen funktionen (noch) nicht drin. ich habe heute bereits (wenn ich mal zeit hatte) versucht rauszubekommen wie man zb readings im code am besten löscht (meint mal gesehen zu haben das es über ($hash... geht).

somit --> danke klausw für die sehr nützliche info, (hier fehlt der daumenhoch-smilie)  . ich werde es gleich umsetzen

edit: habe zugriff auf sf bekommen und werde heute evtl noch das modul einchecken

[chris1284]

Hallo klausw,

ich hätte da mal eine frage,wie muss ich $calendernamehash verstehen?

Code Auswählen Erweitern

delete ($hash->{READINGS}{<readingname>})
habe ich, da die readings ja unterschiedlich bennat sein können, per

Code Auswählen Erweitern

delete ($hash->{READINGS});eingebaut

[klausw]

Code Auswählen Erweitern

delete ($hash->{READINGS});eingebaut

wenn das alle readings löscht ist es super. Ich hätte es komplizierter gemacht...mich einer foreach schleife.

ich hätte da mal eine frage,wie muss ich $calendernamehash verstehen?

das ist der $hash des calenar devices
bekommst du mit $defs{$sdev}
sollte so gehen:

Code Auswählen Erweitern

CallFn($calendername, "GetFn",  $defs{$calendername}, "$calendername start $uid");

[chris1284]

Code Auswählen Erweitern

my $terminstart = CallFn($calendername, "GetFn", $defs{$calendername},(" ","start", $uid));
my $termintext = CallFn($calendername, "GetFn", $defs{$calendername}, (" ","summary", $uid));
my $terminend = CallFn($calendername, "GetFn", $defs{$calendername}, (" ","end", $uid));
danke, so gehts. werde bis morgen testn und die version dann einchecken. die logeinträge sind damit vergangenheit

[klausw]

danke, so gehts. werde bis morgen testn und die version dann einchecken. die logeinträge sind damit vergangenheit

ein Traum, du machst riesen Fortschritte   
Dein Modul ist für mich definitiv ein Gewinn.

Ich hätte noch eine Idee.
Dein Modul mach ja im Zusammenhang mit readingsgroup erst richtig Sinn.
Was hältst du davon, die Modifizierung der Readings DEF nicht einem at oder notify zu überlassen, sondern selbst auszulösen.

Mit einem Attribut, das den entsprechenden readingsproxy Namen enthält. Und dem auslösen eines "CommandModify(...)"
Lässt sich das direkt im Modul erledigen. das ist die Funktion, die hinter modify steht (theoretisch kann man die readings Group sogar aus dem Modul heraus machen).

[chris1284]

ich hatte auch schon die idee mit der DEF des Calview gleich den Wunschnamen der rg mitzugeben, sie anzulegen und diese dann im Updateprozess mit zu betanken.
ein rgmodus würde auch sinn machen (<today>,<tomorrow>,<today+tomorrow>,<all>,....)

Code Auswählen Erweitern

define <Name> CALVIEW <Calendar> <modus> <rgname>

das ist für den user weniger arbeit, fehler werden seitens des Anwenders ausgeschlossen.

evtl. probleme / fragen :
- user benennt rg um, ändert aber die calview-def nicht
-> abfangbar in dem man beim update prüft ob die rg noch definiert ist und wenn nicht, sie stumpf wieder erstellt oder den part auslässt

- wo die neue rg erstellen damit der user sie gleich findet ?
-> raum erzeugen und sie dort reinpacken scheint mir am einfachsten (room CALVIEW_RG)

- die angabe der rg lieber in der def oder als attribut? wo liegen die vor-/nachteile (wenn es welche gibt)
- die angabe des rgmodus lieber in der def oder als attribut? wo liegen die vor-/nachteile (wenn es welche gibt)


ich habe modul gerade eingechecked und werde den thread wohl noch verschieben lassen nach

FHEM Forum » FHEM - Hausautomations-Systeme »  Unterstützende Dienste da dort auch Calendar liegt

jetzt muss ich nur noch sehen wie ich CHANGED , history, MAINTAINER.txt anpasse. muss ich dafür einen patch schreiben?

[MDegelmann5455]

Hallo chris1284

Hab gestern dein Modul nach deiner Anleitung in fhem eingebaut und hab zwei Sachen im Reading  feststellen müssen

1 - bei mir zeigt es die Termine in der reihenfolge Morgen - Heute - usw an (war aber einfach im AT zu ändern)
2 - bei mir zeigt es vor jeden Termin den Namen des calview Moduls an dann erst Heute, Start, Name, end Datum, end Zeit an

kann das sein?

[chris1284]

Reading  feststellen müssen

richtiger wäre in der Readingsgroup aus dem Beispiel, diese gehört (noch) nicht mit ins modul. aber da es ohne kaum sinn macht habe ich ein beispiel für eine mögliche anwendung mitgegeben

zu 1 - ja, das war der richtige weg. dem user ist so überlassen ob er heut/morgen/heute und morgen/alles sehen will

zu 2 - dafür musst du in der readingsgroup das attribut "nonames" setzen.

[MDegelmann5455]

Ok danke

Und Daumen hoch füe deine Arbeit 

[klausw]

ich hatte auch schon die idee mit der DEF des Calview gleich den Wunschnamen der rg mitzugeben, sie anzulegen und diese dann im Updateprozess mit zu betanken.
ein rgmodus würde auch sinn machen (<today>,<tomorrow>,<today+tomorrow>,<all>,....)

Code Auswählen Erweitern

define <Name> CALVIEW <Calendar> <modus> <rgname>

das ist für den user weniger arbeit, fehler werden seitens des Anwenders ausgeschlossen.

Das ist natürlich die Ideallösung.

evtl. probleme / fragen :
- user benennt rg um, ändert aber die calview-def nicht
-> abfangbar in dem man beim update prüft ob die rg noch definiert ist und wenn nicht, sie stumpf wieder erstellt oder den part auslässt

- wo die neue rg erstellen damit der user sie gleich findet ?
-> raum erzeugen und sie dort reinpacken scheint mir am einfachsten (room CALVIEW_RG)

- die angabe der rg lieber in der def oder als attribut? wo liegen die vor-/nachteile (wenn es welche gibt)
- die angabe des rgmodus lieber in der def oder als attribut? wo liegen die vor-/nachteile (wenn es welche gibt)

Genau, ich würde vorm update prüfen, ob das readingsgroup device existiert und wenn nicht ein neues anlegen. Das alte wird dann einfach nicht mehr aktualisiert.
Einen Raum würde ich weglassen.
Nach dem Anlgen erscheint es sowieso unten in deinem Modul, da kann jeder draufklicken und einen Raum vergeben.
Obwohl, wenn du den Raum anlegst kann man den auch noch ändern...also egal

Ein attribut kann man im nachhinein einfacher ändern, zudem hast du ein dropdown menü, was die Konfiguration erleichtert.

ich habe modul gerade eingechecked und werde den thread wohl noch verschieben lassen nach

jetzt muss ich nur noch sehen wie ich CHANGED , history, MAINTAINER.txt anpasse. muss ich dafür einen patch schreiben?

Ja, das verschieben macht Sinn, oder du legst einen Neuen an und sperrst diesen (Verweis auf den Neuen im erstem Post). Hier steht ja viel kram drin, welcher der Vergangenheit angehört.
Wie checkst du es ein? Machst du es über Tortoise SVN? Dort kannst du einfach die beiden Dateien editieren und mit SVN commit hochladen.

[KernSani]

ich hatte auch schon die idee mit der DEF des Calview gleich den Wunschnamen der rg mitzugeben, sie anzulegen und diese dann im Updateprozess mit zu betanken.

Grundsätzlich finde ich den Gedanken gut, aber bitte nur optional, also m.E. eher attribut, wenn kein's da ist wird auch nix betankt... Ich hätte z.B. gerne die Option, nicht alle readings zu zeigen (Beim Abfallkalender nur Datum und Text).

Danke,

Grüße,

Oli