Duracell home battery

I’m currently getting quotes for home solar and battery systems. One that seems quite well priced is Duracell’s Dura5 battery. Having to rely on cloud servers is a deal breaker for me, and my Googling has only turned up getting Home Assistant to interface with this battery by doing RESTful stuff with Duracell’s cloud.

However, the spec sheet says that the Dura5 battery has CAN / RS485 communication ports, so is it possible to get Home Assistant to control this kit locally?

For hybrid inverters and batteries, you cannot control the battery, only the inverter.

Batteries talk to inverters, usually over CANbus. You need to connect to the inverter, which is possibly a Dura-i device.

This appears to have the usual CAN and RS485 ports to connect to the battery and to the CT clamp meter. Extra RS485 port may offer Modbus RTU, and if there is indeed Ethernet (optional LAN/WiFi dongle) then Modbus over TCP may also be offered. Like many manufacturers today, monitoring and control is offered over a cloud based app, and other access can be limited.

Actually doing anything with Modbus by direct connection to the inverter requires knowing the correct settings, protocol, and registers, which are often not willingly offered. However, many devices are actually badged products / systems from the mainstream manufacturers, and will use or mimic something like Solis, Deye, Sunsynk, or Growatt. This can mean that, with a bit of tinkering, an existing HA integration for another brand could work. Of course, unless someone else has already taken this step, with a newly introduced and small market device, you may find yourself being the first person to try and connect to this particular model.

If open Modbus communication is offered (RTU or TCP) by the inverter, and if physical connection can be made, and if the register map used is fairly similar to eg Solis, and if the inverter data and control commands are fairly standard, then I would suggest possibly yes with time and effort.

Interestingly, I had an installer quote the other day for Duracell batteries paired with a Solis inverter (because he said the Duracell inverters are crap), so that may be an option. Although that installer also swore blind that there are no products on the market that can do whole home backup, so I question his knowledge a bit!

ESPHome BLE Modbus monitor for Duracell Dura-i5 inverter (with PV consistency + grid lockout)

I’ve been working on an ESPHome node to monitor a Duracell Dura-i5 inverter that only exposes data over Bluetooth (no RS-485 wired connection used here). The goal was to:

  • Pull reliable PV / grid / load / battery values over BLE
  • Make them behave sensibly at night and during noisy transitions
  • Feed clean metrics into Home Assistant’s Energy dashboard
  • Add a bit of logic + hysteresis so grid import behaves more like a “mode”, not random noise

This post shares my current ESPHome config and explains what it does.


Hardware & stack

  • Inverter: Duracell Dura-i5 (BLE device name BLE1423PH)
  • Bridge: ESP32-S3 dev board running ESPHome
  • Protocol: BLE → vendor bridge → Modbus-style frames on service 0xFF10, write 0xFF11, notify 0xFF12
  • Target: Home Assistant, including Energy dashboard

What this ESPHome node actually does

At a high level, the node:

  • Connects via BLE client to the inverter and sends Modbus-like read requests
  • Reassembles notify frames, verifies CRC16 Modbus, and parses register windows:
    • 0x2000 region: SoC, battery volts/amps
    • 0x1400 region: MPPT1 / MPPT2 power
    • 0x150F : an alternative PV power candidate (scaled u/10)
    • 0x130B : used as load power (AC side)
  • Derives:
    • Battery DC power (charge/discharge)
    • Load consumption (absolute W)
    • PV power from a mix of sources (derived vs MPPT vs 0x150F)
    • Grid power (import/export) from the power balance

It then publishes:

  • Clean instantaneous sensors: PV, grid, load, battery charge/discharge, SoC, etc.
  • Integration sensors (kWh) for:
    • PV energy
    • Grid import / export
    • Load energy
    • Battery charge / discharge energy

These map directly into the Energy dashboard.


PV consistency layer: choosing a sane PV value

The tricky bit with this inverter is that different sources disagree or go stale:

  • Derived PV: load – grid – battery_bus
  • MPPT1/2 power from 0x1400
  • 150F window (u/10 scaled) as another PV candidate

The script adds a “consistency layer” that:

  1. Starts with derived PV as a baseline
  2. Defines a tolerance band using substitutions:
pv_consistency_w: "80"        # absolute tolerance in W
pv_consistency_frac: "0.25"   # fractional tolerance vs derived PV
pv_headroom_w: "120"          # slack over Load+charge for rounding/noise
  1. Checks each candidate (MPPT sum, 150F) against:
  • Difference from derived PV (tol_abs / tol_frac)
  • Physical ceiling: load + discharge + pv_headroom_w
  • Non-negative
  1. Prefers candidates in this order:
  • MPPT (if fresh and within the window)
  • 150F (if fresh, sane range, and consistent)
  • Otherwise stays with derived PV
  1. Adds night-time behaviour:
  • When it’s clearly night and we’re still on derived PV, PV is forced to 0 W
  • A small PV floor is configurable so tiny noise doesn’t show as phantom PV

Result: PV doesn’t randomly jump or show “ghost solar” at night.


Grid lockout with SoC hysteresis

On top of that, there’s a simple grid lockout with hysteresis and PV coverage check:

Substitutions:

soc_unlock_pct: "16.0"   # below -> allow grid import
soc_relock_pct: "18.0"   # above -> re-lock (self mode)
pv_lock_margin_w: "50.0" # require PV >= Load - margin to lock grid

Logic:

  • A small internal state (grid_lock_active) flips when:
    • SoC drops below soc_unlock_pct → allow grid import
    • SoC climbs back above soc_relock_pct → re-enable lock
  • Even when locked, we only clamp grid to 0 W if:
    • It’s daytime (based on a day/night hint)
    • Battery power is within a safe range (below a clamp threshold)
    • PV is actually covering the load (PV ≥ load - pv_lock_margin_w)

If those conditions aren’t met, grid power is allowed to go positive so the house doesn’t go dark or cook the battery.


User-tunable controls (numbers, selects, switches)

I’ve exposed the main tunables as ESPHome number, select, and switch entities so you don’t have to recompile to tweak behaviour.

Numbers

  • Ibat Scale K
    Used when using register 0x2008 for battery current; this scales the raw value into real amps, considering pack count.
  • Grid Deadband (W)
    Anything below this magnitude is treated as 0 W to avoid grid noise around zero.
  • Battery Clamp Threshold (W)
    Maximum comfortable battery power magnitude (discharge) before we stop assuming “grid ≈ 0” in the PV derivation.
  • PV Floor (W)
    Minimum PV power before we allow non-zero PV when using derived values, mainly to clean up low-noise at night/edges.

Selects

  • Ibat Source – choose which battery current register to trust:
    • Auto (prefers 0x2008 when present, else 0x200D)
    • 0x2008
    • 0x200D
  • PV Mode – how strict we are with MPPTs:
    • AnyPresent – if either MPPT1 or MPPT2 looks sane, we can use the sum
    • BothRequired – insist on having both MPPT channels valid

Switch

  • PV Derive: Assume Grid~0
    For testing or specific scenarios: forces the PV derivation to treat grid as ~0 W (or use last good cached grid as a hint). Handy when you know grid import should be minimal.

Day/night hint & MPPT “hammering”

There’s a small support layer that decides day vs night and keeps MPPT fresh:

  • A 30s interval task:
    • Uses SNTP time to treat 06:00–20:00 as a day window
    • Also looks at recent MPPT values; if they’re non-zero and fresh, it nudges the hint to “day” even outside the simple time window
  • Another task runs every 12s during the day:
    • Sends extra reads to the 0x1400 MPPT window (function 0x03 and 0x04) to “hammer” it and keep those numbers alive

On boot, there’s also a hammer_mppt script that runs a quick burst of MPPT reads once we’ve seen a valid load value. This helps populate sensors as soon as possible after a restart.


Home Assistant entities you get

Some of the key sensors exposed to Home Assistant:

Instantaneous:

  • Battery SoC (%)
  • Battery Power (-dis) (W, negative means discharge)
  • Load Power (W)
  • PV Power (W, after consistency logic)
  • Grid Power (W, positive import / negative export)
  • Battery Voltage (V, internal)
  • Battery Current (A, internal)
  • PV Source Status (text: tells you which PV source is being used and current PV W)
  • Frames OK, CRC Errors, Exception Frames, Last Frame Age for debugging the BLE/Modbus layer

Energy (for the Energy dashboard):

  • PV Energy (kWh)
  • Grid Import Energy (kWh)
  • Grid Export Energy (kWh)
  • Load Energy (kWh)
  • Battery Charge Energy (kWh)
  • Battery Discharge Energy (kWh)

These are all sensor.integration entities using trapezoid integration and converted from W·h to kWh with a simple *0.001 filter.

1 Like

I’ve just got my Duracell Inverter and Battery. Turns out they are basically the same as the Skyline inverter. So I used this integration, and followed the instructions to wire it all up: GitHub - iPeel/HA-Skyline: Skyline integration for Home Assistant

Works like a charm.

Hi,
Just had a Duracell Dura-i inverter and battery installed and want to integrate into HA for monitoring following in your footsteps.
In trying to plan the best hardware setup and routing for cabling, can you say whether the integration is able to talk through USB x RS485 Modbus adapter? In my case it would be much easier running a cable from the inverter to a USB x RS485 adapter at the server end as opposed to going to the adapter mentioned in the document and then on to the server. I’m asking you as not able to identify the creator of the integration.
Kind regards

Wonder if you can share what you’ve installed please as I’m in the same position with the inverter of a dura-i.

I’ve installed HAHome to the ESP32 can see all the BLE devices but they are not auto discovering, but also don’t have any idea what integration you’re running for this so if you could share that would be fab.

Thanks

Hi David - wonder if you can assist, I’ve a duracell Dura5 G3 model, is this what you have? I’ve also had a look at the skyline integration and connected up the Tx and Rx + GND but get nothing through, is your RS485 port a 4 or 10 pin port? struggling to get this into HA and the duracell app is well , rubbish

I’ve finally moved forward and installed the Peel Skyline Integration as described above. Works like a charm as previously stated by David. The only downside that’s bugging me is that it identifies as a ‘cyg Skyline’ inverter BUT the Dura-i model number is correct.

Hi Gitano

Can you advise what you’ve used settings wise and how you’ve managed this as I would love to get this setup. What inverter you using? a G1 or G3?

Thanks in advance.

Any chance you can share what you’ve done gitano, as I’ve completed the same as yourself but get nothing? do you have a g1 or g3 inverter, mine is a g3 and really need to get this up and running.

Is there anything to add on what’s in the installation guide if the integration? I have been trying to follow but getting blank on the ACT light with nothing from the inverter, any tips?