Manually calculating power consumption of lights

I see one sensor is not setup correctly:
2021-06-07 19:36:26 ERROR (MainThread) [custom_components.huepower.sensor] Light not supported: ('No lookup file found for mode', 'color_temp'). Need to have a look into that.

The other sensors should be created correctly. I also see it is looking up the power consumption correctly. If the sensor was not created this should not happen.
Could you check in Configuration->Entities if you see some sensor entities there.
The naming should be the light entity name postfixed with _power. So in your example the sensor for light.bedroom_ceiling_light should be sensor.bedroom_ceiling_light_power

I think itā€™s the data files. The four LTW001s i have are in colour temp mode and thereā€™s a colour temp data file. The LCT012 only has a hs data file, but it has both hs and color_temp modes. Iā€™ve booted in both modes and the error still occurs. I had a quick look at the code and it loops through the modes - could this be the issue if thereā€™s not a corresponding data file for all modes?

and yeah, there are power sensors for the others, thanks!

Yes all the modes should have data files. I have asked @CM000n to create the data file for colour temperature, as I donā€™t have that bulb LCT012 myself. When he has created the data file than this light should also work.
Good to hear that the other sensors are working on you installation!

Hey @bramski,
I thought about tracking the energy consumption of my devices for a while and went on the search for a solution today, just to find that you are developing something as we speak. What are the chances!!! :heart_eyes:

I have a question for you. Why did you limit this integration to ā€œhuepowerā€?

I can see that a lot of effort went into the LUTs but with what you got it would be dead simple to mock the energy consumption of almost every device. switch, light, fan, you name it. Your integration could be called ā€œhomeassistant-powerā€ and would address 5 times more users :slight_smile:

I do not own hue lights but would be very interested to link dozens of simple switches and linearly dimmable lights to a power consumption. Thanks for considering this!!

1 Like

@ThomDietrich yes, I also thought abought this yesterday. You are right, this does not have to be limited to only hue lights. However I donā€™t have much time on hand next weeks to refactor the component name, but will definitely consider this.
Also thought about introducing another mode into the component, for example lineair where you can define a min and max watt for the device and it will calculate the power depending on the brightness selected. This estimation is good enough for most users and we donā€™t need lookup tables for all light models. lut would be the other mode.

Exactly. Sounds very promising to me. Just a quick scribble, happy to contribute where you would appreciate it:

- platform: power
  entity_id: light.simple_light_bulb
  power_off: 0  # optional, we can support it but not sure who would use it
  power_on: 15
- platform: power
  entity_id: switch.simple_heater
  wattage: 50  # wattage, power, power_100, power_max, or power_on ...
               # depending on the use case multiple versions would make this more intuitive
- platform: power
  entity_id: binary_sensor.boiler_running
  wattage: 50
- platform: power
  entity_id: light.simple_dimmable_light_bulb
  wattage: 50
  dimming: linear  # default for lights
- platform: power
  entity_id: fan.simple_ceiling_fan
  xxx:  # not sure how to represent, as many fans only have a number of discrete speeds

Further options to consider:

  • name - optional, for conformity
  • friendly_name - optional, for conformity
  • icon - optional, for conformity
  • manual_update_period - datetime, to store an update every x minutes, useful for graphing and databases and such

Yes I had someting similar in mind. Have to look at some other integrations and think about it some more to have some clear configuration schema. And also donā€™t make it to complex so it will become a maintenance issue.

I just started with some refactoring to support multiple strategies. See this PR.

think we need to support 3 different strategies for now:

  • lut this is the default, using lookup tables
  • linear you supply a min/max wattage
  • fixed can be used for devices which are only set on/off
- platform: power
  entity_id: light.simple_light_bulb
  mode: lut
- platform: power
  entity_id: binary_sensor.boiler_running
  mode: fixed
  wattage: 50
- platform: power
  entity_id: light.simple_dimmable_light_bulb
  mode: linear
  min_wattage: 1.5
  max_wattage: 50

Power usage in off state we can introduce as standby_usage, this can optionally be set and supported for every mode

overriding name is already implemented in current version
friendly_name and icon can be considered

manual_update_period I donā€™t see a need for this, as the power sensor is update realtime whenever the binded entity changes (ie the light bulb)

2 Likes

I did some major refactoring for the component to facilitate for other use cases. See the updated readme.

@ThomDietrich could you test in your installation if this is working as expected?

Will also update the naming of the component soon. Than the next step is to get it into HACS so users have the most easy installation.

And we need more LUT files, so if anyone can help with those that would be awesome.

Will test this evening :ok_hand:
HACS: great! is your long-term goal to contribute as an internal integration?

I had a look at the code.

  1. Why differentiate linear and fixed? Fixed is just a limited linear actor. See my examples above.
  2. Is mode mandatory? It can be derived from the given parameters. if manufacturer then mode=lut else mode=linear. Imho no need to bother the user
  3. min_usage feels ambiguous, didnā€™t you work with min_watt before?
  4. manual_update_period is not important now but it might become more interesting. We donā€™t have to discuss this just now. Imagine how the power signal of a simple light source will otherwise look in e.g. Grafana

Not sure if I want to have it a core integration. I am working on some other PR, but it takes a very long time and effort to get it integrated.
Also this component have the LUT files bundled. Pretty sure this is not acceptable for an internal integration, as all those files will be part of the home assistant source code. So this need to be a separate library/module or some other approach to download specific models. This will take lot of additional time and effort, so not on the short term.

  1. You mean by providing both min_watt and max_watt the same value? I also check if the device has a brightness level, and pass the brightness level to a formula to get the right watt depending on the ratio.
    The fixed strategy will make it clear that there is only a single value for when the device is ON, and the implementation is dead simple (a oneliner).
  2. mode is not mandatory. lut is the default mode. But I agree we can auto select another mode by looking at the provided configuration arguments (i.e. min_watt provided, mode is linear)
  3. Yes I agree min_watt is better. Will change this soon
  4. I understand what you mean now, this can be added for sure later on.

Internal integration: That has been my experience too. Understandable. Your lut files problem is another issue to consider, agreed.

Rest sounds good. We will get there!

Will test this evening

1 Like

I have updated the integration naming from huepower to powercalc to facilitate broader use cases.
@cloak and others which are using the alpha version of the component will need to update configuration.yaml to reflect this changes. This will be the final renaming so no need to do that again in the future.
Iā€™m going to further prepare things for HACS support so everyone who wants to use the component has en easy installation and upgrade procedure.
When everything is also working for @ThomDietrich I will tag the first beta version.

Hi @bramski,

here are my power measures for the color_temperature values of the LCT012 bulb:

Greetings

@CM000n Great. Thanks for your efforts. If you want you can create a PR to add it to the component repository.

1 Like

@bramski and @CM000n, Iā€™ve thrown the latest csv into my custom config folder and the power sensor that was erroring for one of my lights is all good now. Thanks very much for this!

1 Like

@bramski, Iā€™ve tried installing powercalc manually at first and then by importing it into HACS. Both installation methods result in the following. I donā€™t appear to be able to open the detailed logs.

Logger: homeassistant.components.automation.emulated_roku_automation_chooser
Source: components/automation/__init__.py:517
Integration: Automation (documentation, issues)
First occurred: 8:53:29 PM (1 occurrences)
Last logged: 8:53:29 PM

Error while executing automation automation.emulated_roku_automation_chooser: The system cannot restart because the configuration is not valid: Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found.

Logger: homeassistant.components.automation.emulated_roku_automation_chooser
Source: helpers/script.py:1341
Integration: Automation (documentation, issues)
First occurred: 8:53:29 PM (2 occurrences)
Last logged: 8:53:29 PM

Emulated Roku Automation Chooser: Choose at step 2: choice 3: Error executing script. Error for call_service at pos 1: The system cannot restart because the configuration is not valid: Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found.
Emulated Roku Automation Chooser: Error executing script. Error for choose at pos 2: The system cannot restart because the configuration is not valid: Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found.

Logger: homeassistant.components.hassio
Source: components/hassio/__init__.py:508
Integration: Home Assistant Supervisor (documentation, issues)
First occurred: 8:53:29 PM (1 occurrences)
Last logged: 8:53:29 PM

The system cannot restart because the configuration is not valid: Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found. Platform error sensor.powercalc - Integration 'powercalc' not found.
1 Like

I have nu clue. Will try to install the component in my own home assistent installation to see if I get the same error. It is working in my development installation

Installed the latest in HACS and all is working for my lights. I havenā€™t attempted the linear or fixed modes for other things yet, but sweet to see the component has a broader application than lights

1 Like

I did a lot more work on the component.

A few big features have been implemented.

  • Added support for switch, fan and binary_sensor entities as requested by @ThomDietrich
  • The directory with light manufacturer/model LUT files has been extended with a model.json containing more information about the given light. This also allows for defining the standby usage of the light and supporting additional modes (linear, fixed) from the model library besides lut mode.
  • Debug logging further improved
  • More intelligent mode selection. For example, when you supply a min_watt value, but no mode in the configuration than automatically linear mode will be selected.

Let me know if this new version works for you guys or if you experience any issues.

2 Likes

I have made a dedicated topic for the component where you can discuss the component and ask questions.

2 Likes