Request - ISY program priority processing option

[larryllix]

In view of the current Insteon MS II disappointments and the seemingly inevitable ISY translation of signals from one protocol to another, priority processing option would be an awesome thing.

This could consist of a two level (or more) priority handling option, perhaps with some maximum number of flagged programs and could entail  priority handling on the process stack as well as I/O queue skipping. Obviously if a user flagged every program noting would be gained.

Hopefully a system like this could alleviate some of the MS ---> lighting delays that may plague the ISY system as some other protocols live with. There may be other high speed priority applications that could benefit also.

[Michel Kohanim]

@larryllix,

Excellent idea alas I will have to refer you back to your logo ... we are still trying to walk!

With kind regards,
Michel

[gviliunas]

To add a little more to the discussion, the thing that drives me crazy is the variability in response times that I see with programs.

My front door is a busy place. I have a Homeseer WD200+ (Z-Wave) which both controls the entry way lights and provides an 8-LED status of other doors and windows that may be open. There is also a Triggerlinc to indicate the door position, an August deadbolt lock, and a Gen 5 Aeontech doorbell (Z-Wave) programmed to say "Welcome" or "Goodbye." Finally, there is a Aeontech MS6 motion sensor triggering lights and the current weather via an Alexa Dot.

There are programs that monitor the status of the door position and the entry way light to determine if I am entering or leaving home.  Different programs are run to accommodate those conditions.

Upon thinking I'm leaving (Status of entryway light is ON and then the front door is Open) the programs are prepared to receive a last trigger, the entryway light being switched OFF. This is supposed to  1. Say "Goodbye" via the doorbell.  2. Turn off all of the lights.  3.  Turn down the heat.

The programs always work but the time from pressing lights-off to hearing "Goodbye" can be anywhere from immediately to 5-6 seconds. Why is this time so variable???

Over the past years (okay I'm a little compulsive) of "tinkering" with this part of the system, using the Admin Console, I have verified that the individual switches and sensors have nearly an immediate response by ISY. 

I have also spent many hours trying to reduce this variability through programming. I tried rearranging program lines, using state variables to group pre-conditions together to minimize the number of conditions that need to be tested to trigger the programs. Finally, I tried using folder conditions to limit the number of programs that would be testing their conditions when these conditions changed. All of these changes seem to make a difference (Does ISY cache recent events?) but over time, I noticed the time from pressing lights-off to hearing "Goodbye" can be anywhere from immediately to 5-6 seconds.

I have no solid proof however, at this point, my belief is that my problem of program execution variability is rooted in ISY's program execution priorities. In addition to the "door activities," I have the entry way motion sensor and 10 nodeservers all possibly vying for ISY's attention.

I am sure that if we had full control over ISY's priorities, we could generate some enormous headaches for ourselves and for @Michel Kohanim but with the ever-growing capability and complications of our systems, @larryllix may have a very good future feature suggestion to allow us to somewhat influence ISY's program execution priorities.

......Maybe this whole issue will be gone when ISY moves to the faster Polisy 

[Bumbershoot]

26 minutes ago, gviliunas said:

.....Maybe this whole issue will be gone when ISY moves to the faster Polisy

I don't know how many times my experience has proven this rule.  I'm betting on Polisy...

[Michel Kohanim]

@gviliunas,

The reason for program execution variability is the sequential nature of events in the queue. So, if your queue has 100 events, then ISY will have to process 100 events before it gets to the event that triggers your lights. So, the question is: is there a pattern for when the program execution is slowest? 

With kind regards,
Michel