Some good points from everybody. Thanks!
Note that my question was about how the logic engines in a controller work. I was not suggesting that polling should be applied to Z-Wave or any other external protocol. Only to the internal registers that track the state of those sensors within the controller. The logic engine should not know or care what kind of communications and validation a protocol is using to set the register values.
Without pretending to have technical skills that in reality I do not. I will just note some observations about interrupt vs polling. Polling in Stargate seems to be more resilient than interrupts in other systems because if a register update is missed it will be caught the next time around (30 milliseconds in the case of my Stargate) while a missed interrupt is just lost. Polling lets you directly interrogate physical inputs instead of relying solely on a device table that could get out of sync with reality. There is no issue with resource contention with polling because the resources needed are constant and do not vary between all devices being idle all the way to all devices change state at the same time.
I did forget about the "status is" option in the ISY. I haven't added any new programs to it since I updated it to version 4.6.2 a couple of years back. As I recall ISY has some other things about the programming that didn't seem intuitive. I recall an example that went something like:
If X is on
AND
If X is not off
THEN....
I don't remember what that was about. There was also something about THEN statements not completing if the trigger became false before all the THEN actions were done. I need to gt back into it once the Polisys comes. Probably after the Holidays the way things are going.
As far as a loop running slower and slower as you add devices, I just don't see that. There are a finite number of memory locations to track hardware state and if clock and processor as designed to to cycle through all of them at the required rate then it would not matter if you max out your system or run it with only one sensor since the cycle would poll every location whether it was in use or not. The cycle time should never change.
I vaguely remember that discussion, I think. It has happened over and over throughout the years.
If
switch is switched On <-----------looks at the signal from the paddle being tapped
AND
switch status is ON <---------- looks at the existing state of the dimmer electronics
Then
At first, it seemed confusing and wasted to me, and I, for one opposed the logic sensibility of it. Once we understand the switched construct comes from the paddle and the status comes from the dimmer electronics, and an Insteon SwitchLinc really is three independent devices, it makes more sense, and is actually a workable consideration.
OTOH: Checking the status of a switch we want on,before turning it on, only saves a redundant ON command going out to an already On switch, and just complicates the readability of the program with a useless line of code.
OTOH:OTOH:
Using the status test in a program with a bad status in ISY (problem with push technology style), could avoid turning a light off for hours/days until a forced query was done and the real status was known.
Afterthought.
The "Not Off" was to circumvent dimmers that may be on at 50%. They are NOT on and they are Not off. Testing ON fails.
Edited by LarrylLix, 16 October 2019 - 06:10 PM.