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:

Check Fronius documentation of its Modbus registers: The document is currently available here (Link last checked and updated 2019-01). There are different sets of registers related to the inverter or associated with one string of PV panels:

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’.

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:

These are the devices on our CAN bus:

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

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

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:

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.

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 (after an update of the logging settings in the controller’s functional data, using TAPPS).
Log files are retrieved by Winsol, the free logging software for the CMI …

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

… and data can be viewed online:

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.
CAN bus? Photo voltaic? Elkement is switching gears! Have fun, control technology can be addictive.
Thanks, but I am not shifting gears :-)
I have been playing with CAN bus since a while – this is the control unit we have been using for the heat pump system since the beginning. Our heat pump uses another CAN bus protocol internally, documented in the ‘Hacking my Heat Pump’ series :-) https://elkement.wordpress.com/2016/08/03/hacking-my-heat-pump-part-1-can-bus-testing-with-uvr1611/
PV is up and running since three years – I have been testing different loggers and meters since then: https://elkement.wordpress.com/2015/12/07/half-a-year-of-solar-power-and-smart-metering/
Still, for me you are now officially a CAN hacker in addition to being a pro heat pump hacker!