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
Switches (should also include most bulbs)
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
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.
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.
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:
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.
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).
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.