Idea to Assist with Custom UI and Dashboard Generation

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?

@nicolasmontoya ,

You are on a very important point and one that I have been focused on lately.

I assume you have seen the Particle Ledger and Logic announcements from Spectra:

When Ledger launches, the "state" or "shape" as you said will be stored the in the cloud and can be queried even when the device is off-line.

Still, it remains to be seen what this means in firmware. I have been working on collapsing the Particle variables and functions into a single "cmd" function that would parse a payload and either provide the data requested or make the needed change to the configuration of the device. It works well, but it needs work when the device is off-line and until Ledger arrives, we have been working on another approach which will work until we can use ledger.

Does this sound close to what you are trying to do?


1 Like

This seems like the use case that Ledger is intended to solve. It implements storage of data in both the cloud and device, so it is available when the device is offline on both sides. Data can be set from the cloud side or device side and is synchronized when the device is online. Change notification is available on both the cloud and device side.

1 Like

Hi Chip,

Yes! That sounds very similar to what I was thinking, I have signed up for the Ledger beta but I am still waiting to get in so i can play with it.

Another feature that would be nice to have, is the ability to define what type of UI element should be used to interact / view with that state (as a state may be interactable or not, like an IAQ reading vs relay control). I suppose the Ledger could contain a variable that represents the intended interface?

Do you think it would also be possible to set constraints on what the available arguments are to interactable states? For instance, if we have a state that controls the PWM of a fan, we may only want the device to accept percentages of 20%, 50%, 75%, and 100%. Even though that will be protected by the firmware anyways, it would save time and complexity for the user as they won't have to track validation logic for each state on the cloud; the user would receive a list of available arguments for that state via the REST API (for dynamic inputs there could be a min/max range, or null to allow for any value) and their app will handle rendering the proper UI from there.

Also, it would be nice to units associated with the data so our custom backend doesn't have to keep track of what units are being represented, all the source of truth is defined with the Device OS and/or Particle Cloud.

The idea behind this is that the user doesn't need to embed Particle-specific features into their app, so they don't feel as invested in a certain solution / platform and can more easily move off to another platform or make their own solution if needed; as Particle will be the source of truth for the interaction of and viewing of states, with all the info they may need.

Perhaps it would be easier to add this additional metadata on the Particle console after the states have been uploaded? Instead of trying to define everything in the firmware? Not entirely sure what would be easier based on the current infrastructure.

Hi Rickkas,

That change notification feature sounds awesome! Would this be similar to an alerting system? i.e. can we setup alerts that tell Particle to notify us if a sensor reading goes out of a predefined range after a certain period of time? We can then pipe those notifications to our backend to then fanout to multiple users of interest.

It's not actually an alerting system, but ledger change notifications work as a callback function on-device, or on the cloud side an event can be generated which can trigger a webhook to communicate with an external service.


Oh ok I see, so we can setup cloud logic to generate an event if a topic's data meets some condition? So the cloud is able to filter a packet, extract the data, and then trigger a webhook?

1 Like

Yes, but not really a packet. It's not acting on a publish, for example.

A logic function can be called in response to a ledger change on either side. This logic function runs in the cloud and can make decisions based on your own business logic, then trigger a publish to an external service.