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

[BigGB]

Es gab einen manuellen Event vom besagten Rollo. Warst Du das?
Setz mal event-on-change-reading auf pct und was Du sonst noch an Event brauchst.

Ja, das war ich. Dieses Event wird die Rolllade doch auch von heute morgen haben, wo meine Frau den Rollladen hochgefahren hat.
Event-on-change-reading habe ich jetzt auf "pct" gesetzt.

Bei den anderen Rollladen ist das Attribut nur zum Teil drin, es werden aber alle zum Herunterfahren motiviert.

Code Auswählen Erweitern

2019.11.20 17:00:02.120 3: CUL_HM set Rolllade.Bad.OG pct 0
2019.11.20 17:00:02.265 5: KLF200Node (Rolllade.DG.Strasse) - set 0
2019.11.20 17:00:02.269 5: KLF200Node (Rolllade.DG.Strasse) KLF200Node_GW_COMMAND_SEND_REQ SessionID 3670 ParameterActive 0 FP0:51200
2019.11.20 17:00:02.317 3: CUL_HM set Rolllade.KU.EG pct 0
2019.11.20 17:00:02.377 3: CUL_HM set Rolllade.KZ.OG pct 0
2019.11.20 17:00:02.445 3: CUL_HM set Rolllade.SZ pct 0
2019.11.20 17:00:02.487 3: CUL_HM set Rolllade.WC.EG pct 0
2019.11.20 17:00:02.529 3: CUL_HM set Rolllade.WZ.Garten pct 0
2019.11.20 17:00:02.571 3: CUL_HM set Rolllade.WZ.Strasse pct 0
2019.11.20 17:00:02.612 3: CUL_HM set Rolllade.WZ.Terrasse pct 0
2019.11.20 17:00:04.844 5: KLF200Node (Rolllade.DG.Strasse) GW_NODE_STATE_POSITION_CHANGED_NTF 0211 2 2 MP:0 T:51200 FP1:63487 0 1661272064
2019.11.20 17:00:04.844 5: KLF200Node (Rolllade.DG.Strasse) BulkUpdateMain MP:0 T:51200 R:0 'Not used'
2019.11.20 17:00:04.876 5: KLF200Node (Rolllade.DG.Strasse) GW_COMMAND_RUN_STATUS_NTF 0302 3670 8 2 FP0:0 2 1 06000400
2019.11.20 17:00:06.738 5: KLF200Node (Rolllade.DG.Strasse) GW_COMMAND_REMAINING_TIME_NTF 0303 3670 2 FP0 = 47
2019.11.20 17:00:06.747 5: KLF200Node (Rolllade.DG.Strasse) GW_NODE_STATE_POSITION_CHANGED_NTF 0211 2 4 MP:0 T:51200 FP1:63487 47 1661403136
2019.11.20 17:00:06.748 5: KLF200Node (Rolllade.DG.Strasse) BulkUpdateMain MP:0 T:51200 R:47 Executing
2019.11.20 17:00:57.297 5: KLF200Node (Rolllade.DG.Strasse) GW_COMMAND_RUN_STATUS_NTF 0302 3670 8 2 FP0:51200 0 1 20000500
2019.11.20 17:00:57.310 5: KLF200Node (Rolllade.DG.Strasse) GW_NODE_STATE_POSITION_CHANGED_NTF 0211 2 5 MP:51200 T:51200 FP1:63487 0 1664679936
2019.11.20 17:00:57.311 5: KLF200Node (Rolllade.DG.Strasse) BulkUpdateMain MP:51200 T:51200 R:0 Done
2019.11.20 17:00:57.311 5: KLF200Node (Rolllade.DG.Strasse) GW_NODE_STATE_POSITION_CHANGED_NTF updateStatus NO

Wir werden morgen früh sehen, was passiert.
Vielen Dank erstmal Gerald.

[CoolTux]

Wenn event-on-change-reading nicht gesetzt ist und das Device alle x Stunden/Minuten ein alive bekommt werden alle Readings geschrieben und pct sendet ein Event deswegen. ASC erkennt es und wertet es als manuelle Fahrt obwohl nicht gefahren wurde und dann greift die manualBlockingTime von einer Stunde und schon wird nicht gefahren.

[Beta-User]

Ein Gedanke zu den Themen "unterschiedliche Level für verschiedene Aktionen" und "updates vom Gerät her (ohne Änderung)":

Wäre es nicht besser, die letzte ASC-Aktion und den zugehörigen Level intern zu speichern und dagegen zu vergleichen?
Also in's Unreine: Entspricht der aktuelle Stand der letzten ASC-Aktion? => dann ist die Annahme naheliegend, dass das von ASC kam, unabhängig von updates. Etwas anderes gilt nur, wenn zwischendurch eine andere Position angefahren wurde (=> Wert löschen?). Ist der neue Ziellevel wegen einer anderen Aktion derselbe, dann ändert man im Hash einfach das auslösende Event...
Dadurch kann man evtl. auch das (vermutete) Problem umgehen, dass per Perl-Code ermittelte Ziellevel sich ändern, aber (noch) nicht nachgefahren werden, man weiß dann, was das frühere Ergebnis war.

Kann sein, dass das noch nicht ausgegoren ist, aber m.E. ist das mit "event-on" ein Dauerbrenner und wird es bleiben, und das mit den unterschiedlichen Zielleveln empfand ich beim Lesen immer als irgendwie künstlich; geht vermutlich anderen auch so...

[FunkOdyssey]

@Beta-User: wir haben in letzter Zeit viele Parallelen. 
Auch wenn man es mir jetzt nicht mehr glaubt, so hatte ich ähnliche Gedanken.
Ich vermute, dass ich dabei aber irgendetwas übersehe, denn sonst hätte CoolTux Lösungen dieser Art doch sicherlich schon umgesetzt. Ich bin mal gespannt.

Das würde viele viele Probleme lösen.

[Borkk]

Hallo CoolTux,

ich war länger nicht mehr hier im Forum und hab eben das Update auf 0.8.2 gemacht. Das lief soweit glatt durch. Schön das du die Azimuth Einstellung für die Beschattung geändert hast, das hatte ich ja schon mal ganz am Anfang angesprochen. So ist es super. Ich habe nur mal eine Verständnisfrage.

Beim Update wurde (exemplarisch) die alte Einstellung Angel_left= 75 ; Direction=345; Angel_right=65 in 270:410 geändert. Da es ja keine 410° gibt, muss man den Wert dann wohl auf 050° ändern.

[CoolTux]

Hallo CoolTux,

ich war länger nicht mehr hier im Forum und hab eben das Update auf 0.8.2 gemacht. Das lief soweit glatt durch. Schön das du die Azimuth Einstellung für die Beschattung geändert hast, das hatte ich ja schon mal ganz am Anfang angesprochen. So ist es super. Ich habe nur mal eine Verständnisfrage.

Beim Update wurde (exemplarisch) die alte Einstellung Angel_left= 75 ; Direction=345; Angel_right=65 in 270:410 geändert. Da es ja keine 410° gibt, muss man den Wert dann wohl auf 050° ändern.

Das ergibt dann irgendwie kein Sinn würde ich sagen. Dann müsstest Du bitte einmal das ganze korrigieren. Ruhig auch mal mit einem Kompass schauen wenn Du Dir unsicher bist.

[CoolTux]

Ein Gedanke zu den Themen "unterschiedliche Level für verschiedene Aktionen" und "updates vom Gerät her (ohne Änderung)":

Wäre es nicht besser, die letzte ASC-Aktion und den zugehörigen Level intern zu speichern und dagegen zu vergleichen?
Also in's Unreine: Entspricht der aktuelle Stand der letzten ASC-Aktion? => dann ist die Annahme naheliegend, dass das von ASC kam, unabhängig von updates. Etwas anderes gilt nur, wenn zwischendurch eine andere Position angefahren wurde (=> Wert löschen?). Ist der neue Ziellevel wegen einer anderen Aktion derselbe, dann ändert man im Hash einfach das auslösende Event...
Dadurch kann man evtl. auch das (vermutete) Problem umgehen, dass per Perl-Code ermittelte Ziellevel sich ändern, aber (noch) nicht nachgefahren werden, man weiß dann, was das frühere Ergebnis war.

Kann sein, dass das noch nicht ausgegoren ist, aber m.E. ist das mit "event-on" ein Dauerbrenner und wird es bleiben, und das mit den unterschiedlichen Zielleveln empfand ich beim Lesen immer als irgendwie künstlich; geht vermutlich anderen auch so...

Ich versuche etwas einfach um zu setzen.

[Beta-User]

Ich versuche etwas einfach um zu setzen.

? Was auch immer das heißt.

In jedem Fall: Danke für die Arbeit bis daher, das ist eine Riesenleistung, und wie an anderer Stelle schon sinngemäß zu dem hier

Ich vermute, dass ich dabei aber irgendetwas übersehe, denn sonst hätte CoolTux Lösungen dieser Art doch sicherlich schon umgesetzt.

sinngemäß angemerkt:
Hinerher ist man manchmal schlauer, und oft genug lernt man gerade bei solchen Projekten auch recht viel dazu (und übersieht erst mal einiges...). Geht mir jedenfalls so...

(Ist mir auch klar, dass das vermutlich mit nicht ganz kleinen Eingriffen in den Code verbunden ist und ich muß auch zugeben, dass ich dazu nicht vorher reingeschaut habe, um einen Eindruck zu bekommen, wie viel das ist.)

Was "event-on" angeht, bin ich mir btw. nicht mehr sicher, ob es "gut" ist, das auf Ebene des Moduls zu lösen: Zu viele unnötige Events sind an sich ein Problem, das man an der Wurzel lösen sollte, und je eher ein User das merkt, desto besser (nicht nur für ASC). Da sich das rumspricht (und vermutlich auch in der Doku steht), ist es evtl. tatsächlich KEINE gute Idee.
Diese Teilrückname betrifft aber ausdrücklich nur den "event-on"-Teil...

[CoolTux]

? Was auch immer das heißt.

In jedem Fall: Danke für die Arbeit bis daher, das ist eine Riesenleistung, und wie an anderer Stelle schon sinngemäß zu dem hier sinngemäß angemerkt:
Hinerher ist man manchmal schlauer, und oft genug lernt man gerade bei solchen Projekten auch recht viel dazu (und übersieht erst mal einiges...). Geht mir jedenfalls so...

(Ist mir auch klar, dass das vermutlich mit nicht ganz kleinen Eingriffen in den Code verbunden ist und ich muß auch zugeben, dass ich dazu nicht vorher reingeschaut habe, um einen Eindruck zu bekommen, wie viel das ist.)

Was "event-on" angeht, bin ich mir btw. nicht mehr sicher, ob es "gut" ist, das auf Ebene des Moduls zu lösen: Zu viele unnötige Events sind an sich ein Problem, das man an der Wurzel lösen sollte, und je eher ein User das merkt, desto besser (nicht nur für ASC). Da sich das rumspricht (und vermutlich auch in der Doku steht), ist es evtl. tatsächlich KEINE gute Idee.
Diese Teilrückname betrifft aber ausdrücklich nur den "event-on"-Teil...

Das Problem im allgemeinen beim Code schreiben ist ja das man das meiste erstmal auf seine Anforderungen aus legt. Und so kommen erst nach und nach die Anforderungen der anderen und deren "Umgebungsprobleme" dazu. Ich habe zum Beispiel nicht das Problem das sich mein Rollodevice ohne eine Fahrt aktualisiert.
Manche Dinge lassen sich sehr sehr einfach lösen da der Code unglaublich flexibel ist. Hatten wir erst letztens wo man sich gewundert hat das ein Problem durch ein einziges Wort gelöst werden konnte.

Ich werde mir die Tage mal Gedanken machen 

[Borkk]

Das ergibt dann irgendwie kein Sinn würde ich sagen. Dann müsstest Du bitte einmal das ganze korrigieren. Ruhig auch mal mit einem Kompass schauen wenn Du Dir unsicher bist.

Hmm, da hast du natürlich recht und in der alten Logik habe ich da gar nicht drüber nachgedacht. Natürlich geht die Sonne an meinem Wohnort im Sommer spätestens bei ca 310° unter. 

Hier kann man übrigens sehr schön seine ganz persönlichen Werte für die Beschattung über eine Simulation ermitteln: sonnenverlauf.de .

[eckibrecki]

Ich würde mal behaupten das FTUI eher zur Visualisierung und zum steuern gedacht ist und weniger zur Konfiguration von Geräten.

Naja, die Möglichkeit der Konfiguration würde in meinem Falle den WAF deutlich erhöhen ; auch wenn es nur ein-/zweimal im Jahr genutzt werden würde 
Bei manchen Dingen könnte ich mir schon vorstellen, dass ich sie das ein oder andere Mal noch anpassen würde. Bspw. Beschattung im Herbst bei einzelnen Rollladen ausschalten oder den Stand anpassen, um die Sonnenenergie ins Haus zu lassen, oder die Schaltung morgens oder abends für ein paar Tage deaktivieren.

... Naja, kann man sich drüber streiten ob man sowas wirklich braucht. Hätte ja sein können, dass es eine "einfache" Möglichkeit gibt. Werde evtl. mal einen eigenen Thread aufmachen. Vielleicht hat sich ja schon jemand damit beschäftigt.
Aber auf jeden Fall Danke für das Modul und die Zeit, die Du in die Weiterentwicklung investierst!

Grüße
Carsten

[BigGB]

Wenn event-on-change-reading nicht gesetzt ist und das Device alle x Stunden/Minuten ein alive bekommt werden alle Readings geschrieben und pct sendet ein Event deswegen. ASC erkennt es und wertet es als manuelle Fahrt obwohl nicht gefahren wurde und dann greift die manualBlockingTime von einer Stunde und schon wird nicht gefahren.

Hallo CoolTux,
die Änderung auf event-on-change-reading hat bei diesem Rollo "Rolllade.AZ" nichts gebracht. Situation wie gestern, Rollo muss manuell geöffnet bzw. geschlossen werden.
Andere Rollos hatten z.T. Attribut even-on-change-reading eingestellt, andere nicht. Aber alle sind zu- bzw- aufgefahren.
Hast Du noch eine Tip.
Danke u. viele Grüße Gerald.

[kilderman]

Hallo CoolTux,

zuerst einmal vielen Dank für deine viele Arbeit mit dem Modul. Ich bin gerade am Ausprobieren desselben. Aktuell habe ich aber ein paar Fragen, die sich mir noch nicht ganz erschließen. Vielleicht kann ich die hier einmal stellen:

1. Ich habe dein Modul vor ein paar Tagen einmal für ein Dachfenster eingerichtet. Dort auf der Couch übernachten eigentlich nur Gäste und niemand aus der Familie. Daher habe ich versucht, dass Rollo so einzurichten, dass es nur nachts runterfährt, wenn Gäste zum Übernachten anwesend sind. Andernfalls soll es oben bleiben. Das funktioniert soweit eigentlich auch, aber nur, bis ein Familienmitglied wieder auf die Idee kommt, nach der Sonnenuntergangszeit noch einmal zu lüften. Wenn dann das Fenster wieder geschlossen wird, fährt auch das Rollo herunter, egal ob Gast anwesend oder nicht. Kann man dies ggf. verhindern? Mein List des Rollos sieht so aus:

Code Auswählen Erweitern


Internals:
   CHANGED   
   FUUID      5c472185-512f-3364-fa6c-5b7399563217906e
   NAME       OGGastSued
   NR         451
   STATE      open
   TYPE       ROLLO
   stoptime   1574369525
   OLDREADINGS:
   READINGS:
     2019-09-28 15:56:17   ASC_Enable      on
     2019-11-21 21:52:05   ASC_ShuttersLastDrive manual
     2019-11-21 16:47:39   ASC_Time_DriveDown 22.11.2019 - 16:47
     2019-11-21 16:47:39   ASC_Time_DriveUp 22.11.2019 - 06:45
     2019-11-17 18:17:51   associatedWith  ASC
     2019-11-21 21:51:57   command         open
     2019-11-21 21:51:57   desired_pct     0
     2019-11-21 21:51:57   drive-type      modul
     2019-11-21 21:51:57   last_drive      drive-up
     2019-11-21 21:52:05   pct             0
     2019-11-21 21:52:05   state           open
Attributes:
   ASC        1
   ASC_Antifreeze hard
   ASC_BlockingTime_afterManual 3600
   ASC_BlockingTime_beforDayOpen 7200
   ASC_BlockingTime_beforNightClose 3600
   ASC_BrightnessSensor ZW_01628321:brightness 600:1000
   ASC_Closed_Pos 100
   ASC_ComfortOpen_Pos 10
   ASC_Down   astro
   ASC_Drive_Delay 700
   ASC_Drive_DelayStart 1
   ASC_LockOut off
   ASC_Mode_Down home
   ASC_Mode_Up always
   ASC_Open_Pos 0
   ASC_Pos_Reading pct
   ASC_Roommate_Device rg_GuestOvernight
   ASC_Roommate_Reading presence
   ASC_Shading_InOutAzimuth 140:270
   ASC_Shading_MinMax_Elevation 25.0:100.0
   ASC_Shading_Min_OutsideTemperature 20
   ASC_Shading_Mode always
   ASC_Shading_Pos 99
   ASC_Shading_StateChange_SunnyCloudy 15000:8000
   ASC_Shading_WaitingPeriod 3600
   ASC_ShuttersPlace window
   ASC_TempSensor Proplanta:temperature
   ASC_Time_Down_Early 16:00
   ASC_Time_Down_Late 22:00
   ASC_Time_Up_Early 06:45
   ASC_Time_Up_Late 08:30
   ASC_Up     time
   ASC_WindowRec du_OGGastSued
   ASC_WindowRec_PosAfterDayClosed open
   ASC_WindowRec_subType twostate
   DbLogExclude .*
   automatic-enabled on
   cmdIcon    open:fts_shutter_up closed:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   devStateIcon open:fts_window_2w: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 desired_pct,pct
   group      Rollo
   rl_autoStop 0
   rl_commandDown set FSR14_02_A on
   rl_commandStopDown set FSR14_02_A off
   rl_commandStopUp set FSR14_02_B off
   rl_commandUp set FSR14_02_B on
   rl_excessBottom 2
   rl_excessTop 4
   rl_resetTime 0
   rl_secondsDown 111
   rl_secondsUp 111
   rl_switchTime 1
   rl_type    normal
   room       OGGast
   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    0
   webCmd     :


Im ASC-Modul habe ich 'ASC_autoShuttersControlComfort' 'off' eingestellt, falls das noch von Interesse ist. Es fährt leider trotzdem. Könnte man das abstellen?

2. Als Attribut lässt sich auch 'ASC_GuestRoom' auswählen. Jedoch habe ich leider noch keine Informationen zu diesem Attribut gefunden, weder in der Commandref, noch im Wiki oder hier im Forum. Für was ist dieses Attribut gedacht (gewesen)?

3. Neu ist anscheinend jetzt das Attribut 'ASC_Shutter_IdleDetection' hinzugekommen. Gem. Commandref soll Reading:Value für's Nichtfahren dort eingetragen sein. Beim Rollo-Modul dürfte dann eigentlich nicht 'drive.*' drinstehen. Ist es möglich, sowas wie !~"drive" oder ähnliches direkt dort einzutragen? Andernfalls würde ich das über ein separates Reading lösen.

4. Ich finde es gut, dass es nun möglich ist, einige Werte über Perl-Code mitzugeben. Für unser eigentliches Gästezimmer, dass nicht unterm Dach, dafr ein bisschen einsehbarer ist, würde ich gerne auch für 'ASC_Closed_Pos' etwas wie {Value('rg_GuestOvernight') eq "home" ? 100 : 50} nutzen. Dies ist aber bisher wohl (noch) nicht möglich. Ist eine solche Möglich vielleicht angedacht? Oder wie könnte ich das sonst ggf. umsetzen?

Herzlichen Dank noch einmal für die viele Arbeit und viele Grüße
Marco

[stefanpf]

Bei der Perl Code Unterstützung würde ich auch gerne einen Wunsch äußern:
Ich könnte das gut bei ASC_PrivacyUpValue_beforeDayOpen
gebrauchen.
Szenario:
z.B. im Bad öffnet der Rolladen nach Sonnenstand.
An Werktagen würde ich dann gerne den Privacy Modus fix zur "Duschzeit" anfahren.

[Karflyer]

Hallo CoolTux,

nach dem Update fahren einige Rollläden verspätet nach oben. Bei dem Befehl 'showShuttersInformations' im ASC-Device werden die betroffenen Rollläden nicht mit ihrem Devicename angezeigt sondern mit 'SOMFY'. Auch steht für ASC UP 'astro' in der Ausggabe obwohl 'time' am entsprechenden Rollladendevice eingetragen ist (siehe Screenshot im Anhang).
Nach der Ausführung des Befehls 'renewAllTimer' im ASC-Device erhalte ich die folgenden Fehlermeldungen im Log:

Code Auswählen Erweitern

2019.11.22 07:40:53 1: ERROR: empty name in readingsBeginUpdate
2019.11.22 07:40:53 1: stacktrace:
2019.11.22 07:40:53 1:     main::readingsBeginUpdate           called by ./FHEM/73_AutoShuttersControl.pm (2716)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (2826)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::RenewSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (587)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::Set      called by fhem.pl (3749)
2019.11.22 07:40:53 1:     main::CallFn                        called by fhem.pl (1896)
2019.11.22 07:40:53 1:     main::DoSet                         called by fhem.pl (1928)
2019.11.22 07:40:53 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2019.11.22 07:40:53 1:     main::CommandCmdAlias               called by fhem.pl (1242)
2019.11.22 07:40:53 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2685)
2019.11.22 07:40:53 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (956)
2019.11.22 07:40:53 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (582)
2019.11.22 07:40:53 1:     main::FW_Read                       called by fhem.pl (3754)
2019.11.22 07:40:53 1:     main::CallFn                        called by fhem.pl (754)
2019.11.22 07:40:53 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 4772.
2019.11.22 07:40:53 1: readingsUpdate(,ASC_Time_DriveDown,22.11.2019 - 17:14) missed to call readingsBeginUpdate first.
2019.11.22 07:40:53 1: stacktrace:
2019.11.22 07:40:53 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (2717)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (2826)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::RenewSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (587)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::Set      called by fhem.pl (3749)
2019.11.22 07:40:53 1:     main::CallFn                        called by fhem.pl (1896)
2019.11.22 07:40:53 1:     main::DoSet                         called by fhem.pl (1928)
2019.11.22 07:40:53 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2019.11.22 07:40:53 1:     main::CommandCmdAlias               called by fhem.pl (1242)
2019.11.22 07:40:53 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2685)
2019.11.22 07:40:53 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (956)
2019.11.22 07:40:53 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (582)
2019.11.22 07:40:53 1:     main::FW_Read                       called by fhem.pl (3754)
2019.11.22 07:40:53 1:     main::CallFn                        called by fhem.pl (754)
2019.11.22 07:40:53 1: readingsUpdate(,ASC_Time_DriveUp,22.11.2019 - 07:51) missed to call readingsBeginUpdate first.
2019.11.22 07:40:53 1: stacktrace:
2019.11.22 07:40:53 1:     main::readingsBulkUpdate            called by ./FHEM/73_AutoShuttersControl.pm (2731)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::CreateSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (2826)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::RenewSunRiseSetShuttersTimer called by ./FHEM/73_AutoShuttersControl.pm (587)
2019.11.22 07:40:53 1:     FHEM::AutoShuttersControl::Set      called by fhem.pl (3749)
2019.11.22 07:40:53 1:     main::CallFn                        called by fhem.pl (1896)
2019.11.22 07:40:53 1:     main::DoSet                         called by fhem.pl (1928)
2019.11.22 07:40:53 1:     main::CommandSet                    called by ./FHEM/98_cmdalias.pm (99)
2019.11.22 07:40:53 1:     main::CommandCmdAlias               called by fhem.pl (1242)
2019.11.22 07:40:53 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2685)
2019.11.22 07:40:53 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (956)
2019.11.22 07:40:53 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (582)
2019.11.22 07:40:53 1:     main::FW_Read                       called by fhem.pl (3754)
2019.11.22 07:40:53 1:     main::CallFn                        called by fhem.pl (754)
2019.11.22 07:40:53 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4525.

Diese Fehlermeldungen wiederholen sich für die Anzahl der Rolläden die mit 'SOMFY' in 'showShuttersInformation' tituliert sind.
Ein erneutes 'scanForShutters' und 'createNewNotifyDef' blieb erfolglos. Hast du eine Idee, woran es liegen könnte?

Gruß
Stefan