What version of this package are you using?
Latest

What problem do you want to solve?
Users may want to switch WiFi networks after having established a successful connection. Currently, the UI disables switching wifi networks is a successful connection exists.

What do you think is the correct solution to this problem?
Two parts:

1. Create a forget/reset wifi button on the networking page, which forces the wifi to disconnect and forget it's current connection so that the user is placed back in the new connection flow where the wifi-connect option is triggered, the device enters AP mode and the user can begin as if the device never had a connection in the first place.

2. Modify the networking page to permit hot-swapping of Wifi SSIDs for users who do not want to go through the wifi-connect flow but rather just connect to a different wifi ssid.

Are you willing to submit a pull request to implement this change?

This would be a rare occurrence. It would only occur when someone is adding networks to the devices manually via docker-compose directly on the device outside of the Balena Supervisor, Cloud or CLI; or creating networks using balena network create on the device.

To overcome the issue, would need some way of choosing which network to join, or to specify a name of a container which it then joins that containers network (would rely on depends_on to ensure container is up).

A work around which is probably a good enough solution rather than try to work around this programmatically, is for users with multiple bridge networks to (1) mount balena-device-ui to the host network; (2) set the NETWORK_MODE environment variable in the docker-compose file to host and then change Py Wifi Connect to listen on PWC_HOST=127.0.0.1.

Have considered just running the balena-device-ui on host network by default, may be done at a later date. Unfortunately wifi-connect needs to be mounted to host, although haven't tested this thoroughly, just heard from people using various wifi-connect setups that it is required and would make some sense considering dnsmasq needs to be listening?

From the latest v0.0.17 release image:

But it seems running dev locally has this already fixed:

This is pretty important for acessability.

I wanted to add an issue here as a good first issue for anyone who can get stuck in and contribute.

An inevitable feature to add will be a menu item for containers. It would display a list of all containers on the device, their IDs and status. Very similar to what you see when writing docker ps in the console. I'm thinking such an implementation should be pretty simply, a q-table (https://quasar.dev/vue-components/table) that is populated from container data fetched from the Supervisor. The endpoints are already in place to fetch the data, and examples of how to use them can be found for the ping and update features already built in to the UI. On the far right of each row can then be buttons that activate certain behaviour on each container, for example stop, start, restart.

As most of the development right now is going in to the SDK, and this would be an independent feature in its own component, this would be a good first issue that is both important, ready to be implemented, and wouldn't interfere with ongoing work.

A note to developers, I think the goal is to avoid polling at regular intervals for data, and instead only fetch data on opening the page and on triggering through a button.

I moved this to next priority list as it is the last of the semi-significant refactors (famous last words, hopefully the last or one of the last at least). Requires some backend and frontend work.

Will likely look at it next week, but converting to an issue for any ideas or thoughts. At the moment I was thinking a simple password option, no usernames, with the smallest interface possible (just an input box that pops up) and controlled by a little padlock icon in the top right. Backend wise, was just going to store a hashed password in a .env file. Creating a database for this would seem excessive for only one user. Unless @nucleardreamer you can see any need for potential database use for features in the future, then it may be worth adding it in now?

Add option for hashed env var and if not then normal password env var, and if not then no password.

I'm increasingly convinced this will be worth doing. Would be nice to add in some debug logs throughout that code that could then be silenced in Production mode.

Needed for Wi-Fi connect and the SDK. This is an interesting topic because it covers a number of different offline cases, I think we need to discuss what "offline" actually means and what we want to setup as far as endpoint go. We have a few different situations to detect:

• WAN disconnected: you can still reach your local network but unable to resolve anything outside. This would effect the calls to the SDK
• LAN disconnected: you have no physical link to your own network. This effects wifi-connect and SDK calls.
• Supervisor disconnected: the supervisor container has crashed or is in a state of restart, meaning those endpoints won't work from our express backend
• Container/machine disconnected: You are on the front-end, but our actual container is not accessible or the machine is in an inaccessible state. This would be from being rebooted (stopping out backend container), or our backend crashing in a loop due to an error.

Polling APIs might be an ineffective solution to get real time information around all these states. We might want to roll WS (socket.io perhaps?) to provide an enum value for the state of why we are offline so that the UI can respond accordingly

The UI form validation for the captive-portal and the dashboard don't permit to connect to a password-less access-point.

I finally got a chance to try the UI and went to use the block from balenaHub via the bh.cr URL, but noticed it's out of sync with the repo and needs updating.

Can we add the balena build action/workflow to automate the publishing of the block to hub and keep it in sync? Here's an example of another block which is publishing multiple architectures to hub as part of the workflow: https://github.com/balenablocks/browser/blob/master/.github/workflows/balena.yml

What version of this package are you using?

What problem do you want to solve?
The column approach like the Balena Cloud uses is really unfriendly to mobile. It prevents things wrapping easily on narrow screens.

What do you think is the correct solution to this problem?
It would be better to build 'mobile first' and avoid parallel columns.

Are you willing to submit a pull request to implement this change?

Building Electron for arm64 on a GitHub runner requires notarised apps with Apple: electron-userland/electron-builder#5850

Requires using the much slower x64 version in the meantime.

At the moment if a device is offline the device info page just stays blank. Components that require internet access should have loading indicators and then notifications when offline and unable to fetch.

Related to #9

Hi there, I'm the lead developer for https://github.com/balenalabs/balena-sound/.

We have a very rudimentary local ui on the project which was only added as a proof of concept, it let's you manage the device, set dtoverlays and has a volume slider, nothing too fancy so I want to replace it with this awesome device-ui sauce which is basically the same thing but 100x times better, and free of maintenance (at least for me :P). Here is how it looks:

What problem do you want to solve?
I would love to be able to add custom components to handle application specific logic. At the moment the volume slider is the only custom thing we have but I want to add a lot more. Ideally the component gets added to the sidebar and has it's own page.

What do you think is the correct solution to this problem?
I've been talking to @nucleardreamer about this and we discussed a few options.

We talked about the possibility of allowing users to provide their component in a .vue file plus some sort of manifest config file, but that presents a lot of problems like you need to rebuild the vue application, you need to consider what extra npm modules the custom component needs, translations, etc. There might be a way forward with this if you extend the device-ui dockerfile, copy over the files, manually install the modules and use something like this https://github.com/FranckFreiburger/vue3-sfc-loader, but it seems to be very complicated approach and error prone. Also this type of solution would mean anyone wanting to add a custom screen would need to write vue code, which reduces the audience.

So we came up with another idea which is adding custom components via iframes. The user would extend the dockerfile and add a configuration file. This can be json, yaml, whatever. The file would contain basic metadata required to add the component to the sidebar, basically a name and a URL to load. Then the app would read this file and add the necessary custom components on the fly.

There is an additional problem with this approach which is that the page we are rendering via iframes might be using API's internal to the device. This is the case in balenaSound for example. The existing UI uses an API that's provided by the sound-supervisor service. To solve this we could add dynamic routing to the app serving device-ui, some logic that maps requests that come in for instance /audio/volume would be transformed into http://sound-supervisor:3000/audio/volume. The specifics of the mappings involved would also need to be provided via config file described previously.

Are you willing to submit a pull request to implement this change?
Sure! And I bet @nucleardreamer is willing to help :P

Consider an expressJs reverse proxy for wifi-connect (/wifi-conenct -> :9000). Or relay the request through the ExpressJS backend, to Wi-Fi connect. This may be better in the long run as WiFi-Connect can then eventually be behind a login page when it is implemented to express in the future.

What version of this package are you using?
Latest

What problem do you want to solve?
Rather than rely solely on the Balena SDK (which already uses some of the systeminformation stats, why not go right to the source and expand the device metrics offering.

What do you think is the correct solution to this problem?
Use systeminformation inside the UI container to populate the current device info like CPU, memory and storage stats as well as other info not currently available in the SDK like:

• Container info (Also useful for #22)
• WiFi stats like RSSI and SSID
• Bluetooth stats

Are you willing to submit a pull request to implement this change?
If I can find them time, absolutely.