[ASC] Configuration and Information Summary zeigt "manual" ohne Handeingriff

[Zeitisen]

Hallo,
ich habe seit Sonntag ASC mit vier HmIP-FROLL an Laufen. Sonntag abend sind alle normal zugefahren, heute früh normal auf. Die Anzeige war aber "manual" bei drei Rollos, nur einer auf "day open"
Heute nach schliessen waren drei auf "night close" und einer auf "manual".
Es hat keiner auf eine Taste gedrückt, weil es noch keine Taste gibt.
Was könnte die Ursache sein?

[CoolTux]

Du hast in jedem Rollo ein ASC Attribut ASC_Pos_Reading. Das Reading welches Du da als Wert hinterlegt hast muß mit dem attribut event-on-update-reading event-on-change-reading geschützt werden. Ich gehe davon aus das sich das Reading automatisch updatet. Immer mit dem selben Wert aber durch den Event den ASC auffängt denkt ASC das Rollo wurde manuell gefahren.


Grüße

[Zeitisen]

Das Attribut ASC_Pos_Reading ist pct.
Im Device sind alle Readings event_on_change:

Code Auswählen Erweitern

attr wg_RolloLang_3 event-on-change-reading 3.LEVEL.*,pct.*,stop,open,closed,3.ACTIVITY_STATE.*

Event_on change gibt doch noch weniger Events  als event_on _update?
Oder muss ich das event_on_update auch für das Reading ASC_Pos_Reading explizit setzen?

[Beta-User]

Das erinnert mich deutlich an die Schilderung von marvin78 neulich: https://forum.fhem.de/index.php/topic,123670.msg1183058.html#msg1183058.

Kann es sein, dass HMCCU.* ungewollt Events erzeugt, die es eigentlich nicht geben dürfte?

@Zeitisen:
Zum einen würde ein etwas vollständigeres list tendenziell eventuell noch offene Fragen besser klären lassen und: Hast du ein (File-)Log von dem Rollladen oder kannst mal eines anfertigen, das die pct-Events mitschneidet?

[CoolTux]

Ich habe mich vertan, sorry. Richtig ist wie Du sagst @zeiteisen event-on-change-reading.
Sorry

Wenn Du das gesetzt hast sollte es keine Probleme geben so lange wirklich keine Events erzeugt werden.

[Zeitisen]

Danke für die Hinweise.

Ich habe jetzt nochmal die Events durchgesehen.
Das Problem könnte sein, dass die Events von der CCU3  bis zu 2 Sekunden später als erwartet kommen.
Die Fahrzeit für wg_Rollolang ist in der CCU3 mit 45 Sekunden definiert. Das letzte Event kommt aber erst nach 47 Sekunden.
ASC_DriveUpMaxDuration habe ich aber nur mit 45 + 2 also 47 Sekunden eingetragen. Ich weiß, in der Doku steht +5 Sekunden, aber ich bin geizig.
ich habe jetzt mal bei allen Geräten die Zeit auf +5 Sekunden geändert. Dann sehe ich, ob es heute abend passt.

Shading konnte ich noch nicht testen, bei der irren Strahlung seit Sonntag.
Die Werte dazu müssen wohl auch noch optimiert werden.

Logfile im Anhang.
Hier noch mal das Gerät komplett:

Code Auswählen Erweitern



defmod wg_RolloLang_3 HMCCUDEV 00115D899135D8  sd=3.LEVEL cd=4.LEVEL
attr wg_RolloLang_3 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_beforeDayOpen ASC_BlockingTime_beforeNightClose 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_CommandTemplate 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_BetweenTheTime 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,awning,EG_window ASC_SlatPosCmd_SlatDevice 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
attr wg_RolloLang_3 ASC 2
attr wg_RolloLang_3 ASC_Adv off
attr wg_RolloLang_3 ASC_AutoAstroModeEvening CIVIL
attr wg_RolloLang_3 ASC_AutoAstroModeMorning REAL
attr wg_RolloLang_3 ASC_BrightnessSensor HeizungUVR:1-S09_Solarstrahlung
attr wg_RolloLang_3 ASC_DriveUpMaxDuration 50
attr wg_RolloLang_3 ASC_Pos_Reading pct
attr wg_RolloLang_3 ASC_Shading_InOutAzimuth 135:220
attr wg_RolloLang_3 ASC_Shading_Mode always
attr wg_RolloLang_3 ASC_Shading_StateChange_SunnyCloudy 400:300
attr wg_RolloLang_3 ASC_Shading_WaitingPeriod 300
attr wg_RolloLang_3 ASC_TempSensor wg_TemperaturRegler_Climate:measured-temp
attr wg_RolloLang_3 ccureadingfilter 1,2,3,4..*
attr wg_RolloLang_3 cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
attr wg_RolloLang_3 event-on-change-reading 3.LEVEL.*,pct.*,stop,open,closed,3.ACTIVITY_STATE.*
attr wg_RolloLang_3 group ASC
attr wg_RolloLang_3 room Wintergarten
attr wg_RolloLang_3 substexcl pct
attr wg_RolloLang_3 webCmd pct:open:close:stop
attr wg_RolloLang_3 widgetOverride pct:slider,0,10,100

und ASC:

Code Auswählen Erweitern


defmod wg_RolloControl AutoShuttersControl
attr wg_RolloControl ASC_autoAstroModeEvening CIVIL
attr wg_RolloControl ASC_autoAstroModeMorning REAL
attr wg_RolloControl ASC_autoShuttersControlEvening on
attr wg_RolloControl ASC_autoShuttersControlMorning on
attr wg_RolloControl ASC_blockAscDrivesAfterManual 0
attr wg_RolloControl ASC_expert 1
attr wg_RolloControl ASC_tempSensor HeizungUVR:1-S01_Aussen
attr wg_RolloControl ASC_twilightDevice TW
attr wg_RolloControl devStateIcon { ShuttersControl_DevStateIcon($name) }
attr wg_RolloControl group ASC
attr wg_RolloControl icon fts_shutter_automatic
attr wg_RolloControl room 99_System,Wintergarten
attr wg_RolloControl userReadings azimuth {ReadingsVal("TW","azimuth",0);;;; }, elevation {ReadingsVal("TW","elevation",0);;;; }, temperatur_innen {ReadingsVal("wg_TemperaturRegler_Climate","measured-temp",0);;;;},strahlung {ReadingsVal("HeizungUVR","1-S09_Solarstrahlung",0);;;; }


[Beta-User]

Dann scheint das das Problem gewesen zu sein:

Das Problem könnte sein, dass die Events von der CCU3  bis zu 2 Sekunden später als erwartet kommen.
Die Fahrzeit für wg_Rollolang ist in der CCU3 mit 45 Sekunden definiert. Das letzte Event kommt aber erst nach 47 Sekunden.
ASC_DriveUpMaxDuration habe ich aber nur mit 45 + 2 also 47 Sekunden eingetragen. Ich weiß, in der Doku steht +5 Sekunden, aber ich bin geizig.

Leider fehlt bei den RAW-Definitionen der "setstate"-Teil, sonst könnte man ggf. sehen, wann jeweils die Zeitstempel aktualisiert worden sind, ist aber hier nicht mehr wichtig.

Die userReadings beim ASC-Device sehen "verbesserungsfähig" aus (kein trigger gesetzt), mal ganz ab davon, dass ich nicht nachvollziehen kann, warum man die Werte überhaupt "importiert" und nicht einfach das Ausgangsgerät mit-loggt.

[Zeitisen]

Wenn du das Erstellen eines Userreadings als "importieren" bezeichnest,

Verbesserungsvorschlag:
Wenn ich ein device als trigger setze, sollte es sofort als Reading eingetragen werden, damit ich auf einen Blick an einem Ort sehe, wie der Stand ist, ohne dass ich erst in vielen anderen devices nachsehe.

Beispiel:
Wenn ich definiere:

Code Auswählen Erweitern

ASC_TempSensor wg_TemperaturRegler_Climate:measured-temp

dann sollte es automatisch das Reading geben "tempSensor". Damit kann ich mir dann userreadings sparen

Userreadings erstellen sind nicht meine Stärke. Dazu mache ich es zu selten. Wenn man nur alle paar Monate was neu macht, erreicht man keine großartigen Fertigkeiten.

[Beta-User]

Wenn du das Erstellen eines Userreadings als "importieren" bezeichnest,

Ja, das war gemeint.

Verbesserungsvorschlag:
Wenn ich ein device als trigger setze, sollte es sofort als Reading eingetragen werden, damit ich auf einen Blick an einem Ort sehe, wie der Stand ist, ohne dass ich erst in vielen anderen devices nachsehe.

Beispiel:
Wenn ich definiere:

Code Auswählen Erweitern

ASC_TempSensor wg_TemperaturRegler_Climate:measured-temp

dann sollte es automatisch das Reading geben "tempSensor". Damit kann ich mir dann userreadings sparen

Userreadings erstellen sind nicht meine Stärke. Dazu mache ich es zu selten. Wenn man nur alle paar Monate was neu macht, erreicht man keine großartigen Fertigkeiten.

Das Problem mit dem userReadings in der vorhandenen Form ist: Es werden immer alle Werte "importiert", sobald irgendein Event am "Stammdevice" zu vermelden ist. Das erhöht den Overhead bei jeder Event-Loop des ASC-Devices => (hochgradig) ineffizient...

Und es macht m.E. auch keinen Sinn, Werte (triggernd) zu importieren, wenn sie sich irgendwo anders ändern. Evtl. könnte es sinnvoll sein, über readingsGroup eine Übersicht zu gestalten. Das begrenzt nämlich den Overhead auf die Fälle, in denen die readingsGroup angezeigt wird, sonst ist sie inaktiv.

Ob es aus CoolTux Sicht sinnvoll ist, im ASC-Device irgendwas anzuzeigen, muss er entscheiden, ich würde das als Modulautor rundweg ablehnen, da man entweder trigger generieren muss, um longpoll zu ermöglichen (automatische Aktualisierung), oder sich im Vorgriff schon vor dem geistigen Auge den Vorwürfen der User ausgesetzt sieht, warum man es abschaltet - über den Aufwand, das zu implemetieren, haben wir da noch gar nicht geredet.
Dazu kommt, dass man viele Sensoren etc. an der Zentralinstanz als "fallback-Lösung" haben kann, aber dann andere am jeweiligen Shutter => so oder so nur eine Erstinfo.

@CoolTux
Was eventuell (auf längere Sicht!) sinnvoll sein könnte: Es gibt ja diverse ascAPIget()-Befehle, mit denen sich einzeln alles mögliche Abfragen läßt. Vielleicht wäre es möglich, die jeweils aktuellen Einstellungen/Werte/defaults (pro Shutter) zu einer einheitlichen Darstellung zusammenzuführen? So ähnlich, wie das bei MQTT_GENERIC_BRIDGE über "get ... devinfo" möglich ist? Hab's nicht im Detail angeschaut, und meine, Teile davon auch schon mal in "readingsGroup-Form" gesehen zu haben, aber sowas sollte eigentlich mit überschaubarem Aufwand möglich sein...

[Zeitisen]

Danke für die Erläuterung der Hintergründe. So tief stecke ich da nicht drin.

Natürlich wäre eine readingsGroup eine Alternative, vor allem wenn sie weniger Ressourcen braucht.
Aber die muss man eben immer von Hand zusammenstricken.
Zum Testen ist es immer einfacher, wenn man alle Parameter im Blick hat. Wenn es mal läuft, kann man vieles weglassen.
Der Test des Shading steht noch bevor.

Das Problem mit manual ist behoben.

Das Modul ist eine super Sache. 2017 habe  ich die Zeitsteuerung für meine Fensterläden selber gestrickt. Da hätte ich das schon brauchen können.