Programmierung Rolläden macht nicht was sie soll

[Schattenmann]

Guten Tag zusammen,

bei meiner Rolladenprogrammierung hakt es. Von der IT-Programmierung kommend musste auch ich erstmal lernen, dass ein Homematicprogramm nicht gleich aufgebaut ist wie andere Programmiersprachen. So habe ich mir sämtliche Tipps und Hints ("Post-it-Theorem" etc.) hier in den Foren zu Gemüte geführt und TROTZDEM hakt es und ich verzweifle.

Ich würde die alten Hasen bitten, über mein Programm zu schauen und den Fehler zu benennen, wenn das möglich ist.

Das Programm steuert nur eine Trigger-Variable (dezimal-Zahl). Die eigentliche Ausführung der Rolläden/Raffstores funktioniert tadellos, sobald die Variablen mal gesetzt sind. Nur das Setzen klappt eben nicht.

Zu Steuerung kommt ein Helligkeitssensor zum Einsatz. Gesteuert werden soll in 2 (Helligkeits-)Stufen. Die Gründe hierfür sind irrelevant.

Also einfach:
- "Erreicht die Helligkeit in einem vorgegebenen Zeitfenster >X, dann Trigger auf Stufe 1"
- "Erreicht die Helligkeit in einem (anderen) vorgegebenen Zeitfenster >Y (Y>X), dann Trigger auf Stufe 2."

As simple as it is.

Das komische, am Abend habe ich was ähnliches Retour mit abnehmender Helligkeit, das klappt.

Auch hatte ich mal ausprobiert, die Helligkeitsbedingung von Stufe 1 nicht einfach "größer" sondern auf einen Bereich mit Obergrenze einzugrenzen. Hilft nicht.

[MichaelN]

den Fehler zu benennen

1.00 != 1.10

[Xel66]

IT-Programmierung kommend musste auch ich erstmal lernen

Das ist eher hinderlich. Die CCU arbeitet eben anders.

Dein Trigger ist in der Zeit von 05:30 bis 09:00 Uhr WAHR, egal wie hell es ist (es ist immer <0,1). Daher landest Du immer im ersten DANN (Prüfung der Bedingungen von oben nach untern). WENN und SONST WENN tauschen, oder im WENN die Bedingung auf "Raffstore Trigger kleiner 1 nur prüfen" einbauen und natürlich @MichaelNs Einwurf beachten.

Gruß Xel66

[Schattenmann]

Hallo an euch beide,

danke für die Antwort. Es hilft, sich mit jemand auszutauschen.

@MichaelN: Durch setzen des Triggers von 0 auf 1 im ersten Block, werden Rolläden verfahren in einem anderen Programm, an dessen Ende wiederum dann der Trigger von 1 auf 1.1. gehoben wird. Das soll signalisieren, dass das Verfahren dieses Blocks erfolgreich ausgeführt wurde und nicht nochmal aufgerufen wird. So kann ich die einzelenen Programm Ausführungen gut nachverfolgen. Vermutlich hattest du das in meinem Post überlesen und daher nur an einen leichten Zahlendreher gedacht (??).

@Xel66. Deine Aussage musst du mir noch etwas näher formulieren bitte. Aus meinem Verständnis wird in das erste DANN nur dann hineingegangen, wenn der erster WENN = WAHR ist. Dieser ist aber nur dann WAHR wenn alle (hier = vier) UND-Bedingungen WAHR sind. Ist auch nur eine dieser FALSCH, dann wird der WENN Block FALSCH und auch nicht in den DANN Block gegangen. Stimmt das?
Falls das so stimmt, dann wird m.E. nach dem ersten Ausführen des ersten DANN-Blocks der "Raffstore Trigger" auf 1.0 (und daran anschließend auf 1.1) gesetzt. Bei wiederholtem Aufrufen dieses Programms (außen hängt ja der "Helligkeitssensor-ändert-sich-bitte-komm-hier-rein"-Post-it) ist der erste WENN Block dann nicht mehr WAHR (Bedingungen "Raffstore Trigger = 0.00 = FALSCH) und es wird zum nächsten SONST-WENN weitergegangen.

Was ist heirbei mein Denkfehler? Auch wenn im ersten WENN-BLOCK die Zeitsteuerung-prüfen = WAHR ist. Die anderen 3 Attribute sind doch nicht mehr alle WAHR...


Ich vergaß zu erwähnen, dass um Punkt 9.00 alle Rolländen hochgehen, was bedeutet, das der SONST-WENN mit der 3. Bedingung funktioniert, nicht aber mit den anderen beiden ODER-Blöcken im SONST-WENN....

[MichaelN]

Siehe Thread zur WebUI - Logik ( auch über die Debugging-Tips in meiner Signatur zu finden)
Trigger und Bedingungsprüfung sind unabhängig voneinander.
Wenn "unten" ein Trigger anspricht wird trotzdem von oben an jede Bedingung geprüft, egal wo der Trigger sitzt.

[HM-Villa]

Hast Du bedacht, dass Dein Helligkeitstrigger (0,x Lux) schon lange "durch" ist, bevor das jeweilige Zeitmodul den ODER-Block freigeben kann? Es muss auch mal wieder dunkler werden als 0,x Lux, damit's wieder triggern kann. Hast Du den Sensor eingegraben oder willst Du wirklich schon bei 0,x Lux schalten? Das ist doch noch stockdunkel.

[Schattenmann]

@MichaelN: Danke für die Tipps zum Debuggin, die arbeite ich gleich durch. Dass der Trigger von unten als Post-it außen angeklebt wird und dann trotzdem von oben nach unten abgearbeitet wird, weiß ich inzwischen auch schon. Aber m.E. ist das ja nicht schlimm in meinem Programm, das von oben kommend wg. des "Raffstore Trigger = 0 prüfen", der erste Wenn Block übersprungen wird.

@HM-Villa: Nicht wunder, mein Helligkeitssensor ist in der Garage (wo es den Batterien schön warm ist). Ein Fenster nach Norden verschmiert den eigentlichen Helligkeitswert. Der Helligkeitsmessung (siehe Bild) entsprechend liegt das im Bereich des definierten...

Als Work-Around (was ich ziemlich dämlich fände) würde ich ein Extra Programm für Stufe 2 definieren, dass dann unabhängig vom ersten läuft. Was ist davon zuhalten?

Weiter unten in dem Programm, zum abendlichen Schließen, funktioniert die 2 Stufigkeit wunderbar...Siehe:

[HM-Villa]

Doch, ich wundere mich trotzdem. Messgeräte mit AD-Wandler haben bei kleinen Werten rel. große Messfehler und bei derart kleinen Werten hast Du nix übrig für eine eventuell notwendige Hysterese. Warme Batterien sind, finde ich, kein Grund. Mein Helligkeitssensor hängt im Freien und ein Batteriesatz hält reichlich 2 Jahre (HmIP-SLO). Aber sei's drum.

Dein Diagramm vom Helligkeitsverlauf bestätigt meine Vermutung. 6:14 Uhr hatte es 0,1 Lux, 6:30 Uhr dann 0,5.

Wenn Du auf Änderung auslöst, wird die Bedingung wahr und damit das Programm getriggert, wenn der Messwert vorher kleiner als der angegebene Bereich war und er nun die angegebene Bedingung (bei Dir also >= 0,5 Lux) das erste Mal erfüllt (lt. Diagramm 6:30 Uhr) - danach nie wieder, es sei denn, der Messwert verlässt zwischenzeitlich den Bereich (bei Dir dann < 0,5 Lux).

Da die Helligkeits-Bedingungen in den ersten beiden ODER-Blöcken im Sonst-Wenn... nicht mehr wahr sind, wenn die Zeitmodule es ermöglichen würden, dass einer der beiden ODER-Blöcke wahr wird, tut sich da nix.

Wenn Du einfach den Sonst-Wenn...-Teil in ein zweites Programm packst, löst das Dein Logik-Problem in keinster Weise. Du musst Dir darüber im klaren werden, wass Dein Programm genau machen soll. Soll es z. B. werktags um 7:15 Uhr arbeiten oder wenn 0.5 Lux erreicht sind? Im Moment willst Du, dass es z. B. werktags von 7:15 Uhr bis 9:00 Uhr darauf wartet, dass (erstmalig) 0,5 Lux erreicht werden, was aber nie eintritt, 's ist vorher schon heller. Deshalb macht's korrekterweise auch nix.

[Baxxy]

Dein Trend zeigt die morgendlich ansteigende Helligkeit.

• 0.1 LUX wurden um 06:14 überschritten, passen also in das Zeitfenster vom 1.Wenn welches dann ausgeführt wird.
• 0.5 LUX wurden um 06:32 überschritten, die Zeit liegt außerhalb beider Zeitbereiche im Sonst, wenn..., es wird also dessen DANN nicht ausgeführt.
• 0.6 LUX wurden ca. um 06:38 überschritten, die Zeit liegt außerhalb beider Zeitbereiche im Sonst, wenn..., es wird also dessen DANN nicht ausgeführt.
• Um 09:00 ist die Helligkeit egal, das Sonst, wenn... DANN wird ausgeführt.

Ach Mist, @HM-Villa ist auch noch wach und war schneller.


Eine Lösung wäre alle "Helligkeits-Trigger" bis auf einen auf "nur prüfen" zu stellen und den letzten auf "bei Aktualisierung".

[HM-Villa]

@Baxxy: Sei nicht traurig ist doch kein Wettbewerb. Und viele Grüße in die Hauptstadt aus'm Erzgebirge. Mein Akku ist gleich leer, kann also keinen weiteren Senf loswerden.