Differences

This shows you the differences between two versions of the page.

--- en:iot-open:practical:software:admins [2024/01/27 21:12] – [Super Admin] pczekalski
+++ en:iot-open:practical:software:admins [2025/03/11 11:24] (current) – [Admins's Guide] pczekalski
@@ Line 1: / Line 1: @@
 ====== Admins's Guide ======
-<todo @pczekalski>Do an admin's guide</todo>
+The system has two kinds of administrators: the Super Admin, a built-in account, and any number of Laboratory Admins.
-The system has two kinds of administrators: the Super Admin, a built-in account, and any number of Laboratory Adminis.
+To understand activities and relations, it is essential to recognise system-building components (figure {ref>vrelsoftware2}).
+<figure vrelsoftware2>
+{{ :en:iot-open:practical:software:vrel.drawio.png?600 |}}
+<caption>VREL Nextgen building components</caption>
+</figure>
 ===== Super Admin =====
@@ Line 11: / Line 15: @@
 Regular Admin has several scenarios:
-  * User management: editing users' data, project files cleanup;
+  * User management:
-  * Managing group of users: adding and removing users to and from the group;
+    * editing User's data,
-  * Managing a group of users in the context of the devices: assigning existing devices to the group and enabling access to them, removing devices from the group;
+    * delete the User's project files (Cleanup).
-  * Managing Groups of Devices (Laboratory);
+  * Managing group of users:
-  * Configuring and managing individual Devices;
+    * creating and deleting user groups,
+    * adding and removing users to and from the group.
+  * Managing a Group of Users in the context of the devices:
+    * assign existing devices to the Group, removing device assignments from the User's Group.
+  * Managing Groups of Devices (Laboratory):
+    * creating and deleting a Group of Devices (Laboratory),
+    * managing individual Devices' assignment to the Group of Devices
+  * Configuring and managing individual Devices:
+    * creating and editing a Device with detailed technical documentation, deleting the device,
+    * cleaning up devices (deletes compilation targets),
+  * Managing User's bookings (per device).
+Below there are some hints and important information:
+  - User Groups bind Users and Devices: Users can book Devices if both are in the same group. The User can be a member of many groups. Groups typically reflect student groups (such as the Dean's group or laboratory team), and devices assigned to the group reflect module-related resources that are needed to perform lab work.
+  - Admin-level access to the Bookings is possible via the Devices menu (then expand the group and the device and check for Bookings in the context menu).
+  - Users' projects (source codes) can be cleaned up in the Users menu.
+  - Laboratory compiled and temporary files can be cleaned up in the Devices' context (Devices menu).
+  - Compiler service uses a single source file on the input, which is PlatformIO-based. Thus, all source codes constituting a project are single cpp (or other) files + platformio.ini files.
+==== Admin: device configuration ====
+Device configuration is the most complex part of the administration process. It requires the correct configuration of the end node proxy service regarding the specification of the target IoT device it manages. It is a compilation service (figure {{ref>vrelsoftware2}}) that executes compilation commands and execution.\\
+The device configuration supports several configuration parameters, many of which may be redundant or unnecessary, to ensure flexibility among different IoT hardware.
+Commands to compile and upload firmware (or configuration) are Admin-defined. Besides common configuration parts such as name, location, and description, there are obligatory sections for:
+  * Device reset (reboot, restart)
+  * Commands copying from the frontend/backend to the compiler service: define commands that transfer files to the compilation space. The defaults are for PlatformIO:
+    * copies ''platformio.ini'' to the root of the project,
+    * copies ''main.cpp'' to ''src'' subfolder.
+  * Code compilation, including check of the success with standardised return signalling to the system:
+    * remember to remove previous compilation results before subsequent compilation so that if compilation fails, the existing compiled code won't be mistaken for the new one.
+  * Verification of the successful compilation - enables Upload button - the command should check if compilation was successful and return 1 otherwise 0.
+  * Code execution (i.e. firmware upload)
+<note tip> The Aforementioned actions can have more than one command, and each command can be an SSH or CMD (bash) command.</note>
+<note tip>There are wildcards that represent some critical information, e.g. source file name, target location, etc. Those can be used in commands and passed as parameters to the external scripts that can be executed (CMDs).</note>

en/iot-open/practical/software/admins.1706389926.txt.gz · Last modified: 2024/01/27 21:12 by pczekalski