Neues Plugin: UZSU (Universelle Zeitschaltuhr)

[Roookie]

1. Wie definierst du mehrere Schaltzeiten für ein Item?

Mal von den Wiederholungen abgesehen, kennt eine Schaltuhr auch nur eine Schaltzeit sowie einen Wert. (Eben das was ein crontab Eintrag an Funktionalität hergibt) Das heisst für eine Rolladensteuerung (morgens hoch und abends runter) braucht man 2 Schaltuhren.

2. Wie fügst du während der Laufzeit eine neue Schaltzeit für ein Item hinzu?

Aus Anwendersicht: Gar nicht, jedenfalls solange es keine Verwaltung über die Visu gibt.
Aus Pluginsicht über die Funktionen add, change und delete, die die .conf Datei aktualisieren. Hoffentlich habe ich deine Frage richtig verstanden....

Da habe ich gestern kurz mit Marcus drüber diskutiert. Das Problem mit den Methoden war, dass man das Visu Plugin anpassen müsste, was eigentlich unschön ist, da du so zwei Plugins eng miteinander koppelst. Klar könnte man jetzt irgend einen Message Bus für die Interpluginkommunikation einbauen... aber dann musst du immer noch auf Visu Seite auch das ganze JS anpassen. Da die smartVISU auf Treiber basiert, müsstest du den sh.py Treiber abermals um etwas erweitern, was nur in Verbindung mit diesem Treiber verwendet werden kann.
Durch die Verwendung der jetzigen Item Lösung funktioniert die Persistenz und die Abfrage über die Visu out-of-the-box.

Gut, da fehlt mir natürlich das Wissen über die Gesamtzusammenhänge. Für mich hat sich das aber so dargestellt, dass es irgendwann mal möglich sein soll, aus der Visu heraus Teile von smarthome.py wie Zeitschaltuhren, Logiken, Scenen usw. zu konfigurieren. (Wäre jedenfalls aus Anwendersicht wünschenswert.) Das das jetzt schon ohne irgendwelche Anpassungen an den "Schnittstellen" möglich ist, war mir nicht klar.

EDIT: ach und wegen time und dt... time war notwendig, da man in einem datetime keine sunrise und sunset verarbeiten kann. Für die Berechnung der rrules brauche ich allerdings ein datetime als Startwert. Ist etwas unschön, aber was besseres ist mir nicht eingefallen.

Dann erzeuge dir doch das dt zur Laufzeit und lies das Datum aus dem time Feld. Oder kann da so viel Mist drin stehen, dass du das Datum als solches nicht erkennst?

VG
Oliver

[2ndsky]

Ich hätte das Thema UZSU folgendermassen umgesetzt:
An zentraler Stelle z.B. im Verzeichnis "smarthome/uzsu/" werden in einer .conf die Schaltuhren hierarchielos definiert

1. Wie definierst du mehrere Schaltzeiten für ein Item?
2. Wie fügst du während der Laufzeit eine neue Schaltzeit für ein Item hinzu?

Solange es keine Visubearbeitung gibt, können die Uhren an zentraler Stelle händisch verwaltet werden.

Da hast du recht, ohne Visu ist das noch schwierig. Aber du kannst auch einfach deine vorgeschlagenen Listen dennoch in "smarthome/uzsu/" ablegen und dir eine kleine Logik schreiben, die diese parst und die Werte den entsprechenden Items zuweist. Oder du trägst dir das ganze in einen Kalender ein und schreibst ne Logik, die den Kalender parst. Also damit geht schon ziemlich viel.

Der späteren Visu könnten die Daten dann über die nun nicht mehr vorhandenen Funktionen add, remove, update und get/list zur Verfügung gestellt werden.

Da habe ich gestern kurz mit Marcus drüber diskutiert. Das Problem mit den Methoden war, dass man das Visu Plugin anpassen müsste, was eigentlich unschön ist, da du so zwei Plugins eng miteinander koppelst. Klar könnte man jetzt irgend einen Message Bus für die Interpluginkommunikation einbauen... aber dann musst du immer noch auf Visu Seite auch das ganze JS anpassen. Da die smartVISU auf Treiber basiert, müsstest du den sh.py Treiber abermals um etwas erweitern, was nur in Verbindung mit diesem Treiber verwendet werden kann.

Durch die Verwendung der jetzigen Item Lösung funktioniert die Persistenz und die Abfrage über die Visu out-of-the-box.

Prinzipiell kann man also mit dieser Umsetzung deinen naiven Ansatz ohne Probleme umsetzen... aber eben auch noch viel mehr machen als das

EDIT: ach und wegen time und dt... time war notwendig, da man in einem datetime keine sunrise und sunset verarbeiten kann. Für die Berechnung der rrules brauche ich allerdings ein datetime als Startwert. Ist etwas unschön, aber was besseres ist mir nicht eingefallen.

[Roookie]

Warum so umständlich? Aber vielleicht sieht es ja nur für mich so aus, weil ich noch recht grün hinter den Ohren bin, was dieses Projekt angeht ;-)

Ich hätte das Thema UZSU folgendermassen umgesetzt:
An zentraler Stelle z.B. im Verzeichnis "smarthome/uzsu/" werden in einer .conf die Schaltuhren hierarchielos definiert
[schaltuhr1]

name = #name der Schaltuhr
*dt = #wenn man mit time das Gleiche erreichen kann, wofür brauchts dann dt?
value =
active =
time =
rrule =
item = #das oder die Items die geschaltet werden sollen

[schaltuhr2]
.....

Solange es keine Visubearbeitung gibt, können die Uhren an zentraler Stelle händisch verwaltet werden. Der späteren Visu könnten die Daten dann über die nun nicht mehr vorhandenen Funktionen add, remove, update und get/list zur Verfügung gestellt werden.

War das zu naiv gedacht?

VG
Oliver

[2ndsky]

habe gerade nochmal etwas mit der Visu gespielt. Macht es aus eurer Sicht Sinn, dass es ein übergeordnetes "active" gibt, dass die UZSU eines gesamten Items deaktiviert? Wenn ja, würde ich den type des mit uzsu_item attributierten Items von list auf dict ändern und dort dann ein dict mit { 'active': True, 'list': [{...}, {...}] } ablegen. Die bisherige Liste wäre also im dict unter 'list' abgelegt. Dadurch könnte man evtl. noch weitere übergeordnete Elemente wie z.B. Filter oder Bedingungen für das Ausführen der UZSU ablegen.

[2ndsky]

Habe gerade meine Änderungen in Git getan und meinen Eingangspost überarbeitet. Die alte Vorgehensweise habe ich mal noch stehen gelassen, damit man darüber diskutieren kann.

[SvStefan]

Tolle Sache, können glaub ich viele brauchen!
Meldest du dich, wenn es soweit fertig ist, dass wir testen können?
Jetzt müssen wir nur mehr ein Widget zum Konfigurieren in der SmartVISU bauen. :-)

LG Stefan

[2ndsky]

Okay, vergesst meine obige Beschreibung. Ich habe gerade einen besseren Weg gefunden. Melde mich nochmal

[henfri]

Danke auch von mir!

[pfischi]

Schonmal dickes Danke fürs Plugin.

Grüsse,

Stefan

[2ndsky]

UPDATE 2:

zu Verwendung des Plugins bitte die Doku aus Github verwenden.

Nur diese ist wirklich aktuell und sollte mit dem Entwicklungsstand übereinstimmen!!!

UPDATE:

unten findet ihr noch den alten Text zum Vergleichen.

Ich habe mir gestern nochmal Gedanken gemacht, wie wir das über den Websocket bekommen könnten. Eigentlich hätte man jetzt das Visu Plugin anpassen und auch auf Client Seite die ganze Widget Implementierung erweitern müssen. Daher habe ich das Plugin jetzt umgeschrieben. Anstatt mit add, remove, update und get zu Arbeiten, verwende ich nun einfach ein separates Item. Ich zeige am Besten ein Beispiel:

[eg]
    [[wohnen]]
        [[[kugellampe]]]
            type=bool
            visu_acl=rw

            [[[[uzsu]]]]
                type=dict
                uzsu_item=eg.wohnen.kugellampe
                cache=True
                visu_acl=rw

Das item selber ist nun vom type list und speichert eine Liste aller Schalteinträge. Mit uzsu_item gibt man nun das Item an, dass von dieser "Schaltuhr" geschaltet wird. Durch cache = True ist automatisch die Persistenz erledigt und SQLite kann entfallen. Mittels visu_acl = rw kann man die Schaltuhren out-of-the-box über die Visu anzeigen und ändern.

Ein Eintrag in der Schaltliste ist ein dict mit folgenden key/value Paaren (sind die gleichen wie bisher):

- dt: Datum und Uhrzeit wann der Wert gesetzt werden soll
- value: Wert der gesetzt werden soll
- active: True wenn der Eintrag aktiv sein soll, andernfalls False
- time (optional): Ein String der ähnlich crontab die Uhrzeit von dt mit Astrofunktionen übersteuert. Also z.B. "17:00<sunset".
- rrule (optional): Dieser Parameter ist der eigentliche Clou an der ganzen Sache. Hiermit lassen sich per rrule aus dem RFC 2445 (http://www.ietf.org/rfc/rfc2445.txt) Regeln für wiederkehrende Einträge angeben. Das Format stammt ursprünglich von iCal Kalendereinträgen und sollte somit ziemlich flexibel für alles notwendige sein.

Zum Testen kann man dann z.B. über die interaktive Konsole folgendes machen:

sh.eg.wohnen.kugellampe.uzsu({'active':True, 'list':[
{'value':1, 'active':True, 'rrule':'FREQ=DAILY;INTERVAL=2;COUNT=5', 'time': '16:30'},
{'value':0, 'active':True, 'rrule':'FREQ=DAILY;INTERVAL=2;COUNT=5', 'time': '17:30'}
]})

Das toggelt den Status des entsprechenden Items für zehn Minuten jede Minute.

Was haltet ihr davon?

UPDATE ENDE

--------------------------------------------------

Hallo Leute,

wie bereits angekündigt, habe ich gerade eben mein UZSU Plugin im develop Branch eingestellt. Items müssen mit "uzsu = True" attributiert werden, um vom Plugin beachtet zu werden. Anschließend hat man vier Zugriffsmethoden "get", "add", "update" und "remove" um die Einträge eines Items verwalten zu können. Alle Einträge werden in einer SQLite Datenbank unter <<smarthome_dir>>/var/db/uzsu.db gespeichert (solange nicht anderes angegeben wurde). Alte, abgelaufene Einträge werden vom Plugin automatisch gelöscht. Ein Eintrag kann folgende Parameter haben:

- item: Das Item für den die nachfolgenden Parameter gesetzt werden sollen.
- dt: Datum und Uhrzeit wann der Wert gesetzt werden soll
- value: Wert der gesetzt werden soll
- active: True wenn der Eintrag aktiv sein soll, andernfalls False
- time: Ein String der ähnlich crontab die Uhrzeit von dt mit Astrofunktionen übersteuert. Also z.B. "17:00<sunset".
- rrule: Dieser Parameter ist der eigentliche Clou an der ganzen Sache. Hiermit lassen sich per rrule aus dem RFC 2445 (http://www.ietf.org/rfc/rfc2445.txt) Regeln für wiederkehrende Einträge angeben. Das Format stammt ursprünglich von iCal Kalendereinträgen und sollte somit ziemlich flexibel für alles notwendige sein.

Hier mal einige Beispiele mit denen ich das Plugin getestet habe:

sh.uzsu.add(sh.item1, datetime.datetime.now() + datetime.timedelta(minutes=2), '1')

sh.uzsu.add(sh.item1, datetime.datetime.now() + datetime.timedelta(minutes=2), '1', True, rrule='FREQ=MINUTELY;INTERVAL=2;COUNT=5')
sh.uzsu.add(sh.item1, datetime.datetime.now() + datetime.timedelta(minutes=3), '0', True, rrule='FREQ=MINUTELY;INTERVAL=2;COUNT=5')

sh.uzsu.add(sh.item1, datetime.datetime.now() + datetime.timedelta(minutes=2), '1', True, '17:40')

sh.uzsu.add(sh.item1, datetime.datetime.now() + datetime.timedelta(minutes=2), '0', True, '17:00<sunset<18:30', rrule='FREQ=DAILY;INTERVAL=2;COUNT=5')

sh.uzsu.add(sh.item1, datetime.datetime.now() + datetime.timedelta(minutes=2), '0', True, '7:00<sunrise<8:30', rrule='FREQ=DAILY;INTERVAL=2;COUNT=5')

sh.uzsu.update(sh.item1, 1, active=False)
sh.uzsu.update(sh.item1, 1, active=True)

Die update und remove Methode haben als zusätzlichen Parameter die ID des zu ändernden bzw. löschenden Eintrags. Das ist die SQLite Datenbank ID. Für die direkte Verwendung des Plugins ist das zwar nicht sehr einfach, aber notwendig um die jeweiligen Einträge eindeutig identifizieren zu können. Da das Plugin hinterher ja nicht mehr manuell bedient werden soll, sondern über eine Visu oder ähnliches, sollte das kein Problem sein. Über die get Methode kommt man an alle Einträge eines Items und kann sich damit auch die IDs ansehen.

Ich habe das ganze jetzt über mehrere Tage ausgiebig getestet und bin soweit zufrieden. Dennoch bitte ich hier vor allem die etwas erfahreneren Entwickler sich das ganze auch mal genauer an zu sehen. Wenn jemand Probleme/Fehler feststellen sollte, bitte mit ausführlicher Fehlerbeschreibung und Debug Log. Ansonsten kann ich euch leider nicht helfen. Ein Tipp noch, achtet darauf, dass die Zeitzone und die Längen- und Breitenangaben in der etc/smarthome.conf richtig sind, sonst wird nach UTC Zeit gearbeitet

Ich freue mich auf erste Erfahrungsberichte und Kritiken.