We’re all thinking alike here, I think.
I think the (current) more “Vera standard” practice is to make monolithic devices so you can have a unified UI for all the components, but @therealdb is correct, a better device architecture is to push the individual components out to separate child devices. It would be a very useful enhancement to the Vera UI to be able to create a unified device interface from parent device and all its children combined. This would also more easily allow a default UI when the device type is not known: the presenter can simply go through the parent and child devices presenting the UI elements it does know (as if they were separate devices, but again, in a more unified presentation). This is the same idea as @Vpow expressed in describing the “one variable per row”–I’m saying it should be more expansive: one device per row.
Basically, too many devices in the Vera world are built around the “is a” thinking rather than the “has a” thinking.
Since @therealdb mentioned thermostats, let’s take that example. The current model in Vera is to try to describe all the capabilities and inconsistencies of all makes and models within one device type (the “is a” approach). This has led to UI7 itself contains device/make/model-specifc exceptions, a horrible breach of encapsulation that has ultimately led to a set of interface objects and controls that are difficult (and in a few instances impossible) to make work properly for a non-Vera device (plugin), even when using all-native types–the UI’s exceptions don’t apply. The overuse of device type as inference data for device capabilities is a flawed premise as a long-term strategy.
Now, let’s imagine the “has a” approach: A thermostat is a container that provides coordinated control over a set of devices: it has a temperature sensor, and by comparing the reading of that to a setpoint is has, it can turn on or off the air handling unit it has. Simplest thermostat: there is a heating unit (on/off), a temperature setpoint, and a temperature sensor (for reading ambient). That would be four devices (the master and three children), each having its own very simple, basic UI. A heating/cooling system would simply have either an additional air handler for cooling, or a combined heating/cooling type as appropriate to its implementation. If the thermostat has separate heating and cooling setpoints, it would have an additional setpoint device. If it had humidity sensing and a humidifer, it would have additional child devices: a humidity sensor and a humidifer control (probably just a binary switch). The mix and match expresses the capabilities of the device, not the device type. Then, if the Vera UI allowed the specification of a unified UI for the thermostat, that would be used, presumably drawing on the child devices. If no custom unified UI was created, however, the Vera UI could still present a unified dashboard card by presenting, piece by piece, the standard UI for each child. Temperature sensors already have a standard UI. Switches already have a standard UI. The focus of building a UI for the device shifts away from specifying inidividual controls to choosing devices as components (higher level).
As we all recognize, you can do the parent-child relationship today. We could start building better devices immediately. The cost of that today, though, as I said earlier, is in the absence of a mechanism for creating (or self-generating) that unified parent-child UI, you force your customer to deal with the myriad devices that the parent-child relationship creates.
But… Vera’s does not need to be the only UI… (cough… hint… @amg0)…
