CUxD Timer unzuverlässig

[AndiN]

Also, der Tippgeber mit dem "Schaltzustand Ein" und "Aktualisierung" war ich und wieso das so ist, wie es ist weiß hier vermutlich keiner.

Ist wie mit dem "EVENT" (war ja die dritte Variante). Sie funktioniert einfach nicht mehr. Da kannst Du philosophieren und spekulieren. Wenn nicht einmal Uwe sich das erklären kann, dann kann das höchstens jemand der sich mit der CCU und der Programmierung auskennt. Aber in all den anderen Beiträgen, die sich auch mit der "unzuverlässigen CuXD Timer Auslösung" beschäftigt haben gab es dazu einen Post.

Andi

[Wortmann30]

Und wenn ich Dich richtig verstanden habe,
dann hast Du Dein CUxD Probleme auch auf diese Weise gelöst....

So ist es.

[zehensocke]

Vielleicht räuspert sich Uwe ja auch mal zu dem Thema "CUxD-Timer" und Zuverlässigkeit,
und kann mir sagen wo ich Bockmist gebaut habe oder wo ich noch suchen kann.

gerd

[uwe111]

Hallo Gerd,

Vielleicht räuspert sich Uwe ja auch mal zu dem Thema "CUxD-Timer" und Zuverlässigkeit,
und kann mir sagen wo ich Bockmist gebaut habe oder wo ich noch suchen kann.

Ich habe bereits alles dazu geschrieben und verstehe den Sinn dieser Diskussion nicht.

Der CUxD sendet beim Ablauf der Timer entsprechende Werte in Datenpunkten zur CCU. Das lässt sich anhand des CCU Systemprotokolls auch prüfen. Auch erneute CUxD-Installationen (der gleichen Version) ändern an diesem Verhalten nichts!

Wenn die Triggerung nicht funktioniert, dann liegt das Problem an der CCU-Logikschicht. Vielleicht laufen ja zu viele Programme gleichzeitig oder etwas in der Art... Bei mir funktioniert es jedenfalls problemlos!

Als Alternative kann der CUxD-Timer aber Befehlszeilen auch direkt aufrufen. Das umgeht die Logikschicht und funktioniert sehr zuverlässig.

Viele Grüße

Uwe

[AndiN]

@Uwe:
nur für mich interessehalber (bin ja nicht der Crack):

Wo ist der Unterschied bei "GET kleiner gleich 0 Aktualisierung" und "Schaltzustand Ein Aktualiserung"? Wenn Timer Get 0 , dann wird doch auch der Schaltzustand EIn gesetzt. Daher verstehe ich nicht warum das eine klappt und das Andere nicht.

Die Schaltzustand Ein löst zuverlässig aus (arbeite mit Skripten und somit bin ich froh, weil die Befehlszeilen Variante für mich nicht in Betracht käme und somit ist es mir persönlich egal. Hauptsache es funzt. Mich interessiert nur (wenn es in einfachen Worten geht) er Unterschied zwischen beiden Varianten.

So, sonnige Grüße

Andi

[uwe111]

Wo ist der Unterschied bei "GET kleiner gleich 0 Aktualisierung" und "Schaltzustand Ein Aktualiserung"? Wenn Timer Get 0 , dann wird doch auch der Schaltzustand EIn gesetzt. Daher verstehe ich nicht warum das eine klappt und das Andere nicht.

Wenn beide Bedingungen gesetzt sind, dann sollte auch in beiden Fällen getriggert werden. Da dies aber scheinbar nicht immer passiert, kann es sich hier nur um einen Fehler in der CCU Logikschicht handeln. Und darauf kann Dir nur eQ3 eine Antwort geben! Da dies aber wahrscheinlich aussichtslos sein wird, habe ich im CUxD mehrere verschiedene Möglichkeiten der Signalisierung integriert.
Dass der CUxD die Events richtig sendet, kann ja jeder im Systemprotokoll der CCU sehen. Für Programmfehler der CCU-Logikschicht gibt es keine logische Erklärung.
Als Alternative kannst Du vom Timer auch direkt Befehlszeilen aufrufen lassen. Das funktioniert zuverlässig und umgeht die CCU-Logikschicht.

Viele Grüße

Uwe

[AndiN]

@Uwe: Danke Dir. Also gibt es wenn überhaupt einen Unterschied in der CCU Logschicht, dass die das nicht versteht.

Wie gesagt: Bei mir läuft es ohne Probleme mit der dritten Variante und den Tipp habe ich hier öfters publiziert und scheinbar klappt das auch dort zuverlässig. Demnach alles gut.

Mit der CMD Zeile ist auch eine Idee. Allerdings habe ich mich so an Skripte und einfache Programme gewöhnt, dass ich doch das "Klickbunti", wie Alchy es immer so schön nennt favorisiere

Andi