My lights are currently controlled by timers, by motion, by illumination and manually. I want to use a relay so I can show the input status for a single light together in a single dashboard point. So I see the need for at least 3 discrete (on/off) inputs and 1 analog input for each light.
My window shades are controlled by timers, by sun location (altitude and azimuth), by room illumination and manually. The sun position controls keeps the sun light within a certain distance of the window and to the side when the sun is shining brightly. The room illumination keeps the room to a certain light level when the sun is not shining brightlyl. That gives 2 discrete and 3 analog inputs for each shade. There could be more for other types of control.
Need to create a virtual relay for each device type. I have seen references to virtual relays, but nothing about how to create them. Need some directions on how to start.
My future controls include water heaters, sprinklers, locks, pumps and thermostats. There seems to be multiple inputs with one or more output. So the relay model seems to work for all of there types.
My goal is to have all controls in a single parent app with multiple child apps. The current method of having so many rules spread out in RM and additional user created apps is hard to explain to a non techie.
I want to use evcallia's Schedule Manager as a starting point for the timer related controls. Then add the additional control types as additional child apps. Evan's app brings all timer controls in a single table. Want to do the same thing for other types of control.
From a parent app that shows an overview of all real device controls, tahe user should be able to select by device type or control type to go down in the structure to see the next level of details. Then finally to a specific device.
Just to be clear, RM is a parent app, and each user define rule is indeed a child app, so the seems like a chunk of what your trying to do.
As for a virtual relay, a virtual switch is easy enough to setup, which is effectively an output contact. When you say “relay”, my initial thought is a PLC input coil and a NC or NO output, with things in series as ANDs and things in parallel as ORs. Rule machine is a tool where user defined logical expressions and conditionals can be written with AND/OR logic. If you really want to get serious with custom logic, that is repeated across multiple similar devices, then writing your own apps in Groovy will give you the best results.
But I’m still a bit confused why you need a virtual relay, versus a virtual switch. Perhaps I don’t complexly understand your goals here.
My goal ie to have all of the control logic joined to the switch at the device level.
I'd like to have the relay read the inputs directly. Just like a rung or a set of rungs in PLC ladder logic.
If I can create a virtual relay with various types of inputs then it will be easier to assign the various inputs to specific relays. A lamp relay will have a different set of inputs from a window shade, a sprinkler timer, a lock or a thermostat.
Shouldn't have mentioned RM. I don't plan on using RM for any controls. It is harder for people to get a full picture of the controls than ladder logic, with the controls spread out in so many rules.
Ladder logic at least keeps all controls in one place. But it still is hard for the average person to understand.
Evan Callia's Schedule Manager is a good example of having all time-based controls in one place and in an understandable format. (a data table/spreadsheet) I want to create a child app like Schedule Manager for each type of control. For example, motion, illuminance, presence, temperature and more. Using Schedule Manager as a starting point, that should be fairly straightforward.
Then create a parent app that gathers all the types of control into a single table that shows a summary of all the controls for each output, with links to look at the details by control type or by output device.
Since this will be an independant app, with multiple cild apps, nothing will be in RM.
My goal is to have all controls documented in the set of apps so my wife and the people we eventually sell our house to can have a more easily understood way of seeing the logic.
Hope this helps to understand my goals.
I’m unfamiliar with PLC methodology so I don’t fully understand your goals however I wonder if the “virtual relay” you are looking for exists in the form of Room Lights (and its activator device). RL supports many of the inputs you use, such as time, illuminance and motion. You can add additional inputs of arbitrary type via virtual switches controlled by RM or other means.
That does not describe a relay. A relay is binary, just like a switch, contact sensor, or motion sensor. It just does on/of. You can even use a relay tile on the dashboard for a switch, as they share the same attributes. So I do not get why the relay capability makes any difference, as a relay is really just a switch with a different capability and display name.
Multi-gang switches (or relays) in Hubitat use a parent, and child devices for each individual switch. Is this what you are trying to reproduce? They still will not show on one tile, each child device is just another device, and would need a separate tile on a dashboard.
Edit: If you really want the virtual relay capability, just make the driver yourself. If you are coding apps it is pretty simple to make the virtual relay driver, though I don't see what it gains you over a virtual switch.
@johnwill1 you are correct in wanting to see the inputs and output(s) together.
Since I have not written an app or driver for Hubitat, and my skills areca bit rusty, I really need to see something similar to understand the code structure to get started.
One way to describe my idea is to think of the entire rung in the ladder logic that operates the relay as a virtual device, from the inputs through the logic to the relay. Since many of these virtual devices will be identical in structure of the logic with the only differences in the inputs and outputs.
I think I can see where you're wanting to head with this. Unfortunately, Hubitat 'Devices' do not allow direct connections/associations to other Hubitat 'Devices'. One always must use a Hubitat 'App' to accomplish this. You could create a virtual device driver, that includes multiple 'Attributes' as the 'Inputs', as well as one or more 'Attributes' as the 'Output(s)'. However, you will need an 'App' like Rule Machine, or a custom Groovy App, to mirror the actual physical devices to the 'Inputs' of this custom device.
At that point, it seems like it would just be much simpler to use a Rule Machine Rule to perform all of the 'Input' data gathering as logic, and then simply 'Output' the result to a Virtual Switch (or whatever type of device you'd like.)
The issue with the earlier method is that it really does not follow Hubitat's architectural design of Apps and Devices, using Standard Capabilities. It is this architecture that allows all of the standard Hubitat Apps to work properly with Devices that adhere to the architecture.
I am struggling to figure out the advantage of the proposed design versus just using the architecture as-is? I have been using this architecture since 2014 and it has been very flexible and capable of meeting most everyone's requirements.
Reading the following, I can't help but think you are basically describing Rule Machine. It has data inputs, then logic, and then an output. This can easily be an output to a virtual device, if desired, or a physical device.
Rule Machine allows one to copy and paste Rules, changing the devices as necessary in the new rule. Perhaps you could at least start with Rule Machine to see if it achieves what you're wanting to accomplish? If not, custom Groovy code is always an option.
@ogiewon Yes, RM does fill all of my needs, but still leaves me wanting something that can be used by a non-techie. I don't want to disparage what you or others have done with Hubitat. But the more I use smart hubs and put more automation in them, the more I realize that this is not my ideal. I have way too many rules now and I need to create many more to accomplish all of the automation that we want to have at home.
As I said in earlier posts I find Evan Callia's Schedule Manager app to be a great idea for time-based control. I see the need for similar apps for control based on various input types, like motion, illuminance, presence, lock status. I believe they should all be child apps of the same parent app.
Thanks to your comments, I now realize that I don't need to create a virtual relay, all I need is apps, one for each input type. I was hung up on having single device for my dashboards.
