Aussie summer heat and batteries don’t mix, but there may be an internal temperature sensor in the nRF52840 that the firmware uses to throttle down the processor for self preservation.
Alternatively the heat may be expanding your meter box door and letting in too much light in the gap, swamping out the pulse detector diode.
The one that seemed to work with the previous fixes applied to @muneeb1990 version is now also broken.
The latest ESPHome version 2026.2.1 refuses to compile now in either Arduino or ESPIDF with the missing WiFi.h error, flagged a long time ago, and overlooked, as the Arduino code seemed to work previously. Now it doesn’t so the offending line 4 in powerpal_ble.cpp that reads
#include "WiFi.h"
should go.
This was the one that was working until the new version of ESPHome tightened the Arduino compile parameters and it is now broken.
I noticed in the above post that IOT7712 mentioned that esp 2026.02.1 doesn’t compile.
I am running the version which gurrier created, but i haven’t updated it to the latest ESPHome version as I didn’t want issues
I know that the original issue was with muneeb1990 version, but was wonder if any other versions are still affected.
Now I think about it, I am probably onto my fourth folk/version of the powerpal esp since I put it in back in May 2022. (also probably onto my fourth ESP board, since I used to get dropouts a lot)
Heads up, looks like code doesn’t compile under ESPHome 2026.3.0 using GitHub - gurrier/esphome-powerpal_ble · GitHub
Compiling .pioenvs/esphome-gateway-b65314/src/esphome/components/script/script.cpp.o
src/esphome/components/powerpal_ble/powerpal_ble.cpp: In member function 'virtual void esphome::powerpal_ble::Powerpal::setup()':
src/esphome/components/powerpal_ble/powerpal_ble.cpp:148:27: error: 'class esphome::sensor::Sensor' has no member named 'set_device_class'; did you mean 'get_device_class'?
148 | this->energy_sensor_->set_device_class("energy");
| ^~~~~~~~~~~~~~~~
| get_device_class
src/esphome/components/powerpal_ble/powerpal_ble.cpp:150:27: error: 'class esphome::sensor::Sensor' has no member named 'set_unit_of_measurement'; did you mean 'get_unit_of_measurement'?
150 | this->energy_sensor_->set_unit_of_measurement("kWh");
| ^~~~~~~~~~~~~~~~~~~~~~~
| get_unit_of_measurement
src/esphome/components/powerpal_ble/powerpal_ble.cpp:153:33: error: 'class esphome::sensor::Sensor' has no member named 'set_device_class'; did you mean 'get_device_class'?
153 | this->daily_energy_sensor_->set_device_class("energy");
| ^~~~~~~~~~~~~~~~
| get_device_class
src/esphome/components/powerpal_ble/powerpal_ble.cpp:155:33: error: 'class esphome::sensor::Sensor' has no member named 'set_unit_of_measurement'; did you mean 'get_unit_of_measurement'?
155 | this->daily_energy_sensor_->set_unit_of_measurement("kWh");
| ^~~~~~~~~~~~~~~~~~~~~~~
| get_unit_of_measurement
Compiling .pioenvs/esphome-gateway-b65314/src/esphome/components/sensor/automation.cpp.o
*** [.pioenvs/esphome-gateway-b65314/src/esphome/components/powerpal_ble/powerpal_ble.cpp.o] Error 1
Have you reported it on GitHub? Maybe @tmugan may wish to chip in on what yaml code still works with PowerPal and ESPHome?
Just went to lodge it on GH, looks like a fix has already been implemented:
Nice!
Yes, that update seems to be working now.
Hopelessly confused with all these variations floating around and most not compiling any more.
Can you please post the contents of your flavor-of-the-month yaml, the one that is apparently working.
use the main branch for latest builds. 1.3 is giving the same compile errors.
external_components:
- source:
type: git
url: https://github.com/gurrier/esphome-powerpal_ble.git
ref: "main"
components: [ powerpal_ble ]
Hello all,
a big thanks to WeekendWarrior1 for the Powerpal BLE github repository. What a legend!
Long time lurker, first time poster here - please be gentle!
Using this the amazing WeekendWarrior code as inspiration, I've managed to get updates every minute - and set myself the challenge getting near live updates using the pulse characteristic.
Using the 59DA0003 UUID I had sort of got it working - albeit I was getting some occasional dodgy readings due to a too frequent samples...
I've been refining the code, and it's now stopped working all together. My question:
has anyone made any progress on getting near live updates from PowerPal - in line with what the app on the phone does?
This is the characteristic i'm using...
static BLEUUID POWERPAL_CHARACTERISTIC_PULSE_UUID("59DA0003-12F4-25A6-7D4F-55961DCE4205");
Hey I just spent some time with ChatGPT to throw together a basic integration. I know very little about Home Assistant so any feedback would be appreciated. It requires a BT adapter and directly connects to the device.
Exposes Daily Energy, Power and Total Energy sensors.
I've got it working with live power usage:
It's disabled by default for now, because I don't know what impact it'll have on the Powerpal's battery to have it enabled 24/7. I'm going to leave it running for a few days on my setup and see what happens.
I am keen to use your version - is it safe to do so now?
I've been happy with it. I haven't noticed any kind of sharp drop in the battery status, it hovers between 95-96% for me. Maybe a little more time on 95% in the last few days, indicating a little bit of a drop over the past week, but presumably less than 0.5%. Could also be related to the cold weather this week making the battery a little less efficient.
I've just pushed a change to enable the live power updates by default, it can still be disabled by defining live_power: false in the ESPHome device config.
As a side note, I like how the PowerPal app shows your current power usage in $, so I made a couple of sensors to duplicate it: configure energy_cost with whatever your plan's times and prices are, then use estimated_power_cost in a dashboard somewhere you want to see live price updates.
template:
- trigger:
- platform: time
at: "10:00:00"
- platform: time
at: "15:00:00"
- platform: homeassistant
event: start
sensor:
- name: "Energy Cost"
unique_id: energy_cost
unit_of_measurement: "AUD/kWh"
state: >
{% set h = now().hour %}
{{ 0.1335 if 10 <= h < 15 else 0.3885 }}
- sensor:
- name: "Estimated Power Cost"
unique_id: estimated_power_cost
unit_of_measurement: "AUD/h"
icon: mdi:cash-clock
availability: >
{{ has_value('sensor.powerpal_power')
and has_value('sensor.energy_cost') }}
state: >
{{ ((states('sensor.powerpal_power') | float(0)) / 1000
* (states('sensor.energy_cost') | float(0))) | round(2) }}
I have also been very happy with how this is working.. The biggest issue was getting the hardware up and running which I got working after I realised the manufactures instructions are totally out of date.. Unfortunately if you restart the daily usage is reset (only for the device) as HA is still correct. HA Energy consumption often lags behind the energy consumption being captured by PowerPal so watch out for that, it can be up to two hours behind PowerPal.. Overall why PowerPal could not have made this standard I don’t get.. Really short sighted of them
How do you deal with the daily network supply charges?
Good to hear that it’s useful!
I went back and forth a bit over the daily supply charges - I can certainly see it being useful if you want to keep exact track of expenses, but it doesn’t fit into the Energy dashboard all that well. Here’s a topic where people have come up with different solutions:
Yeah I seen the replies (thanks for link) it looks like a creative attempts to work around the limitation around the way ha tracks energy.. On a site note I cannot believe how accurate the HA / Powerpal measurements are..
Version 1.4 just released to “main” with a number of optimisations.
Keen for feedback.