search

VILLASframework / web-backend

A go implementation of the backend for VILLASweb
https://fein-aachen.org/en/projects/villas-web/
GNU General Public License v3.0
1 stars 2 forks source link

Change data model relation of Signal, ComponentConfig and IC #72

Closed stv0g closed 1 year ago

stv0g commented 3 years ago

In GitLab by @skolen on Jul 26, 2021, 14:14

I would like to propose a change in the data model of VILLASweb.

Currently the relation of a Signal, ComponentConfig and IC is like this:

IC --(1)--> ComponentConfig --(n)--> Signal

A ComponentConfig uses exactly one IC and can have n Signals (OutputMapping and InputMapping) in the DB associated with it.

However, I think it makes more sense this way:

Signal --(n)--> IC --(1)--> ComponentConfig

So the major change would be that Signals would be associated with the IC in the DB---and not with the ComponentConfig. As far as I understand, the Signals that are configured in VILLASweb have to be compliant with the selected IC anyway. If the IC does not support the configured signals, then the signal configuration will not work. We have also the option to auto-configure signals for VILLASnodes (given that the VILLASnode is set up properly). But then again, Signals are rather a property of the IC and not the ComponentConfig.

I suggest to move Signals as property to the IC (OutputMapping and InputMapping).

@iripiri @stvogel As this change of the data model would entail significant changes to the API logic, access and so on, I would like to get some feedback to my idea before I start implementation. What do you think?

The frontend issue https://git.rwth-aachen.de/acs/public/villas/web/-/issues/323 is related.

stv0g commented 3 years ago

In GitLab by @skolen on Jul 26, 2021, 14:26

mentioned in issue web#323

stv0g commented 3 years ago

In GitLab by @skolen on Aug 3, 2021, 15:08

After a discussion with @stvogel, I close this issue.

We will keep the association as it is. However, we will try to focus more on "hiding" the VILLAS node (gateway) component from the user in the frontend. The responsibility of starting and configuring the VILLAS node should move from VILLASweb to the VILLAScontroller - who should read the signal configuration for a given model and start both gateway and simulator accordingly. We will keep the option for the user to manually change the Signal config if needed, but in general, the signals should be auto-configured for a component config.

The VILLAScontroller should report status updates for both ICs (simulator and gateway) separately to make debugging for admins easier. The relation between simulator and gateway should be included in the status updates reported by the VILLAScontroller as custom property.