-
Notifications
You must be signed in to change notification settings - Fork 2
SolarEdge Cloud Integrations
This page descirbes the Cloud Integrations support for SolarEdge.
The SolarEdge integration service identifier is s10k.c2c.i9n.solaredge.v1. The following service
properties are supported:
| Property | Description |
|---|---|
apiKey |
The SolarEdge V1 API key |
baseUrl |
An optional alternate URL to use to access the cloud service |
The SolarEdge integration supports the following Cloud Datum Stream Service implementations:
| Service | Identifier | Description |
|---|---|---|
| SolarEdge | s10k.c2c.ds.solaredge.v1 |
Polling datum stream using the SolarEdge API. |
The SolarEdge datum stream service identifier is s10k.c2c.ds.solaredge.v1. The following service
properties are supported:
| Property | Description |
|---|---|
resolution |
The resolution of the data to request. One of QUARTER_OF_AN_HOUR (default) or HOURLY
|
placeholders |
An optional Map of placeholder names with asscoiated values, to make available to Datum Stream Mapping Property value references |
sourceIdMap |
A map or comma-delimited mapping list of component IDs to associated source ID values. See source ID mapping for more information. |
The following placeholders are supported on the placeholders service property:
| Placeholder | Description |
|---|---|
siteId |
A single SolarEdge site ID value to associate with the datum stream |
The following Data Filters are supported:
| Filter Key | Description |
|---|---|
siteId |
A SolarEdge site ID value |
deviceType |
A SolarEdge device type, one of bat, inv, or met for battery, inverter, or meter |
componentId |
A SolarEdge component ID value |
The SolarEdge API returns data for all devices within a site, and as such the Datum Stream Service
can generate SolarNetwork datum streams for multiple devices at once, if desired. To do so, the
valueReference for a Datum Stream Mapping
Property can use a *
wildcard for the 3nd-level identifier. This can be combined with the {siteId} placeholder.
SolarNetework will then take the sourceId defined on the Datum
Stream and append /TYPE/X to each device in the
site, where TYPE is a device type identifier like inv or met and X is the component identifier.
For example, imagine the Data Values
method returned an inverter 11111111 and meter Production for site 12345 like this:
{
"success": true,
"data": [
{
"name": "Inverters",
"identifiers": [
"12345",
"inv"
],
"children": [
{
"name": "Inverter 1",
"identifiers": [
"12345",
"inv",
"11111111"
],
"metadata": {
"serial": "11111111",
"manufacturer": "SolarEdge",
"model": "SE7600A-USS20NHY2",
"firmwareVersion": "DSP1: 1.210.1623, DSP2: 1.210.1623, CPU: 3.2724.0"
}
}
]
},
{
"name": "Meters",
"identifiers": [
"12345",
"met"
],
"children": [
{
"name": "Production Meter",
"identifiers": [
"12345",
"met",
"Production"
],
"metadata": {
"serial": "22222222",
"manufacturer": "SolarEdge",
"model": "SE-RGMTR-1D-240C-A",
"connectedTo": "Inverter 1",
"connectedToSerial": "11111111",
"firmwareVersion": "62"
}
}
]
}
]
}Assuming your Datum Stream was configured
with a sourceId of S01, you could configure mapping properties like this:
| Value Reference | SolarNetwork Property | Property Type |
|---|---|---|
/{siteId}/inv/*/W |
watts |
i |
/{siteId}/inv/*/TotWhExp |
wattHours |
a |
/{siteId}/met/*/W |
watts |
i |
/{siteId}/met/*/TotWh |
wattHours |
a |
Then SolarNetwork would generate 2 datum streams: S01/inv/11111111 and S01/met/Production, both
with watts and wattHours properties.
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:
{"/12345/inv/11111111":"S1/INV/01", "/12345/met/Production":"S1/MET/01"}or a string like:
"/12345/inv/11111111=S1/INV/01, /12345/met/Production=S1/MET/01"A complete example of the Datum Stream could look like this:
{
"enabled": true,
"name": "SolarEdge Example",
"serviceIdentifier": "s10k.c2c.ds.solaredge.v1",
"integrationId": 1,
"schedule": "300",
"kind": "n",
"objectId": "123",
"sourceId": "unused",
"serviceProperties": {
"resolution": "QUARTER_OF_AN_HOUR",
"siteId": 12345,
"sourceIdMap": {
"/12345/inv/11111111": "S1/INV/01",
"/12345/met/Production": "S1/MET/01",
}
}
}Here the generated datum streams would be S1/INV/01 and S1/MET/01 because of the sourceIdMap
setting. The unused sourceId setting would not be used.
☝️ When
sourceIdMapis configured, only the devices explicitly included will be generated into datum streams, and all other devices will be ignored.
- SolarNetwork API access
- SolarNetwork API authentication
- SolarNetwork API rate limiting
- SolarNetwork global objects
- SolarNetwork aggregation
- SolarFlux API
- SolarIn API
- SolarQuery API
-
SolarUser API
- SolarUser enumerated types
- SolarUser datum expire API
- SolarUser datum export API
- SolarUser datum import API
- SolarUser event hook API
- SolarUser location request API
- SolarUser Cloud Integrations API
- SolarUser DIN API
- SolarUser DNP3 API
- SolarUser ININ API
- SolarUser OCPP API
- SolarUser OSCP API
- SolarUser Secrets API
- SolarUser SolarFlux API