Limit on trigger usage?

[larryllix]

I have many motion sensors reporting to my ISY. About 9 - X10 units and two Insteon units, so far.

 

Originally when I required a MS trigger to accomplish multiple tasks I would jump around programs in different folders but the code got very hard to keep track of who was calling what when editing a downstream program used as a subroutine.

 

Later I began to use the triggers multiple times in various folders for different styles of applications but now I am noticing that some of the applications don't seem to run even with multiple manual stimulations of MS units. This may be only the X10 units doing this. I am not sure if this happens on the Insteon units.

 

I have typically used an entrance "Wait 1-2 seconds" on programs with MS triggers that do not require a quick lamp on response etc.. in order to theoretically avoid some CPU cycle hogging of the event processing engine. I am not sure whether that is a valid logic or not but I find some events triggered by shared MS signals just don't ever get processed or get processed what seems like 2-5 seconds later. Is there some consideration of just bogging the ISY CPU down? Since the ISY Pro version can handle 1000 programs and I only have about 50-70 programs so far I didn't think I would be bogging down the real time engine yet.

[Xathros]

Larry-

 

Are you sure the triggers are being missed? Check the last run time of suspect programs to be sure. I feel it is more likely that the resulting activity from the triggered programs may be preventing or delaying the result of some of the triggers rather than the triggers being missed. Insteon activity will queue up and take priority over a number of other things. This may result in the appearance of some programs not being triggered.

 

-Xathros

[larryllix]

Larry-

 

Are you sure the triggers are being missed? Check the last run time of suspect programs to be sure. I feel it is more likely that the resulting activity from the triggered programs may be preventing or delaying the result of some of the triggers rather than the triggers being missed. Insteon activity will queue up and take priority over a number of other things. This may result in the appearance of some programs not being triggered.

 

-Xathros

Thanks for your ideas. I will have to investigate further before I get too rowdy changing all my programs to a folder disabling method. I do not prefer that method.

 

I did run a few tests to see what was happening and two other programs ran fine and the one that sends notices didn't. This happened on 75% of the trials I tested. Thus my conclusion there may be a trigger table limit for each device or some other limitation in the software engine.

 

I shall have to set up a side set of programs to experiment more thoroughly with this. SWMBO gets a little irate when the lights keep going on and off. It shows I have control.

[larryllix]

I have discovered one thing regarding this so far:

 

Notifications without any body text do NOT get sent! Since the event viewer (level 3) does not indicate any notification activity it cannot be concluded who isn't processing the blank notifications. Neither emails or SMS messages get processed.

 

Here is the event without body text.

Sat 06/14/2014 11:29:12 AM : [ Time] 11:29:16 0(0)

 

Here is the event with a single period for body text

Sat 06/14/2014 11:30:28 AM : [ Time] 11:30:29 0(0)

 

Note: Regardless of how many lines of SMS and/or email notifications are sent the event viewer indicates the same [ time] line only.

[LeeG]

The requirement that Notify have Subject and Body has been noted by UDI in various topics.