Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Danke an Max a.k.a. l0wside für einen Patch der den crontab erweitert.
Er ist in github zu finden.
Schön, auch mal was beitragen zu können :-)
Der Code hat noch ein paar Probleme, Update folgt. Bitte das erweiterte crontab-Format noch nicht produktiv einsetzen.
Bestehende crontab-Einträge (im bisherigen Format, z.B. crontab = sunrise-5) sind nicht betroffen.
Die Syntax hat sich leicht geändert, da ich die ':' hier gerne unbelegt lassen würde um sie später für Uhrzeiten verwenden zu können.
Ich bin aber leidenschaftslos und für andere Vorschläge/Feedback offen.
Hatte gerade eine Idee, wie wir das vielleicht architektonisch elegant lösen könnten. Der Scheduler berechnet ja aus cycle und crontab, wann er das Item das nächste mal Triggern muss und mit welchem Wert. Nun könnten wir den Items zusätzlich eine Methode spendieren, die der Scheduler abfrägt mit next_time und value als Rückgabe. Damit wäre zumindest mal die Möglichkeit geschaffen, das ganze etwas komplexer werden zu lassen und der Scheduler bleibt sauber.
Wie die Methode in den Items dann genau aufgebaut wird muss man sich noch überlegen. Ganz interessant wäre hier auch sowas wie "Externe Schaltlisten" beim HS... diese könnte man per Logik z.B. aus iCal generieren. Auch könnte man darin dann über die Visu konfigurierte Zeiten irgendwoher auslesen und dem Scheduler übergeben.
ich habe jetzt einen ersten Wurf in git gepusht. Damit lassen sich jetzt mal einfache Schaltuhren auf Itemebene realisieren. Für Logiken habe ich es nicht getestet, aber dort sollte es ebenso funktionieren. Gibt man bei cycle oder crontab einen Doppelpunkt gefolgt von einem Wert an wird dieser als value dem scheduler übergeben und der Logik über das Trigger Objekt zugeführt bzw. dem Item gesetzt. Weiter lassen sich beliebig viele Eintäge in crontab wie bisher durch das Pipesymbol '|' angeben. Folgendes ist nun also möglich:
Dadurch wird das Item um xx:00 Uhr auf 0, um xx:15 Uhr auf 50, um xx:30 Uhr auf 100 und um xx:45 Uhr auf 150 gesetzt.
Code:
[home]
[['itemname']]
type=num
cycle=60 : 0
Setzt den Itemwert jede Sekunde zurück auf 0.
Die Änderung war recht einfach, daher habe ich das mal so integriert.
Das Ändern über die Visu fehlt dabei natürlich noch komplett, hier sollte man dann zunächst überlegen, wie man solche Werte über die Visu ändert so das sie auch persistiert werden und vor allem, wie sie persistiert werden (in eine DB geschrieben, in eine spezielle Konfigurationsdatei in der man Schaltuhren definiert oder in die Konfigurationsdatei selber). Da sollte man noch einiges an Hirnschmalz reinstecken, bevor man hier einen Schnellschuss macht. Evtl. macht hier doch eine ganz andere Implementierung sinn, aber für das einfache Setzen von Werten zu bestimmten Uhrzeiten ist die scheduler Anpassung ausreichend.
Wenn Max dann noch seine Erweiterung der crontab Syntax einbaut, kann man damit schon mal recht mächtige Sachen anstellen. Aber klar, Ziel soll es natürlich sein, eine UZSU über die Visu konfigurieren zu können.
Zeitschaltuhr löst Szene aus (ggf. genügt es dann, jeder Szene eine Zeitschaltuhroption mitzugeben)
genau das was ich meine, nur eben ohne das Zusammenlegen von Szenen und UZSU. Man legt eine Szene an (egal ob in der Konfig oder über die Visu) und definiert eine UZSU die die Szene triggert (auch hier egal ob über die Konfig oder eine Visu). Jedoch kann eine UZSU immer noch auch Items triggern, die keine Szenen sind.
also gut. Dann habe ich als Feature-Request einfach nur:
"Eine UZSU-Aktion soll auch durch eine Item-Änderung (d.h. eine GA) getriggert werden können."
Wir reden glaub immer noch ein wenig aneinander vorbei
Die UZSU triggert eine Szene, genauso kannst du aber auch mittels GA eine Szene triggern. In der Szene sind wiederum die Aktionen definiert, die bei einer Triggerung (egal woher) für einen bestimmten Szenewert ausgeführt werden sollen.
Dann hast du die Szenen in den conf-Dateien und ich welche über die UZSU. Ich finde es nur unschön, dass die Szenenfunktionalität dann zweimal implementiert ist, wenn Martins Anforderung, mehrere Items ändern zu können, mit umgesetzt wird.
Okay, dein "Problem" ist also quasi, dass du nicht einfach eine beliebige Szene über die Oberfläche anlegen kannst, weil es dafür ja noch kein sh.py Item gibt, verstehe ich das richtig? Denn eine bestehende Szene zu ändern soll ja genauso möglich sein, wie die unterschiedlichen Schalthandlungen der UZSU zu ändern. Weil zweimal implementiert ist sie ja nicht. Die Szene bleibt die Szene und die UZSU bleibt die UZSU, aber eine UZSU kann eine Szene triggern und in einer Szene können beliebige andere Items getriggert werden.
Wo taucht hier die UZSU auf? sunset+6 ist ja ein ganz normaler Trigger, keine UZSU.
crontab ist hier die UZSU. Denn was ist denn eine UZSU, einfach mehrere Einträge, wann ein Item einen bestimmten Wert annehmen soll und das kann ich mit crontab erweitert um einen zu setzenden Wert doch erreichen.
[scene_aufstehen]
type = scene
crontab = timer
timer_value = sunrise+6: 1
In der Visu kann ich dann scene_aufstehen.timer_value anpassen, fertig ist die UZSU. Ich würde mich auch um das Parsen des timer_value-Strings kümmern (auch wenn regex-Parsen in Python keine Freude ist).
Den Gegenvorschlag versteh ich nicht. Du kannst doch anstatt timer_value über die Visu zu ändern auch einfach crontab über die Visu ändern und erreichst somit dasselbe.
Nur lässt sich Martins Wunsch, in der Visu die zu setzenden Werte auszuwählen, so nicht umsetzen - die Szene ist ja fix in der conf-Datei festgelegt.
Die Szenen ändern könnte man über die Oberfläche ja ebenfalls. Was natürlich so schwer zu konfigurieren ist, wenn sich die Werte einzelner Szenen Teilnehmer ständig ändern sollen. Dann bräuchte man zig unterschiedliche Szenenkonfigurationen für eine Szene um alle Teilnehmer der Szene mit den entsprechenden Werten zu versehen.
Machen wir es doch mal andersrum... nenne mir bitte mal einen konkreten Anwendungsfall, wo du das brauchen könntest. Denn bei normalen Szenen in KNX kann ich sowas auch nicht machen und mir fällt auch gerade nicht ein, wozu ich das verwenden würde.
das was du möchtest würde doch ohne weiteres funktionieren auch wenn UZSU und Szenen getrennt sind.
Hallo Niko,
also gut. Dann habe ich als Feature-Request einfach nur:
"Eine UZSU-Aktion soll auch durch eine Item-Änderung (d.h. eine GA) getriggert werden können."
Dann hast du die Szenen in den conf-Dateien und ich welche über die UZSU. Ich finde es nur unschön, dass die Szenenfunktionalität dann zweimal implementiert ist, wenn Martins Anforderung, mehrere Items ändern zu können, mit umgesetzt wird.
Das Argument der schnellen Umsetzbarkeit ist natürlich einleuchtend.
[scene_making_love]
type = scene
crontab = sunset+6: 1
Wo taucht hier die UZSU auf? sunset+6 ist ja ein ganz normaler Trigger, keine UZSU.
Gegenvorschlag:
Code:
[scene_aufstehen]
type = scene
crontab = timer
timer_value = sunrise+6: 1
In der Visu kann ich dann scene_aufstehen.timer_value anpassen, fertig ist die UZSU. Ich würde mich auch um das Parsen des timer_value-Strings kümmern (auch wenn regex-Parsen in Python keine Freude ist).
Nur lässt sich Martins Wunsch, in der Visu die zu setzenden Werte auszuwählen, so nicht umsetzen - die Szene ist ja fix in der conf-Datei festgelegt.
Max
P.S.: gibt es den Bedarf an einem Feature, das den crontab wie folgt erweitert?
Code:
crontab = sunrise+1h30m
Das wäre ein Trigger 90 Minuten nach Sonnenuntergang.
Oder auch als zusätzliche Erweiterung:
Code:
crontab = 6.00~sunrise-10m~8.00
Das wäre ein Trigger 10 Minuten vor Sonnenaufgang, allerdings frühestens um 6.00 und spätestens um 8.00 Uhr.
Ersteres läuft schon einigermaßen, letzteres würde ich bei Bedarf auch noch umsetzen.
das was du möchtest würde doch ohne weiteres funktionieren auch wenn UZSU und Szenen getrennt sind. Du definierst die Szene und eine UZSU die die Szene triggert. Durch die Implementierung von Marcus für Szenen würde das ganze so aussehen:
Code:
[scene_making_love]
type = scene
crontab = sunset+6: 1
Also jeden Abend 6 Grad nach Sonnenuntergang würde die Szene "Making Love" aktiviert werden, die wiederum beliebig definiert sein kann. Wie man das ganze in der Oberfläche konfiguriert ist ja erstmal egal. Dort kann man immer noch Szenen zusammen mit der UZSU verwalten, wenn man das möchte.
Diese Vorgehensweise hat aus meiner Sicht zwei Vorteile:
1. Die Implementierung wäre ziemlich minimal invasiv. Marcus hat die Szenen bereits umgesetzt und crontab für Logiken funktioniert auch schon ewig. Diese auch auf Items anzuwenden ist relativ einfach, da der scheduler bereits alles dafür mit bringt.
2. Man kann auch eine UZSU für Items definieren, die keine Szene sind. Und das ist mir sehr wichtig, denn wenn ich z.B. abends alle Rollladen zufahren möchte, dann will ich nicht erst eine Szene anlegen wo ich die Zentral GA eintragen muss und dann die UZSU dafür einstellen. Und ich spreche hier nicht von einem komfortablen Editor für die Visu wo ich mir alles zusammenklicken kann sondern davon, wie ich das auch ohne Editor in der Konfiguration direkt einstellen kann. Denn diese Möglichkeit halte ich nach wie vor für sinnvoll. sh.py hat zwar eine Schnittstelle zur Visu, muss aber auch unabhängig davon konfigurierbar sein, denn nicht jeder will eine Visu verwenden bzw. für manche Einsatzzwecke macht eine Visu keinen Sinn.
Wenn ich dich damit immer noch nicht überzeugen konnte, dann nenne mir doch bitte die konkreten Vorteile, die eine Zusammenlegung von Szenen und UZSU bietet und wie du dir die Konfiguration ohne Visu vorstellst.
2. dass man bei einem Ereignis (nahezu) beliebig viele Telegramme auf den Bus senden kann, mit verschiedenen DPT's.
[...]
Und das alles möglichst schön über Apollo's Visu konfigurierbar
Martin hat sehr schön beschrieben, dass er hier Szenen haben will. Er hat sie nur nicht so genannt.
Und der Wunsch nach dem grafischen Editor war auch nicht von mir.
Szenen haben seine Berechtigung, sollten aber auch unabhängig von einer USZU funktionieren. Damit man Sie z.B. per Schalter und knx dpt 17 wählen kann.
Was spricht dagegen, dass beides möglich ist? Reagieren auf eine GA und auf die UZSU? Logiken können ja auch auf mehrere Dinge triggern.
Das ganze Feature, und die Diskussion, geht auch stark in Richtung grafischer Editor. Und das diskutiere ich hier nicht mal locker flockig. Dafür benötigt es eine separate Schnittstelle bzw. eine heftige Erweiterung. Es sollte hier nur erst mal um die UZSU gehen.
Wenn du die Features "Uhrzeit(en) einstellen" und "mehrere Telegramme triggern" in die UZSU einbaust, hast du die Szenenfunktionalität doch schon fertig.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: