Now drivers are just the configuration file.json for each sensor, since the main is expected to be the same for each sensor to be run, creating an instance for the specific class according to the name passed as argument, it could be useful to download from drivers service the class too.

When the service catalog is up, it stores information about how to retrive other services. However, when a service starts, does it need to perform a request to the catalog to know the port in which it is expected to run? Otherwise, it starts the process, pinging the catalog about the actual address is using.

The function was implemented to create the final url address, merging IP address and port. However, the hypothesis for the current implementation is that a service (like the profiles one) pings the service catalog to know the expected address. Therefore, it is not used now.

Some error exceptions are defined, in particular for GET functionalities. A further attention is expected for POST/PUT/DEL to handle possible errors during requests. Different test should be performed to study the reactions to bad requests.

Avoid to give information of other users due to particular requests.

Configuration could be lighter. Now each room is directly connected to the final server during configuration phase. It should be replaced by a procedure in which the hub is in charge of performing the configuration phase. So that, sensors will communicate with the server when connection is performed only, through MQTT. In this way, REST communications with outside world can be reduced.

Some evaluations should be performed on collected data. Also MRT needs to be computed. A new service inside the server can be created.

When should the system save for each database? Last update (develop) saves when a new successful change is attempted. Saving could be provided after some time or before exiting.

Use PUT when you can update a resource completely through a specific resource. For instance, if you know that an article resides at http://example.org/article/1234, you can PUT a new resource representation of this article directly through a PUT on this URL.

If you do not know the actual resource location, for instance, when you add a new article, but do not have any idea where to store it, you can POST it to an URL, and let the server decide the actual URL.

https://restcookbook.com/HTTP%20Methods/put-vs-post/

In a first time, when a new room or device is added to the catalog, the instance of the object is generated according to the main parameters previously defined for a specific structure (room_ID, MRT, devices), avoiding bad requests. However, if new parameters are needed, there are many aspects to modify. This approach can be changed adding directly the json_body of the request to the catalog.

To exploit better the profile service, since clo and met should be set by the user with limited knowledge, according to the name/type of room registered inside profile service, the application should provide reasonable suggestion for this configuration. Then, the value is sent to resource catalog.

Maybe a new client should be added through POST/PUT rather than GET during registration phase.

It should be decided how to handle parameters values during the configuration phase (if the value is null) and the consequently behaviour. At this moment, try-except is used for remove inactive devices

Check how to retrieve data from the server to create a influxDB database and the related dashboard in Grafana in real-time.

There is the possibility to delete a device with the specific http command. It is useful in testing phase, but it should be decided if keep it also for the final user. In general, the effects should be properly implemented. In fact, the sensor keep sending measurements, generating an error. Now, the catalog use try/except to neglect errors. Therefore, the sensor needs to be launched again for a new installation. In general, this function can be removed (using only removeInactive) or the catalog can return an error/warning or the sensor should be stopped.

The main script is now with the same structure of the others in terms of configuration and related packages. Errors management is missing. The server is working but all html files should be adapted (they are still referring to 192.168.1.130/leaf) and tested. It is important to modify such that files are automatically set according to the configuration of the registration service (like the python script, retrieving information from etc/db.json and from the catalog service).