I have an idea that would help for building out custom UI / widgets for devices, and it is centered around the concept of defining metadata for functions / variables on the firmware level. Like exposing another variable, for instance, that links functions and variables in a standardized way to help applications understand what types of actions and states are available by the firmware. Different types being, slider, switch / toggle, gauge, text input, JSON input, number input, floating-point input, for example.
As a simple example, let's say I have a function, called led_toggle, and there is a variable, led_status, that represents whether or not this LED is turned on/off. That function and variable, together, represents a state. That state could be controlled through various methods, like a text input box where the user can type in on or off, or it could be a toggle switch that reflects the current state, and allows the user to toggle that state (set the desired state and wait until the real state is reflected back). Ideally, a switch would be the easiest and best way to interface with this desired functionality.
In order to achieve this, there needs to be some sort of metadata that ties the function, led_toggle and led_state, and says, "hey, this state, LED state, can be represented with a switch UI element, and this variable, led_state, returns a boolean that represents the state, and there is a function, called led_toggle, that influences the state. The available arguments to this function are on and off, where on represents True and off represents False"
Effectively, you can have a state be represented with multiple functions and variables, all that can be defined in the firmware (so there is one source of truth), and that way the developer can make UI that dynamically renders the appropriate widgets in order to interact with those states. This allows for a clearly defined feedback loop that is defined in a single place.
The metadata can also provide insight into the type of units for that state, say for instance if it should be a temperature reading in C or F, or a current reading in A or mA. You could also provide unit conversions or alternate units in this metadata as well, so the frontend never has to provide its own unit conversions.
This metadata would ideally be stored in the Particle cloud, so even if our device is offline, we still can obtain the "shape" of the device and see what actions / states are available to it, and thus allow our frontend to pull historical data for that device since the metadata is stored. Basically, the metadata always represents the last reported metadata definition by the device.
To recap:
State metadata is tied to a firmware version
State metadata would be stored in the particle cloud
State metadata clearly defines what variables are linked to what functions (establish a feedback loop)
State metadata defines what arguments are accepted for specific functions (if applicable)
State metadata defines the appropriate UI type that should be used to allow users to interact with the desired functionality (depending on the type of UI, only certain arguments would be allowed, and some would have default values, like a Toggle Switch)
Thoughts on this?