Welcome to the documentation repository for IOT platform for energy projects.

See platform overview

High level project plan:

MILESTONE 1: POC

EMS

We prototype our EMS with Thingsboard. We need to define:

• a data structure so we can store telemetry data from gateway for a subsystem
• a dashboard structure so we can navigate from site > subsystem > BESS module > battery cluster > battery pack for example.
• basic data for devices from simulator
• we can add a few controls widgets placeholders
• we test with 1 site > 1 subsystem > 2 BESS modules

Gateway

• a simple simulator to generate debug POC data for 2 BESS modules into demo subsystem.

MILESTONE 2: Beta release

EMS

We need to prepare for actual subsystem tests:

• build complete dashboards with more data, more control widgets.
• add more RPC to enable remote control and to fetch control data on demand
• add some rules for basic control logic.

Gateway

Improve simulator for complete data and with RPC mock answers logic.

Prepare and debug real gateway for one subsystem with 2 BESS modules:

• Get source code for gateway for 20C1200K container.
• review source code.
• define how to integrate to Thingsboard EMS. preferably keep existing gateway structure and data formats and convert data at thingsboard server? or add a layer of transcoding in gateway ?

MILESTONE 3: pre production gateway and edge controller

EMS

Finetune dashboard and widgets for EMS monitoring and control for one subsystem with 2 BESS modules.

Gateway

Transition to real gateway testing and debugging.

Edge controller and dashboards

Add Edge controller for site with subsystems edge dashboard for local monitoring and control of site subsystems.

SKYTALK platform

Overview

We build and need to monitor and operate Battery Energy storage systems, sometimes with solar panels installed in parallel.

EMS platform has a structure with entities like assets or devices which can have attributes and telemtry data.

DRAFT

Entities and devices

EMS platform manages telemetry and attributes data for assets or devices. Assets can be virtual, devices normally represent actual things.

The architecture of the EMS platform is designed to manage energy sites with solar, storage, consumption and other optional devices like ev chargers or HVAC which affect energy efficiency and can be managed via platform.

Assets and devices for energy site

Naming conventions

EMS platform requires entities (devices and assets) to have a unique name, so we use a naming convention:

• Each site has a unique site prefix like “EE001” (2 letter country code and a unique number). This is defined as an asset assigned to customer.
• Each site has 4 fixed virtual nodes to support energy management (see below) “EE001 Meter”
• Nodes can contain multiple Blocks (of devices) or the same type.
• Blocks contain multiple devices of the same type. This standard site > nodes > blocks > devices hierarchy allows us to organize our EMS data in a common format and to develop advanced dashboards which can be reused for every customer site.

Site nodes

We define 4 virtual asset nodes for each site which represent key data for energy management needed for energy optimizer service providers and for tenant level dashboards:

• POC meter node (total measured energy and power at grid connection)
• Solar production node (total of all solar inverters on site)
• Plant consumptions node (total of all consumption on site - via meters)
• BESS node (total of all BESS inverters on site + available power for charge or discharge + total of all batteries on site - available charge or discharge capacity + State of Charge)

Each node represents the total for all relevant devices for the site: so EE001 Solar should show all solar production for the site (ie 2 PV blocks – one with 5 inverters, another one with 6) and BESS should show all inverters and batteries capacities available (for example 1 or 2 BESS blocks, each with 5 inverters and 5 battery strings).

Devices profiles

We register site and fixed nodes as assets. Blocks and devices are registered as devices, even if sometimes a block does not represent a device:

• solar blocks are groups, there is no device for the block
• bess blocks are device with a controller and the block may have a meter and multiple strings

We have asset or device profiles for all standard nodes, block and devices expected:

• nodes
• blocks
• devices

Device profiles are used to categorize devices and define standard attributes and custom device dashboard for each device profile.

hierarchical relations

EMS platform allows to define "Contains" relationship to create a hierarchiy site > nodes > blocks > devices. This is useful to enable hierarchical navigation in Dashboards and data rollup.

Exceptions:

• The site controller device is attached under site directly and acts as gateway (it pubishes data for all devices connected to it).
• The meter node contains no blocks, usually just one meter device.

Devices for site

Devices are almost always organized in blocks: The first site has one BESS block (ES01) with 5 AC battery strings, two PV blocks (PV01 and PV02) each with solar inverters, and a POC meter and a site controller (gateway):

See Devices configuration XLS sheet for the site for latest configuration.

DRAFT

See entities and devices for device code conventions

Data types

We use standardized data and units so that we can compare data from different devices, sites or customers.

• We use camelCase format.
• We need to define a standard unit and unit power factor: for example all power data in W, all energy in Wh, all temperatures in C, all frequencies in Hz. The gateway has conversion routines available on server to convert data if needed?

We store standard data such as:

gateway connection

The Site gateway (usually the site controller) is the only device connecting to EMS platform to handle

• all attributes and telemetry data
• all subscriptions and RPC commands received from EMS platform

The gateway connection is via MQTT:

Telemetry data format - V1

We have:

• SIEMENS site controller as Modbus server which consolidates all site devices data.
• Teltonika RUTX router with 4G connection which can poll site controller registers every xx seconds and push a list of key:values to EMS platform via MQTT

V1 data map and forma

For now, the site controller has one dedicated telemetry register per device connected to site controller. This Modbus register contains a string of comma separated key,value pairs representing telemetry data for the device, prefixed with device type and timestamp. These registers are polled by teltonika router and assigned to the device name like this

{
"EE001 PV1 PC1": "inverter,1734506822436,key1,value1,key2,value2... keyN,valueN",
"EE001 ES1 BC1": "battery string,1734506838687,key1,value1,key2,value2",
"EE001 ES": "node meter,0,key1,value1,key2,value2",
...
}

The EMS platform receives this data and after parsing, it saves the telemetry data to each corresponding device.

timestamp

Timestamp can optionally be provided by site controller as second value in string, or the value is set to 0 and the server will attach server timestamp. difference is the MQTT latency plus polling interval, which is rarely meaningful.

Attributes data format - V1

coming soon, not critical

telemetry data example

NOTE: units are not required ? fixed for each data type.

Example of data for Energy storage block 1 in site EE001:

Gateway nodes data publishing

The nodes data is used by energy platforms to monitor the site total energy state and capabilities and needs to be published regularly.

This will be updated with additional site data required by energy optimizing services like Fusebox or Capalo...

power covention: TO BE CONFIRMED

• charge/consumption is positive
• discharge/production is negative NOTE: BESS is the opposite for inverter power !!!

Publishing with flat JSON syntax

//Topic: v1/devices/me/telemetry
{
  "EE001_MT_meterNode": "energyConsumptionTotal, 100000,energyProductionTotal,920000,energyConsumptionToday,190000,energyProductionToday,8000,power,-190000",
  "EE001_PV_solarNode": "energyProductionTotal,920000,energyProductionToday,8000,power,40000",
...
}

The EMS platform has a converter that will parse the value string to extract device type, timestamp

The gateway converter will convert to below EMS syntax and add timestamp:

EMS JSON syntax

[{
  "deviceName": "EE001_MT",
  "deviceType": "meterNode",
  "telemetry": [
    { "ts": 1734506822436,
    "values": {
        "energyConsumptionTotal": 100000,
        "energyProductionTotal": 920000,
        "energyConsumptionToday": 190000,
        "energyProductionToday": 8000,
        "power": -190000
        }
    }]
}, {
  "deviceName": "EE001_PV",
  "deviceType": "solarNode",
  "telemetry": [
    { "ts": 1734506838687, // set by server converter
    "values":  {
        "energyProductionTotal": 920000,
        "energyProductionToday": 80000,
        "power": 40000
      }
    }]
}
]

NOT UP TO DATE BELOW

Gateway block data publishing

blocks data can be published block by block.

BESS block(s) publishing

The energy values come from each BESS block meter. the string values come from BESS block controller.

mode for BESS are:

• 0: stopped
• 1: standby
• 2: charge
• 3: discharge
• 4: calibration
• 5: hibernate
• 6: reserved
• 7: fault - stopped
• 8: fire alarm - stopped

power: TO BE CONFIRMED:

• charge/consumption is negative
• discharge/production is positive

complete Bess block data update

Note this data representation is for convenience, the data is joined in comma separated string prefixed by device type and timestamp.

//Topic: v1/gateway/telemetry
{
  "EE001 ES1": [
    {
        "energyConsumptionTotal": 100000,
        "energyProductionTotal": 920000,
        "energyConsumptionToday": 100000,
        "energyProductionToday": 920000,
        "SOC":0.9,
        "SOH": 0.95,
        "temperatureMin": 23,
        "temperatureMax": 29,
        "power":50000,
        "mode": 2
      }
  ],
  "EE001 ES1 BC1": [
    {
        "SOC":0.9,
        "SOH": 0.965,
        "powerDC": -40000,
        "VoltageDC": 690,
        "CurrentDC": 70,
        "powerActive": 40000,
        "powerReactive": 0,
        "temperatureMin": 25,
        "temperatureMax": 28,
        "power": 40000,
        "mode": 2
      }
  ],
   "EE001 ES1 BC2": [
    {
         "SOC":0.9,
        "SOH": 0.936,
        "powerDC": -40000,
        "VoltageDC": 690,
        "CurrentDC": 70,
        "powerActive": -40000,
        "powerReactive": 0,
        "temperatureMin": 24,
        "temperatureMax": 27,
        "power": 40000,
        "mode": 2
      }
  ],
   "EE001 ES1 BC3": [
    {
        "SOC":0.9,
        "SOH": 0.963,
        "powerDC": -40000,
        "VoltageDC": 690,
        "CurrentDC": 70,
        "powerActive": 40000,
        "powerReactive": 0,
        "temperatureMin": 24,
        "temperatureMax": 29,
        "power": 40000,
        "mode": 2
      }
  ],
   "EE001 ES1 BC4": [
    {
        "SOC":0.9,
        "SOH": 0.946,
        "powerDC": -40000,
        "VoltageDC": 690,
        "CurrentDC": 70,
        "powerActive": 40000,
        "powerReactive": 0,
        "temperatureMin": 23,
        "temperatureMax": 28,
        "power": 40000,
        "mode": 2
      }
  ],
   "EE001 ES1 BC5": [
    {
         "SOC":0.9,
        "SOH": 0.968,
        "powerDC": -40000,
        "VoltageDC": 690,
        "CurrentDC": 70,
        "powerActive": 40000,
        "powerReactive": 0,
        "temperatureMin": 24,
        "temperatureMax": 28,
        "power": 40000,
        "mode": 2
      }
  ]
}

Dashboards