1 of 100

next-snapshot

EdgeTX LUA Reference Guide

This guide covers the development of user-written scripts for R/C transmitters running the EdgeTX operating system with Lua support. Readers should be familiar with EdgeTX, the EdgeTX Companion, and know how to transfer files the SD card in the transmitter.

The latest version of this guide will always be available here. At the top of the left sidebar there is a version option if you are running an older version of EdgeTX and need the docs for that specific version.

Sections

Chapter

Content

Covers various topics of LUA implementation in EdgeTX operating system system

Reference of all constants and functions available in EdgeTX LUA API

EdgeTX LUA programming guide that covers coding techniques with examples.

EdgeTX LUA development support

Quickest way to get support from seasoned EdgeTX LUA developers is to join our Discord server and ask on dedicated #lua channel

Join the chat on Discord

LUA Reference guide collaboration

Please feel free to make suggestions or corrections to the documentation.

Preferred method of editing is to use GitBook, as it uses WYSWIG editor allowing two-stage publication. If you want to change or add whole page or become collaborator <decribe what to do>.

Project support

The EdgeTX team has no intention of making a profit from their work - EdgeTX is free and open source and will remain free and open source. However, the project is more expensive to maintain than most open source projects. This in mainly because there is a never ending flood of hardware to integrate and maintain code for. Hardware that costs. In addition, in order to develop for this hardware, certain specalised test and measurement equipment is also required.

In order to support this, EdgeTX has chosen to use OpenCollective to allow for donations from the community, as well as funding from manufacturers who choose to partner with and sponsor the project. This also allows for transparent accounting of what the funds are spent on.

Please visit our OpenCollective page if you would like to financially help support the project!

Overview

This section covers various topics of LUA implementation in EdgeTX operating system system

Topic

Description

LUA Basics

Brief introduction to LUA language

LUA Version and included libraries

Dut to memory limits not all standard LUA libraries are included in EdgeTX embedded version of LUA interpreter & compiler.

Script Types

EdgeTX allows to use various LUA scripts for different purposes. Here you can check which one suits your needs.

Lua Basics

Lua is a small but powerful language. This section will explain a few of the most important concepts.

Introduction

Lua was chosen for EdgeTX, because it is a small language designed to be highly extensible by libraries written in C and C++, so it can be integrated into other systems like EdgeTX. It is also relatively efficient, both in terms of memory and CPU usage, and hence well suited for the radios.

In addition to the provided libraries, Lua has a very elegant mechanism for loading new Lua code modules during run-time. A lot of the elegance comes from the way that the loading mechanism meshes with another concept supported by Lua: first class functions with closures.

First Class Functions

Computer science pioneer Christopher Strachey introduced the concept of functions as first-class objects in his paper Fundamental Concepts in Programming Languages from 1967. What it means is that functions can be treated as other variables: as arguments passed in function calls, as results returned from function calls, and a function identifier can be re-assigned to another chunk of function code, just like a variable ca be assigned to a new value.

In Lua, a function declaration is really "syntactic sugar" for assigning a variable to the chunk of code that is called when the function is invoked, i.e.

local function f(x) return x + 1 end

is the same as

local f = function(x) return x + 1 end

You can even add functions to Lua tables, i.e.

t = { f = f }

will add the above function to the table t, as a field that is also called f. Does that look familiar to the return statement required at the end of a Lua script?

Yes indeed, because a script is really an anonymous function that returns a list of functions to the system. The function declarations assign variables to chunks of function code, these variables are added to the list returned at the end of the script, and the system then calls the functions periodically to run the script. So the script itself is run one time initially, and subsequently the functions returned by the last statement are called periodically.

Closures

Another important concept that goes with first-class functions, is closures. This is the environment of the function with the variable names that the function can see. Please consider the following function counter that returns another function:

local function counter(start, step)
  local x = start

  return function()
    local y = x
    x = x + step
    return y
  end
end

The function is returned directly without being assigned to a variable name. The closure of the function returned is the body of the function counter, containing both the arguments start and step, and the local variable x. So if c1 = counter(1, 1) then c1() will return 1, 2, 3, ... when called repeatedly, and if c2 = counter(2, 3) then c2() will return 2, 5, 8, ...

Likewise, the local variables that you declare outside the functions of your script can be used by all of the functions in your script, and they persist between function calls, but they are not visible to other scripts.

The widget scripts are a little trickier, as you can register multiple instances of the same widget script, and all of these instances run within the same Lua closure. Therefore, local variables declared outside any functions in a widget script are shared among all of the instances of that script. But each call to the create(...) function returns a new widget list to the system. And since this list is unique to each instance, you can add private instance variables to it.

Functions with Variable Number of Arguments

Please consider this function:

local function match(x, ...)
  for i, y in ipairs({...}) do
    if x == y then
      return true
    end
  end
  return false
end

It takes an argument x and a vararg list ... A vararg list is just like a list of arguments separated by commas, and you can call the function with any number of arguments greater than 1. Inside the function, you can also treat ... like a comma separated list of variables, e.g. in the above function, ... is converted to a table by {...} just like you could construct a table by e.g. {a, b, c}. The table is iterated with the ipairs function to look for an element matching the first argument x. So e.g. the following statement

if event == EVT_VIRTUAL_ENTER or event == EVT_VIRTUAL_EXIT then

can be replaced by

if match(event, EVT_VIRTUAL_ENTER, EVT_VIRTUAL_EXIT) then

You can also use ... directly as a comma separated list of values, e.g. local a, b, c = ... will assign the three variables to the three first arguments following x, or nil if none are given.

LUA version and included libraries

LUA Version

EdgeTX 2.10 uses LUA interpreter and compiler version 5.2 For detailed reference read

Included standard libraries

Lua Standard Libraries

Comment

io Library

Standard LUA io library has been simplified and only a subset of functions and their functionality is available.

Available functions:

io.open()
io.close()
io.read()
io.write()
io.seek()

Examples

Read the whole file

-- this is a One-time script

local function run(event)
  print("lua io.read test")         -- print() statements are visible in Debug output window
  local f = io.open("foo.bar", "r")
  while true do
    local data = io.read(f, 10)     -- read up to 10 characters (newline char also counts!)
    if #data == 0 then break end    -- we get zero length string back when we reach end of the file
    print("data: "..data)
    end
  io.close(f)
  return 1
end

return {  run=run }

Append data to file

-- this is a One-time script

local function run(event)
  print("lua io.write test")
  local f = io.open("foo.bar", "a")        -- open file in append mode
  io.write(f, "first line\r\nsecond line\r\n")
  io.write(f, 4, "\r\n", 35.6778, "\r\n")  -- one can write multiple items at the same time
  local foo = -4.45
  io.write(f, foo, "\r\n")
  io.close(f)
  return 1    -- this will end the script execution
end

return { run=run }

Script Types

This section introduces the types of Lua scripts supported by EdgeTX and how they may be used.

One-Time Scripts

Purpose

One-time scripts are used mainly to perform tasks that are not connected with flying. In example ELRS configuration LUA script. They do their task and are then terminated (by user or function) and unloaded.

Execution & Lifetime

Script is executed when user selects "Execute" on a script file from SD card browser screen, or opens a Lua Tool, or creates a new model with a Wizard script.

The script executes until:

it returns value different from 0 (except returning string that contains new script name to be executed)
is forcefully closed by user by long press of EXIT key
is forcefully closed by system if it misbehaves (e.g. run-time error or low
memory)

Running a One-Time script will suspend execution of all other currently loaded Lua scripts (Custom, Telemetry, and Functions). They are automatically restarted once the One-Time script is finished. This is done to provide enough system resources to execute the One-Time script.

File Location

One-Time Scripts can be placed anywhere on SD card, however, the folder /SCRIPTS/ is recommended.

If One-Time Script is placed in special folder /SCRIPTS/TOOLS it will be visible in EdgeTX RADIO>TOOLS tab To give this One-Time Script unique name place at the beginning of lua script line: -- toolName = "TNS|ScriptName|TNE

Otherwise script's filename will be used to display in RADIO>TOOLS list.

Wizard scripts must be stored in the same subfolder of /TEMPLATES/ with the same "first name" as the template file using it. Some Wizard scripts are just small scripts that load one of the common scripts located in /SCRIPTS/WIZARD/.

Interface

Every script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:

Parameters

Return values

Parameters none

Return Values none

Examples

Simplest one-time LUA script

Because 0 is returned all the time this script will continue running until user long press EXIT (RTN) key.

One-Time LUA script with initialization and exit feature if user short press and release EXIT (RTN) key

Telemetry Scripts

Purpose

Although they are named "Telemetry scripts" in fact they can be used to perform constant task while running in background. Telemetry scripts are mostly used for building customized screens that are avalilable to user directly from main screen using key shortcut. Each model can have up to three active scripts as configured on the model's Telemetry configuration page. The same script can be assigned to multiple models.

Telemetry scripts are only available on radios with B&W LCD screens, such as e.g. FrSky Taranis models (including Xlite), Radiomaster TX12, Zorro, Boxer or Jumper T12. Read more about <radios>.

Execution & Lifetime

Telemetry script is loaded and executed when model is selected. Script executes until:

it misbehaves (e.g. run-time error or low memory)
is running. When One-time script finishes execution, Wigdet Script resumes execution.

File Location

Telemetry scripts are located on the SD card in the folder /SCRIPTS/TELEMETRY/.

Telemetry script file name length (without extension) must be 6 characters or less

Interface

Every Telemetry script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:

Field

Type

Required

Desctiption

Parameters

Return values none

Parameters none

Return Values none

Parameters none

Return Values none

Examples

Widget Scripts

Purpose

Widget scripts are avaiable on radios equiped with color LCD. They are designed to run constantly in the background performinfg various task. Widget scripts are mostly used to extend EdgeTX functionality via Widgets that are places by user on Main Views. They are equivalent of Telemetry Scripts on radios equiped with B&W LCD.

Most of the time, widget scripts show some info in a Widget's zone in one of the user defined Main Views. They cannot receive direct input from the user via key events with exeption of being displayed in so called Full Screen mode. Full screen mode can be entered by selecting the widget, pressing ENTER and selecting Full screen from the widget's contextual menu, ~~or by double tapping the widget on radios with a touch screen~~. Full screen mode can be exited by long pressing the EXIT (RTN) button, or by calling the Lua function lcd.exitFullScreen().

Each model can have up to nine Main Views, with up to 8 widgets per screen, depending on their size and layout. Each instance of a widget has his own options table.

Widget scripts are only available on radios with color LCD screens, such as e.g. FrSky X10 or X12, Radiomaster TX16S, Jumper T16 or T18, Flysky NV14., etc. Read more about radios.

Execution & Lifetime

All widget scripts on the SD card are loaded into memory when the model is selected, even widgets that are not used. This has the side effect that any global functions defined in a widget script will always be available to other widget scripts. It also means that any Widget Script placed in proper location on the SD card will consume part of the radio's memory - even if it is not being used.

It is important to either keep Widget Scripts small, or to use Lua's function to load code dynamically

Script executes until:

it misbehaves (e.g. too long runtime, run-time error, or low memory)
One-Time script is running. When One-time script finishes execution, Wigdet Script resumes execution.

File Location

Widget scripts are located on the SD card, each one in their specific folder: /WIDGETS/<folder name>/

Widget script folder name length must be 8 characters or less

Widget script name is constant and has to be named main.lua

Example of proper Widget script placement to be registered by EdgeTX as valid Widget script available to user in Widgets selection menu: /WIDGETS/MYWGT/main.lua

Try to use unique folder name. In case of naming clash, previously installed widget will be overwritten.

Interface

Every Widget Script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:

The name length must be 10 characters or less.

options table is passed to create function when invoked and then stored in Lua. Changing options table values while Widget script is running has no effect. This table is designed to be changed with EdgeTX system menus.

If options is changed by the user in the Widget Settings menu, then update will be called with a new options table, unaffected by any changes made by Lua code to the old options table.

Parameters

Return values

The size of the widget's zone area is as follows:

Full screen mode: LCD_W by LCD_H
Not full screen mode: zone.w by zone.h (updated if screen options are changed)

If local variables are declared outside functions in the widget script, then they are shared between all instances of the widget. Therefore, local variables that are private for each instance should be added to the widget table in the create function before returning the widget table to EdgeTX.

Parameters

Return values none

Parameters

Return values none

Parameters

Return values none

if you want background function to run when the widget is visible, then call it from refresh function.

Examples

Function Scripts

Purpose

Function scripts are invoked via EdgeTX 'Lua Script' of Special Functions configuration page.

Typical uses of Function scripts are:

specialized handling in response to switch position changes
customized announcements

Execution & Lifetime

Function script is loded when model is selected. Script executes until

it misbehaves (e.g. run-time error or low memory)
is running. When One-time script finishes execution, Wigdet Script resumes execution.

Function scripts DO NOT HAVE ACCESS TO LCD DISPLAY

File Location

Function scripts are located on the SD card in the folder /SCRIPTS/FUNCTIONS/

File name length (without extension) must be 6 characters or less

Interface

Every Function script must include a return statement at the end, defining its interface to EdgeTX.

This statement returns a table with the following fields:

Parameters none

Return values none

Parameters none

Return Values none

Parameters none

Return Values none\

Example

Mixes Scripts

Don't use Lua Mixes Scripts for controlling any aspect of your model that could cause a crash if the script stops executing!

Purpose

Mixes Scripts take one or more values as inputs, do some processing in Lua code, and output one or more values. Each model can have several Mixes Scripts associated with it, and these scripts are run periodically. They behave similarly to standard EdgeTX mixers, but at the same time they provide a much more flexible and powerful tool.

Typical use cases:

replacement for complex mixes that are not critical to model function
complex processing of inputs and reaction to their current state and/or their history
filtering of telemetry values

Execution & Lifetime

Mixes script is loded when model is selected. Script executes until

it misbehaves (e.g. run-time error or low memory)
is running. When One-time script finishes execution, Wigdet Script resumes execution.

Limitations

cannot update LCD screen or perform user input.
should not exceed allowed run-time/ number of instructions.
custom scripts are run with less priority than built-in mixes. Their execution period is around 30ms and is not guaranteed!

If the script output is used as a mixer source , and the script is killed for whatever reason, then the whole mixer line is disabled!

Mixes Scripts should be as short as possible, to avoid delays. It is also important to keep in mind that other loaded Telemetry and Function scripts can add to the response time, or worse: hang the system!

To enable Mixes Scripts, firmware must be compiled with the option LUA_MIXER=Y.

File Location

Mixes scripts are located on SD card in folder /SCRIPTS/MIXES/

File name length (without extension) must be 6 characters or less

Interface

Every Mixes Script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:

This function is called periodicaly when script is running. Parameters Variables matching those used in input table Return values Variables matching those used in output table\

This function is called once when Mixes Script is loaded and executed for the first time

Parameters none Return values none\

The input table defines what values are available as input(s) to custom scripts.

There are two forms of input table entries

SOURCE

SOURCE inputs provide the current value of a selected OpenTX variable. The source must be selected by the user when the script is configured. Source can be any value that EdgeTX knows about (inputs, channels, telemetry values, switches, custom functions etc.). Note: the typical input range is -1024 thru +1024. Simply divide the input value by 10.24 to convert to a percentage from -100% to +100%.

VALUE

VALUE inputs provide a constant value that is set by the user when the script is configured.

name - maximum length of 8 characters
min - minimum value of -128
max - maximum value of 127
default - must be within the valid range specified
Maximum of 6 inputs per script

The output table defines only name(s), as the actual values are returned by the script's run function.

Above names are only visible as source values on the radio screen when the script is running. If the model is edited in Companion, then the values show as LUA1a and LUA1b etc.

Examples

Example of <decribe what it does>.

Example where Lua mix script is used to drive ailerons in some clever way, but control falls back to the standard aileron mix if script is killed. Second mixer line replaces the first one when the script is alive:

Radios

Radios with B&W LCD screen

Manufacturer

Model

introduced in EdgeTX

Radios with Grayscale LCD screen

Radios with COLOR LCD screen

BetaFPV

FlySky

FrSky

Jumper

Radiomaster

TX16S

Technical Data

LUA data

getVersion() name

tx16s

Inputs overview

Internal indexes

Switch Positions List

LUA API Reference

This section describes the Lua libraries, functions and constants that are provided by EdgeTX.

Constants

This section describes various constants that are provided for Lua by EdgeTX.

Color Constants

On radios with color display, a color may be added to the flags described above.

There are two types of color constants: one that is an index into a table holding a palette of theme colors, and one that is just a color.

Indexed colors

These are the theme colors plus CUSTOM_COLOR, and they can be changed with the function lcd.setColor(color_index, color). Please note: if an indexed color is changed, then it changes everywhere that it is used. For the theme colors, this is not only in other widgets, but everywhere throughout the radio's user interface!

COLOR_THEME_PRIMARY1
COLOR_THEME_PRIMARY2
COLOR_THEME_PRIMARY3
COLOR_THEME_SECONDARY1
COLOR_THEME_SECONDARY2
COLOR_THEME_SECONDARY3
COLOR_THEME_FOCUS
COLOR_THEME_EDIT
COLOR_THEME_ACTIVE
COLOR_THEME_WARNING
COLOR_THEME_DISABLED
CUSTOM_COLOR

Literal colors

These color constants cannot be changed:

BLACK
WHITE
LIGHTWHITE
YELLOW
BLUE
DARKBLUE
GREY
DARKGREY
LIGHTGREY
RED
DARKRED
GREEN
DARKGREEN
LIGHTBROWN
DARKBROWN
BRIGHTGREEN
ORANGE

Deprecated color constants

These should no longer be used, but they are included for backwards compatibility. The old OpenTX API had a large number of indexed theme colors, and these have been mapped to the new theme colors as follows:

ALARM_COLOR -> COLOR_THEME_WARNING
BARGRAPH_BGCOLOR -> COLOR_THEME_SECONDARY3
BARGRAPH1_COLOR -> COLOR_THEME_SECONDARY1
BARGRAPH2_COLOR -> COLOR_THEME_SECONDARY2
CURVE_AXIS_COLOR -> COLOR_THEME_SECONDARY2
CURVE_COLOR -> COLOR_THEME_SECONDARY1
CURVE_CURSOR_COLOR -> COLOR_THEME_WARNING
HEADER_BGCOLOR -> COLOR_THEME_FOCUS
HEADER_COLOR -> COLOR_THEME_SECONDARY1
HEADER_CURRENT_BGCOLOR -> COLOR_THEME_FOCUS
HEADER_ICON_BGCOLOR -> COLOR_THEME_SECONDARY1
LINE_COLOR -> COLOR_THEME_PRIMARY3
MAINVIEW_GRAPHICS_COLOR -> COLOR_THEME_SECONDARY1
MAINVIEW_PANES_COLOR -> COLOR_THEME_PRIMARY2
MENU_TITLE_BGCOLOR -> COLOR_THEME_SECONDARY1
MENU_TITLE_COLOR -> COLOR_THEME_PRIMARY2
MENU_TITLE_DISABLE_COLOR -> COLOR_THEME_PRIMARY3
OVERLAY_COLOR -> COLOR_THEME_PRIMARY1
SCROLLBOX_COLOR -> COLOR_THEME_SECONDARY3
TEXT_BGCOLOR -> COLOR_THEME_SECONDARY3
TEXT_COLOR -> COLOR_THEME_SECONDARY1
TEXT_DISABLE_COLOR -> COLOR_THEME_DISABLED
TEXT_INVERTED_BGCOLOR -> COLOR_THEME_FOCUS
TEXT_INVERTED_COLOR -> COLOR_THEME_PRIMARY2
TITLE_BGCOLOR -> COLOR_THEME_SECONDARY1
TRIM_BGCOLOR -> COLOR_THEME_FOCUS
TRIM_SHADOW_COLOR -> COLOR_THEME_PRIMARY1
WARNING_COLOR -> COLOR_THEME_WARNING

Flags and Pattern Constants

Many of the lcd functions accept parameters named flags and patterns. The names and their meanings are described below.

lcd.drawText Flags

Name

Description

EdgeTX ver

Notes

lcd drawing functions flags on B&W LCD radios

lcd.drawLine function patterns

Key Event Constants

Overview

EdgeTX widgets and One-Time scipts can make use of LVGL controls and objects to create the script user interface. In addition to providing much better performance, this gives Lua scripts the same styles applied to firmware LVGL pages and controls.

The LVGL API can be used to add varios objects such as labels, rectangles, circles, buttons, toggle switches, sliders and more. Objects can be grouped, e.g. a rectangle can contain child labels or any other object. Objects can be moved, resized and updated as needed.

Many object properties can be set dynamically through functions in the Lua script - whenever the function returns a new value the objects property is automaticall changed. This removes the need for manually re-drawing the user interface.

Limitations:

Direct drawing via the 'lcd' API is not available for scripts using LVGL to create the UI.

Activating the LVGL API

A script that wants to use LVGL to create the UI must return 'useLvgl = true' in the table returned by the script:

Once activated a new 'lvgl' object will be available to use in the script. This is the primary interface to the LVGL API.

Scripts should check that 'lvgl' is not nil before use. If the 'lvgl' object is nil it is most likely the script is running on an earlier version of EdgeTX (prior to 2.11), or you forgot to set 'useLvgl = true'. Scripts should either display an error or fall back to using the lcd API in LVGL is not available.

Usage patterns

One-Time scripts

One-Time scripts have only two functions. Prior to the LVGL API, the 'init' function would be used to set up the initial state for the script and the 'run' function would re-draw the UI whenever called as well as process key and touch events.

With the LVGL API, the 'init' function should still set up the initial state for the script; but should also create the UI from LVGL objects. The 'run' function may handle key and touch events; but in most cases the LVGL objects themselves will do the heavy lifting. When set up correctly the LVGL UI will be automatically updated as the local state is changed, and the script will be automatically updated as the user interacts with the LVGL objects.

Widget scripts using LVGL should create their UI in the 'update' function using the widget size to determine what elements to create and how to lay them out.

The 'background' and 'run' functions should just update essential state changes that are not being managed directly by the LVGL objects.

API

LVGL objects are created and manipulated using the 'lvgl' functions.

Most of these functions follow the syntax below. A few function have only the optional 'parent' parameter.

lvgl.function([parent], {settings})

Parameter

Notes

Description

parent

Optional (with some exceptions) If present must be an LVGL object

Parent object. If set then whatever LVGL objects are created by the function are set as children of 'parent'. If not set then objects are created in the top level script window.

settings

Mandatory (with some exceptions) Must be a table

Contains all of the settings required to create the LVGL object.

Most of the functions return an LVGL object that can be used to update the UI or in other API calls.

API functions can also be called using Lua OO syntax.

For example the following two lines are equivalent.

lvgl.show(parent)
parent:show()

There are a number of settings that are common to all of the LVGL functions that take a 'settings' table parameter.

Name

Type

Description

Default if not set

Number

Horizontal position of the object relative to the top left corner of the parent object.

Number

Vertical position of the object relative to the top left corner of the parent object.

Number

Width of the object

Auto size to fit content

Number

Height of the object

Auto size to fit content

color

Color or Function

Primary color for the object.

COLOR_THEME_SECONDARY1

pos

Function

Position of the object relative to the top left corner of the script window. Must return a table with two values - x, y.

nil

size

Function

Size of the object. Must return a table with two values - width, height.

nil

visible

Function

Controls visibility of the object. Must return a boolean - true if the object is shown, false to hide it.

nil

The functions associated with settings are called periodically by the firmware. Where a setting is defined using a function, the UI will automatically update whenever the function returns a different value.

A note on object width and height

Although width and height, and the size function, can be defined for all objects they may not be used in some cases. For example when creating a circle or arc object the radius property should be used instead.

lvgl.build

Build a complex UI in a single operation.

Syntax

lvgl.build([parent], {{settings}})

parent:build({{settings}})

Parameters

See the API page for parameter description and common settings.

Build specific settings:

Name

Type

Description

Default if not set

type

String

Mandatory on each table entry to determine what type of LVGL object to create.

name

String

Empty string

children

Table

nil

Return values

Table of named LVGL objects.

Notes

The 'settings' parameter to lvgl.build should be a table of tables. Each inner table creates a separate LVGL object based on the 'type' value.

For example the code below creates two object, a label and a rectangle.

lvgl.build({
    {type="label", x=0, y=0, text="Some text", color=BLACK},
    {type="rectangle", x=0, y=20, w=100, h=100, color=BLACK}
})

Objects can be nested by using the 'children' setting, this should be another table of tables just like the build settings.

For example this code creates another label as a child of the rectangle object. The x & y co-ordinates for the second label are relative to the top left corner of the parent rectangle.

lvgl.build({
    {type="label", x=0, y=0, text="Some text", color=BLACK},
    {type="rectangle", x=0, y=20, w=100, h=100, color=BLACK,
        children={
            {type="label", x=5, y=5, text="More text", color=BLACK}
        }
    }
})

The lvgl.build function will return a table of LVGL objects. This table will contain named references to any objects created that have the 'name' setting, Only references to named objects are returned.

For example this code assigns a name to the inner label and then updates the color.

local uiElements = lvgl.build({
    {type="label", x=0, y=0, text="Some text", color=BLACK},
    {type="rectangle", x=0, y=20, w=100, h=100, color=BLACK,
        children={
            {type="label", x=5, y=5, text="More text", color=BLACK, name="lbl1"}
        }
    }
})

uiElements["lbl1']:set({color=BLUE})

Warning

Very large nested tables or very deeply nested tables may not work when compiled to a .luac script. If your script works when run from the .lua file; but fails when run from .luac, try breaking the lvgl.build call into multiple calls with smaller tables.

API Status

Avail

Status

Comment

BW radios

Color radios

active

Change log

EdgeTX version

Change

2.11.0

Introduced