Please report missing energy signals (apparentpower, reactivepower, powerfactor)

[TurkeyMan]

Describe the bug
Device reports voltage, power, current, but it doesn't report apparentpower, reactivepower, powerfactor.
Please add reporting for those values.

If you think it's not something that most people would want, then put it behind a configuration flag?

Firmware:

• Version 1.17.464
• Chip/model: BK7231N
• Device: relay + energy meter
• Relay on channel 0 + BL0942

[openshwprojects]

#1092

[TurkeyMan]

Appears to be merged so I was going to close this issue, but I tested and it wasn't reporting.
Maybe there's a new option I didn't see or something like that?

[openshwprojects]

Try to redo hass Discovery

[stefan064]

More progress:
https://github.com/stefan064/OpenBK7231T_App/tree/refactor-energy-sensors


I found and included 2 additional past days energy were already being recorded. And some diagnostic sensors (via flag 2 'broadcast self state..')
I may have gotten carried away refactoring particularly in drv_bl_shared.c, and feel the need to give this a fairly thorough test. Keen on feedback too.

[TurkeyMan]

Repost here:

When I click "start home assistant discovery", it just shows a message "MQTT not running".
What is this actually supposed to do?
I'm not using homeassistant... what is the goal here, or what mechanism will make it start reporting these new topics?

[openshwprojects]

Well,you obviously need to configure mqtt first in order to use home assistant discovery

…

On Sun, Feb 25, 2024, 10:23 AM Manu Evans ***@***.***> wrote: Repost here: When I click "start home assistant discovery", it just shows a message "MQTT not running". What is this actually supposed to do? I'm not using homeassistant... what is the goal here, or what mechanism will make it start reporting these new topics? — Reply to this email directly, view it on GitHub <#1097 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUMGZ64VG4PFBZCMXLF5MHDYVL7HNAVCNFSM6AAAAABDOFCZFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRSHA3DQOBWGI> . You are receiving this because you commented.Message ID: ***@***.***>

[TurkeyMan]

I'm not sure what that means though? What is home assistant discovery?
What is it to "configure MQTT'? It seems configured to me... MQTT is working fine; it connects to my broker and reports on the topics that it should be at the rates I expect...?

[stefan064]

'Start home assistant discovery' causes the device to publish a group of messages under the mqqt topic /homeassitant. That's all, nothing more.
Home assistant uses these messages to automatically add the sensors i've been posting screenshots of. It just lets people easily set up devices in a reasonably automated manner without fiddling with manual configuration files. This is the majority of what i've been working on here, other than adding those extra power sensors to mqtt.

[TurkeyMan]

Okay. So when I say that the device isn't reporting on those topics, I mean it's not publishing to those new topics at all. It's nothing about home assistant. Should the latest version of the software be publishing those new topics regularly?
It could be that VCPPrecision and VCPPublishThreshold are not affecting those new topics you added, and so they're just not publishing any data.
I think for apparent and reactive power, they should probably use the same precision/threshold values given for power. Power factor might need a new precision/threshold value added to the end for those 2 commands?

[stefan064]

Actually you're right about power factor/reactive/active power, They're not released at this point, my previous #1092 didn't include them, only 'Energy Today' and 'Energy Yesterday'.
These new sensors are in my open PR #1102.
For VCPPrecision I made reactive power and apparent power use the same rounding as [active] power with power factor being fixed to 2 decimal places.
Same for VCPPublishThreshold with power factor fixed to 0.05.
These publishing thresholds were one of the motivations for refactoring a load of related stuff. Would be great if you could help test this and see if i've broken anything.

[stefan064]

Try flashing from the build output here, download at bottom of the page:
https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/8029772566?pr=1102

[TurkeyMan]

I'll have a look in the morning, but immediately, having a 5% granularity on power factor feels pretty course. That's a huge error margin.
Many of the devices I've seen recently advertise class 1 or even class 0.5 accuracy (that is, accurate to 1% or 0.5%). If I can't assign the reporting threshold, I'd like the default value not to truncate precision (ie, 0.005 default).

[TurkeyMan]

Okay, I tried it now. It's reporting these values. Something is definitely wrong though:

Info: MQTT - Received PUBLISH from : 96, obk125DAED5/power/get = 53.481636 (qos: 2)
Info: MQTT - Received PUBLISH from : 93, obk125DAED5/power_apparent/get = 30.415142 (qos: 2)
Info: MQTT - Received PUBLISH from : 94, obk125DAED5/power_reactive/get = 0.000000 (qos: 2)
Info: MQTT - Received PUBLISH from : 95, obk125DAED5/power_factor/get = 1.75 (qos: 2)

You can see here, power is greater than apparent power (impossible), and power factor is >1 (also impossible). Also fishy that reactive power is exactly 0.000000 to that level of precision. The hardware's not that precise, there should be at least some noise.
So, something seems very wrong here. Not sure if the hardware is reporting totally broken measurements, or perhaps the calibration implementation is broken?

Do you have a debug build where you can log the calibrated and uncalibrated values as a sanity check? Might reveal is the problem is hardware or calibration software...

Are these values reported as recorded from the hardware, or are they calculated locally?

[stefan064]

Thanks for trying it.
A few ideas:
What does the web UI show for those values? Do they look similar between release builds and my PR test build?
To be sure, have you calibrated all 3 points of your device?
They need voltageset, currentset and also powerset (i.e. active power). All three need doing and they each apply to 3 values provided by the hardware. The other sensors are derived from these. Any one of these un-calibrated can cause nonsensical reactive/apparent power and power factor like what yours shows.

The exact zeros are likely from some zero clamping happening in the calculations, in drv_bl_shared.c around line 500 (in my PR version).

[TurkeyMan]

Oh okay; I did voltageset and powerset. I can't easily do currentset, because I don't really have a good way to measure the current!
I can measure the voltage with a meter, and I know the power is 53W, because it's a 53W light bulb... I guess I can calculate the current assuming pf 1.0 and specify it without measuring it... but if that's acceptable, the software could just do the same thing...

I also realised that the frequency isn't reported either... do you mind also adding that one to the list?

[TurkeyMan]

I did currentset using a calculated value assuming pf 1.0, and the wonky values appear corrected now. Thanks for the tip!

So the outstanding issues as I see; i'd like to be able to set the pf sensitivity or threshold, or if not, at least set them to values such that they are not truncating data (0.5% is a good baseline, since there are some devices on the market which advertise accuracy class 0.5S). And can you add frequency too? I forgot this one before when I asked for the other items.

[giedriuslt]

0.5% is fantasy with such hardware. Tuya itself says 5% for bl0937 and 3% for bl0942.

[TurkeyMan]

I see heaps of devices listed on ali that say accuracy class 1, or accuracy class 0.5... I guess they're all full of shit! :)

[giedriuslt]

Never seen socket with such advertisment. There is Pzem devices for energy metering specifically, they are more believable, but still for me looks like they don't meet the spec.

[TurkeyMan]

No, certainly no socket; dedicated meter products often advertise this.

[stefan064]

I may see about adding frequency as a separate PR while I still have some understanding of how it all works. Not all devices report it however - BL0937 does not.
With accuracy etc, I think one particularly important constraint here is the mqtt library. I don't really understand the underlying cause but I see that publishing needs to be done quite conservatively and decisively to keep things from becoming unreliable. Especially if wifi is not reliable. This factored strongly for the values I used when adding these. VCPPublishIntervals can still give you higher reporting rates if you want to try that.