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

[marvin78]

Die erste Zahl ist 100 und die wird auch erreicht (bei Zwischenpositionen ist es ggf. anders) . Aber was ist mit der eingestellten Zeit? Wo baue ich die ein? Eine max duration Angabe gibt es ja nur für up.

[Beta-User]

"up" dauert meistens länger wie "down", und von daher sollte da dann halt die längere Zeit drin stehen, falls es ausnahmsweise anders ist...

[marvin78]

Gerade bei Jalousien handelt es sich da um maximal eine Sekunde.

Heißt das, die drive down time wird von der up time abgeleitet?

[Beta-User]

Jein. MWn. ist es einfach eine (einheitliche) zeitliche Abgrenzung.

[marvin78]

Das wäre ja sinnlos. Es sei denn die Zeit liegt bei irgendwas von weit über 2 Minuten. Jalousien können langsam sein.

Hier liegt die Laufzeit aber in 5 Fällen bei etwa 60 Sekunden und in einem bei 30 Sekunden. Es wird immer das definierte Ziel (0 oder 100) erreicht. Trotzdem ist Fahgrund immer manual.

Gibt es eine Liste der Kriterien für diese Erkennung?

[Reinhard.M]

Das wäre ja sinnlos. Es sei denn die Zeit liegt bei irgendwas von weit über 2 Minuten. Jalousien können langsam sein.

Hier liegt die Laufzeit aber in 5 Fällen bei etwa 60 Sekunden und in einem bei 30 Sekunden. Es wird immer das definierte Ziel (0 oder 100) erreicht. Trotzdem ist Fahgrund immer manual.

Gibt es eine Liste der Kriterien für diese Erkennung?

Das hört sich für mich bekannt an. Hast du schon folgendes getestet

Code Auswählen Erweitern

{ ascAPIget('LastDrive','<Device>') }
Daran konnten wir erkennen das es intern richtig verarbeitet wird, im Reading aber nicht angezeigt. CoolTux konnte es dann fixen. Zumindest in meinem Fall.

[Beta-User]

Wann kommen da welche Events? Immer derselbe, richtiger Stand, aber zu spät? => manual...

[marvin78]

Wann kommen da welche Events? Immer derselbe, richtiger Stand, aber zu spät? => manual...

? das ist doch meine Frage oben: Was ist denn zu spät? Was ist denn bei einer Jalousie, die (egal ob hoch oder runter) nur 30 Sekunden fährt, zu spät? Falls die Zeit, in der ASC erkennt, ob es eine ASC Fahrt ist, unter 30 Sekunden liegt, ist sie schlicht zu klein. Es gibt auch viele Rollladen die länger fahren.

Ich kann hier nicht ständig auf Events testen, es ist das Haus meiner Schwiegermutter und ich kann auch nicht zu den Fahrzeiten auf der Lauer liegen. Deshalb nochmal anders:

Ist irgendwo dokumentiert, was genau für Kriterien anliegen müssen, damit eine Fahrt auch von ASC als ASC-Fahrt erkannt wird oder umgekehrt? Nur so kann ich das für mich vernünftig bewerten.

[marvin78]

Das hört sich für mich bekannt an. Hast du schon folgendes getestet

Code Auswählen Erweitern

{ ascAPIget('LastDrive','<Device>') }
Daran konnten wir erkennen das es intern richtig verarbeitet wird, im Reading aber nicht angezeigt. CoolTux konnte es dann fixen. Zumindest in meinem Fall.

Danke. Das hatte ich schon probiert und es liefert auch manual. Dabei fahren diese Jalousien NIE manuell.

[marvin78]

Es wird im Übrigen die Zeit sein. Wie ich festgestellt habe, klappt es korrekt bei der einen Jalousie, die von 12 auf 0 läuft (weil sie tagsüber nicht ganz auf geht wegen Sichtschutz. Diese habe ich erst heute ASC hinzugefügt, deshalb hatte ich die noch nicht auf dem Plan). Das geht natürlich schnell.

Bleibt die Frage: Welche Zeit ist denn hier maßgeblich? Kann man das überhaupt beeinflussen oder muss man bei langsam laufenden Geräten damit leben, weil es hardcodiert ist. Wenn ja, wo finde ich das ggf.?

[Beta-User]

1. Das Ziel muss passen
2. Es darf nicht zu spät _getriggert_ werden (also default <60 Sek. nach Anweisung bzw. später wie "jetzt+up-Zeit"). Dabei kann auch nicht gesetztes "event-on-change.*" das Problem sein. Hatten wir ständig bei den Shelly, dieses Thema. Dauernde trigger ohne Änderung => zu spät => manual.

Es ist auch nicht "hartcodiert". Es gibt einen änderbaren default.

[marvin78]

Das Ziel passt (wenn die Beschreibung von dir oben stimmt, wie es passen muss). Wie die FHEM Grundfunktionen funktionieren, weiß ich, wann Events kommen auch. Das habe ich ganz sicher im Griff.

Also ist die Antwort auf meine Frage (die ich schon weit oben gestellt habe): Die Zeit die für das setzen von manual oder eben nicht gilt, ist <60 oder (wenn gesetzt)<"ASC_DriveUpMaxDuration"?

Darauf kam bisher keine eindeutige Antwort. In der Doku steht ja nun nicht wirklich, was dieses Attribut nun macht. Falsch benannt ist es in dem Fall auch.

[CoolTux]

Das Ziel passt (wenn die Beschreibung von dir oben stimmt, wie es passen muss). Wie die FHEM Grundfunktionen funktionieren, weiß ich, wann Events kommen auch. Das habe ich ganz sicher im Griff.

Also ist die Antwort auf meine Frage (die ich schon weit oben gestellt habe): Die Zeit die für das setzen von manual oder eben nicht gilt, ist <60 oder (wenn gesetzt)<"ASC_DriveUpMaxDuration"?

Darauf kam bisher keine eindeutige Antwort. In der Doku steht ja nun nicht wirklich, was dieses Attribut nun macht. Falsch benannt ist es in dem Fall auch.

Bei Fahrten welche von ASC ausgelöst werden wird intern ein Timestamp gesetzt. Ist die erfasste Zeit nach dem triggern des Fahrens (setzen des aktuellen pct Wertes) minus der intern erfasste Timestamp kleiner ASC_DriveUpMaxDuration dann kam die Fahrt von ASC ist der Wert größer kann es nur eine Fahrt nicht von ASC ausgelöst gewesen sein also manual

[marvin78]

Ok. danke. ABER: es erklärt es noch nicht, warum das Reading bei der einen Jalousie auf manual geht, obwohl ich bei exakt 30 Sekunden echten Laufzeit hoch und runter, 65 Sekunden für dieses Attribut eingetragen habe. Ist es sicher, dass das Attribut greift?

Und ja. Bei den Events bin ich mir sicher. Die kommen von der HMCCU schomal was später aber nicht 35 Sekunden später. Und es gibt auch keine nachträglichen Trigger. event-on-change-reading ist gesetzt.

Also kann es aber doch am Reading liegen, dass den aktuellen Stand enthält. Wenn dort 0 als Event kommt, im Attribut ASC_Closed_Pos aber 0:0 steht stimmt es ja nicht überein und es wird manual geschrieben? Kann das sein? Oben schrieb Beta-User ja, dass nur der Wert vor dem Doppelpunkt relevant wäre. Stimmt das so?

[marvin78]

Ok. Wir schließen das ab. So wichtig ist das eigentlich gar nicht. Es hat mich nur gewundert und dann gefuchst, dass dieses Attribut nicht richtig dokumentiert und dann (aus meiner Sicht) missverständlich benannt ist. Der Fahrgrund ist hier aber tatsächlich am Ende gar nicht so wichtig. Wie gesagt, fahren die nie (maximal 1-2 mal im Jahr) manuell, sodass man das Reading auch vernachlässigen kann.

Ggf. trotzdem der Vorschlag, die Doku dieses sehr umfangreichen Moduls nochmal anzuschauen. Es ist sicher sehr viel in den Forenthreads versteckt, welche auch über die Suche (nach diesem Attribut habe ich viel und lange gesucht) nicht wirklich gut zu durchforsten sind.

Danke für die Zeit!