Diskussion zu "Alltagsprobleme und deren Lösungen mit dem OpenKNX-Logikmodul"

[Theees]

nimm doch einfach https://github.com/OpenKNX/OAM-ShutterController

Wenn Du über Helligkeit gehen willst, wird Dir meine "Neuerung" nichts bringen. Da wird einfach nur der Shutter mit im Sensormodul integriert, und der geht auch über Sonnenstand und Zeit.

Hi, ich habe mir den ShutterController mal angesehen. So wie ich das in der ETS sehe, und so wie ich Waldemars Beitrag verstehe, kann der ShutterController keine Steurerung per Helligkeit?

Irgendwie komisch, dass es diese Option nicht gibt. Hätte ehrlich gesagt gedacht das es "normaler" oder verbreiteter wäre die Rollläden per Helligkeit als über den Sonnenstand zu steuern. Eben wegen den deutlichen Helligkeitsunterschieden bei schönem oder schlechtem Wetter welche mich total stören.
Mir ist sowas auch schon bei z.B. der Zennio RemoteBox aufgefallen. Dort kann man seine Rollladensteuerung total einfach per Dropdowns erstellen. Aber auch hier kann man nicht auf Helligkeitswerte zurückgreifen...
Irgendwie unverständlich für mich, aber ich baue mir das dann übers Logikmodul.

Gruß Thies

[Ing-Dom]

Helligkeit gibts es für die Beschattungssteuerung, aber afair nicht für den Nachtmodus.

[mumpf]

aber afair nicht für den Nachtmodus.

Genau - ist aber durchaus eine Anregung für mgeramb, das in dem Zusammenhang auch zu nutzen.

Gruß, Waldemar

[coko]

Theees Bei ausschließlicher Helligkeitssteuerung kann es auch zu Fehlsteuerungen kommen (siehe z.B.
https://knx-user-forum.de/forum/proj...73#post2056873 ).

Ich interpretiere Deine Anforderungen so, dass Du abhängig von der gemessenenen Helligkeit, abends die Rolläden einmalig im Zeitraum von einer Stunde vor und einer Stunde nach Sonnenuntergang herunterfahren willst und morgens immer um genau 7:30?

[Theees]

Bei ausschließlicher Helligkeitssteuerung kann es auch zu Fehlsteuerungen kommen

Ja, genau dieses Problem hatte ich auch schon ein mal. Habe da auch tatsächlich noch keine Lösung außer ein erneutes Auslösen zwischen Sonnenauf- bzw. untergang zu sperren.

einmalig im Zeitraum von einer Stunde vor und einer Stunde nach Sonnenuntergang herunterfahren

Genau, meist tritt dieser Moment eine halbe Stunde - Stunde nach Sonnenuntergang ein, je nach Wetterlage.

und morgens immer um genau 7:30?

Ne, morgens immer um 07:30 Uhr außer es ist draußen noch dunkler als bspw. 3lx. Dann später, und zwar erst wenn 3lx überschritten wurden.
Denn aktuell ist es um 07:30 Uhr noch so dunkel das die Rollladen hochfahren obwohl es draußen stockdunkel ist. Das ändert sich denke ich Ende des Monats schon wieder, wenn die Uhr umgestellt wird. Aber aktuell in der Übergangszeit würde ich das gerne abfedern.

[coko]

Ne, morgens immer um 07:30 Uhr außer es ist draußen noch dunkler als bspw. 3lx. Dann später, und zwar erst wenn 3lx überschritten wurden.
Denn aktuell ist es um 07:30 Uhr noch so dunkel das die Rollladen hochfahren obwohl es draußen stockdunkel ist. Das ändert sich denke ich Ende des Monats schon wieder, wenn die Uhr umgestellt wird. Aber aktuell in der Übergangszeit würde ich das gerne abfedern.

Das spräche schon für eine Zeitdefinition wie Sonnenaufgang, frühestens 7:30, wobei Du morgens dann natürlich immer noch eine wetterabhängige Helligkeit hast.

Wie misst Du die Helligkeit überhaupt und wie ist sichergestellt, dass der Wert hinreichend stabil ist?

Ich verstehe Dein Vorhaben nun wie folgt, wobei da noch einige Zeitgrenzen fehlen (sowie auch eine mögliche Berücksichtigung manueller Bedienung):

	vor 7:30	ab 7:30 bis ?	?	? bis "Sonnenuntergang"	"Sonnenuntergang" bis ?	? bis Mitternacht
> 3 lux	unten	oben	oben	oben	oben	unten
< 3 lux	unten	unten	oben	unten	unten	unten

im Zeitraum "Ab 7:30 bis =" wäre nur ein Wechsel von unten nach oben erlaubt, um "Sonnenuntergang" herum nur von oben nach unten. Ein solches Verhalten lässt sich u.U. einfacher mit den OpenKNX Zustandsautomaten abbilden.

[willisurf]

OK 1-2 Wochen kann ich noch warten

Ein solches Verhalten lässt sich u.U. einfacher mit den OpenKNX Zustandsautomaten abbilden.

Spoiler: Der ist ja dann auch mit im nächsten Release des „Sensormoduls“ enthalten.

[mumpf]

Leute, ihr denkt viel zu kompliziert. Der Zustandsautomat ist hier komplett überdimensioniert.
Das sind 3 simple Logikkanäle:

1. Eine Zeitschaltuhr, die den Tag definiert, ganz nach Userwunsch, hier mal Beispielhaft
   1. Sonnenaufgang, frühstens 7:30 Uhr -> 1 (Tag ist 1)
   2. Sonnenuntergang, spätestens 22 Uhr -> 0 (Nacht ist 0)
2. Helligkeit > 3 Lux UND Tag sendet "hoch"
3. Helligkeit < 3 Lux UND NICHT Tag sendet "runter"

Das war es. Da braucht man keinen Shutter, keinen Zustandsautomat, es geht auch mit der gegebenen Firmware und ist simpel umzusetzen.

Gruß, Waldemar

[coko]

3 simple Logikkanäle:

Ich würde noch einen weiteren ergänzen, um für "Tag" und "Nacht" irgendwann eine Umschaltung unabhängig von der Helligkeit sicherzustellen und Wiederholungen bei schwankender Helligkeit zu vermeiden (das war bei meinen Überlegungen mit vorgesehen, sollte sich nun nun aber auch umsetzen lassen):

1. ZSU, allerdings mit 4 Tagesphasen (mit Werten 1 bis 4 über E1 zur Wertausgabe):
   1. 7:30 für Morgen-Phase (Rolladen soll hochfahren)
   2. 9:30 für Tages-Phase (Rolladen soll immer hier normaleraeise immer oben sein)
   3. Sonnenuntergang minus 2 Stunden für Abend-Phase (Rolladen soll runterfahren)
   4. 22:00 Uhr für Nacht
2. Helligkeit > 3 Lux UND ZSU_Phase==1
3. Helligkeit < 3 Lux UND ZSU_Phase==3
4. RS-Flip-Flopp zum jeweils einmaligen Senden von hoch/runter (Kodierung könnte auch anders heraum erfolgen)
   • Set durch
     • Ausgang von Logikkanal 2 (interner Eingang)
     • ZSU_Phase==2
   • Reset durch
     • Ausgang von Logikkanal 3 (interner Eingang)
     • ZSU_Phase==4

[mumpf]

Wozu? Morgens hoch, Abends runter. Da gibt es nichts mit Schwankungen. Die anderen Phasen sind nicht notwendig.

Wenn Du Angst hast, dass die 3 Lux sofort nach der Überschreitung wieder unterschritten werden, dann macht man da noch eine Hysterese rein, die erst bei <1 Lux auf false geht (morgens) und z.B. >10 Lux auf false geht (abends). Die Auswirkung wäre aber nur ein wiederholden des "hoch"-Befehls, nicht ein "runter" (abends dann umgekehrt).
Und wenn es darum geht, den Sonnenfinsternis-Fall abzudecken (mitten am Tag wird es so dunkel dass der Lux-Wert auf 0 sinkt), was dazu führen würde, dass nach der Sonnenfinsternis nochmal die Wiederholung von "hoch" auftreten würde (was nicht stört, wenn er sowieso oben ist, aber potentiell eine manuelle Fahrt zuvor zunichte machen würde), dann kann man den Ausgängen für "hoch" und "runter" das S-Flag setzen und sie nur bei Änderung am Ausgang senden lassen.

Gruß, Waldemar