Go Back
Image for post: My Energy Optimization with IoT-Ticket 3/3

My Energy Optimization with IoT-Ticket 3/3

This is a blog series about optimizing my energy consumption with IoT-TICKET®. Basically I am controlling the energy load of my house as optimal as possible taking electricity price, own solar energy production and weather conditions into consideration. In this blog post I will describe the technical part and tell how it was implemented. See my previous posts about functionalities from here.

The overall architecture of the system is illustrated in the figure below. Basically IoT-Ticket -the Internet of Things platform and WRM247+ IoT gateway is used to implement the system.

Overall architecture Figure 1. Overall architecture of the system

Data acquisition

Active components Figure 2. Active components in a system

All sensors (e.g. 1-wire temperature not shown in the figure above) and active components are connected at home using WRM247+ terminal which is one of the data acquisition gateway alternatives in IoT-Ticket platform. Active components are connected using Ethernet (Modbus/TCP) or serial (Modbus/RTU). All configuration is done in web browser with IoT-Ticket enterprise manager, for example below is a data tag located in the ABB A43 kWh meter Modbus/RTU register:

Configuration Figure 3. Modbus/RTU register configuration

After the data tags have been defined (example below) they can be utilized in IoT-Ticket platform.

Data tags Figure 4. Example (power) data tags from the house

Solar power (PV inverter)

SMA Tripower 5000-tl is a PV inverter which converts DC power from the solar panel to AC 3 phase 230V power. From the inverter we are mainly interested in producing power, but the inverter can also provide detailed diagnostic information for the geeks. SMA inverters has SunSpec register format which is very well defined and SMA has its own FAQ section for Modbus developers as well.

Electric vehicle (EV) charging

Basically any IEC 61851-1 Mode 3 charger could be utilized if such a device could be externally connected. There are many in the market, but I am not satisfied with their prices, therefore I built my own using Phoenix Contact EM-CP-PP-ETH EV Charge Control and EV-RCM-C1-AC30-DC6 Differential current monitoring for monitoring DC residual currents. DC residual current monitoring is for additional safety because DC fault current might blind RCD type A to trigger. Such DC fault current source in EV charging setup might be isolation fault in Power Factor Correction device (PFC – used to meet EMC requirements) in a car.

Charge station is very simple, much like any other electric device in a house or building. It requires a professional electrician and that electrical safety regulations are fulfilled. Next figure is a connection diagram for my charging station and it is taken directly from the Phoenix Contact application examples.

Application example

Figure 5. Application example from Phoenix Contact

Electric vehicle charging cable in this case is Type 2 connector which has N, PE, L1, L2, L3 and:

  • Proximity pilot (PP): pre-insertion signaling, this is just resistance between PP and PE telling that the plug has been connected and it's also defining the maximum current of the cable.
  • Control pilot (CP): post-insertion signaling is PWM signal between the charge controller and the car. With this signaling the charge stations gives the maximum charge current and the car says when it is ready for charge or if the charging needs to be stopped. Basic principle here is that the charging plug cannot be disconnected (it is locked in car) when a charging is active.

From the charge controller I have the following data tags connected via Modbus/TCP:

Car charging data tags

Figure 6. Car charging controller data tags

I am using “EV status” in a dashboard to visualize charging status. IoT-Ticket flow is used to control “Set charging current” as well as “Enable Charging process”. The algorithm is pretty simple:

If energy production to grid is (20 minute average, excluding car charge power):

  • > 1500 W -> start charging 6 A / 2.7 kW
  • > 4000 W -> start charging 10 A / 4.4 kW
  • > 5000 W -> start charging 13 A / 5.7 kW
  • < 1500 W -> stop charging

For example, look how this algorithm is implemented in the IoT-Ticket flow:

Charging algorithm

Figure 7. Charging algorithm

The Dashboard (user interface) is simple, it just contains information about charging status and a Manual checkbox which I turn on when I want to charge my car without intelligence and with full power immediately. In IoT-Ticket one can create mobile layouts for dashboards, here I have done an UI as simple as possible because in practice no more is needed.

Mobile UI

Figure 8. Mobile UI for EV charging

Floor/water heating

Controlling of house energy load including floor heating and water heating is implemented using ADAM 4068 Modbus/RTU relay. This relay controls contactors already existing in the electrical center. As a backup there is a manual bypass switch because this implementation is relative beta and I am currently developing it.

External sources

Nordspool stock prices are read with python script found from here and written to IoT-Ticket database using IoT-Ticket REST API using IoT-Ticket Python Library. For weather data same logic is used, python script reads the weather forecast from here and writes values to IoT-Ticket REST API. Because IoT-Ticket flow programming language has REST block which would be easier to use, I am considering to use some REST based weather forecast data source for example Darsky or Open weather map.


IoT-Ticket IoT WRM247+ energy optimization solar power hybrid car

Author

Teemu Niemi

Segment Manager (Industrial)

Image of post author Teemu Niemi

Let's Get Started