Smart(-ish) Electric Car Charging

For a while now I’ve been frustrated that the highly capable ‘smart’ electric car charging point installed as part of the Electric Nation research project reverted to ‘dumb’ mode at the end of the trial period. It’s not been too bad because the car has some of its own intelligent charging logic but since moving from the Octopus Agile tariff to Octopus Go (with a rate of 5p per kWh between 00:30 and 04:30 every night) it’s become more important to do all the charging between those times – and I’ve got enough of the API to the charge point working to exercise the control I need.

There’s a separate Technical Article on the details of the Circontrol EVSE API but the following high-level logic is currently working well:

  • The car is configured to charge immediately and at the maximum rate of 32A / 7kW
  • The charge point is normally configured as ‘Disabled’; this state is automatically set at 12:00 (noon) every day
    • This means that the car can be plugged in at any time after that and it doesn’t start charging
  • At the start of the Octopus Go low-tariff period (00:30), there’s a script which runs to:
    • Check there is a car connected to the charge point
    • Change the charge point to the ‘Enabled’ state
    • Run the ‘Remote Start’ transaction to prompt the car to start charging

The result is that – whenever the car needs charging overnight – it can be plugged in at any time of day and it will be fully charged by the morning, using cheap-rate electricity. The charge point is also available to power pre-conditioning of the car and the battery for a morning departure, if that has been configured in the car.

(If the car battery is really low (like less than 10 miles of range) it can take 4.5 hours to fully charge at 7kW, so it’s not quite fully charged by 04:30 when the cheap-rate period ends. The least-bad thing to do is to leave it charging until it finishes, which is probably no later than 05:00.)

NIBE Heat Pump Monitoring using Python instead of Perl

One of the most popular topics on this Blog is using the NIBE Uplink API to retrieve operational data reported by the Internet-connected NIBE heat pumps. That API is protected by OAuth2 authentication, which is a robust solution but which is rather more complicated than other APIs which simply expect an API Key or a non-expiring Token for authentication purposes.

There’s a Technical Articles page dating from 2016 which explains how to use the Perl scripting language on Linux to call the NIBE Uplink API, navigating the multiple steps of the OAuth2 handshake – see NIBE Heat Pump Monitoring via NIBE Uplink API (Perl Version). I originally chose Perl because that’s the language I was familiar with – and there was a Perl Module which handled many of the OAuth2 complexities.

Recently I’ve been learning Python for work and that’s proven to be a bit more friendly for this sort of thing. It’s also a language that more people are familiar with – and it’s rather more commonly used on different platforms, notably Microsoft Windows.

I’ve therefore adapted the original Technical Article to use Python rather than Perl and published that as NIBE Heat Pump Monitoring via NIBE Uplink API (Python Version). The Perl version is still relevant so will remain available too (especially since it has some valuable comments and responses) but my advice is for new users to follow the Python version instead.

I’ve also included some more general updates (such as the new NIBE S-Series heat pumps using an alternative API connected to myUplink.com) and some new screenshots. The script code is also now in a GitHub Repository rather than being embedded in the Blog page – and I intend to add some more comprehensive script examples once I migrate my other scripts from Perl to Python.