Licht abschalten in Kombination mit Tageszeit

[AndiN]

Jetzt qualmt mir auch der Kopf. Vielleicht könnt ihr mich korrigieren oder bestätigen?

Also war mein Programmentwurf doch korrekt?

Das Programm hier würde auch klappen:

Code: Alles auswählen

Wenn Tageszeit => Dämmerung => Änderung
Oder Tageszeit => Abend => Prüfen

Jetzt würde das Programm auslösen, wenn die Tageszeit in Dämmerung geht (weil Änderung)
Dann würde es auch auslösen wenn es jetzt von Dämmerung in Abend geht (obwohl es auf Prüfen steht).

Wäre es vertauscht

Code: Alles auswählen

Wenn Tageszeit => Dämmerung => Prüfen
Oder Tageszeit => Abend => Änderung

Würde es bei Dämmerung nicht auslösen, weil von Tageszeit (Bsp: Tag auf Dämmerung geht). Aber bei Abend würde es ausgelöst (weil es sich von Dämmerung auf Abend ändert).

Ist schon kompliziert seine Gedankengänge zu formulieren. Aber ich hoffe es war einigermaßen verständlich und ich habe es richtig verstanden.

Danke

Andi

[JRiemann]

Nein, Du verstehst unsere Diskussion falsch:
Folgender Fall: Du hast z.B: für das Tageszeitenskript die Wertliste
„Nacht; frühmorgens; Morgengauen; Vormittag; Mittag; Nachmittag; Dämmerung; Abend“

Wenn jetzt in einem Programm „Nacht > bei Änderung auslösen“ steht, dann wird nur ausgelöst wenn der Zustand „Nacht“ angenommen oder verlassen wird.
Wechselt z.B. der Zustand von „Vormittag“ auf „Mittag“, dann löst das Programm nicht aus weil ja „Nacht“ die Bedingung ist und von dem Wechsel des Status nicht direkt betroffen war.

[AndiN]

Hallo Jörg,

dann passt das Beispiel von mir oben und ich habe es richtig verstanden.

Der Sonst Wenn oder Sonst würde dann logischerweise auch nur ausgelöst, wenn der Wert sich von Nacht auf frühmorgens geändert wird? Korrekt?

Es sei denn man stellt bei "Sonst Wenn" alle andere Möglichkeiten "bei Änderung" und einer (logischerweise) "Oder" Verknüpfung ein.

Glaube dadruch erklärt sich so manches Programmproblem und die Aussage: Lieber viele kleine Programme ohne Sonst wenn?

Man lernt nie aus.

Danke Dir.

Andi

[JRiemann]

Es klingt so als hättest Du es verstanden.
Die Bedingung ist halt der wichtige Faktor! Die Bedingung muß von richtig zu falsch oder von falsch zu richtig wechseln damit ausgelöst wird.
Eben so wie bei Temperaturbereichen wo nur das betreten oder verlassen des Bereichs auslöst. Alle anderen Statusänderungen bleiben ohne Folgen.

Das von „Gluehwurm“ genannte Szenario steht noch auf dem Prüfstand. Das ist aber ein anderes Thema.

[BadenPower]

Das von „Gluehwurm“ genannte Szenario steht noch auf dem Prüfstand. Das ist aber ein anderes Thema.

Also meine Programme haben alle im WENN-Abschnitt keinen einzigen Auslöser. Alle Auslöser befinden sich ausschließlich im 1. SONST-WENN-Abschnitt.

.

[JRiemann]

Hat das einen bestimmten Grund??
Oder ist das nur eine Frage der persönlichen Vorlieben?

[Gluehwurm]

... meine Programme haben alle im WENN-Abschnitt keinen einzigen Auslöser ...

Hatte ich in Erinnerung, deshalb bin ich etwas verwundert. Bin aber noch nicht dazu gekommen, das genauer zu betrachten. Vielleicht hat sich wirklich nur an meiner CCU was quer gelegt.

[Oli9000]

Dank euch allen für die Vorschläge und die spannenden Diskussionen. Ich seh, es sind bei diesem Thema immer noch viele Fragen offen. Werde nun mal das eine oder andere versuchen, denke aber, die Lösung mit zwei Programmen ist wohl am einfachsten!

[BadenPower]

Hat das einen bestimmten Grund??

Das hat viele Gründe.

Der 1. Abschnitt sorg dafür, dass Programme keine Aktionen auslösen, wenn sie es nicht sollen, also unkontrolliert nach einem Reboot.

Der EXEC-Abschnitt mit den Auslösern ist absolut flexibel einsetzbar und kann dann natürlich auch Auslöser enthalten (wie zum Beispiel die virtuellen Tasten), die nicht Bedingungen sind welche in einem der SONST-WENN-Bedingungen benötigt werden.

Gerade nach einem Reboot ist es wichtig Programme in einer bestimmten Reihenfolge auszuführen, da ein Wert auf einem anderen Beruht, welcher zum Zeitpunkt x noch nicht da wäre. Dies ist durch den Einsatz von 10 Virtuellen Tasten gelöst, welche in speziellen Bootprogrammen, welche durch die VTs getriggert werden die Boot-Sequenz-ID setzen und dann wiederum mit Verzögerung die nächste VT "drücken", damit die nächste Sequenz gestartet wird.

Daher wird der benötigte Funkverkehr auf ein minimum beschränkt und durch die verzögerte sequenzielle Abarbeitung durch Verzögerungen Funkkollisionen verhindert/minimiert.
.

[nimmnenkeks]

Könntest Du bitte anhand Deines etwas "leichteren Beispiels" in den einzelnen Bereichen etwas mehr über die Abläufe zu bringen, bzw. was diese bezwecken?
So könnte man auch evtl. Deinem (zumindest für mich) komplexeren Beispiel/Programm besser folgen.

Der 1. Abschnitt sorg dafür, dass Programme keine Aktionen auslösen, wenn sie es nicht sollen, also unkontrolliert nach einem Reboot.

Da kann ich ja noch 1/2 folgen, wobei ich k.A. habe wie SYS-True und SYS-False zustande kommen.
Bisher kenne ich nur den Weg, die SysVar "Anwesenheit" zu Nutzen, um z.B. "SYS-CCU-Reboot" zu setzen.

Der EXEC-Abschnitt mit den Auslösern ist absolut flexibel einsetzbar und kann dann natürlich auch Auslöser enthalten (wie zum Beispiel die virtuellen Tasten), die nicht Bedingungen sind welche in einem der SONST-WENN-Bedingungen benötigt werden.

Dies ist durch den Einsatz von 10 Virtuellen Tasten gelöst, welche in speziellen Bootprogrammen, welche durch die VTs getriggert werden die Boot-Sequenz-ID setzen und dann wiederum mit Verzögerung die nächste VT "drücken", damit die nächste Sequenz gestartet wird.

Kann man dass so verstehen?
SysVar "CCU-BootSequenz" ist auf "gestartet" gesetzt und startet die erste VT01
VT löst Programm/Skript aus, füllt/setzt Werte (u.a. auch die SysVar "SYS-BootSequenz-Id") und löst zeitverzögert die nächste VT aus
VT02 hat nun aktualisierte Werte mit denen ein weiteres Programm/Skript arbeiten kann
Das Ganze in Deinem Einsatz bis VT10

Die Vorgehensweise finde ich klasse.
Bisher habe ich eine andere Vorgehensweise verwendet und Skripte/Programme gestartet um nach einem Reboot wieder auf ein entsprechendes Grundsystem zu kommen.

... durch die verzögerte sequenzielle Abarbeitung durch Verzögerungen Funkkollisionen verhindert/minimiert.
.

Versuche gerade dahinter zu kommen; wie man das so modular aufbaut, dass man bei Änderungen nicht wieder gefühlt die 1/2 der Programme neu schreiben muss

Jetzt raucht der Kopf nicht nur, die Synapsen gehen in die Kernschmelze wenn ich versuche über die SysVar "SYS-Protokoll" nachzudenken.
Das ist doch kein Werteliste, obwohl ich Dir das zutraue


Beste Grüße
Keks