I would argue that the standard way of doing it would be to use capabilities in the first place instead of “flows only” because this not only gives you an ui-component but it also create insights and let you see the history which is impossible with “flows only”. As a bonus the flows are also created automatically so you don’t have to do that at all. Though, in your case I see that this causes some minor complications as to how to adapt to the legacy code to avoid non-breaking changes and avoid having multiple flows doing the same thing.
I understand that the main points against adding it as capabilities could be that:
- It creates an unwanted ui-component
- but that can be disabled with uiComponent: null
- It creates unwanted extra flows
- This can be avoided if you create the capabilities as sub-capabilities (so
measure_current.offeredwould be fine)
- This can be avoided if you create the capabilities as sub-capabilities (so
If you would want to go for a standard, I suggest that you do the same as the Easee app, which has this exposed as capabilities with names:
measure_current.offeredandtarget_charger_current(though, if you don’t want the flows you could name ittarget_current.chargerinstead
I would much rather have it exposed as a capability because having it as an API will need the other applications to ask for permission in app.json, which when added will disable automatic updates of the app, which is an unwanted situation for me because the big majority of my app users doesn’t even have Tesla chargers. In fact, any API’s for doing this, no matter how standardized it is made, will not make communication with other apps work out of the box as everyone needs to add the permission and push new updates of the app just to make it compatible with the Tesla charger, which defeats the purpose of a standard, it will not work out of the box. And I would argue that the Tesla app users would appreciate having the insights for the target current as well, so it’s better for you to have it as a capability as well.
