Added MQTT client, Maintenance tap feature, C++ style rework, Tasks

fablab-bergamo / Fab-O-matic

RFID machine access solution for a Fab Lab, based on ESP32. Uses modern C++ with Arduino framework. Hardware project is included.

https://www.fablabbergamo.it/2024/06/03/fabomatic1/

MIT License

2 stars 3 forks source link

Added MQTT client, Maintenance tap feature, C++ style rework, Tasks #3

Closed PBrunot closed 1 year ago

PBrunot commented 1 year ago

removed secrets.h

PBrunot commented 1 year ago

Notable changes in this PR:

I have used a cooperative task scheduler to simplify loop() with several independent tasks.
I configured platform.io cland-tidy as linter and removed many warnings, so C++ code shall look decent now
Configured clang-tidy integration in platform.io ; but it has a bug on windows ( https://github.com/platformio/platformio-core/issues/4446 ). Build still works on Windows with VSCODE+Platform.io extension.
I created a GitHub action to automatically use platformio to build on push and archive BIN files. They get deleted after 10 days.

Still missing for V1.0:

server integration (mock functions only)
some automated tests.

valerionew commented 1 year ago

This is excellent progress, congrats! 🤩

For the server-machine communication, should we stick with the MQTT protocol that was foreseen by me and @lorossi?

An issue I can see with the automated builds is that:

secrets should not be distributed publicly with the compiled bin (very easy to reverse engineer);
a compiled bin without the secrets is not really useful.

So I don't really know if there is a good way to solve this. Is private artifacts a thing?

PBrunot commented 1 year ago

@valerionew : ok, I can implement a MQTT client and move on this topic.

Right now the builds are based on secrets.h.example which do not contain any useful information. I don't see a good way to protect the contents for automated builds. I mean, if the goal is to have one standard image, and make this public, we can't have a custom list of RFID badge in the image, even if encrypted somehow.

On the other hand, having a whitelist is really a good idea to make the solution reliable even in case of network/server failures.

One option could be to add a method to the server, to provide a list of whitelisted users (maybe all the fablab staff priviledged users), and then we could persist this on ESP32 flash memory. This requires the ESP32 to be online with the server at least once... What do you think?