Variable for Device

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.

1 Like

I'm sure there must be something around... most of the apps I have found are temperature based, not providing multiple trigger points...

1 Like

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.

But the "type" is currently the driver that is selected. So, you would only be able to swap one Generic Zigbee RGBW bulb with another Generic Zigbee RGBW bulb and not a Hue bulb, for example. So, unless you also developed an entirely different classification structure for devices, this wouldn't work.

I am fine with that and actually that's the way I would expect it to work.

Then I fail to see how that would useful in the real world. How often do you swap one exact device for another of the exact same device? I usually only swap if I want to try a different device in place of another. Why bother swapping devices if you're only going to get the same functionality?

Never had a device fail?

I created an automation rule that links a virtual thermostat to a physical thermostat and temperature sensor. I need this automation for each room where I want to have this functionality. So I'd swap out the devices with the same type, but a different ones. For this particular example without variables I have to manually adjust 16! devices after I clone the rule. Multiply that by 3 rooms and you can see where having a device variable would be useful.

Only if all 3 thermostats were the same device. And you only have to do this once. It's not like you will have to replicate the rules every week. So, the variable your proposing would be per rule? So, basically, you would save absolutely zero time the first time you wrote a rule.

I'm sorry, but it sounds a lot more like you just want to save yourself some time for this one specific use-case. I would suggest that you learn groovy and write your own apps. That way you would only have to define the device once and then you're done.

Why would they have to be the same device??? The device type needs to match.

In my particular use-case the rule would use 3 global variables:

  1. Physical Thermostat
  2. Virtual Thermostat
  3. Temperature Sensor

I would then use those variables - instead of the specific devices - to write the rule.

Instead of replicating that rule for each room, it would actually be better to leave the trigger empty and create separate rules for each room that contain the triggers and in the actions you set those 3 global variables and then call the main rule.

This makes the rule much more maintainable. Otherwise, if you want to change the rule after you replicated it, you'd have to make that change to all those copies.

You wouldn't save any time writing the original rule, but you'd save time for each copy you make, because instead of changing 16 devices, you change 3 variables. Using the approach outlined above, you'd also save time maintaining/updating the rule.

This is just one use-case. I am confident that there are other scenarios where having a device variable would be useful. Like the case @aaiyar mentioned when a device fails.

Here is another example:
Imagine you have a rule that has a bunch of conditions and actions for one device. Currently, if you want to change the device in that rule you have to change it for each condition and action. Instead, if you created that rule using a local device variable, you'd only have to change the value of that local variable.

I'd love to, but that takes even more time then changing 50 devices in my rules.

A global variable is the same across the entire system. So, again, I fail to see how this would work in your description. You would write the rule with the variable and then the variable would be set to one of your three thermostats. So, you would have 3 rules all controlling the same thermostat.

Or are you also proposing that these fictional variables also allow multiple devices to be selected. So, not only would you have to swap the devices within the variable for the same devices but devices within the variable would also have to be the same?

Only if you replace it with a device that uses the same driver. Again, it is not all-encompassing. Because of that limitation it becomes very restrictive and not worth the effort to implement, IMHO.

I think it's clear that neither of us is going to convince the other so let's just agree to disagree.

No, each rule (with the trigger) would control a different thermostat. The rule sets the global variables and then calls the main rule. It would be the same concept as having a function with parameters, where the parameters are the physical and virtual thermostat and the temperature sensor.

It could be useful, but not necessary.

I don't see where this is an issue. Variables are always of a specific type (int, float, string, etc...). So that a device variable could only be assigned to a specific device type isn't anything unusual. You can't assign a string to an int either.

Let's do that.

Just out of curiosity: Do you have a programming background (no need to answer if you think the question is too personal)

I don't think we're using the same terminology. Global variables in Rule Machine are variables that have a constant value across all rules. So, how would a global variable have different variables for 3 rules?

Apples and oranges. A new device variable that is limited to devices sharing a common driver would mean that the use of said variable would make it so specific as to render it useless. If you implement a string variable, it is very unlikely that you would ever have to change that to an integer variable because the functions attached to said variables are so different. Not true with device types. A Generic Zigbee RGBW Bulb and a Hue RGBW Bulb have the exact same functionality but in your proposal they would not be interchangeable because they do not share the same device type.

Well, I have pointed it out several times. But once again, because it makes the functionality of such a function so limiting as to become useless.

No...but I do have a software V&V and life-cycle management background. I think that is why I am able to see the bigger picture and not get bogged down in the code. You seem to be focused only on the question "can we do this" and I'm thinking more along the lines of "should we do this". Almost anything is possible with enough time and money. But Hubitat has limited resources and they have to work on what is going to get the most bang for the buck. Whenever they get a request they are asking what benefit will this have to the company. It would make you very happy but how many users would complain that they wrote a rule with a global device variable and then had to go through and re-write all their rules anyway since they used a device that used a different driver? Bottom line...spending the time to implement the functionality you propose would not gain them anywhere near the cost of implementing it. I mean, folks can't pair devices to the hub at the moment. Priorities are elsewhere and I can't see them ever getting enough time on their hands to tackle something like this.

What you are saying is an oxymoron: A variable has a constant value. You can change any global variable through a "set variable" action.