Server requirements for V1.0

[PBrunot]

Following @valerionew suggestion, I am drafting here the requirements for V1.0 version of FabLab machine management solution.

Users management

• Server must provide a list of FabLab users
• Server must be able to authenticate a FabLab user from an RFID tag identifier
• Server must handle user classes (staff / non staff)

Machines management

• Server must keep a list of machines in the lab
• Machines must have at least a name, a machine type and ID
• Server must keep track of worked hours for each machine
• Server must be able to trigger maintenance operations, based on worked hours criteria, for each machine
• Server must keep a machine operations & maintenance history (when-howlong)

Maintenance & Admin

• A web user interface must be available for Staff
• Web user interface must authenticate staff user with name/password
• Administration tasks (adding machines, users...) must not require code changes and be done through UI
• Web user interface must allow manual registration of maintenance tasks
• Web user interface must allow blocking of a lab machine (e.g. broken unit)

Boards API

• Server must provide "user RFID validation" to the boards (based on RFID tag ID)
• Server must provide "machine status" to the boards (based on machine ID)
• Server must provide "start use"/"stop use" methods to the boards (based on RFID ID + machine ID)
• Server must provide "maintenance postponed" method to the boards (based on RFID ID + machine ID)
• Server must provide "maintenance done" method to the boards (based on RFID ID + machine ID)

Connectivity

• A local Wifi connection to the boards must be available
• Server must handle at least 10 RFID boards connected simultaneously

Others requirements

• For easier maintenance Python language must be used server-side
• Server must be able to run on a Raspberry Pi platform

Open points:

• Planned maintenance tasks based on calendar time (is it needed?)
• Users history and privacy (should it be kept ?)
• Security (is http acceptable?)
• Backup of the database (where?)
• Is a local access good enough ? Making the server accessible over the internet brings some additional work (e.g. cybersecurity, https, patching...)
• Preferred protocol for boards-to-server (continue with MQTT?)
• Preferred database technology (SQLite? others?)

[valerionew]

I was about to add this to https://github.com/fablab-bergamo/rfid-arduino/issues/4 but i figured it would be more relevant here.

Are we foreseeing the case where the power of the machine is lost but the power of the server is not? Do we have a keepalive? If not, would it be enough for the machine to reconnect to the server? If that's the case, could a device "deauth" another one if they use the same name/id?

[PBrunot]

I think machine and board will share the same power source. If board goes offline and server is online, nothing would happen. Also I noticed MQTT broker has its own keepalive protocol with clients. When so when board comes back online, it will reconnect to the server and subscribe to the machine topic. In the case of different boards subscribing the same machine topc : first, it is a configuration error, as boards are physically connected to only one machine. To handle gracefully this kind of issues, I will investigate if MQTT broker can be configured to allow max 1 subscriber per topic, so that the second board will not be able to subscribe successfully the machine topic if one board already owns it I don't think we will have ever the case of a machine "blocked" because the server thinks another boards owns it because 1) machine free/not free is managed by the board and notified to the server 2) the MQTT keepalive will take care of freeing the topic.

[valerionew]

To handle gracefully this kind of issues, I will investigate if MQTT broker can be configured to allow max 1 subscriber per topic, so that the second board will not be able to subscribe successfully the machine topic if one board already owns it

I guess the proper way of doing this would be some sort of authentication. But we can definitely push this to the V2