I want to build a new Cloud Connected device integration. The device I want to integrate has no local interface, so it seems like the more scalable and maintainable path vs dumping lots of HTTP code into a classic DTH.
I would like to try the STSC migration tool. Theres’s nothing special about my environment that can’t be migrated based on what I’m seeing. Is there a way to opt in?
Where is the promised documentation for building custom device UIs in the new app? For the device I’m trying to connect (a pool automation system) the built in Capabilities are not sufficient. I can see exactly how they would work though if I could define a few new ones and extend a few that already exist! Frankly I’ve always hated the coupling between DTH and UI layout in the classic app and find this path liberating… if I can just extend it.
There are no custom capabilities for the new app, nor can you edit the UI for existing capabilities.
The UI will display based on the capabilities you have selected, either using groovy or using the new developer workspace. The only extra thing as far as I can tell that you can do with the developer workspace is specify which capability displays on the tile from the rooms overview (Otherwise, it seems to select it based on some kind of priority. For example, if I add the switch capability in groovy it will display the switch on the tile).
My pool automation system can be modeled as 4 components with subcomponents:
A pump with 4 speeds - needs 4 buttons to select preset speeds, needs master switch for on/off, needs to report an RPM value, needs to report energy use
A salt water chlorine generator - needs ta slider allowing output to be adjusted in 5% increments, needs a boost mode button, needs to report a salt number and temp number.
A color light - needs 14 buttons to select one the available modes and show which is active, needs to report energy usage
A heater - this is the only component I can see how to model today with the existing thermostat component
Even if I did these the old Groovy way, I can’t see how STSC would display the controls, given I can’t figure out how to model them from existing Capabilities. Am I missing something?
heater > thermostat mode, thermostat heating set point, thermostat operating state
light > color control & or color temperature
pump > switch, fan speed
saltwater > switch level, temperature measurement
these are just a few ideas. my recommendation is to try capabilities in groovy and see what will work for you. to test them in the app you’ll need to add the capability to the metadata and then initialize each capability with a send event.
one problem is you may run out of room. I think you can only display so much in the new app before it stops letting you add more to the UI. to get around this you can perhaps develop each component as a separate device, for example pool light and pool heater each as a separate DTH.
I’m not a huge fan of the developer workspace because my approach to programming is more poke and change, its easier to instantly see results by changing something in groovy and refreshing the app, especially ui changes (you’ll need to delete and readd the device each time you do something that messes with the ui like adding or removing capabilities)
BUT if you’re starting from scratch the developer workspace is probably easier? Once you have the capabilities decided for the UI anyway.
@cjisndenial We will be releasing a tool to create custom capabilties soon. For now your unsupported capabilities will not be available in the app or automations.
Thanks @jody.albritton much appreciated. Is there anything I can do to prepare for the editor? For instance should I start making custom Capabilities using the legacy IDE because that will be necessary to support the C2C connectivity? Or should I just wait?
Thanks @mvevitsis for the capability suggestions. However the devices work a bit differently than the capabilities express. For instance the color lights only support a discreet set of 14 pre-defined modes. So the normal color picker capabilities would not be appropriate. Looks like I definitely need custom capabilities for some of these features.
@cjisndenial the new cloud connected devices model does not require groovy. You can build your solution with the custom capabilties in mind today, they just won’t work properly until you can geneate the capabilties on our platform and generate the UI for the mobile app.