search

SmartGridready / SGrSpecifications

SmartGridready Specifications
BSD 3-Clause "New" or "Revised" License
0 stars 1 forks source link

Device-wide valid data point handling #90

Open ChrisBroenni opened 1 year ago

ChrisBroenni commented 1 year ago

User Voice

Many Modbus devices use data points that are used devcie wide.

Examples:

  1. Garo wallbox fallback timeout counter for HEMS Current limit is triggerd by ANY modbus acces to the device
  2. CTA Heatpump remote acces counter (enabling the setpoints for a certain time) are valid for ALL setpoints

Suggested Solution

Extend the range of SubProfileTypeEnumType with a "DeviceInformation" functional profile (it may replace "UNDEF"). remove the ProfileTypeEnumType "DeviceInformation" for avoiding misunderstandings Advantage: fits to the existing setVal / getVal methodology
DeviceInformation was inherited from EEBUS but does not make sense any more as we use ProfileTypeEnumType definietions for documenting future virtual devices. It makes no sense to add another device element in the logical tree

Alternatives (optional)

We may ectend the SGrDeviceProfileType with data points Advantage: fits to the existing general view

Acceptance Criteria

List the criterias that need to be met to declare this feature as implemented. This section must be complete and agreed upon before starting implementation.

Open Questions

none yet

Additional context none yet.

ergozeller commented 1 year ago

Hi @ChrisBroenni

It seems that these device data points will be device specific, and probalby will have almost no potential for standardization, correct? For communicators this basically breaks device-independent implementation based purely on functional profiles.

If so I suggest to separate these new structures clearly from the standardizes part in the functional profiles, and therefore not to recycle functional profile structures as not to confuse uses. I would rather create a new complexType "deviceListElement" that contains an unbounded lsit of dplistElements.

We probably should require a mandatory dpPrgDesc element.

Do we need default values? This would perhaps help to minimize device-specific implementations for communicators, at least for some basic applications...

ChrisBroenni commented 1 year ago

Yes, these device data points will be device specific. After the discussion with ergozeller and ergo-furrer the follwing decitions have been made:

so far, we allighn these types of data to each functional profile with a remark in this data point has a device wide impact in extending timeouts for. X,Y,Z...... </sgr:textElement>en</sgr:language> </sgr:dpPrgDesc> or similar.

The issue is NOT deleted as we intend to review it after the config data architecture design has been completed.