Windmeter: add measure interval setting

[malbinola]

Description:

Original implementation was designed for a small cup anemometer (approx 6cm radius) where measuring speed every second was sufficient. As reported by @Ingenieur89 several months ago, when using an anemometer with a higher radius, is useful to delay speed computation, otherwise the speed may not get computed below a certain value.

New setting windmeter_measure_intvl, by default set to 1s (like before), allows to increase the resolution of the speed measurement. Using command Sensor68 6, X (where is X from 1 to 255), you can specify to compute the speed every X seconds.

Finally, now the computation is based on the real time-delta between measurements and not on the name of the timer function (***EverySecond) as happened before.

Compilation for ESP32 succeeded but unfortunately i do not have an ESP32 device to test it on the field.

Related issue (if applicable): fixes #9091

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.4.9
• The code change is tested and works with Tasmota core ESP32 V.2.0.13
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[PatMan6889]

Thanks @malbinola for coming back and bringing this improvement!
I will look into it again.

Is it possible to compute by fractions of a second like 2.5s? Not just 1, 2, 3, ... seconds.

You have 3 parameters here:
windmeter_pulses_x_rot, windmeter_radius, windmeter_speed_factor
which are only used in this formula if I see it right:
// speed = ( (pulses / pulses_per_rotation) * (2 * pi * radius) * anemometer_factor ) / delta_time
WindMeter.speed = (((WindMeter.counter / Settings->windmeter_pulses_x_rot) * (windmeter_2pi * ((float)Settings->windmeter_radius / 1000)) * ((float)Settings->windmeter_speed_factor / 1000)) / ((float)(time - last_time) / 1000000));
Maybe you could save on memory if you merge them together to one factor?
Example:
speed = pulses * factor / delta_time
factor = 2 * pi * radius * anemometer_factor / pulses_per_rotation
The user has to solve this equation one time and hand it over to the settings.
Also this could help the user to customize their calculation.

Best regards!

[malbinola]

Ok, let me know.

Is it possible to compute by fractions of a second like 2.5s? Not just 1, 2, 3, ... seconds.

Yes but it's not an immediate modification. Speed computation is based on FUNC_EVERY_SECOND callback, so logic needs to be migrated for instance to FUNC_EVERY_250_MSECOND and handle time fractions.
I think that seconds here are enough. Why do you need fractions?

Maybe you could save on memory if you merge them together to one factor?

With this PR, i've tried to keep changes to a minimum. But of course it can be pre-computed into a single factor in order to improve internal calculations. Do yo mean internally? Right?
From a user perspective is easier to deal with three named parameters from Sensor68 #,X command instead of having a single compressed factor to set. Then we need to take into account backward compatibility.
Anyway, this could be the 2.0 improvement! :)

[PatMan6889]

Yes but it's not an immediate modification. Speed computation is based on FUNC_EVERY_SECOND callback, so logic needs to be migrated for instance to FUNC_EVERY_250_MSECOND and handle time fractions. I think that seconds here are enough. Why do you need fractions?

I checked again, don't necessarily need fractions. I use a Davis windmeter and in the calculation they go with a measurement period of 2.5 seconds but I can convert the equation to 3 seconds, no issue. This is what i use currently anyway.

With this PR, i've tried to keep changes to a minimum. But of course it can be pre-computed into a single factor in order to improve internal calculations. Do yo mean internally? Right?

Yes, I meant a single factor for internal calculation.

From a user perspective is easier to deal with three named parameters from Sensor68 #,X command instead of having a single compressed factor to set. Then we need to take into account backward compatibility.

I didn't think about backward compatibility, this would be a breaking change...
Or just show the speed equation in the sensor commands description so users can customize.

Anyway, this could be the 2.0 improvement! :)

This was just what I had on my mind. Just leave it as it is. Perfect!
I saw some commented code of a wind direction calculation. This could be interesting to implement in the future, too.

[malbinola]

I saw some commented code of a wind direction calculation. This could be interesting to implement in the future, too.

I agree, it would be cool! This implementation was inspired by tx20/tx23 sensor (xsns_35_tx20) that have support for wind direction information; some code was ported as starting point for future implementations.
Unfortunately, i have only a cup anemometer with no direction measurement.

@Ingenieur89 what kind of ESP device do you have? Can you confirm that modification also work on ESP32?
Thank you

[Jason2866]

PR needs to be tested with an ESP32. Without no merge.

[PatMan6889]

I saw some commented code of a wind direction calculation. This could be interesting to implement in the future, too.

I agree, it would be cool! This implementation was inspired by tx20/tx23 sensor (xsns_35_tx20) that have support for wind direction information; some code was ported as starting point for future implementations. Unfortunately, i have only a cup anemometer with no direction measurement.

@Ingenieur89 what kind of ESP device do you have? Can you confirm that modification also work on ESP32? Thank you

I use an ESP32 devkit c (not sure which model).
I will try to find time on the weekend and test it on a separate device.
Do you know how I can download all the files with your PR included? Im not used to Github

[malbinola]

I use an ESP32 devkit c (not sure which model).

I think that is enough. What do you think @Jason2866 ?
If he asserts that works successfully on that, can i mark the checklist as done?

Do you know how I can download all the files with your PR included? Im not used to Github

@Ingenieur89 This is the source branch of my PR: you can click on "Code" (green button) then "Download ZIP".

[PatMan6889]

I use an ESP32 devkit c (not sure which model).

I think that is enough. What do you think @Jason2866 ? If he asserts that works successfully on that, can i mark the checklist as done?

Do you know how I can download all the files with your PR included? Im not used to Github

@Ingenieur89 This is the source branch of my PR: you can click on "Code" (green button) then "Download ZIP".

I flashed your branch to the ESP32 devkit c and it is working fine for a few days. Thank you for the update!

[malbinola]

Great news @Ingenieur89 !! Thank you for the feedback!
Checklist updated ;)