Allow recording data-lake variables in the telemetry/sensor-logging/video-overlays by rafaellehmkuhl · Pull Request #2406 · bluerobotics/cockpit

rafaellehmkuhl · 2026-02-11T22:35:33Z

This allows simply dragging data-lake variables, as one normally would do, but it also adds support for data-lake syntax in the Custom Message overlays! For it to be easy to use (with auto-completing), I've also changed that to use the Monaco Editor.

Fix #2185

ES-Alexander

Exciting feature! 😃

Haven't had a chance to try yet, but a couple of concerns around the current approach:

ES-Alexander · 2026-02-12T10:52:59Z

src/libs/sensors-logging.ts

👂 Isn't this backwards, and unnecessary? I thought the IDs existed to always be used as the source/reference to fetch names and/or values, because neither names nor values need to be unique or constant?

This is because ExtendedVariablesData use the keys as display names.

I will take a deeper look to see if its acceptable to convert that to use IDs (avoiding migrations).

ES-Alexander · 2026-02-12T11:26:39Z

src/libs/sensors-logging.ts

      variablesData = { ...variablesData, ...veryGenericData }

+      const dataLakeData = this.collectDataLakeData(variablesData, timeNowObj)
+      variablesData = { ...variablesData, ...dataLakeData }


Could this have conflicts/overrides?

I think the ExtendedVariablesData type should probably be expanded to have an optional display name field, with IDs used as the keys. Finishing implementing part 1 of #2281 may also help avoid conflicts (I think the remaining steps are adding a prefix for the internal variables, and possibly adding a default prefix for user calls to the variable creation function).

It's what's causing the need for what you mentioned in the previous comment.

Despite being desirable to enter at some point, the standardization is not a must here for this functionality. We can work step by step.

Agreed that standardisation isn't a requirement for this, but while it isn't implemented it's likely worth at least a comment or an Issue mentioning we know it's a potential source of conflicts, just in case a user actually runs into issues with it down the line :-)

Definitely.

rafaellehmkuhl · 2026-02-12T13:09:26Z

@ES-Alexander I have refactored the implementation to enforce display names, even if blank. This way I could use the variable IDs as keys, avoiding conflicts.

ES-Alexander

Nice feature - seems to work well :-)

Some minor non-blocking issues, which you can choose to address or ignore:

There are lots of "(Legacy)" data-lake variables, which are lexicographically sorted to the top of the list (both in the Data Lake Variables section, and in the auto-complete in the monaco editor)
- It would be nice if they could be pushed down to the bottom of the list instead, but it's probably also ok to just filter them out, since we don't want to encourage people to use the legacy specifiers?
The monaco editor adds syntax highlighting, and code-style auto-complete for the normal text parts, which can make it seem like the whole "message" gets evaluated rather than being a slightly special text field
- It would be ideal if the autocomplete could be only for the data-lake variables
- Is it possible to disable the syntax highlighting? Seems unlikely to cause many issues (since most users will be just trying to write text there), but it could be one less source of confusion
Very long strings apparently get pushed down to the bottom of the screen in the subtitles
- There are several things this might occur on, since the data-lake variable names get used as the display names, but it's already possible to work around by just including the variable's value via a custom message field, or a VGI
- If we want to reduce the issues, it could help to set the display name of data-lake variables up to the first open bracket, to at least remove the MAVLink system and stuff?
  - This could be conditional on the name being above some length, or containing "MAVLink", but probably good to avoid overly complex checks/processing
- A potentially more effective but also less smart solution would be to clip data-lake display names to a fixed number of characters

ES-Alexander · 2026-02-12T15:51:29Z

src/libs/sensors-logging.ts

    value: string
    lastChanged: number
-    hideLabel?: boolean
+    displayName: string


Suggested change

displayName: string

displayName?: string

If we make this optional then if left unspecified it can default to the key, and if specified as an empty string it could replace the previous hideLabel: true usage (with the special behaviour of no name section being rendered).

Not a blocker, just could make the code slightly cleaner / require fewer changes to the existing definitions.

This one I prefer to stay as it is. I believe the right approach is to remove all non-data-lake sensor/telemetry logging approaches.

rafaellehmkuhl · 2026-02-12T17:07:13Z

Nice feature - seems to work well :-)

Some minor non-blocking issues, which you can choose to address or ignore:

There are lots of "(Legacy)" data-lake variables, which are lexicographically sorted to the top of the list (both in the Data Lake Variables section, and in the auto-complete in the monaco editor)

It would be nice if they could be pushed down to the bottom of the list instead, but it's probably also ok to just filter them out, since we don't want to encourage people to use the legacy specifiers?

I believe this looks good, right? Implemented your suggestion on cropping from the first bracket on /mavlink variables.

rafaellehmkuhl · 2026-02-12T17:37:30Z

@ES-Alexander can you take one more look? I've implemented all suggested changes.

ES-Alexander

Nice improvements!

One tiny bug got introduced, and one of the suggestions was only partially implemented, but happy for it to be merged already :-)

ES-Alexander · 2026-02-12T23:07:23Z

src/libs/sensors-logging.ts

Suggested change

if (entry.includes('/mavlink') && displayName.includes('(')) {

if (entry.includes('mavlink/') && displayName.includes('(')) {

(Legacy) HEARTBEAT/mavlink_version comes up as an empty string if we search for /mavlink 😅

ES-Alexander · 2026-02-12T23:09:45Z

src/views/ConfigurationLogsView.vue

Suggested change

if (entry.includes('/mavlink') && name.includes('(')) {

if (entry.includes('mavlink/') && name.includes('(')) {

As above, although I wonder whether it's possible to read the displayNames directly from the variables, or import the function for them, instead of needing to redefine it here?

ES-Alexander · 2026-02-12T23:10:44Z

src/views/ConfigurationLogsView.vue

This is nice, but it would be even nicer if it was also used in the monaco editor autocomplete options (instead of just in the "Data Lake Variables" list) :-)

I've decided to completely remove the legacy variables from both lists. As you said previously, it doesn't make sense to allow people to use old variables when the new ones are available there. The legacy variables are there just to make sure existing features don't break, but we don't need to support them on new features.

…e ID Enforces the use of a displayName for all variables. Removed the `hideLabel` field.

They can be used both standalone and on custom messages

This adds auto-completing to data-lake variables.

rafaellehmkuhl · 2026-02-13T18:01:53Z

@ES-Alexander based on your approval and having fixed the last bug mentioned and removing the legacy support.

rafaellehmkuhl requested review from ArturoManzoli and ES-Alexander February 11, 2026 22:35

ES-Alexander added the docs-needed Change needs to be documented label Feb 12, 2026

ES-Alexander reviewed Feb 12, 2026

View reviewed changes

rafaellehmkuhl force-pushed the allow-recording-data-lake-vars branch 2 times, most recently from 2a822eb to 45f41ed Compare February 12, 2026 13:08

rafaellehmkuhl requested a review from ES-Alexander February 12, 2026 13:08

ES-Alexander approved these changes Feb 12, 2026

View reviewed changes

rafaellehmkuhl force-pushed the allow-recording-data-lake-vars branch from 45f41ed to 2020169 Compare February 12, 2026 17:36

ES-Alexander approved these changes Feb 12, 2026

View reviewed changes

rafaellehmkuhl force-pushed the allow-recording-data-lake-vars branch from 2020169 to 2947f91 Compare February 13, 2026 13:04

rafaellehmkuhl added 8 commits February 13, 2026 12:19

menu: settings: telemetry: Fix input field overflowing modal

f0ba5a3

sensor-logging: Add displayName field to differentiate from variabl…

33196f7

…e ID Enforces the use of a displayName for all variables. Removed the `hideLabel` field.

sensor-logging: Add support for logging data-lake variables

92fc82d

They can be used both standalone and on custom messages

monaco: Allow editor overrides

2aa1cb3

menu: settings: telemetry: Use monaco editor for custom messages

0e1cd39

This adds auto-completing to data-lake variables.

menu: settings: telemetry: Fix input style not being applied

88089c8

monaco: Allow usage of plaintext as language (instead of javascript)

11e308b

monaco: Filter out legacy variables from autocomplete suggestions

74db352

rafaellehmkuhl force-pushed the allow-recording-data-lake-vars branch from 2947f91 to 74db352 Compare February 13, 2026 15:19

rafaellehmkuhl merged commit 8ad4d44 into bluerobotics:master Feb 13, 2026
11 checks passed

rafaellehmkuhl deleted the allow-recording-data-lake-vars branch February 13, 2026 18:02

	if (entry.includes('/mavlink') && displayName.includes('(')) {
	if (entry.includes('mavlink/') && displayName.includes('(')) {

	if (entry.includes('/mavlink') && name.includes('(')) {
	if (entry.includes('mavlink/') && name.includes('(')) {

Conversation

rafaellehmkuhl commented Feb 11, 2026

Uh oh!

ES-Alexander left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ES-Alexander Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rafaellehmkuhl commented Feb 12, 2026

Uh oh!

ES-Alexander left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rafaellehmkuhl commented Feb 12, 2026

Uh oh!

rafaellehmkuhl commented Feb 12, 2026

Uh oh!

ES-Alexander left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ES-Alexander Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rafaellehmkuhl commented Feb 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Comments

ES-Alexander Feb 12, 2026 •

edited

Loading

ES-Alexander Feb 12, 2026 •

edited

Loading