Home Energy Management System Part 3: Planning the hardware

In order to meet my objectives without running wires from one part of my house to another, I will need at least the following WiFi-connected units for control and monitoring:

1. A unit near the hot water cylinder to measure the hot water temperature and simulate the boiler thermostat with a relay. As the iBoost main unit is also located close to the hot water cylinder, I will also use this unit to generate 868MHz fake iBoost sender signals, fake the Buddy transmissions (so that the main unit transmits the hot water heating power) and receive the transmission that reports the hot water heating power.
2. A unit close to the inverter and consumer unit, to measure the current draw of the Hypervolt EV charger (using an additional current transformer), measure the house import/export (possibly using an additional current transformer, but more likely by snooping the Modbus transmissions from the existing CT to the inverter), adjust the Hypervolt CT reading in order to control the Hypervolt, and measure the battery charge/discharge current so that I can reduce the power draw of the Hypervolt and/or iBoost to prevent the battery supplying them. In order to calculate power and power factor, this unit will also monitor the mains voltage and phase.
3. A unit in the hallway to display what is happening and provide control using a touch screen.
4. A unit in any convenient location act as the proxy server for the inverter so that I can snoop the data it sends to the cloud.

The obvious choice of hardware for unit #4 is a Raspberry Pi 4 running mitmproxy. It seems logical to run a web server on the same device to provide remote access, and to coordinate the whole system using software running on the Pi.

Units #1 and #2 do not need a lot of computing power, but they do need to provide real-time functions. A small WiFi-enabled microcontroller running a real-time operating system such as FreeRTOS will be adequate for each of these. To me, the obvious candidates are the ESP32 Devkit and the Raspberry Pi Pico W. So I need to choose between them. Each has advantages and disadvantages, and in both cases the primary development environment supported by the manufacturer is not to my taste.

ESP32 Devkit vs Raspberry Pi Pico-W

Raspberry Pi Pico W

ESP32 S3 Devkit C1

• The ESP32 uses its own ESP-IDF framework, which relies on code generated by a configuration script. It is designed to run under Linux only. That is an immediate problem for me, because I develop under Windows, using the Eclipse IDE out of preference. Every time I have to use Linux I find my self re-learning how to set up a Linux VM under Windows, then I need to research and re-learn a pile of obscure Linux command lines to get it to do what I want. There is an Arduino environment for ESP32 development under Windows, but while Arduino is great for users wanting to start learning C++ development on microcontrollers, it isn’t a serious development environment like Eclipse.
• The developers of the RP2040 development system don’t appear to have heard of libraries. They expect me to include the entire RP2040 SDK source in my project, whereas any sensible development environment would be provided as a static library that I can link my project with (with the option to modify and rebuild the library if I wish). The include files describing the SDK API and the hardware are scattered across numerous directories and depend on each other, forcing me to use a huge number of include paths. Again there is an Arduino environment for the RP2040 which includes a pre-built library for the SDK, but unfortunately it isn’t compiled with FreeRTOS support, which is a shame if I want to use USB or other subsystems (WiFi?) that would benefit from RTOS.
• The ESP32 uses several FreeRTOS tasks running closed-source software to control the WiFi, so I am denied full control of the RTOS task scheduling. The RPi Pico W uses a separate WiFi module with communication over a variant of SPI, so I have complete control over FreeRTOS tasks.
• Both the ESP32 and the RP2040 have broken ADCs. I am told that the ESP32 ADC is sufficiently non-linear that an external ADC is required if you need accurate measurements. The RP2040 ADC has missing codes around four particular values. It appears to be OK if you I avoid these values, and it’s probably possible to adjust the readings to remove the worst of the missing codes if I can’t.
• ESP32 has a DAC, RPi Pico W doesn’t.
• ESP32 has around 40 GPIO pins, although the devkits typically don’t provide access to all of them. RPi Pico W has 23 uncommitted GPIO pins, plus an on-board LED that can be driven via the WiFi module.
• RPi has two programmable IO units, which are useful for driving devices with non-standard interfaces such as WS2812 LED strips.
• ESP32 would be easier to re-implement on a dedicated PCB, because ESP32 SMD modules can be purchased, containing the WiFi electronics, processor, crystal, flash memory, and antenna (external antenna versions are also available). The RPi Pico W design would have to be copied almost in its entirely, however the antenna design is protected by a third-party copyright.
• Until the firmware I write includes over-the-air updating, the ESP32 will need to be programmed using ESPTool. The RPi Pico W is easier, just power up with the boot button held down and it presents a USB drive that I can just copy the firmware to, making firmware update form a laptop trivial.
• Both ESP32 and RPi Pico are dual core (I am ignoring the single-core ESP32 variants). I don’t expect to need a second core in this application.
• ESP32 has around double the RAM of the RPi Pico, although I expect the 264kb RAM of the Pico to be more than enough.
• The documentation for the RP2040 chip in the Pico and its SDK is superb. Historically, documentation from Expressif hasn’t been good – the ESP8266 documentation was initially appalling – but it has probably got better.

The ESP32 and RPi Pico W would both be valid choices in this application. In the end I decided on RPi Pico W because of the easier firmware upload process, because I am already familiar with the non-wireless version of the RPi Pico, and because I already have an Eclipse/Windows development environment for it and FreeRTOS from another project I work on (RepRapFirmware and in particular its CoreN2G hardware abstraction layer).

The remaining question is whether the display and control unit #3 in the earlier list should be combined with the Raspberry Pi 4 unit #4, or be a separate unit using another RPi Pico W. I will leave this open for now, although currently I favour locating the Raspberry Pi 4 closer to the inverter and connecting it to Ethernet rather than relying solely on WiFi; so I will most likely use another Pico W to manage the touch screen.

Next: hacking the Hypervolt Current Transformer