Pitch
pyro-engine has evolved and and this development environment does not reflect it.
The services replicating pyro-engine and cameras interactions are no longer relevant and, above all, do not allow new features to be developed.
We want it to be possible to work on pyro-engine developments without having an IP camera at home, and therefore relying on pyro-envdev.
What is done currently
Two Docker services, reolinkdev1 and reolinkdev2, simulate IP cameras that the Docker service pyro-engine would query to retrieve images.
See docker-compose file
What must be done
Take into account the new process of the pyro-engine repository.
See docker-compose file : This consists of two services:
-
reolink-api: the API responsible for interacting with the cameras (capturing images, focusing, moving PTZ cameras, etc.)
-
engine: which relies on reolink-api to interact with the cameras, in particular to retrieve images, perform detection, and generate alerts (and therefore interact with pyro-api)
-
Therefore, within pyro-envdev, develop a service that replicates reolink-api (camera-mock-api), initially in a simplified manner, i.e., providing an endpoint constructed in the same way as the reolink-api endpoint, allowing an image to be retrieved.
-
For any image requested, this endpoint will return a image taken from a folder (and shall loop in images in this directory).
-
The directory must be in a volume that makes it easy to change the images returned.
-
Next, the service engine must be set up so that it queries camera-mock-api to retrieve images and connects it correctly to the API (see pyro-engine doc -> to be updated)
-
This API must reproduce certain endpoints required for the engine to function and therefore, initially, systematically return the elements that enable proper functioning -> to be detailed.
-
Finally, it must be possible to launch only the reolink-api-mock service in order to work on new features on pyro-engine : updates makefile consequently and document the readme accordingly.
Happy to discuss it !
Pitch
pyro-engine has evolved and and this development environment does not reflect it.
The services replicating pyro-engine and cameras interactions are no longer relevant and, above all, do not allow new features to be developed.
We want it to be possible to work on pyro-engine developments without having an IP camera at home, and therefore relying on pyro-envdev.
What is done currently
Two Docker services, reolinkdev1 and reolinkdev2, simulate IP cameras that the Docker service pyro-engine would query to retrieve images.
See docker-compose file
What must be done
Take into account the new process of the pyro-engine repository.
See docker-compose file : This consists of two services:
reolink-api: the API responsible for interacting with the cameras (capturing images, focusing, moving PTZ cameras, etc.)
engine: which relies on reolink-api to interact with the cameras, in particular to retrieve images, perform detection, and generate alerts (and therefore interact with pyro-api)
Therefore, within pyro-envdev, develop a service that replicates reolink-api (camera-mock-api), initially in a simplified manner, i.e., providing an endpoint constructed in the same way as the reolink-api endpoint, allowing an image to be retrieved.
For any image requested, this endpoint will return a image taken from a folder (and shall loop in images in this directory).
The directory must be in a volume that makes it easy to change the images returned.
Next, the service engine must be set up so that it queries camera-mock-api to retrieve images and connects it correctly to the API (see pyro-engine doc -> to be updated)
This API must reproduce certain endpoints required for the engine to function and therefore, initially, systematically return the elements that enable proper functioning -> to be detailed.
Finally, it must be possible to launch only the reolink-api-mock service in order to work on new features on pyro-engine : updates makefile consequently and document the readme accordingly.
Happy to discuss it !