LBS 19000145 - Beschattungssteuerung-NG

[rdeckard]

Hallo Yves

Um bei Deinem Beispiel zu bleiben wäre das von Dir oben angegebe Azimut nicht 76° sondern 346° und das Azimut links nicht 166° sondern 256°. Soweit klar? Wenn nicht, fragen!

Hier eine Skizze aus der Elsner Anleitung:
azimut3.jpg
Da bei mir das Haus -14° gedreht wäre, entspricht dies somit 0° (bzw. 360°) - 14° = 346° (weil es -14° ja nicht gibt)
Und dann davon jeweils + 90°, +180° und +270° wie in der Skizze angegeben.
Ergibt dann: Norden 346°, Osten 76°, Süden 166° und Westen 256°
Das würde sich mit deinen Werten decken.

Rechnerisch würde das zwar funktionieren, rein technisch glaube ich aber nicht, dass das wirklich so ist! Wenn Du die Lamellen ganz schliesst, dann überlappen sich diese mit ziemlicher Sicherheit ein wenig. Und genau um diese Überlappung sollte der Abstand mindestens kleiner sein als die Lamellenbreite. Das solltest Du nochmal genau nachmessen.

Hmm..der Abstand wird ja so wie in dieser Skizze gemessen?
azimut4.jpg
Meine Lamellen sind nicht ganz so gekrümmt und ich habe den Abstand an der Aussenkante zur nächsten Aussenkannte (bei 0% Stellung, also wie hier abgebildet) gemessen. Werds aber nochmals anschauen...vorallem wegen der Überlappung wenn geschlossen.

Das sieht eher nach einer nicht sauberen Konfiguration resp. Einstellung der Verfahrzeiten aus. Ich kenne den Aktor nicht, aber irgendwie lässt er sich mit Sicherheit dahingehend konfigurieren. Es gibt da sicher eine Möglichkeit, die genauen Zeiten einzustellen die Dein Behang braucht, um von ganz oben nach ganz unten oder auch um von ganz offen (waagerecht) nach ganz geschlossen (senkrecht) zu fahren. Damit kannst Du dann bspw. auch 95% anfahren und hast einen leicht geöffneten Behang.

Also ich kann eine Laufzeit definieren. Das habe ich mit der Stoppuhr gemessen und eingetragen. Die Höhe in Prozent wird auch einigermassen korrekt angefahren. Ich kann also 90% angeben, dann fährt die Jalousie bis ca. 90% (hab den Abstand nicht exakt abgemessen).
Problem ist also vorallem die Lamellenwinkel-Steuerung. Und dort kann ich glaub keine Parameter definieren. Die Schrittgrösse wird vom Motor vorgegeben. Und die entspricht ca. 20 Schritten (von offen bis geschlossen). Aber eben...die Prozentwerte des Winkels gehen nicht von 0-100%, sondern eher 0-60%.

Werd das aber sicher nochmals genauer anschauen.

[starwarsfan]

Hallo Hansjörg

Ich wohne nun seit bald 1.5 Jahr in unserem neu gebauten Haus. Es hat 15 Fenster mit Jalousien. Auf dem Dach (genauer an der Südfassade ganz oben) ist eine (teure) Elsner Suntracer KNX sl Wetterstation montiert.
In der Zeit, in der wir hier wohnen, ist mir aufgefallen, wie stark sich das Haus durch die Fenster aufwärmt, wenn man es nicht beschattet. (Bis jetzt bediene ich die Jalousien noch manuell, bzw. über Edomi ohne Logik)
Ich habe schon 1-2 Versuche gestartet, mich mit der Elsner Wetterstation zu beschäftigen. Aber trotz der recht umfangreichen Doku ist vieles für mich unklar. Und leider beschreibt die Doku einfach alle Funktionen ohne aber sinnvolle Praxisbeispiele zu geben. (Zudem ist die Temperatur-Messung ein Witz...kaum scheint die Sonne, gibt es Abweichungen im zweistelligen (!) Bereich. Ohne Sonne ist sie einigermassen korrekt. Ein Offset bringt da also nicht viel.)

So in etwa ging es mir auch. Mir haben dann bedingt durch unsere Hausform die drei steuerbaren Fassaden nicht mehr gerreicht und somit habe ich mit dem Umstieg auf Edomi den Beschattungs-LBS entwickelt (bzw. bin immer noch dabei...).

Nun verfolge ich seit einiger Zeit deinen (alten und vorallem neuen) LBS und würde es gerne mal damit wagen. Irgendwie scheint mir ein Edomi LBS einfacher zu parametrieren, als eine Wetterstation in der ETS. (Und ich habe im Moment mehr Vertrauen in deine Arbeit...)

Woah, das hört man gern. Vielen Dank!

Vorallem hoffe ich hier auf mehr Unterstützung für einen "Beschattungs-Laien" wie mich.

Joa, das kriegen wir schon hin.

Sehe ich das richtig, dass man den LBS pro Fassade oder ggf. sogar pro Fenster laufen lassen muss? D.h. wenn Fenster sich gleich verhalten sollen, kann man sie durch eine Instanz verknüpfen. Will man ein bestimmtes Fenster anders steuern, so müsste man diese Fenster dann mit einer weiteren Instanz verknüpfen?

So ist es. Ich hatte am Anfang auch je Fassade einen LBS, bin aber mittlerweile auf dem Stand, je Fenster einen LBS im Einsatz zu haben. Das ist überhaupt kein Problem.

Natürlich fängt es mit den "Stammdaten" an. Wichtig ist ja vorallem der Winkel der jeweiligen Fassade. Mein Hausgrundriss sieht folgendermassen aus:

D.h. eine horizontale Azimut-Linie (Nord oder Süd) wäre 90° und ich habe 76°, somit eine Abweichung von 14° (die Abweichung gilt dann natürlich für alle 4 Fassaden).
In deinem LBS müsste man aber den Azimut von Innen nach Aussen gesehen, angeben. Wie kann man das in meinem Fall für die Ost-, Süd- und West-Fassade berechnen?
(Das eigentliche Haus ist übrigens quadratisch. Rechts (Osten) auf dem Bild ist der Anbau mit dem Carport-Flachdach. An der Ost-Fassade hat es nur Fenster am Hauptgebäude und auch nur im 1. Stock, d.h. oberhalb des Anbaus/Carports)

Sorry, aus dieser Beschreibung kann ich mir nicht viel nehmen. Aber das ist ganz einfach. Ich nehme an, der Grundriss ist korrekt "genordet", also oben ist Norden und unten ist Süden. Nun legst Du einen 360°-Winkelmesser auf den Grundriss, wobei der Mittelpunkt des Winkelmesser auf der zu bestimmenden Fassade liegt und 0° genau nach oben resp. genau nach Noden zeigt. Das Azimut der Fassade kannst Du nun ablesen, indem du vom Mittelpunkt des Winkelmessers im rechten Winkel zur Fassade "nach draussen" schaust und dabei den Winkel abliest.

Um bei Deinem Beispiel zu bleiben wäre das von Dir oben angegebe Azimut nicht 76° sondern 346° und das Azimut links nicht 166° sondern 256°. Soweit klar? Wenn nicht, fragen!

Meine Lamellen sind 7 cm breit und haben einen 7 cm Abstand.

Rechnerisch würde das zwar funktionieren, rein technisch glaube ich aber nicht, dass das wirklich so ist! Wenn Du die Lamellen ganz schliesst, dann überlappen sich diese mit ziemlicher Sicherheit ein wenig. Und genau um diese Überlappung sollte der Abstand mindestens kleiner sein als die Lamellenbreite. Das solltest Du nochmal genau nachmessen.

Lux-Werte erhalte ich von der Wetterstation.
Da die Wetterstation den Sonnenstand selber berechnen kann, liefert sie auch die beiden Werte für den Sonnenstand (Aximut und Elevation). In der ETS werden die Werte als Winkel (Datentyp 14.007) angezeigt. In Edomi bekomme ich aber nur ein 4-Byte Wert (z.B. 1129623116). Und den passenden Datentyp habe ich nicht gefunden (bzw. kennt Edomi evtl. noch nicht).
Dein LBS verlangt aber Winkelgrad als Eingang, oder?

Edomi kennt doch DPT14, das ist kein Problem:

2017-03-26_DPT-Elevation.png

Als Jalousien-Aktor kommen MDT zur Anwendung. Ich kann dort die absolute Höhe in Prozent angeben (funktioniert in der ETS, wie genau das aber ist, weiss ich nicht).
Bei der Lamellensteuerung sieht es so aus, dass ich ebenfalls Prozentwerte übermitteln kann. 0% = flach (90°), 100% = zu (ca. 10°, nicht nachgemessen)
Ich habe mal in der ETS getestet und gesehen, dass sich die Lamellen immer nur alle 3% bewegen. Also 0,1 und 2 passiert nichts. 3% verstellt sich etwas. 4 und 5 nichts, 6% bewegt sich was. usw.
Aber bei max. 60% ist dann Schluss, d.h. die Lamellen sind dann zu. Alle Werte >60% ändern nichts mehr. Somit entspricht eigentlich 60% 100%. Kann oder muss man das im LBS definieren, damit er die Zwischenstände korrekt berechnen kann?

Das sieht eher nach einer nicht sauberen Konfiguration resp. Einstellung der Verfahrzeiten aus. Ich kenne den Aktor nicht, aber irgendwie lässt er sich mit Sicherheit dahingehend konfigurieren. Es gibt da sicher eine Möglichkeit, die genauen Zeiten einzustellen die Dein Behang braucht, um von ganz oben nach ganz unten oder auch um von ganz offen (waagerecht) nach ganz geschlossen (senkrecht) zu fahren. Damit kannst Du dann bspw. auch 95% anfahren und hast einen leicht geöffneten Behang.

Folgende Funktionen möchte ich gerne umsetzen (Liste ohne Priorisierung):
- Nachtfunktion: Jalousien gehen bei Dunkelheit/Dämmerung zu (Ausnahme ein Fenster) und am Morgen wieder auf (wenns hell ist oder über einen optionalen Zeitpunkt, falls dieser nicht in der Dunkelheit liegt.)
- Beschattung: Am Tag gehen die Jalousien bei Sonnenschein runter, sofern die Fassade von der Sonne beschienen wird.
- Beschattung: Lamellenwinkel wird langsam angepasst.
- Beschattung: Jalousien gehen tagsüber nur bis ca. 80% runter, damit für Pflanzen und Katzen noch ein "Lichtstreifen" übrigbleibt. (Konstanter Wert)

Das ist mit dem Baustein kein Problem, lässt sich alles machen.

Beim Benutzen kommen vermutlich dann weitere Detailwünsche... ;-)

[rdeckard]

Hallo Yves
Ich wohne nun seit bald 1.5 Jahr in unserem neu gebauten Haus. Es hat 15 Fenster mit Jalousien. Auf dem Dach (genauer an der Südfassade ganz oben) ist eine (teure) Elsner Suntracer KNX sl Wetterstation montiert.
In der Zeit, in der wir hier wohnen, ist mir aufgefallen, wie stark sich das Haus durch die Fenster aufwärmt, wenn man es nicht beschattet. (Bis jetzt bediene ich die Jalousien noch manuell, bzw. über Edomi ohne Logik)
Ich habe schon 1-2 Versuche gestartet, mich mit der Elsner Wetterstation zu beschäftigen. Aber trotz der recht umfangreichen Doku ist vieles für mich unklar. Und leider beschreibt die Doku einfach alle Funktionen ohne aber sinnvolle Praxisbeispiele zu geben. (Zudem ist die Temperatur-Messung ein Witz...kaum scheint die Sonne, gibt es Abweichungen im zweistelligen (!) Bereich. Ohne Sonne ist sie einigermassen korrekt. Ein Offset bringt da also nicht viel.)

Nun verfolge ich seit einiger Zeit deinen (alten und vorallem neuen) LBS und würde es gerne mal damit wagen. Irgendwie scheint mir ein Edomi LBS einfacher zu parametrieren, als eine Wetterstation in der ETS. (Und ich habe im Moment mehr Vertrauen in deine Arbeit...)
Vorallem hoffe ich hier auf mehr Unterstützung für einen "Beschattungs-Laien" wie mich.

Sehe ich das richtig, dass man den LBS pro Fassade oder ggf. sogar pro Fenster laufen lassen muss? D.h. wenn Fenster sich gleich verhalten sollen, kann man sie durch eine Instanz verknüpfen. Will man ein bestimmtes Fenster anders steuern, so müsste man diese Fenster dann mit einer weiteren Instanz verknüpfen?

Natürlich fängt es mit den "Stammdaten" an. Wichtig ist ja vorallem der Winkel der jeweiligen Fassade. Mein Hausgrundriss sieht folgendermassen aus:
azimut.jpg


D.h. eine horizontale Azimut-Linie (Nord oder Süd) wäre 90° und ich habe 76°, somit eine Abweichung von 14° (die Abweichung gilt dann natürlich für alle 4 Fassaden).
In deinem LBS müsste man aber den Azimut von Innen nach Aussen gesehen, angeben. Wie kann man das in meinem Fall für die Ost-, Süd- und West-Fassade berechnen?
(Das eigentliche Haus ist übrigens quadratisch. Rechts (Osten) auf dem Bild ist der Anbau mit dem Carport-Flachdach. An der Ost-Fassade hat es nur Fenster am Hauptgebäude und auch nur im 1. Stock, d.h. oberhalb des Anbaus/Carports)

Meine Lamellen sind 7 cm breit und haben einen 7 cm Abstand. Lux-Werte erhalte ich von der Wetterstation.
Da die Wetterstation den Sonnenstand selber berechnen kann, liefert sie auch die beiden Werte für den Sonnenstand (Aximut und Elevation). In der ETS werden die Werte als Winkel (Datentyp 14.007) angezeigt. In Edomi bekomme ich aber nur ein 4-Byte Wert (z.B. 1129623116). Und den passenden Datentyp habe ich nicht gefunden (bzw. kennt Edomi evtl. noch nicht).
Dein LBS verlangt aber Winkelgrad als Eingang, oder?

Als Jalousien-Aktor kommen MDT zur Anwendung. Ich kann dort die absolute Höhe in Prozent angeben (funktioniert in der ETS, wie genau das aber ist, weiss ich nicht).
Bei der Lamellensteuerung sieht es so aus, dass ich ebenfalls Prozentwerte übermitteln kann. 0% = flach (90°), 100% = zu (ca. 10°, nicht nachgemessen)
Ich habe mal in der ETS getestet und gesehen, dass sich die Lamellen immer nur alle 3% bewegen. Also 0,1 und 2 passiert nichts. 3% verstellt sich etwas. 4 und 5 nichts, 6% bewegt sich was. usw.
Aber bei max. 60% ist dann Schluss, d.h. die Lamellen sind dann zu. Alle Werte >60% ändern nichts mehr. Somit entspricht eigentlich 60% 100%. Kann oder muss man das im LBS definieren, damit er die Zwischenstände korrekt berechnen kann?

Ich hoffe auf etwas Unterstützung, bis ich mich dann selber mehr an die Thematik gewöhnt habe. (Als Gegenleistung kann ich auch eine Praxisanleitung von meinen Settings erstellen.)

Folgende Funktionen möchte ich gerne umsetzen (Liste ohne Priorisierung):
- Nachtfunktion: Jalousien gehen bei Dunkelheit/Dämmerung zu (Ausnahme ein Fenster) und am Morgen wieder auf (wenns hell ist oder über einen optionalen Zeitpunkt, falls dieser nicht in der Dunkelheit liegt.)
- Beschattung: Am Tag gehen die Jalousien bei Sonnenschein runter, sofern die Fassade von der Sonne beschienen wird.
- Beschattung: Lamellenwinkel wird langsam angepasst.
- Beschattung: Jalousien gehen tagsüber nur bis ca. 80% runter, damit für Pflanzen und Katzen noch ein "Lichtstreifen" übrigbleibt. (Konstanter Wert)

Beim Benutzen kommen vermutlich dann weitere Detailwünsche... ;-)

In meinem Fall würde nur die Ost-, Süd- und Westfassade gesteuert werden. Ein Fenster im Schlafzimmer und die Gartensitzplatztür im Wohnzimmer sollen anders gesteuert werden (muss ich noch im Detail schauen). Somit gehe ich davon aus, dass ich später 5 Instanzen deines LBS laufen lassen werde. Richtig?

Zum Testen würde ich natürlich nur mal mit einem Fenster beginnen.

Und vielen Dank nochmals für deine tolle Arbeit und dein Herzblut!!

Gruss, Hansjörg

[starwarsfan]

Hallo Andi

Hallo Yves,
es wird immer besser, Du näherst Dich dem Optimum!

Cool, freut mich zu hören.

extrem positiv, da nun funktioniert / gelöst:
- Das Output Problem an A8 ist gelöst, es kommt der richtige Status nun wieder raus.
- E40/E60 Trigger führen nun immer zu entsprechenden sofortigen Reaktionen! Auch laufende andere Timer werden hier sauber beendet.
- E1 als Trigger funktioniert auch sauber und schreibt immer die Ausgänge.
- das Timerhandling funktioniert nun auch deutlich besser, der Baustein ist nun nicht mehr immer "tot" und bricht bei entsprechenden Eingangsänderungen nun auch in den allermeisten Fällen den laufenden Timer korrekt ab!

Thx für die Rückmeldung, sehr schön.

negativ ist mir bisher nur das Timerverhalten beim Status 5 aufgefallen:

Hier habe ich quasi die Wolke bei einem laufenden Beschattungstimer simuliert. Ich hätte erwartet daß bei laufendem Beschattungstimer sobald ein Helligkeitswert unter der Schwelle wieder kommt, dieser Timer auch abgebrochen wird (und ggf. dann sobald der Wert wieder über die Schwelle geht dann halt neu aufgesetzt wird). In meinem Beispiel läuft trotz "der Wolke" der timer zu Ende und es wird die Beschattung ausgelöst. Nachdem dann die Beschattungsposition angefahren wurde wird direkt der Öffnungstimer gestart und nach Ablauf dessen wird die Jalousie wieder geöffnet. In diesem Fall wäre es sinnvoll gewesen die Jalousie einfach gar nicht zu verfahren.

Korrekt, laut Code sollte das auch so sein, dass der Timer abgebrochen wird. Ich werd's mal im Dev-Setup nachstellen...

ansonsten ist mir nichts weiteres aufgefallen bisher, ich hoffe das bleibt so!

Das hoffe ich auch jedes mal...

Vielen Dank für Deine echt tolle Arbeit!

Ich werde damit nun mal probieren eine einfache Vorschaltlogik für das Temperaturhandling zu entwickeln.

Gut, bin gespannt!

PS: Nur mal am Rande erwähnt, hier ein Screenshot meines Dev-Setup. Das sind mehrheitlich Drehregler und damit kann ich alle Eingänge explizit setzen und die Reaktion des Bausteins beobachten.

2017-03-26_DevSetupBeschattung.png

[tger977]

Hallo Yves,
es wird immer besser, Du näherst Dich dem Optimum!

extrem positiv, da nun funktioniert / gelöst:
- Das Output Problem an A8 ist gelöst, es kommt der richtige Status nun wieder raus.
- E40/E60 Trigger führen nun immer zu entsprechenden sofortigen Reaktionen! Auch laufende andere Timer werden hier sauber beendet.
- E1 als Trigger funktioniert auch sauber und schreibt immer die Ausgänge.
- das Timerhandling funktioniert nun auch deutlich besser, der Baustein ist nun nicht mehr immer "tot" und bricht bei entsprechenden Eingangsänderungen nun auch in den allermeisten Fällen den laufenden Timer korrekt ab!

negativ ist mir bisher nur das Timerverhalten beim Status 5 aufgefallen:
Timerproblem_Status5.PNG

Hier habe ich quasi die Wolke bei einem laufenden Beschattungstimer simuliert. Ich hätte erwartet daß bei laufendem Beschattungstimer sobald ein Helligkeitswert unter der Schwelle wieder kommt, dieser Timer auch abgebrochen wird (und ggf. dann sobald der Wert wieder über die Schwelle geht dann halt neu aufgesetzt wird). In meinem Beispiel läuft trotz "der Wolke" der timer zu Ende und es wird die Beschattung ausgelöst. Nachdem dann die Beschattungsposition angefahren wurde wird direkt der Öffnungstimer gestart und nach Ablauf dessen wird die Jalousie wieder geöffnet. In diesem Fall wäre es sinnvoll gewesen die Jalousie einfach gar nicht zu verfahren.

ansonsten ist mir nichts weiteres aufgefallen bisher, ich hoffe das bleibt so!
Vielen Dank für Deine echt tolle Arbeit!

Ich werde damit nun mal probieren eine einfache Vorschaltlogik für das Temperaturhandling zu entwickeln.

[starwarsfan]

Update: 19000145 Beschattungssteuerung-NG, V3.0.RC5

• Handling der Abfrage auf laufende Timer ueberarbeitet. Die Trigger-Eingaenge werden nun unabhaenig davon ausgewertet.
• Ausgabe des Aktivierungsstatus korrigiert.

Happy testing!

[starwarsfan]

Ok, dann habe ich wohl etwas beim testen übersehen.

Bin heute auf einer Weiterbildung, weiss noch nicht, ob und wann ich heute dazu komme...

[baumhaus123]

Ich habe ähnliches beobachtet. Nach einer Deaktivierung ließ sich der Baustein gar nicht mehr aktivieren, bzw. es wurde zumindest kein aktiv-Status mehr ausgegeben.

Ich bin jetzt erstmal ein paar Tage nicht zuhause, werde aber Ende der nächsten Woche weitertesten.

Keep up the good work!

[tger977]

Hallo Yves,

Nachdem nun der Baustein mit der Codeänderung von oben sich mehrfach komisch verhielt (habe keinerlei Reaktion mehr hinbekommen und im Log kam nur immer die Meldung daß der Baustein deaktiviert sei, an A8 bekam ich auch partout keine 1 mehr hin...) habe ich nun auf Deine Originalversion RC4 zurückgedreht.

Aber auch hier habe ich ähnliche Probleme wieder. Nach einem Projekt neu aktivieren bekomme ich an A8 gar keine Ausgabe mehr, der Baustein arbeitet aber mit der Beschattungsautomatik soweit korrekt und gibt an den anderen Ausgängen auch plausible Werte raus:

RC4_A8-Problem.PNG

ich habe an einer anderen Jalousie auch länger rumgespielt und da war es dann irgendwann soweit daß an A8 nur noch eine 0 anlag und keinerlei Ausgänge mehr geschrieben wurden, egal welche Trigger ich auch gesetzt habe (E1, E5-11, E40, E60):
(Unterschied zu Bild oben ist A8 mit 0 obwohl E11 = 1 und E1 auch mehrfach auf 1 gesetzt wurde, die Ausgänge sind alle noch von der letzten korrekten Berechnung und ändern sich dann nicht mehr)

RC4_A8-Problem.PNG

[tger977]

ich meinte der ganze else Pfad gehört doch in geschweifte Klammern.

} else  {
            if (!LB_LBSID_isLBSActive($E)) {
                return;
            }
            if (LB_LBSID_isPositionChangedExternally($E)) {
                return;
            }
            if (LB_LBSID_isLBSLocked($E)) {
                return;
            }
            if ($E[$GLOBALS["LB_LBSID_INPUT_Brightness"]]['refresh'] == 1
                || $E[$GLOBALS["LB_LBSID_INPUT_BrightnessDawn"]]['refresh'] == 1
                || $E[$GLOBALS["LB_LBSID_INPUT_Elevation"]]['refresh'] == 1
                || $E[$GLOBALS["LB_LBSID_INPUT_Azimut"]]['refresh'] == 1
            ) {
                LB_LBSID_debug(true, "===== === = Timer finished and trigger input refreshed, starting LBS = === ===");
                $doTheWork = true;
            } elseif (!LB_LBSID_isOutputSet()) {
                LB_LBSID_debug(true, "===== === = Timer finished and outputs not set, starting LBS = === ===========");
                $doTheWork = true;
            }
        }

[starwarsfan]

Das kann aber nicht funktionieren, da mit obiger Änderung eine öffnende geschweifte Klammer entfällt. Damit musst Du die dazugehörende schliessende Klammer auch entfernen!

[tger977]

Code ist geändert und wird so mal getestet (die geschweiften Klammern hab ich aber drin behalten...)

bin mal gespannt auf morgen und werde berichten.

[starwarsfan]

Hi Andi

danke fürs erneute Update! Pünktlich zum WE kann nun wieder fleissig getestet werden und das Wetter scheint auch sonnig zu werden...

So ist der Plan...

in der Hauptfunktion noch auf einer zu hohen Ebene ist, da damit während eines Timers z.B. auch Änderungen an der Helligkeit, Azimut, etc. auch komplett ignoriert werden. Gerade Helligkeitsänderungen sollten doch aber während eines Timers ausgewertet werden, dazu sind ja die Timer da.

Bzgl. Azimut etc. muss ich mal drüber nachdenken aber bzgl. Helligkeit will ich das eben genau nicht haben! Wenn das so wäre, dann bekommt man damit bei wechselhaftem Wetter ein ständiges auf und ab des Behangs. Das hatte ich schon und erst mit den Timern war das dann endlich brauchbar in Griff zu bekommen.

Du kannst ja die Zeile

} else if (LB_LBSID_isTimerFinished()) {

durch

} else

ersetzen, am Ende des Blocks die nun überzählige schliessende geschweifte Klammer entfernen und schauen, wie sich der Baustein verhält. Ich werd's auch mal testen, weiss nur nicht, ob ich an diesem Wochenende dazu komme...

[tger977]

Hallo Yves,

danke fürs erneute Update! Pünktlich zum WE kann nun wieder fleissig getestet werden und das Wetter scheint auch sonnig zu werden...

Ich glaube nach kurzem Codedifferenz ansehen aber trotzdem dass das

else if (LB_LBSID_isTimerFinished())

in der Hauptfunktion noch auf einer zu hohen Ebene ist, da damit während eines Timers z.B. auch Änderungen an der Helligkeit, Azimut, etc. auch komplett ignoriert werden. Gerade Helligkeitsänderungen sollten doch aber während eines Timers ausgewertet werden, dazu sind ja die Timer da. Sprich wenn eine dunkle Wolke für ein paar Sekunden verdunkelt wird ein Timer zum Öffnen gestartet, wenn aber die Wolke innerhalb des Timers wieder weg ist soll trotzdem im Beschattungszustand geblieben werden und der Timer beendet werden. Im Moment läuft ein einmal getriggerter Timer immer hart durch und führt zwangsläufig zu einem Zustandswechsel.

Wenn ich mir den Code in der Statemachine ansehe prüfst Du dort doch auch eigentlich überall nochmals explizit per Funktionsaufruf isTimerFinished () separat ab bevor wirklich ein Zustand gewechselt wird. Könnte damit die Abfrage in der Hauptfunktion nicht entfallen?

[starwarsfan]

N'abend miteinander,

sodele, die 3.0.RC4 ist online:

• Handling der Trigger-Eingaenge E1, E12, E40 und E60 komplett neu implementiert, allfaellig bereits laufende Timer werden nun ignoriert
• Schwellwerte fuer automatische LBS-Deaktivierung sind nun via E16/E17 konfigurierbar

Viel Spass und her mit dem Feedback!