Powercalc does not provide something like this. You could do something with HA automation probably. Where you create an automation to which sets an input boolean (input_boolean.kettle_activated) which you can use as input for powercalc virtual sensor. Maybe you can create a statistics helpers which collects the mean for 30 seconds of power sensors, and than compare that to the current power value, when it’s delta is higher than 1000W for example you set the input boolean on.
But I think it will be hard to get right. How do you know it’s not the fridge for example, washing machine or some other big consumer?
1 Like
This linear calibration feature is meant to convert a linear scale of light, fan etc to a power value.
It’s not purposed to calibrate an existing power sensor. It’s not something I’ll add to Powercalc.
You could achieve it using a template sensor.
Thank you so much for your reply; your advice is already pointing me in the right direction.
Your question is valid, but I think all the large appliances I own have their own specific energy footprint, which I can extrapolate: the consumption rate, the speed in seconds they reach their maximum consumption, the duration of energy consumption, instances of lower but still significant consumption followed by a new peak, etc.
The problem that comes to mind is how to clean up and track the delta from other consumption. I think I could do this by excluding all energy variations within a range considered to be “small appliances.” If there are multiple large appliances, it could be done with a script that takes into account whether there are two or more large appliances in the consumption, more kilowatts which is more than what is needed for a single appliance etc.
It needs some research, but I see a small chance of success.
For now, I’ll try the kettle; that’s easy.
I’ll figure out the rest if I’m successful.
seems latest update causes most of my entities not being picked up…
Deze fout is ontstaan door een aangepaste integratie.
Logger: custom_components.powercalc.power_profile.factory
Bron: custom_components/powercalc/power_profile/factory.py:67
integratie: Powercalc (documentatie, problemen)
Eerst voorgekomen: 10:26:18 (28 gebeurtenissen)
Laatst gelogd: 10:26:19
Problem loading model: Model Signify Netherlands B.V. Hue Ensis down not found
Problem loading model: Model Signify Netherlands B.V. Hue Aurelle Panel not found
Problem loading model: Model Signify Netherlands B.V. Hue Flourish table not found
Problem loading model: Model Signify Netherlands B.V. Hue outdoor post not found
Problem loading model: Model Google Inc. Google Home Mini not found
and
Deze fout is ontstaan door een aangepaste integratie.
Logger: custom_components.powercalc.sensors.power
Bron: custom_components/powercalc/sensors/power.py:205
integratie: Powercalc (documentatie, problemen)
Eerst voorgekomen: 10:26:18 (29 gebeurtenissen)
Laatst gelogd: 10:26:19
light.hue_ensis_down: Skipping sensor setup: Model not found in library (manufacturer: Signify Netherlands B.V., model: Hue Ensis down)
light.plafond_bijkeuken: Skipping sensor setup: Model not found in library (manufacturer: Signify Netherlands B.V., model: Hue Aurelle Panel)
light.flourish: Skipping sensor setup: Model not found in library (manufacturer: Signify Netherlands B.V., model: Hue Flourish table)
light.achterdeur_lamp: Skipping sensor setup: Model not found in library (manufacturer: Signify Netherlands B.V., model: Hue outdoor post)
media_player.googlehome_hal: Skipping sensor setup: Model not found in library (manufacturer: Google Inc., model: Google Home Mini)
there are more… rolling back for now.
quick & dirty issue Skipping sensor setup: Model not found in library · Issue #3765 · bramstroker/homeassistant-powercalc · GitHub
wait: 1.19.3 now also shows these errors… didnt I see that before, or is something else going on
no, can confirm 1.19.2 to bring back my entities.
Thanks for your response.
Actually I think the Compensation integration is a better fit.
Hi friends, hope everyone had a great Christmas!
I’ve just released Powercalc v1.20.0, which introduces optional, fully anonymous analytics.
If you’re using Powercalc and would like to help improve it, please consider enabling analytics. It helps me understand which devices and features are actually used in real setups, so I can focus development where it matters most.
The analytics are lightweight, completely anonymous, and contain no personal or identifiable data. The documentation explains exactly what data is collected and how you can enable or disable analytics:
Analytics - Powercalc documentation
Opting in is a small step, but it makes a real difference.
Thanks to everyone supporting Powercalc, this will help make it even better in the new year.
2 Likes
Hello everyone,
I’ve been using Powercalc for a while, and recently decided to create manual virtual power sensor for a few devices that aren’t in the library.
I’ve successfuly mapped the values of the fan speed of my air purifier to it’s consumption, using linear strategy, but here’s my problem :
I use the sensor “sensor.zhimi_mb5_175a_moto_speed_rpm” for my linear strategy, but the on/off state of the device is managed by the “fan.zhimi_mb5_175a_air_purifier” entity.
My current setup is not able to know when the purifier is off, and so the standby value is never applied.
Is there any simple way to fix this, or am I going to need to use a composite strategie ? (I would have prefer not to, but if I don’t have a choice)
You can try with calculation_enabled_condition. See Sensor configuration - Powercalc documentation.
The docs say it will calculate 0 when this property is false, but this is not the case it will look at the configured standby_power.
So you can use something like this: {{ is_state('fan.zhimi_mb5_175a_air_purifier', 'on') }}
Hope this helps.
1 Like
When I replaced the source for my three phase heater, where the target is a PowerCalc group, the group energy as reset to 0.
Initially the group consisted of three separate energy entities, while now my source is three devices (the old entries was made up from an ESP32 solution, now replaced with a Shelly 3-phase reader).
Is there any way that the reset can be un-done, ie by adding a static constant or likewise.
That’s perfect, thanks !
I have three questions :
-
If I want to submit a profile to the profile library, does every combination have to be tested ?
I’m currently measuring the Govee H61E1 lightstrip, and I have done the csv for hs and color_temp, but there is 306 effects listed for this lightstrip, the script estimates that it will take 23 hours with MEASURE_TIME_EFFECT=10 and SAMPLE_COUNT=1.
There’s no way I’m doing this. -
When first measuring the hs and color_temp, I put false for GZIP, and now I don’t have the .gz files, only the csv, how can I fix this, is there a script I can run ?
-
Last question, with most settings inside of the .env left to default, it takes more time to measure that I’ve read it should. I’ve seen that it’s supposed to take arround 2 hours with 2 pass
For me it takes around 2 hours for a single pass for hs, and 2 more hours for color_temp. Is this normal ? I’m using a Shelly Plug S Gen3 for the power monitoring
As always, this integration is awesome, I’m just starting to use it more in depth !
Effects support was added relatively recently, and only a small number of profiles currently include it.
If you omit effects, the consequence is that the power sensor will become unavailable whenever an effect is selected. That said, this is perfectly acceptable — several other lights with effect modes also don’t have effect lookup tables.
I’m completely fine with leaving effects out for now. They can always be added later by you or another contributor if needed.
I’ll also see if I can add a warning in the setup flow to make it clear to users that effects are not supported for certain profiles.
You can gzip it with this command (it’s available on most OS in the terminal):
gzip color_temp.csv. Or use some online tool.
Yes, this is completely expected.
In practice, 1–2 hours per color mode is normal. We need enough measurement points to build an accurate profile, and the default settings are intentionally conservative to balance accuracy and total measurement time.
It’s a one-time job, and once the profile is merged, both you and other users benefit from it long-term.
Hmm. I’m not certain about that approach.
These lights (such as Govee) are designed to create user effects. Such effects appear on the list of effects. And I can imagine that log users create own effects for Govee products.
Would it mean that every effect created by a user stops measuring self-energy? Cannot imagine that every user who creates their own light effect is able or willing to measure it.
I understand that there is no correct solution for this. Just thinking out loud, what is better: not record energy at all in such cases (a lot of cases) or record some defaults?
I’m aware that the best option is to use a smart socket that can measure such lamps.
At the moment, only 2 out of the 8 Govee profiles include effect support. These can be recognized by the magic wand icon in the color modes on the Powercalc library website:
So far, there haven’t been any reports from users about Govee power sensors becoming unavailable. That makes me think relatively few users actively use effects, and therefore only a small group would actually be impacted by a missing effect profile.
Ideally, effect measurements should be included for completeness. However, when measuring effects is not feasible for a contributor, I think it’s still very valuable to at least provide measurements for the most commonly used color modes. As long as it’s clearly communicated during setup that effect support is missing, users can make an informed choice to either proceed without effect support or ignore the discovered device.
These lights (such as Govee) are designed to create user effects. Such effects appear on the list of effects. And I can imagine that log users create own effects for Govee products.
Would it mean that every effect created by a user stops measuring self-energy? Cannot imagine that every user who creates their own light effect is able or willing to measure it.
Yes, custom effects will indeed cause the virtual power sensor to become unavailable, simply because Powercalc has no way to estimate the power usage of those effects.
@DevoliaEsp I also noticed that the other two Govee light strip profiles each list 12 effects, which appear to be the default ones. I’m not sure why you’re seeing 306 effects. I’m not a Govee user myself and don’t have much insight into that ecosystem, so I can’t really explain the discrepancy.
Help improve Powercalc analytics (almost 1,000 opt-ins!)
Powercalc analytics is getting some great traction, we’re close to 1,000 opt-ins already 
Thanks to everyone who has enabled it so far!
If you’re using Powercalc and haven’t opted in yet, I’d like to invite you to join.
The analytics data helps me (and the community) get better insights into things like:
- Adoption per manufacturer and model
- Sensor and profile usage
- Real-world configuration patterns
- Where improvements and new profiles matter most
All data is anonymous and only used in aggregate.
To give you an idea of what this enables, I’ve built several public dashboards you can check out here:
analytics insights
If you like what you see and want to contribute, enabling analytics is a small effort that makes a big difference. Every extra installation improves the quality and usefulness of the insights.
Thanks for helping make Powercalc better for everyone! 
I tried setting up powercalc to group a few emporia panel clamps. My dryer has two legs, A & B. I made a powercalc group:
However, looking at the energy dashboard, the daily energy values for the group are exactly double the values from the individual devices. This has remained the case across multiple other groups and different days. The instant power readings are accurate however.
Is there a different way I should be setting up these groups? Thanks!
I would suggest to first check which actual individual sensors are included in the group. Get Group Entities - Powercalc documentation
1 Like
Thank you for pointing me in the right direction! Looks like it was including the monthly sums along with the daily sums. I moved away from including the devices, and am using just the entities instead which seems to have solved the issue.
Glad you got it resolved. You should have a close look in Energy today though, when this is an energy sensor which resets daily this will cause an issue with the powercalc group, as it expects energy sensors which increase indefinitely.
Don’t you have a total energy sensor from the Emporia?
Emporia only exposes daily and monthly energy, along with power. I’ll keep an eye on it. I suspect it should work, since the last few days it was perfectly accurate other than being exactly double which is explained by it summing the daily and monthly. This is only for displaying in the energy dashboard too.
1 Like