Tja, schlechte Nachrichten: Weder Du noch ich haben endgültig Recht. Ich habe mal zwei Programme erstellt, die eigentlich nur bei Änderung des Zustandes einen Output (hier ein Protokolleintrag durch eine auf Systemvariable, bei der protokollieren aktiviert ist) erzeugen sollen. Und genau das tun sie. Die Statuswechsel im Abstand weniger Sekunden waren manuell, damit das Programm mal einen Protokolleintrag schreibt. Kein (auch nur einmaliges) Nachtriggern. Ich hätte ggf. ein Weitertriggern bei Statusaktualisierung erwartet. Tut's aber nicht. Möglicherweise ist auch mein Testaufbau (nur ein TFK für verdeckte Montage, der im ca. 45 Minuten-Takt seinen Status aktualisiert) nicht repräsentativ. Ich muss es mal um eine zusätzliche Prüfroutine erweitern (irgenein Wert, der statisch ist). Hier erst mal die Screenshots, die sich auch so verhalten, wie es im Handbuch hinterlegt ist.
Das erste Programm ohne zweiten gegensätzlichen Trigger. Der Zeitstempel der Programms wird im Zyklustakt der Statusmeldungen des TFK aktualisiert.
Und das zweite Programm mit dem gleichen Trigger aber gegensätzlichem Status. Auch hier wird der Zeitstempel im Zyklustakt aktualisiert.
So, und nun mach was draus. Daraus folgt, entweder bildet diese Testkonstellation keinen brauchbare Struktur ab oder es liegt an zusätzlichen Triggern und Prüfroutinen. Getestet wurde auf einer CCU2 mit Firmware 2.53.27. Heute gerade frisch aufgespielt (allerdings ist dort auch CUxD installiert, weil ich einige Funktionen davon nutze) und der HmIP-SWDO-I ist auch heute zu Testzwecken frisch aus meinem Hauptsystem abgelernt worden und an der CCU2 angelernt worden. Mach was draus. Vielleicht komme ich morgen zum Testen mit zusätzlichen Prüfbedingungen. Da muss ich mir erst was ausdenken, weil ich keine freien HM-Geräte mehr habe. Mal sehen, ob ich was freischaufeln kann.
Gruß Xel66