Closed Cougar closed 1 year ago
φ (cos-phi) ?
From electrical point of view, I fully agree. I can live with "p.f." as unit if a unit is required. Empty unit (space) is also fine but probably not consistent with all other measures.
My understanding is that in the HA the unit is even not bound with device class. For instance, if I create sensor like this:
- platform: mqtt
name: "POW voltage"
state_topic: "DVES_A0352E/tele/SENSOR"
value_template: "{{ value_json['ENERGY'].Voltage }}"
device_class: voltage
Then it will give a number without a unit and Lovelace shows state changes instead of graph.
It looks like that the unit needs to be configured in any case. In case of YAML, every user can (and must) choose their unit. In case of using web UI (config flow), the integration sets up device and its sensors with proper units. Only two of such sensors exist in the core right now.
If anyone really likes to see a range 0…100, it can be still easily achieved with template. In some cases power factor can be also negative but negative percentage is totally misleading IMHO.
@dgomes yes, "φ" is Greek letter phi and it denotes an angle. Wikipedia has good illustrations and describes what this angle means (there is no angle in electricity, this is for pure math for vector calculations).
@dannerph As long nothing breaks in HA, I would still propose to use " " as a unit to be correct. This can be easily modified with customizations anyway. I removed this unit (and changed the value to the right range) some times ago and don't see any problem with that.
Can we correct this before 1.0 or is it too late? The change itself is a really small (three lines (1, 2, 3) in core and one place in documentation). Edit: and here.
I understand that percent was proposed to pass test instead of fixing it… :)
@Cougar: How does the influxdb component behave if there is no unit or a unit of " "? In my keba integration the power factor is an attribute of the charging power sensor thus not a problem.
When unit is defined as space, it is also in InfluxDB with such name but when unit is empty then I don't see it in InfluxDB any more. This is also why I suggest to use "space" as a unit.
If a proper solution for https://github.com/home-assistant/architecture/discussions/503 is found I think we can use the power factor without unit.
If a proper solution for #503 is found I think we can use the power factor without unit.
Looks a good discussion. Lets hope that the outcome will be better than the current space hack. I can help with the PR when decision is made.
Meantime I have used space everywhere instead of wrong units. Looks ok in most places but even empty string as a unit would look much better in configuration files.
Frontend no longer has the limitation showing history graphs for sensors without a unit, and we can allow power factor sensor unit None
This is implemented by https://github.com/home-assistant/core/pull/85181
As this issue is otherwise resolved, I'll go ahead and close it.
Context
Power factor is a ratio of real power to apparent power. The value is in range -1.0 to 1.0. Right now the HA describes it with a percent (percent from what?).
The current range and unit idea came from discussion in #397. There was an issue that numbers need a unit (to display graphs correct way).
I have looked a lot of public configurations and wrote that in forum.
I have found from feedback and from configurations that there are very few users who care about power factor and they usually use correct range between -1.0 and 1.0. The workaround for a "percent" unit is to replace it with invented units like "cos(φ)" but the common one is to use a space as a unit (empty unit) and then it looks correct in Lovelace graphs too.
There are only two integrations in core where power factor is used: Shelly and Keba. Power factor values from Keba sensor are already in correct range.
Proposal
Consequences
This will be a breaking change. Users who has been used with percent, need to multiply the new value with 100. Users who like to see correct numbers and divided the value with 100 before (most likely only in case of Shelly), have to remove this division.
Shelly is the only integration that gives power factor in range -100…100 (or is it 0…100?) and needs to be changed in core code. I have a PR ready for that and for documentation change.
All other sensors that I have searched (like Tasmota, some Z-wave power sensors, Keba, OpenEnergyMonitor based projects) return correct power factor.
Only few exceptions are systems which don't support floating numbers in their wire protocols and then the user library or application to divide the number with 100 or 1000 (depending on the resolution).
Based on my research, it is very unlikely that anyone run any automation based on power factor.