Diskussionsthread EDOMI-Releases/Updates

[MrMirror]

Stichwort ZSU: wie habt ihr eigentlich das Thema ZSU und Feiertage gelöst?

Damit: http://service.knx-user-forum.de/?co...ad&id=19000890

[rene.z]

Eine 2.ZSU für Feiertage anlegen (Tage Mo-So). Die Zeitschaltuhren werden vom LBS 19000890 umgeschaltet.

... für jede ZSU eine zweite ZSU und die dann per LBS 890 umschalten... ist sicher eine Möglichkeit, aber sowohl in der Implementierung als auch in der Wartung mit viel Mehraufwand verbunden (... und auch der WAF dürfte überschaubar sein).

Die Frage war daher, ob der allgemeine Usecase "Feiertag" nicht eine zusätzliche Kategorie (neben Mo - So) in der Standard-ZSU rechtfertigt.

Die Kategorie "Feiertag" könnte dann greifen, wenn z.B. ein System-iKO von LBS 890 auf 1 gesetzt wird...

Ich wollte eigentlich nur die Gelegenheit nutzen, wenn gaert ohnehin an den ZSUs herumbastelt... wenn sich eine solche Kategorie "Feiertag" in der Standard-ZSU nicht umsetzen lässt, werde ich bei Gelegenheit die Empfehlung von vento implementieren, danke für den Tip.

[vento66]

Ich hoffe nicht, das er wieder an den Datenbanken der ZSU rumbastelt Bei mir läuft das ja auch etwas anders ich nutzen den LBS http://service.knx-user-forum.de/?co...ad&id=19000608. So ein zentrales Feiertags Objekt hätte aber vielleicht auch was....

[gaert]

Prinzipiell wäre ein Feiertags-KO im ZSU-Kontext durchaus denkbar - nur wer füttert dieses KO? EDOMI sicher nicht - Feiertage sind äußerst flexibel und auch individuell verschieden (es soll Berufe geben, die auch an Feiertagen ausgeübt werden wollen). Und irgendwelche Listen mit Feiertagen zu pflegen kann's ja auch irgendwie nicht sein.

[vento66]

Der LBS 19000890 macht das eigentlich ganz gut. Wenn das IKO nicht gesetzt, dann wird es halt ignoriert. Jetzt kommt dann aber gleich noch die Frage „Kann man die Tage vor Feiertagen“ auch auswerten, da man da ggf. Etwas länger unterwegs ist.

[rene.z]

... da bin ich bei vento66, dass ein passender LBS das iKO setzen kann (ob der jetzt eine Liste verwaltet oder auf einem Algorithmus basiert kann dann jeder selbst entscheiden).

Und genau dieser Ansatz löst dann gleich auch das "der Tag vor dem Feiertag" Problem... wer den Tag vor dem Feiertag anders behandeln möchte, programmiert sich den LBS zum Setzen des iKO eben entsprechend (der LBS 890 gibt ja auch den Tag vor dem Feiertag aus).

Also ich fände das eine super Erweiterung (ob da eine DB-Anpassung notwendig ist oder nicht kann ich aber nicht beurteilen ????)

[ThomasCologne]

Die Frage war daher, ob der allgemeine Usecase "Feiertag" nicht eine zusätzliche Kategorie (neben Mo - So) in der Standard-ZSU rechtfertigt

Also eine zusätzliche Kategorie fände ich auch nicht schlecht, da man so selbst bestimmen kann, woher die Steuerung kommt. Denn nicht nur Feiertage (über den LBS890) wären möglich, sondern auch generelle Urlaubstage oder gezielt (unregelmäßig) freie Tage. Je nachdem, woher das KO gesteuert wird.
Ob diese Kategorie nun "Feiertage" heißt oder sogar selbst bezeichnet werden könnte, wäre zweitrangig. Obwohl eine eigene Bezeichnungsmöglichkeit durchaus Vorteile hätte. Denn:

„Kann man die Tage vor Feiertagen“ auch auswerten, da man da ggf. Etwas länger unterwegs ist.

Für die VOR-Feiertage könnte man die Kategorie erneut anlegen, anders bezeichnen und über ein anderes KO (LB890 -1) steuern lassen. So hätte man so ziemlich alle Optionen offen.

[gaert]

Zu kompliziert wollte ich's eher nicht machen - ich dachte da an eine(!) zusätzliche Option (ähnlich den Wochtentagen) die 3 Einstellungen erlaubt:
- deaktiviert (d.h. alles wie gehabt)
- aktiviert, d.h. wenn das KO=1 ist wird ggf. geschaltet (also z.B. Feiertag)
- negiert, d.h. wenn das KO=0 ist wird ggf. geschaltet (also z.B. kein Feiertag)

Wahrscheinlich werde ich dafür ein System-KO hinzufügen, das jedoch nicht von EDOMI gesetzt wird sondern "hart" mit allen ZSUs/TSUs verdrahtet ist. Oder macht ein individuell zuweisbares KO mehr Sinn? Meines Erachtens eher nicht.

[rene.z]

Zu kompliziert wollte ich's eher nicht machen - ich dachte da an eine(!) zusätzliche Option (ähnlich den Wochtentagen) die 3 Einstellungen erlaubt:
- deaktiviert (d.h. alles wie gehabt)
- aktiviert, d.h. wenn das KO=1 ist wird ggf. geschaltet (also z.B. Feiertag)
- negiert, d.h. wenn das KO=0 ist wird ggf. geschaltet (also z.B. kein Feiertag)

... ein zusätzlicher "Tag" (Mo - So + "Feiertag") sollte die Mehrzahl an UseCases abdecken -

Wahrscheinlich werde ich dafür ein System-KO hinzufügen, das jedoch nicht von EDOMI gesetzt wird sondern "hart" mit allen ZSUs/TSUs verdrahtet ist. Oder macht ein individuell zuweisbares KO mehr Sinn? Meines Erachtens eher nicht.

Wenn es hart-codiert den zusätzlichen Tag "Feiertag" gibt, reicht m.M.n. ein System-KO "Feiertag" (Ja/Nein) aus.

Falls du irgendwann darüber nachdenkst mehrere, selbst konfigurierbare zusätzliche Tage zu erlauben (was aber die Komplexität vermutlich signifikant erhöhen würde, schon alleine Layout in den Dialogen usw.), würde ein individuell zuweisbares KO vermutlich mehr Sinn machen... im ersten Schritt reicht mir persönlich aber die erste Variante mehr als aus!

[ThorstenGehrig]

Hi
ich habe einen "kleinen Bug" gefunden:
ich bin gerade dabei den DVR in betrieb zu nehmen.
Mein Aufzeichnungspfad ist "/mnt/drobo/cameras/edomi" - wobei der mount-punkt "/mnt/drobo" ist.
Bei der Prüfung ob der Mount vorhanden ist wird mir gemeldet: "Prozess DVR: Zielpfad ist nicht gemounted (Mountcheck) - Aufzeichnung wurde angehalten! ERROR"
(obwohl der Mount erfolgt ist und der Pfad vorhanden ist).

Deaktiviere ich die Mount-Prüfung läuft der DVR...

Gruß
Thorsten

[gaert]

Das ist so auch nicht gedacht - bei der Prüfung wird der angegebene Pfad überprüft, dieser muss also "gemounted" sein. Unterordner funktionieren nicht im Zusammenspiel mit der Prüfung (wie Du bereits festgestellt hast).

[ThomasCologne]

Wahrscheinlich werde ich dafür ein System-KO hinzufügen, das jedoch nicht von EDOMI gesetzt wird sondern "hart" mit allen ZSUs/TSUs verdrahtet ist. Oder macht ein individuell zuweisbares KO mehr Sinn? Meines Erachtens eher nicht.

Ich denke, dass ein selbst wählbares iKO mehr Flexibilität und somit mehr Sinn ergibt. Denn wenn EIN KO hart mit JEDER ZSU verbunden ist, wird man wieder eingeschränkt sein in der Flexibilität. Vielleicht sollen ja die Rollläden an einem Feiertag was anderes machen als die Bewässerung. Und auch das „Vorfeiertags-Problem“ könnte so nicht gelöst werden.

Zudem hätte man mit einer zusätzlichen Implementierung eines Bezeichnungsfeldes und der zwingenden Angabe eines iKO, ALLE Möglichkeiten offen.
Damit wären alle Felder abgedeckt wie:
- Bezeichnung „Feiertag“: iKO xx ->1/0
- Bezeichnung „Vorabend“: iKO yy -> 1/0
- Bezeichnung „Urlaub“: iKO zz -> 1/0

1.jpg

… im ersten Schritt reicht mir persönlich aber die erste Variante mehr als aus!

Aber warum erst eine 70% Lösung anstreben, anstatt gleich auf 100% zu gehen?

[vento66]

Vielleicht sollen ja die Rollläden an einem Feiertag was anderes machen als die Bewässerung.

Du hast doch sicher
für die Bewässerung und die Rolläden eh getrennte ZSUs. Somit klickst Du einfach bei der Bewässerung den Feiertag nicht an, und sie läuft normal, oder Du stellst sie auf "Feiertag" und sie macht ihr Feiertagsprogamm. Tage vor Feiertagen, musst Du Dir berechnen, und ab Mittag den Tag als "Feiertag" markieren. Urlaub, geht auch als "Feiertag" durch oder?

[ThomasCologne]

... Tage vor Feiertagen, musst Du Dir berechnen, und ab Mittag den Tag als "Feiertag" markieren. Urlaub, geht auch als "Feiertag" durch oder?

Na ja klar. Alles richtig. Auch hier führen wieder viele Wege nach Rom. Aber warum diese Umwege über Logiken, Berechnungen, Annahmen gehen, wenn man doch in einer kompakten ZSU alle Zeiten und Schaltpunkte auf einem Blick haben kann. Smart ist es m.E. nach, alles auf einen Blick zu haben und nicht überlegen zu müssen, was wird nun von der Logik ermittelt und was steht in der ZSU als Feiertag, ist aber gar kein Feiertag.

[gaert]

Es wird genau 1 zusätzliches KO geben (frei wählbar pro ZSU). Was man dann damit anstellt, ist Sache der Logik - z.B. Feiertage, Astro, etc. Als Bezeichnung wird dann einfach der KO-Name angezeigt - damit sollte dann alles klar sein.