[gelöst] AutoShuttersControl, Entschattung klappt nicht

Begonnen von yep_DD, 06 Juli 2022, 11:53:35

Vorheriges Thema - Nächstes Thema

yep_DD

Hallo zusammen,

ich habe das Problem, dass meine Entschattung nicht funktioniert. Beschattung und Astrofahrten klappen einwandfrei, nur die Entschattung nicht. Der Status steht auf "out reserved", dann "out", aber sie fahren nicht hoch. Sicher habe ich etwas falsch konfiguriert. Was vielleicht noch wichtig wäre: last_drive steht immer auf "manuell" auch wenn ASC die Rollos gefahren hat. Vielleicht kann mir jemand helfen.

Vielen lieben Dank schon mal und vor allem auch für das tolle Modul. Wirklich klasse.

Hier meine Attribut (und im Anhang die Übersicht von ASC)

ASC Device:

attr Rollosteuerung ASC_autoAstroModeEvening HORIZON
attr Rollosteuerung ASC_autoAstroModeEveningHorizon -3
attr Rollosteuerung ASC_autoAstroModeMorning HORIZON
attr Rollosteuerung ASC_autoAstroModeMorningHorizon 6
attr Rollosteuerung ASC_autoShuttersControlEvening on
attr Rollosteuerung ASC_autoShuttersControlMorning on
attr Rollosteuerung ASC_blockAscDrivesAfterManual 0
attr Rollosteuerung ASC_expert 1
attr Rollosteuerung ASC_tempSensor HM_Wetterstation:1.ACTUAL_TEMPERATURE
attr Rollosteuerung ASC_twilightDevice AstroModul
attr Rollosteuerung devStateIcon { ShuttersControl_DevStateIcon($name) }
attr Rollosteuerung icon fts_shutter_automatic
attr Rollosteuerung room ASC


Ein Rollo beispielhaft:

defmod HM_Rollo_Kueche HMCCUDEV "Rollo_Kueche_00111D89B40631"
attr HM_Rollo_Kueche 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 HM_Rollo_Kueche ASC 2
attr HM_Rollo_Kueche ASC_BrightnessSensor HM_Wetterstation:1.ILLUMINATION
attr HM_Rollo_Kueche ASC_DriveUpMaxDuration 21
attr HM_Rollo_Kueche ASC_Pos_Reading pct
attr HM_Rollo_Kueche ASC_Shading_InOutAzimuth 90:150
attr HM_Rollo_Kueche ASC_Shading_Min_OutsideTemperature 20
attr HM_Rollo_Kueche ASC_Shading_Mode always
attr HM_Rollo_Kueche ASC_Shading_Pos 20
attr HM_Rollo_Kueche ASC_Shading_StateChange_SunnyCloudy 6800:5500
attr HM_Rollo_Kueche ASC_TempSensor HM_Wetterstation:1.ACTUAL_TEMPERATURE
attr HM_Rollo_Kueche ccureadingfilter (^STATE$|^LEVEL$)
attr HM_Rollo_Kueche ccureadingformat datapoint
attr HM_Rollo_Kueche cmdIcon open:fts_shutter_up stop:fts_shutter_manual close:fts_shutter_down
attr HM_Rollo_Kueche room Kueche,Homematic
attr HM_Rollo_Kueche substexcl pct
attr HM_Rollo_Kueche webCmd pct:open:close:stop
attr HM_Rollo_Kueche widgetOverride pct:slider,0,10,100

Beta-User

Zitat von: yep_DD am 06 Juli 2022, 11:53:35
Was vielleicht noch wichtig wäre: last_drive steht immer auf "manuell" auch wenn ASC die Rollos gefahren hat.
Dann solltest du mAn. das Attribut "event-on-change-reading" so einstellen, dass das nicht ohne Not "manuell" wird...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

yep_DD

Danke dir für deine Antwort,ich habe jetzt das event-on-update reading bei den Rollos auf .* gesetzt. Das habe ich wohl auch schon mehrmals gelesen. Kannst du vielleicht noch mal sagen, was du mit "ohne Not" meinst?
Grüße

Beta-User

Zitat von: yep_DD am 06 Juli 2022, 12:41:07
Kannst du vielleicht noch mal sagen, was du mit "ohne Not" meinst?
Ohne, dass tatsächlich ein Bewohner an einem Schalter gedreht hat... Dafür ist die Auswertung nämlich da, ob manuell gefahren wurde ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

yep_DD

Wofür die Auswertung da ist, ist mir bewusst. Aber ich verstehe den Zusammenhang nicht, dass da immer "manuell" da steht und welches reading das verursacht. Wird das auf manuell gestellt wenn "pct" geupdated wird? Und deswegen das event-on-update reading anzupassen ist? Außerdem weiß ich ja noch nicht, ob das last_drive manuell überhaupt das Problem verursacht.

Beta-User

Zitat von: yep_DD am 06 Juli 2022, 13:30:44
Wird das auf manuell gestellt wenn "pct" geupdated wird?
Jein. Wenn die Aktualisierung erfolgt, nachdem die "maximale Fahrzeit" abgelaufen ist.

Zitat
Und deswegen das event-on-update reading anzupassen ist?
Genau. Und genau deswegen ist es im Zusammenhang mit ASC wichtig, unnötige (triggernde) updates des Readings zu verhindern. Deswegen findet man das auch "überall" im Zusammenhang mit ASC...

Zitat
Außerdem weiß ich ja noch nicht, ob das last_drive manuell überhaupt das Problem verursacht.
Wir werden sehen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

yep_DD

Ah okay, das heißt, das Rollo fährt runter. PCT wird geupdated und bringt ASC durcheinander. Ich frage mich nur, wie ich das verhindern kann. Erkennt ASC ob PCT auch verändert wurde? Denn wenn die Position gleich ist, dann war es ja kein wirklich manuelles Verfahren des Rollos.

Das heißt, ein "event-on-change" müsste ja dann fast reichen, wenn das die Ursache ist, oder?

Beta-User

Zitat von: yep_DD am 06 Juli 2022, 13:42:41
Das heißt, ein "event-on-change" müsste ja dann fast reichen, wenn das die Ursache ist, oder?
Zitat von: Beta-User am 06 Juli 2022, 13:35:26
Wir werden sehen...

Trotzdem ggf. nochmal etwas Hintergrundinfo:
ZitatAh okay, das heißt, das Rollo fährt runter. PCT wird geupdated und bringt ASC durcheinander. Ich frage mich nur, wie ich das verhindern kann. Erkennt ASC ob PCT auch verändert wurde? Denn wenn die Position gleich ist, dann war es ja kein wirklich manuelles Verfahren des Rollos.
Der triggernde update von pct "bringt ASC" nur dann "durcheinander", wenn es "unerwartet" erfolgt (bzw. ggf. kann es später zu Irritationen kommen, wenn der aktuelle Stand nicht dem erwarteten Stand entspricht). ASC wartet jedenfalls im Hintergrund auf Events, um feststellen zu können, ob ein Eingriff seitens eines Users erfolgt ist. Wenn ja, werden automatische Fahrten unterbunden. Die "blocking"-Zeit auf 0 zu stellen, ist daher m.E. für eine "gute Akzeptanz" bei den Mitbewohnern in der Regel kontraproduktiv, die richtige Stellschraube haben wir ja jetzt hoffentlich identifiziert ;) .

Ergänzend: Zum Zeitpunkt eines Events hält FHEM den alten Wert nicht vor, und ASC kennt auch "nur" den alten "Soll"-Wert.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

yep_DD

Also das event-on-update reading auf on-change-reading zu setzen hat definitiv funktioniert. Für alle die das gleiche Problem haben: Ich habe verwende Homematic-IP BROLL Aktoren. Diese senden periodisch, auch ohne Benutzung, ein Status Update. Das bringt dann ASC durcheinander. Jetzt funktioniert alles wie es soll.

Vielen Dank

Beta-User

 :)

Markierst du den Thread dann bitte als [gelöst] oä? (Dann braucht CoolTux den nicht noch ansehen...).

PS: In https://forum.fhem.de/index.php/topic,101182.0.html (Thread zu "getesteter Hardware") wärst du vermutlich auch fündig geworden, da gibt es auch noch ein paar weitere "Tricks" für spezielle Fragen (auch zu HM-IP-Geräten).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors