Home Center 3 UI - Feature Request: “User Properties" and "Dynamic Device Groups" within Scenes

[RedRocketFire 2]

Home Center 3 UI - Feature Request: “User Properties" and "Dynamic Device Groups" within Scenes

 

Overview

 

The use of "User Properties" and "Dynamic Device Groups" would do the following:

• Make scenes easier to create and maintain

• Reduce the need for LUA code in many cases

• Provide for a more powerful feature set out of the box.

• Provide for a GUI object oriented approach rather than one of a hard coded block or LUA scene.

• Adding or replacing devices in the system will not force a modification to scenes.

 

User Properties

 

One could create User Properties such as “Nightlight” or “PrivacyLights” and then have the ability to assign one or more User Properties to an Area, Room or Device. The User Property could then be used to define a group of devices that could be controlled by a scene. Devices would then no longer need to be specified in scenes by a hard coded ID but could be specified by one or more Properties. When a property is applied to an Area or Room, it applies to all descendent devices.

 

Dynamic Device Groups

One could create a Dynamic Device Group that had filters based on User Properties and Device Properties rather than on hard coded IDs. Dynamic Device Groups could also reference other Dynamic Device Groups.

 

For example:

• Dynamic Device Group name - All My Lights

  • Device.Role == Light

  • OR

  • Device.Role == RGB

 

• Dynamic Device Group name - Common Lights

  • Dynamic Device Group name = All My Lights

  • AND

    • Room.Category != Bathroom

    • AND

    • Room.Category != Hallway

    • AND

    • UserProperty != PrivacyLights

Scenes

 

Users could use the Dynamic Device Group in a block or LUA scene to control devices. If a property can not be set for a specific device at run time, the property would be ignored. This way in the scene we can specify that we want to turn lights on, set the dimmer value and then change a color to all of our lights in a group. If a device is a switch for instance, then dimmer and color control commands would just be ignored.

Edited March 27, 2023 by RedRocketFire

[Joep 181]

Please do some research on roles and categories on devices. Also do some research on profiles. With Lua script you can simple use API commands to get your groups without scripting with id's. To start look at the api call: local enabled_lights = api.get("/devices?interface=light&enabled=true") or {}

 

More about this you can find

Please login or register to see this link.

and

Please login or register to see this link.

.

[RedRocketFire 2]

Thanks, it’s a good suggestion. I have got my house running dynamically on roles and types but it took a huge effort in terms of learning LUA and Fibaro. Also it is undesirable that I have to make a code change when adding a new device type like I recently had to do when moving Hue lights off of the Hue integration and enrolled directly via Zigbee. I enjoy coding but I don’t want to do it because the lights aren’t turning on. 

 

It would be nice to simply see an intuitive connection to these concepts when adding devices and using the block scene designer without getting into LUA. 
 

When I made my first block scene I was disappointed that I would not have a simple way to make a single scene that could be scoped to a device, room, area or entire house. I had to make many scenes if I wanted to do that.

 

When a device failed and had to be replaced I was frustrated to see all of the block scenes that I had created were suddenly invalid and I had to re add all devices in all of my scenes.
 

Updating these things to get them working is usually not the end of the world but it is a pain if you are not there and nothing is working for my wife and kids or maybe a potential tenant.

 

Thanks for your feedback and suggestions, they help a lot!

 

[RedRocketFire 2]

I think the disconnect for me is that Roles and  Categories are not necessarily relevant to the intent of what a scene is doing although they sound like they are. Profiles look a lot like static scenes with a slightly different intent but still not solving any of the static ID problems.

Ideally a great GUI feature for me still would be to define a SceneType to Sections, Rooms and Devices and allow us to code for that in LUA or better yet code for it in block scenes. This places scene programming back in the GUI during device enrollment and configuration instead of in LUA.

As a work around I though I could add custom Categories into the system since the GUI device configuration allows for multiple values. There is no GUI for that and it is not available in the rest API so that appears to be impossible. Also Role is less flexible and also just a single value. This scene type would also be better suited in it's own SceneType drop down. Also these same problems apply to rooms and sections.

I started a new project called Nightlight. I wanted every room to have a virtual motion sensor and binary switch with a scene that automatically turned on for motion sensors in the room if they existed, taking into account the current light level of the dimmers as well as when the last time someone touched a device. It was more complicated than it sounds and didn't perform as fast as I would like in the end. I got to thinking about a new approach that I think is  much better as a work around to the underlying issue:

I created a Nightlight setup script that dynamically creates a LUA scene, quick apps and variables for each room. Of course the setup can run manually or on system startup and will rebuild everything as needed. This way I don't have to worry about IDs and new devices and managing individual room scripts. Also hard coded IDs perform much faster than an all in one script that has to look everything up. I just created everything manually once and taught the setup script to create everything for each room based on my template objects.