Devices as objects in RM

I'm aware that this subject - or variations of it - has been discussed in another threads, however, here I go ...

I'd like to suggest a feature that could improve the already rich set of features found in RM: handling of devices as objects.

What could be done:

  • Create a new type of variable: "device object"
    The objective of it, as it may be clear by the type itself, is a variable that can hold information about a device - a classic indirection.

  • Create a new type of value, "trigger device"
    This woul hold a reference to the object that, as the name says, contains a reference to the object that triggered the rule;
    It would be used to load into a local variable (type "device object") the reference to the device that, guess what ... triggered the rule.

  • Create, also, a special device: "trigger device" (as in %device%)
    It would make possible to use direct reference to the object that triggered the rule without the resort to a "middle man", a "device object" variable

  • Make it possible to compare a "device object" with any device
    It would make possible to check if the "device object" references to a specific object or, in a more advance form, to a set of devices (as in "device object" is one of [device list]);
    It would be used, for example, to identify the specific device that triggered the rule.

  • Change the %variable_name% reference logic
    Whenever a %variable_name% is used in strings, messages, etc, RM would replace it with the device name (as it does with %device%).

  • Change devices reference logic
    RM uses a direct reference to objects and, with the "device object" implementation (or special device "trigger device"), it would be changed to, additionally to a direct reference, use the indirect reference that the "device object" represents.

Of course I don't know the internals of RM, however, I believe that, albeit not being a simple implementation, it would not cause significant overhead in processing of rules.

This proposal does not intend to be an exaustive list of details that where RM must be updated to allow the use of "device objects".

One use case - a real one:

The environment:

  • I own an apartment with 5 rooms, that I intend to rent to a nearby college students
  • The apartment will have central heating, with water radiators on each room
  • As expected, each room will have selectable room heating settings
  • Each radiator will have a ZigBee water valve to control of its heating
  • Each room will be equiped with window sensors

Some of the automations to be implemented:

  • Limitation of temperature heating settings
  • Shutting of heating of a room if a window is kept opened for some time
  • Shutting of heating if a tenant leaves the vicinity of the apartment
    Note: so far I have 9 different rules ...

Having 5 rooms with the same set of rules will be very difficult to maintain - an update in a rule must be replicated on the others. Of course cloning rules make it easier to implement (BTW, cloning rules is great!), but it requires additional steps - in this case, cloning 4 additional rules.

Now imagine having another two apartments with each one having, for example, 4 rooms on each?

How "device object" could help?

In a rule exploring the suggested feature it could:

  • Identify what specific device triggered the rule by comparing the "triggered device" with specific devices
  • Set additional "device object" variables based on the specific device that triggered the rule
  • Use those "device objects" at the following device references

Well, that's all - at least for now.

@bravenel, your thoughts please!

I understand. However a "device object" extension isn't needed to accomplish your use case.

Devices are identified in the hub in 3 primary ways: name, label and id. A device object contains those values and others, specifically the various attribute values. In RM one identifies a device by its "name", which is either the label or the name (if there is no label). This is the value put into %device% when a rule is triggered. The value of the trigger event is put into %value%. The attributes of the device are available through the Last Event Device condition, which allows testing those attribute values. Between these three, every aspect of the triggering device is available for comparison, to be put in a variable, and action (coming soon). Comparing the triggering device to know what to do can be accomplished by putting %device% into a String variable, and then comparing it to whatever you want, including other device names.

There is a new feature in the next release that allows the Last Event Device (the one that triggered the rule) to be acted upon in a Custom Action.

3 Likes

It makes sense!

Since each room device names begin with a preffix that identifies the room (Qn - from Quarto - room in Portuguese - and n, for room number) I can use the feature described bellow to identify programmaticaly the room:

I must confess that I still have some difficult in abstracting the problems into RM features/capabilities. But I'm optmistic and I'm sure I'll get there!

By the way, is it possible to set a variable to a device attribute? I found this post ...

but I couldn't find the option "device attribute" here.

Thanks for the prompt response!!

You can set a variable to a device attribute value. Look at Set Variable. What's missing, that would be a good addition, is an option to set a variable to an attribute of the Last Event Device.

Yep - I was using a wrong variable type. Need to be string.

:+1:

Download the Hubitat app