Processing Priority

Posted on
Wed Sep 23, 2015 8:00 am
brian.vanheesch offline
Posts: 17
Joined: May 05, 2014

Processing Priority

This feature request is 2-fold and I'm not exact sure on the best way to configure each:

1) Set priority on the order by which triggers are executed. For example, a certain situation cause multiple triggers. Sometimes, you want to certain triggers to execute first. Correct me if I am wrong here: but the "state" of the devices is captured at condition confirmation time and provided to all matching triggers? Or will the results (the changes it makes to the system) of the first trigger be provided as input to the second executed trigger?

2) Set priority on execution to the modem (e.g. Instead PowerLinc Modem). Many times, when multiple triggers and schedules invoke at the or near the same time; there is queue for processing. I would like to assign higher priority to the "turns lights on when I enter the room" and lower priority to "turn lights off when no motion in the room". So often; a timeout failure (no-acknowledgement) causes a lag of 10-15 seconds. This translates into lights turning on and off in rapid succession, once the timeout is cleared. Furthermore, some triggers/schedules are "activity intense"; hitting many devices (such as disabling the security system -- which in part will turn off all the random lighting that was on). When a failure occurs; all of the device changes queue and wait for an unreasonable amount of time.


What is considered a "large" deployment? I have > 200 insteon devices on the power network. What are some recommendations for reducing timeout-failures? All I can do is relink periodically; but quite honestly, relinking 50 motion sensors is a pain.

Posted on
Wed Sep 23, 2015 11:04 am
howartp offline
Posts: 4559
Joined: Jan 09, 2014
Location: West Yorkshire, UK

Re: Processing Priority

Hi Brian.

I'm not Insteon, but in general Indigo terms:

1) Correct, state is evaluated at condition execution. You can call a trigger in an action group - so would adding the second trigger at the end of the first triggers actions help?

2) This should be doable by delays in your actions.

3) Pass

Can you give examples of your multiple triggers in case there's a better way of approaching them that you haven't come across?


Sent from my iPhone using Tapatalk

Posted on
Wed Sep 23, 2015 4:13 pm
brian.vanheesch offline
Posts: 17
Joined: May 05, 2014

Re: Processing Priority

I have motion sensors in every room (at least one but most rooms have 2 or more). Here is a breakdown of my system:

- 24x hue
- 14x sonos
- 3x I/O lin
- 3x meter sensors
- 69x switches (various type: remotes, scenes, dimmer, switch, lamplinc, etc)
- 8x door sensors
- 56x motion sensors
- 8x leak sensors
+ miscellaneous devices such as growl, weather, plex, cameras, iTunes,

And other items:
- 73x device groups
- 35x timers
- 548x triggers
- 111x schedules
- 159x action groups
- 519x variables
- 24x pages

So, inevitably, there will be queue of commands to be sent/received via the Insteon powerlinc to the network. Tweaking delays is not a viable solution, as it only defers the problem. I, recently, upgraded my hardware to a brand new minimac with 8GB RAM; but this did not solve any problems. If anything it has made it worse as the it processes the trigger much faster. I have moved the minimac and powerlinc to various "branches" of the power network; no change.

The only thing I can think of is to prioritize inbound/outbound commands. There are a list of triggers and actions that I absolutely want to execute when the trigger fires. There are many that I don't care if the commands are executed 1, 2, 5 or even 10 seconds after the trigger has been fired. Even a "wait until interface is not busy" is an option, that I can work with.

What is really driving this investigation is several timeout problems (no-ack) that I have been experiencing with critical triggers like "turn off alarm siren"; thus causing the siren to not turn off! From the logs, I can see latency between firing of the trigger and execution of the associated commands.

Because the system does not have "guaranteed delivery of the commands" (and I understand why it does not); I have a series of "checkup" schedules to run and re-verify that what SHOULD have happened ACTUALLY happened. For example, if the kitchen lights do not turn off when no motion trigger is fired; then within 10 minutes, a schedule will fire to reverify the situation and correct as required.

Posted on
Wed Sep 23, 2015 4:19 pm
brian.vanheesch offline
Posts: 17
Joined: May 05, 2014

Re: Processing Priority

A big reason for multiple triggers is because there is no conditions on individual items within action list. So the choice is:

1) multiple triggers with slightly different conditions

or

2) one trigger with a complex python script (instead of the point/click action interface).

Posted on
Wed Sep 23, 2015 6:01 pm
jay (support) offline
Site Admin
User avatar
Posts: 18200
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Processing Priority

Hi Brian - unfortunately, what you're seeing is a significant weakness in the Insteon protocol as those networks become larger (nothing to do with the speed of the Mac). Insteon doesn't handle signal collisions well at all (multiple devices trying to transmit at the same time), and with all the devices you have trying to broadcast at the same time you're going to be getting a lot of collisions (periodically probably storms of them). Prioritization isn't going to help significantly, because you never really know when one of the sensor devices (motion, leak, door, etc.) is going to try to broadcast. Another contributing factor with Insteon is it's speed - as you see, when it tries to recover it can slow down rather quickly. Your checkup schedules that periodically do status update requests aren't helping either - just adding more Insteon traffic to an already overloaded network.

We've had some good results testing Z-Wave devices when trying to overload the network - it's much faster and much better at recovering from issues. Our general recommendation is to use Z-Wave for sensor devices and thermostats (which broadcast relatively regularly and at more random times) and Insteon for switches, keypads, and plugin modules (where direct linking is useful). I know that doesn't really help you since you have a significant investment in Insteon sensors, just relaying what we've found.

It's also not really feasible to try to prioritize queueing Insteon commands to the PowerLinc in any other order than a standard FIFO queue. That kind of logic will very quickly become unmanageable from both a development and user perspective. Adding logic and UI to enable prioritization of identically defined triggers (in terms of firing events) is not something I think we want to do because it adds end-user complexity just to satisfy a very small demand (for which there is already a solution, though not point and click). Allowing different conditions to be specified for different groups of actions might be something we look into in the future, but again we have to balance what real user demand is vs adding what might be relatively unused complexity. But mostly, because of the very advanced nature of the use-case, we think implementing some logic in Python is a good solution and a good compromise.

And as for your example of:

"turns lights on when I enter the room" and lower priority to "turn lights off when no motion in the room"


That's problematic because Indigo will not get them at the same time (they are two different signals and two different firing events): it will first get the signal from the PowerLinc that one of those events happens, and Indigo will then start the trigger working, then we'll get the next one, and start that trigger working. There is no way we can wait to start the first trigger because we don't know what's going to come off the PowerLinc next.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Sep 23, 2015 6:44 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: Processing Priority

If you have a handful of modules that need to be really high priority (siren, for example), then you could change those over to Z-Wave modules and use just Z-Wave as your priority queue. The different protocols are handled independently, so regardless of where in your action lists the Z-Wave commands are they will go out as soon as the Z-Wave interface (Z-Stick) is ready for them.

Image

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 4 guests