I recently posted
an issue where delayed event actions were occasionally not being processed. I.e., an event action (THEN) requests a device action to occur a little later. A little later comes around, and it's as if the delayed action had never been requested at all.
So far, I have had no responses, so I decided to dig a little deeper myself. To start, I created a counter for test purposes only. Then I created a recurring event that does nothing but increment the counter 5 times:
I expected the counter value to increase by 5 every 5 minutes. I was surprised to discover that the counter incremented by 1 every 5 minutes. Suspecting that there might be timing issues (i.e. a race condition) involved, I created another counter to be driven by a new event definition:
Then I set both of these recurring events running. I found that the second event with the interspersed waits was consistently incrementing by 5 every 5 minutes, while the original event was incrementing its counter by only 1 when it ran every 5 minutes. The obvious conclusion: if you try to increment a counter too often (under at least some conditions), not every event action is going to get honored.
So, what are the implications? Call me naive, but I think that if HS3 lets me build an event definition, then it ought to execute that event as written when triggered, subject to external hardware constraints. Alternatively, if that's asking too much, then I think it's critical for HS3 documentation to identify precisely what event action sequences are beyond its ability to perform. (Perhaps that has been done, and I have just not read the appropriate material. If so, I would appreciate a pointer to the information I need.) And if I can't have even that, then will somebody please tell me how I can create a secure system, knowing that HS3 sometimes won't perform event actions, though nobody can say what, or why?
Originally posted by ericg
View Post
So far, I have had no responses, so I decided to dig a little deeper myself. To start, I created a counter for test purposes only. Then I created a recurring event that does nothing but increment the counter 5 times:
I expected the counter value to increase by 5 every 5 minutes. I was surprised to discover that the counter incremented by 1 every 5 minutes. Suspecting that there might be timing issues (i.e. a race condition) involved, I created another counter to be driven by a new event definition:
Then I set both of these recurring events running. I found that the second event with the interspersed waits was consistently incrementing by 5 every 5 minutes, while the original event was incrementing its counter by only 1 when it ran every 5 minutes. The obvious conclusion: if you try to increment a counter too often (under at least some conditions), not every event action is going to get honored.
So, what are the implications? Call me naive, but I think that if HS3 lets me build an event definition, then it ought to execute that event as written when triggered, subject to external hardware constraints. Alternatively, if that's asking too much, then I think it's critical for HS3 documentation to identify precisely what event action sequences are beyond its ability to perform. (Perhaps that has been done, and I have just not read the appropriate material. If so, I would appreciate a pointer to the information I need.) And if I can't have even that, then will somebody please tell me how I can create a secure system, knowing that HS3 sometimes won't perform event actions, though nobody can say what, or why?
Comment