Negative power factor with Shelly EM

Hi, any news about this. Any comment or recommendation from Shelly ?

Thanks !

Same problem hereā€¦ when starting the car charging with OpenEVSE, the circuit starts showing negative values (power factor negative):

Shelly EM3 with firmware: 20220324-123835/v1.11.8-3EM-fix-g0014dcb

With less Voltage:

If you donā€™t mind sharing, how do I duplicate this API call? I too want to open a ticket with Shelly on this. I can use postman or whatever I just didnā€™t make any progress trying to find some kind of API documentation.

Rubber Duck debug, as typical I found my answer myself only after asking.
https://shelly-api-docs.shelly.cloud/gen1/#shelly-em-settings-emeter-index

basically GET http://ip-address/status

Thanks!

Or just visit this address in a web browser:

http://<shelly_ip_address>/status

It seems like a workaround has been added in 2022.10.5

1 Like

The integration has been modified to remove the negative sign on the Shelly Power Factor value, this made the results totally wrong.

Itā€™s clear that most if not all commentators donā€™t understand Power Factor because if they did they would not have supported changing the integration.

The change that introduced abs(Power Factor) needs reversing.

Power is calculated with Voltage x Current x PF

Itā€™s clear from the examples above that some people are not understanding the electrical engineering subjects that have given rise to this incorrect change.

What would a negative power factor indicate? Negative (i.e. generated) power? Iā€™m pretty sure thatā€™s not whatā€™s happening.

Neither one of RMS voltage and RMS current can be negative.

A negative Power Factor either indicates energy export from a Solar or Wind generation system, or when loads are light perhaps a TV or LED lighting they present negative PF values.

The Shelly 3EM is reporting the correct values and PF ranges from -1 to +1 and canā€™t be converted into an absolute value, this is why the values are now incorrect.

It is not unusual for PF to swing from a negative to positive value frequently as load types or load distribution varies, itā€™s all quite normal, but much misunderstood.

Voltage and current values are always positive the value of PF converts the readings to real power rather than Apparent Power.
So VxA = Apparent Power
V x A x PF = Real Power

Why would the device report positive real power and negative power factor? (See Tomā€™s screenshot from the API report).
And why would it always show positive power factor in itā€™s official web interface?

You can see from Tomā€™s graph that his system is clearly generating solar energy and the PF is negative indicating an export, then after sunset the PF gives positive again, exactly as it should do.
The problem is people donā€™t understand Power Factors and they assume any negative value must be a fault, but itā€™s not.
My system was working perfectly and as soon as this updated integration was implemented everything went wrong. Then I discovered the change made was to return the absolute value of PF - thatā€™s just wrongā€¦

I donā€™t see that in neither one of Tomā€™s graphs.

Additionally, this API response contains contradicting information, right?
Screenshot 2022-03-26 at 12-03-04 Screenshot
How could [real] power be positive when power factor is negative?

Iā€™m not necessarily saying that the new code is right, Iā€™m just pointing out that there likely is a bug in the Shelly firmware.
If you want to get the patch reverted, you should raise an issue on Github and include your explanation of why the new code is wrong. I see you have already done that :+1:

Tomā€™s house load is normally negative because he presumably has a lot of leading PF loads, this is not unusual and you can see that the much increased negative PF diminishes around sunset and then starts to go negative again at about 0800 as the Solar starts to export again after sunrise.
Yes Iā€™ve reported the integration is now wrong on GitHub.

Leading PF (capacitive load) does not generate any real power.
PF should still be positive, itā€™ll just be less then 1.
-pi/2 < phi < 0
0 < cos(phi) = PF < 1

Incorrect, the total load is a mix of 12.88 real power and -93.52 apparent power and therefore the PF is 12.88/-93.52 giving a PF of -0.14

The real power element is just 13W and in a typical load situation at very low powers these are the results to be expected.

The total load is a mix of 12.83 W real power and -93.52 var reactive power, thus giving sqrt(12.83^2 + (-93.52)^2) = 94.396 VA apparent power.
Power factor is PF = 12.83 W / 94.396 VA = 0.136

But you donā€™t know the sign because you havenā€™t measured the phase angle and the Shelly did and reported -0.14.
You ignored the sign in your calculations so the vector maths is wrong.
The bottom line is the integration was correct, now itā€™s not.

So shelly is reporting abs(P) instead of P for real power?
P = -12.83 W
Q = -93.52 var
S = sqrt((-12.83 W)^2 + (-93.52 var)^2) = 94.396 VA
PF = -12.83 W / 94.396 VA = -0.136
12.83 watts of real power is generated.

So you sort of got to the correct result eventually, real power canā€™t be negative and Shelly does not report it as that.
If you think about the vectors the y-axis is the apparent power and the x-axis the real power.

So I knew that PF was negative for inductive loads (when voltage leads current, ā€œCIVILā€ mnemonic) but had not considered that its sign changes when exporting power.

I agree that the PR needs reverting.

The only issue is that the Shelly web interface is showing positive PF when it should be showing negative PF. The API (that home assistant uses) is correct. So itā€™s only a problem that Shelly needs to fix.

Shelly web Interface

a8cfa5f918f2873d06bcd0bb85a97b5533670dd7

API:

f821e684ff45d337d6602dcdf8da0c75a2d2832a

Home Assistant:

5efec1ab9502c956f838713e516f32440a5b8b61