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!
