13.05.2021, 12:02
(This post was last modified: 13.05.2021, 12:28 by Erwin van der Zwart.)
For the scheduler you can also use a virtual object, for example 31/1/0 and the script is attached to this bit object.
When the scheduler changes state it triggers the script, the script will fetch all virtual objects that you have created with the TAG ‘Input’ and itterates over all these objects, when the value is ‘true’ (enabled load in your visu) it will write the scheduler value to the normal object. So is 32/x/x is enabled it writes the scheduler value to 1/x/x
See this small recording:
Recording.zip (Size: 1.61 MB / Downloads: 25)
It is also possible without script, create in the ETS your addresses for the toggles and use the blocking object of the actuator channel, this way you can write to all channels from the scheduler and when the blocking is active it won’t respond on the scheduler. I would do it like that as i aways use as much as possible in the KNX devices itself and as less possible in a central controller.
In this scenario you are already depending on the controller as the scheduler is hosted there so if the controller is not available it would not work either so single point of failure is the same however it reduces your KNX traffic as script sends to each channel separate and when using the blocking object you only send 1 telegram from the scheduler…
When the scheduler changes state it triggers the script, the script will fetch all virtual objects that you have created with the TAG ‘Input’ and itterates over all these objects, when the value is ‘true’ (enabled load in your visu) it will write the scheduler value to the normal object. So is 32/x/x is enabled it writes the scheduler value to 1/x/x
See this small recording:
Recording.zip (Size: 1.61 MB / Downloads: 25)It is also possible without script, create in the ETS your addresses for the toggles and use the blocking object of the actuator channel, this way you can write to all channels from the scheduler and when the blocking is active it won’t respond on the scheduler. I would do it like that as i aways use as much as possible in the KNX devices itself and as less possible in a central controller.
In this scenario you are already depending on the controller as the scheduler is hosted there so if the controller is not available it would not work either so single point of failure is the same however it reduces your KNX traffic as script sends to each channel separate and when using the blocking object you only send 1 telegram from the scheduler…