Is it worthwhile in terms of Vera resources (cpu, memory) to try to fit all logic into just a few Reactor sensors? Or does it really matter and 10-15 sensors won’t consume much?
Reactor is built as a parent-child application, so there is a single copy of the Reactor plugin in memory, and each ReactorSensor is just a container for its configuration and state. The overhead of each ReactorSensor is thus significantly less than it would be otherwise.
As a rule of thumb for my own house, I have a ReactorSensor per room to do whatever jobs need to be done in that room. In my home theater, I have two, one for the media stuff and one for everything else (lighting, etc.). I have a couple more that contain general house-wide logic (e.g. I would always forget to enable DeusExMachinaII when we travel, so now I just put our travel dates into a ReactorSensor when they become known, and we pretty much just walk out of the house knowing everything will be taken care of–one less thing to think about when coordinating our punctual departure).
To me, one big ReactorSensor would become too unruly. I recommend you split it up some way that works for you. They’re cheap.
2 Likes
How strange! I was going to ask pretty much same question.
I am up to 24 Reactor sensors now and my Vera seems to be running better now I have replaced the native Vera scenes.
Is there a theoretical limit to the amount of Reactor Sensors a Vera could support?
So I did a quick test.
On my development VeraPlus (256K RAM), I took a “baseline” of free memory: about 123K (48%). I then created 150 ReactorSensors, and cloned my largest current test configuration on the box in terms of footprint (13 groups, 17 conditions) to each of the new sensors. Free memory went down to about 93K (36%) while cloning the configurations, and then settled in to run slightly higher at 98K (38%–Reactor purges unused/cached data from “quiet” sensors to assist memory management on the Vera). So, that’s still quite a bit of free memory to run with, and suggests that you could theoretically create twice that many ReactorSensors and still have >25% free memory.
There’s no enforced limit. My impression is that the theoretical and practical limits are a good bit higher than even this test for the Vera Plus, and not something the majority of users would likely encounter. Other models will vary, of course.
Really interesting - thanks for checking.
As a best practice do you find it’s better querying device states in each sensor or creating a single group that queries a device state and then using group states?
I favor simplicity! Do what is easiest for you to understand now and read later. I do everything in my system with the idea that I could be hit by a bus tomorrow and my Vera will be in the hands of my sons or my wife’s next husband to support.
Seriously, though, for me, if I can do something as simply as possible, that’s the way I’m going to do it–it’s usually the right way. I want it simple, readable, and predictable, and I’ll push that goal as hard as I can.
For your group states question (which is better?–individual tests of a sensor; or test the sensor in a group and then use group state tests?), the answer is a firm it depends, and again, has more to do with your sensibilities than technical limitations:
- If there are no other underlying conditions or requirements, just a straight test of a binary sensor, for example, then testing the sensor directly in each case may be simpler;
- On the other hand, if the test is against a value or range that you might want to change, and that test is used in multiple locations and so any change would need to applied to each use if done individually, then a group test makes sense. Example, testing an outdoor sensor for CurrentTemperature > 72F for some purpose. If you use that test in multiple places, you may be better off putting the condition in a group, then using group state tests where you need that result. Later, if you need to change the test temperature, you only have to change it in one place (the group) and all the places that use it come along for the ride and stay consistent.
While group tests add one more level of indirection, and thus take longer to process, we’re talking about low numbers of milliseconds longer here, on events that typically at worst happen a few times per hour, not 100 or even 10 times per second. Optimizing those milliseconds out for performance at the expense of simplicity and/or supportability of your work in the long term wouldn’t be a good exchange of value, in my opinion.
I have quite a few sensors that I want to react differently depending on times of day so I have created a single sensor called Time Schedules. This has a bunch of subgroups that query the time in different ways or looks at different sunrise/sunset combinations giving me simple true or false options that I can use across the the rest of my sensors.
As you say - Keep it simple 
1 Like