Solar PV

This page contains our notes about our proposed solar PV installation.

“A little knowledge is a dangerous thing”, so the saying goes. I am no expert on these matters, just technically savvy and curious to learn and understand it all. I’m hot on electrics, physics, geometry, calculation; but weak on the practicalities in this industry. That’s why we’re approaching installers for their expertise in design and installation. Not everything here may be correct or make sense.

I am learning as I go along, starting in November 2022.

Contents:

  1. Outstanding Concerns, Requests, Questions
  2. Our Household Energy Usage
  3. Our own roof measurements
  4. Our own system planning exploration
  5. Panel Layouts Suggested by Installers
  6. Inverter
  7. Panels
  8. Shading
  9. Battery
  10. Installation requests
  11. Control and Monitoring

Removed from scope:

  1. Air Source Heat Pump (ASHP) System [removed from scope]
  2. Other household energy system changes

Outstanding Concerns, Requests, Questions

Solar PV:

  • Advice: Should we maximise system size and generation, at the cost of complexity (multiple orientations, shading, MPPT inputs)?
  • Advice: Our roof has an awkward L-shaped valley, dividing it into ​four or five small usable areas. Some areas suffer shading from the roof valley shape. Unsure of the impacts (shading factor, panel-level optimisers, multiple MPPT inputs).

Inverter:

  • To best integrate with on-site home automation, select Fronius, and in particular Fronius GEN24 Plus. (Open question on OpenEnergyMonitor community: Should we choose a Fronius inverter for best cloud-free PV monitoring interfaces?)
  • Fronius Inverter: can we add the “full backup” option at small extra cost? (Because, “why not?”)
  • Inverter sizing: stick to 3.6 kW for certification simplicity, or go bigger for better yield?

Battery:

  • Battery sizing: what is optimum battery size for us? (Can we see the calculations?)
  • Compatibility: Fronius says only BYD and one other battery are compatible, but these are expensive; a local installer told us that “LG Chem” is also compatible, and much cheaper. What’s the case, what are the nuances?

General

  • Question: who underwrites the long guarantees (10 years to 25 years), given that many companies go out of business in this time frame? (I’m told SunSynk said they have an arrangement for their guarantee to be covered by another party in that case.)

Our Household Energy Usage

Expected energy usage, per year:

Electricity: ~5,000 kWh
Gas: ~16,000 kWh

Energy usage history: see Our Energy Consumption

Our own roof measurements

  • 4 or 5 potentially useful roof surfaces (see diagrams below)
  • 2 larger roofs facing roughly south:
    • roof pitch: 45°
    • roof azimuth: 20° east of south / compass bearing 160° / -20° from south
    • roof height: 3.0 m gutter-to-ridge
  • 2 smaller roofs facing roughly east:
    • roof pitch: 45°
    • roof azimuth: 20° north of east / compass bearing 070° / -110° from south
    • roof height: 3.0 m gutter-to-ridge
  • 1 smaller roof facing roughly west:
    • roof pitch: 45°
    • roof azimuth: 20° south of west / compass bearing 250° / +70° from south
    • roof height: 3.0 m gutter-to-ridge

(roof section heights, all cases: counted 27~30 tile rows; best estimation is 3.0 m gutter-to-ridge)

Our own system planning exploration

Reminder: I’m new to this. This is experimental. These plans are ideas for discussion, not final.

We have no preference for make/model/type/colour of panels.

Planning attempts:

  • Easy PV Project Report – Julian’s version 1
  • This version of our plan shows a 6 kW inverter where 5 kW is probably enough; likewise other details may be inappropriate.
  • No shading is defined for any panels in this version. Two roofs are behind a valley: the lower those panels reach, the more shading they have.
  • This layout pattern uses panels of the most elongated shape I could find (1855 x 1029 mm), in landscape orientation, just to illustrate one of the extremes of shape and layout that might fit. More common panel sizes are ~1100×1700 mm.

Looks like 16 panels may be too much of a squeeze.

  • This version of our plan uses panels of more common shape and a more conservative fit in the available space.
  • 12 panels shown: 4 and 3 on SSE roofs, 3 and 2 on ENE roofs

We’re also looking to add more (2) panels on the west-facing roof space.

Panel Layouts Suggested by Installers

Inverter

Aims:

  • Home automation connection, locally: the power monitoring should be independent of anyone’s “cloud” service. Including any “apps”, and any available control functions.
  • Backup capability? Ability to run the house from battery and/or solar power alone, when the grid has a power cut.

Backup capability:

  • See for example https://www.spiritenergy.co.uk/kb-solar-panel-backup (compares DC-Coupled (SolaX) and AC-Coupled (Tesla Powerwall 2))
  • Ability to operate in “island mode” always requires a G98/G99 certificate (and not G99 fast track applications)
  • Manual or automatic switch-over? Automatic is obviously nice, but not too important.
  • Whole house or split? Probably whole house: we can add a smart switch per device if desired, any time later, easily for appliances up to 13A. Perhaps split and don’t back up any too-high-power circuits such as electric shower; alternatively we can just avoid using it.

Tech specs relevant to solar inverters:

  • Communication protocol: (standard) SunSpec Modbus protocol IEEE-1547 (explanation), (optional) manufacturer’s other open protocol such as Fronius API (JSON).
  • Communication physical connection: any of Ethernet, WiFi, Zigbee, perhaps other.

Research:

  • Fronius seem to be the only inverter manufacturer that makes known a serious commitment to local API with open protocols: Fronius Solar API info.
  • Home Assistant (preferred open home automation system) has good integration for Fronius inverters.
  • SolarEdge looks like the second best make in this regard: local connection available through hard-wired ethernet (previously also wifi but that no longer enabled in recent versions).
  • Home Assistant has some integration for local connection to SolarEdge and a few others; but neither SolarEdge nor others seem to promote or prioritise this from their end.

Choice:

  • Fronius Primo GEN24 Plus (3 to 6 kW) (page for installers | page for home owners)
  • sizing: 3.6 kW (~2% loss), 4.0 kW (~1% loss), 4.6 kW (~0% loss) (assuming system 5 kWp)
  • with “full backup” add-on, because “why not?”: small additional cost for grid outage backup.

Some suppliers of Fronius Primo GEN24 Plus (just from a general DuckDuckGo search):

Assigning strings of panels to Inverter MPPT Inputs

A principle often repeated is each group of panels facing a different direction, or with different shading, should go to a separate inverter input. Maximum power will not be achieved otherwise. However, the power loss from ignoring this principle might be small.

There are 4 main roof areas, two roughly south facing (-20° from south), two roughly east facing (-110° from south), plus potentially one small roughly west facing area (+70° from south). Two roof areas are at the back of a roof valley and so have some shading at times of low sun elevation.

Some inverters have 1 MPPT input, some have 2 MPPT inputs (including Fronius Primo GEN24 Plus).

How many separate MPPT inputs do we need to connect, in order to capture a reasonable fraction of maximum available power?

Panels

Aim: maximise capacity, for the sake of future use and economy of scale.

Requirements:

  • No particular requirements on size, make, style, colour.

Research:

  • See my plan (shown above) made on Easy-PV
  • Consider whether 16 panels can fit.
  • Consider panels of more elongated shape (~1850 x 1050 mm) instead of the more common shape (~1700 x 1100 mm) if that helps.
  • Considered triangular panels: they seem to be expensive and hard to obtain (few suppliers).
  • Lichen growth, especially on non-south-facing panels. Are some panel types more resistant than others? Concern because ours are quite high and difficult for cleaners to reach.

Shading

I estimated our shading factors, with assistance from easy-pv.

  • rear south-facing roof: around 0.6 to 0.75
  • rear east-facing roof: Around 0.8 to 0.9

Panel Level Optimisation (PLO) or Module Level Power Electronics (MLPE):

One line of wisdom says we need PLO/MLPE: either a micro-inverter or a DC conditioning unit on each panel.

Another line seems to show this doesn’t in fact help, when compared with a good PPT string inverter.

Battery

  • Battery sizing. Still TBC whether we install PV + ASHP together or PV first and ASHP later. Consider probably sizing for PV + ASHP. (Is that the conditions where a smaller battery is appropriate?)
  • Battery (system) type: what’s compatible with Fronius inverters? See Fronius Compatible Batteries — looks like it requires BYD Battery-Box Premium HVS/HVM

Installation requests

  • Battery and inverter in under-stair cupboard next to existing electric supply consumer unit.

Control and Monitoring

Open source home automation system:

Solar PV monitoring:

Heat pump monitoring:

Running an OpenWrt Router

I am running an OpenWrt open-source router, at last.

OpenWrt: Wireless Freedom

Dave kindly donated me the hardware three years ago, when I spent many happy and frustrating hours installing OpenWrt for the first time, bricking it, recovering by connecting a serial port inside it, and eventually finding the OpenWrt configuration interfaces at that time were just too complicated for me to navigate.

It sat on my desk ever since then, unused.

What changed?

The old noddy little router

This week, our noddy little ISP-provided router keeled over.

All I did was try to change its upstream DNS server addresses to point to AdGuard’s ad blocking service. There was a simple web UI to enter the addresses, but, after doing so, its web UI promptly and permanently died and would not come back. Its DNS gateway function and SSH access died too, while some functions such as its basic routing and port forwarding continued. I tried power-cycling the router, of course, but avoided doing a factory reset because then I would lose my port forwarding that provides access to my self-hosted services such as Matrix and contacts and calendar, and would not be sure I could reconfigure everything. I was able to regain internet access temporarily, by manually configuring each of our devices to use external DNS server addresses instead of the router’s local address.

Well, I didn’t like that router anyway. Its UI was slow and awkward, its features were very bare and its WiFi was weak. (It was a Sagemcom 2704N, also branded PlusNet and Technicolor.)

So it was that I took a second look at this TP-LINK TD-W8970 router.

A pleasant surprise awaited: I found that OpenWrt had just the previous week released a major update, a 2021 version, a year and a half since their previous 2019 version, and it looks much more polished. A quick in-place firmware upgrade, followed by many hours figuring out how to make and manage the configuration, resetting, starting again from defaults, and it’s now all working. ADSL WAN connection, wired, wireless, and my port forwarding rules for my servers, and some bits of static DHCP and static DNS hostname entries.

Where the previous router had hung lopsided from one screw, to make a better impression and improve its chances of acceptance by the family I screwed it neatly to the wall and tidied the wires.

The Ordinary User May Appreciate…

TP-LINK TD-W8970 v1
  • ad-blocking
  • stronger WiFi signal now covering the whole house and garden
  • faster

None of these benefits seen by the ordinary user are unique to OpenWrt, of course.

Ad blocking was the trigger for this whole exercise. I had previously been considering self-hosting either Pi-Hole or Adguard-Home. Recently I learned that AdGuard DNS service is currently available free of charge, simply by setting it as the router’s DNS server address (or, less conveniently, by overriding the setting in individual devices). While less comprehensive and customisable than a self-hosted ad-blocking DNS server, for the time being the convenience and simplicity of this solution wins.

The new router is faster in a few ways: faster WiFi connection speeds; faster access to self-hosted services such as backups enabled by gigabit ethernet (up from 100 Mbit) for the wired connection; and (probably) some faster software operations such as DNS where the previous router often seemed responsible for delays of several seconds.

The Self-Hoster Appreciates…

Configuration Example

Where OpenWrt shines is in the features I use for self-hosting services, and how I will be able to manage it over time.

Because it’s open-source software:

  • reassurance that the software cannot be abandoned at the whim of some company;
  • strong support for open and standard and modern protocols, e.g. mesh WiFi, encrypted DNS standards, standard Unix admin tools;
  • likely to be upgraded to add new features, support new security measures;
  • I can keep my configuration if I need to buy new or different hardware, because the same software runs on many devices;
  • many optional add-on features contributed by community members;

Because it’s software for professionals:

  • full IPv6 support, alongside IPv4;
  • strong WiFi features, e.g. multiple networks (trusted vs. guest);
  • strong network protocols support, e.g. tagged VLANs, switch control protocols;
  • configuration stored as text, so can be managed by external tools like Ansible and version control, and re-configured from scratch by one automated script (“configuration as code”, “infrastructure as code”);

Things That Went Wrong

Bricking the device during initial installation

Part of the OpenWrt TD-W8970 installation instructions, which are in a linked forum post, advised me to use commands like “cat openwrt.image > /dev/mtdblock1” to install OpenWrt initially. What appears to have gone wrong is this did not successfully write all of the image file to the flash memory. Some blocks of flash remained blank. Then when rebooting the router, it just hung. I got in touch and was advised there are more reliable ways to do it. To recover, I had to buy a serial port to USB adapter, open up the router and solder on a serial header, and use the serial port recovery method.

Some web sites would not load

At first, a few ordinary web sites failed to load.

According to a note near the end of the user guide “Dnsmasq DHCP server” page:

“If you use Adguard DNS … you need to disable [DNS] Rebind protection… If not, you can see lot of this log in system.log, and have lag or host unreachable issue.”

"daemon.warn dnsmasq[xxx]: possible DNS-rebind attack detected: any.adserver.dns"

I have read a lot more about this issue since then, to understand it better. I changed the setting, as suggested, and everything seems to work OK now.

I wish this issue would be explained more clearly, and with references. I am still not entirely comfortable that disabling the rebind protection is the best that could be done: it seems to me it would be better if we could accept just the “0.0.0.0” responses that this DNS sends while still protecting against any other local addresses.

WiFi Would Not Connect

After a while I decided to change the WiFi channel selection from 11 to Auto. Next day, our devices would not connect. Some of them would briefly attempt to connect and immediately disconnect, while others would not even show our WiFi network in their list.

It turned out the router had switched to channel 13. From what I have been able to learn, this is a valid channel to choose, although in the USA there are restrictions on the power level on channels 12 and 13. A lot of writers strongly advise only choosing among 1, 6, and 11. The rationale for this advice seems to originate from one particular study that may not be relevant in today’s common scenarios; some writers disagree and it’s not really clear. I wonder if the problem is that the firmware in many devices may not “like” connecting to channels above 11.

Whatever the precise cause, switching back to manually selected channel 11 seems to have solved the problem.

Struggles

It was far from a breeze to install, and far from a breeze to configure.

The OpenWrt web UI (LUCI)

LUCI is still not clear and helpful, although much improved. Examples:

  • understanding how to set upstream DNS (on WAN interface, in LAN interface, in DHCP settings, in all of these?);
  • same for how to set local domain name (3 places to choose) and what the consequences are.

Poor documentation

I struggled with the OpenWrt “user manual”. For example, many of its pages say basically “help for FOO: to accomplish FOO, I pasted the following text into the config files in some unspecified version of OpenWrt,” without explaining what exactly FOO was meant to accomplish and its trade-offs and interactions.

Configuration as code

I discovered by accident that the LUCI can show the commands for the settings changes, if you click the mis-named “unsaved changes” button which appears after pressing “save”.

That’s a great start. It could be developed into something so much better, a real configuration-as-code methodology. Nowadays that should be promoted as the primary way to manage the router. Instead of just “backup” and “restore” there should be facilites like diff the current config against a backup and revert selected differences. Tools should be promoted for managing the config externally from e.g. a version control system or Ansible.

Inconsistent defaults

When LUCI writes a config section, it changes settings that the user didn’t change. It seems to have its own idea about what a default config looks like, and this is different from the default config files supplied at start-up. This makes it difficult to manage the settings in version control. These spurious changes are shown in the LUCI pending changes preview. (It would be helpful if that preview included the option to revert selected changes, although that would not go far enough.)

How it should be done: The LUCI settings should always match the text config defaults, and that should be tested. This would come naturally when adopting configuration-as-code as the primary management method.

Finding what (A)DSL settings to use

Finding settings to use for the ADSL connection was hard. My ISP PlusNet published a few basic settings (VPI/VCI, mux, user and password, etc.) but OpenWrt required other settings as well, and some of the settings didn’t exactly match.

The OpenWrt ISP Configurations page seems quite useful but says for example “Annex A, Tone A” whereas LUCI doesn’t have an option named exactly “Annex A”: its options include “Annex A+L+M (all)”, “Annex A G.992.1”, etc., and it doesn’t have an option for “Tone A” but instead “A43C+J43+A43”, “A43C+J43+A43+V43”, etc. This makes it really frustrating if one is not a DSL expert: I do not know which of the available options will work and which will not. When on my first try it would not connect (showing some sort of authentication error) I did not know which settings could possibly be the cause.

After a lot of reading and experimentation I noticed that the generated text configuration corresponding to each LUCI option gave me a strong clue: the generated config for tone “A43C+J43+A43” used the option code value “a” whereas for tone “A43C+J43+A43+V43” it used the code value “av”. That strongly suggested I should select the former. And similarly for “Annex”.

Finally I came across a small comment between two example configurations in that same page, that said I must also delete the ATM bridge that was set up by default. The LUCI description of “ATM Bridges” says, “ATM bridges expose encapsulated ethernet in AAL5 connections as virtual Linux network interfaces which can be used in conjunction with DHCP or PPP to dial into the provider network.” Not great. That didn’t help me at all.

After changing settings as best I could, and deleting that ATM bridge, it then worked.

How it should be made easier:

  • define a way of publishing a DSL configuration online as a structured code block (could be the OpenWrt config language, for a start);
  • make LUCI able to accept a whole DSL definition in a single cut-and-paste operation (a text config box);
  • start a database of these (encourage this to be maintained by the community; make it distributed);
  • add a “search in database(s)” function for these in LUCI.