Hallo zusammen,
wer wie ich versucht die Beschattung im AutoShutterControl (ASC)-Moduls richt einzustellen und ggf. wie ich noch Anfänger bei FHEM ist, kann ggf. folgende extra Reading Definitionen für die richtige Einstellung der Shading-Funktion im jeweiligen Rolladen nutzen, deshalb als CodeShnippsel anbei.
Ziel: Relevante Beschattungsparameter + damit notwendige Bedinungen, die für eine Beschattung erfüllt sein müssen als Readings dem jeweiligen Rolladendevice <Shutter Device> zur Informatio hinzfügen. Es wird dadurch keine zusätzliche Funktion dem Modul / Rolladen hinzugefügt.
Alle Devices in den dreieckigen Klammern (<>) müssen durch eure eigenen systemspezifischen Devices und Readingnamen ersetzt werden.
myBrightness {ReadingsNum("<BrightnessSensorDevice>","<brightness reading>",0)},
myBrightnessForShadingMin {if(AttrVal("<Shutter Device>", "ASC_Shading_StateChange_SunnyCloudy","")=~qr/(.*):(.*)/p){$1}},
myTemperatureExtern {ReadingsNum("<TempSensorDevice>","temperature",0)},
myTemperatureExternForShadingMin {AttrVal("<Shutter Device>", "ASC_Shading_Min_OutsideTemperature","")},
mySunAzimuth {ReadingsNum("<TwilightDevice>","SunAz",0)},
mySunAzimuthLeft {if(AttrVal("<Shutter Device>", "ASC_Shading_InOutAzimuth","")=~qr/(.*):(.*):(.*)/p){$1}},
mySunAzimuthRight {if(AttrVal("<Shutter Device>", "ASC_Shading_InOutAzimuth","")=~qr/(.*):(.*):(.*)/p){$2}},
mySunElevation {ReadingsNum("<TwiligthDevice>","SunAlt",0)},
mySunElevationForShadingMin {if(AttrVal("<Shutter Device>", "ASC_Shading_MinMax_Elevation","")=~qr/(.*):(.*)/p){$1}},
mySunElevationForShadingMax {if(AttrVal("<Shutter Device>", "ASC_Shading_MinMax_Elevation","")=~qr/(.*):(.*)/p){$2}},
myShadingPASS_GreaterBrightnessMin {if (ReadingsNum("<Shutter Device>","myBrightness",0) > ReadingsNum("<Shutter Device>","myBrightnessForShadingMin",0)) {"True"} else {"False"}},
myShadingPASS_GreaterSunAzimuthLeft {if (ReadingsNum("<Shutter Device>","mySunAzimuth",0) > ReadingsNum("<Shutter Device>","mySunAzimuthLeft",0)) {"True"} else {"False"}},
myShadingPASS_LowerSunAzimuthRight {if (ReadingsNum("<Shutter Device>","mySunAzimuth",0) < ReadingsNum("<Shutter Device>","mySunAzimuthRight",0)) {"True"} else {"False"}},
myShadingPASS_GreaterSunElevationMin {if (ReadingsNum("<Shutter Device>","mySunElevation",0) > ReadingsNum("<Shutter Device>","mySunElevationForShadingMin",0)) {"True"} else {"False"}},
myShadingPASS_LowerSunElevationMax {if (ReadingsNum("<Shutter Device>","mySunElevation",0) < ReadingsNum("<Shutter Device>","mySunElevationForShadingMax",0)) {"True"} else {"False"}},
myShadingPASS_GreaterTemperatureExternMin {if (ReadingsNum("<Shutter Device>","myTemperatureExtern",0) > ReadingsNum("<Shutter Device>","myTemperatureExternForShadingMin",0)) {"True"} else {"False"}}
Zur Information:
Der Sonnensensor <BrightnessSensorDevice> muss mindestens 2 Messwerte liefern, bevor das ASC-Modul in die Beschattungsposition fährt! Beim (zeitlich gesehen) ersten Messwert wird der Zustand in-reserved eingenommen und erst beim zweiten Messwert dann der Zustand in shading eingenommen. Die Anzahl der Messwerte ich abhängig vom "moving average window", der mit dem dritten Parameter des Attributs ASC_Shading_StateChange_SunnyCloudy konfiguriert wird.
Hallo und danke für deinen Code Schnipsel.
Habe den versucht bei mir einzubauen. Musste die readings vom Twilight Device und die regex von "ASC_Shading_InOutAzimuth","")=~qr/(.*):(.*):(.*)/p){$1}}, anpassen. Du hattest auf drei Werte geschaut aber bei Azimuth gibt es auch nur zwei Werte. Danach funktionierte alles.
Habe mir basierend auf diese Readings dann einen readinsgroup gesetzt und kann nun anhand eines Ampelsystem sehen ob die Werte erfüllt sind.
Poste doch bitte einmal den Code für Dein Ampelsystem, oder besser noch schreibe es als Beispiel ins Wiki. Ich denke das ist auch für andere Interessant.
Frage: Was ist eine extra Reading Definition?
Gemeint sind userReadings, nehme ich an?
Dann wäre m.E. ergänzend folgendes sinnvoll:
1. je einen trigger dazu (z.B. allg. pct/dim);
2a. $name statt fester Werte, wo möglich;
2b. Eventuell kann man auch den Twilight-Device-Namen usw. indirekt über eine Attributauswertung - ausgehend von $name - hinbekommen? (Ggf. muß man für den default dann nochmal eine Funktion einfügen, die dann auf das allg. ASC-Device verweist, wenn es eine Logik "lokal nicht vorhanden? => nimm den Wert aus dem ASC-Gerät" gibt.
So ganz klar ist mir noch nicht, ob man nicht mit dem readingsGroup-Vorschlag (mit der getter-Funktion) von Cooltux neulich nicht eine "bessere Basis" hätte, wenn dann irgendwann auch die setter kommen?
Zitat von: CoolTux am 21 April 2020, 11:50:14
Poste doch bitte einmal den Code für Dein Ampelsystem, oder besser noch schreibe es als Beispiel ins Wiki. Ich denke das ist auch für andere Interessant.
Du wirst lachen genau das hatte ich vor wollte nur die Reaktion abwarten. Wenn das hilfreich ist baue ich das ins Wiki ein.
Gesendet von meinem JSN-L21 mit Tapatalk
Zitat von: xerion am 21 April 2020, 12:14:02
Du wirst lachen genau das hatte ich vor wollte nur die Reaktion abwarten. Wenn das hilfreich ist baue ich das ins Wiki ein.
Gesendet von meinem JSN-L21 mit Tapatalk
Super vielen lieben Dank. Ich denke schon das es sehr hilfreich ist. Nimmst Du zum auslesen der Werte aber bitte die ASC API.. Ist denke ich besser wie die Regex Methode von "AutomatisierEtwas"
Zitat von: Beta-User am 21 April 2020, 12:11:24
Frage: Was ist eine extra Reading Definition?
Gemeint sind userReadings, nehme ich an?
Dann wäre m.E. ergänzend folgendes sinnvoll:
1. je einen trigger dazu (z.B. allg. pct/dim);
2a. $name statt fester Werte, wo möglich;
2b. Eventuell kann man auch den Twilight-Device-Namen usw. indirekt über eine Attributauswertung - ausgehend von $name - hinbekommen? (Ggf. muß man für den default dann nochmal eine Funktion einfügen, die dann auf das allg. ASC-Device verweist, wenn es eine Logik "lokal nicht vorhanden? => nimm den Wert aus dem ASC-Gerät" gibt.
So ganz klar ist mir noch nicht, ob man nicht mit dem readingsGroup-Vorschlag (mit der getter-Funktion) von Cooltux neulich nicht eine "bessere Basis" hätte, wenn dann irgendwann auch die setter kommen?
Ja der User hatte es als Userreading kreiert ich musste anfangs auch überlegen.
[emoji848]
Ich bin leider kein Programmierer und versuche mir sehr pragmatisch zu helfen. Wenn du mir das erklären kannst wie man sich die Daten von dem Twilight Device usw. automatisch holen kann, dann kann ich ja Mal was versuchen und kann meinen Horizont erweitern.
Gesendet von meinem JSN-L21 mit Tapatalk
Zitat von: CoolTux am 21 April 2020, 12:18:15
Super vielen lieben Dank. Ich denke schon das es sehr hilfreich ist. Nimmst Du zum auslesen der Werte aber bitte die ASC API.. Ist denke ich besser wie die Regex Methode von "AutomatisierEtwas"
Wenn du mir das als nicht Programmierer erklären kannst wie man das per ASC API macht versuche ich das gerne.
Gesendet von meinem JSN-L21 mit Tapatalk
Da gab es bereits ein tolles Beispiel. Warte ich schaue
tada
https://forum.fhem.de/index.php/topic,110263.msg1044471.html#msg1044471
(zu spät...)
Zitat von: xerion am 21 April 2020, 12:19:33
Wenn du mir das als nicht Programmierer erklären kannst wie man das per ASC API macht versuche ich das gerne.
Das hier dürfte als Beisliel ggf helfen: https://forum.fhem.de/index.php/topic,110263.msg1044471.html#msg1044471 (https://forum.fhem.de/index.php/topic,110263.msg1044471.html#msg1044471)
Zitat von: xerion am 21 April 2020, 12:18:28
Wenn du mir das erklären kannst wie man sich die Daten von dem Twilight Device usw. automatisch holen kann, dann kann ich ja Mal was versuchen und kann meinen Horizont erweitern.
Hmm, vermutlich wird das zu viel Aufwand, lohnt vermutlich eher weniger, man kann diese Angabe ja via search+replace recht einfach ersetzen (sofern erforderlich). Für die readingsGroup müßte "TYPE=AutoShuttersControl" reichen, dass man das eine Device erwischt (weiß aber noch nicht genau, wie am besten einbauen).
Zitat von: CoolTux am 21 April 2020, 12:39:38
tada
https://forum.fhem.de/index.php/topic,110263.msg1044471.html#msg1044471
Perfekt. Danke. Ich werde das mal versuchen als Grundlage zu nehmen um die userReadings zu ersetzen worauf meine readingsGroup mit Ampelsystem zurückreift. Wenn ich was vorzeigbares haben melde ich mich wieder und wenn es okay ergänze ich das dann im Wiki und würde die alten entfernen das es doch immer zur Verwirrung führt, da diese so nicht mehr funktionieren.
Vielen Dank für die Mühe.
Ich werde die Tage die Setter vorbereiten dann kann man auch die Werte ändern.
Zitat von: xerion am 21 April 2020, 12:49:07
Perfekt. Danke. Ich werde das mal versuchen als Grundlage zu nehmen um die userReadings zu ersetzen worauf meine readingsGroup mit Ampelsystem zurückreift. Wenn ich was vorzeigbares haben melde ich mich wieder und wenn es okay ergänze ich das dann im Wiki und würde die alten entfernen das es doch immer zur Verwirrung führt, da diese so nicht mehr funktionieren.
Hast du eine aktuelle Liste von dem ungesetzten Getters, denn in der commandref stehen scheinbar nicht alle drin, in deinem Beispiel vom dem Link sind ja schon die Werte Links/Rechts und Min/Max von Azimut bzw Elevation einzeln abrufbar.
Hast du zufällig auch schon ein Getter für den Brightness Sensor, vom device und vom ASC Modul?
Zitat von: xerion am 21 April 2020, 13:55:05
Hast du eine aktuelle Liste von dem ungesetzten Getters, denn in der commandref stehen scheinbar nicht alle drin, in deinem Beispiel vom dem Link sind ja schon die Werte Links/Rechts und Min/Max von Azimut bzw Elevation einzeln abrufbar.
Hast du zufällig auch schon ein Getter für den Brightness Sensor, vom device und vom ASC Modul?
device und ASC Modul gibt es keine Getter.
Relevant für den Brightness Sensor ist ja das Brightness Average.
getBrightnessAverage
über die API als
BrightnessAverage
ab zu rufen.
Eine Vollständige Übersicht habe ich noch nicht.
Zitat von: CoolTux am 21 April 2020, 15:18:13
device und ASC Modul gibt es keine Getter.
Relevant für den Brightness Sensor ist ja das Brightness Average.
getBrightnessAverage
über die API als
BrightnessAverage
ab zu rufen.
Eine Vollständige Übersicht habe ich noch nicht.
Ich meinte nicht ein Getter vom Device oder ASC selber sondern vom Brightness sensor der ja im device und/oder im ASC Modul vorhanden sein kann. So wie du es auch für OutTemp umgesetzt hast. Von welchen Sensor wird denn Brightness average per API übertragen?
Gesendet von meinem JSN-L21 mit Tapatalk
Es wird zu erst im shutter geschaut wenn da nichts ist wird der globale im ASC genommen. Kannst also getrost den von mir erwähnten getter nehmen.
Sorry Unsinn geschrieben. Es gibt nur einen Brightness Sensor und der ist im Rollo hinterlegt.
Zitat von: CoolTux am 21 April 2020, 16:52:46
Es wird zu erst im shutter geschaut wenn da nichts ist wird der globale im ASC genommen. Kannst also getrost den von mir erwähnten getter nehmen.
Perfekt. Verhält sich OutTemp auch schon so oder muss ich das explizit auswählen?
Gesendet von meinem JSN-L21 mit Tapatalk
Zitat von: xerion am 21 April 2020, 16:55:01
Perfekt. Verhält sich OutTemp auch schon so oder muss ich das explizit auswählen?
Gesendet von meinem JSN-L21 mit Tapatalk
Sorry falsch verstanden. Siehe oben. Es gibt ja nur einen Sensor für Brightness im Rollo.
Aber das oben geschriebene gilt für den Tempsensor.
Zitat von: CoolTux am 21 April 2020, 17:01:02
Sorry falsch verstanden. Siehe oben. Es gibt ja nur einen Sensor für Brightness im Rollo.
Aber das oben geschriebene gilt für den Tempsensor.
Stimmt jetzt wo du es sagst [emoji16]Sorry für die Verwirrung.
Gesendet von meinem JSN-L21 mit Tapatalk
So konnte das nun mit den getters und $NAME vereinfachen. Nun muss man einfach den nachfolgenden Code in dem dem gewünschten Device unter attr <ROLLODEVICE> userReadings einfügen. Damit werden dann zusätzlich Readings erzeugt basierend auf den Code aus Beitrag #1.
myBrightness {ascAPIget('BrightnessAverage',$NAME)},
myBrightnessForShadingCloudy {ascAPIget('ShadingStateChangeCloudy',$NAME)},
myBrightnessForShadingSunny {ascAPIget('ShadingStateChangeSunny',$NAME)},
myTemperatureExtern {ascAPIget('OutTemp',$NAME)},
myTemperatureExternForShadingMin {AttrVal("$NAME", "ASC_Shading_Min_OutsideTemperature","")},
mySunAzimuth {ascAPIget('Azimuth')},
mySunAzimuthLeft {ascAPIget('ShadingAzimuthLeft',$NAME)},
mySunAzimuthRight {ascAPIget('ShadingAzimuthRight',$NAME)},
mySunElevation {ascAPIget('Elevation')},
mySunElevationForShadingMin {ascAPIget('ShadingMinElevation',$NAME)},
mySunElevationForShadingMax {ascAPIget('ShadingMaxElevation',$NAME)},
myShadingPASS_GreaterBrightnessSunny {if (ReadingsNum("$NAME","myBrightness",0) > ReadingsNum("$NAME","myBrightnessForShadingSunny",0)) {"True"} else {"False"}},
myShadingPASS_LowerBrightnessCloudy {if (ReadingsNum("$NAME","myBrightness",0) > ReadingsNum("$NAME","myBrightnessForShadingCloudy",0)) {"True"} else {"False"}},
myShadingPASS_GreaterSunAzimuthLeft {if (ReadingsNum("$NAME","mySunAzimuth",0) > ReadingsNum("$NAME","mySunAzimuthLeft",0)) {"True"} else {"False"}},
myShadingPASS_LowerSunAzimuthRight {if (ReadingsNum("$NAME","mySunAzimuth",0) < ReadingsNum("$NAME","mySunAzimuthRight",0)) {"True"} else {"False"}},
myShadingPASS_GreaterSunElevationMin {if (ReadingsNum("$NAME","mySunElevation",0) > ReadingsNum("$NAME","mySunElevationForShadingMin",0)) {"True"} else {"False"}},
myShadingPASS_LowerSunElevationMax {if (ReadingsNum("$NAME","mySunElevation",0) < ReadingsNum("$NAME","mySunElevationForShadingMax",0)) {"True"} else {"False"}},
myShadingPASS_GreaterTemperatureExternMin {if (ReadingsNum("$NAME","myTemperatureExtern",0) > ReadingsNum("$NAME","myTemperatureExternForShadingMin",0)) {"True"} else {"False"}}
Danach erzeugt man nachfolgende readinsgGroup:
defmod ASC_Shading_Info readingsGroup <Gerät>,<IsSunny>,<NotCloudy>,<MinAzi>,<MaxAzi>,<MinEle>,<MaxEle>,<MinTemp> (Rollo|Jalousie)_.*..:myShadingPASS_GreaterBrightnessSunny,myShadingPASS_LowerBrightnessCloudy,myShadingPASS_GreaterSunAzimuthLeft,myShadingPASS_LowerSunAzimuthRight,myShadingPASS_GreaterSunElevationMin,myShadingPASS_LowerSunElevationMax,myShadingPASS_GreaterTemperatureExternMin
attr ASC_Shading_Info room ASC
attr ASC_Shading_Info valueIcon {($VALUE eq 'True')?"ampel_gruen":"ampel_rot"}
Dadurch bekommt man eine Ampel-Übersicht. Damit das Shading für das entsprechende ROLLODEVICE dann greifen kann, müssen alle Ampeln grün sein somit sind dann alle Bedingungen erfüllt. Nach Ablauf von ASC_Shading_WaitingPeriod wird dann Be- bzw. Entschattet. Somit kann man dann anhand der roten Ampel erkennen welche Bedingung noch nicht erfüllt ist.
Würde das für den Anfang reichen oder fehlt noch was? Falls ihr euer Okay gibt, würde ich es dann im Wiki veröffentlichen.
An sich sieht das ja erst mal gut aus, aber irgendwie will mir die Frage nicht aus dem Kopf, wann das wie aktualisiert wird...
Erst dachte ich, dass da zumindest noch je ein trigger dazu gehört, damit nicht alles bei jedem update von irgendeinem Reading an dem Rollo-Device aktialisiert wird. Aber bei näherer Betrachtung ist das alles suboptimal, eigentlich müßte alles nur bei Bedarf aktualisiert werden oder direkt in der readingsGroup stattfinden. Letzteres wäre m.E. das eigentliche Ziel, das dürfte aber einiges an Value-Formatierung in der rG erfordern...
Zitat von: Beta-User am 22 April 2020, 11:25:47
An sich sieht das ja erst mal gut aus, aber irgendwie will mir die Frage nicht aus dem Kopf, wann das wie aktualisiert wird...
Erst dachte ich, dass da zumindest noch je ein trigger dazu gehört, damit nicht alles bei jedem update von irgendeinem Reading an dem Rollo-Device aktialisiert wird. Aber bei näherer Betrachtung ist das alles suboptimal, eigentlich müßte alles nur bei Bedarf aktualisiert werden oder direkt in der readingsGroup stattfinden. Letzteres wäre m.E. das eigentliche Ziel, das dürfte aber einiges an Value-Formatierung in der rG erfordern...
Also momentan habe ich einen event-on-change-reading im Rollo device gesetzt und dementsprechend passt es bei mir. Ich habe noch nicht ganz verstanden worin aus deiner Sicht der Nachteil an dieser Umsetzung ist kannst du das bitte etwas näher erläutern?
Gesendet von meinem JSN-L21 mit Tapatalk
Wenn es "nur" "on-change"-Events gibt, sind es evtl. zu wenige Aktualisierungen, da ja auf externe Daten zugegriffen wird. Weiter ist es generell nicht optimal, userReadings ohne trigger zu definieren (meine Meinung), denn wenn sich z.B. mein ZWave-Aktor bewegt, werden immer mehrere Readings angefaßt; nun weiß ich nicht, ob das "bulk"-Änderungen sind (_ein_ Trigger), oder single-Readings-updates (_viele Trigger_), tendenziell würde ich eben vermeiden wollen, dass "zu viele" Trigger da sind. Ist einfach ein "schlechtes Beispiel", das man so dann auch nicht ins Wiki packen sollte.
Die ReadingsGroup dagegen "überwacht" "ihre Readings" dagegen selbstständig, und vermutlich auch nur dann, wenn sie in FHEMWEB angezeigt wird (die userReadings laufen immer und unabhängig davon, ob sie benötigt werden).
Nun klarer?
Dann habe ich aber noch mal eine Verständnisfrage zu deinem Vorschlag. Wenn ich nun einen Trigger auf pct/dim setze dann würden die Readings doch nur bei einer Fahrt des Rollos aktualisiert oder verstehe ich das falsch?
Korrekt. Aber das wäre ggf. zu selten... Man müsste evtl.einen händischen trigger via setreading oä. definieren.
Hatte ja schon geschrieben, dass das nicht so einfach zu lösen ist...
Un wenn man den Brightnesssensor triggert dann hätte man tagsüber zwar etwas mehr events aber Abends keine mehr?
Jein: der Brightness-Sensor triggert gar nicht innerhalb der userReadings eines anderen (!) Devices (hier: des Rollladens).
Deswegen nochmal: Wir sollten das möglichst innerhalb der readingsGroup-Definition abgefackelt bekommen, alles andere ist suboptimal...
Kann zwar auch sein, dass die getter da erst dann ausgeführt werden, wenn man die Seite refresht, aber das ist m.E. das kleinere Übel.
Dann muss ich mich noch etwas weiter einlesen bei den readingsGroup. Bei mir funktioniert es momentan erstmal und meine Infos die ich haben wollte bekomme ich, aber ich versuch mal das zu optimieren.
@xerion
bei mir funktioniert die Ampel nicht, die Logikwerte werden unter "userreadings" richtig angezeigt, das shading funktioniert auch; aber kein Gerätename und keine Ampeln nur die Überschriften.
"
ASC_Shading_Info
Gerät IsSunny NotCloudy MinAzi MaxAzi MinEle MaxEle MinTemp
"
defmod ASC_Shading_Info readingsGroup <Gerät>,<IsSunny>,<NotCloudy>,<MinAzi>,<MaxAzi>,<MinEle>,<MaxEle>,<MinTemp> (Rollo|Jalousie)_.*..:myShadingPASS_GreaterBrightnessSunny,myShadingPASS_LowerBrightnessCloudy,myShadingPASS_GreaterSunAzimuthLeft,myShadingPASS_LowerSunAzimuthRight,myShadingPASS_GreaterSunElevationMin,myShadingPASS_LowerSunElevationMax,myShadingPASS_GreaterTemperatureExternMin
attr ASC_Shading_Info room ASC
attr ASC_Shading_Info valueIcon {($VALUE eq 'True')?"ampel_gruen":"ampel_rot"}
Nach langem tricksen mit der Syntax läuft es jetzt:
defmod ASC_Shading_Info readingsGroup <Gerät>,<IsSunny>,<NotCloudy>,<MinAzi>,<MaxAzi>,<MinEle>,<MaxEle>,<MinTemp>
(.*Rollo.*):!?myShadingPASS_GreaterBrightnessSunny,myShadingPASS_LowerBrightnessCloudy,myShadingPASS_GreaterSunAzimuthLeft,myShadingPASS_LowerSunAzimuthRight,myShadingPASS_GreaterSunElevationMin,myShadingPASS_LowerSunElevationMax,myShadingPASS_GreaterTemperatureExternMin