openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601 and BL602
https://openbekeniot.github.io/webapp/devicesList.html
1.33k stars 226 forks source link

Emetering refactoring #1273

Open rpv-tomsk opened 1 week ago

rpv-tomsk commented 1 week ago

1) Added SaveState and PublishHASSDevices driver callbacks

 This allows implement other [metering] drivers which will use these callbacks.

2) Allow drivers to have different set of EnergySensors.

Multiple drivers might implement different set of EnergySensors, and we need a way to publish it into HASS.
Instead of DRV_GetEnergySensorNames() use in hass_init_energy_sensor_device_info(), we could pass sensor structure directly.
Function DRV_GetEnergySensorNames() removed completely.

3) Reimplement DRV_GetReading()

Multiple drivers might be used to get same Reading.
We need a way to get value from currently used active driver.
Solution: Driver should keep its 'readings' values in global array.

Enum `reading_e` and appropriate global array are introduced for DRV_GetReading().

Enum `energySensor_e` is local for `drv_bl_shared`-based drivers.
Please don't get confused. :)

Enum `energySensor_e` (local to drivers) might be subset of `reading_e`, and also could contain sensors, not available as Readings.
Other Drivers could be designed completely without `energySensor_e`-like enums.

I implemented 3phase power meter hass integration using BL602, and want to publish all related code changes and my proposals. This is patch series, which I prepared for publishing from "dirty hacks I already done".

My 3phase power meter module code is dirty and build with BL602 specific. For those interested, I published that code in my repo (https://github.com/openshwprojects/OpenBK7231T_App/commit/3842a4458a4433d75462ed255a126b841fddce57).

Kindly ask maintainers to comment changes in overall. Thanks.

openshwprojects commented 1 week ago

Hey, thank you, it seems that I am a bit late, is W800 issue resolved?

rpv-tomsk commented 1 week ago

Hi, all issues are resolved, I polished and published all the code I want to publish. So, waiting for feedback, ready to answer questions and do PR improvements.

My 3phase power meter module code is dirty and build with BL602 specific, I published that code in other branch of my repo (https://github.com/openshwprojects/OpenBK7231T_App/commit/3842a4458a4433d75462ed255a126b841fddce57). It might be worked out and put in official repo, if needed.

rpv-tomsk commented 1 week ago

Details about 3phase meter module:

Direct connection of BL602 to powermeter internals. It has 500-550 kpulses per kWh on each phase. MCU in powermeter has calibration values, so it converts high-speed pulses into low-speed via divider.

My module implemented a kind of calibration using powermeter "600 pulses-per-kWh" low-speed standart output. When enter calibration (by CMD exec), we wait for first pulse, then reset phase counters, wait for 600 calibration pulses, display value of phase counter. After that, we do some calculations (multiply by 3 in my case, as all phases had same current and only 0.3333kWh passed through each phase) and enter calculated value as command arguments. So, we calibrated the module.

We can "automatically" calibrate IC-based modules using this principle (using trusted/certified power-meter with pulse output) Ie, we have power-meter with pulse output, connect it into module input, connect the wires and let some energy pass. Then we have "precise" count of pulses from trusted power-meter and matching value of pulses from IC in module-under-calibration.

HASS screenshot: image

openshwprojects commented 1 week ago

I see you've moved two calls to drivers system:

void(*cbSaveState)();
bool(*publishHASSDevices)(const char* topic);

Is there any need for them? Are they used by other drivers (non-power) as well?

but.. I can see you removed this code from HASS discovery: image So it's per driver now? Well, not bad...

Ok, it seems good so far, but what about the staiblity and other platforms? It was tested only on BL602?

rpv-tomsk commented 1 week ago

So it's per driver now? Well, not bad...

That was the point )

but what about the staiblity and other platforms? It was tested only on BL602?

I tested this only on BL602. See no reasons why it should fail on other platforms, but I had no tests/checks of this , and has no such hardware currently.

openshwprojects commented 1 week ago

Is this BL602 meter documented anywhere, maybe on our forum? https://www.elektroda.com/rtvforum/forum51.html

rpv-tomsk commented 1 week ago

I used internals of this device: image

BL602 board connected to another device internals - energymeter which generates pulses for each phase lines. image

Internals of both these devices are connected now. That are two devices, not one factory-made.

rpv-tomsk commented 5 days ago

Hi, After a some time of "production use", I caught several reboots by watchdog. After each reboot I get "negative energy" value (energy returned back to mains) in HASS. "Energy total" measurements sent to MQTT more often than saved to flash, so HASS has more actual (greater) value than stored in device flash. When device publish new value which is less, negative difference calculated in HASS.

The question to community:
Is that is possible to get last energy measurement values back from MQTT/HASS? (If that is possible then I will try to study and implement that myself).

I'm new in MQTT/HASS so don't know if it is possible at all. Or, maybe there is another solutions in HASS?

Thanks.