I have started to build a new App/Drivers for the Netatmo Velux devices and they have the concept of Home -> Room -> Module (three levels of depths / nesting), when creating this number of children devices (nested) it works as expected.
The problem comes when listing the devices, the UI does not list the last device (Module):
In other words children are active endpoints, in some form or another. Isn't a "room" a container for endpoints? You wouldn't "turn off the room" but would "turn off the devices in the room" (Not referring to how it might be used via voice.)
What commands does a room support?
(I have none of these devices but am curious anyway )
I have tried this type of thing as well (initial work on a Unifi Access driver), where the existing concepts from the Unifi Access system generally seem to be best represented by having the parent driver for the overall system, child drivers for sub-sections, then grandchildren (as I referred to them) representing individually controllable devices/elements within those subsystems.
It all worked in my initial testing (I thought Hubitat might choke having children of children). It seems a bit funny in the code at times but it had no real problems. But they do not get represented as @syepes points out in the devices screen.
I am not sure where the limit of nested devices should be for Hubitat... but at the least it might be nice if it gets further than parent/child.
Since the Unifi Access stuff is pretty esoteric I have not focused on it too heavily and did not really think to bring it up until I saw this post.
@mike.maxwell | @bravenel
What do you think of allowing 1 or 2 extra levels in the UI?
This would be suitable for most of the community use cases and should not affect the current UI layout:
I’m in the process of Developing Apps and drivers for Advantage Air MyAir ducted Airconditioning system. It has a similar hierarchy where it has 3 levels of device because the My Air Systems support multiple AC units (controllers) and each AC unit can have different AC zones.
MyAir AC -> Controller # -> Zones
So my architecture for my App and Drivers (in progress) is as follows:
App for discovery of MyAir AC Systems. Creates a Child App when it finds a MyAir System on the local subnet. Also performs rediscovery to make sure the IP of the system doesn’t change and updates the child App if it does.
-> Child App is for maintaining an inventory of each MyAir System (can have multiple AC units). The inventory creates a Parent Device based (in progress and needs further development) on the inventory for each AC unit (controller)
—> (Parent) Device which is effectively a master Controller and thermostat for the AC unit
—-> Child Device for each of the Zones. There are two types of devices because one is a Dumb on/off zone and the other acts as a Themostat Zone.
I’m currently at the stage were I have The discover App, and Child App Working. I have a stand alone Parent Device and Child devices working with a couple of known problems that when i complete the Child App managing the Parent device it should sort most of my known issues out. Squeezing in development time is a little tough so I’m a few months from probably finishing it all, but I have a direction and just need to work around the limits of the Hubitat System. All up I will finish the project with 2 Apps and 3 Drivers…learning groovy along the way (sysadmin background…so I’m naturally picking up and adapting my skills on the fly). Will my Apps/drivers work…yeah, could it be more efficient from a coding aspect…definitely.
So for your custom drivers, maybe have the App handle events that relate to the Home, that can interact with other Apps and treat your room devices as the parents? Just another way to approach it maybe?
We are always looking to improve the UI, and have projects underway to do so. We certainly can't commit to your specific idea. There are multiple possibilities, and our challenge is to move forward the best improvements we can.
)
