Implement the MPC use case for Monitored Units #108

sthelen-enqs · 2024-08-29T12:43:36Z

This adds an implementation of the MPC use case for Monitored Units.

The current implementation has 2 major restrictions so far:

it automatically configures itself as a 3-phase meter (ABC) and there's no way to specify a different configuration right now
it only supports the required phase-to-neutral and not the phase-to-phase voltages

I'm opening this as a Draft PR because while this UC works, it can still be improved and I'm looking for feedback and potential improvements. Some of the areas I'm explicitly looking for feedback in are:

how best to make instantiation of the use case configurable (number of phases supported etc)
how best to adapt the public usecase API when phases are configurable (e.g. adapting functions to take []float64 or something else entirely)
how to improve the current tests, I thought about connecting a remoteDevice and reading the set values out via that but couldn't get that to work easily, the alternative as far as I can see would be to add functions to the public api and copy the cs/lpc tests

DerAndereAndi · 2024-08-29T17:27:06Z

Thanks a lot for the PR!

Some first thoughts, more will surely come:

Having individual public functions for each scenario is what surely is expected and needed. But using those individually will result in a notify update message for each call, which I think is not nice.

I do see 2 options here:

Add another public method that can take all measurement values for all scenarios, with all being optional at the end so only the ones with actual data will be used
Introducing a mechanism in the SPINE repository to combine multiple local data updates to work like a transaction, where only the transaction end will trigger the actual local data storage update which will then automatically trigger the notify messages to all subscribers

DerAndereAndi · 2024-08-29T17:52:24Z

Regarding initialization: how about the possibility to define the supported scenarios, and for each scenario define a configuration item where items like amount of phases, measurement type, reference to etc. needs to be set.

Scenario 1 is required, all other scenarios are option/recommended. And even within the scenarios there are optional items, e.g. phase specfiic power.

Also I am wondering you only added setters, but maybe it is also helpful to have getters to e.g. validate the current storage?

usecases/api/mu_mpc.go

usecases/mu/mpc/public.go

Co-authored-by: Simon Thelen <[email protected]>

Implements the new approach added by enbility#115 to allow setting measurement values independently or at the same time

sthelen-enqs · 2024-10-25T11:26:10Z

I've updated the PR with support for updating multiple measurements at the same time using the Update() function. For an example as to how to use the Update() function look at the Test_PowerPerPhase test.

The mu/mpc use case is now also configurable for e.g. non-three-phase use cases by passing configuration parameters to the NewMpc function. The config types are located in usecases/mu/mpc/config.go. For an example as to how to use these configuration parameters, look at the MPC testhelper

DerAndereAndi

Awesome updates, I really like the way you solve the multiple datapoint update topic!

usecases/usecase/usecase.go

usecases/mu/mpc/config.go

DerAndereAndi · 2024-11-01T15:19:36Z

usecases/mu/mpc/config.go

+type MonitorPowerConfig struct {
+	ConnectedPhases ConnectedPhases // The phases that are measured
+
+	ValueSourceTotal  *model.MeasurementValueSourceType // The source of the values from the acPowerTotal (not optional)


Instead of (not optional), how about writing required or mandatory?

usecases/mu/mpc/config.go

usecases/mu/mpc/usecase.go

DerAndereAndi · 2024-11-01T15:29:02Z

usecases/mu/mpc/usecase.go

+				model.FeatureTypeTypeMeasurement,
+			},
+		},
+	}


The scenarios should only be added, if the configuration for this scenario is provided and hence the application supports it. Right now this code would always report that all scenarios are supported.

Should be fixed now, though it might be nice to have tests for it as well.

Yes. Test coverage still has potential to grow ;)

DerAndereAndi · 2024-11-01T15:48:35Z

usecases/mu/mpc/usecase.go

+		panic(err)
+	}
+
+	idEc1 := model.ElectricalConnectionIdType(0)


This will cause problems, as other use cases may use an eletrical connection in the entity, and they may not be identical.

Instead we should check if one exists with the properties defined in the spec and use that. Otherwise create one.

DerAndereAndi · 2024-11-01T16:04:20Z

usecases/mu/mpc/testhelper_test.go

+	s.sut.AddFeatures()
+	s.sut.AddUseCase()
+
+	//s.remoteDevice, s.monitoredEntity = setupDevices(s.service, s.T())


I would love to see such tests as in CS/LPC to be added, not just using the mocks.

This commit also adds some fixes to allow leaving unsupported config parameters to NewMPC as nil and a test for those scenarios.

sthelen-enqs · 2024-11-04T10:19:43Z

I've updated the PR with fixes for the simple changes, will look over the rest when I have more time

DerAndereAndi

Great improvements already, thank you!

DerAndereAndi · 2024-11-04T10:31:09Z

usecases/mu/mpc/config.go

+	ValueConstraints *model.MeasurementConstraintsDataType // The constraints for the frequency values (optional can be nil)
+}
+
+func (c *MonitorPowerConfig) SupportsPhases(phase []string) bool {


It would be great to have some tests for this method standalone as well. So line 93 is also covered.

DerAndereAndi · 2024-11-04T10:34:55Z

usecases/mu/mpc/usecase.go

+	return uc, nil
+}
+
+func (e *MPC) AddFeatures() {


This method is getting quite loooooooong. How about splitting it up into individual functions for each config?
Also I am still not sure if using panics is the right approach. Maybe AddFeatures() signature should be changed to AddFeatures() error overall ?

Also the code looks quite repetitive, and maybe there is a good way to shrink this down, and thus making it also easire to improve the test coverage for all error scenarios?

sthelen-enqs force-pushed the feat/implement-mu-mpc branch from 186302a to 47947ab Compare August 29, 2024 12:47

DAMEK86 reviewed Aug 31, 2024

View reviewed changes

usecases/api/mu_mpc.go Show resolved Hide resolved

sthelen-enqs force-pushed the feat/implement-mu-mpc branch from e8b7796 to 7e07acf Compare September 27, 2024 09:34

DerAndereAndi reviewed Sep 27, 2024

View reviewed changes

usecases/mu/mpc/public.go Show resolved Hide resolved

DerAndereAndi added the enhancement New feature or request label Oct 15, 2024

sthelen-enqs force-pushed the feat/implement-mu-mpc branch from 7e07acf to a82f86c Compare October 25, 2024 10:05

nils-prommersberger and others added 4 commits October 25, 2024 12:09

Implement MPC usecase for the MonitoredUnit actor type

bdb813c

Co-authored-by: Simon Thelen <[email protected]>

Add and use allEntityTypesValid boolean instead of nil validEntityTypes

4242dc7

Update MPC to allow for updating multiple data points in one step

f2081be

Implements the new approach added by enbility#115 to allow setting measurement values independently or at the same time

Make the mpc configurable. And support option stuff.

193fc5c

sthelen-enqs force-pushed the feat/implement-mu-mpc branch from a82f86c to 193fc5c Compare October 25, 2024 10:10

sthelen-enqs marked this pull request as ready for review October 25, 2024 11:28

DerAndereAndi requested changes Nov 1, 2024

View reviewed changes

sthelen-enqs added 2 commits November 4, 2024 10:59

Fix comments and formatting mentioned in review

c70256a

Only add scenarios when they're supported

62108f5

This commit also adds some fixes to allow leaving unsupported config parameters to NewMPC as nil and a test for those scenarios.

sthelen-enqs force-pushed the feat/implement-mu-mpc branch from 6834d88 to 62108f5 Compare November 4, 2024 10:10

DerAndereAndi requested changes Nov 4, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement the MPC use case for Monitored Units #108

Implement the MPC use case for Monitored Units #108

sthelen-enqs commented Aug 29, 2024

DerAndereAndi commented Aug 29, 2024

DerAndereAndi commented Aug 29, 2024

sthelen-enqs commented Oct 25, 2024

DerAndereAndi left a comment

DerAndereAndi Nov 1, 2024

DerAndereAndi Nov 1, 2024

sthelen-enqs Nov 4, 2024

DerAndereAndi Nov 4, 2024

DerAndereAndi Nov 1, 2024

DerAndereAndi Nov 1, 2024

sthelen-enqs commented Nov 4, 2024

DerAndereAndi left a comment

DerAndereAndi Nov 4, 2024

DerAndereAndi Nov 4, 2024

Implement the MPC use case for Monitored Units #108

Are you sure you want to change the base?

Implement the MPC use case for Monitored Units #108

Conversation

sthelen-enqs commented Aug 29, 2024

DerAndereAndi commented Aug 29, 2024

DerAndereAndi commented Aug 29, 2024

sthelen-enqs commented Oct 25, 2024

DerAndereAndi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sthelen-enqs commented Nov 4, 2024

DerAndereAndi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment