Wednesday 18 May 2022

Sungrow SG5K-D and HomeAssistant

In December 2021 we decided to install Solar Panels on our house (thanks to Quest Energy in Perth for doing a great job), choosing JA Solar Solar Panels and a Sungrow SG5K-D inverter. Unfortunately there isn't an official Sungrow Inverter integration for HomeAssistant, but it is possible to feed solar data to HomeAssistant by sticking together a few components.

A high-level diagram showing components and data flows is given below:

 
1: SolarIoT connects periodically to Sungrow Inverter using ModBus over TCP and periodically reads the inverter's read registers and holding registers.
2: SolarIoT sends data to pvoutput.org.
3: SolarIoT sends data to a local MQTT broker on a specified topic.
4: HomeAssistant MQTT integration subscribes to the specified topic and makes the Solar Inverter data available via HomeAssistant Sensors.

This setup lets me use HomeAssistant to track my Solar production and energy consumption over the day:

Details of how to configure all the components are below:

Sungrow Inverter

I have a SG5K-D with a wifi module that sends data to iSolarCloud (and Solar Analytics) periodically. It's also possible to connect in to the wifi module and pull down data using ModBus over TCP.

SolarIoT

SolarIoT connects to a ModBus capable inverter and reads registers and then sends the data to other systems. This works well for me as I want to send my inverter data to pvoutput.org, but also want to publish the data to other local systems that will use the solar inverter data. To do the latter I've configured my instance of SolarIoT to publish the data to a local MQTT broker.

I had problems with SolarIoT with my Sungrow SG5K-D where connections would succeed most of the time, but once in a while the inverter would stop responding to ModBus handshakes. I found that I could work around this by doing a TCP connect to the inverter on the ModBus power, waiting a couple of seconds and then disconnecting and I would need to do this whenever the inverter ModBus comms went into a stuck state. I've forked the SolarIoT source here and added a feature to automate the resetting dummy connection when SolarIoT has issues communicating with the inverter (add --sungrow-reset to the command line options to use it).

I also expanded the ModBus map for the SG5K-D so it includes the "daily export energy" register which is needed for HomeAssistant's energy dashboard.

There's also a fix for pvoutput.org with the SG5K-D: the "power meter" value for the SG5K-D measures house power consumption, not the self-consumption of PV energy so this value must not be sent otherwise the data in pvoutput.org will be incorrect.

I'm running SolarIoT on one of my Linux VMs. I'll deploy it into a container eventually, I haven't gotten around to setting it up yet :)

MQTT Broker

I run a MQTT broker (Mosquitto) to manage publishing and subscribing data from various IoT sensors (e.g. Sungrow inverter, Xiaomi / Aqara Zigbee sensors, TP Link Kasa smart switches with power monitoring, OpenSprinkler and a custom battery voltage sensor I built for my powered home sliding gate). SolarIoT publishes payloads to a topic "inverter/stats".

HomeAssistant

HomeAssistant has an MQTT integration but in this case manual configuration in the config files are needed because we need to specify the device class, state class and unit of measurement fields so the energy dashboard can use the sensors. My configuration for this is below (from sensors.yaml): 
- platform: mqtt
  state_topic: "inverter/stats"
  name: "Inverter - Daily Power Yield"
  value_template: '{{ value_json["daily_power_yield"] }}'
  unit_of_measurement: Wh
  device_class: energy
  state_class: total_increasing

- platform: mqtt
  state_topic: "inverter/stats"
  name: "Inverter - Daily Export Energy"
  value_template: '{{ value_json["daily_export_energy"] }}'
  unit_of_measurement: kWh
  device_class: energy
  state_class: total_increasing

- platform: mqtt
  state_topic: "inverter/stats"
  name: "Inverter - Daily Purchased Energy"
  value_template: '{{ value_json["daily_purchased_energy"] }}'
  unit_of_measurement: kWh
  device_class: energy
  state_class: total_increasing

Just a reminder that my configuration.yaml has the following in it to read sensor config from sensors.yaml:
# manually configured sensors
sensor: !include sensors.yaml

And you also need to make sure the recorder integration has been set up to save sensor data, for example mine is below:
recorder:
  purge_keep_days: 28
  db_url: !secret URL_MariaDB

Nb. I don't have any sensors listed in my recorder section as I'm using the implicit behaviour to record all sensors.

Once the MQTT sensors have been configured and their entities are showing values from the inverter, the Energy dashboard can be set up with the MQTT sensors that we set up previously:

Once this is all set up, you'll be able to use HomeAssistant's energy dashboard (it will look like this once it has collected enough data to show a whole day's energy production and consumption):








AirRohr particulate matter sensor build

Recently I put together an AirRohr particulate matter sensor to see what the PM10 and PM2.5 levels were outside my house. I ordered a SDS011 fine dust sensor and BME280 from Aliexpress, reused an old NodeMCU v1 ESP8266 module and put together the pipe enclosure using 75mm PVC pipe fittings from Bunnings. The modules are powered using a LM2596HV AC to DC Buck Converter, set to output 5V with an input source of 12V AC from a garden lighting transformer.

Firmware

As I was using an old NodeMCU v1 ESP8266 module (I have a few of these lying around and didn't want to order another v2 or v3 module), I couldn't use the pre-built firmware available from the sensor.community website, so I cloned the git repo and tried flashing the firmware using the Arduino IDE. For some reason I ran into problems with the SSD1306 library and as I wasn't using an OLED display I ended up just wrapping all the code that interfaced with the SSD1306 with #ifdef ... #endif directives referencing an undefined token (effectively the same as commenting the code out). This let me build the code and flash it to my NodeMCU v1 module.

Thanks to the Open Data Stuttgart initiative for making the source and sensor design available!

Hardware

Here in Australia the 75mm PVC pipe fittings are different to what's available in Germany so I ended up using:

  • 2x 75mm 90 degree female to female elbows
  • 2x 75mm PVC couplings (used to fit flyscreen to stop bugs getting in, see later)
  • 2x 80mm PVC clips (holds 75mm pipe as it has some give in the design)
  • 1m 75mm PVC pipe (which needed to be cut into a few pieces)
  • Some leftover flyscreen

The pipes are mounted on our outdoor patio in an inconspicuous spot which has good airflow away from the house:

I used the PVC couplings as endcaps with flyscreen in them to keep bugs out. Cutting a thin (couple of mm - test out your hacksaw skills!) piece of PVC pipe and bending the circle in at one point, this makes an easy flyscreen holder that can be easily wedged into the coupling. From the back it looks like this:
 
 
From the front it looks nice and tidy:
 
The small triangle void formed from pushing the thin PVC piece in gives a nice route to run the power cable into the pipe pieces. I've also wedged a piece of flyscreen foldered into a cone to block off the rest of the hole bounded by the triangle void.

Software

I noticed that the sensor outputs data in JSON format at http://sensor/data.json, so thought I could use this output and write an integration for HomeAssistant to read the sensor data locally. Luckily in searching I found that someone had already written this (https://github.com/lichtteil/local_luftdaten, thanks!) and it was available through HACS so I've added the integration and configured it by adding a sensor to my yaml configuration:

In configuration.yaml I have this section to reference another file for sensors:
# manually configured sensors
sensor: !include sensors.yaml

And in sensors.yaml I have the following config for local_luftdaten (IP address and name redacted):
# luftdaten sensor
- platform: local_luftdaten
  host: 192.168.20.XXX
  scan_interval: 180
  name: airrohr-nnnnnnnn
  monitored_conditions:
    - SDS_P1
    - SDS_P2
    - BME280_temperature
    - BME280_humidity
    - BME280_pressure

This lets me set up a couple of cards to show the sensor values and their trend over the last 24 hours:


It's been interesting to watch the PM2.5 and PM10 values shoot up during the controlled burns we've had in Perth recently while hiding inside away from the smoke :)