Category Archives: Home Automation

Myenergi Zappi EV Charge Point First Test

Posted on by
Reply

Now the parking area is accessible to cars and with it being forecast sunny for most of the day, it seemed a good opportunity to put the electric car in the garage for the first time and test out charging it with the Myenergi Zappi EV charge point, using excess solar generation that probably wouldn’t fit in the PowerWall battery and would hence be curtailed.

BMW i3 EV in the Garage, connected to one of the two Myenergi Zappi EV Charge Points

The BMW i3 looks a bit lost when viewed from the CCTV camera that monitors the garage. The plan was always to park that car there, which influenced the location of the ‘primary’ Zappi EV charge point at the back of the Garage, between the first and second parking bays. (The ‘secondary’ Zappi is just visible at the bottom-right of the photo, where it can be used from the third parking bay and for cars parked outside.)

One of the key features of the Zappi unit is that it can harvest excess solar generation and charge a car at a variable rate to make best use of the solar generation that would otherwise be exported (or curtailed – depending on the configuration settings). While it’s useful to have this capability, with both a house battery and a decent export tariff it will typically be more economical to charge the car on the off-peak overnight rate and get paid to export solar generation during the daytime – except when there’s more solar power than can be exported or used to charge the house battery1.

With the PowerWall having a DC-connected battery integrated with the solar PV inverter, it’s not possible for the Zappi to tell whether power coming from the PowerWall (which it monitors using a CT clamp) is originating from the solar panels or from discharging the battery. It has a second CT clamp on the main grid connection, so it does know whether the site is Exporting or Importing overall – but the Zappi manual admits to the limitations in such circumstances.

With the Intelligent Octopus Go tariff, Octopus get to control when the car charges – and will either do this in the normal overnight off-peak period or they will add an ‘extra’ off-peak period if they decide to charge the car at other times. Before having the Zappi it was necessary to have Octopus control the car via the BMW API but now it is preferable to have them control the charger instead2. Right now – even when deleting and re-adding the Electric Car ‘device’ and when telling them there is a Zappi charger, they still want to control the car. I’ve submitted an online form which is meant to ask them to control the charger instead – for which they’ll ask for the Myenergi account details, not the BMW account details. The form said to allow up to one working day for that to take effect, so I’ll try re-adding the ‘device’ in a day or so.

The other configuration setting that needs attention before allowing Octopus free rein over overnight EV charging is the “Import Limit” for the PowerWall 3. Right now there’s no import limit set so there’s a risk of:

  • Octopus charging the electric car at 7.5 kW
  • Tesla charging the PowerWall battery at 8 kW
  • The House drawing 3.5 kW or more if both heat pumps are running

That would make a total of 19 kW or 82.6 A at 230V, which is more than the rated capacity of the DNO fuse on the grid connection and it would be A Bad Thing to have that fuse blow3. Given that the PowerWall is enforcing the grid export limit we might as well have it enforce the grid import limit too (by slightly reducing how aggressively it charges its batteries from the grid).

  1. It should be rare to have ‘too much’ solar generation like this once the charging algorithm for the house battery can be made to leave enough room for ‘tomorrow’s’ forecast solar generation ↩︎
  2. This should mean that any scheduled pre-conditioning ahead of a future journey won’t be affected, whereas that schedule gets wiped when Octopus control charge scheduling using the car API. It should also prevent the car charging for a few minutes whenever it’s plugged in. ↩︎
  3. There’s another 80 A fuse in the PowerWall Backup Gateway, which might blow first and is much easier to replace ↩︎

Temperature and Humidity Monitoring in the Outbuildings

Posted on by
Reply

In the House, there are Oregon Scientific temperature and humidity sensors in about half the rooms, as described in the Multi-Room Temperature and Humidity Monitoring page. These are integrated with Home Assistant via an RFXCOM 433MHz gateway. At the time those were installed they were an easy and cheap add-on to an existing monitoring solution and continue to work well – but they don’t feel like the best choice for a new setup in the Outbuildings. Where sensors like the THGN132N are listed by online stores they’re showing “Out of Stock” but would be £20 each, inc VAT.

In the Outbuildings, the Workshop and Utility Room are insulated and heated – and will report temperature (and humidity?) data via their Daikin air-to-air heat pump controls – so arguably those don’t need any further sensors. It’s the unheated, uninsulated and well-ventilated spaces which are of more interest – especially in terms of any risk of below-freezing temperatures (frozen water pipes?) or condensation.

An important emerging standard for environmental sensors and other IoT devices is the Matter IoT protocol, typically run over the Thread radio network. The vendor-independent nature of both Matter and Thread is appealing and they both operate locally within a site – not relying on an Internet connection or Cloud-hosted services. The Home Assistant folks are committed to supporting these protocols and IKEA have recently announced they will be moving their IoT product line over to the Matter and Thread standards and there’s an initiative to integrate Thread with KNX. That feels like enough momentum to make these protocols ‘mainstream’ – but even if they prove unsuitable it will be good to learn about how both Matter and Thread operate. Matter is based on IPv6 and it will be interesting to see how that has been implemented.

The separation between the Matter service protocol and the Thread (or WiFi) network layer feels like a robust IT architecture decision – as does the ability to have multiple Matter Controllers active simultaneously.

For the temperature and humidity sensors, Ikea’s TIMMERFLOTTE should be a good option – though they’re not available for purchase quite yet. If those don’t work out, other Matter-over-Thread sensors are available. The other required pieces of the puzzle are:

  • A Matter Controller – which is expected to be Home Assistant
    • Controllers are used to operate installed Matter devices
    • The Controller software runs as a separate process but on the same server as Home Assistant
  • A Thread Border Router – which connects the Thread radio network to wired and / or wireless Ethernet
    • This will almost always be a dedicated hardware device, since it needs to be located where it can act as a Thread radio, within range of Thread client devices
    • It’s possible to run the OpenThread Border Router software on something like a Raspberry Pi with additional boards to handle the Thread radio communications, but that seems like a lot of work to end up with a very flexible but unoptimised solution
    • Many of the devices which act as Thread Border Routers are part of the Google, Amazon, or Samsung ecosystems, which makes me think they’ll be expecting to integrate with other devices from those ecosystems – and might tend to be more ‘closed’ and less standards-compliant as a result
    • The GL-iNet GL-S20 IoT Gateway | Thread Border Router looks like a nice option:
      • It can be powered via PoE
      • It is supplied with a wall mount bracket
      • It runs the OpenThread Border Router software
      • It’s affordable – about £35 from the official GL.iNet store on AliExpress

I’ve now ordered one of the GL-S20 TBRs, though it will take a week or so to arrive from China.