Curious about what is happening when the sensor is throttled. I have a Reactor Sensor for my Garage that watches 2 garage doors, garage entry door, and a motion sensor and controls the garage lights accordingly. When somebody opens garage entry door, then opens a garage door, then trips motion sensor, the Reactor sensor always shows “Throttled! (high change rate)”. Is this bad? Is it slowing things down? Thanks.
There are two ways that your ReactorSensor will be throttled:
- “high update rate”: the devices that the RS is watching are changing frequently; the default limit for this is 30 times per minute;
- “high change rate”: the ReactorSensor itself is being asked to trip and untrip too frequently; the default limit for this is 5 times per minute.
These are meant to prevent errors in logic or problems with devices from creating a situation in which states are oscillating uncontrollably, or logic errors that otherwise just make it change too rapidly. For example, if you created an RS to sense if a light is off and turn it on, and then you create one to sense if the light is on and turn it off, intending to add a delay but innocently forgetting to do that. The result would be the two ReactorSensors battling each other at machine speed for control of the light. Rather than pin your Vera at 100% CPU until you can figure out what’s going on and fix it, Reactor will sense the rapid change/update rate and throttle–stop doing what it’s doing–so you can get in and fix it.
When your RS is throttled, it stops running condition evaluations and activities for a short period, in an effort to let things settled down without overwhelming the system.
I’d have to see a Logic Summary and an explanation for how you approached your solution in order to go further, but just imagining something as straight-foward as controlling the garage lights suggests to me that something is amiss in your logic. It can be hard to see because the UI only updates about once every two seconds, but the “high change rate” message specifically suggests that something about your logic is making it trip and untrip rapidly in those transitions.
By the way, the default limits for these values are very conservative. There’s a lot of room to up the limits if an application legitimately needs them higher. The relatively low default values are meant to apply to most typical use cases, but they can be changed on a per-RS basis. I strongly recommend investigating and understanding the reason for the message/throttling before tweaking these values, as just upping them to shut the warning off is akin to putting a black sticker over your car’s “check engine” light (and yes, I’ve seen people do this).
Ok. I get it. I really don’t think the sensor is doing all that much so I am curious as to why it is getting throttled. I have the Root group set to “Null” so the ReactorSensor itself is not even tripping and un-tripping. I pasted the Logic Summary below.
*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
Version: 3.0 config 301 cdata 19082 ui 19125 pluginDevice 342
System: Vera version 1.7.4453 on Sercomm G450; loadtime 1557277230; systemReady 1557277249; Lua 5.1
Local time: 2019-05-08T11:37:00-0400; DST=1
House mode: plugin 1; system 1; tracking off
Sun data:
Geofence: not running
====================================================================================================================================
Garage_Reactor (#344)
Version 19082.1557328900 05/08/19 11:21:40
Message/status: Not tripped
Condition group "Garage_Reactor_Root" (NUL) false as of n/a <root>
+-?-comment "This Reactor is used to control automations in the Garage" <cond0>
+-F-group "Triggers_Light" (OR) false as of 11:30:52 <grpcuq8329>
| |-F-grpstate Garage_Reactor (344) GarageDoors_Open (grpcur6l95) istrue [true => false at 11:30:52; F/F as of 11:30:52/11:30:52] <condcuqab1k>
| |-F-service MotionGarage(Parent) (322) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 (match case) [1 => 0 at 11:29:56; F/F as of 11:29:56/11:29:56] <condcuqbdpy>
| |-F-service AlarmTriggers (234) urn:dcineco-com:serviceId:MSwitch1/Status2 = 1 (match case) [1 => 0 at 11:30:11; F/F as of 11:30:11/11:30:11] <condcuqcd2w>
| |-F-service AlarmStates (233) urn:dcineco-com:serviceId:MSwitch1/Status6 = 1 (match case) [1 => 0 at 23:45:02; F/F as of 23:45:02/23:45:02] <condcuqdjkw>
+-F-group "Return_Home" (AND) false as of 21:27:18 <grpcuqwcrp>
| &-F-grpstate House_Reactor (343) HomeAway (grpcugxgm2) istrue [false at 21:27:18; F/F as of 21:27:18/21:27:18] <condcuqyhlb>
| &-F-grpstate Garage_Reactor (344) GarageDoors_Open (grpcur6l95) istrue [true => false at 11:30:52; F/F as of 11:30:52/21:27:18] <condcuqz80t>
+-F-group "GarageDoors_Open" (OR) false as of 11:30:51 <grpcur6l95>
| |-F-service GarageDoor(Audi) (205) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 (match case) [0 at 21:32:36; F/F as of 21:32:36/21:32:36] <condcur6otp>
| |-F-service GarageDoor(RR) (203) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped = 1 (match case) [1 => 0 at 11:30:51; F/F as of 11:30:51/11:30:51] <condcur7d9k>
+-F-group "TurnLightsOn" (OR) false as of 11:31:52 <grpcurh6dz>
| |-F-grpstate Garage_Reactor (344) Triggers_Light (grpcuq8329) istrue [true => false at 11:30:52; F/F as of 11:30:52/11:31:52] <condcuri3fv>
| |-F-grpstate Garage_Reactor (344) Return_Home (grpcuqwcrp) istrue [false at 21:40:08; F/F as of 21:40:08/21:40:08] <condcurilqs>
+-F-group "NotifyGarageDoorsOpen1" (AND) false as of 10:55:11 <grpcusao0x>
| &-F-grpstate Garage_Reactor (344) GarageDoors_Open (grpcur6l95) istrue [true => false at 11:30:51; F/F as of 11:30:51/10:55:11] <condcusbc80>
Events
05/08/19 11:29:41 condchange: newState=true, cond=grpcurh6dz, oldState=false
05/08/19 11:29:41 evalchange: newState=true, cond=grpcurh6dz, oldState=false
05/08/19 11:29:41 sensorstate:
05/08/19 11:29:42 sensorstate:
05/08/19 11:29:46 devicewatch: device=322, old="0", name=MotionGarage(Parent), var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
05/08/19 11:29:47 condchange: newState=true, cond=condcuqbdpy, oldState=false
05/08/19 11:29:47 evalchange: newState=true, cond=condcuqbdpy, oldState=false
05/08/19 11:29:47 sensorstate:
05/08/19 11:29:48 devicewatch: device=203, old="0", name=GarageDoor(RR), var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
05/08/19 11:29:49 condchange: newState=true, cond=condcur7d9k, oldState=false
05/08/19 11:29:49 evalchange: newState=true, cond=condcur7d9k, oldState=false
05/08/19 11:29:49 condchange: newState=true, cond=grpcur6l95, oldState=false
05/08/19 11:29:49 evalchange: newState=true, cond=grpcur6l95, oldState=false
05/08/19 11:29:49 devicewatch: device=344, old="0", name=Garage_Reactor, var=urn:toggledbits-com:serviceId:ReactorGroup/GroupStatus_grpcur6l95, new="1"
05/08/19 11:29:49 condchange: newState=true, cond=condcusbc80, oldState=false
05/08/19 11:29:49 sensorstate:
05/08/19 11:29:50 condchange: newState=true, cond=condcuqab1k, oldState=false
05/08/19 11:29:50 evalchange: newState=true, cond=condcuqab1k, oldState=false
05/08/19 11:29:50 condchange: newState=true, cond=condcuqz80t, oldState=false
05/08/19 11:29:50 sensorstate:
05/08/19 11:29:52 devicewatch: device=203, old="1", name=GarageDoor(RR), var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="1"
05/08/19 11:29:53 sensorstate:
05/08/19 11:29:55 devicewatch: device=322, old="1", name=MotionGarage(Parent), var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
05/08/19 11:29:56 condchange: newState=false, cond=condcuqbdpy, oldState=true
05/08/19 11:29:56 evalchange: newState=false, cond=condcuqbdpy, oldState=true
05/08/19 11:29:56 throttle: type=change, limit=5, rate=6
05/08/19 11:30:10 devicewatch: device=234, old="1", name=AlarmTriggers, var=urn:dcineco-com:serviceId:MSwitch1/Status2, new="0"
05/08/19 11:30:11 condchange: newState=false, cond=condcuqcd2w, oldState=true
05/08/19 11:30:11 evalchange: newState=false, cond=condcuqcd2w, oldState=true
05/08/19 11:30:50 devicewatch: device=203, old="1", name=GarageDoor(RR), var=urn:micasaverde-com:serviceId:SecuritySensor1/Tripped, new="0"
05/08/19 11:30:51 condchange: newState=false, cond=condcur7d9k, oldState=true
05/08/19 11:30:51 evalchange: newState=false, cond=condcur7d9k, oldState=true
05/08/19 11:30:51 condchange: newState=false, cond=grpcur6l95, oldState=true
05/08/19 11:30:51 evalchange: newState=false, cond=grpcur6l95, oldState=true
05/08/19 11:30:51 devicewatch: device=344, old="1", name=Garage_Reactor, var=urn:toggledbits-com:serviceId:ReactorGroup/GroupStatus_grpcur6l95, new="0"
05/08/19 11:30:51 condchange: newState=false, cond=condcusbc80, oldState=true
05/08/19 11:30:51 sensorstate:
05/08/19 11:30:52 condchange: newState=false, cond=condcuqab1k, oldState=true
05/08/19 11:30:52 evalchange: newState=false, cond=condcuqab1k, oldState=true
05/08/19 11:30:52 condchange: newState=false, cond=grpcuq8329, oldState=true
05/08/19 11:30:52 evalchange: newState=false, cond=grpcuq8329, oldState=true
05/08/19 11:30:52 devicewatch: device=344, old="1", name=Garage_Reactor, var=urn:toggledbits-com:serviceId:ReactorGroup/GroupStatus_grpcuq8329, new="0"
05/08/19 11:30:52 condchange: newState=false, cond=condcuqz80t, oldState=true
05/08/19 11:30:52 condchange: newState=false, cond=condcuri3fv, oldState=true
05/08/19 11:30:52 sensorstate:
05/08/19 11:30:53 sensorstate:
05/08/19 11:31:52 evalchange: newState=false, cond=condcuri3fv, oldState=true
05/08/19 11:31:52 condchange: newState=false, cond=grpcurh6dz, oldState=true
05/08/19 11:31:52 evalchange: newState=false, cond=grpcurh6dz, oldState=true
05/08/19 11:31:52 sensorstate:
When pasting the Logic Summary, there’s a pretty clear instruction about keeping everything below the top line. That’s there to ensure that the summary is properly formatted when posted here, and that the site’s native formatting doesn’t change anything about the content. I can work with what’s here (don’t repost it), but in future, please make sure to post everything exactly as the instruction says. Those three ticks (```) at the top and bottom are important.
Interesting. Try putting that back to an AND and seeing what happens. It’s perfectly safe to ignore the Trip/Untrip state.
Changed it to AND and now no Throttle message like before. I will keep monitoring it over time and report back if I see the throttling again. Thanks for your quick help.
No worries. I guess throttling and root NUL don’t get along. I’ll look into that.
Just to let you know, I had the same issue, and it seams solved after changing from a nul group 
3.0 from github, under openLuup.
Yup, found it, fixed it. Will be in 3.1 (Sunday/Monday), and is available now in the Github stable branch (and thus AltAppStore).