UI Development

Now we have the toolchain installed, a microcontroller running some example code, and a working UI sandbox, lets customise the template to control the hardware!

Editing the template

Open the arc generated project folder hello-electric with your IDE/text editor of preference. We strongly recommend VS Code, as the real-time Typescript hinting integration works wonderfully.

The main application sources are in /src/application/pages/DevicePages, with OverviewPage.tsx being the first main view. Open it in your editor and you'll see the layout of the page.

Typescript files start with imports at the top, followed by the component definition OverviewPage which contains the UI layout.

  1. // Component imports belong at the top
  2. import React from 'react'
  3. ...
  4. import { Printer } from '@electricui/components-desktop'
  5. // OverviewPage is an exported React function which renders a layout
  6. export const OverviewPage = () => {
  7. return (
  8. // UI Layout goes here
  9. <React.Fragment>
  10. Internal battery level: <Printer accessor="batt" />
  11. </React.Fragment>
  12. )
  13. }

The hello-blink demo firmware exposes LED blinking parameters, allowing you to vary the frequency, enable/disable blinking, and manually override the LED state. We'll build out the UI and firmware to provide better control over the hardware.

Displaying data as text

The template already has some simple components to visualise the hello-blink example. We'll be adding more components to the UI to get started.

We want to print the led_state variable as text, so we'll use a Printercomponent and some human readable text. Electric UI components use an accessor property to provide the data source.

import { Printer } from '@electricui/components-desktop'

We'll import it at the top of our file, then use the <Printer /> component in our layout.

LED state: <Printer accessor="led_state" />

The printer can go anywhere inside the <React.Fragment> ... </React.Fragment> block, but we suggest above the slider (inside the <Card> block).

Save the source file, the UI will update and you should see the text changing as the light on your hardware blinks.

If you play with the slider, you'll notice that the led_state doesn't always keep up with the hardware LED state, and for rapid blinking, the graph shows the wrong shape. You might have heard of Nyquist Theorem before, and the slow polled variable requests made by the template are responsible.

Polling hardware for data

The template includes a IntervalRequester near the top of the body which requests variables every 250 milliseconds.

  1. <IntervalRequester
  2. variables={['led_state', 'led_blink', 'lit_time']}
  3. interval={250}
  4. />

Change the interval to 50ms, save, and see at how this changes the graphed data.

Faster polling interval makes the graph more accurately represent the blinking light

While its tempting to continue 'increasing the polling frequency', its not the best way to capture rapid changes in state. Likewise, it's inefficient to waste bandwidth polling settings or sensor data more often than the underlying data changes.

Pushing UI updates from hardware

Instead of polling the microcontroller periodically for variable states, we will change the embedded firmware to send updated led_state data as the changes occur.

Open up your microcontroller's editor to make a small tweak to the demo firmware flashed earlier.

Add a eui_send_tracked( "led_state" ); function call to the blink logic, reflash your hardware, and play with the UI.

  1. if( millis() - led_timer >= glow_time )
  2. {
  3. led_state = !led_state; //invert led state
  4. led_timer = millis();
  5. eui_send_tracked( "led_state" ); // send the new value to the UI
  6. }

The UI is now updating as soon as the LED changes state, and the graph should properly represent the blinking LED's behaviour.

Hardware pushed variables are lowest latency and best represent the hardware's blinking light

Lets add a two-state switch to toggle the blinking behaviour on and off. We're going to use a Switch component.

We've already imported the Slider component from that package, so just add the Switch import to the same import.

import { Slider, Switch } from '@electricui/components-desktop-blueprint'

Then, just below our Printer, lets add the switch.

  1. <Switch
  2. unchecked={0}
  3. checked={1}
  4. accessor={state => state.led_blink}
  5. writer={(state, value) => {
  6. state.led_blink = value
  7. }}
  8. >
  9. Toggle LED Blinker
  10. </Switch>

It accepts the unchecked and checked properties which let you specify the intended state of the variable.

For the switch to show the correct position as the hardware changes state, we use the accessor property to specify the input state.

When you click on the switch to toggle the setting, you are writing a new value against the current state. This is done using the writer property, where we update the led_blink state with the value given to us by the component.

Toggling the switch will stop the blinking, but the LED will stick in an ON or OFF state when the mode changes.

The switch lets us stop the blinker at will

Try adding another Switch, or a Checkbox component to manually set the led_state variable to 0 or 1 while led_blink is disabled.

Cleaning up the layout

Some new components have been added, but any reasonable UI will need the ability to group and position components to control their UI layout.

Compositions form the skeleton of the UI, providing rules which format the UI components. The template uses the areas feature to define the arrangement of zones which are used during layout.

  1. const layoutDescription = `
  2. Chart Chart
  3. Light Slider
  4. `

Rectangular grid of boxes (chart chart light slider) representing the layout

Because the Chart area was referenced twice, the layout engine treats them as one larger area. This templated layout is used in the composition by passing in the description to the areas property:

  1. <Composition areas={layoutDescription} gap={10} autoCols="1fr">
  2. {Areas => (
  3. <React.Fragment>
  4. <Areas.Chart> ... </Areas.Chart>
  5. <Areas.Light> ... </Areas.Light>
  6. <Areas.Slider> ... </Areas.Slider>
  7. </React.Fragment>
  8. )}
  9. </Composition>

We're going to put another Composition inside the <Areas.Slider> area to arrange the Printer and Switch components like so:

Nesting compositions allows rich layout behaviour to be easily declared

  1. <Composition templateCols="1fr 1fr" margin={10}>
  2. <Box>
  3. LED state: <Printer accessor="led_state" />
  4. </Box>
  5. <Box>
  6. <Switch
  7. unchecked={0}
  8. checked={1}
  9. accessor={state => state.led_blink}
  10. writer={(state, value) => {
  11. state.led_blink = value
  12. }}
  13. >
  14. Toggle Blinker
  15. </Switch>
  16. </Box>
  17. </Composition>

The templateCols="1fr 1fr" property tells Composition that we want the layout to use two evenly sized columns. We add some spacing from our parent Card by setting the margin.

After saving, the components will position themselves horizontally.

The nested composition controls the layout of the printer and switch

Try vertically centering the layout by adding a justifyItems="center" property to the Composition. The layouts article teaches the power of composition driven layouts in more detail.

Moving on

With the basics worked out, you can start making a UI for your own project!

We strongly recommend reading the debugging, layout and custom data structures guides as a primer on the most important areas during development.

Theelectricui-embedded/examples/demonstrations folder has a set of self contained demos which expose simulated data for examples like water heaters, garage doors or test equipment. Try building a simple UI against simulated data, or dive into your own project!