Hello again,
I see a lot of confusion in this thread and I think that is related to the way we each see the ST platform as a whole.
I’d refer to a previous thread I did on this topic.
In my book, a device type is a device controller (not just an UI). This device controller is instanciated into individual devices in our homes. A device type should be autonomous and self contained.
A device type should not rely on any other smartapps for its day-to-day operations. I know that it’s not the case with the current ST architecture, hence my previous posts on the topic. The current tight coupling required between the service manager (smartapp) and its child devices is not a good engineering practice as it can introduce failure points, especially in a cloud/local processing distributed environment. On top of it, the current architecture does not allow us to use any inherited methods/attributes from the parent which is quite restrictive.
A smartapp should be just an app that uses the device controller for a specific task or within a broader workflow.
So, all the capability theads I’ve posted are related to my view of the ST platform.
A device controller should be able to specify to its hub or its cloud containers what non functional requirements (e.g. multiThreading, localProcessing, highPriorityProcessing, strongAuthentication) it requires to interface with the world around it.
I suggested using Capabilities to do so. Maybe, it should be called something else in the ST development environment, but it does not change the fact that we need those capabilities within the device controller to achieve high performance and reliability.
My 2 cents.
P.S. Please refer to my github:
GitHub - yracine/device-type.myecobee: SmartThings-ecobee integration
for a concrete example of a service manager (My ecobee Init) which does not do much (except instanciating child devices at their creation and polling them from time to time). The custom ecobee device type that I created is really self contained and autonomous from its parent (it does not call its parent to realize its functions). Due to the current cloud-to-cloud limitations, it only refers to its parent for refreshing its access token when needed, but that’s all.