Update GET/{connection_id}/profile with connection specifics

[Stroomversnelling]

Is your feature request related to a problem? Please describe.
There is a lot of non-measured information about a connection that is relevant to store.

Describe the solution you'd like
Have GET /{connection_id}/profile return a number of connection specifics.

Describe alternatives you've considered
N/A

Additional context
In general connection specifics can be listed as follows:

• variablename_value [number]
• variablename_unit [string]
• variablename_description [string]

A number of connection specifics that could be needed:

• latitude [number] > in 1 decimal (0.1), so the length is appr. 7 km in The Netherlands. Needed for solar irradiation and weather.
• longitude [number] > same.
• construction_type [factor] > see VERA or VABI standard.
• usage_type [factor] > see VERA standard.
• pv_installed_peak [integer]
• pv_orientation [integer]
• pv_inclination [integer]
• power_consumption_max [integer] > number of Amps after which the fuses would blow.
• heat_demand_design [integer] > supposed insulation in kWh_th/m2/year.

[FilipAben]

Doesn't this belong more in {connection_id}/config as these are more configuration items than measurements?

[Stroomversnelling]

Both /config and /profile are, in a way, configuration items. The difference is that /config relates to how the actual measurement data is structured, where /profile describes other characteristics of the {connection_id} that have no direct relationship to the measurement data.

[Stroomversnelling]

Hier horen ook de design_xxxx & guarantee_xxxx variabelen thuis (zie documentatie). Dat zijn namelijk waarden die iets zeggen over de woning, maar die niets met meten te maken hebben. De annual_xxxx variabelen kunnen we inmiddels laten vallen, omdat we de API hebben ingericht op het realtime berekenen van die waarden op het moment dat ze opgevraagd worden.

[FilipAben]

Ok, I think I get it. It would be good to have clear examples of this in the documentation.

[nickdickinson]

Marten and I think it may be clearer to combine profile and config to simply specify the norm/standard in question when querying data_objects and provide data_objects with a start_date and end_date (optional) to provide both the configuration information and the measurement data as both can change over time. For example, if the design_xxxx and gaurantee_xxxx change after a certain date then this has to be recorded. Simpler to keep everything in data objects and under profiles.

An additional simplification for app developers and users may be to provide high level data objects defined in the same for profile variables like E_gen that would just have a start date and provide a continuous time series even if the underlying calculations change / data objects have changed. For example an additional inverter has been added and the underlying operations requires adding one more inverter value. It makes sense to provide underlying data_objects with start and end dates with the different types of calculations. Perhaps named E_gen_calc.

So E_gen would look like this:

{ "data_object": { "object_id": 0, "name": "E_gen", "description": "Total gross energy production of electricity", "unit": "kWh", "start": "2019-03-25 08:00", "members": [ "E_gen_calc" ], "operations": [ "E_gen_calc" ] }, "time_series": [ { ... } ] }

There may be one or more data_objects named E_gen_calc with different object_id's and different start and end dates (not overlapping).

[rsa2010]

A profile can tell you which configurations are supported but this doesn't mean you will have access to all.
This also means that you might not be able to see specific details of a supported configuration without proper credentials. So I'm opting to keep this separated.

For E_gen (and others), we do not force a specific implementation but in case there is an additional invertor added, this simple goes into the configuration (extending the current members of E-gen)

For instance: E_gen = E_pv1 + E_pv2
As soon as member E_pv2 is added, E_gen will give correct values (from the date E_pv2 is supplying reading to the database)

E_pv1 and E_pv2 will have it's own members (for instance E_pv1_import and E_pv1_export)
E_pv1 will have members E_pv1_export, E_pv1_import with operation E_pv1_export, - , E_pv1_import

The top level E_gen will have members E_pv1, E_pv2 with operation E_pv1,+,E_pv2

[nickdickinson]

Thanks for the examples. This is useful. I'd like to go through the case of changing the number of inverters (taking away or adding) as I think it will be useful to explore the implications both for app developers and for the server side. It also has implications in how a log is used and how errors are checked.

Let's take the example of removing an inverter. I'm nesting the high level variable E_gen as E_gen_calc and I'll show why:
E_gen=E_gen_calc
E_gen_calc = E_pv1 + E_pv2 + E_pv3
E_pv1 = E_pv1_export - E_pv1_import
...

Let's say E_gen_calc has the object_id = 3. Then when the first inverter is removed then this E_gen_calc would expire and another E_gen_calc object would be created with object_id = 55 with a new start date from the moment it is installed. This would allow apps / audits to distinguish in the new setup the difference between missing data of E_pv1 after removal (error?) vs. missing data because it isn't there in the first place. The new setup without E_pv1 looks like:
E_gen=E_gen_calc
E_gen_calc = E_pv2 + E_pv3
E_pv2 = E_pv2_export - E_pv2_import
...

The additional nesting of the high level object defined in the profile would allow a call to a profile to return only the high level objects defined in the profile with the full time series without having to worry about start and end dates if this structure would be used.

I'm just trying to understand how this case is addressed in the current setup. If it would require going back to the log, I think it could get very messy. If it requires a new connection_id then it could also get difficult for time series in the UI.

A quick response regarding profile/ and config/ (maybe a separate discussion): currently version and timezone are the only parameters different between the profile/ and config/ endpoints. I don't yet understand the purpose of keeping them separate we it adds code without significant function. From a security perspective, the user should not get any information about profiles they don't have access to.

I would think a call to profile/ then would only provide a list of profiles supported AND to which the user has access but not all data objects.

The a call to either profile/{profile_id} or profile/?name={profile_name} would then provide access to the data_object array and associated metadata.

[Stroomversnelling]

Fixed.