Tag / Nacht

[awknx]

Die beiden Items werden derzeit ja als env-Items automatisch bereitgestellt. Leider ist es so, dass wahrscheinlich jeder gerne was Anderes darunter versteht, wann "Tag" und wann "Nacht" sein soll. Im smarthome.py ist der Beginn des Tages mit sh.sun.rise(-6) hinterlegt - also bis zum Ende der bürgerlichen Dämmerung (in /usr/local/smarthome/lib/env/location.py).

Ich habe mir nun damit beholfen, zwei neue Items zu ergänzen - brightness (Helligkeit) und darkness (Dunkelheit) und dazu die beiden Dateien ergänzt:

# lib/env/location.py
...
    # setting day and night
    day = sh.sun.rise(-6).day != sh.sun.set(-6).day
    sh.env.location.day(day)
    sh.env.location.night(not day)

[COLOR=#008000]    # setting brightness and darkness
    brightness = sh.sun.rise(6).day != sh.sun.set(6).day
    sh.env.location.brightness(brightness)
    sh.env.location.darkness(not brightness)[/COLOR]

location.conf

[env]
    [[location]]
        [[[day]]]
            type = bool
        [[[night]]]
            type = bool
[COLOR=#008000]        [[[brightness]]]
            type = bool
        [[[darkness]]]
            type = bool[/COLOR]

Mit sh.sun.rise(6) erhalte ich ungefähr bei der Uhrzeit das Hell- oder Dunkelitem, wenn es bei mir in der Wohnung tatsächlich so wird.

Jetzt ist das aber keine saubere Lösung, wenn ich im Source rumbastele. Viel besser wäre es m.E., wenn man den Parameter (6) als Attribut/Wert übergeben könnte und diesen in der smarthome.conf ähnlich wie lat, lon hinterlegen könnte (am Besten wahlweise als Grad- oder Minutenangabe). Dann kann ich darüber ganz einfach einstellen, wann bei mir Tag oder Nacht o.ä. sein soll.

Ich fange jetzt auch mal an Python zu lernen, aber das müsste doch wohl eher jemand des Kernteams in den Source integrieren, oder? Oder wäre es geschickter, die ganzen astronomischen Berechnungen aus dem Source raus und in ein Plugin rein zu nehmen?

Viele Grüße
Andi

[Bonze]

Praktisch als sog offset wert?

[awknx]

Genau. Ganz luxuriös wären unterschiedliche Offsets für Tag und Nacht. Und wenn wir schon beim Thema sind, ich würde alle Berechnungen so machen, dass sie für ein bestimmtes Datum gültig sind und nicht wie bisher immer das nächste Eintreten berechnet wird (z.B. Sunrise für den nächsten Tag). Ich kenne auch aus der Seefahrt keine Anwendung, die das nicht datumsbezogen berechnet.

[psilo]

Bei Helligkeit bin ich weniger ein Freund davon, das durch Berechnung setzen zu lassen. Brightness-basiere Steuerung sollte imho nur über Helligkeitsmesser bspw. via Wetterstation gehen. Vielleicht bin ich da aber auch alleine..
Dass bspw. nach dem Sonnenaufgang im sunrise Item bereits die Zeit des nächsten Tages steht, stört mich aber auch etwas.

[awknx]

Spricht natürlich was dafür. Bei mir ist es halt so, dass ich nur in der Wohnung zwei Präsenzmelder habe, die auch Helligkeit messen. Leider liegen die aber derart daneben, was die empfundene Helligkeit bzw. Notwendigkeit das Licht einzuschalten betrifft, dass ich mit dem smarthome.py stattdessen ein Sperrobjekt an den knx schicke. Sonst geht mir z.B. im Flur tagsüber auch dauernd das Licht an, obwohl nicht notwendig. Aber letzlich würde ein parametrierbares Tag-/Nachtobjekt ausreichen.

[psilo]

oder man benennt sie halt unterschiedlich und berechnet alle sinnvollen, so lange sie fachlich korrekt benannt sind?!
nur brightness und darkness ist mE. der falsche bezeichner
ich rechne bei meinen logiken einfach nochmal 15 min ab bzw rechne sie drauf. das funktioniert auch gut... sunset+15m; sunrise-15m

[awknx]

Gerne einen anderen Bezeichner, mir ist nur nix Besseres eingefallen. Man muss aber wahrscheinlich aufpassen, jetzt nicht zig Items vorzukonfigurieren, da wird dann die Schaltuhr schnell sinnvoller. Eigentlich würde reichen, das Tag/Nacht mit einem konfigurierbaren Parameter statt der -6 zu versehen und schon kann das jeder in seiner smarthome.conf nach Belieben voreinstellen.

[Eugenius]

Ich habe bei mir es so gelöst, dass ich nur Nacht Objekt mit 1 oder 0 nutze. Und somit stört mich die Zeit überhaupt nicht