Good Starting Place for Local Balena Device UI

Hello everyone! I’m the developer/maintainer of a project that utilizes Balena’s incredibly awesome OpenFleets concept: Ribbit Network.

We have a raspberry pi balena device that has several sensors connected to it and uses a wifi Radio to connect to the internet. Given that this is an Open Fleet, it’s sometimes not obvious what issues are for someone building their own sensor given that they don’t have access to the Balena UI. So I would like to build a local UI that gives as much status about the sensor as possible.

Is there a good starting place for a local User Interface / Web Page like this which I could fork and modifying for my Balena project?

I’m thinking this should be a local web server that displays some basic information to help diagnose the following issues:

  • Sensor Connection Issues - Is there a good connection to the CO2 Sensor, Barometer, and GPS?
  • GPS Location Fix - Does that GPS have enough satellites for a good location fix?

Additionally, it would probably be useful to display some other information like:

  • Local IP address
  • Software Version
  • Wifi Connection
  • Signal Strength

Hi Keenan,

Here are some starting points for using a web page to display information about your device:

Hope this helps!

Kind regards,

Julia

Thanks for those links @jmakivic !

Hello @keenanjohnson you also can find a local UI where the Device Variables are updated on this balenaHub project GitHub - just4give/birdwatcher

Check the tools service for getting the information.

1 Like

Thanks @mpous ! That’s a great example that I can start from!

1 Like

Let me know if I can help you with anything @keenanjohnson

Will do!

I’m not so sure what it is you’re looking for. The fact that it is sensors you want to aggregate status of rather than Balena device indicators means it is probably going to be very bespoke. Something that sprung to mind maybe for inspiration is the open balena dashboard project, maybe just something to spur some ideas. Its online though but may be useful to adapt for aggregating device status. https://forums.balena.io/t/open-balena-dashboard-project/2219

And for the UI design itself im having a love affair with Quasar. Reading about your project of stats it sprung to mind. Here is someone else’s example project showing off components: https://quasar-admin-demo.netlify.app/. Check out the charts tab in the menu and others.

1 Like

@mpous @jmakivic @cywang117 is there a dummy Supervisor you have laying around somewhere for development? I may try and throw together a quick example, but rather than develop on a device it would be helpful to have a dummy supervisor to send requests to for development. I figured this may be something you guys have already developed?

@Maggie The “bespoke” aspect of the LocalUI indeed poses an interesting dilemma. We’ve discussed this previously and it may be possible to have the local-ui balenaBlock pull from a user-defined services section of the balena.yml contract. There, the user may specify what info they may provide. Of course the implementation may be complex, but this sounds like an ideal solution if we can manage it. Feel free to follow/contribute to this repo :wink: it’s still under development!

As for the dummy Supervisor, I am not personally aware of any such item, but I have had luck provisioning an amd64 balenaOS in a VM as an Intel NUC, which I can then livepush on with even more speed than with a Raspberry Pi 4. I can provide the scripts I use if you’d like?

Alternatively, there is the balenaOS-in-container workflow described in the Supervisor’s README.

1 Like

I had a look this morning and managed to push to the device for testing. Hopefully I will not be so far into the UI to make it worth going through the VM process, but thanks for the offer.

Here are my two-cents:

NGINX branch:

It always seemed a little cumbersome to have to build another backend for a frontend to communicate with just to then be passed to a second backend (the supervisor). So here I used an NGINX reverse proxy to bring the Supervisor on to an open port, then used the same NGINX instance to host a UI which communicated with the supervisor on the reverse proxy port. Pros: great image size, around 15mb, Cons: security having opened the supervisor on a port, and not much room to grow. If the goal was to pursue other features like CPU usage that isn’t on the Supervisor API it would be problematic. Moreover, no means of adding a useful authentication at a later date.

Main branch:

This is probably a little more logical. It has an ExpressJS backend but a super simple one. The idea is it acts as a proxy for Axios to the main UI and then all the work is done on the UI itself. It means less code base to maintain and problems to debug (hopefully). Downside is the container with Node in it is 100+mb, but because the express js backend is so simple it should be relatively easy for someone to create the same link in Flask (Python) or other languages, then reuse the same interface out of the box. Would mean more contributes to the frontend. And then by having different languages, image size isn’t so much of a problem as people can align it with whatever image they already have on the device and benefit from Docker/balena-engine image sharing. It also has the potential to add in future features like authentication, and reading local CPU stats etc (while at its core is still very portable to other languages and the UI interchangeable).

I put all the Supervisor paths in one file for easier maintenance. Then built the UI example in Quasar because it has a whole bunch of easy to drop in components for the UI development. If hoping to get more open source contributions then thinking the code really needs to be as easy to access and manipulate as possible (take wifi-connect for example that is in Rust, is popular but has had no contribution as it’s a rarer language). Quasar setup allows for some other drop-in features, so added i18n for future proofing, I’m sure there are lots of language speakers in the community.

Not sure how I landed in the UI thing, but was a bit of fun tinkering for a while. Also not sure if drifting off of @keenanjohnson question. Is any of this helpful? If you are putting something together could it be towards a generic base for the community?

2 Likes

Wow @Maggie this seems like you did a lot of work here! Is this something that I can deploy you think to start testing?

1 Like

It’s only the logic and a few buttons, but yes of course by all means use it as you wish. If you do have time it would be appreciated if you could put it into some commits moving it forward as something everyone can use, and then at the last stage fork it to do any of your custom components.


The most obvious next step is adding the routes from the balena supervisor docs to the supervisorRoutes in the app.

Then perhaps the tricker part. How should the UI be laid out? There are a lot of components to fit in and some menu items to name and consider what will go where. I wonder if using vuedraggable so that users can drag the components around to where they want them to be may be better than trying to work out an answer for everyone? And then in the settings panel add a bunch of toggles for each component with a description of it to enable or disable it. It will reduce clutter but also reduce every route being hit with a request each time the page loads (for things like stats that you would want to show immediately without a button click).

Maybe echarts to integrate visual effects GitHub - xlsdg/vue-echarts-v3: Vue.js(v2.x+) component wrap for ECharts.js(v3.x+) from apache Examples - Apache ECharts.

Ui wise though the Quasar docs are the place to start. They are extensive and detailed, there are a whole bunch of components ready to go: https://quasar.dev/. I would probably want to try one without draggable and see how clutter it is, because draggable would require storing the state of the layout for the users next visit and while very possible maybe best to get something working done rather than aim high and not finish it. Keep throwing some ideas around, best to think out loud.

2 Likes

Hmm, the juices are flowing now. I will put a GitHub workflow in to build it as a multi arch docker image from the main branch. It will mean someone can ssh into a device and run a balena run command rather than have to push it through the balena cli or cloud or local. Then remove it when done. Useful for debugging or getting some control immediately on site without tampering with running services.

Would need to know from the Balena people how to make the supervisor accessible in that instance though. My understanding is the supervisor does the assigning of the api keys and url based on the label? If working outside of the supervisor how best to get the api key and url vars into the container and permission to interact? Would it need to attach to a certain network?

1 Like

Someone flagged the Balena blink node package for flashing the rpi led: GitHub - balena-io-modules/blinking

Throwing it in here to keep track as may be useful for a UI.

Thanks for those links

Thanks and regards..

I had been meaning to pull some of the components built for other projects together into something more public so I made a few changes to the Balena device UI example I shared earlier: GitHub - maggie0002/balena-device-ui: A UI for displaying and using Balena Supervisor API

Separated the Supervisor and other elements in to components for easier customisation of the interface, and tracking of changes: balena-device-ui/ui/src/components at main · maggie0002/balena-device-ui · GitHub

Separated the backend endpoints for Supervisor in to it’s own file, and added a place for people to add their own backend endpoints for interacting with other peripherals or software: balena-device-ui/CustomRoutes.js at main · maggie0002/balena-device-ui · GitHub

Integrated the Wi-Fi connect component being worked on in another project: GitHub - maggie0002/balena-py-wifi-connect: An API for controlling Wi-Fi connections on Balena devices.. It allows users to find, connect and disconnect from nearby networks out of the box. Also added an interface to the UI for interacting with that component:

I added some basic explanations to the README: balena-device-ui/README.md at main · maggie0002/balena-device-ui · GitHub

That’s about as far as I go for now. There are lots of things that could be done in terms of code, adding Supervisor endpoints, cleaning up the example components and adding others. Will see how it goes and if anyone finds it useful.

1 Like

Wow @Maggie this looks awesome!

I’m definitely going to be taking a look and possibly adapting this for my project!

2 Likes