Question: Are Custom Configuration Variables Applied on Image Download or After Connection to Cloud?

Product support
1

Hey everyone! A question, I have a custom configuration variable as shown below.

Is this applied to the image when I download an image for a new device or does the device need to connect Balena cloud before the configuration variable is applied?

image
image2044×448 19 KB

The reason I’m asking is that the configuration variable is required to allow access to the WiFi radio for my device, so it would be ideal if the configuration variable just came with the image on download :slight_smile:

2

Boop

3

Hey Keenan, we were just discussing this today. The configuration variables are applied once the device connects to balenaCloud, and are not delivered with the image download. Let’s see if @cywang117 can offer any advice or workarounds (if at all possible – there may not be a good clean solution, I’m not totally sure!).

:slight_smile:

4

Thanks! Yeah no worries if not! It looks like a balena preload command does the trick, but I was just wondering if there were any other ways. Thanks all!

5

Hi @keenanjohnson,

Good to hear that balena preload works for your use case! Aside from preload, we were discussing one of several options:

  • If the device doesn’t have connectivity without pre-setting this custom config var, then you could create a oneshot container whose only job is to set the config var and reboot, granted the config var isn’t already set. Then your other services could depend on this config var. However, this situation isn’t easy or recommended, since it requires the oneshot container to have host filesystem access, which is disabled by default in the Dockerfile and not possible via bind mounts.
  • If the device does have connectivity on reboot, but does not have dtoverlay set, you could call the balena API (or use the balena SDK) from within the container to set the config var on first launch, again with the conditional that if it’s already set, proceed to the main application code. If the app makes the call to balena API in this case, the Supervisor will add this config to config.txt for you and reboot the device.

In both of these alternate cases, there would be a reboot upon setting the config var, so it sounds like balena preload is the most ideal. But do let us know if you’re interested in hearing more about either of these alternate methods. Let us know how it goes!

Regards,
Christina

7

Thanks @cywang117! That’s very helpful! Unfortunately, balena preload isn’t super ideal because I’m working with an Open Source project that will utilize the Balena Open Fleets as the primary deployment mechanism, so I’d like to avoid people having to learn the balena preload command if possible!

In either of the alternatives above, the device would have had to had an initial code load correct? So neither would work for an Open Fleet Balena fleet?

Thanks!

8

Hi @keenanjohnson,

Good point about balena preload. Regarding the rest of your comment:

I’m not super familiar with balena’s backend with regards to non-balena-user devices (openFleet devices) being added to a fleet. When an openFleet device is added to a fleet on balenaHub, if an entry for the device is created in our backend, that means that the running app (your app) on the device will be able to set configuration variables using an API call. I’ve asked internally about this first bit, as it relates to the architecture of part of our backend.

There is another which you could try out, that may work and may be simpler than my previous paragraph: if you set a fleet-level configuration variable (see Configuration variables - Balena Documentation for instructions), it’s possible that this fleet-level config var would be set for all devices in the fleet, including new devices. Could you try this out and let us know how it goes? Thanks!

Regards,
Christina

10

Yes I currently set fleet level configuration variables, but these require the device to connect to the cloud first to download the variable. As I mentioned above, the reason I’m asking is that the configuration variable is required to allow access to the WiFi radio for my device, so it would be ideal if the configuration variable just came with the image on download :slight_smile:

11

Thanks for clarifying. I did ask about this before, in my comment about the device having/not having connectivity on startup. It sounds like the device does not have connectivity apart from the WiFi radio (which I’m not familiar with since I mostly look at software :sweat_smile:) – is that correct?

12

I see that this WiFi radio refers to “TP Link USB Wifi Adapter” as listed here (https://github.com/Ribbit-Network/ribbit-network-frog-sensor/blob/main/hardware/ribbit_network_frog_sensor_bom.csv). It looks like balena’s OS team is adding support for this: https://github.com/balena-os/balena-raspberrypi/pull/709

We are also looking at a feature which will allow preloaded config vars (which would fit your use case). We’ll keep you updated in the meantime.

14

As a side note, I’m looking through the repo (https://github.com/Ribbit-Network/ribbit-network-frog-sensor) and I love what you’re doing here!

15

Thanks! Yeah these are all related :). The carrier board I use for the Raspberry pi doesn’t enable the USB ports without a config variable set, so I need to do that before the Wifi USB link becomes active :slight_smile:

Thanks for the love for Ribbit Network!