Home Energy Management System Part 4: Characterising the Hypervolt Current Transformer

The Hypervolt EV Charge Point is a UK-manufactured 7kW single phase unit. It is one of the smartest looking EV chargers on the market. It has no controls on the unit and can only be controlled via a smartphone or similar via the cloud server.

Unfortunately the app is rather poor. It often loses connection with the server and has to be stopped and restarted. The Charging/Stopped status display is frequently wrong. However, it does provide solar integration, with three modes:

  • Super Eco (only charge if there is enough solar power to provide the minimum 6A charging current, and then use all available solar power up to the maximum 32A)
  • Eco (use grid power if necessary to make up the required 6A, but use up to 32A solar power if available)
  • Boost (ignore solar, always charge at 32A).

Unfortunately, in the solar modes there is no display showing the actual charging power. There is a graph of charging power shown on the Analytics page, but it is misleading because it is very heavily smoothed and it does not show the gaps when charging was suspended. Also there is no facility to specify the maximum amount of grid power to be imported to make up the 6A; you can only choose zero (Super Eco mode) or 6A (Eco mode). So when my excess solar PV drops to 4A, if I want to avoid exporting that solar power and I am happy to import 2A to continue charging my car at one third of the price of fully imported electricity, I have to switch it out of Super Eco mode into Eco mode. Then I have to monitor the solar output as it drops further at the end of the day and turn it off when the amount of imported current it needs is more than I want. Of course I often forget to do this.

Sensible EV charger software would allow me to specify that I am happy to import up to e.g. 750W (3A) to make up the solar output to 6A. I am told that the Zappi EV charger provides this facility.

All said, I honestly cannot recommend the Hypervolt until they improve its functionality. But I’ve already had it installed, and I am not going to spend another £1000 or so for an alternative unit that might or might not be better overall.

In the absence of any published API to control the Hypervolt, and not wishing to modify the Hypervolt itself, it seems my only option to exert greater control over it is to modify the input that it receives from the current transformer. This input tells the unit how much current is being imported from or exported to the grid, and hence how much charge current to provide to the EV when the unit is in solar mode. In order to be able to show the real-time EV charging power, I will use an additional current transformer to monitor the power draw of the Hypervolt.

Caution! In some installations, the current transformer is also used to sense the amount of grid import, and to reduce the charging current if necessary in order to limit the grid import to some maximum value. This may be needed when the house electricity supply does not have a 100A fuse and cannot easily be upgraded, for example because it is a looped supply (cable shared with an adjacent property). In such an installation it could be dangerous to modify the signal from the current transformer to the Hypervolt. Fortunately for me, I have a modern supply with a 100A fuse and my local distribution company has not applied an import limit to my property.

How current transformers work

A split core current transformer comprises a pair of ferrite cores which are clamped around either the line or the neutral wire that carries the current to be monitored. Around one of the cores is wound many turns of fine wire. This acts as the secondary of the transformer. The wire carrying the current to be measured passing through the core acts as a single-turn primary.

The current is stepped down by (ideally) the turns ratio of the current transformer. For example, if the current transformer has a ratio of 1:1000 then a current of 10A in the wire would give rise to a current of 10mA in the secondary.

In order to measure the secondary current, it is normally loaded with a “burden resistor”. For example, a burden resistor of 100 ohms would convert the 10mA current into 1V.

Sometimes the burden resistor is integrated into the current transformer itself (this is the case for the current transformer used by the iBoost sender). If it isn’t, then when the current transformer is disconnected from the equipment that provides the burden resistor, a dangerously high voltage can appear across the secondary of the current transformer. To avoid this, current transformers without internal burden resistors normally have metal oxide resistors or other transient suppression devices incorporated, to carry the secondary current safely and limit the output voltage to a few volts or a small number of tens of volts.

Modifying the sensed current

We could modify the current sensed by the CT in a number of ways:

  • Modify the CT itself, for example by adding an additional winding. This is not likely to be practical.
  • To make the CT less sensitive, we could switch an additional burden resistor in parallel with the existing one to shunt some of the current
  • To make it more sensitive, we could substitute a current transformer with a higher turns ratio
  • If the current transformer has an internal burden resistor, then to add an offset we could insert a voltage in series with the current transformer
  • We could apply an offset by injecting a current in parallel with the current transformer (this method can be used regardless of whether the burden resistor is internal or external)

Whatever method is used, we have no control over the static voltage at the Hypervolt current transformer connections; so we had better ensure that whatever means we use includes an isolating transformer, or some other form of electrical isolation from our control hardware.

In order to achieve full control of the amount of charging current provided by the Hypervolt from zero to its maximum, I will need to put it in Super Eco mode; then I can control how much power it takes by adjusting the apparent grid import, by adding an offset to the current transformer output. To prevent the Hypervolt from taking charge from the house battery, I will need to reduce the apparent grid export power by the amount of power drawn from the battery. To put the Hypervolt in Boost mode, I will need to pretend that there is 7kW of solar export available (and then prevent the house battery trying to supply any of it).

The first step was to establish the ratio of the current transformer and whether it has an internal or external burden resistor. To do this, I carefully disconnected the current transformer secondary for the Hypervolt. Then I looked at the voltage across the secondary using an oscilloscope. This showed a clipped waveform – almost a square wave – with an amplitude of 15V peak to peak, indicating that the CT uses an external burden resistor and has a metal oxide resistor or other internal transient suppression device.

I then connected a multimeter set to measure AC current across the secondary. I monitored the reading while watching the solar export reported by the inverter app. The inverter app has some lag and at times the CT current reading was changing rapidly as clouds passed in front of the sun; but eventually I got a set of readings. Here are some of them:

Export powerCurrent mACalculated CT ratio
14462.62317
14252.62284
13992.62242
14322.72210
60639.02807
55278.02879
47088.52308
53678.62600
51578.252605
42046.952520
42396.952541
42607.22465
Some readings of Hypervolt CT current and export power

From this I conclude that the Hypervolt CT has a ratio of about 2500:1. Current transformers are not exact devices because the actual ratio depends on how well the wire fills the aperture and how thick the insulation is. Small wires and thick insulation cause some of the magnetic field from the wire not to be captured by the ferrite core, leading to a reduction in the ratio achieved.

I also estimated the value of the burden resistor in the Hypervolt, both by attempting to measure it directly (testing it with both polarities of the multimeter leads) and by measuring the voltage when the CT was again connected to the Hypervolt and the export power was stable. Both led to a value of around 10 ohms.

So to control the Hypervolt up to 32A charging current, we will need to inject current of up to (32/2500)A = 12.8mA. The maximum voltage that the injection device may need to overcome, assuming 70A maximum load, is about (70/2500)*10 = 0.3V.

Providing an isolated source of injection current

I have already mentioned the need for the injection device to be electrically isolated from the CT in case of high common mode voltages in the Hypervolt (for example, before a PEN fault is detected). Additionally we require that when the injection device is not powered, it must not affect the CT output read by the Hypervolt significantly. To meet these requirements I propose to use an Oxford Instruments A262A6E transformer. This is a 1+1:1+1 audio transformer capable of carrying frequencies down to 30Hz, so it covers the 50Hz frequency that we need. It provides isolation up to 1kV. With the two secondaries connected in series, it has 500mH secondary inductance and 40 ohms resistance. The reactance at 50Hz will be 2*pi*50*0.5 = 157 ohms, which if not corrected could cause a phase shift and up to 6% error in the Hypervolt reading. We can tune that out by connecting 20uF of capacitance in parallel with it so as to form a parallel resonant circuit tuned to 50Hz. The split primaries allow us to drive it easily in push-pull fashion from constant-current outputs.

The Vigortronix VTX-101-006 appears to be a very similar transformer at lower cost but its datasheet does not specify the inductance; so I chose the Oxford Instruments one.

The remaining consideration is whether the transformer can tolerate the maximum required secondary voltage at 50Hz without the magnetic core saturating. The datasheet gives the power carrying capacity as 2.5mW @ 50Hz. Although not clearly stated on the datasheet, I believe this is with the windings connected in series and a load of 600 ohms. This corresponds to a voltage of sqrt(0.0025 * 600) = 1.22V RMS, well above the maximum 0.3V that we expect (thanks to the low burden resistance in the Hypervolt).

I will publish the full schematic of the current injection circuit in a later instalment of this series.

[Series to be continued]

Posted in Electronics | Tagged | Leave a comment

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

Posted in Electronics | Tagged | Leave a comment

Home Energy Management System Part 2: Hacking the iBoost+ protocol

The Marlec iBoost+ solar PV hot water diverter uses a current transformer to detect when there is surplus power being exported. This is wirelessly connected to the main iBoost+ unit, which adjusts the power fed to the hot water tank immersion heater so as to use any excess power to heat the water, until the immersion heater thermostat cuts out.

The iBoost+ Buddy display unit is also connected wirelessly to the main unit. By this means the Buddy can display the current grid import or export and the amount of power being diverted to the immersion heater, or “Water tank HOT” if the thermostat has cut out. It can also be used to turn on the immersion heater at full power temporarily for a set period of time.

The sender is battery powered and measures only the current being imported or exported. It sends a burst of data over a 896.3MHz wireless channel to the main unit every ten seconds. The iBoost+ main unit and the Buddy also communicate over 896.3MHz wireless.

To monitor and control the iBoost+, one option would be to fake the sender current transformer input, and add a current transformer to measure the power being fed to the immersion heater. But if we can decode the RF protocols, it would be simpler to fake the sender RF transmission, and read the messages sent by the main unit to the Buddy.

There have been previous attempts to decode these RF protocols, which are recorded at https://github.com/merbanan/rtl_433/issues/1739. These have been only partially successful. So far these decode attempts have been made using RF data captured from Software Defined Radio receivers.

Decoding the sender protocol

I decide to take a closer look at the iBoost hardware, in particular the sender unit. Removing the cover revealed a main circuit board with a microcontroller, and a RF daughter board with a CC1100 RF transceiver IC. This IC uses SPI to communicate with a microcontroller, and the SPI pins were conveniently connected directly to the standoff pins joining the daughter board to the main board. So I hooked up a logic analyser and captured some traces.

Here are some sample captures:

With no sensor connected:

MISO: 0x0F·0x0F·0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F

MOSI 0x36 0x3F 0x2C 0x7F 0x8D 0x2D 0x01 0x00 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x35 

After further captures it was observed that the MOSI data bytes that are all 0x02 in this capture are in generally a mixture of 0x01 and 0x02.

With the sensor connected but no current flowing:

MISO 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F

MOSI 0x36 0x3F 0x2C 0x7F 0x8D 0x2D 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x35

We see that the 0x01 and 0x02 bytes have all been replaced by 0x00.

With a 3kW kettle drawing current through the CT (five different samples of MOSI):

MISO 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F

MOSI 0x36 0x3F 0x2C 0x7F 0x8D 0x2D 0x01 0x00 0x7D 0x89 0x82 0x6B 0x4E 0x29 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x25 0x4F 0x6D 0x7C 0x88 0x84 0x6E 0x51 0x2D 0x06 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x2A 0x54 0x70 0x35

MOSI 0x36 0x3F 0x2C 0x7F 0x8D 0x2D 0x01 0x00 0x26 0x1D 0x13 0x0A 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x05 0x11 0x1D 0x22 0x27 0x26 0x1E 0x14 0x0B 0x05 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x07 0x13 0x1E 0x22 0x27 0x35

MOSI 0x36 0x3F 0x2C 0x7F 0x8D 0x2D 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x09 0x0E 0x10 0x13 0x12 0x0E 0x0B 0x07 0x05 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x08 0x0D 0x10 0x10 0x0F 0x0C 0x0A 0x07 0x05 0x01 0x00 0x00 0x00 0x35

MOSI 0x36 0x3F 0x2C 0x7F 0x8D 0x2D 0x01 0x00 0x00 0x00 0x00 0x01 0x02 0x03 0x06 0x06 0x07 0x07 0x06 0x05 0x03 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x02 0x03 0x05 0x05 0x06 0x07 0x06 0x05 0x03 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x35

MOSI 0x36 0x3F 0x2C 0x7F 0x8D 0x2D 0x01 0x00 0x06 0x07 0x07 0x07 0x06 0x04 0x02 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x02 0x04 0x06 0x06 0x07 0x06 0x07 0x05 0x03 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x02 0x02 0x05 0x35

It can be seen that the MISO data is always 0x0F, indicating that the sensor is not receiving anything. This is the case whether or not the main unit and Buddy are powered. So the sensor is transmit-only.

Plotting the MOSI data for several sets of data gave the following chart:

MOSI data for six data captures

We observe the following:

  • The first 8 bytes and the last byte are the same in all captures. The first few bytes are commands to the CC1100 chip rather than data to be sent. The last byte is also a command to the CC1100.
  • The remaining 40 bytes appear to show the positive half cycles only of a sinusoidal waveform.

So it is reasonable to conclude that once every ten seconds the ADC takes 40 readings at 1ms intervals, then these readings are set in a single burst as 8-bit data points. Negative values are sent as zero.

The three readings that peak at a value of 140 were taken with a 3kW kettle drawing current. The Buddy displayed about 2600W during this time. Assuming 240V main voltage, this corresponds to an current of 10.83A RMS or 15.3A peak. Therefore the transmitted value appears to be about 9.1 times the instantaneous current.

So it appears that this transmission will be easy to fake, using an off-the-shelf RF module based on a CC1100 or CC1101 chip.

Decoding the main unit and Buddy protocols

Armed with the above information, I set up a SDR radio to receive the signals and confirmed that I could use rtl_433 (https://github.com/merbanan/rtl_433) to capture similar data. I found that it was unable to capture the data when no current was flowing and all the samples were zero, but otherwise it could.

I then tried capturing transmissions with either or both of the iBoost main unit and the Buddy powered up. With just the main unit powered up, there were no additional transmissions. With just the sender and Buddy powered up there were additional transmissions like this:

2c8d2d0100000000000000000000000000000000000000000000000000000000000000000000000000000000000

I interpret this as a message from the Buddy to poll and/or command the main unit. When the main unit is also powered up, transmissions of the following form appear shortly after each message from the sender:

258d2d2200000001000000000100000000ffffffffffff000000000000000000000000000000a7f38

The above message was captured with zero current in the sender. With a 1400W load connected it changed to this:

258d2d2200000001000000000100000000000018190900000000000000000000000000000000f2020

With a 3kW kettle connected (Buddy reading about 2500W, reducing slowly) I saw these transmissions:

258d2d22000000010000000001000000000000b7071000000000000000000000000000000000c1f38
258d2d22000000010000000001000000000000f2371000000000000000000000000000000000d9bc4
258d2d22000000010000000001000000000000f2371000000000000000000000000000000000d9bc0
258d2d22000000010000000001000000000000cf3010000000000000000000000000000000009b020
258d2d220000000100000000010000000000009f21100000000000000000000000000000000097c82

With the current transducer reversed (so that the Buddy registered power export) it changed to this:

258d2d2200000000000000000100000000590b5de3f6ff000000000000000000000000000000cc760

So it appears that the import/export amount and heating power are is passed in a 6-byte field. A value of 0xffffffffffff means no data available. A value of 000018190900 is an amount of imported power, and a value of 590b5de3f6ff is an amount of exported power and an amount of heating.

Further tests indicated that when the amount of imported power varied, the final two bytes of this 6-byte field remained as 0900 and the leading two bytes remained at 0000. With the export current held more or less constant and the heating power ramping up, the values I saw included these:

0000d81ff7ff 0000d81ff7ff 1b00ac2bf7ff b5045842f7ff b5084563f7ff 590b5de3f6ff

With the export power increased to almost 3kW I saw these values:

5404d9ffefff 150b58c8efff 150b58c8efff

So I hypothesise the following:

  • The first two bytes represent the amount of heating power as a 16-bit little-endian unsigned integer;
  • The next four bytes represent the amount of imported or exported power as a 32-bit little-endian signed integer. With 2.5kW export indicated these values are 0xffefffd9 and 0xffefc858 which translate to -1048615 and -1062824. With 1.4kW export the values are 0xfff71fd8, 0xfff72bac, 0xfff76345 and 0xfff6e35d which translate to -581672, -578644, -564411 and -597155. With 2.5kW import they are 0x001007b7, 0x0001037f2, 0x001030cf and 0x0010219f which translate to 1050551, 1062898, 1061071 and 1057183; so approximately the negative of the export figures, as expected.
  • There are also a couple of 1-bits earlier in the message, meaning unknown.
  • When the thermostat cuts out, one or more bits must change to tell the Buddy to display “Water tank HOT”. I haven’t captured this message yet.

You can see some sample data I captured in BitBench.

I also captured the initialization commands that are sent to the CC1100 chip when the sender battery is inserted. First CS is lowered, a single byte of 0x30 is sent and CS is raised again. Then CS is lowered and there is the following 70-byte burst:

0x0D·0x21·0x0E·0x65·0x0F·0x6A·0x0B·0x08·0x0C·0x00·0x10·0x5B·0x11·0xF8·0x12·0x03·0x13·0x22·0x14·0xF8·0x0A·0x00·0x15·0x47·0x21·0xB6·0x22·0x10·0x18·0x18·0x17·0x00·0x19·0x1D·0x1A·0x1C·0x1B·0xC7·0x1C·0x00·0x1D·0xB2·0x23·0xEA·0x24·0x2A·0x25·0x00·0x26·0x1F·0x29·0x59·0x2C·0x81·0x2D·0x35·0x2E·0x09·0x00·0x0B·0x02·0x46·0x07·0x04·0x08·0x05·0x09·0x00·0x06·0xFF

Then CS is raised, lowered for this 9-byte burst, and raised again:

0x7E·0xC6·0x39·0x3A·0x3B·0x3C·0x3D·0x3E·0x3F

About 10 seconds later it sends the commands and data for the first sensor reading transmission. Another user kindly decoded these commands and published his analysis at https://github.com/merbanan/rtl_433/issues/1739#issuecomment-1265761556.

This information should be sufficient for me to construct a module to transmit fake CT readings to replace the sender and fake poll messages to replace the Buddy, and receive the readings from the iBoost main unit.

Next: Planning the Hardware


Posted in Electronics | Tagged | 1 Comment

Home Energy Management System Part 1: Objectives

This series will record my adventures in building a home Energy Management System, to monitor and control solar PV generation, battery storage, EV charging, hot water heating, and grid import/export.

Back in 2018 I had a solar PV (photovoltaic) system installed, comprising 4kW solar panels, a Bosch inverter, a Marlec iBoost+ to divert excess solar power to the hot water tank immersion heater, and iBoost+ Buddy to display and amount of grid energy import/export and the amount of power used for water heating.

Last year I bought a battery electric vehicle and had a Hypervolt EV charge point installed.

In response to the recent increase in energy costs, I recently had an additional 6.4kW solar PV installed along with a Alpha ESS inverter and 10.4kWh battery. My system now looks like this:

Energy system diagram

Individually, these systems work well. Also the new inverter is aware of the older 4kW PV array and monitors the power it generates, so that it can account for it when deciding whether or not to charge the battery, and to enforce the 5kW export limitation that my DNO (Western Power) has unfortunately mandated. However, the system as a whole has some issues because the various parts don’t communicate:

  • Sometimes the solar hot water diverter comes on in the middle of the night when there is no PV generation, causing the battery to power the immersion heater. This is not in general a good use of electricity. In some cases it might be desirable, depending on the battery state of charge (it is high?) and the hot water temperature (is it low enough that the oil-fired boiler is about to fire up?).
  • The Hypervolt (in common with other Type 2 EV charge points) needs a minimum of 1.4kW power. It can be set to charge the car only when there is at least 1.4kW of solar power available, or to import enough for the grid to make up the solar power to 1.4kW when necessary, There can be times when there is e.g. 1kW of excess PV generation, but the battery is full so that power is being exported to the grid. If the EV charge state is low then I would rather use that 1kW plus 400W of grid energy to charge the EV. However, I don’t want the house battery to discharge to provide the 400W.

So I need a home energy management system that will allow me a greater degree of control:

  • Not allow the house battery to power the hot water diverter unless I want it to
  • Never allow the house battery to charge the EV
  • If the EV state of charge is low and the home battery state of charge is high, prioritise the EV charger over the home battery when there is sufficient PV generation to charge the EV

and some additional nice-to-haves:

  • Display in a convenient location the power being generated by solar PV, grid power import or export, battery charge/discharge power, water heater power, EV charge power and other load power. The Alpha ESS app can display the first three of these along with total load power on a smartphone, but there is some delay in the readings and I would also like a fixed display.
  • Display the hot water temperature
  • Integrate with the Octopus Energy Agile and Outgoing Agile time-of-use tariffs, so that I can import electricity when the price is negative and export it when the export price is highest

In order to achieve this, the Energy Management System (EMS) will need to sense the following:

  • Total PV generation
  • Battery charge/discharge
  • Hot water diverter power
  • EV charging power
  • Grid import/export
  • Hot water temperature

and the EMS will need to exert some control over the following:

  • Hot water diverter power
  • Battery charge/discharge rate
  • EV charging rate

Unfortunately, there are as yet no open protocols for monitoring or controlling any of these devices – something that I hope will change in future! So it will be necessary to use a degree of hacking to achieve these goals. My aims will be:

  • Not to make any hardware modifications to individual items. Doing so would invalidate manufacturer’s warranties and the MCSE certification.
  • Not to compromise any safety or regulatory facilities, for example the ability of the EV charger to throttle its output if it detects that excessive power is being drawn from the grid.
  • To maintain the ability to restore the system to its original configuration in the event of having to get specialist help to resolve a fault

To achieve these aims I will need to focus on the communication protocols between components of the system. These include:

  • The iBoost current sensor, main unit and Buddy display use 868MHz RF for communication. It may he possible to identify the protocols in use to achieve control and monitoring of that subsystem.
  • The Hypervolt uses a current transformer to sense when there is sufficient grid export to turn on the charger when it is in solar mode, and how much power to deliver. It should be possible to add additional voltage or current to the output to fake additional grid import, to persuade the device not to charge or to reduce the charging power.
  • The Alpha ESS system sends data to the cloud every few seconds. It may be possible to use a proxy server to intercept this data.
  • The battery is connected to the inverter through a pair of thick wires. A clamp-on DC current sensor could be used to monitor the charging current. This would give an approximate indication of charging power if we can estimate the battery voltage.
  • The Alpha ES uses separate power monitoring units to monitor grid import/export and the output from the old solar PV array. The communication protocol is based on Modbus and is published, so we could snoop this communication.

My provisional plan for the EMS will use the following pieces of hardware:

  1. A unit located close to the Alpha ESS inverter and consumer unit. This will snoop the modbus sensor data used by the inverter, measure the current draw of the Hypervolt using a current transformer, add voltage/current to the Hypervolt CT input to fake a reduction in grid power export, and if necessary monitor the battery charge/discharge current.
  2. A unit on the LAN to act as a proxy server for the inverter, to snoop the data being sent to the cloud by the inverter, and query Octopus Agile import and export prices.
  3. A unit close to the hot water cylinder to measure the hot water temperature, command the boiler hot water heating on/off using a relay, control the iBoost either via its RF protocol or by faking the sender CT input, and monitor the iBoost power either via its RF transmissions or using an additional CT.
  4. A display and control unit with TFT touch screen in the hallway.

I plan to use a Raspberry Pi to provide the proxy server and a web server for remote access. The other units will be built around ESP32 or RPi Pico-W modules.

Before I proceed, here are some observations about existing equipment available:

  • myEnergi sells the Zappi EV charger and the Eddi hot water diverter (similar to the iBoost). These units can work together with solar PV to assign priority to one of the other when excess solar power is available. It looks as though they may announce integration with a home battery system soon. Ths nay provide a good solution for anybody starting from scratch with solar PC, battery storage and EV charging.
  • Open Energy Monitor (https://openenergymonitor.org/) is a set of modules based on Raspberry Pi and Arduino to monitor energy use and provide some aspects of control.

Next: Hacking the iBoost protocol

Posted in Electronics | Tagged | 1 Comment

Adding filament monitors to the Hemera tools

The imminent 3.2beta release of RepRapFirmware includes support for filament monitors connected to Duet 3 expansion and tool boards. This post describes how I added filament monitors to the two Hemera tools on my E3D Tool Changer.

Continue reading
Posted in 3D printing | Tagged , | Leave a comment

Improvements to the Hemera Tools

Since building my first Hemera tool controlled by a Duet3D Tool Board, I have built a second one and made some improvements.

Continue reading
Posted in 3D printing | Tagged , , , | 5 Comments

Large Kossel update

My large Kossel variant has been running for several years now. It is reliable and produces good prints. I have however replaced the extruder drive and the power supply by different models, and added a filament monitor. I will now describe these changes and the reasons for them. Continue reading

Posted in 3D printing | Tagged , , | 4 Comments

Converting the E3D Tool Changer to Duet 3 with Hemera Tools (Part 2)

Configuring the Duet 3

The Duet 3 configuration and other system files I use are based on the ones that I published for Duet WiFi/Ethernet running RepRapFirmware 3. They are configured so that X0 Y0 is the centre of the bed. The changes I made for Duet 3 are: Continue reading

Posted in Uncategorized | 3 Comments

Converting the E3D Tool Changer to Duet 3 with Hemera Tools (Part 1)

The E3D Tool Changer is a versatile platform for multi-material 3d printing, laser cutting/engraving, and associated techniques requiring a stable XYZ motion system. Although it is also available with fewer tools or no tools, the common configuration is four 3D printing heads using Titan extruders and 780mm Bowden tubes. It is generally recognised that direct-drive print heads can deliver better print quality than heads using long Bowden tubes, and the Titans are not as good as some competing extruders. So the arrival of the E3D Hemera direct drive extruder provides an interesting upgrade path for the Tool Changer. Continue reading

Posted in Uncategorized | Comments Off on Converting the E3D Tool Changer to Duet 3 with Hemera Tools (Part 1)

Using exceptions in C++ embedded software

For several years I have been the lead developer of RepRapFirmware, which is firmware for 3D printers running ARM Cortex processors. Until recently I saw no compelling reason to use exceptions, so I compiled the firmware with gcc options -fno-exceptions -fno-rtti in order to keep the code small. Continue reading

Posted in Embedded software | Tagged , , , , | 6 Comments