BL0937: Add voltage/current spike filter command (e.g. VCPSpikeFilter)

[cristianforgiarini]

Problem

BL0937-based plugs report occasional large voltage spikes (300–500V) that are
clearly false readings caused by electrical transients when the relay switches.
The actual grid voltage is stable at ~234V.

This has been confirmed by comparing the same BK7238 hardware flashed with
OpenBeken vs ESPHome — ESPHome shows clean readings (230–242V), OpenBeken
shows periodic spikes up to 500V.

What exists today

• VCPPublishThreshold reduces MQTT noise but does NOT filter spikes — a 400V
  spike still gets published since it exceeds the threshold.
• PowerSave 0 is already set, no improvement.
• Flag 25/26 are unrelated.

In an Elektroda forum post (topic3964717, post #20495199) the project author
mentioned "we have a setting to skip large power spikes, it's in the command
docs" — but this command does not appear in the current commands.md or
commands-extended.md.

Request

Add a command like VCPSpikeFilter <maxVoltage> <maxCurrent> <maxPower> that
discards any reading exceeding the specified threshold before publishing or
storing. Values above the threshold would be silently ignored (keeping the
last valid reading).

Example: VCPSpikeFilter 280 16 3600 would discard any voltage reading above
280V on a 230V grid.

Environment

• Chip: BK7238
• Firmware: OpenBeken 1.18.288
• Energy chip: BL0937

[divadiow]

maybe @openshwprojects was referring to PowerMax command in that thread

[DeDaMrAzR]

Also have in mind that those spikes can be, and most times are, a result of a bad power supply or a filter cap(s) within it - explained several times on elektroda forum.

[cristianforgiarini]

Thanks for the suggestions.
To clarify my situation:
PowerSave is not enabled in my startup config, so that's ruled out.
PowerMax only filters power readings — my spikes are on voltage, not power, so it doesn't help here.
The same physical hardware running ESPHome produces clean readings (230–242V, no spikes), which strongly suggests this is a firmware/driver issue rather than a hardware problem (bad caps, noisy power supply, etc.).
So the original request still stands: a VoltageMax and/or CurrentMax command equivalent to PowerMax would solve this cleanly. It would simply discard any reading above a configurable threshold before publishing.

[DeDaMrAzR]

PowerMax only filters power readings — my spikes are on voltage, not power, so it doesn't help here.

So voltage and current filter will help, interesting thing to investigate but super hard to replicate locally in order to debug it...

Have you tried latest builds as we have some issues with BL0937 readings - are any of the new builds producing the same error?

[NonPIayerCharacter]

A known problem for BK7238.
Disable logging completely, via "loglevel 0" command

[cristianforgiarini]

Tried loglevel 0 as suggested — spikes persist.
Here's a screenshot from Home Assistant history showing the voltage readings after disabling logging completely. The baseline is stable at ~229V but spikes appear regularly in both directions, reaching up to ~360V and dropping as low as ~190V.
Since the spikes occur in both directions and logging is disabled, this seems unrelated to CPU load or interrupt timing. The VoltageMax/VoltageMin filter request still stands.
(attaches screenshot)

[DeDaMrAzR]

And did you test it with latest release -1.18.295??

[cristianforgiarini]

Update after further testing:
Tried loglevel 0 and updated to 1.18.295 — both together seem to reduce the spikes significantly, but don't eliminate them completely.
Looking at the HA history graph, there's a clear difference before and after disabling logging at ~12:00 today: spikes were much more frequent and dense before, and noticeably less frequent after. So logging does contribute to the problem, but it's not the root cause.
The baseline remains stable at ~232V, but occasional spikes still reach up to ~600V after disabling logging.
A VoltageMax/VoltageMin filter command would still be the clean solution to discard these outliers before they get published to MQTT/HA.

[DeDaMrAzR]

#define BL0937_VOLTAGE_SPIKE_DELTA 30.0f //voltage delta
#define BL0937_VOLTAGE_SPIKE_CONFIRM_SAMPLES 2 //maybe 2 samples is too small??
//rest of drv_bl0937.c

//
static float last_valid_v = 0.0f;
static float pending_v = 0.0f;
static int pending_v_count = 0;
static int has_last_valid_v = 0;

if (has_last_valid_v && fabsf(final_v - last_valid_v) > BL0937_VOLTAGE_SPIKE_DELTA) {
    if (fabsf(final_v - pending_v) <= BL0937_VOLTAGE_SPIKE_DELTA) {
        pending_v_count++;
    } else {
        pending_v = final_v;
        pending_v_count = 1;
    }

    if (pending_v_count < BL0937_VOLTAGE_SPIKE_CONFIRM_SAMPLES) {
        final_v = last_valid_v;
    } else {
        last_valid_v = final_v;
        pending_v_count = 0;
    }
} else {
    last_valid_v = final_v;
    pending_v_count = 0;
}

//add this before 
#endif
	BL_ProcessUpdate(final_v, final_c, final_p, NAN, NAN);

...in theory and for voltage only, but do we gate it for 7238 or enable it on all BL0937 builds?

[cristianforgiarini]

Great implementation! The confirmation-based approach is much smarter than a simple threshold — it will filter out spurious spikes while still allowing real voltage changes to pass through.
Regarding whether to gate it for BK7238 only or enable it for all BL0937 builds: I can only speak from my own experience with BK7238, but I'd vote for enabling it on all BL0937 builds. The filter logic is harmless by design — it only discards readings that differ significantly from the last valid value without confirmation — so there's no downside to having it active on other chips too.