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

MCh76 · 23 Juli 2019, 15:26:34

Zitat von: ch.eick am 23 Juli 2019, 15:05:31
Hallo Chris,

nach meinen Versuchen steht in <ASC_Device>: lastPosValue die letzte Position, die durch ASC angefahren wurde.
Da Du mit einem set Befehl "manuell" gefahren hast wird das dort nicht eingetragen, um später wieder zu der ASC Position zurück zu fahren.

Gruß
Christian

super! danke für die Erklärung...dann muss ich mal weiter forschen warum dieser eine Rolladen als einziger heute nicht runter gefahren ist, obwohl die Rahmenbedingungen erfüllt waren, die restlichen sind gefahren.

flummy1978 · 23 Juli 2019, 15:33:40

Hallöchen,

ich hab mal ne ganz kurze Frage zur Programmierung / Funktion vom ASC:

Bezieht sich ein Teil der Programmierung auf den Zustand vom eigentlichen STATE (nicht state!) ?

Hintergrund der Frage ist der, dass ich sehr viele Geräte die ich auch vom Handy aus bedienen möchte mit einem mehrzeigeilgem State ausgestatet hab, so dass auch in der smallscreen Darstellung mehrere Icons / Befehlen neben / übereinander dargestellt werden können. Bsp:

Code Auswählen


read0:state
<br>
read1:state
 
read2:state
 
read3:state

Jedes Icon hat zwar den gleichen Zustand (nämlich den von state) ABER der read0:ICON reagiert anders auf eine state Veränderung als read1:ICON usw ....

Für mich ist es nur wichtig, dass ich mit stateFormat nicht irgendwelche unerwünschten Effekte hervorrufe.

Vielen Dank im Voraus

Grüße
Andreas

ch.eick · 23 Juli 2019, 15:38:17

Zitat von: MCh76 am 23 Juli 2019, 15:26:34
super! danke für die Erklärung...dann muss ich mal weiter forschen warum dieser eine Rolladen als einziger heute nicht runter gefahren ist, obwohl die Rahmenbedingungen erfüllt waren, die restlichen sind gefahren.

verbose 5
List ASC_Device
List shutter_Device
Log Auszüge

Und schon wird Dir hier geholfen [emoji16]

Gesendet von meinem SM-G930F mit Tapatalk

ch.eick · 23 Juli 2019, 18:25:56

Hallo zusammen,

wofür werden diese beiden Attribute verwendet?

ASC_Close_Pos in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ASC
ASC_Open_Pos in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ASC

Mit dem Attribut "ASC 1" im Rollo Device habe ich doch bereits gesagt, dass "position 0" einem open und "positoion 100" einem close entspricht.

Gruß
Christian

Beta-User · 23 Juli 2019, 18:43:45

Zitat von: ch.eick am 23 Juli 2019, 18:25:56
Mit dem Attribut "ASC 1" im Rollo Device habe ich doch bereits gesagt, dass "position 0" einem open und "positoion 100" einem close entspricht.

Nicht ganz...
Ursprünglich hatten wir es wirklich nur mit Aktoren zu tun, die zwischen 0 und 100 lagen. Recht häufig ist es aber auch, dass max. 99 angesteuert werden kann (typisch für die ZWave-Aktoren). Und irgendwann hatten wir auch mal einen Fall, in dem die Werte effektiv zwischen 17 und 22 (?) lagen.

Ich selbst habe aber auch ein paar Aktoren, die offener als "offen" (im ASC-Sinn) sein können. Das allgemeine Attribut gibt also einfach nur die Richtung vor und dient als "Kenner", damit man den Aktor einfach einbinden kann, die anderen beiden braucht man uU. zusätzlich für eine sinnvolle Ansteuerung.

"Falsch" ist auch die Beschränkung auf 10-er Schritte. Effektiv geht auch mehr, wir hatten nur ursprünglich gleich ein Auswahlfeld mit drin, das brauchte "irgendeine" Vorgabe (geht mit selectnumer-widget eigentlich einfacher, hätte man damals nur wissen müssen...).

MCh76 · 23 Juli 2019, 19:03:43

Wenn ich es richtig verstehe müsste es doch eigentlich egal sein ob ich ASC auf 1 oder 2 setze, so lange ich ASC_Pos_Reading bzw. ASC_Closed_Pos und ASC_Open_POS entsprechend setze oder?
Hintergrund meiner Frage ist, dass bei meinen Home Matic (mit levelinverse) und Velux Rolladen oben = 0 und geschlossen = 100 entspricht. demnach hab ich ASC = 2 und open_pos und closed_pos entsprechend gesetzt.

Beta-User · 23 Juli 2019, 19:13:06

Hmm, dazu müßte man mal in den Code sehen.
Ich _vermute_, es ist nicht egal, weil die Frage, ob ein Wert "oben" oder "unten" ist, sich nach dem allg. ASC-Attribut richten sollte (so war das jedenfalls mal ursprünglich gedacht). Solange man nur morgens/abends auf- und zumacht, mag das sogar egal sein (hmm, eigentlich ja nicht, eine Fahrt ist nach meinem Verständnis nicht erforderlich, wenn offener als offen ist), aber an sich ist es m.E. eine separate Fragestellung, ob jetzt nach größergleich oder kleinergleich verglichen wird, bevor der effektive Fahrbefehl rausgeht.

MCh76 · 23 Juli 2019, 19:34:42

Zitat von: Beta-User am 23 Juli 2019, 19:13:06
Hmm, dazu müßte man mal in den Code sehen.
Ich _vermute_, es ist nicht egal, weil die Frage, ob ein Wert "oben" oder "unten" ist, sich nach dem allg. ASC-Attribut richten sollte (so war das jedenfalls mal ursprünglich gedacht). Solange man nur morgens/abends auf- und zumacht, mag das sogar egal sein (hmm, eigentlich ja nicht, eine Fahrt ist nach meinem Verständnis nicht erforderlich, wenn offener als offen ist), aber an sich ist es m.E. eine separate Fragestellung, ob jetzt nach größergleich oder kleinergleich verglichen wird, bevor der effektive Fahrbefehl rausgeht.

ok dann stelle ich das ASC attribut mal am besten um in meinem Fall auf 1 und setz dann pos_reading auf pct...
reicht danach ein set createNewNotifyDev im ASC device oder muss ich mehr tun?

Beta-User · 23 Juli 2019, 19:40:35

Vorsichtshalber auch scannen.Ist aber alles nur ein "vermutlich"...

ch.eick · 23 Juli 2019, 23:21:11

Vielen Dank für die Infos.

In meinem Fall mit FSB61 reicht bisher
ASC=1
Damit ist position 0 ganz oben und 100 ganz unten, also keine schräge Sondereinstellung.
Klaus vom EnOcean Modul hat für FSB61 noch einen Patch eingebaut über den ich hier schon mal geschrieben hatte (opens/closes)

Also ist FSB61 mit ASC kompatibel und getestet.

Könntet Ihr das mit ASC_Open/Close_Pos noch in der Wiki genauer eintragen. Das mit den Beispielen hat es mir gut klar gemacht.

Danke Christian

Beta-User · 24 Juli 2019, 07:41:01

Zitat von: ch.eick am 23 Juli 2019, 23:21:11
Könntet Ihr das mit ASC_Open/Close_Pos noch in der Wiki genauer eintragen. Das mit den Beispielen hat es mir gut klar gemacht.

Darfst gerne Rückmeldung geben zu dem, was ich jetzt ganz vorne bei der 1/2-Frage dazugebastelt habe... Aber bitte im Wiki-Bereich

.

CoolTux · 24 Juli 2019, 08:40:58

Zitat von: Beta-User am 23 Juli 2019, 19:13:06
Hmm, dazu müßte man mal in den Code sehen.
Ich _vermute_, es ist nicht egal, weil die Frage, ob ein Wert "oben" oder "unten" ist, sich nach dem allg. ASC-Attribut richten sollte (so war das jedenfalls mal ursprünglich gedacht). Solange man nur morgens/abends auf- und zumacht, mag das sogar egal sein (hmm, eigentlich ja nicht, eine Fahrt ist nach meinem Verständnis nicht erforderlich, wenn offener als offen ist), aber an sich ist es m.E. eine separate Fragestellung, ob jetzt nach größergleich oder kleinergleich verglichen wird, bevor der effektive Fahrbefehl rausgeht.

Bitte daran denken daß sich die Default Fenster Auf Positionen auch nach dem ASC Wert richten. Und Beschattung auch.
Aber im Grunde ist es in der Tat egal ob 1 oder 2 man muss halt dann nur entsprechend die Defaults überschreiben durch setzen der Attribute.

Beta-User · 24 Juli 2019, 09:17:53

Zitat von: CoolTux am 24 Juli 2019, 08:40:58
Bitte daran denken daß sich die Default Fenster Auf Positionen auch nach dem ASC Wert richten. Und Beschattung auch.
Aber im Grunde ist es in der Tat egal ob 1 oder 2 man muss halt dann nur entsprechend die Defaults überschreiben durch setzen der Attribute.

Danke für den Hinweis mit den defaults. Das baue ich vermutlich auch noch in den Wiki-Hinweis mit rein.

Trotzdem irritiert mich diese Antwort: Denn im Prinzip muß das Modul ja ständig prüfen, ob die aktuelle Position "geschlossener" oder "weniger geschlossen" ist als die jeweilige Sollposition. Ich wäre jetzt davon ausgegangen, dass die Basislogik dafür aus dem ASC-Attribut abgeleitet wird. Alles andere ist jedenfalls auf den ersten Blick "feature-verdächtig", gerade weil man die anderen Attributwerte ansonsten recht frei setzen und damit auch bewußt ein "seltsames" (aber eben gewolltes) Verhalten herbeiführen kann.

CoolTux · 24 Juli 2019, 09:31:41

Das ASC Modul hat damit so erstmal nichts zu tun. Es dient lediglich dazu sollten bestimmte Attribute nicht gesetzt sein Defaults zu ermitteln. Wer also OpenPos oder ClosedPos nicht setzt und ASC auf eins hat so ermittelt sich Default OpenPos 0 und ClosedPos 100, Fenster gekippt 80 und so weiter.

Beta-User · 24 Juli 2019, 09:42:49

...wir reden vermutlich mal wieder aneinander vorbei...

Das mit den defaults ist klar (und steht btw. auch schon im Wiki).

Aber, mal ein kleines Beispiel:
Rollo steht auf 90. Closed Pos ist 80. Open Pos ist 20.

Wie fährt jetzt das Rollo, wenn "closing time" ist?

MMn. sollte es da einen Unterschied machen, ob ASC auf 1 oder 2 steht. "1" würde bedeuten: "Fahre auf 80", "2" würde "laß es, wie es ist" (weil schon geschlossener als geschlossen) zur Folge haben.

(Dass diese Einstellung ggf. "seltsam" ist, ist klar und steht hier nicht zur Diskussion... Es geht nur um die Frage, wie festgelegt wird, was "oben" und was "unten" ist, und dafür _sollte_ m.E. _nur_ das ASC-Attribut maßgeblich sein.)