What a KISS threshold might look like.. (I am sooo sorry but couldnt resist)
7 Likes
Inspired by our Fearless Leader 
and his exhortation to not throw trigger information away, I just simplified my "Generator active" rule (wait and retest the acceleration sensor to make sure it's not a false trigger, then set a virtual device to match the condition) from this:
Trigger: Generator sensor CHANGED
IF (~ Generator sensor inactive(T) [TRUE]) THEN
Cancel Delayed Actions
inactive() on Generator virtual sensor
ELSE
Delay 0:00:10 (cancelable)
IF (~ Generator sensor active(F) [FALSE]) THEN
active() on Generator virtual sensor
END-IF
END-IF
to this:
Trigger: Generator sensor ACTIVE
Delay 0:00:10
IF (~ Generator sensor active(F) [FALSE]) THEN
active() on Generator virtual sensor
Wait for condition: ~ Generator sensor inactive TRUE
inactive() on Generator virtual sensor
END-IF
Thanks, Bruce!
2 Likes
The kiss threshold makes sense. As Bruce said, the device isn't a super computer, or better yet a full blown PC. So thought needs to go into each rule creation, and trying to maximize the hardware built into hubitat.
I still feel if Hubitat released something faster and we still focused our efforts on maximizing and rethinking our rules, we could get better response times.
My thought at this time based off previous conversations with other people is that I've pushed past the limitations of what I can expect from hubitat.
For example, I have several motion lighting rules that have many conditions it needs to check before running the action. The response times for most is fine, but I'm damn picky and want 100ms for my motion lighting.
This is by no means to start an arguement. Hubitat is a great device! I'm just damn picky!
1 Like
Another issue that I thought of that I ran into is polling. I tried polling a bunch of older Z-Wave switches. That seemed to really bog things down. Now I only poll a switch if I absolutely need to and only every two minutes or so. Currently that is only three switches right now. Technically I use HubConnect so I am actually refreshing them.
Along the lines of KISS, a question for @bravenel -
When waiting for something, I've often got two choices:
Wait for events: Generator sensor inactive
or
Wait for condition: Generator sensor inactive
From a resource-usage standpoint, is either choice preferable?
Use event when possible, and condition only when you need it. For example, to wait for All of multiple devices to do something, you would need a condition, but to wait for Any you could do with an event.
7 Likes
I just did the same thing after watching this! I don't really press those buttons manually, so it made sense to turn the polling off.
1 Like
I have used devices that utilized much speedier processors (i.e., PC class) and it seems that UARTs, Zigbee and Z-wave were often the bottlenecks. That's not to say that the processor didn't make a difference, it just didn't make that much of a difference.
2 Likes
I watched the replay on Youtube. Very informative. Admiral Grace Hopper would be proud. 
You could drop the IF statements I would think, no?
The trigger executes because the generator sensor became Active. So there shouldn't be a reason to re-check if it's active again.
The "Delay" and "If" are because I was getting false positives from the vibration sensor. I blame the squirrels. 
Doing the second check makes sure the generator's actually running.
1 Like
@bravenel Bruce - In the spirit of KISS I’ve taken your suggestion to get rid of “changed” triggers to heart. I’ve started changing these triggers to trigger on the on or off event instead and then wait for the other event. However, I’ve got one question. How resilient is this methodology to a hub restart? If the rule is waiting for the next event to occur and the hub is restarted, will the rule go back to the same state of waiting for the next event, or will the rule “reset” itself and go back to waiting for the initial trigger again?
Rebooting the hub shouldn't matter unless the Wait event would happen while that was happening (time for example).
This is easy to test, just try it.
1 Like
Thanks for e quick reply. I was hoping that would be the answer 
I’ve given it a go before to test it but I thought I didn’t get consistent results from my testing. It could well have been that the event it was waiting for occurred during the reboot though. Thanks for clarifying!
If it is a device event, the rule creates a subscription to that event. Two things could cancel that subscription: the rule triggering again or the event occurring, fulfilling the Wait.
1 Like
So in the spirit of this I have been looking at my rules to try and simplify. This is one I changed but I am starting to wonder if it would be better flipped around to trigger on the open and wait for the close?
I reckon it’s better the other way around (trigger on open). As it is now, the rule is going to spend most of its life midway through, waiting for the open event. Not that there is anything wrong with that, I would just personally write the rules so that they finish as quickly as possible (I perceive there being a higher chance of failure the longer something runs, rightly or wrongly).
I would suggest that you trigger on open. Your rule would then look like:
Cancel delayed actions
Cancel any waits (just for good measure. There is a very low probability that the rule would ever get itself in to a state when this would be required)
Wait for event door closed
Delay actions 5 minutes
IF auto-lock on {
Lock door
}
I would put the wait before the IF just in case the state of the auto-lock changes during the 5 minute wait period.
I hadn't considered this before. I use automation switches to turn off different automation depending on if we have guest or I have people here cleaning/doing work. This is making me think about how they work and as you point out what happens if I were to turn them off during the delay.
1 Like
