warten in Logiken/Plugins

[Cannon]

Sicherlich ist es programmiertechnisch vernünftiger mit Schedulern zu arbeiten. Es gibt aber Situationen, wo die Scheduler einfach zu langsam sind. Beispielsweise dann, wenn man etwas schnell blinken lassen will. Ist es deshalb zulässig auch mit Delay zu arbeiten, ohne, dass dabei etwas hängen bleibt? Um es bildlich zu machen:

    while lContinue and lAnzahl > 0:
        lAnzahl = lAnzahl - 1
        sh.knx.groupwrite(groupAddress, True, knxDpt)
        time.sleep(1/4)
        sh.knx.groupwrite(groupAddress, False, knxDpt)
        time.sleep(1/4)

Wie gesagt, dass ist nur exemplarisch zu sehen. Mich interessiert aber, ob das so realisierbar ist und ob man solche Logiken/Plugins dann auch mehrfach aufrufen kann?

[Tom Bombadil]

Zeit, mal den epischen Satz von Marcus zu zitieren:

time.sleep ist böse!

Nein, im Ernst - sollte für Einzelfälle so realisierbar sein. Ob's schön ist, ist eine andere Frage ...

scnr,
/tom

[Cannon]

Ja hatte ich auch mal so gehört. Deshalb wäre mir die Meinung von denen, die da tiefer in der Programmerung drin stecken wichtig. Vor allem auch, ob dann irgendwas hängt oder ob eine Logik auch mehrfach ausgeführt werden kann. In diesem Fall ist es ja keine Dauerschleife, zumindest sollte es nicht sein, sondern wir reden im Fall eines Falles über wenige Sekunden.

Ich überlege nämlich das auch in ein plugin zu packen, damit man nicht ständig Fehlermeldungen wegen der verwendeten Item-Attribute bekommt.

[Morg]

Der Thread, in dem das sleep() aufgerufen wird, "hängt" dann für die entsprechende Zeit. Ob eine Warteschleife mit sleep, mit while True: pass oder anderen Methoden durchlaufen wird, macht für die Ausführung des aktuellen Threads keinen Unterschied. while True: pass sollte man allerdings nicht nutzen, da dies die CPU auslastet (bzw. den jeweiligen Core). sleep wechselt meist auf den nächsten Thread, so dass die CPU-Zeit nicht "verschenkt" wird.

Wenn du das in einer Logik einsetzt, wird der jeweilige Worker-Thread blockiert; der sollte nach meinem Verständnis aber - in dem Moment - exklusiv der Logik zur Verfügung stehen.

In einem Plugin kannst du mit sleep() möglicherweise den Ablauf des Plugins oder - bei update_item() - sogar den Event-Thread von shng anhalten, da wäre ich mit so etwas vorsichtiger.

[Msinn]

Das problem mit time.sleep ist, dass es den Thread in dem es aufgerufen wird einfach anhält. Wenn das in einer Logik passiert, die selten mal aufgerufen wird, ist das ohne weiteres verschmerzbar.

Allerdings haben sich schon Mehrere ihr system mit time.sleep abgeschossen. Zum Beispiel mit der Verwendung eines (längeren) Sleeps in einer Logik und die Logik wurde durch Items häufig getriggert. Da der erste Thread noch schlief, wurde für das nächste Triggern ein neuer Thread genutzt, etc.. Das ging so weit, bis SamrtHomeNG quasi nur noch aus einer großen Anzahl schlafender Threads bestand.

[Cannon]

Okay, verstehe. Danke an alle.

Mein Verständnis daraus ist, dass man es grundsätzlich einsetzen kann. Man muss sich nur darüber Gedanken machen, wofür und es muss einem bewusst sein, wie lange man das Ganze anhält und wie oft man das Ganze aufruft. Grundsätzlich würde ich das auch nur für zeitkritische Dinge verwenden. Für alles andere kann man ja Scheduler verwenden.

[Morg]

Logiken laufen intern in Schedulern

Und Gedanken machen, wofür man etwas verwendet, sollte man - gerade beim Programmieren - immer tun

Dein Beispiel mit zweimal 1/4 Sekunden Delay ist sicher umsetzbar, wenn das nicht zweimal pro Sekunde getriggert wird.

[Cannon]

[QUOTE=Morg;n1746718]Logiken laufen intern in Schedulern

Ja kalr, aber die Logik wid nicht alle 250 ms getriggert.

Dein Beispiel mit zweimal 1/4 Sekunden Delay ist sicher umsetzbar, wenn das nicht zweimal pro Sekunde getriggert wird.

Hängt davon ab, wie oft ich am Tastsensor drücke. Ich nutze das als Sperre des PM (Langdruck) und das Blinken ist die Signailsierung.

Es ist schade, dass es natürlich in KNX kein Objekt dafür gibt, bzw. dass die Produktdatenbanken der Geräte nicht offen zugänglich sind, dann könnte man das ganz anders lösen.

[Msinn]

Ja kalr, aber die Logik wid nicht alle 250 ms getriggert.

Wer weiss... Das kann man schon hin bekommen.

Hängt davon ab, wie oft ich am Tastsensor drücke.

alle 250ms?

[Morg]

Ich nutze das als Sperre des PM (Langdruck) und das Blinken ist die Signailsierung.

Sowas habe ich auch - wenn das Garagentor auf oder das Gartenwasser an ist, blinken an einigen Tastern die unteren LEDs rot - allerdings nutze ich die Blinkfunktion des Glastasters, "extern" setze ich den Status nur auf 1.

Bietet dein Gerät sowas ggf. auch an?

[Onkelandy]

Ich hab bei mir in Logiken das hier implementiert, ist im Prinzip identisch zu dem oben erwähnten while True.

def _wait(time_lapse):
          time_start = time.time()
          time_end = (time_start + time_lapse)

          while time_end > time.time():
               pass

Bei Logiken hatte ich da nie Probleme. Beim gpio Plugin, wo nur ganz kurz gewartet werden soll, gab es die hohe CPU Last wie von Morg beschrieben. Da konnte ich dann nur time.sleep nutzen.

So eine richtig optimale Lösung für ein bisschen Warten scheint es dann wohl nicht zu geben..?

Wegen Blinken am Taster hätte ich auch empfohlen, mal in die KNX Applikation zu schauen, das sollte eigentlich schon über den Status machbar sein.

[Cannon]

Bietet dein Gerät sowas ggf. auch an?

Leider nicht so richtig. Ich habe die von Berker. Die sind zwar optisch schön und klassisch. Die können sogar blinken, aber man kann das blinken nicht separat steuern, also entweder blinken die immer oder die leuchten immer. Man kann nur zwischen der Lichtfarbe wechseln. Deshalb sagte ich ja, schade, dass man die Applikationssoftware nicht anpassen kann.

[Cannon]

Ich hab bei mir in Logiken das hier implementiert, ist im Prinzip identisch zu dem oben erwähnten while True.

Wozu der Weg mit der Warteschleife? Das ganz macht doch im Ergebnis genau das Gleiche, wie time.sleep() nur mit mehr Code und mehr CPU-Last. Welchen Vorteil bringt das?

[Morg]

Keinen

[Cannon]

Dann wäre doch die Änderung sinnvoller:

def _wait(time_lapse):
          time.sleep(lapse)
          pass

Einziger Vorteil der Funktion wäre aus meiner Sicht, wenn man protokollieren will, wie oft man auf irgendwas wartet. Das könnte man da einbauen. ;-)