Moderator: Co-Administratoren
Jetzt wo du es schreibst …Ist für mich auch logisch, denn die Triggerbedingung "bei Änderung", die das Programm startet, gilt sowohl für "ein" als auch "aus".
???wann und in welchem Schedule laufen überhaupt HM Programme?
Vermutlich von dem ganzen Funkchaos …das wär jetzt eine Mammutaufgabe um rauszufinden, wo die herkommen.
Das System ist ereignisgetriggert konzipiert. Heißt, es gibt ein Ereignis und die mit diesem Ereignis (Tastendruck, Grenzwertüber/-unterschreitung, Zeitpunkt, Statuswechsel) verknüpften Aktionen werden durchgeführt, bzw. wenn es noch zusätzliche Bedingungen gibt (UND/ODER), werden diese ebenfalls noch bei der Bedingungsprüfung mit berücksichtigt. Es gibt keinen Scheduler. Darum sind eben auch für manuelle Betätigungen die Direktverknüpfungen vorzuziehen, da hierbei die Reaktion prompter ist und eher der menschlichen Erwartung entspricht.
).
Ja.
Nein, die CCU arbeitet bei Bedingungsprüfungen ausschließlich mit in der CCU bereits bekannten Status und fragt aktiv keine weiteren ab.
Kommt auf den Betrachtungswinkel an. Meiner Meinung nach nicht. Wenn man in einem Script den .State()-Datenpunkt eines netzversorgten HM-Gerätes prüft, dann wird dieser aktiv abgefragt (sprich, man kann sich das System auch damit vorzüglich auf den Bauch legen, ohne auch nur eine Aktion auszuführen). Bei Prüfung auf .Value() wird so wie auch bei der normalen Bedingungsprüfung per Programm mit dem auf der CCU hinterlegten Status gearbeitet. Und dieser wird ja durch das Gerät selbst entweder beim Ausführen von Aktionen und/oder per zyklischer Statusmeldung gesetzt, und sollte demnach dem realen Status entsprechen (wenn keine Kommunikationsstörungen vorhanden sind). Es gibt einige batterieversorgte Aktoren, die man auch per .State() ansprechen kann. Häufig wird dabei noch geburstet (Burst = Aufwecktelegramme mit "Überlänge"), was dann den Duty Cycle massiv treiben kann.
