I'd love to see a variable of type "Device".
Use case:
Set a local variable in a rule to a specific device and then just use that variable in the various conditions and functions.
When you clone a rule, you'd only have to change the local variable(s), but don't have to change each condition and action of the rule.
This has two aspects, that you intermingle in your post: The value of device attributes used in conditions, and the use of a device in an action commanding the device to do something.
The first aspect can easily be done now, as each device attribute can be put in a variable now.
The second aspect would introduce a new overhead to every device action in Rule Machine. That seems a bad tradeoff against a benefit of making it easier to set up a rule. Setting a rule up is something done once. The device actions are done thousands of times. Burdening every device action would penalize every rule. So this one won't be happening.
In terms of the request for a variable I think keeping the rules simple to make reproducing / copying easier, and I would think if the copying is on a large scale an app may be the next logical option, if not in place of using the rules in the first place.
Perhaps an alternative to the variable option, would having the ability in configuring a rule to replace a device be possible? So if you have an existing rule referencing a contact sensor and want to change it to a different contact sensor?
I'm not talking about keeping the rule simple, but of not burdening the code that does an action with figuring out if the device is a variable or a real device.
To my simple way of thinking about it -- you don't burden run-time with things to make compile-time easier. In this case, run-time is every rule ever written actually running, and compile-time is the process of authoring rules.
The way I do this is by using an app called device groups.
All my contact sensors use this and if I need to replace one i just change the contact sensor.
Cannot remember where I got it but can post if you wish.
Yes, I realised my mistake in misrepresenting your post @bravenel, I amended it probably while you were typing your last response. I definitely agree with keeping the processing of rules as lean as possible.
I would love to, but the learning curve to create an app seems pretty steep (and I am saying this as a C++ programmer)
Here is the rule I am trying to simplify in terms of creating the same rule for different rooms (it controls a physical thermostat from a virtual thermostat and physical temperature sensor)
As you can imagine, cloning this for different rooms is a lot of work.
I was encapsulating in that option both developing an app but also looking to built in apps or community developed apps. I can appreciate the learning curve, there can be a lot to take in and not always enough time to dedicate to it.
Unfortunately you can't put thermostats in groups.
That would surely simplify things.
I moved from ST to HE and was surprised that such an app didn't already exist. I'm sure I'm not the only one that wants a virtual thermostat that can be connected to a physical thermostat and temperature sensor.
Also, what happens if the device you set the variable to doesn't support the command that you have defined? The rule would just error out and not perform any of the subsequent actions. making it a nightmare to support.
There would have to be a mechanism in place where you can only set the variable to the proper device type. Similar to the way that "connectors" are limited depending on the type of variable. So when you create the device variable you'd also have to specify the device type.
So, only something that uses the same driver? That would be pretty useless. There is no other way of identifying the "type" of a device since each driver has different capabilities and custom commands. There is no mechanism to call something a dimmer vs. a switch for example. So, you're talking about a whole new identification schema as well. More trouble than it's worth IMHO
I thought I was talking about contact sensors.
I used that as an example, sorry for any confusion
IMHO I don't think so. Look at my use case above. I have 2 thermostats plus one temperature sensor. Being able to replace the thermostats with different thermostats and the temperature sensor with a different temperature sensor would be quite useful: Clone the rule, change those devices, done.
No problem. I try to get the devices that I can into something like the device groups app so that I only have to change one thing and leave my rules alone.
Makes life so much easier.
Appreciate we cannot do that with everything.
I'm sure there must be something around... most of the apps I have found are temperature based, not providing multiple trigger points...
Not 109% related to the original question, but this app may be of interest. I don't use it myself, but it does look interesting....
I just realized, that there already is a concept of device variables in HE: virtual devices. I guess the only thing that's missing is the ability to assign a device to a virtual device (or does that exist?). I saw the "Mirror" app, but unfortunately that one only works on simple devices like switches.
I agree. Is there perhaps such a concept of compile time resolved variables (such as #define in C) in HE?
I know I am stretching now, but how about a pointer variable type? It could be assigned to any other variable or device and accessed the same as the variable/device its pointing to.
The same is true when you assign an integer to a decimal (which has bitten me already a couple of times).
Perhaps you should explore writing apps in Groovy.
Download the Hubitat app
