This has been picked up by @thebearmay and his thread is here:
Whelp...I decided to stop mooching and to take a stab at writing an app. This will hopefully be both a beneficial learning experience for me and a benefit to the community. My intent is to grow this app over time to include more sensors.
What is this?
A, hopefully, lightweight app that will allow the user to group together sensors.
What's special about that?
This app will update the created virtual device with aggregate counts and status. All device group apps have a configurable threshold. This will allow the user to set how many devices will need to be in the active state (e.g. active motion/smoke detected/contact open, etc.) before the virtual device is updated. Full feature list:
Custom attributes to give a snapshot status of the grouped devices
Configurable thresholds of how many sensors need to trigger before the virtual device is triggered
Provides a list of triggered devices. The list is provided as a custom attribute (string type) and is part of the status change event for the virtual device to be used as the %text% variable for RM.
Can be nested.
Supported Capabilities That Can Be Monitored
CO Detector
Contact
Humidity
Lux
Motion
Power Meter
Pressure Sensor
Smoke Detector
Switches (should also include most bulbs)
Temp
Water Leak Detector
NOTE: Min/max/avg readings for humidity, lux, and temperature are for the group at that point in time. An example for humidity; sensor1 at 50, sensor2 at 60 and sensor3 at 70;
min - 50
max - 70
avg - 60
INSTALLATION
Can be installed using HPM; just search for "Sensor Groups+"
Fully modular, so only the sensor apps needed can be installed.
Manual installation requires the parent app, along with the child apps and the omnisensor driver. All code can be found in my GitHub repo.
Hello.
I just tried your app, and I'd like to make a small suggestion.
First of all, it's great because I will find it very handy - I will show you how I intend on using it:
I will make a "combined " water sensor to very quickly test and see if there is a leak in the house.
it works great for this.
however, if there is a leak, I have to go back and figure out which one (out of the 12) is causing the leak!
therefore my suggestion: Is it possible to make another state variable which has in it the name of the sensor(s) that is "wet"?(i.e. over the threshold)?
How about this? I need to do a little more poking to see if I can sort the list.
EDIT: Well, the list is an oddity...I'm not sure why 01_test is getting sorted to the end, the other sensors are sorting as I would expect. I'll do some more digging tomorrow.
EDIT 2:
I rectified the sort issue with the help of the gracious @bertabcd1234.
FYI @FriedCheese2006 - I think there may be something wrong with your coding for some of the new devices. I tried doing some groups for CO Alarms, Smoke Alarms, and Leak Sensors - it's not creating a virtual device, and throwing this error in the logs.
Doh... rookie mistake. Apparently I should go to bed. I paired up the app in HPM and assumed that'd have been installed. Re-ran the device setup, and they're showing up now. Thanks!
%device% is a global variable in RM that refers to the device that caused the event in the rule.
I'll most likely include the OpenList values as description text in the open/wet/detected events so you could use the %text% variable in RM for notifications.
Actually, this is more my fault. I have everything except the parent app set to optional, but they really aren't...for now. I do want to make this a little more modular so that the drivers are automatically installed based on the selected child apps. That's a little ways off, so I'll update the HPM integration to just pull everything.
I was able to work on this some more today. With the way I have it setup now (to be pushed out), we'll have two options for notifications:
Option 1
If you only care about what devices are 'active' when the threshold is broken, you'll be able to just use the global %text% variable in the notification. For everything except motion sensors, this would be the first device is the group that changes state. For motion, this would be whatever sensors are active when the set threshold is hit.
Example:
Setting up a rule to notify when the contact sensor group opens, I can get a copy of the open list in the notification. This shows that "01_test" was opened causing the group device to show open.
The downside is that this will not be triggered again unless all the sensors are closed and then it's opened again. If I just continued to open contact sensors, I would not get any more notifications (this might be desirable depending on the use-case).
Option 2
Which brings me to the custom attribute. You can set RM up to notify when the attribute changes. This will result in a notification any time a device is added or removed from the list.
