[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.8.x

[CoolTux]

Du hast falsch runter geladen. Du musst auf den nach unten zeigenden Pfeil klicken dann kommt ein Download Pop-up. Und es wird ein Tip runter geladen. Danach brauchst nur das Modul aus dem Zip packen.

Alles weitere am besten im anderen Thread.

[mrfloppy]

Du hast falsch runter geladen. Du musst auf den nach unten zeigenden Pfeil klicken dann kommt ein Download Pop-up. Und es wird ein Tip runter geladen. Danach brauchst nur das Modul aus dem Zip packen.

Hab grad meinen Beitrag editiert, war mein Fehler schon drauf gekommen!
Danke

[flummy1978]

Holla,

vielen Dank für Deine Antwort auf die um die Ecke Realisierung...  Ich habe mich wieder etwas weiter heran gemacht, das Ganze mit Hilfe von Dummys zu testen. D.h. ich hatte einen exakten Einfluss auf das was an Werten übergeben wird. Meine Erkenntnis dazu wird Dir und vielen anderen (so hoffe ich), viele "Fehler" erklären, warum das Teil nach Veränderung von Wert X (z.B. Brightness über den Grenzwert) TROTZDEM nichts passiert ist.....

Vielleicht irre ich mich ja auch ... aber vielleicht hab ich auch Recht. Mein Vorgehen war wie folgt:

Ein Dummy Rollo (dum_JALOU_Gang - list unten) erstellt, das ein Rollo simuliert hat die relevanten Werte:
ASC_Shading_Mode: always
ASC_Shading_Pos: 90
ASC_BlockingTime_afterManual : 10
ASC_BrightnessSensor dum_JALOU_Gang_VARS:BH1750_Illuminance >>> AUCH ein Dummy
ASC_Shading_InOutAzimuth: 195:299
ASC_Shading_MinMax_Elevation 0
ASC_Shading_Min_OutsideTemperature 3
ASC_Shading_StateChange_SunnyCloudy: 2500:2000
ASC_Shading_WaitingPeriod 60

Somit war ab 14 Uhr lediglich die Helligkeit die ich selbst hin und her geschoben habe, meine Einzige Variable.  Zeiten konnten fast ignoriert werden (10 und 90sek) sonnenstand war gegeben etc. Dennoch ist das DummyRollo nur ein Einziges mal hin und her gefahren. Nämlich als ich die Werte mehrfach hin und her verändert habe (im laufe einer Std)

Nun meine Vermutung
1. Ausschließlich Dinge die von außen kommen, erzeugen ein Event mit dem auch ASC was anfangen kann. - Brightnes Wert
2.  Hat man wie ich ein Astro Modul mit den "Standard" Einstellungen wird der Sonnenstand nur 1x die Std aktualisiert und verzögert dann vielleicht auch Reaktionen vom Device, den Sonnenstand betreffend ( Bei manuellem Auslösen des Updates hat sich im Beschattungsvorgang oder DEBUG nichts getan)
3. Der an 1. geänderte Wert muss mehrfach ein Event über dem Grenzwert auslösen, ansonsten passiert nichts. (so wie aktuell.... habe vor fast einer Std den Helligkeitsgrenzwert überschritten und bisher ist nichts passiert - Das DummyDevice steht immernoch auf shading out)

Die Punkte 1 und 3 führen meiner Meinung nach hier zu diskrepanzen, warum die Beschattung dann manchmal funktioniert und manchmal eben auch nicht.

In dem Betroffenem Punkt habe ich noch eine Frage:

So sieht das Brightness Reading aus: BH1750_Illuminance  3800   2020-04-28 17:55:11

So der Log: (Bewusst in quote, wegem dem Highlight)

ASC_DEBUG!!! 2020.04.28 17:55:11 - FnIsDay: dum_JALOU_Gang getDownBrightness: 1 Brightness: 3800 BrightnessMin: 500 Sunset: 0
ASC_DEBUG!!! 2020.04.28 17:55:11 - FnIsDay: dum_JALOU_Gang getUpBrightness: 1 Brightness: 3800 BrightnessMax: 800 Sunrise: 1
ASC_DEBUG!!! 2020.04.28 17:55:11 - ShadingProcessing: dum_JALOU_Gang - Übergebende Werte - Azimuth:250.2, Elevation: 33, Brightness: 1833, OutTemp: 16, Azimut Beschattung: 195, Azimut Endschattung: 299, Ist es nach der Zeitblockadezeit: JA, Das Rollo ist in der Beschattung und wurde manuell gefahren: JA, Ist es nach der Hälfte der Beschattungswartezeit: JA
ASC_DEBUG!!! 2020.04.28 17:55:11 - ShadingProcessing: dum_JALOU_Gang - Alle Werte für die weitere Verarbeitung sind korrekt vorhanden und es wird nun mit der Beschattungsverarbeitung begonnen
ASC_DEBUG!!! 2020.04.28 17:55:11 - FnIsDay: dum_JALOU_Gang Allgemein: 1

Woher kommen diese 1833 ? Genau das führt (so zumindest meine Vermutung) dass das Device genau deswegen nicht fährt ( weil der Grenzwert 2500 ist ). Diese 5-6 Zeilen kommen danach noch so 5, 6x (vermute Astro Events, weil ich den Timer verändert habe) und es passiert aber nichts weil Brightness bei 1833 bleibt. Das heisst solange ich die Brightnesswerte nicht verändere, passiert auch nichts am Wert.

Wenn man nun großzügige event-on-change Einschränkungen drin hat, kann es passieren, dass das Event über dem Grenzwert nur einmal und danach erst mal für lange Zeit nicht ausgelöst wird.


Vielleicht kann ich damit ein wenig dazu beitragen, dass man da näher kommt und würde mich freuen, wenn Du mir da auf die Sprünge helfen kannst......

List vom DummyRollo noch:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF       
   FUUID      5ea711c9-f33f-8d79-c546-01ac10ff960e215f
   NAME       dum_JALOU_Gang
   NR         6566
   STATE      open
   TYPE       ROLLO
   stoptime   1588083556
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2020-04-28 15:26:04   ASC_Enable      on
     2020-04-28 16:19:16   ASC_ShuttersLastDrive manual
     2020-04-28 15:26:09   ASC_Time_DriveDown 28.04.2020 - 20:45
     2020-04-28 15:26:09   ASC_Time_DriveUp 29.04.2020 - 06:13
     2020-04-28 15:26:05   associatedWith  AUTO_RolloSteuerung
     2020-04-28 16:19:00   command         open
     2020-04-28 16:19:00   desired_pct     0
     2020-04-28 16:19:00   drive-type      modul
     2020-04-28 16:19:00   last_drive      drive-up
     2020-04-28 16:19:16   pct             0
     2020-04-28 16:19:16   state           open
Attributes:
   ASC        1
   ASC_BlockingTime_afterManual 10
   ASC_BrightnessSensor dum_JALOU_Gang_VARS:BH1750_Illuminance
   ASC_Mode_Down off
   ASC_Mode_Up off
   ASC_Pos_Reading pct
   ASC_Shading_InOutAzimuth 195:299
   ASC_Shading_MinMax_Elevation 0
   ASC_Shading_Min_OutsideTemperature 3
   ASC_Shading_Mode always
   ASC_Shading_Pos 90
   ASC_Shading_StateChange_SunnyCloudy 2500:2000
   ASC_Shading_WaitingPeriod 60
   ASC_ShuttersPlace window
   ASC_TempSensor dev_SYS_wetter_ext:temperature
   DbLogExclude .*
   cmdIcon    open:fts_shutter_up closed:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop pct-100:fts_shutter_100:open pct-90:fts_shutter_80:closed pct-80:fts_shutter_80:closed pct-70:fts_shutter_70:closed pct-60:fts_shutter_60:closed pct-50:fts_shutter_50:closed pct-40:fts_shutter_40:open pct-30:fts_shutter_30:open pct-20:fts_shutter_20:open pct-10:fts_shutter_10:open pct-0:fts_shutter_10:closed
   event-on-change-reading .*
   rl_autoStop 0
   rl_excessBottom 2
   rl_excessTop 4
   rl_secondsDown 30
   rl_secondsUp 30
   rl_switchTime 1
   rl_type    normal
   userattr   ASC_Adv:on,off ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Delay ASC_Drive_DelayStart ASC_ExternalTrigger ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownValue_beforeNightClose ASC_PrivacyDown_Pos ASC_PrivacyUpValue_beforeDayOpen ASC_PrivacyUp_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Mode:absent,gone,off ASC_Shading_InOutAzimuth ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_SunnyCloudy ASC_Shading_WaitingPeriod ASC_Shutter_IdleDetection ASC_ShuttersPlace:window,terrace ASC_Sleep_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate
   verbose    4
   webCmd     open:closed:half:stop:pct

Viele Grüße
Andreas

[CoolTux]

Hallo Andreas,

1833 ist der Wert welcher durch das BrightnessAverage errechnet wurde. Per Default werden die letzten 3 Werte genommen und daraus wird der Durchschnitt ermittelt. Du kannst dies per Attribut ändern.

ASC_Shading_StateChange_SunnyCloudy 2500:2000 2

nimmt die letzten 2

ASC_Shading_StateChange_SunnyCloudy 2500:2000 1

nimmt immer nur einen Wert was ja da gleich des eigentlichen Brightnesswertes ist.

Für die Beschattung wird auf Brightness Event sowie auch auf ein Twilight Device Event reagiert und die Daten verarbeitet. Zu beachten ist auch die ASC_Shading_WaitingPeriod. Standard 20 min und eine Verarbeitung der Daten erfolgt nach ASC_Shading_WaitingPeriod / 2. Also hier 10min.

Wie gesagt wird in der neuen Version welche gerade in der Betaphase ist ein zusätzliches Reading für Shading im Rollo Device befüllt.

[flummy1978]

Hallo Marko,

Vielen Dank für Deine Antwort ....

ASC_Shading_StateChange_SunnyCloudy 2500:2000 2

nimmt die letzten 2

Das ist aber ein gänzlich undokumentiertes Feature oder ?
Gibt es solche Sachen noch wo anders zu beachten?

Wenn ich dann auf x:y 1 stelle muss ich dann trotzdem 3 Events haben, damit es dann beachtet wird ?
Könnte es grad an dem oberen Device nochmal reproduzieren indem nach dem 3 Event in der Helligkeit "gefahren" wurde....

Grüße
Andreas

[CoolTux]

Hallo Marko,

Vielen Dank für Deine Antwort .... Das ist aber ein gänzlich undokumentiertes Feature oder ?
Gibt es solche Sachen noch wo anders zu beachten?

Wenn ich dann auf x:y 1 stelle muss ich dann trotzdem 3 Events haben, damit es dann beachtet wird ?
Könnte es grad an dem oberen Device nochmal reproduzieren indem nach dem 3 Event in der Helligkeit "gefahren" wurde....

Grüße
Andreas

Sollte eigentlich in der Commandref stehen. Grübel nur gerade ob das erst ab 0.9er oder schon in der letzten 0.8er drin ist.

[xerion]

Sollte eigentlich in der Commandref stehen. Grübel nur gerade ob das erst ab 0.9er oder schon in der letzten 0.8er drin ist.

Das ist schon in der 8er Version drin gewesen zumindest laut device specific help.

Gesendet von meinem JSN-L21 mit Tapatalk

[xerion]

Ich habe noch eine andere und auch alte Sache. Vielleicht könntest du dir das Mal anschauen. Ich würde gerne das schließen der Rollos bei geöffneten Fenster und Residents absent nutzen wollen wenn  Shuter place auf window steht. Momentan geht das nur wenn ich es auf Terrasse Stelle. Bei window passiert bei absent Leider nichts. Selfdefense steht auf Default damit die Rollos bei absent nicht runter gehen wenn die Fenster geschlossen sind.

Gesendet von meinem JSN-L21 mit Tapatalk

[CoolTux]

Ich habe noch eine andere und auch alte Sache. Vielleicht könntest du dir das Mal anschauen. Ich würde gerne das schließen der Rollos bei geöffneten Fenster und Residents absent nutzen wollen wenn  Shuter place auf window steht. Momentan geht das nur wenn ich es auf Terrasse Stelle. Bei window passiert bei absent Leider nichts. Selfdefense steht auf Default damit die Rollos bei absent nicht runter gehen wenn die Fenster geschlossen sind.

Gesendet von meinem JSN-L21 mit Tapatalk

Lege ich auf meine ToDo. Im Moment ist leider viel los, bearbeite gerade 5 Module gleichzeitig 

[xerion]

Lege ich auf meine ToDo. Im Moment ist leider viel los, bearbeite gerade 5 Module gleichzeitig 

Perfekt. Danke dir nochmals für deine ständige Unterstützung und kompetenten Support. So macht es einfach Spass wenn weiß das dort jemand ist der ständig unterstützt.

Gesendet von meinem JSN-L21 mit Tapatalk

[flummy1978]

Das ist schon in der 8er Version drin gewesen zumindest laut device specific help.

Du hast Recht.... Ich für meinen teil habs übersehen (besser gesagt nicht beachtet, weil es früher auch nicht drin war) ABER.... ich bin mir sicher, dass 99 % der normalen User

ASC_Shading_StateChange_SunnyCloudy - Brightness Wert ab welchen die Beschattung stattfinden und aufgehoben werden soll, immer in Abhängigkeit der anderen einbezogenen Sensorwerte. Ein optionaler dritter Wert gibt an wie viele Brightnesswerte im Average Array enthalten sein sollen (default: 35000:20000 [3])

nicht verstehen werden. Ich hab es einfach übersehen.... Ob ich es dann so hätte zuordnen können ist ne andere sache.

@Marko: Imho wäre in dem Fall besser: Ein optionaler dritter Wert gibt an, wie viele Brightnesswerte für den aktuellen Brightness-Durchschnitt berücksichtigt werden. Standard ist [3] Mögliche Werte sind 3, 2 und 1 (oder auch andere ... ?)

Edith ergänzt noch Rechtschreibfehler und eine kleine Ergänzung für die Commandref / Doku - was auch immer: (Ergänzungen in Rot)

Damit die Beschattung Funktion hat, müssen folgende Anforderungen erfüllt sein.
Im ASC Device das Reading "controlShading" mit dem Wert on, sowie ein Astro/Twilight Device im Attribut "ASC_twilightDevice" und das Attribut "ASC_tempSensor".
In den Rollladendevices benötigt ihr ein Helligkeitssensor als Attribut "ASC_BrightnessSensor", sofern noch nicht vorhanden. Findet der Sensor nur für die Beschattung Verwendung ist der Wert DEVICENAME[:READING][Ø] ausreichend.
Alle weiteren Attribute sind optional und wenn nicht gesetzt mit Default-Werten belegt. Ihr solltet sie dennoch einmal anschauen und entsprechend Euren Gegebenheiten setzen. Die Werte für die Fensterposition und den Vor- Nachlaufwinkel sowie die Grenzwerte für die StateChange_Cloudy und StateChange_Sunny solltet ihr besondere Beachtung dabei schenken.
Von Standardwerten ist folgende Funktionsweise angestrebt:
1.   Event vom Astro oder Helligkeits Device kommt -> sind alle Werte innerhalb der Arbeitsbereiche, ändert sich der ASC Info-Zustand im Rollo von XX auf ,,in reserved" (Beschattung vorbereitet).
2.   Ein erneutes Event vom Astro oder Helligkeits Device kommt -> Überprüfung der Werte -> sind diese weiterhin gegeben folgt der Wechsel von ,,in reserved" auf ,,in"
3.   Bei Verwendung von DEVICENAME:HELLIGKEITSREADING ist zu beachten, dass ein Durchschnitt über die letzten 3 Events gerechnet wird. Möchte man das vermeiden muss man DEVICENAME:HELLIGKEITSREADING 1 setzen.
4.   Die Zeiten ASC_Shading_WaitingPeriod und ASC_BlockingTime_afterManual können die hier zusätzlich für eine Verzögerung sorgen.

Wichtig zu beachten: Es müssen mehrere Events für den Betrieb erfolgen. In den Standardeinstellungen vom Astro Modul erfolgt dieses z.B. nur 1 x pro Std. Kommt also Euer Helligkeits-Event auch nur 1x pro Stunde, könnte es > 2 Std dauern, bis Eure Beschattung greift.


MIR hätte dieser Text sehr geholfen. Vielleicht tut er es für andere auch und sorgt somit für weniger verwirrte Gesicher, wie bei mir 


Mich würde allerdings noch meine Frage aus #1639  interessieren: wenn ich Brightness auf "3000:2000 1" geändert habe, muss ich dann trotzdem 3 Brightness Events haben, damit sich am Rollo was tut ? (Irgendwas ...Shading in reserverd ....shading in)?  Oder ist damit auch die Abhängigkeit gelöst ? Selbst getestet .... Abhängigkeit gelöst. 1 Event reicht 

Grüße
Andreas

[JWRu]

auch im englischen Teil ist es etwas mißverständlich:

A optional parameter set the maximal object in brightness average array.

Mein Vorschlag:
An optional parameter specifies how many successive brightness reading values should be used to average the brightness value.

[CoolTux]

Du hast Recht.... Ich für meinen teil habs übersehen (besser gesagt nicht beachtet, weil es früher auch nicht drin war) ABER.... ich bin mir sicher, dass 99 % der normalen User 
nicht verstehen werden. Ich hab es einfach übersehen.... Ob ich es dann so hätte zuordnen können ist ne andere sache.

@Marko: Imho wäre in dem Fall besser: Ein optionaler dritter Wert gibt an, wie viele Brightnesswerte für den aktuellen Brightness-Durchschnitt berücksichtigt werden. Standard ist [3] Mögliche Werte sind 3, 2 und 1 (oder auch andere ... ?)

Mich würde allerdings noch meine Frage aus #1639  interessieren: wenn ich Brightness auf "3000:2000 1" geändert habe, muss ich dann trotzdem 3 Brightness Events haben, damit sich am Rollo was tut ? (Irgendwas ...Shading in reserverd ....shading in)?  Oder ist damit auch die Abhängigkeit gelöst ?

Grüße
Andreas

Hallo Andreas,

Nein Du musst dann nicht auf 3 Events warten. Musstest Du so gesehen vorher ja auch nicht. Es kam immer nur drauf an wie hoch die Werte sind.

140 120 100    ergibt im Durchschnitt  120
Wenn Deine Brightnesswert mit 50000 rein kommt und Deine Beschattung bei 15.000 beginnt dann wird dennoch die nächste Stufe geschalten.

100 ist der erste Wert der fliegt raus und oben rein kommt der neue Wert 50.000

50000 140 120    ergibt im Durchschnitt  16.753



Grüße

[flummy1978]

Oh da warst Du schneller, als ich grad meinen Beitrag editiert hab ..... egal hilft anderen ganz sicher

[CoolTux]

Du hast Recht.... Ich für meinen teil habs übersehen (besser gesagt nicht beachtet, weil es früher auch nicht drin war) ABER.... ich bin mir sicher, dass 99 % der normalen User 
nicht verstehen werden. Ich hab es einfach übersehen.... Ob ich es dann so hätte zuordnen können ist ne andere sache.

@Marko: Imho wäre in dem Fall besser: Ein optionaler dritter Wert gibt an, wie viele Brightnesswerte für den aktuellen Brightness-Durchschnitt berücksichtigt werden. Standard ist [3] Mögliche Werte sind 3, 2 und 1 (oder auch andere ... ?)

Edith ergänzt noch Rechtschreibfehler und eine kleine Ergänzung für die Commandref / Doku - was auch immer: (Ergänzungen in Rot)

Damit die Beschattung Funktion hat, müssen folgende Anforderungen erfüllt sein.
Im ASC Device das Reading "controlShading" mit dem Wert on, sowie ein Astro/Twilight Device im Attribut "ASC_twilightDevice" und das Attribut "ASC_tempSensor".
In den Rollladendevices benötigt ihr ein Helligkeitssensor als Attribut "ASC_BrightnessSensor", sofern noch nicht vorhanden. Findet der Sensor nur für die Beschattung Verwendung ist der Wert DEVICENAME[:READING][Ø] ausreichend.
Alle weiteren Attribute sind optional und wenn nicht gesetzt mit Default-Werten belegt. Ihr solltet sie dennoch einmal anschauen und entsprechend Euren Gegebenheiten setzen. Die Werte für die Fensterposition und den Vor- Nachlaufwinkel sowie die Grenzwerte für die StateChange_Cloudy und StateChange_Sunny solltet ihr besondere Beachtung dabei schenken.
Von Standardwerten ist folgende Funktionsweise angestrebt:
1.   Event vom Astro oder Helligkeits Device kommt -> sind alle Werte innerhalb der Arbeitsbereiche, ändert sich der ASC Info-Zustand im Rollo von XX auf ,,in reserved" (Beschattung vorbereitet).
2.   Ein erneutes Event vom Astro oder Helligkeits Device kommt -> Überprüfung der Werte -> sind diese weiterhin gegeben folgt der Wechsel von ,,in reserved" auf ,,in"
3.   Bei Verwendung von DEVICENAME:HELLIGKEITSREADING ist zu beachten, dass ein Durchschnitt über die letzten 3 Events gerechnet wird. Möchte man das vermeiden muss man DEVICENAME:HELLIGKEITSREADING 1 setzen.
4.   Die Zeiten ASC_Shading_WaitingPeriod und ASC_BlockingTime_afterManual können die hier zusätzlich für eine Verzögerung sorgen.

Wichtig zu beachten: Es müssen mehrere Events für den Betrieb erfolgen. In den Standardeinstellungen vom Astro Modul erfolgt dieses z.B. nur 1 x pro Std. Kommt also Euer Helligkeits-Event auch nur 1x pro Stunde, könnte es > 2 Std dauern, bis Eure Beschattung greift.


MIR hätte dieser Text sehr geholfen. Vielleicht tut er es für andere auch und sorgt somit für weniger verwirrte Gesicher, wie bei mir 


Mich würde allerdings noch meine Frage aus #1639  interessieren: wenn ich Brightness auf "3000:2000 1" geändert habe, muss ich dann trotzdem 3 Brightness Events haben, damit sich am Rollo was tut ? (Irgendwas ...Shading in reserverd ....shading in)?  Oder ist damit auch die Abhängigkeit gelöst ? Selbst getestet .... Abhängigkeit gelöst. 1 Event reicht 

Grüße
Andreas

Hallo Andreas,

Was hälst Du davon wenn Du den Beitrag ins Wiki zu ASC schreibst. Zwar werden diese Bedingungen in der kommenden Version geprüft und Warnungen oder Fehler ausgegeben in einem speziellen Reading im Rollo Device aber es hilft auf alle Fälle bei den Vorbereitungen.


Grüße