KeyAid - “A Platform for Remote Device Maintenance”, is a web platform that connects Information Technology (IT) technicians with individuals in need of assistance with their devices, whether for updates or technical issues. The platform consists of two main components:

💻 Web Platform:
This is where technicians and clients interact. Technicians can describe the work to be done, perform the tasks, and allow the client to pay and evaluate the completed work.
📡 Control Device (Raspberry Pi):
A Raspberry Pi is used to remotely control the end user’s target computer. Command execution on the target device is achieved using the TinyPilot software.

Regardless of the client’s geographical location, KeyAid allows them to maintain their devices from the comfort of their home. Clients can choose the technician they find most suitable, coordinate work schedules, and agree on costs.

**TinyPilot is an open-source software developed by Michael Lynch. It is installed on a 32-bit Raspbian operating system, which is based on the Debian GNU/Linux distribution.

***Special Thanks to Michael Lynch, which who I have a meeting discussing about it and he was open to make use of his software for this idea. Thank you very much for the support Michael, in case you are reading this.

1. 💡 Motivation

For years I have been helping family members, friends, even when I was part of the IT Help Desk service at the National Technological University - Mendoza Regional Faculty (https://www4.frm.utn.edu.ar/) as part of scholarship, where everytime there was an issue, we had to be on-site.

For tiny fixes related to OS problems, there are already great solutions like:

The idea of this project is to try to go a little bit beyond the OS limitations. What happens when a given user ask for a PC format, reinstall OS, do some strange configuration in the BIOS? The only workaround this is, what if we could have a external controller that could simulate a Keyboard + Mouse + Mass Storage Device that could be managed remotely, simulating a technician being in front of that PC with access to it?.

So this is how this project started, from the necessity to extend the technician capabilities doing their tasks remotely and that users being able to no need to install any software, instead, they would have an external device that would take charge of everything, and by having that device, they would have access not a single technician, if not, any technician that would be in the KeyAid - Web Platform.

2. 📋 Considerations

So the idea of the projects was, ok, let’s try to move the traditional IT Service to make it remotely. Nowadays we have an infrastructure, that would allows us to go in that direction.

Now, there are some considerations that the client and technician must take care from both sides, to make the platform a useful product to promote the transition from traditional IT Service to KeyAid Service. From my previous experience, I’ve found the following necessities from both perspectives:

Client:

Be able to trust your data to a person of trust.
Know before hand what is the ETA and budget for the solution.
Trust the platform for payment, and also in case, any unexpected issue could happen.

Technician:

Be able to access the full PC, along with rebooting + shutdown.
Be able to make a budget specifying possible tasks, with some flexibility in case of unforeseen events.
Trust the platform for getting paid through it and make the money accessible easily.

3. 🗂️ Architecture

KeyAid is composed by the following components:

3.1 Web Platform:

Acts as the main interface for communication between clients and technicians. Clients can create maintenance jobs, review technician applications, and manage payments. Technicians can apply for jobs, manage client devices remotely, and receive payment.

**Front-end developed with Flutter and GetX for state management, utilizing the MVC design pattern. The back-end relies on Firebase services including Cloud Firestore for data storage and Firebase Authentication for user management.

3.2 Remote Access (Rasbperry Pi):

For the remote module access, TinyPilot was installed on a Raspberry Pi at the client’s location, providing a web server accessible via IP for remote control by technicians. This module connects the Raspberry PI controller with the Web Platform allows technicians to interact with the client’s machine as if they were physically present.

3.3 Emulate USB Devices (Rasbperry Pi - OTG):

TinyPilot supports emulating USB devices such as mouse, keyboard and even mass storage devices (Only in premium version). This is done, because behind the doores, makes use of ConfigFS, that allows it to manage and configure devices like keyboards, mouse, and storage to aid in system installation or data backup.

At the same time, for the emulated Mass Storage Device, I made use of Ventoy, which allows to have multiple bootable ISOs. This makes it easier to manage from a code point of view, since handling what the technician needs it’s just about to download the ISO file into the emulated storage device.

– Repo: OS Downloader Service

3.4 USB OTG/Video - Connection:

Keyboard/Mouse Events: Enabled through the OTG protocol supported by the Raspberry Pi, requiring a “Splitter” for data separation and safe power delivery.
Video Signal Capture: A USB/HDMI capture device is connected to the Raspberry Pi, capturing and encoding video in MJPEG format. This video feed is streamed to the technician’s browser via TinyPilot and uStreamer for real-time monitoring. Security Considerations: Connections are encrypted using Tailscale, a VPN service, to ensure data privacy and mitigate unauthorized access risks.

KeyAid - Iot - Hardware — 3.4 - Raspberry Pi + Splitter - Physical Connection

4. Technologies

At the time of trying to solve how to handle emulating USB Devices, how to send video output with low latency and how to make it easy for technicians to load/unload ISOs (or even perform backups), there were several choices that had to be made in terms of what frameworks, libraries should be used to allow an easy interaction between clients/technicians in the platform.

Web Platform: Flutter was chosen for the Web Platform. One of the main reasons was my previous experience with the framework, which allows code reuse in case I want to export it to other platforms with minimal changes. This includes reusing components, colors, themes, assets, and more.
One of the downside of Flutter that I’ve noticed in the past—though I’m not sure if this still applies—is that if the project grows and requires additional developers, it may be harder to find people experienced with Flutter compared to more widely used frameworks like React or Vue.
Raspberry Pi: I chose to use a Raspberry Pi because it was ideal as a proof-of-concept (PoC). It allowed me to run a lightweight server to handle business logic such as retrieving operating systems, streaming video output, and emulating keyboard and mouse input using TinyPilot - Build a KVM Over IP Blog—all on a single device.
But in terms of making this product profitable, this device could be customized to only have the minimum hardware necessary to do what it need to do, in order to first reduce power consumption, make it small as possible to not disturb the environment of the client, even, if it could be inside the PC would be even better.

4.1 Linux ConfigFS - How Emulating USB Devices Works

When I started doing this project, I was curious about how it could be done to emulate different USB Devices from a single device. That’s when I found TinyPilot project, where I started to learn more and more about ConfigFS, that’s the key enabler for this to work.

“ConfigFS is a ram-based filesystem that provides the converse of sysfs’s functionality. Where sysfs is a filesystem-based view of kernel objects, configfs is a filesystem-based manager of kernel objects, or config_items.”

In very simple terms, this means that you can manage kernel objects from the user-space, just by setting a pair of files in a given structure that is defined in the Linux Kernel Documentation linked above. A very powerful feature!!, just with a set of scripts you could create fake devices with their own configurations (Keyboards, Mouse, Network, Mass Storage, etc).

In order to have support for mass storage devices in the community edition of TinyPilot, I needed to handle configfs in order to have the Fake Mass Storage available and manageable from a coding point of view, so the technician could handle OSes easily, as well as backups or whatever it could need from a mass storage device.

So, to support that, I developed the following project OS Downloader Service, that is a tiny server that inside of it, it has the script of configuring the device using ConfigFS.