Trying to create an automated greenhouse
License: MIT License
Hi!
My name is Andrea (user: WinterWind33). I'm a professional software developer.
I'm currently working as a full time C++ developer at Zuru Tech.
The greenhouse controller needs an entry point that is capable to print basic software information:
After the milestone for the first prototype is delivered, we don't need anymore the automatic version increment as the new version will be 1.0.0+ and new version won't be automatic.
The first thing we need to have is a good CI/CD in order to build and test our software, prevent and catch bugs on a daily basis. This implies that the first things that need to be set up are:
Because the user will send input to the software from different kind of channels, we need our application class to have an injectable input stream where it can read requests from the user/external units.
This will improve testability and it'll follow the DI principle.
In order to meet the basic UX MVP, the greenhouse controller application calls was approximated and technical debt was added.
With these refactor we want to remove duplicated code, meet SRP, DIP and improve the current existing tests.
As we are working with hardware, we need a pool of resources that needs to be released when the software performs an emergency abort or exits.
The user needs to interact with the software. The initial idea is that the user will type some command and the application will execute its logic after that.
In order to parse and process the user commands, we need a module that works as an interpreter for the commands.
The user must be able to type in a command to request a list of all the feature toggles implemented inside the application with their description.
The command must be accepted during the application execution and with the launch command:
$ rpi_gc --<command>
Some of the software included inside this repo needs to be run inside a Raspberry PI 3B+ (e.g. RPI_GC) while others are specific for desktop environments.
For those application that need to be run inside the RPI we want that our build and tests workflow has a RPI runner.
Currently, the logger doesn't automatically flush when a new entry is given but this could cause loss of information when the application crashes.
With this issue, we need to add a way to automatically flush the logging system every time a new entry is added.
As we wanted to wrap libraries so we can compile the software in every platform, we need an efficient error handling system that can wrap errors that comes from these libraries.
These errors need to be platform-independent and they must be included in the basic framework.
Connect the new interpreter module to the main application logic so that, when the user types some command, it can be parsed and executed.
Add the possibility to override the pin where valve and pump are attached.
As the greenhouse is a software that runs on a physical hardware, it should be created and designed a termination system, i.e. a set of logics that are capable to terminate the software execution whenever a fatal error is encountered during the normal software flow.
Before writing code about reading humidity values from the external sensors, we need to design the software components and to document the hardware requisites, such as the input channel etc...
After the command interpreter is connected to the main flow, the user must be able to:
These two commands must be accepted even when the application is not executed but are passed as arguments to the application launch command, i.e.:
$ rpi_gc --version
$ rpi_gc --helpAs the old gpio library is unusable and doesn't work, we're going to try a new library, libgpiod.
Since the library offers command line tools to detect and try the code, a script can be created for the user so we can test if it works or not.
We need to add a class that represents the application and that is instanced inside the RPI_GC entry point. This application class will be responsible to handle the application main flow and it will handle user/external requests.
The application class must have an injectable output dependency, i.e. the output produced by the application class and its dependencies mustn't know details about the output streams used, they must be injected from the outside.
This will:
During the application execution, if a request to enable/disable a feature toggle is made to the software then the application must be able to trigger their respective events so that the application can turn on/turn off the requested features.
We need a set of classes/entities inside the feature toggle framework in order to achieve this.
Currently, when a test uses a StrictMock mock and an uninteresting call is made (and probably an expectation is not me in general) the test crashes with a segmentation violation.
Probably the crash is given by the fact that these messages are not integrated with Catch2.
Example:
The user must be able to turn on/turn off feature toggles during the application execution and during the launch command.
In order to start working with a good framework, we need to setup the project dependencies. This means that we need to add third-party libraries that can be used as the starting point for the software development process.
Add a CMake module that is linked against the RPI_GC controller and that will contain a basic framework for managing feature toggles.
When the user starts the automatic watering system, the watering system doesn't transit to the stopped state after execution. This can cause the application to crash.
auto-watering --start;exit command;Expected result: The system should warn the user that the system is not running when exiting the application and after the watering system has finished its job.
Build references:
Add a command that can activate automatic watering (help + flow attachment)
With the old CppGPIO library the raspberry seems to not work properly, the pins don't even turn up. Try to remove the old library and add the libgpiod library as gpio driver.
Right now the repository depends on third-party repos and they are added as submodules. The problem arises when, in the workflows, builds are triggered, as many of these repos are very huge and the compilation is slowed down.
We need to find a solution, like pre-compiled modules, in order to speed up the workflows execution.
Currently, we have a workflow that is executed when a PR is marked as "Ready for review" where it builds and run tests for the rpi_gc target.
This workflow is particularly heavy, and it takes ~50 minutes to complete. This is not acceptable, as this time increases every time a new feature is added to the software.
The proposal is to add a new workflow that only builds the "rpi_gc" target when the PR is ready, but it runs on a ubuntu-latest workflow where it installs the gcc compiler for aarch64 before compiling the application.
Adds an interface that represents a feature toggle. The interface must provide methods for enabling, disabling and reading the state of the feature toggle at run-time.
In order to have a better comprehension of what is going on in the greenhouse, the logger should flush the information periodically so the user can see what is happening.
As for now, the flush is done at the end of the process, which may not occur in real life.
In order to create a software that is completely independent from the underlying platform, we need to wrap third party libraries into useful classes and frameworks that can be always compiled.
When a library cannot be compiled on a certain platform, the framework must act as a double. For a first iteration, the framework can have an empty implementation when this happens.
Right now, if the automatic watering loop is executed, after the valve and the pump have been activate, the user cannot stops the automatic watering until ten minutes passes.
Change the logic to check a stop request more frequently.
Add a simple input loop logic that will prompt the user to type some command and press enter. The main application thread will wait the user to type something before proceeding with the loop.
The new libgpiod version 2.0.1 is out now. Update the configuration to use that instead of the 2.0.1.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.