How to use lv_observer in lvgl 9.x

[sukesh-ak]

Here is an example of how to use lv_observer in LVGL 9
https://github.com/sukesh-ak/BSP-IDF5-ESP_LCD-LVGL9/blob/main/main/main_ui.c

It's used for the brightness percentage slider to show the percentage value in label as well as use it to change the actual brightness of the display using callback from lv_subject_add_observer_obj.

Callback function

// callback function
static void brightness_observer_cb(lv_observer_t * observer, lv_subject_t * subject)
{
    int32_t brightness_percent = lv_subject_get_int(subject);
    bsp_display_brightness_set(brightness_percent);
}

UI Binding using lv_observer

lv_subject_t brightness_subject;

// Initialize lv_subject into int (int32_t) type
lv_subject_init_int(&brightness_subject, 80);

/*Create a slider in the center of the display*/
lv_obj_t * slider = lv_slider_create(lv_screen_active());
lv_obj_align(slider,LV_ALIGN_CENTER,0,10);
lv_slider_bind_value(slider, &brightness_subject);                  // Bind slider value with the lv_subject
lv_obj_set_style_anim_duration(slider, 2000, 0);

/*Create a label below the slider*/
lv_obj_t * slider_label = lv_label_create(lv_screen_active());
lv_obj_align_to(slider_label, slider, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
lv_label_bind_text(slider_label, &brightness_subject, "%d %%");     // Bind label text with lv_subject

// Add lv_observer with a callback when the value changes
lv_subject_add_observer_obj(&brightness_subject, brightness_observer_cb, NULL, NULL);

[sukesh-ak]

@mhaberler I thought you might be interested in this.

[mhaberler]

thanks - tracking ;)

[sukesh-ak]

@kisvegabor ESP32-S3 based sample project showcasing lv_observer from lvgl 9.x

[kisvegabor]

@mhaberler Thans for the detailed description. I agree with @sukesh-ak that the JSON part shouldn't be part of LVGL but we need to make it possible to easily integrate the observers into such environment.

it is questionable if the observer is the right pattern for what is essentially a message queue without locks.

In this comment I have summarized the advantages of the lv_observer over lv_msg (from LVGL v8). It might be useful when designing this system too.

[mhaberler]

you're bang on, I retract my opinion and maintain the opposite position as of now while I recode ;)

it's pushing the envelope using observers as a general IPC mechanism.

I guess the more appropriate locus of application is within the LVGL task/UI context proper like @sukesh-ak 's opening example, or the Wifi indicator here

this also answers the question "do we need observers to handle objects, not just scalars and strings" as: IMO no.

that suggests interaction of the UI task via structured messages like JSON, msgpack ff better happen with separate threadsafe queues or similar - while leaving any heavy lifting like parsing outside the LVGL task/UI space

meaning: this is not an observer-related issue

[kisvegabor]

It seems we are on the same page ☺️

[mhaberler]

I reworked the IPC mechanism into a ESP-IDF ringbuffer and a lv_timer callback in the UI context.

works fine, several lvgl locks can be removed because the ringbuffer is threadsafe.

some JSON parsing still present in UI context but looks acceptable to me

[sukesh-ak]

Will check it out

[mhaberler]

I'm looking into a client which can work with MQTT

it looks to me the observer pattern is a good match with a MQTT subscription/topic - I'm thinking about how to best match these up in generic way instead of per-case C++ coding, maybe through a JSON config

btw the broker does not necessarily be somewhere external, see https://github.com/mlesniew/PicoMQTT (PicoMQTT is currently learning MQTT-over-websockets and that will leave the route open to use a plain website as client as an alternative)

I'd be interested in exchange of ideas/prototypes on the subject

-m

[sukesh-ak]

@mhaberler Btw here is the Espressif ESP-IDF MQTT5 sample client
https://github.com/espressif/esp-idf/tree/master/examples/protocols/mqtt5

[mhaberler]

yeah one can always brute-force the broker issue with some local linux vehicle

I wanted to avoid that in the sensorlogger case, so you'd get away with just say an esp32+custom sensors, and sensorlogger - no extra boxes

some sensorlogger deployment locations I'm using are less than ideal for running an extra linux box:

[sukesh-ak]

Interesting use case :)

[sukesh-ak]

@mhaberler I think the thread topic got hijacked.
Lets open another discussion thread to discuss MQTT.

[mhaberler]

ok, admitted - sorry

[mhaberler]

re Espressif ESP-IDF MQTT5 : tried that, works great - for sensorlogger we need some form of broker

however sensorlogger will eventually be able to subscribe to a broker to fetch values and add them to the log (not yet in the current release, but drop Kelvin a note for a TestFlight invitation - should be around shortly)

with that scheme it should be possible to log arbitrary sensors, maybe even ones read and decodeby Open MQTT Gateway

[mhaberler]

on using binary JSON representations for queued UI interactions :

it seems the nlohmann/json library would be the better choice over ArduinoJson - it supports serialisation and deserialisation to/from CBOR, msgpack and a couple of others out of the box

to make sense, that of course rests on the assumption that decoding and acting on a CBOR or msgpack message in the LVGL context is faster than parsing a string into JSON as I am doing right now

works nicely on Arduino, ESP-IDF component here

[sukesh-ak]

ESP-IDF comes with json (cjson), so I used the same for ESP32-TUX
https://github.com/espressif/esp-idf/tree/master/components/json