V9261F Miscalculated Sensors

[Kaan88]

Device

wemos-d1mini

Version

espurna-github20220816

Bug description

Ever since I got V9261F working I noticed that Reactive, Apparent and Power Factor values made no sense at all.

So I messed around in V9261FSensor.h and tried to match it with CSE7766Sensor.h, hoping that that one was actually working.

This is how it was before:

And now against my custom HA sensors (took inspiration for the sensors from here esphome :

So calculations seem to be exactly the same and this issue is fixed.

I don't know coding, I just messed around and copied stuff until it compiled. I couldn't even create a pretty diff.

Btw, Energy calculation doesn't work either. It should be far more than 0.003.

84c84
<             _serial->begin(V9261F_BAUDRATE);
---
>             _serial->begin(V9261F_BAUDRATE, SWSERIAL_8O1); //I get no sensor values without this addition
125,126c125,126
<             if (index == 4) return _apparent;
<             if (index == 5) return _apparent > 0 ? 100 * _active / _apparent : 100;
---
>             if (index == 4) return _voltage * _current; //from cse7766
>             if (index == 5) return ((_voltage > 0) && (_current > 0)) ? 100 * _active / _voltage / _current : 100; //from cse7766
261,262c261,270
<                     _apparent = fs_sqrt(_reactive * _reactive + _active * _active);
< 
---
>                     // Calculate reactive power ---- from cse7766
>                     _reactive = 0;
>                     unsigned int active = _active;
>                     unsigned int apparent = _voltage * _current;
>                     if (apparent > active) {
>                         _reactive = sqrt(apparent * apparent - active * active);
>                     } else {
>                         _reactive = 0;
>                     }
>                     
334d341
< 

Steps to reproduce

No response

Build tools used

PlatformIO Core 6.1.5
Python 3.10.5-final.0
System Type windows_amd64
Platform Windows-10
File System Encoding utf-8
Locale Encoding cp1252
PlatformIO Core Directory C:\Users\kaank.platformio
PlatformIO Core Executable C:\Users\kaank.platformio\penv\Scripts\platformio.exe
Python Executable C:\Users\kaank.platformio\penv\Scripts\python.exe
Global Libraries 0
Development Platforms 1
Tools & Toolchains 5

Any relevant log output (when available)

No response

Decoded stack trace (when available)

No response

[mcspr]

We get that raw apparent power value from the buffer while reading everything else, is it always providing garbage values like that?
Reframing calc and using volt and current instead of sqrt of 'triangle' sides makes sense too, just wonder why v9261f makes it so (or we have some misunderstanding about the payload of data[] in lines above your patch)

[Kaan88]

We get that raw apparent power value from the buffer while reading everything else, is it always providing garbage values like that?

Yes, apparent and factor reactive always had the same garbage values and factor was either 100% or 0%.

[mcspr]

s/apparent/reactive/ for data buffer, I meant that apparent and factor are derived from it :>
and I don't see anything special mentioned in datasheet.

what raw data looks like btw? DEBUG_MSG_P(PSTR("v9261 -> %s\n"), hexEncode(_data).c_str()); somewhere in that block setting all the values should periodically dump it in our logs (e.g. like it is done in 1c95531)

[Kaan88]

I meant that apparent and reactive always showed the same value on the webpage, not factor. Sorry about that. So it doesn't seem like any calculation was being done for apparent.

Anyway, here are some raw values:

[019310] v9261 -> FE11046F22420067F6BBFF90837F3870F83F01C300000000
[020265] v9261 -> FE11040A8341005A09BCFF40E57D38D0D13D017A00000000
[021233] v9261 -> FE11040A8341005A09BCFF40E57D38D0D13D017A00000000
[022177] v9261 -> FE11044BDC410046F6BBFFA0158538D0353E010B00000000
[023136] v9261 -> FE1104A461420032E4BBFFC0088638707E3F015400000000
[024102] v9261 -> FE11046043420094E1BBFFD0058338005E4001DC00000000
[025047] v9261 -> FE11046043420094E1BBFFD0058338005E4001DC00000000
[026014] v9261 -> FE11041BA9410060D8BBFFA0489438B0C83D01BE00000000
[026976] v9261 -> FE1104AC124200EDD4BBFF801E8D3890EB3E018700000000
[027917] v9261 -> FE1104973742006CB1BBFFB093993850613F013300000000
[028866] v9261 -> FE1104973742006CB1BBFFB093993850613F013300000000
[029845] v9261 -> FE1104450F4200CDBDBBFFF0F69638E0823F01EF00000000
[030778] v9261 -> FE11046693410035DEBBFFC0AF9438C0833D015C00000000
[031754] v9261 -> FE1104AEE5410027D3BBFFA0BC9538A0263E016900000000
[032704] v9261 -> FE1104AEE5410027D3BBFFA0BC9538A0263E016900000000
[033665] v9261 -> FE11041083420098B8BBFFD0519638801940017700000000
[034607] v9261 -> FE1104F01D4200EFCEBBFF7087953880D63F01FF00000000
[035577] v9261 -> FE1104B183410052C5BBFF60269C38A0923D010F00000000
[036521] v9261 -> FE1104B183410052C5BBFF60269C38A0923D010F00000000
[037481] v9261 -> FE110400C34100B3C5BBFFB0D19C3800253E013000000000
[038430] v9261 -> FE1104DC3842008E0BBCFF70C57C38B0433F015900000000
[039392] v9261 -> FE1104AFFE4100401EBCFF20607338503F3E011F00000000
[040353] v9261 -> FE1104AFFE4100401EBCFF20607338503F3E011F00000000
[041303] v9261 -> FE1104FD9D4100FE09BCFFA0CB7838C0E03C018A00000000
[042263] v9261 -> FE11049A404300FEC5BBFF102B8A3830294101ED00000000
[043222] v9261 -> FE1104916F42007FE2BBFF705B8138D0313F01FD00000000
[044168] v9261 -> FE1104916F42007FE2BBFF705B8138D0313F01FD00000000
[045146] v9261 -> FE1104D4C641004118BCFF60B28C38B0EF3E017C00000000
[046097] v9261 -> FE110408594100C212BDFF30AA063820423D013500000000
[047045] v9261 -> FE1104CACC4100030DBDFFA071FF3780773E01FF00000000
[048000] v9261 -> FE1104CACC4100030DBDFFA071FF3780773E01FF00000000
[048953] v9261 -> FE1104713542000B04BDFF406FFE37E0E53F018300000000
[049914] v9261 -> FE1104C5E441004B04BDFF20040138909D3F016000000000
[050882] v9261 -> FE110425F2420069C1BCFF20670C38C05E4101B600000000
[051819] v9261 -> FE110425F2420069C1BCFF20670C38C05E4101B600000000

[mcspr]

diff --git a/code/espurna/sensor.cpp b/code/espurna/sensor.cpp
index 93bf7668..f74e82fc 100644
--- a/code/espurna/sensor.cpp
+++ b/code/espurna/sensor.cpp
@@ -1329,6 +1329,7 @@ constexpr bool ratio_supported(unsigned char type) {
     return (type == MAGNITUDE_CURRENT)
         || (type == MAGNITUDE_VOLTAGE)
         || (type == MAGNITUDE_POWER_ACTIVE)
+        || (type == MAGNITUDE_POWER_REACTIVE)
         || (type == MAGNITUDE_ENERGY);
 }

Ratio calc is ignored here, so instead of dividing by (default) ratio value it divides by 1.0

espurna/code/espurna/sensors/V9261FSensor.h

Line 205 in 1169be2

) / _power_reactive_ratio;

espurna/code/espurna/sensors/BaseEmonSensor.h

Lines 137 to 138 in 1169be2

	// Generic ratio configuration, default is a no-op and must be implemented by the sensor class
	static constexpr double DefaultRatio { 1.0 };

espurna/code/espurna/sensor.cpp

Line 4007 in 1169be2

if (isEmon(magnitude.sensor) && magnitude::traits::ratio_supported(magnitude.type)) {

espurna/code/espurna/config/sensors.h

Lines 1171 to 1175 in 1169be2

	// Default ratios
	#define V9261F_CURRENT_FACTOR 79371434.0
	#define V9261F_VOLTAGE_FACTOR 4160651.0
	#define V9261F_POWER_FACTOR 153699.0
	#define V9261F_RPOWER_FACTOR V9261F_CURRENT_FACTOR

[Kaan88]

diff --git a/code/espurna/sensor.cpp b/code/espurna/sensor.cpp
index 93bf7668..f74e82fc 100644
--- a/code/espurna/sensor.cpp
+++ b/code/espurna/sensor.cpp
@@ -1329,6 +1329,7 @@ constexpr bool ratio_supported(unsigned char type) {
     return (type == MAGNITUDE_CURRENT)
         || (type == MAGNITUDE_VOLTAGE)
         || (type == MAGNITUDE_POWER_ACTIVE)
+        || (type == MAGNITUDE_POWER_REACTIVE)
         || (type == MAGNITUDE_ENERGY);
 }

Reverted my changes and added that line, but now I'm getting this error and the values are still the same. (LED lamp)

Now there is Reactive Energy ratio on this page, (Energhy disappeared)

[mcspr]

UI does not expect anything but these four, reactive power would be ...-pwrModS but there is no elem with that class

espurna/code/html/index.html

Lines 2371 to 2374 in 1169be2

	<span class="pure-form-message-inline emon-expected-pwrP">In Watts (W). Calibrate your sensor connecting a pure resistive load (like a bulb) and enter here its nominal power or use a multimeter.</span>
	<span class="pure-form-message-inline emon-expected-volt">In Volts (V). Enter your the nominal AC voltage for your household or facility, or use multimeter to get this value.</span>
	<span class="pure-form-message-inline emon-expected-curr">In Amperes (A). If you are using a pure resistive load like a bulb, this will be the ratio between the two previous values, i.e. power / voltage. You can also use a current clamp around one of the power wires to get this value.</span>
	<span class="pure-form-message-inline emon-expected-ene"></span>

espurna/code/html/custom.js

Lines 1864 to 1867 in 1169be2

	const expectedClass = `emon-expected-${info.prefix}`;
	const root = template.children[0];
	root.classList.add(`show-${expectedClass}`);

espurna/code/html/custom.js

Lines 1881 to 1885 in 1169be2

	const hint_shown = container.querySelector(`.show-${expectedClass}`);
	if (hint_shown === null) {
	const hint = template.querySelector(`.${expectedClass}`);
	hint.style.display = "block";
	}

Quick edit is to just inject another <span> like the energy one, proper fix would be to stop .js from trying to access elems and inject style and / or css var instead

[mcspr]

...does not seem to really make sense to add extra reactive ratio, though.

Will bundle original patch instead, also with some fixes related to pointless _serial->flush() calls when we never write anything and the ones we expect it to flush input buffer instead, looping on available() and causing soft wdt triggers