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.
ich denke der Code hat keine Probleme. Er hat wenig mit Deiner Implementierung zu tun. Ich habe die RegEx ersetzt.
Hallo Marcus,
ich bin etwas verwundert. Die Regexp waren in Ordnung, der Fehler lag woanders. Vielleicht kannst du ja mal klarstellen, welchen Code du akzeptierst und welchen nicht. Wenn du jede Einreichung ohnehin umschreibst, brauche ich mir nicht halbe Nächte um die Ohren zu schlagen bzw. kann mich um andere Themen kümmern.
tut mir Leid Dich verärgert zu haben. Bei Änderungen an den lib-Files oder an bin/smarthome.py bin ich eher vorsichtig.
Ich kann gerne Versuchen die Kriterien für Patches klarzustellen. Von Oben nach Unten wird die Liste allerdings immer unschärfer.
Ein Diff gegen den (aktuellen) github master branch
pep8 Konformität (abgesehen von Linien-Länge)
Fehlerbehandlung
Anzahl der Fehler im Patch
Usability, wie sieht die Konfig für den User aus
Passt der Diff zu dem restlichen Code
Klarheit des Codes, kann ich Ihn einfach nachvollziehen. Wie werden z.B. Variablen benutzt.
Komplexität des Codes - hängt mit der Klarheit zusammen.
Inwieweit ich von der Notwendigkeit des Patches/Features überzeugt bin. Kann ich die Beweggründe nachvollziehen? Wie groß ist der Nutzen für alle User?
Edit: Soll nicht heißen das alle erfüllt sein müssen, es hilft aber.
Allerdings bin ich bei meinem letzten Versuch (https://knx-user-forum.de/smartvisu/...eren-kann.html) am Verständnis von JavaScript und jQueryMobile gescheitert, bzw. ich würde mich erstmal lange einarbeiten müssen, da ich davon absolut keinen Plan habe.
Visu-seitig schiele ich mal v.a. zu Niko rüber, da Niko ja schon gezeigt hat, dass er mit o.g. Tools gut klar kommt. Ich will gerne versuchen auf der smarthome.py Seite die Voraussetzungen zu schaffen. Ich kann auch versuchen JavaScript-Hilfe zu leisten...
Was wir aber bräuchten wäre wohl ein Konzept!?
Eine Uhr, die ein (Achtung, KNX-Denke!) Zeit-GAD bekommt, dies anzeigt und eben bei Änderung zurückschreibt
Als Erweiterung obiges mit einem Datum?
Was machen mit "Wochentage selektieren"? Wie definiert man Zeiträume?
Wie definiert man die GADs? Gibt es Visu-seitig so etwas wie geeignete Datentypen oder wären das alles Strings? Oder doch alle "Zahlen" einzeln?
Diese beiden "Items" (smarthome.py-Denke) müssten dann von einer Logik entsprechend verarbeitet werden.
wie in einem anderen Thread schon erwähnt, habe ich mir etwas gedanken gemacht. Auf smartVISU Seite fehlt so ziemlich alles was dafür notwendig ist. Auf sh.py Seite ist schon vieles da und daher sollte die Änderung dort minimalinvasiv gehen und auch werden (um nicht zu viel umstellen zu müssen). Hier mal meine Idee:
- sh.py seitig:
Ähnlich der Szenen erstellen wir in dem lib Ordner eine timer.py (Namen vorerst mal noch unerheblich). Diese funktioniert grundlegend erstmal wie scene.py. Sie liest aus einem speziellen Ordner Konfigurationsdateien, in denen die Schaltlisten definiert sind. Jede Zeile einer solchen Datei enthält einen Crontab Eintrag (also wann welcher Wert gesetzt werden soll). Der Dateiname der Konfigurationsdatei ist (wie bei den Szenen auch) der Pfad zu einem Item. Damit kann man also erstmal eine Liste mit Schaltbefehlen für ein bestimmtes Item ablegen.
Wie bereits vorgeschlagen, brauchen wir ein Attribut an den Items, die den Einsatz eines Timers steuert. Bisher war ich für timer=yes. Mir gefällt aber die Idee die ein Vorgänger bereits hatte nun besser es mittels crontab=timer zu lösen. In diesem Fall darf auch kein weiterer Eintrag bei crontab verwendet werden, da es sonst zu unübersichtlich wird. Sonst weiß man nämlich nicht, warum ein Item jetzt seinen Wert verändert hat, wegen Crontab oder wegen dem Timer.
EDIT: um das nochmal klar zu machen, crontab funktioniert dann wie bisher weiter. Nur sobald 'timer' als Wert vorkommt, darf nur noch 'timer' und nichts anderes mehr vorkommen.
timer.py geht also alle Items durch und wenn crontab = timer, dann lädt es die entsprechende Konfiguration aus dem timer Ordner und übergibt sie mit scheduler.change an den Scheduler. Dadurch kann eine UZSU erstmal mit Konfigurationsdateien erstellt werden.
Weiter soll die timer.py dann noch Methoden erhalten, um eine Liste aller Schaltzeiten zurückzugeben und neu zu setzen. Beim Setzen werden die neuen Schaltzeiten in die Konfigurationsdatei des Items geschrieben und gleichzeitig dem Scheduler übergeben.
crontab = timer könnte man dann auch für Logiken implementieren.
- visu Plugin
Das Visu Plugin muss dann die Möglichkeit erhalten, bestimmte Attribute eines Items abfragen zu können und nicht nur den Wert. Damit kann man dann erstmal den Wert von crontab abfragen. Ist dieser gleich timer, zeige ich die Möglichkeit, eine UZSU zu definieren überhaupt erst an. Außerdem brauchen wir eine Schnittstelle und ein Datenformat für Listen, um dann die Einträge der UZSU abfragen zu können. Entweder bekommen die Items noch eine Methode um die Liste der UZSU abzufragen, oder das visu Plugin fragt direkt bei timer.py für das Item nach. Das gleiche beim Setzen einer UZSU. Prinzipiell werden dann aber einfach alle Einträge der UZSU Konfiguration an die smartVISU geschickt und von der smartVISU gesetzt.
- smartVISU seitig:
Wenn man Attribute von Items abfragen kann, kann man zumindest mal das Icon für die UZSU anzeigen. Anschließend brauchen wir erstmal eine Liste, die dynamisch aus dem Backend geladen und angezeigt wird. Kompliziertert wird dann schon, wie wir die crontab Einträge leserlich darstellen, also "werktags um acht Uhr aber erst nach Sonnenaufgang" (und das auch noch für alle Sprachen). Weiter brauchen wir dann ein Widget, das sämtliche Möglichkeiten bietet, die man mit crontab einstellen kann. Da bin ich aber auch noch nicht so weit, hier einen guten und einfachen Weg gefunden zu haben.
Was haltet ihr von der sh.py seitigen Umsetzung? Kritik und Verbesserungsvorschläge werden gerne angenommen
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
ich dachte zugegebenermaßen an etwas Minimalistischeres. Zudem zweistufig:
1. Stufe:
Ähnlich einem "Bool" ein "Date" oder "Time", das zur Visu übertragen, angezeigt und geändert werden kann.
Beispiel:
Bool-GAD/Item - kann in Visu mit verschiedenen buttons/switches etc geändert werden. Was dass dann bedeutet kann durch eine Logik in sh.py entschieden werden.
Analog dazu:
Time-GAD/Item - in sh.py/Python "time", (z.B. KNX DPT 11), kann in der Visu dann auch angezeigt und geändert werden.
2. Stufe:
Wenn dieses Item dann Trigger (über normales watch_item) für eine Logik ist (da kann ggfl. sogar mit enforce_updates gearbeitet werden), kann die Logik mit dem Python-Time-Object dann legendäre Dinge tun. Hier könnte es dann evtl. eine Referenz-Implementierung einer UZSU geben. Dafür bräuchte man doch nicht mals neue Funktionen im Scheduler, oder?
Vorteil den ich sehe: Ist irgendwie generischer. Die Date/Time-Typen können auch mal für andere "Plugins"/Technologien benutzt werden, und man kann flexibel bei der Implementierung der UZSU. Zudem bleibt der Kern-Code schlanker!?
Unabhängig der Philosophien bezüglich der sh.py-Seite: Wäre es nicht schon mal ein Anfang, die Anzeige und Änderung von Date/Time-GADs in Angriff zu nehmen? Gibt es da für JavaScript eine übliche Encodierung?
mit einem "date" oder "time" Item, kann dieses Item aber genau einen Wert annehmen. Dadurch kannst du keinerlei Astro Funktionen oder wiederholende Werte (alle Werktage, jeden 2. Dienstag im Monat) abbilden. Deshalb dachte ich daran, die Vorteile von crontab zu nutzen. Damit hast du alle Möglichkeiten, die auch crontab kann.
Kennst du die UZSU vom Homeserver? Da kannst du für ein Item eine Liste mit beliebigen Schaltzeiten festlegen und welchen Wert das Item zu einer Zeit annehmen soll. Das wäre mit deiner Vorgehensweise IMHO recht schwer umsetzbar.
EDIT: was natürlich nicht heißen soll, dass ein "date" oder "time" Typ nicht sinnvoll ist. Eine Umsetzung dafür wäre sicherlich interessant für andere Anwendung, auch um Logiken zu triggern. Aber für eine UZSU wie ich sie vom Homeserver kenne, ist das schlicht zu wenig.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
Ich finde die Item-only Variante auch sehr ansprechend. Wobei type ja auch z.B. crontab oder datetime sein könnte.
Davon abgesehen müsste man auch noch crontab aufbohren um einzelne (nicht wiederkehrende) Zeitpunkt verarbeiten zu können. Das ganze würde halt nicht noch ein directory für die Config bedeuten, was ich attraktiv fände.
und wie würdest du damit mehrere Schaltzeiten für ein Item umsetzen? Wobei sich die Anzahl der Schaltzeiten ja auch ändern lassen muss? Mit fest verdrahteten Triggeritems geht das IMHO nicht.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
vielleicht bin ich mit der HS-Denke nicht ausreichend vertraut - habe jetzt erstmal in Ruhe den UZSU-Lexikoneintrag gelesen.
Bitte korrigiere mich falls ich es falsch verstehe oder so:
eine UZSU kann mehrere Schaltzeiten einstellen
eine Schaltzeit kann einmalig (also Datum und Uhrzeit verwendet?) oder wiederkehrend (nur Uhrzeit verwendet?) sein
eine Schaltzeit kann gefiltert/überlagert sein, also "nur Werktage" oder "variiere Zeitpunkt um 30min"
eine Schaltzeit kann eine "Funktion" ausführen
Die Punkte zwei und drei könnte man ja wirklich mit den Typen "Date"/"Time"/"Bool" halbwegs anständig erschlagen. Evtl. statt den Bools nur ein "Num" was die Kombinationsmöglichkeiten aus Tagen etc. enkodiert ("Bitmaske" - 2^8 wären schon alle Tage als Maske + Feiertagsbit).
Problematischer sind ja die Punkte 1 und 4. Punkt 1 ist wahrscheinlich die Flexibilität, meinen Rolladen im Wohnzimmer jetzt statt "jeden Tag um 6 hoch" zu sagen "jeden Werktag um 6" & "am Wochenende um 7". Erhöht natürlich die Komplexität beträchtlich.
Punkt 4 verstehe ich jedoch gar nicht. Wenn ich die UZSU in die Visu einbaue, weiß ich doch wo ich sie einbaue und was ich damit "timen" will, oder? Oder wird dann ein und dieselbe UZSU für "hoch" und "runter" benutzt und dass sind die "Funktionen"? Wird das beim HS bei der Programmierung schon bestimmt was die "Funktion" sein kann? Das wäre dann ja mit https://knx-user-forum.de/smartvisu/...eren-kann.html zu erschlagen.
Wenn also Punkte 2-4 reichen, könnte ja eine Kombi aus "Date"/"Time"/"Num"(Bitmaske)/"Str"(Liste des Funktionen) reichen.
Wenn 1 auch noch mit rein soll, denke ich, sollte man sich auf ein String-Format "UZSU" einigen, was dann in einer Logik geparst wird (zusätzlich zu einer selektierbaren Liste für die Funktionen).
, = erstes Escape für Felder einer Schaltzeiten
\ = zweites Escape für Trennung mehrerer Schaltzeiten
Könnte dann schnell per split&Co in mehrere Schaltzeiten und Felder getrennt werden. Evtl. was für "tools" um es in einer Logik kompakt nutzen zu können?
Dieser "UZSU"-String könnte dann problemlos als Trigger_item fungieren. Ggfl. kann ja die Logik den letzten Zustand speichern um mittels Vergleich kleinere Änderungen schnell justieren zu können.
(1) könnte man zumindest damit umgehen das man das Item mehrfach anlegt (mit verschiedenen Zeitpunkten). Etwas mehr Aufwand aber, denke ich, praktikabel.
Also das Item mehrfach anlegen geht gar nicht... technisch zwar schon, aber praktikabel ist das nicht. Wie stellst du das in der Visu ein? Dann hättest du da x mal das gleiche Item?! Und dynamisch bist du dann wieder nicht, also du kannst dann nur soviel Schalteinträge anlegen, wie du das Item in der Konfig geklont hast.
Das tolle aber an der UZSU des HS ist ja gerade der 1. Punkt. Du kannst dort nach belieben neue Schaltzeiten anlegen und auch wieder löschen. Beispiel Rollo: Du hast eine Liste mit folgenden Einträgen:
- Werktags um 8:00 Uhr AUF
- Werktags um 20:00 Uhr AB
- Wochenende 20 min. vor Sonnenaufgang AUF
- Wochenende 1 Std. nach Sonnenuntergang AB
- Jeden 1. Dienstag im Monat erst um 22:00 Uhr AB (weil da ist Poker Abend)
Wenn dir im Sommer jetzt einfällt, es wäre ganz praktisch ab einer gewissen Uhrzeit zu beschatten (hier mal angenommen eine WS gibt es nicht), machst du halt schnell über die VISU zusätzlich die zwei Einträge:
- Werktags um 14:00 Uhr auf 70%
- Werktags um 18:00 Uhr AUF
Sobald die Liste irgendwie statisch wird, hat es für mich den Sinn verloren.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
eine Schaltzeit kann einmalig (also Datum und Uhrzeit verwendet?) oder wiederkehrend (nur Uhrzeit verwendet?) sein
eine Schaltzeit kann gefiltert/überlagert sein, also "nur Werktage" oder "variiere Zeitpunkt um 30min"
eine Schaltzeit kann eine "Funktion" ausführen
Astrofunktionen fehlen hier noch, könntest du aber evtl. mit Punkt 3 meinen. Die eine Funktion bedeutet wahrscheinlich das sie abhängig vom Gewerk ist. Bei der Jalousie kannst du Behanghöhe und Winkel setzen, beim dimmbaren Licht eben die Helligkeit usw.
Bei uns gäbe es halt bool und num. Das Aussteuern müsste dann je nach smartVISU Widget passieren. Also Behanghöhe und Winkel haben jeweils eine UZSU Option, in dem späteren smartVISU Widget werden diese aber gemeinsamm verwendet und gesetzt.
Problematischer sind ja die Punkte 1 und 4. Punkt 1 ist wahrscheinlich die Flexibilität, meinen Rolladen im Wohnzimmer jetzt statt "jeden Tag um 6 hoch" zu sagen "jeden Werktag um 6" & "am Wochenende um 7". Erhöht natürlich die Komplexität beträchtlich.
Genau, aber ohne diese Flexibilität macht eine UZSU für mich keinen Sinn.
Wenn also Punkte 2-4 reichen, könnte ja eine Kombi aus "Date"/"Time"/"Num"(Bitmaske)/"Str"(Liste des Funktionen) reichen.
Wenn 1 auch noch mit rein soll, denke ich, sollte man sich auf ein String-Format "UZSU" einigen, was dann in einer Logik geparst wird (zusätzlich zu einer selektierbaren Liste für die Funktionen).
Warum eine Logik? Ich will doch vom Benutzer nicht, dass er erst eine Logik anlegen muss, um eine UZSU verwenden zu können. Das muss ein einfaches Konfig Attribut für den User sein, alles weitere wird über die Visu eingestellt.
Dieser "UZSU"-String könnte dann problemlos als Trigger_item fungieren. Ggfl. kann ja die Logik den letzten Zustand speichern um mittels Vergleich kleinere Änderungen schnell justieren zu können.
Dann muss zusätzlich dieser "UZSU"-String irgendwo in sh.py verbaut und geparst werden, damit dieser als Trigger fungieren kann. Das sind mir alles viel zu viele Änderungen am gesamten System, wo sich das doch alles mit bereits vorhandenen mitteln erschlagen liese.
crontab kann doch schon fast alles, außer feste Schaltzeitpunkte mit Datum und Uhrzeit und überlagerten Funktionen (Fahre den Rollo um 8 hoch, außer am WE). Wenn wir das crontab noch beibringen könnten, wäre das die einzige Anpassung die notwendig ist. Der Rest wird alles zusätzlich und unabhängig vom jetztigen System implementiert. Lediglich das Visu Plugin müsste dann noch erweitert werden. Da es bisher aber überhaupt keine Möglichkeit dafür gibt, das im Visu Plugin zu handeln, muss dieses eh erweitert werden.
Mit freundlichen Grüßen Niko Will
Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -
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.
Kommentar