Tuning your apps for speed and reliability

🛎️ Get Help
, ,
1

I thought I would share a tip i have learned. I have an all Zwave, 90ish device network and 2 years on HE. Insanely cool product and people. Anyway the tip is this; any RE rule that has more than one trigger, in particular motion, put a latch in the rule using the same rules Private Boolean. First line is always a Conditional test for true and, if true then exit rule.

At the end of the rule set the private boolean for this rule false, delay 1 minute.

The objective is to stop the same rule from being fired multiple times by multiple triggers. It fires the first one it sees then ignores repeat triggers for 1 minute. With Zwave RGB bulbs in particular (they are a PITA) the packet chatter is horrible. I sniff the Zwave net with the Zwave Toolbox sniffer.

The bandwidth and latency issues I chased for years went away. It is not a processor issue, it is a tiny pipe and tiny throughput issue - by design to save power on the battery devices.

By firing the rule only on the first trigger (again in particular if you have an RGB bulb involved) the chatter is cut down enormously, and the network throughput is lightening fast - consistently.

Added tip on Zwave RBG bulbs; leave them on. Pick a color like white and set the dimmer to 1%. It takes fewer packets and less time for the bulb to respond if it does not have to handshake on / off power in addition to color, level, temp packets with the hub. Set to 1% and you cant see it, then change to the color and level you need when you need it, then back again. Makes the PITA bulbs that are 75% communications error packets anyway cut down the amount of noise on the network significantly.

This and "throttling" using the latch technique above made my network bullet proof and lightening fast. I have spent a stoopid amount of hours chasing rabbits (i.e., thinking devices were defective, zwave repair, etc.) when it was just this.

It would be so cool to have a utility like Windows Device Manager to see what rules are eating up the most time to help lean up problem RE rules up faster. Save service $$

Love the product and the direction. jj

4 Likes
2

Great recommendations!

If I may ask - what are you using to do this? I have a UZB device on my PC and would love it if I could figure out when my network gets saturated...

3

You treat it like adding a zwave device. Start inclusion then "connect network" on the toolbox to establish inclusion, a generic device is created - call it toolbox and save it. you only have to do this once to add to your network in HE.

2 Likes
4

Thanks! They certainly don’t give it away... But it does seem like something that could be useful to have! I was hoping it would be a software solution to go with the UZB stick...

5

it is an excellent tool, i lean on it heavily. worth every dime. lots of tools built in but packet trace is what i sue the most. ideally, i want to see long periods (several seconds to even a couple of minutes) of silence in the traces to know it is fine tuned. the tool is the only way to quickly pinpoint issues that eat up bandwidth, you will see very distinct patterns forming around noisy rules. Anyhow i had to share this. Hundreds of hours chasing the wrong thing. if you open the trace the first time and just see continuous non-stop packets then you just got your investment out of the tool. If it is constantly busy you have apps to go lean up badly and until you do your throughput will be very inconsistent. Sometimes instant, sometimes many seconds. If you are seeing wild variances in performance routinely this is very likely the culprit. start throttling rules that run often in particular if the trigger is one or more motion sensor. Multiple triggers you are going to see duplicate triggers choking the pipe up, throttling by using a one-shot that times out to fend of repeat triggers i use on all my busy rules - lightening fast 24x7. Sub second response times all the time, no more "hide, wait and hope it works".

2 Likes
6

Unless you add additional z-wave devices after adding the Z-wave Toolbox. In which case, the only way to refresh the list of devices seen by the toolbox is to exclude it and re-include it.

At least I haven't found any other way ....

7

I dont use the testers so i didnt know about the issue you describe - great tip if i need to use the testers. i really only bought it to be a snifffer, didnt care about the device testers. great tip though thank you jj

8

Can you post a picture of your rule? I can't seem to figure this out

9

its a habit to form, like learning to always add cancel delayed events. Like me learning the hard way then formed habits. I always start a rule if i have delays in the rule with Cancel Delayed Actions as the first statement just to get it out of the way and make it obvious.

Like that add this process to writing a rule that could have a tendency to be traffic heavy, in particular when the rule has many triggers. I have one area outside with three motions 30 feet apart. it is simple to hit all three, they all trigger the same rule, this rule is a monster that has lots of RGB in it (RGB colors indoors in the den indicate back yard, front door, garage presence). If all three motions hit the same rule in seconds a have 1500 packets of data to sequence through at slow speed and presto - my app throughput blows. Putting in a one shot fixed that for me.

Like i got into the habit of adding Cancel Delayed events when i start a new rule i know could load up the networks:

  1. do a conditional; if Private boolean for this rule is true, then exit rule, else set private boolean for this rule true. This will stop the next device from firing the same rule again for a hold period you choose.
  2. End the rule last line; Set private boolean for this rule false, delay 1 minute.
    Set the delay for how long you want HE to ignore more triggers for this rule.

Tip: As a precaution is always have a rule called "critical things". One-off stuff to double check. I have this rule run once a minute. When it runs i have it take all the rules i have that use throttling and have rule "Check Critical Things" as a safeguard. It resets them all to false to none can get hung, My throttle time is always a minute so this worked out well. Good luck and merry Christmas. jj

3 Likes
10

long answer to a short question - that clear it up for you? jj

11

The tip on ZWAVE RGB bulbs is good too. Leave them in "standby" when not in sleep mode. picka color like white and a level of 1%. you cant see it. Whe you need you just need to change color and level. Much faster, reliable and best of a the PITA bulbs generate more packet traffic than anything and 75% of the messages are errors. Leaving them on saves 50% of the handshakes you need to just turn on / off and verify. instant on this way too. Common - its an led, 1 cent a year to leave them on during the day. hope this helps others scratching whats left of their hair - i aint the device 99.9% of the time it is a log jam waiting for messages killing performance. 90 devices, sub second response 24x7. enjoy and have a safe and prosperous 2021..

12

I need a boolean logic for dummies. I can't wrap my head around your suggestion but do understand how it would help.
Where in here would I add the private boolean

image
image1547×746 26.7 KB

Thank You

13

image
image1920×1080 146 KB

Good example is this one.

1.many motion sensors can trigger. thus the problem, you could walk in 10 seconds and have triggered this rule 4 times back to back and blitz the network with redundant noise bogging down throughput.

  1. look now at actions. first statement is check for the boolean for this rule to be true. if so - exit. in this way the first device to trigger locks out repeat requests for the same thing and the packet noise that goes with it.

  2. if it is false the the rule action proceeds the first thing then is to make the private boolean for this rule true to shut out repeats. One shot, clean simple and with 1/4 the packet load.

  3. last line in the rule is to set the private boolean to false after one minute to let things settle down.

  4. get into this habit where a rule can get triggered multiple ways or if it is a rule that is a main rule that works hard and frequently.

  5. you will see a remarkable difference in speed and reliability. Ex - devices that should go on instantly taking seconds, in particular RGB bulbs. 75% of the packet traffic and HE are unrecognized command errors. RGB's are bandwidth hogs, bad.

1 Like
14

Awesome, took some clicking but I think I figured it out, but can't get light to come on. I probably made a stupid mistake. Can you take a look?
Thanks

image
image1579×866 30.2 KB

15

You need to start with the Private Boolean being set to "False" otherwise your rule never makes it past the first IF statement. If it starts as false then each time the rule runs it will only be true for 1 minute and during this minute the rule won't make it past the first IF.

If the rule is originally created with the Private Boolean set to False and each time the rule runs all the actions execute (especially the action that is delayed by 1 minute that sets the private boolean to false) then the rule should be ready to execute actions past the first IF statement after 1 minute has passed since the rule was last run. But what happens if for some reason that delayed action that sets the Private Boolean to false doesn't happen, the original poster suggested doing this to alleviate that possibility:

16

Stephan.J nailed it. It must always start with the private boolean as false to work, the whole point is to let the first trigger fire the actions, then block any repeat triggers for one minute so the rule has plenty of time to negotiate all the handshakes and settle down before a new trigger can fire the actions again - a purposeful throttle. A "Critical things " rule just ensures HE does not allow a private boolean to remain in true for more than one minute as a back stop check to ensure the delay to turn the PB back to false was done correctly and not stuck - it happens, rare, but it happens.

17

As written Stephan is correct, your rule will not work, it will never get past the PB as true and exit. Two solutions; As i do with a "centralized" rule called Critical Things, have a 'maintenance' rule that fires once a minute to do no heavy lifting, just check key register values to keep the wheels turning is one gets stuck. You can create a maintenance rule (like I do with my Critical Things rule) that sets one or more rules PB to false every one minute, then after a minute this routine as written will work. The simple option is to take your set PB false statement you have at the end of your rule, and make it the first statement. The first time the rule triggers if the PB is true (BTW, HE makes the default True so like Stephan said you have to have something that will not allow it to stick in true) in one minute the PB will be set false and the routine will then begin to work properly afterwards. I would suggest doing this to keep things simple before writing a maintenance rule. jj

1 Like
18

to be clear; take your last statement and move it up to the first statement. Set the PB false in 1 minute being the first thing the rule sees - the first time it triggers if the PB is true the routine will not work, but in one minute the PB will be set to false and subsequent triggers will stay in sync. Make your last statement (set PB false in one minute) the first statement and after the first cycle it will stay in sync on it own - simple is good. j

2 Likes
19

Everything you have posted sounds like great advice. somehow this post should become required reading!

Thanx

1 Like
20

I took this a bot further since the original post.
In all of my apps that i want to throttle, i deleted from the rule changing the rules private boolean itself. The rule still latches after a trigger by turning its own PB true (remember the point is the opening rule argument is a conditional that exits the rule if the PB is true - the latch / throttle mechanism). I have a "centralized rule" called 'critical things' that triggers every 5 minutes. it is in this rule that i set the PB false in all the rules i am using throttling. one place, like a global variable, to centrally manage the cadence system wide for throttling. Found this to be more reliable (like 100%) than rules using delay to reset their own PB (they get stuck from time to time using delayed set false in the rule itself - no idea, just happens on occasion and annoying. Having the external rule set the PB outside the rule works 100% flawless.
Pick of Critical Things:

image
image1920×1080 127 KB