Logging Fun with UVR16x2: Photovoltaic Generator – Modbus – CAN Bus

The Data Kraken wants to grow new tentacles.

I am playing with the CMI – Control and Monitoring Interface – the logger / ‘ethernet gateway’ connected to our control units (UVR1611, UVR16x2) via CAN bus. The CMI has become a little Data Kraken itself: Inputs and outputs can be created for CAN bus and Modbus, and data from most CAN devices can also be logged via JSON.

Are these features useful to integrate the datalogger of our photovoltaics inverter – Fronius Symo 4.5-3-M? I am now logging data to an USB stick and feed the CSV files to the SQL Server Data Kraken. The USB logger’s logging interval is 5 minutes whereas Modbus TCP allows for logging every few seconds. The inverter has built-in energy management features, but it can only ‘signal’ via a relay which also requires proper wiring. Modbus TCP, on the other hand, could use the existing WLAN connection of the inverter and the control unit could do something smarter with the sensor reading of the output power.

My motivation is to test if you – as an UVR16x2 user – can re-use a logger you  already have – the CMI – as much as possible, avoiding the need to run another ‘logging server’ all the time (Also my SQL Server is for analysis, not for real-time logging). I know that there are many open source Modbus clients available and that it is easy to write a Python script.

Activate Modbus on the inverter: I prefer floating numbers to integers plus a scaling factor, and I turn off the option to make changes via Modbus:

Modbus settings, Fronius Datalogger, inverter’s local web server. 502 is the TCO standard port. The alternative to floating numbers is integers plus a varying scaling factor (SF), to be found in another register.

Check Fronius documentation of its Modbus registers: The document is currently available here. There are different sets of registers related to the inverter or associated with one string of PV panels:

PDF p.97, Common Inverter Model. For logging AC output power you need:  Address 40092, type of register 3 (read and hold), datatype float32 (‘corresponds’ to two 16bit integer register, thus size 2).

The address to be configured on a Modbus client is smaller than this address by 1 – so 40091 needs to be set to log AC power.

Using these configuration parameters an analog Modbus Input is added at the CMI. The signal is ‘digital’ – but in field-bus-language everything that is not a single bit – 0/1 – seems to be ‘analog’.

Modbus input at the CMI. Input value:  32bits read from the bus interpreted as an integer. Actual value: Integer part of the ‘true value’ = the 32bits interpreted as 32-bit float.

Yes, I checked the network trace 😉 as the byte order dropdown menu confused me: According to the Modbus protocol specification Big Endian is required, not an option.

Factors and data types: Only integer values are understood by CAN devices. Decimal places might be indicated by a scaling factor. The PV power value in Watt has enough significant digits; so the integer part of the float number is fine. But for current in Ampere – typically about 15A maximum – a Factor of 10 would be better. It would not have helped to select int + scaling factor at the inverter: The scaling factor would be stored in a second register, there is a different factor for every parameter, and you cannot configure another ‘scaling factor register’ per input at the CMI. Theoretically you could log the scaling factor separately and re-scale the value in a custom application – but then I would use a separate, custom logger.

In any case, if you screw this up, you see non-sensible numbers of the CAN bus: Slowly evolving positive values – like PV power on a sunny day – are displayed as wild variations of signed integers between -32000 and 32000 😉

Where are the ‘logged’ data? The CMI is first and foremost the data logger for the control units. The CMI does not immediately store the data from Modbus inputs in a  local ‘logging database’. All I have achieved so far is to display the value on the Settings page. The CMI can only log values from the CAN bus or DL bus. So we need an…

… Analog CAN Output at the CMI:

The CMI has the default node number 56 on the CAN bus. Other CAN devices on the bus can query it for this parameter by specifying node 56 and output no 1.

These are the devices on our CAN bus:

CAN bus displayed on the CMI’s website. UVR1611 and UVR16x2 controllers can be managed by clicking their icons – which brings up a web page that resembles the controller’s local display.

The CMI’s Logging page looks tempting – can we simply select the CMI itself as a CAN logging source – CAN 56?

Configuration of the devices the CMI logs data from, via CAN bus. CAN 1 – UVR1611, CAN 2 – UVR16x3, CAN 41 – energy meter CAN-EZ.

Nothing stops you from selecting CAN 56 in this dropdown menu, but it does not end well:

CAN error message displayed at the logger CMI when you try to configure the CMI also as a logging source.

We need a round-trip: Data needs to be sent to a supported device first – one of the controllers on the CAN bus. We need an…

… Analog CAN input / network variable at the UVR16x2:

Configuration of a CAN input at the controller UVR16x2 (via CMI’s web interface to the controller).

The value of AC power is displayed as integer without scaling. Had a factor of 10 been used at the Modbus input it would be ‘corrected’ here, using the Unit called dimensionless,1.


Values received by the controller UVR16x2 over CAN bus.

Result of all this: UVR16x2 knows PV power and can use it do magic smart things when controlling the heat pump. On the other hand, CMI can log this value – in the same way it logs all other sensor readings.

Log files are retrieved by Winsol, the free logging software for the CMI …

Logged visualized with Winsol. Logfiles are downloaded from the CMI on the internal LAN or via Technsche Alternative’s web portal. PV power (PV.Leistung.Watt) is displayed together with global radiation on a vertical plane (GBS, at the solar/air collector for the theat pump), ambient temperature (red), temperature of solar/air collector (orange)

… or logging is configured at the web portal cmi.ta.co.at …

Configuration of logging at cmi.ta.co.at: Supported loggers are UVR1611 and UVR16x2. Values to be logged are selected from all direct inputs / outputs / functions and from CAN network inputs and outputs.

… and data can be viewed online:

Data visualized at cmi.ta.co.at. Data logged via CAN are sent from the CMI to the web portal.

Using this kind of logging for all values the inverter provides would be costly: It’s not just a column you add to a log file, but you occupy one of the limited inputs and outputs at the CMI and the controller. If you really need to know the voltage between phase 1 and 2 or apparent power you better stick with the USB file or use a separate Modbus logger like a Rasbperry Pi. This project is great and documented very well – data acqusition from a Symo inverter using Python plus a web front end.

Sending Modbus data back and forth from the CMI to UVR controllers is only worth the efforts if you need them for control, not for ‘nice-to-have’ logging.

Half a Year of Solar Power and Smart Metering

Our PV generator and new metering setup is now operational for half a year; this is my next wall of figures. For the first time I am combining data from all our loggers (PV inverter, smart meter for consumption, and heat pump system’s monitoring), and I give a summary on our scrutinizing the building’s electrical power base load.

For comparison: These are data for Eastern Austria (in sunny Burgenland). Our PV generator has 4.77kWp, 10 panels oriented south-east and 8 south-west. Typical yearly energy production in our place, about 48° latitude: ~ 5.300 kWh. In the first 6 months – May to November 2015 – we harvested about 4.000kWh.
Our house (private home and office) meets the statistical average of an Austrian private home, that is about 3.500 kWh/year for appliances (excl. heating, and cooling is negligible here). We heat with a heat pump and need about 7.200kWh electrical energy per year in total.

In the following plots daily and monthly energy balances are presented in three ways:

  1. Total consumption of the building as the sum of the PV energy used immediately, and the energy from the utility.
  2. The same total consumption as the sum of the heat pump compressor’s input energy and the remaining energy for appliances, computers, control etc.
  3. Total energy generated by PV panels as the sum of energy used (same amount as contributing to 1) and the energy sold to the utility.

Monthly energy balances: PV generation and consumption, May-Nov 2015

Monthly electrical energy consumption - heat pump and appliances, May-Nov 2015

In summer there is more PV  energy available than needed and – even with a battery – the rest would needed to be fed into the grid. In October, heating season starts and more energy is needed by the heat pump that can be provided by solar energy.

This is maybe demonstrated best by comparing the self-sufficiency quota (ratio of PV energy and energy consumed) and the self-consumption quota (ratio of PV energy consumed and PV production). Number ‘flip’ in October:


In November we had some unusually hot record-breaking days while the weather became more typical at the end of the month:


This is reflected in energy consumption: November 10 was nearly like a summer day, when the heat pump only had to heat hot water, but on the colder day it needed about 20kWh (resulting in 80-100kWh heating energy).

Daily energy balances: PV generation and consumption, Nov 2015

Daily electrical energy consumption - heat pump and appliances, Nov 2015

In July, we had the chance to measure what the building without life-forms needs per day – the absolute minimum baseline. On July 10, 11, and 12 we were away and about 4kWh were consumed per day160W on average.

Daily energy balances: PV generation and consumption, July 2015

Note that the 4kWh baseline is 2-3 times the energy the heat pump’s compressor needs for hot water heating every day:

Daily electrical energy consumption - heat pump and appliances, July 2015

We catalogued all devices, googled for data sheets and measured power consumption, flipped a lot of switches, and watched the smart meter tracking the current consumption of each device.


Consumption minus production: Current values when I started to write this post, the sun was about to set. In order to measure the consumption of individual devices they have been switched an of off one after the other, after sunset.

We abandoned some gadgets and re-considered usage. But in this post I want to focus on the base load only – on all devices that contribute to the 160W baseline.

As we know from quantum physics, the observing changes the result of the measurement. It was not a surprise that the devices used for measuring, monitoring and metering plus required IT infrastructure make up the main part of the base load.

Control & IT base load – 79W

  • Network infrastructure, telephone, and data loggers – 35W: Internet provider’s DSL modem / router, our router + WLAN access point, switch, ISDN phone network termination, data loggers / ethernet gateways for our control unit, Uninterruptible Power Supply (UPS).
  • Control and monitoring unit for the heat pump system, controlling various valves and pumps: 12W.
  • The heat pump’s internal control: 10W
  • Three different power meters: 22W: 1) Siemens smart meter of the utility, 2) our own smart meter with data logger and WLAN, 3) dumb meter for overall electrical input energy of the heat pump (compressor plus auxiliary energy). The latter needs 8W despite its dumbness.

Other household base load – 39W

Electrical toothbrush, at least no bluetooth.

  • Unobtrusive small gadgets – 12W: Electrical toothbrush, motion detectors, door bell, water softener, that obnoxious clock at the stove which is always wrong and can’t be turned off either, standby energy of microwave oven and of the PV generator’s inverter.
  • Refrigerator – 27W: 0,65 kWh per day.

Non-essential IT networking infrastructure – 10W

  • WLAN access point and router for the base floor – for connecting the PV inverter and the smart meter and providing WLAN to all rooms.

These are not required 24/7; you don’t lose data by turning them off. Remembering to turn off daily might be a challenge:

Boldly going where no one has gone before!

Non-24/7 office devices – 21W. Now turned off with a flip switch every evening, and only turned on when needed.

  • Phones and headsets: 9W.
  • Scanner/Printer/Fax: 8W. Surprisingly, there was no difference between ‘standby’ and ‘turned off’ using the soft button – it always needs 8W unless you really disconnect it.
  • Server in hibernated state 4W. Note that it took a small hack of the operating system already to hibernate the server operating system at all. Years ago the server was on 24/7 and its energy consumption amounted to 500kWh a year.

Stuff retired after this ‘project’ – 16W.

  • Radio alarm clock – 5W. Most useless consumption of energy ever. But this post is not meant as bragging about the smartest use of energy ever, but about providing a realistic account backed up by data.
  • Test and backup devices – 7W. Backup notebooks, charging all the time, backup router for playground subnet not really required 24/7, timer switch most likely needing more energy than it saved by switching something else.
  • Second old Uninterruptable Power Supply – 4W. used for one connected device only, in addition to the main one. It was purchased in the last century when peculiarities of the local power grid had rebooted  computers every day at 4:00 PM.

Historical UPS from last century

In total, we were able to reduce the base load by about 40W, 25% of the original value. This does not sound much – it is equivalent to a small light bulb. But on the other hand, it amounts to 350kWh / year, that is 10% of the yearly energy consumption!


Logging setup:

  • Temperature / compressor’s electrical power: Universal control UVR1611 and C.M.I. as data logger, logging interval 90 seconds. Temperature sensor: PT1000. Power meter:  CAN Energy Meter. Log files are exported daily to CSV files using Winsol. Logging interval: 90 seconds.
  • PV output power: Datamanager 2.0 included with PV inverter Fronius Symo 4.5-3-M, logging interval 5 minutes.
  • Consumed energy: Smart meter EM-210, logging interval 15 minutes.
  • CSV log files are imported into Microsoft SQL Server 2014 for analysis and consolidation. Plots are created with Microsoft Excel as front end to SQL Server, from daily and monthly views on joined UVR1611 / Fronius Symo / EM-210 tables.

The Impact of Ambient Temperature on the Output Power of Solar Panels

I have noticed the impact of traversing clouds on solar power output: Immediately after a cloud has passed, power surges to a record value. This can be attributed to the focusing effect of the surrounding clouds and/or cooling of the panels. Comparing data for cloudless days in May and June, I noticed a degradation of power – most likely due to higher ambient temperatures in June.

We had a record-breaking summer here; so I wondered if I could prove this effect, using data taken at extremely hot days. There is no sensor on the roof to measure temperature and radiation directly at the panels, but we take data taken every 90 seconds for:

  • Ambient air temperature
  • Global radiation on a vertical plane, at the position of the solar thermal collector used with the heat pump system.

I was looking for the following:

  • Two (nearly) cloudless days, in order to rule out the impact of shadowing at different times of the days.
  • These days should not be separated by too many other days, to rule out the effect of the changing daily path of the sun.
  • Ideally, air temperature should be very different on these days but global radiation should be the the same.

I found such days: August 1 and August 12 2015:

Daily PV ouput energies and ambient temperatures in August 2015

Daily output of the photovoltaics generator (4,77 kW peak), compared to average and maximum air temperatures and to the global radiation on a vertical plane. Dotted vertical lines indicate three days nearly without clouds.

August 12 was  a record-breaking day with a maximum temperature of 39,5°C. August 1 was one of the ‘cool’ but still perfectly sunny days in August. The ‘cold day’ resulted in a much higher PV output, despite similar input in terms of radiation. For cross-checking I have also included August 30: Still fairly hot, but showing a rather high PV output, at a slightly higher input energy.

August 2015 in detail:

Daily PV ouput energies and ambient temperatures in August 2015 - details

Same data as previous plot, zoomed in on August. Dotted lines indicate the days compared in more detail.

Overlaying the detailed curves for temperature and power output over time for the three interesting days:

PV power and ambient temperature over time

Detailed logging of ambient air temperature and output power of the photovoltaic generator on three nearly cloudless days in August 2015.

The three curves are stacked ‘in reverse order’:

The higher the ambient air temperature, the lower the output power.

Note that the effect of temperature can more than compensate for the actually higher radiation for the middle curve (August 30).

I have used global radiation on a vertical plane as an indicator of radiation, not claiming that it is related to the radiation that would be measured on the roof – or on a horizontal plane, as it is usually done – in a simple way. We measure radiation at the position of our ribbed pipe collector that serves as a heat source for the heat pump; it is oriented vertically so that it resembles the orientation of that collector and allows us for using these data as input for our simulations of the performance of the heat pump system.

Our house casts a shadow on the solar collector and this sensor on the afternoon; therefore data show a cut-off in the afternoon:

Global radiation on solar collector, vertical plane, August 2015

Global radiation in W per square meter on a vertical plane, measured at the position of the solar collector. The collector is installed on the ground, fence-like, behind the house, about north-east of it.

Yet, if you compare two cloudless days where the sun traversed about the same path (thus days close in the calendar) you can conclude that solar radiation everywhere – including the position on the roof – was the same if these oddly shaped curves are alike.

This plot shows that the curves for these two days that differed a lot in output and temperature, August 1 and 12, were really similar. Actually, the cooler day with higher PV output, August 1, even showed the lower solar radiation due to some spikes. Since the PV inverter only logs every 5 minutes whereas our system’s monitoring logs every 1,5 minutes those spikes might have been averaged out in the PV power curves. August 30 clearly showed higher radiation which can account for the higher output energy. But – as shown above – the higher solar power could not compensate for the higher ambient temperature.


Logging setup: