This page descirbes the Cloud Integrations support for Fronius. See Fronius Solar.web API for information about the Fronius API.

The Fronius integration service identifier is s10k.c2c.i9n.fronius. The following service properties are supported:

The Fronius integration supports the following Cloud Datum Stream Service implementations:

The Fronius datum stream service identifier is s10k.c2c.ds.fronius.

The following service properties are supported:

The following placeholders are supported on the placeholders service property:

The following Data Filters are supported:

The Fronius integration uses the following data value cloud-speicifc metadata keys (refer to the Fronius API documentation for more information on possible values):

The Fronius cloud data value model is represented in 3 levels:

1. System
2. Device
3. Channel (property)

System and Device objects have unique IDs. Channels have names like EnergyExported or GridPowerA. Value references are formed as:

/{systemId}/{deviceId}/{channelName}

For example:

/3e210d7d-2b9e-43d6-830a-000000000000/5faf4ac6-e79e-4b42-a644-000000000000/ApparentPower

Using placeholders a value reference could be instead specified like:

/{systemId}/{deviceId}/EnergyExported

By default the Fronius Datum Steam service will generate unique source IDs based on the combination of the Datum Stream sourceId value and the pattern /{systemId}/{deviceId} taken from the configured data value references in the stream's property mappings.

Assuming your Datum Stream was configured with a sourceId of S01, you could configure mapping properties like this:

☝️ Note the reference component IDs shown here have been shortened for brevity.

Then SolarNetwork would generate 2 datum streams:

1. S01/3e210d7d/5faf4ac6
2. S01/3e210d7d/4b42a644

You can also define an explicit mapping of components to source IDs with a sourceIdMap service property on a Datum Stream. This can be specified as a map or comma-delimited mapping list of component IDs to associated source ID values. For example in JSON, the sourceIdMap service property could be specified as an object like:

{"/3e210d7d/5faf4ac6":"S1/INV", "/3e210d7d/4b42a644":"S1/GEN"}

or a string like:

"/3e210d7d/5faf4ac6=S1/INV, /3e210d7d/4b42a644=S1/GEN"

A complete example of the Datum Stream could look like this:

{
  "enabled": true,
  "name": "Fronius Test",
  "datumStreamMappingId": 1,
  "schedule": "3600",
  "kind": "n",
  "objectId": 123,
  "sourceId": "unused",
  "serviceIdentifier": "s10k.c2c.ds.fronius",
  "serviceProperties": {
	"sourceIdMap": {
	  "/3e210d7d/5faf4ac6": "S1/INV",
	  "/3e210d7d/4b42a644": "S1/GEN"
	}
  }
}

Here the generated datum streams would be S1/INV and S1/GEN because of the sourceIdMap setting. The unused sourceId setting would not be used, and SolarNetwork would generate 2 datum streams:

1. S1/INV
2. S1/GEN

☝️ When sourceIdMap is configured, only the devices explicitly included will be generated into datum streams, and all other devices will be ignored.

When an explicit sourceIdMap service property is configured, a set of placeholders is automatically generated from the mapping keys:

1. {systemId}
2. {deviceId}

This means you can configure value references that take advantage of those placeholders in the stream's associated datum property mappings. For example, given the previous sourceIdMap example:

{
   "sourceIdMap": {
	  "/3e210d7d/5faf4ac6": "S1/INV",
	  "/3e210d7d/4b42a644": "S1/GEN"
	}
}

and a set of property mappings like this:

Then both the S1/INV and S1/GEN datum streams would be resolved. Although all mappings will be applied to all datum, only inverter devices support VoltageA and EnergyExported and only meter devices support GridEnergyExported and GridEnergyImported, so the effective value references are:

Because Fronius does not provide meter-reading style energy data channels typically mapped to an accumulting wattHours property, an expression property can be used to derive one. For example, assuming a wh_exp property mapped from a EnergyExported or GridEnergyExported channel:

has('wh_exp') && hasOffset(1, timestamp) && offset(1, timestamp).props['wattHours'] != null
? offset(1, timestamp).wattHours + wh_exp
: has('wh_exp')
? wh_exp
: 0

Similaryly, a "reverse" style meter-reading style expression could generate a wattHoursReverse property, assuming a wh_imp property mapped from a EnergyImported or GridEnergyImported channel:

has('wh_imp') && hasOffset(1, timestamp) && offset(1, timestamp).props['wattHoursReverse'] != null
? offset(1, timestamp).wattHoursReverse + wh_imp
: has('wh_imp')
? wh_imp
: 0

Additionally, Fronius may not provide "phase aggregate" data channels. For example a meter might provide GridPowerA, GridPowerA, GridPowerC channels. Assuming you map each of those channels to properties named watts_a, watts_b, and watts_c, you could configure an expression to generate a watts total power property like this:

has('watts_a') ? sum(group('watts_.*')) : null

Another phase aggregate example is to calculate an average voltage from voltage_a, voltage_b, and voltage_c properties configured from GridVoltageA, GridVoltageB, and GridVoltageC channels:

has('voltage_a') ? round(avg(group('voltage_.*')), 1) : null

This service supports the Cloud Datum Stream import service.