[ASC] - ACHTUNG!!! Tester gesucht, @Reinhard. M, @marvin78 und @sukram und ALLE!

[Reinhard.M]

Dein external Trigger Problem sollte eigentlich gefixt sein.

Mit "Problem" meinte ich, dass ich keinen Slat Parameter übergeben kann. Alles andere funktioniert jetzt problemlos, absolut richtig. Aber ich kann halt nur "pct" übergeben und brauche "pct:sltpct" als Übergabeparameter da ich damit dit Slatposition auch verstelle. Das meinte ich.

[Beta-User]

Mit "Problem" meinte ich, dass ich keinen Slat Parameter übergeben kann. Alles andere funktioniert jetzt problemlos, absolut richtig. Aber ich kann halt nur "pct" übergeben und brauche "pct:sltpct" als Übergabeparameter da ich damit dit Slatposition auch verstelle. Das meinte ich.

Na ja: Wenn du Perl anflanschst, kannst du prüfen, ob für $slatPos was sinnvolles bekannt ist oder nicht (dann kommt: "-1"). Vorläufig würde es vermutlich reichen, einfach in dem Fall dann für die Lamellen auch $pos zu verwenden...?

Nachtrag - etwa so:

Code Auswählen Erweitern

{ my $slats = $slatPos ne '-1' ? $slatPos : $pos; fhem("set $name datapoint 4.LEVEL_2 $slats 4.LEVEL $pos") }

[Reinhard.M]

Na ja: Wenn du Perl anflanschst, kannst du prüfen, ob für $slatPos was sinnvolles bekannt ist oder nicht (dann kommt: "-1"). Vorläufig würde es vermutlich reichen, einfach in dem Fall dann für die Lamellen auch $pos zu verwenden...?

Nachtrag - etwa so:

Code Auswählen Erweitern

{ my $slats = $slatPos ne '-1' ? $slatPos : $pos; fhem("set $name datapoint 4.LEVEL_2 $slats 4.LEVEL $pos") }

Danke für dein schnelles Feedback. Ich habe aber noch mehr als genug offene Baustellen und nicht so viel Zeit. Dein Vorschlag passt bei mir leider nicht ganz da ich derzeit an dieser Stelle beide Positionen übergeben muss. Für mich ist momentan mit der Jalousie alles in Ordnung, da fange ich nur ungern eine Zwischenlösung an die schlechter ist als meine aktuelle. Sorry.

[Beta-User]

...nur für den Fall, dass du derzeit sowas wie "60.44" übergeben bekommst im external trigger-Fall: auch diesen $pos-Wert könnte man "nachbearbeiten" und dann mit der Perl-Variante splitten.
Aber wir können gerne darauf warten, dass CoolTux den Attribut-Parser passend umbaut; das wäre vermutlich zielführender wie noch ein workaround . Wollte nur zeigen, dass es jetzt möglich ist, flexibel zu reagieren, wenn man das braucht .

[CoolTux]

Danke für dein schnelles Feedback. Ich habe aber noch mehr als genug offene Baustellen und nicht so viel Zeit. Dein Vorschlag passt bei mir leider nicht ganz da ich derzeit an dieser Stelle beide Positionen übergeben muss. Für mich ist momentan mit der Jalousie alles in Ordnung, da fange ich nur ungern eine Zwischenlösung an die schlechter ist als meine aktuelle. Sorry.

Da Du selbst nun Perlcode verwenden kannst wäre eine Möglichkeit den Fahrgrund aus zu werten und wenn der external Trigger ist einfach den Slat Wert im Fahrbefehl mit zu übergeben.

[Reinhard.M]

...nur für den Fall, dass du derzeit sowas wie "60.44" übergeben bekommst im external trigger-Fall: auch diesen $pos-Wert könnte man "nachbearbeiten" und dann mit der Perl-Variante splitten.
Aber wir können gerne darauf warten, dass CoolTux den Attribut-Parser passend umbaut; das wäre vermutlich zielführender wie noch ein workaround . Wollte nur zeigen, dass es jetzt möglich ist, flexibel zu reagieren, wenn man das braucht .

Wirklich nochmals herzlichen Dank für die Unterstützung, das weiß ich zu schätzen.

[marvin78]

Das muss ich leider noch ein wenig schieben da ich ansonsten wieder Probleme mit meinem ExternalTrigger bekomme. Aber bei Marvin funktioniert es ja schon, bei mir wird es dann ja (hoffentlich) nicht anders sein

Gruß Reinhard

Ich muss das noch ein wenig einschränken. Fahren ist zuverlässig, Last Drive stimmt aber eigentlich nur mal zufällig. Dahinter steige ich nicht.

[Reinhard.M]

Ich muss das noch ein wenig einschränken. Fahren ist zuverlässig, Last Drive stimmt aber eigentlich nur mal zufällig. Dahinter steige ich nicht.

Das kann ich unabhängig von den Änderungen bestätigen. Es gibt einige verschiedene LastDrive Speicher pro Device. Ich habe bis heute nicht wirklich alle verstanden glaube aber die allermeisten logisch nachvollziehen zu können. Dafür muss man aber viel raumprobieren.

[Beta-User]

Entsprechen denn die angefahrenen Positionen dann im Ergebnis den von ASC erwarteten?

Bei 100.100 ist relativ klar, dass 100,1 halt nicht 100 ist (das war der Grund, warum ich gleich bei dieser "Punkt"-Geschichte darauf hingewiesen habe, dass das nicht das Gelbe vom Ei ist).

Meine ZWave-Aktoren hatten ähnliche Probleme, weil da das Kippen der Lamellen dann dazu geführt hat, dass teils die dim-Values für den Behang an sich nicht mehr zu 100% gepaßt haben (kleine Abweichungen von ca. 1-2 dim-Punkten). Bei ZWave kann man das korrigieren, weil man den "dim"-Reading-Wert "rückwärts" eh per userReadings setzen muss und ich dann eine entsprechende Hysterese eingebaut habe. Vielleicht ist das bei den HM-IP-Jalousie-Geräten auch so und man muss einen Workaround finden?

(@CoolTux: Das ist auch so ein allgemeines Problem, für das man ggf. dann doch irgendwie eine zentrale Fix-Option basteln sollte...?)

[CoolTux]

Entsprechen denn die angefahrenen Positionen dann im Ergebnis den von ASC erwarteten?

Bei 100.100 ist relativ klar, dass 100,1 halt nicht 100 ist (das war der Grund, warum ich gleich bei dieser "Punkt"-Geschichte darauf hingewiesen habe, dass das nicht das Gelbe vom Ei ist).

Meine ZWave-Aktoren hatten ähnliche Probleme, weil da das Kippen der Lamellen dann dazu geführt hat, dass teils die dim-Values für den Behang an sich nicht mehr zu 100% gepaßt haben (kleine Abweichungen von ca. 1-2 dim-Punkten). Bei ZWave kann man das korrigieren, weil man den "dim"-Reading-Wert "rückwärts" eh per userReadings setzen muss und ich dann eine entsprechende Hysterese eingebaut habe. Vielleicht ist das bei den HM-IP-Jalousie-Geräten auch so und man muss einen Workaround finden?

(@CoolTux: Das ist auch so ein allgemeines Problem, für das man ggf. dann doch irgendwie eine zentrale Fix-Option basteln sollte...?)

Das versuche ich eigentlich seit Jahren zu umgehen. Ich finde persönlich nicht das es Aufgabe von ASC sein sollte diese "Probleme" zu fixen. Entweder das Teil fährt zu 100% den gewünschten Behang/Stufe an oder es ist halt Mist. Die Frage ist ja immer wo fängt so ein Fix an und wo endet er.

[Beta-User]

Das versuche ich eigentlich seit Jahren zu umgehen. Ich finde persönlich nicht das es Aufgabe von ASC sein sollte diese "Probleme" zu fixen. Entweder das Teil fährt zu 100% den gewünschten Behang/Stufe an oder es ist halt Mist. Die Frage ist ja immer wo fängt so ein Fix an und wo endet er.

Im Prinzip hast du ja recht, und wenn die Realität nicht immer mal wieder eine andere wäre wie in einer idealen Welt, würden wir das nicht auch immer mal wieder diskutieren. Hier wissen wir bisher noch nicht mal, ob das das Problem ist - das sollten wir also in jedem Fall zuerst erfahren...

Ansonsten ist es halt so, dass da viele Faktoren mit reinspielen, angefangen damit, dass halt mehrere Umwandlungen, Rundungen, Timing-Probleme usw. auf dem Weg vom und zum Device stattfinden können. Es geht wenn, dann auch nicht darum, das generell zu fixen, sondern vielleicht eine Art "RHASSPY-Specials" anzubieten, mit denen man eben bei solchen kleinen Wacklern noch nachregeln könnte. Sowas sinnvoll mit Leben zu füllen wäre dann eben Aufgabe des Users. Konkret könnte hier eben eine absolute Differenz angegeben werden, innerhalb derer ein Wert noch als "gleich" angesehen wird (default: 0).
Ist halt unschön, dass das die Koplexität und den Rechenaufwand pro Event nochmal erhöht, und bei den ZWave-Dingern finde ich auch nach wie vor die userReadings-Lösung besser, weil direkt an der Wurzel. Für die HM-IP-Dinger kann ich (noch) nichts sagen, da fehlt einfach bisher die Rückmeldung, an was es genau hängt...

[Reinhard.M]

Sorry, missverständlich ausgedrückt von mir.
Das Problem ist, dass man nicht weiß "welche" LastPos angefahren wird. Im ASC Device sehe ich lastDelayPosValue, lastPosValue und "Last Position" im Summary. Die DelayPos sicherlich nur weil ich sie einmalig ausgelesen habe. Aber welche gibt es noch und wann wirkt welche? Ich meine, es gibt auch noch eine lastManualPos, ich weiß es aber nicht sicher. Diese vielen Möglichkeiten und die Unwissenheit bezüglich der logischen Verknüpfungen führen dazu, dass eine Fahrt in die LastPos gelegentlich bis oftmals absolut willkürlich aussehen. Ich sitze dann davor und frage mich: "Warum fährt das Ding jetzt in diese Position? Die letzte Position die ich gesehen habe war doch eine andere". Es geht absolut nicht um ein paar Zentimeter hin oder her, es kann ohne weiteres der Unterschied zwischen ganz oben und ganz unten sein. Ich habe vermutet, dass Marvin78 das Gleiche meinte.

[Beta-User]

Ich habe in dem anderen Thread nur gesehen, dass da anscheinend immer "manual" als Fahrt erkannt wird. Wenn ASC denkt, der User hat dazwischen irgendwas gemacht, dann wird das häufig respektiert und die weiteren Fahrten finden dann eben teils nicht statt. Also muss man zuerst dafür sorgen, dass ASC "seine" Fahrten als "abgeschlossen" betrachten kann. Und genau da sind wir wieder bei "100.100 ist nicht gleich 100" (oder was auch immer die HM-IP-Jalousie dann anfährt).

Bitte also diese Basisfunktionalität überprüfen, vorher ist m.E. alles andere an Aufklärungsversuchen unnötig.
Edit: Das scheint ja in dem anderen Thread schon funktioniert zu haben... Dann wird es das nicht gewesen sein, sorry. Dann kann ich bis auf weiteres auch nichts sinnstiftendes mehr beitragen.

[marvin78]

Ich habe in dem anderen Thread nur gesehen, dass da anscheinend immer "manual" als Fahrt erkannt wird. Wenn ASC denkt, der User hat dazwischen irgendwas gemacht, dann wird das häufig respektiert und die weiteren Fahrten finden dann eben teils nicht statt. Also muss man zuerst dafür sorgen, dass ASC "seine" Fahrten als "abgeschlossen" betrachten kann. Und genau da sind wir wieder bei "100.100 ist nicht gleich 100" (oder was auch immer die HM-IP-Jalousie dann anfährt).

Bitte also diese Basisfunktionalität überprüfen, vorher ist m.E. alles andere an Aufklärungsversuchen unnötig.
Edit: Das scheint ja in dem anderen Thread schon funktioniert zu haben... Dann wird es das nicht gewesen sein, sorry. Dann kann ich bis auf weiteres auch nichts sinnstiftendes mehr beitragen.

Was genau heißt das? Wenn ich jetzt nach der neuen Methode 100:100 als anzufahrende Position für bspw. open (ASC_Open_Pos) angebe, dann muss im entsprechenden Reading das ich unter ASC_Pos_Reading angebe auch 100:100 stehen haben, damit ASC es nicht als "manual" erkennt?? Ist das der Grund, warum der Fahrgrund eigentlich nie stimmt? Das würde erklären, dass der Fahrgrund bei normalen Rollladen zumindest häufiger stimmt, auch wenn nicht immer (und dazu muss man wissen, dass diese Geräte NIE manuell gefahren werden).

[Beta-User]

Was genau heißt das? Wenn ich jetzt nach der neuen Methode 100:100 als anzufahrende Position für bspw. open (ASC_Open_Pos) angebe, dann muss im entsprechenden Reading das ich unter ASC_Pos_Reading angebe auch 100:100 stehen, damit ASC es nicht als "manual" erkennt. Ist das der Grund, warum der Fahrgrund eigentlich nie stimmt? Das würder erklären, warum der Fahrgrund bei normalen Rollladen zumindest häufiger stimmtm, auch wenn nicht immer (und dazu muss man wissen, dass diese Geräte NIE manuell gefahren werden).

An sich sollte bei "ordnungsgemäßer" Angabe in der Form "60:70" dann die erste Zahl (60) als Positionsangabe am Ende auch angefahren sein. Das gilt nach der erwarteten Fahrzeit, die man v.a. bei größeren Jalousien evtl. entsprechend erhöhen muss.

Bei den ZWave-Geräten ist es so, dass bei manchen Zwischenpositionen dann eben (ohne Korrektur) hinterher statt "60" nur "59" (oder "61") rauskommt, weil die Neuberechnung der Höhe nach dem Drehen der Lammellen (=kurzes Fahren in Gegenrichtung) eben auf dem Aktor nicht zwangsläufig "richtig" ist (es ist je nach Sichtweise sogar nicht mal "falsch", weil der untere Abschluss der Jalousie ja tatsächlich bewegt wird!).

Es handelt sich also um zwei unterschiedliche Ursachen, warum ASC dann uU. fälschlicherweise davon ausgeht, dass manuell eingegriffen wurde. Teil 1 mit der Zeit kann man lösen, Teil 2 (Nachberechnung) nur, wenn man das betreffende Positions-Reading ggf. nachmanipuliert. Zu den HM-IP-Geräten kann ich nichts sagen, da ich für diesen Zweck deutlich lieber die ZWave-Modelle im Einsatz habe wie die aus dem Hause eQ-3 (ich hatte da vorher normale Rollladenaktoren in BidCoS), und bei ZWave muss/kann man das Reading eh' "nur" per userReadings setzen.