ElabNET Technik Forum

Hallo zusammen.
Bei der Schaltfunktion der Astrouhr des HS4 ist mir negativ aufgefllen, dass es zu Fehlschaltungen (nicht im eigentlichen Sinne!) kommt, wenn der Sonnenaufgang (SA) VOR der eingestellten Schaltzeit an diesem Tag erfolgt. Im Winter ist das kein Problem, denn i.d.R. schaltet man das Außenlicht ja früh z.B. um 6:00 ein und bei SA + 15 Minuten wieder aus. Im Winter funktioniert das allerdings nicht immer, denn der SA ist da häufig VOR der Einschaltzeit. Das hat dann zur Folge, dass das Licht erst mit der Ausschaltung des Lichtes am Abend wieder aus geht und den ganzen Tag eingeshaltet ist.

Frage an die Entwickler des Bausteins der Astrouhr:
Ist das irgenwie abgefangen beim LBS Astrouhr? Wenn nicht - kann man das irgendwie noch einpflegen, dass es zu keiner Schalthandlung kommt, wenn die Schaltzeit für EIN / AUS unlogisch zum SA / SU an diesem Kalendertag angelegt ist? Das Highlight wäre natürlich, wenn es noch zu einer Textausgabe beim Anlegen der Schaltzeiten kommen würde, die mitteilt, dass die Einschaltzeit im Bereich vom 17. Mai bis 23. August ausserhalb des zulässigen Zeitfensters liegt.

Wenn das funktioniert, wäre das wieder ein Punkt, der den HS4 toppt!

Gruß
Stephan

Hallo Stephan,

der Astro-Logikbaustein gibt nur diverse Uhrzeiten (SA/SU, Dämmerung), Sonnenwinkel und Sonnenhöhe etc. aus. Mehr muss er auch gar nicht tun.

Aber diese Werte können in anderen Bausteinen wiederum z. B. mit Schaltzeiten kombiniert werden. Und die Logikengine ist insgesamt so "logisch" designed, dass die von dir angesprochenen unlogischen Schaltzeiten einfach ausgeschlossen werden können.

Ich habe z. B. genau so eine Logik wie in deinem Beispiel im Einsatz, die u.a. um 6 Uhr morgens das Außenlicht einschaltet. Bei Beginn der Dämmerung (Sonnenwinkel > -6 Grad) schaltet sie wieder aus. Wenn um 6 Uhr der Sonnenwinkel schon über -6 Grad ist, wird gar nicht erst eingeschaltet.

Das ist also alles schon möglich und läuft bei mir seit ein paar Monaten einwandfrei! Ich kann gerne noch beschreiben, wie ich das umgesetzt habe (anhand von anderen Beispielen hier im Forum).

Ja, gerne auch mit Beschreibung.

Gruss
Stephan

ja, solchse Beispiele braucht das (TWS)-Land!

Gerne. Ich beschreibe mal etwas ausführlicher, was ich gemacht habe. (wobei ein großer Teil auf anderen Beispielen oder Anregungen hier aus dem Forum basiert - möchte mich da nicht mit fremden Federn schmücken.)

Meine Logik ist aus insgesamt drei Bausteinen zusammengesetzt und macht folgendes:

- Wenn es dunkel wird schaltet sie abends eine Außenlampe EIN
- Nachts um 1 Uhr wird die Beleuchtung ausgeschaltet
- Morgens um 6 Uhr wird sie wieder eingeschaltet - es sei denn, der Beginn der Morgendämmerung ist schon vorbei.
- Spätestens bei Einsetzen der Morgendämmerung wird sie wieder ausgeschaltet.

Verwendete Logikbausteine:

Logik 1) Der Standard-Astrobaustein.

Logik 2) Einen Custom-Timer-Baustein, der TRUE ausgibt, wenn wir uns im Nachtfenster zwischen 1 Uhr und 6 Uhr befinden.
Hier benutze ich den von Stefan Kolbinger vorgestellten Baustein aus diesem Beitrag: viewtopic.php?f=24&t=1291&hilit=Zeitfen ... =10#p13289

In Zukunft soll es ja mal möglich sein, auch dafür einen Standard-Baustein zu verwenden.

Logik 3) Die Haupt-Logik: Ein einfacher AND-Baustein, um die Logiken 1) und 2) zu verknüpfen und die Lampe zu schalten:



Diese AND-Logik hat zwei Eingänge:

Eingang 1: Den "Sonnenhöhe"-Ausgang aus dem Astro-Baustein. Darin die "Schwellwert unter"-Funktion mit dem Wert -6.

D.h. liegt die Sonnenhöhe unter -6 Grad ist der Eingang TRUE (= es ist dunkel), ansonsten FALSE.

Den Wert kann man natürlich beliebig auf die eigenen Bedürfnisse anpassen. Nimmt man "0" entspricht das Umschalten genau dem Sonnenauf- bzw untergang. "-6" ist abends das Ende bzw. morgens der Beginn der "bürgerlichen Dämmung".

Ich arbeite hier also nicht direkt mit den Zeiten aus dem Astro-Baustein, sondern indirekt über die Sonnenhöhe. Damit kann ich alles was ich brauche über einen Eingang abwickeln.

Eingang 2: Den invertierten Ausgangswert aus Logik 2)

Was passiert nun?
- Bei Ende der Abenddämmerung (Sonnenhöhe geht unter -6 Grad), schaltet der erste Eingang um auf TRUE. Der zweite Eingang für das Zeitfenster 1-6 Uhr ist (invertiert) zu diesem Zeitpunkt auf jeden Fall TRUE. Der Ausgang wechselt somit auch auf TRUE, die Lampe geht an.
- Nachts um 1 Uhr geht der zweite Eingang (invertiert) auf FALSE, da dann das Nachtfenster (1 - 6 Uhr beginnt). Die Lampe geht aus.
- Um 6 Uhr morgens geht der zweite Eingang (invertiert) wieder auf TRUE.
=> Wenn zu diesem Zeitpunkt die Sonne schon über -6 Grad steht, ist der erste Eingang bereits FALSE. Der Ausgang bleibt FALSE und die Lampe geht somit nicht an.
=> Ist es noch dunkel, d.h. Sonne unter -6 Grad, geht das Licht an. Sobald die Sonnenhöhe die -6 Grad übersteigt, geht die Lampe wieder aus.

Das Zeitfenster lässt sich natürlich auch anpassen. Und soll z. B. die Beleuchtung nur morgens eingeschaltet werden, aber abends nicht, legt man den Beginn des Zeitfensters z. B. vor den frühestmöglichen Sonnenuntergang.

Das war jetzt eine Menge Text zur Erklärung. Wenn etwas unklar ist, einfach fragen. Aber eigentlich ist es ganz einfach, und das Ergebnis ist immer "logisch"

Schöne Logik Matthias, In Kombination mit einem Feiertagskalender wäre das schonmal perfekt für die Steckdosen mit Deko-krams.

perfekt, genau das brauche ich für mein Bodenlicht zwischen Haustüre und Straße, Vielen Dank!

@773H: Kann man diesen Thread auf gelöst setzen?
Der FR als solches existiert ja nicht mehr, wenn ich richtig mitgelesen habe.

Robert

Nun ja, nachdem der Lösungsansatz von Matze zu Teilen aus einer "Custom Logik" besteht, könnte man die doch irgendwie in die Astrouhr integrieren. Ist ja etwas, das zur Zeitschaltuhr passt.

Prinzipiell ist das eigentliche Problem allerdings erst mal gelöst.

Gruß Stephan

773H hat geschrieben: ↑Mi Okt 30, 2019 12:10 pm Nun ja, nachdem der Lösungsansatz von Matze zu Teilen aus einer "Custom Logik" besteht, könnte man die doch irgendwie in die Astrouhr integrieren. Ist ja etwas, das zur Zeitschaltuhr passt.

Denke nicht, dass das sinnvoll ist. Dadurch geht Flexibilität und Anpassbarkeit verloren und der Astrobaustein wird durch Dinge aufgebläht, die man anders lösen kann. Würde auch die Tests komplizierter machen.
Grundregel der SW-Entwicklung (passt hier genauso): Lasse Funktionen nur genau eine Sache machen und die dafür richtig.
Beim Astrobaustein ist das halt genau nur die Ausgabe der Astrodaten. Verarbeitung dann woanders.