Good Starting Place for Local Balena Device UI

Is it worth creating a new thread?

For future reference, the NGINX example described here:

Has moved here: GitHub - balena-io-experimental/balena-nginx-ui

@maggie0002 I just tested your repo GitHub - maggie0002/balena-device-ui: A UI for Balena devices.

Terrific start!
I’m very lucky that you started this project since for the last few months I’ve been thinking about how to tackle a local device UI that does exactly what you’re doing.

Thanks for working on this!

Thanks, great to hear, hope it will be useful. There are some fairly big changes to come so would be wary of forking and developing off it just yet if you were hoping for a smooth experience. Maybe another week or two and that will be different.

It’s @nucleardreamer who is charging forward with the UI part, rather than it being my repo though. And also woke me up a little to developing it further.

Would be great to hear any thoughts or ideas, what would constitute a useful UI starting point? No idea too big small or silly, it’s all good food for thought.

@maggie0002 I noticed all the activity on the repo and figured you had more to come. I love what I’ve seen so far. Thanks again.

Here’s one idea:
Password protect the interface. I’ve seen others use a default username (e.g. admin) and a serial number for the password. In this case UUID is known publicly so that won’t work - at least it’s known publicly if using Balena public URLs since UUID is in the URL. Maybe the admin password could be set in the fleet-wide variables and Express could read from that. For that matter I guess you could make user and pass both fleet variables if Express can read from that.

Also, one thing I never managed to figure out (or at least remember) was how to clear a known WiFi connection so that the device will trigger the WiFi Connect interface.

The device I’m testing your project was already connected to a known Wifi, but I’d like to play around with your Wifi interface which isn’t an option if already connected.

So maybe idea #2. Allow the Wifi UI to select a different SSID even if a valid connection already exists.

Really appreciate the thoughts.

Password protection is high on the agenda. I hadn’t considered a fixed default password though, I was thinking an env variable to set a default, and then when the env variable isn’t there to leave the interface unlocked but provide a password setting option. Could possibly add an option to provided a hashed password in an env or a non-hashed password (really got to start documenting these ideas somewhere).

Would be great if you could participate in the thinking and conversation around it: Add login page option to provide secure ui option #maggie · Issue #14 · maggie0002/balena-device-ui · GitHub. If you have a particular vision in mind from an architecture perspective, lay it all out there, would certainly appreciate the input.

Wifi connect is a little tricker. The wifi chip on the devices (such as RPIs) are not like the ones in laptops or larger hardware, and are quite limited in terms of doing more than one thing at a time. That plus some software limitations. In short, when you are connected to a Wi-Fi network, you can’t then scan for other networks in the area without disconnecting again first (on some devices that is). It’s very hard behaviour to pin down the reasoning, but unfortunately is a thing.

That said, some hardware does allow it and there is some checks in place that should (in theory) be effectively detecting when it can or cannot perform a refresh (it’s quite experimental). I don’t think it would be a major issue while we are all experimenting to use that same logic to allow the interface to be active when the refresh is available. It’s actually a very small UI change. Will keep giving it some thought and maybe create a branch for you to test and play around with if you can?

Bumping this up to highlight to the rest of the forum the incredible progress @maggie0002 is making on this!

2 Likes

:+1:

Could really do with some ideas for features. It’s a little free and lose right now. What are the sort of things used most, or problems most often experienced that could do with diagnostics? Networking has been flagged, seems like a good one to me. Would be interesting to hear from the Balena team their experience with devices but also experience here on the forums of most encountered issues. In fact do you have stats on that sort of thing to monitor common questions/problems?

Journalctl logs?

@maggie0002 I was thinking you might actually be getting close to the point where the foundational use case is already well covered and that future needs would be very specific use cases that wouldn’t apply to all users.

For example, @mpous and I have been playing with LoRa for a while, where in our case having some LoRa gateway stats, populated from Basicstation or the LNS would be really nice to see in a local UI. Like connection status to the LNS, LoRa payload stats like number of uplinks, downlinks, etc. But like I said this starts to get very specific and only useful for those of us running Balena for LoRa gateways.

Also, I wanted to comment on the project card that @nucleardreamer’s suggestion for a DNS setup which would allow users to get to the UI via http://devicename.local instead of needing to know the IP address is an excellent one as well.

2 Likes

I had been looking at that DNS thing too, although wasn’t really sure what was meant. Balena devices can be accessed already by the-hostname.local. Is the idea that there can also be a static url separate from the hostname? Wasn’t sure how that works.

I think there were two visions early on. A base for people to build on but also a container useful to start up on a device with some basic tools. You’re right, as a base it’s probably close enough. But as a ui for interacting perhaps a few components missing?

Authentication?
Container management?
Logs access?
Offline device info?
Mdns

Think that would pretty much cover it?

And a docs update.

1 Like

Definitely… I could be wrong but I imagine besides some UI tweaks, between whats been done already and the list you’ve just identified I can’t imagine anything more that would be universally needed. Could be wrong, thats why you’re right about gathering more feedback.

I did just have a thought, perhaps this should become a balena block so it could very easily be slotted into other projects?

1 Like

I submitted the Python version of Wi-Fi connect through the Balena blocks process months ago, said it would be under review. Nothing ever happened so wouldn’t hold my breath on that being different for the UI. Will add a balena.yml file though, may be worth a try.

@maggie0002 let me ask about this internally!

BTW balenaBlocks are self-served since last week, so feel free to submit the block! i would love to test it :slight_smile:

Good to know thanks, will do it today.

Fleets, projects and blocks. If I have understood the different types correctly, the wifi-connect would be a block, deploy it and use it. The user interface would be a block and a project: deploy it and use it; and be able to fork it and adapt it?

Maybe not today. Still a little confused.

Blocks are also not joinable, but there is no need to add the joinable: false as balenaCloud only uses this for Fleets and Projects.

So don’t include the string, but how does it know it is a block not a fleet? The docs could probably do with a bit more clarity, I have already read the page a few times and still a little confused: balenaHub: an easier way to find and publish fleets and projects for edge devices

Edit: Ok, think I see, there is a separate tab in the dashboard now for Blocks. Will try and work it out later, but now seems like I am going to need to have an app in the Cloud, and will need to add a new GitHub workflow to publish to it at the right time.

1 Like

Did you read this @maggie0002 ?

Looks helpful. As is this: How to make your own balenaBlocks: simple, drop-in edge app functionality

Would be good to compile all these in to one ‘how to deploy a block’ guide, and then have that be the page that shows when we click ‘Publish Block’ on the UI.

There might be a bit of a problem with it picking up logos, but other than that, this new system is way easier. :slight_smile:

Added the container manager, logs access and offline device info. Also added a captive portal and published it as a container (docker pull ghcr.io/maggie0002/bdu:latest). Just the authentication and MDNS missing, but going to have to leave that to someone else. The MDNS I don’t really get, and the SQLite backend I haven’t implemented in ExpressJS before and hoping someone who has walked that path already might come along and do it (would be happy to do the UI frontend, but hopefully someone can contribute the backend work). Anyone who has done it before is bound to bring some inside knowledge.

@nucleardreamer is going to go and wave their magic wand over it now too. Will keep an eye out and work on bug fixes as people identify them, but think that’s probably as far as I can take it and is plenty useable now.

Enjoy.

1 Like