I have a ton of water sensors around the house (paranoid after friend did over $250k in damage from a pipe rupture). But I don't want all of them sitting on my main dashboard taking up most of the real estate. I'd like to create a custom (virtual?) device that reads in the states of the water sensors and if any are reporting WET, then this virtual device will show WET. That way I only need that one device on the main dashboard, and I can have a separate dashboard for the water sensors individually.
Create a virtual moisture sensor and update it's state via Rule Machine. Use all the water sensors you want to group as the trigger and if "ANY" are wet, set the virtual sensor as wet and set as dry if "ALL" are dry (might need to rules for this).
I you need help on the rule machine portion, just let me know and I'll get back to you tonight some time.
1 Like
I use a custom app called Device Groups that can do what you’re looking for. If you are running Hubitat package manager it’s available through that.
1 Like
I haven't installed Package Manager. Should I?
OK, this was what I've started. I just haven't figured out how to update the state of the virtual moisture sensor.
Here I have set the Trigger to look at these sensors reporting WET (I'm hoping that means any of them reporting wet instead of all of them?)
But when setting up the Action, I'm not sure which to select.
The Package Manager solves a problem you may not have. If you do have the problem, then look into it and see. 
If you have a few Community Apps and Drivers, Package Manager will help you to detect and update when new versions are released. Obviously the Hubitat built Apps and Drivers get an update with each Platform release, so Package Manager is helping with just the Community ones. It also helps with installing a new App and/or Driver as well.
Thus, mostly the answer depends on you.. how many Community offerings you're using and how much help you want with keeping them up-to-date.
(I hope that summarizes it well...)
1 Like
Only reason I mention the package manager is I briefly searched and couldn’t find a post for app I was recommending you install to solve your actual problem. I know I installed it via HPM, so was just easier to recommend doing that instead. I’d still recommend using HPM, it just makes installing and finding packages easier.
But I’m using the app to do what your asking not with just leak sensors, but also to group up contact sensors in various ways as well.
Edit: github link to the readme (which I grabbed from HPM)
1 Like
Here is how I would do it...
For the Actions, make conditional "any" for the wet test.
To set the virtual water sensor, use the Set Mode, Variables or Files, Run Custom Action,
select the Run Custom Action and then select the water sensor, etc..
Conditional else if, make a conditional "all" for the dry test.
Set the Run Custom Action, Water, to dry.
End-If
And save the rule.
Hope this helps, I would have put a few more screen shots but I'm on an old Win7 computer right now and cropped screen shots are a b.... to do.
If you need more info, I'll make the screen shots.
1 Like
Thanks for the tips, let me play with it some more and I'll ping you if I have any questions.
Regarding screen shots, have a look at Greenshot. It's the screenshot tool I've used for years.
Just installed Lightshot Chrome Extension, looks like exactly what I need for helping people here 
I'll check back in 1/2 hour or so to see how it goes/went !
1 Like
So I'm not getting any options when selecting the custom command for the Virtual Water sensor. The virtual device type is the Generic Z-wave Water Sensor. Maybe I need to try a different device type for the virtual water sensor?
That's it, I believe you can only change states of virtual devices!?
My unsolicited .02, RM 100% will work for this and it’s good to understand how it works If it’s unfamiliar to you. However, you will frequently see people suggesting to use the simpler options when available. RM can be heavy at times and as more rules are added, there are more ways you can impact hub performance in undesirable ways.
A custom app/groovy code when available is potentially cleaner to deal with and is simpler to maintain at least in my opinion. For example, having to edit a RM if condition can quickly become unwieldy and annoying to do. All of that combined with the potential for increased performance.
That all to say, this rule is unlikely to cause any sort of performance impact in the grand scheme and it’s no skin off my back if RM is your preference.
1 Like
This is a great point. I'm familiar with unofficial community plugins in other areas (I run an Unraid server with plenty of community plugins/apps). Just learning Hubitat so wasn't sure how "supported" they are, especially with platforms updates. Last thing I want to do is brick my HE, ha.
You should be pretty safe from a bricking perspective with most custom apps. I’m not aware of anything a custom app could do that would cause it to brick a hub.
As you continue on your journey into Hubitat, you’ll probably find a number of reasons to use community code/apps. The devs are all pretty willing to help troubleshoot issues with their code if it’s encountered. For this specific case though, the app should be simple enough that you won’t run into issues.
As with most things in life, you’ve got a bunch of different ways to accomplish the same thing within Hubitat.
