Complex AC RMS Current Reading Issues

Hello Rob
I am having issues with the ACS712 library ver 0.2.7/6 when reading complex AC waveform and i am wondering if you want my full project details and waveform photos to investigate.
Basically the load on the AC line that the ACS712 is monitoring has two loads:
Load One is an old 100w incandescent lamp controlled via a simple switch.
Load Two is an old 200w incandescent lamp controlled the RBDdimmer function.
Switching on load One gives a clean sine ACS712 output and your library produces very good results.
Switching on load Two gives a switched sine ACS712 output and your library produces good but variable results depend on the dimmer.setPower( n );  power level.
Switching on load One and load Two produces a complex ACS712  waveform (Sine plus Dimmer Spike) and I am afraid your ACS712 library produces very inconsistent results. compared to the in series BRYMEN BM257 RMS meter I am using.
I have had a look on Github for your email to send you full info, scope screen shots and my code and project wire info but i can't seem to find it so i am wondering how to proceed.
All best Ian Knight
PS Ignore the jitter in the image, this is my poor camera

Thanks for reporting the issue.
This is sort of a known problem as the complexity of the signal changes with the dimmer setting as you stated.
I assume the BRYMEN (I have one too) makes more samples to determine the crest factor (form factor).
Analysis
Could you do the following experiment:

use only the dimmer lamp at 100%  (expect a reasonable match in mA)
use only the dimmer lamp at 75%
use only the dimmer lamp at 50%
use only the dimmer lamp at 25%

Thinking out loud
If your dimmer is under program control -  I see dimmer.setPower(n) - it might be possible to derive a function to mimic the crest factor.  The crest factor can be approached by the area under the sine function times some constant:
integral sin(x) => 1 - cos(x)  -  (from my head)
The setPower() parameter n goes from 0..maxN which equals  x  going  from 0 .. PI (radians)
So the formula for the crest factor will probably look something like:
const float cf = 1.0/ (2 * sqrt(2));  //  this value is my best guess

float ff = (1 - cos(  (n * PI) / maxN))  * cf );

PS, email is in the json file

(some more thoughts)

I am afraid your ACS712 library produces very inconsistent results.

The wave form is quite complex indeed, for this kind of wave forms I do not expect the library to be smart enough.

might need to add a note in the description

looking at the point of the spike in the signal I assume it is leading edge phase control.
https://www.dmlights.com/help/lighting/different-methods-dimming/
Problem is that the form factor changes per setting of the dimmer.
Tip: to make a better picture of the scope you better take some distance, so  the autofocus can do its job.
Normally that allows to cut the important part with enough resolution afterwards.

Another way to determine the RMS current should be sampling.
(I have no hardware setup near so please test this function and compare to your BRYMEN

//  PARAM         TYPICAL VALUE
//  frequency   = 50.0
//  mVperStep   = 5000.0 / 1023.0  (Assume Arduino UNO ADC) = 4.887586
//  mVperAmpere = 100.0
//  analogPin   = A0

float RMS_by sampling(float frequency, float mVperStep, float mVperAmpere, uint8_t analogPin)
{
  uint16_t midpoint = 511;
  uint16_t period     = round(1000000UL / frequency);
  float    AmpPerStep = mVperStep / mVperAmpere
  uint16_t samples    = 0;
  float    sumSquared = 0;

  uint32_t start = micros();
  while (micros() - start < period)
  {
    samples++;
    float current = (analogRead(analogPin) - midpoint) * AmpPerStep;
    sumSquared += (current * current);
  }

  float RMS = sqrt(sumSquared) / samples;
  return round(RMS);
}

Hello Rob and many thanks for your replies.
So here are the test results for your first github message.
Attached are some ACS721 output pin scope images, without any electronic
filter:
ZeroLoadNoise
100W-Not-Dimmed                        BRYMEN    0.435A     ACS712
Library Output , Mean of Ten calls to  ACS.mA_AC()          0.353A
200w-Load-Dimmer-25%              BRYMEN    0.472A     ACS712 Library
Output , Mean of Ten calls to  ACS.mA_AC()          0.804A
200w-Load-Dimmer-50%              BRYMEN    0.705A     ACS712 Library
Output , Mean of Ten calls to  ACS.mA_AC() 0.683A
200w-Load-Dimmer-75%              BRYMEN    0.815A     ACS712 Library
Output , Mean of Ten calls to  ACS.mA_AC()          0.704A
200w-Load-Dimmer-100%           BRYMEN    0.536A     ACS712 Library
Output , Mean of Ten calls to  ACS.mA_AC()          0.336A
As can be seen dimmed 25%, 50%, 75% look expected waveform.
But something goes wrong I think in the dimmer library as only half
power and the lamps are not full brightness,
I will do more testing tomorrow, I hope this help Ian

The mA-AC() works on the peaks of the signal during one period. As the peaks are not representative for the (distorted)e signal the math with the crest factor fails. So definitely not OK.
It surprises me that the DMM measures its highest current somewhere around 75% and not at 100%. Does the voltage drop?
Do you have a datasheet / docs /link of the dimmer?

Hello Rob,
So i had an hour spare this evening to try the RMS_by_sampling function
you said i might try.
Unfortunately your version does not seem to work, as it seems to returns
immediately  rather than run for many sample, maybe you meant mills and
not micros for the timing.
So i did a quick hack at it and replaced the timer function with a
simple FOR 10000 loop, this seems to produce some results.
However the RMS output is off by about a factor of 40 or so, inasmuch as
simple 100w lamp load BRYMEN's says 0.435mA and the LCD displays 17.99
or so.
It is also interesting to note that sometimes when turning the load on
the LCD display only 0.02 or so... This maybe a loose connection on my
rig, or a power spike to the Nano....need more testing
Thought you might be interested please see capture of sketch below, all
the best Ian
//
//    FILE: ROB_RMS_TEST_1.ino
//  AUTHOR: Ian Knight, Rob Tillaart
// PURPOSE: To test the Return RMS Function
//    DATE: 2022-08-16
#defineADJUSTABLE_MAX_CURRENT_ANALOG_PIN              A1
#defineHYSTERESIS_CURRENT_IN_MA 100
#include<LiquidCrystal.h>
#defineACS712_ANALOG_PIN                             A0
// initialize the library by associating any needed LCD interface pin
// with the arduino pin number it is connected to
// const int rs = 12, en = 11, d4 = 5, d5 = 4, d6 = 3, d7 = 2; // Working OK
constintrs = 12, en = 11, d4 = 7, d5 = 6, d6 = 5, d7 = 4;
LiquidCrystallcd(rs, en, d4, d5, d6, d7);
floatTheRMS;
longMaxmA; // Adjusted maximum current
//  ----------------------------- Prototypes
voidDisplayToLCDTotalCurrent( void);
voidDisplayToLCDMaxCurrent( void);
//  PARAM         TYPICAL VALUE
//  frequency   = 50.0
//  mVperStep   = 5000.0 / 1023.0  (Assume Arduino UNO ADC) = 4.887586
//  mVperAmpere = 100.0
//  analogPin   = A0
floatRMS_by_sampling( floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin);
// ------------------------------------------------ setup()
voidsetup()
{ // set up the LCD's number of columns and rows:
lcd.begin(16, 2);  // Init LCD
//lcd.print("hello, world!");   // Print a message to the LCD.
}
// -------------------------------------------------- loop()
voidloop()
{ // set the cursor to column 0, line 1   (note: line 1 is the second
row, since counting begins with 0):
//TheRMS = RMS_by_sampling( 50.0 , 4.887586 , 100.0 , A0 );
TheRMS = RMS_by_sampling( 50.0, 4.887586, 100.0, ACS712_ANALOG_PIN );
DisplayToLCDTotalCurrent();
MaxmA = analogRead( ADJUSTABLE_MAX_CURRENT_ANALOG_PIN );
MaxmA = map( MaxmA , 0, 1023, 0, 20000); // Map ADC 0->1023 to 0->20000 mA
DisplayToLCDMaxCurrent();
}
#ifdefROB_VERSION
// -------------------------------- RMS_by_sampling()
floatRMS_by_sampling( floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin)
{
uint16_tmidpoint = 511;
uint16_tperiod     = round(1000000UL/ frequency);
float   AmpPerStep = mVperStep / mVperAmpere;
uint16_tsamples    = 0;
float   sumSquared = 0;
uint32_tstart = micros();
while( micros() - start < period )
 {
 samples++;
floatcurrent = (analogRead(analogPin) - midpoint) * AmpPerStep;
 sumSquared += (current * current);
 }
floatRMS = sqrt(sumSquared) / samples;
//return( round(RMS) );
return( RMS );
}
#endif
// -------------------------------- RMS_by_sampling()
floatRMS_by_sampling( floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin)
{
uint16_tmidpoint = 511;
//uint16_t period     = round(1000000UL / frequency);
float   AmpPerStep = mVperStep / mVperAmpere;
uint16_tsamples    = 0;
float   sumSquared = 0;
///uint32_t start = micros();
for( inti = 0; i < 10000; i++ )
 {
 samples++;
floatcurrent = (float)( analogRead( analogPin ) - midpoint ) * AmpPerStep;
 sumSquared += (current * current);
 }
floatRMS = sqrt(sumSquared) / samples;
return( RMS );
}
// ------------------------------------------ DisplayToLCDTotalCurrent(
) ----------------------------------
voidDisplayToLCDTotalCurrent( void)
{
lcd.setCursor(0, 1);
lcd.print("                ");// Clear Line
lcd.setCursor(0, 1);
lcd.print( TheRMS );  // print the RMS AC current
}
// ------------------------------------------- DisplayToLCDMaxCurrent()
voidDisplayToLCDMaxCurrent( void)
{
lcd.setCursor(0, 0);// Col, row
lcd.print("                ");// Clear Line
lcd.setCursor(0, 0);
lcd.print( MaxmA );  // print the System Maximum mA
}
// -- END OF FILE --

Thanks for testing,
So I time to 'disect' that RMS code ...
If the error is a constant factor it is easy to patch.
Think I need some hardware to build a test setup. I will look if I have a spare sensor somewhere.

saw one error in my code - already updated above -
Was float RMS = sqrt(sumSquared)/ samples;
should be
float RMS = sqrt(sumSquared / samples);   //   the () should be around the whole expression.

Dividing by samples after doing the square root makes the outcome at least sqrt(samples) too small.
Can you retry? I'll going to check if I have some hardware today

BRYMEN's says 0.435mA ...

I assume a 100W lamp uses 435 mA  😁

Morning Rob and many thanks for the support.
I have busy day ahead so i am unable to do more testing until this evening.
However i implemented your update to
float  RMS = sqrt(sumSquared / samples);
into my FOR 10000 sample function as can be seen below.
Output for 100W 240V resistive load is BRYMEN 0.435A The function returns 2150.5 not sure if A or mA
I should be back about 1900 today to do further testing, have a good day Ian
// -------------------------------- RMS_by_sampling()
floatRMS_by_sampling( floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin)
{
uint16_tmidpoint = 511;
//uint16_t period     = round(1000000UL / frequency);
float   AmpPerStep = mVperStep / mVperAmpere;
uint16_tsamples    = 0;
float   sumSquared = 0;
///uint32_t start = micros();
for( inti = 0; i < 10000; i++ )
 {
 samples++;
floatcurrent = (float)( analogRead( analogPin ) - midpoint ) * AmpPerStep;
 sumSquared += (current * current);
 }
//float RMS = sqrt(sumSquared) / samples;
floatRMS = sqrt(sumSquared / samples);
return( RMS );
}

Do you have a datasheet / docs /link of the dimmer?

Hello Rob,
Please find below link to the 8A dimmer i am currently testing with.
However the testing I have done with the RMS_by_sampling() function have
all been done with a NONE dimmed 100W load.
Although the dimmer module is still wired to the NANO but is not
software enabled.
https://robotdyn.com/ac-dimmer-module-8a-with-ac-dc-power-supply-1-channel-3-3v-5v-logic-ac-110-240v-8a.html
Am home again now and able to do more testing if you wish, all best Ian

Thanks for the link, I had a quick look at the library for it - https://github.com/RobotDynOfficial/RBDDimmer
and it looks pretty dedicated (timer interrupts etc) per platform.
Did not make progress today (too much "non maskable interrupts") so I have to catch up tasks.
I'll be online around 21:00 GMT again, maybe earlier.

Minor change in the RMS code, added some print
//  PARAM         TYPICAL VALUE
//  frequency   = 50.0
//  mVperStep   = 5000.0 / 1023.0  (Assume Arduino UNO ADC) = 4.887586
//  mVperAmpere = 100.0
//  analogPin   = A0

float RMS_by_sampling(float frequency, float mVperStep, float mVperAmpere, uint8_t analogPin)
{
  uint16_t midpoint   = 511;   // UNO midpoint.
  uint32_t period     = round(1000000UL / frequency);  //  should be ~20k micros
  Serial.println(period);
  float    AmpPerStep = mVperStep / mVperAmpere;       // should be ~0.048875 Ampere per step.
  Serial.println(AmpPerStep, 5);

  uint32_t samples    = 0;
  float    sumSquared = 0;

  uint32_t start = micros();
  while (micros() - start < period)
  {
    samples++;
    float current = (analogRead(analogPin) - midpoint) * AmpPerStep;   // unit = Amperes.
    sumSquared += (current * current);       //  unit = Ampere squared.
  }
  float RMS = sqrt(sumSquared / samples);    //  unit = Ampere.
  Serial.println(RMS, 5);
  return RMS;                                //  current = Amperes.
}

If you run this with the 100Watt lamp  100W / 230 V = 0.435 Ampere, what does it return?

Test proposal
Can you do the test with a load of ~1000 Watt e.g. an iron?  1000W/230V = 4.4 Ampere

measure with BRYMEN
measure with mA_AC();
measure with RMS_by_sampling();

Rationale
A problem with a load of 100 W could be that the point2point (max signal - min signal) is only 25 steps.
So the peak above the midpoint is only 12 or 13 steps.  (Ampere per step = 5000/1023/100 = 0.048875.
As noise can easily be a 2-5 steps this is a substantial part (30%) of the peak => so even more of the non peak part.
A 1000 W load should be less affected by the noise.
How I got the 25 steps.
from ma_AC()
  float mA = (500.0 * point2point) * _mVperStep * _formFactor / _mVperAmpere;
500 * 25 * 4.8875 / sqrt(2) / 100 = 432 mA   (that is what BRYMEN measured)

Hello Rob,
Quick note re RobotDyn Library interrupts/timers etc.
During my early testing couple of weeks ago, I was doing a long
Serial.print message in loop every second.
This caused the dimmer output to dim at the same same rate as the
Serial.print.
I Think the serial out interrupt was interfering with the Dimmer Library
interrupts/timers.
This I will build a proper rig for when i get a moment and test
thoroughly as is potential problem.
I shall do other testing for you in next hour or so and send to you, Ian

Rob,
Tested at 9600 bps serial, it is interesting to note that the serial
output is very fast, implying that is doing not do many samples in
RMS_by_sampling.
Also note micro() wraps after a few minutes, so may produce inconstant
results, maybe us mills()
Output from Serial Print Version of RMS_by_sampling() without any load:
Brymen 0.007A
Serial Output from Arduino IDE V2.0.0 RC9.2 with time stamp:
21:58:23.702 -> 0.04888
21:58:23.702 -> 0.36488
21:58:23.733 -> 20000
21:58:23.733 -> 0.04888
21:58:23.733 -> 0.36870
21:58:23.765 -> 20000
21:58:23.765 -> 0.04888
21:58:23.765 -> 0.36849
21:58:23.807 -> 20000
21:58:23.807 -> 0.04888
21:58:23.807 -> 0.36226
21:58:23.842 -> 20000
21:58:23.842 -> 0.04888
21:58:23.842 -> 0.36585
21:58:23.877 -> 20000
21:58:23.877 -> 0.04888
21:58:23.877 -> 0.36594
21:58:23.913 -> 20000
21:58:23.913 -> 0.04888
21:58:23.913 -> 0.36660
21:58:23.947 -> 20000
21:58:23.947 -> 0.04888
21:58:23.947 -> 0.36245
21:58:23.982 -> 20000
Output from Serial Print Version of RMS_by_sampling() with 100W load at
237V:
Brymen 0.436A
Serial Output from Arduino IDE V2.0.0 RC9.2 with time stamp:
22:3:33.409 -> 1525.90014
22:3:33.442 -> 20000
22:3:33.442 -> 0.04888
22:3:33.442 -> 1531.34667
22:3:33.483 -> 20000
22:3:33.483 -> 0.04888
22:3:33.483 -> 1501.86999
22:3:33.518 -> 20000
22:3:33.518 -> 0.04888
22:3:33.518 -> 1477.44860
22:3:33.555 -> 20000
22:3:33.555 -> 0.04888
22:3:33.555 -> 1452.61437
22:3:33.591 -> 20000
22:3:33.591 -> 0.04888
22:3:33.591 -> 1525.90161
22:3:33.627 -> 20000
22:3:33.627 -> 0.04888
22:3:33.627 -> 1531.33801
22:3:33.662 -> 20000
22:3:33.662 -> 0.04888
22:3:33.662 -> 1501.87451
22:3:33.699 -> 20000
22:3:33.699 -> 0.04888
22:3:33.699 -> 1477.44470
22:3:33.735 -> 20000
22:3:33.735 -> 0.04888
22:3:33.735 -> 1477.44641
22:3:33.770 -> 20000
22:3:33.770 -> 0.04888
22:3:33.770 -> 1477.44799
22:3:33.808 -> 20000
22:3:33.808 -> 0.04888
22:3:33.808 -> 1477.44799
22:3:33.844 -> 20000
22:3:33.844 -> 0.04888
22:3:33.844 -> 1452.61511
22:3:33.880 -> 20000
22:3:33.880 -> 0.04888
22:3:33.880 -> 1477.45007
Hope that helps Ian

Sure this helps, at least two parameters are as expected.
The micros() does wrap every 10 minutes or so.
As the code uses subtraction in the comparison it works.
Serial output is handled in the background, and yes it affects the analogRead()
Lets count the number of samples. (load 100W for now) to find out.
Can you verify that the midpoint = 2.5V ?

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  float amps = RMS_by_sampling(50, 4.887586, 100, A0);
  Serial.println(amps);
  Serial.println();
  delay(1000);
}

//  PARAM         TYPICAL VALUE
//  frequency   = 50.0
//  mVperStep   = 5000.0 / 1023.0  (Assume Arduino UNO ADC) = 4.887586
//  mVperAmpere = 100.0
//  analogPin   = A0

float RMS_by_sampling(float frequency, float mVperStep, float mVperAmpere, uint8_t analogPin)
{
  uint16_t midpoint   = 511;   // UNO midpoint.
  uint32_t period     = round(1000000UL / frequency);  //  should be ~20k micros
  float    AmpPerStep = mVperStep / mVperAmpere;       // should be ~0.048875 Ampere per step.

  uint32_t samples    = 0;
  float    sumSquared = 0;

  uint32_t start = micros();
  while (micros() - start < period)
  {
    samples++;
    float current = (analogRead(analogPin) - midpoint) * AmpPerStep;   // unit = Amperes.
    sumSquared += (current * current);       //  unit = Ampere squared.
  }
  float RMS = sqrt(sumSquared / samples);    //  unit = Ampere.
  Serial.println(samples);
  Serial.println(RMS, 5);
  return RMS;                                //  current = Amperes.
}

Note to myself:
There is an optimization, the * AmpPerStep;  in the loop can be outside the loop.
Would save a float multiply every loop, and adds 2 float multiplies instead.

Hello Rob, Please find test result for your mini app ROB_RMS_TEST_2.ino
5V Uno supply from USB 4.68v
ACS721 No load midpoint 2.35v
No load BryMen 0.006A, Your app results below
15:35:02.373 -> 0.49
15:35:02.373 ->
15:35:03.402 -> 139
15:35:03.402 -> 0.49355
15:35:03.402 -> 0.49
15:35:03.402 ->
15:35:04.418 -> 139
15:35:04.418 -> 0.49249
15:35:04.418 -> 0.49
15:35:04.418 ->
15:35:05.447 -> 139
15:35:05.447 -> 0.49468
15:35:05.447 -> 0.49
15:35:05.447 ->
15:35:06.461 -> 139
15:35:06.461 -> 0.49259
15:35:06.461 -> 0.49
15:35:06.461 ->
15:35:07.475 -> 139
15:35:07.475 -> 0.49369
15:35:07.475 -> 0.49
15:35:07.475 ->
15:35:08.523 -> 139
15:35:08.523 -> 0.49046
15:35:08.523 -> 0.49
15:35:08.523 ->
15:35:09.539 -> 139
15:35:09.539 -> 0.49319
15:35:09.539 -> 0.49
15:35:09.539 ->
15:35:10.537 -> 139
15:35:10.537 -> 0.49216
15:35:10.537 -> 0.49
15:35:10.537 ->
15:35:11.539 -> 139
15:35:11.539 -> 0.49611
15:35:11.539 -> 0.50
15:35:11.539 ->
100W load BryMen 0.431A, Your app results below
15:39:40.996 -> 1912.74
15:39:40.996 ->
15:39:42.040 -> 143
15:39:42.040 -> 1949.89526
15:39:42.040 -> 1949.90
15:39:42.040 ->
15:39:43.071 -> 143
15:39:43.071 -> 1949.89147
15:39:43.071 -> 1949.89
15:39:43.071 ->
15:39:44.086 -> 143
15:39:44.086 -> 1931.40795
15:39:44.086 -> 1931.41
15:39:44.086 ->
15:39:45.115 -> 144
15:39:45.115 -> 1943.10546
15:39:45.115 -> 1943.11
15:39:45.115 ->
15:39:46.129 -> 143
15:39:46.129 -> 1949.89074
15:39:46.129 -> 1949.89
15:39:46.129 ->
15:39:47.121 -> 142
15:39:47.121 -> 1919.46875
15:39:47.121 -> 1919.47
15:39:47.121 ->
15:39:48.164 -> 142
15:39:48.164 -> 1938.19055
15:39:48.164 -> 1938.19
15:39:48.164 ->
15:39:49.197 -> 142
15:39:49.197 -> 1956.74804
15:39:49.197 -> 1956.75
15:39:49.197 ->
15:39:50.210 -> 143
15:39:50.210 -> 1968.20080
15:39:50.210 -> 1968.20
15:39:50.210 ->

Very insightful!  thanks a lot

ACS721 No load midpoint 2.35v

Assumed 2.5V so lets adapt the midpoint in code  2.35 / 5.00 * 1023 = 480

5V Uno supply from USB 4.68v

Assumed 5V so lets adapt too  4680 / 1023 = 4,57478 mVperstep.
void setup()
{
  Serial.begin(9600);
}

void loop()
{
  float amps = RMS_by_sampling(50, 4.57478, 100,  A0);
  Serial.println(amps);
  Serial.println();
  delay(1000);
}

//  PARAM         TYPICAL VALUE
//  frequency   = 50.0
//  mVperStep   = 5000.0 / 1023.0  (Assume Arduino UNO ADC) = 4.887586
//  mVperAmpere = 100.0
//  analogPin   = A0

float RMS_by_sampling(float frequency, float mVperStep, float mVperAmpere, uint8_t analogPin)
{
  uint16_t midpoint   = 480;   // UNO midpoint.
  uint32_t period     = round(1000000UL / frequency);  //  should be ~20k micros
  float    AmpPerStep = mVperStep / mVperAmpere;       // should be ~0.048875 Ampere per step.

  uint32_t samples    = 0;
  float    sumSquared = 0;

  uint32_t start = micros();
  while (micros() - start < period)
  {
    samples++;
    float current = (analogRead(analogPin) - midpoint) * AmpPerStep;   // unit = Amperes.
    sumSquared += (current * current);       //  unit = Ampere squared.
  }
  float RMS = sqrt(sumSquared / samples);    //  unit = Ampere.
  Serial.println(samples);
  Serial.println(RMS, 5);
  return RMS;                                //  current = Amperes.
}

Give it a try, should be closer to the BRYMEN now.

Note:
As the midpoint was 31 steps off (511-480) , half of the measurements - and squared -  was way too high.

optimized version,
replaced a multiplication for every measurement in the loop with one outside the loop
#samples in 20 milliseconds goes up from 145 to 152 so ~4% more samples (tested on UNO)
float RMS_by_sampling(float frequency, float mVperStep, float mVperAmpere, uint8_t analogPin)
{
  uint16_t midpoint   = 480;   // UNO midpoint.
  uint32_t period     = round(1000000UL / frequency);
  float    AmpPerStep = mVperStep / mVperAmpere;

  uint16_t samples    = 0;
  float    sumSquared = 0;

  uint32_t start = micros();
  while (micros() - start < period)
  {
    samples++;
    uint32_t current = analogRead(analogPin) - midpoint ;
    sumSquared += (current * current);
  }
  float RMS = sqrt(sumSquared / samples) * AmpPerStep;
  Serial.println(samples);
  return RMS;
}

Hello Rob, Please find test result for your mini app ROB_RMS_TEST_3.ino
100W load BryMen 0.433A, Your app results below
18:10:19.585 -> 140
18:10:19.585 -> 1.87211
18:10:19.585 -> 1.87
18:10:19.585 ->
18:10:20.599 -> 140
18:10:20.599 -> 1.86943
18:10:20.599 -> 1.87
18:10:20.599 ->
18:10:21.617 -> 140
18:10:21.617 -> 1.86537
18:10:21.617 -> 1.87
18:10:21.617 ->
18:10:22.615 -> 140
18:10:22.616 -> 1.86387
18:10:22.616 -> 1.86
18:10:22.616 ->
18:10:23.663 -> 140
18:10:23.663 -> 1.86361
18:10:23.663 -> 1.86
18:10:23.663 ->
18:10:24.697 -> 141
18:10:24.697 -> 1.86070
18:10:24.697 -> 1.86
18:10:24.697 ->
18:10:25.718 -> 141
18:10:25.718 -> 1.86190
18:10:25.718 -> 1.86
18:10:25.718 ->
Just go your up date this i'll test in couple of minutes and call it
ROB_RMS_TEST_4.ino
Ian

Hello Rob, Please find test result for your mini app ROB_RMS_TEST_4.ino
100W load BryMen 0.434A, Your app results below
18:22:08.664 -> 1.85
18:22:08.664 ->
18:22:09.678 -> 157
18:22:09.678 -> 1.85
18:22:09.678 ->
18:22:10.695 -> 157
18:22:10.695 -> 1.85
18:22:10.695 ->
18:22:11.730 -> 157
18:22:11.730 -> 1.86
18:22:11.730 ->
18:22:12.727 -> 157
18:22:12.727 -> 1.85
18:22:12.727 ->
18:22:13.770 -> 157
18:22:13.770 -> 1.86
18:22:13.770 ->
18:22:14.786 -> 157
18:22:14.786 -> 1.86
18:22:14.786 ->
18:22:15.783 -> 157
18:22:15.783 -> 1.85
18:22:15.783 ->
18:22:16.830 -> 157
18:22:16.830 -> 1.86
Ian

So number of samples increased and still no substantial improvement in the measurement.
Can you run without load?  to see if the zero point is improved?

think it is time to get the raw data, as raw as possible.
Should give one period of raw data.
uint16_t samp[250];

void setup()
{
  Serial.begin(9600);
  Serial.println();

  uint16_t samples = 0;
  uint32_t start = micros();
  while (micros() - start < 20000)
  {
    samp[samples] = analogRead(A0);
    samples++;
    delayMicroseconds(28);  // simulate math so we get ~145 samples.
  }
  Serial.print("samples: ");
  Serial.println(samples);

  for (int i = 0; i < samples; i++)
  {
    if ((i % 10) == 0) Serial.println();
    Serial.print(samp[i]);
    Serial.print("\t");
  }

  Serial.println("\n\ndone...");
}

void loop()
{
}

Rob please results for ROB_RMS_TEST_RAW_DATA_1.ino
Zero Load
19:30:33.115 ->
19:30:33.180 -> samples: 146
19:30:33.180 ->
19:30:33.180 -> 520    520    520    521    520    519 519    520
520    520
19:30:33.213 -> 520    520    521    520    519    520 520    520
520    519
19:30:33.280 -> 520    519    520    520    520    519 519    520
520    520
19:30:33.313 -> 520    520    520    520    519    520 519    520
520    519
19:30:33.346 -> 519    520    521    519    519    520 519    520
519    520
19:30:33.413 -> 520    520    520    519    520    519 519    520
520    520
19:30:33.445 -> 519    520    520    520    520    520 521    520
520    520
19:30:33.479 -> 520    520    519    520    520    520 520    520
520    520
19:30:33.546 -> 520    519    520    520    520    520 520    519
519    519
19:30:33.579 -> 519    519    520    519    521    520 519    519
520    520
19:30:33.612 -> 520    520    520    520    520    520 520    520
520    519
19:30:33.645 -> 521    520    520    520    520    520 520    520
520    520
19:30:33.712 -> 520    520    520    520    520    520 520    520
519    519
19:30:33.745 -> 520    520    520    520    520    520 520    519
520    519
19:30:33.779 -> 520    520    520    519    520    520
19:30:33.814 ->
19:30:33.814 -> done...
Brymen 0.434A load
19:33:45.882 ->
19:33:45.914 -> samples: 146
19:33:45.914 ->
19:33:45.914 -> 535    535    534    534    534    532 532    532
532    532
19:33:45.962 -> 531    530    530    529    529    529 528    528
527    527
19:33:46.040 -> 526    526    525    525    524    524 522    522
522    521
19:33:46.074 -> 522    520    520    521    519    518 518    518
517    517
19:33:46.107 -> 516    516    515    515    515    515 515    514
515    514
19:33:46.173 -> 514    514    513    514    514    513 514    514
514    514
19:33:46.207 -> 513    513    513    513    514    513 514    514
515    516
19:33:46.240 -> 515    516    516    516    517    517 517    517
519    519
19:33:46.306 -> 518    520    519    520    520    520 522    522
522    523
19:33:46.340 -> 524    524    524    525    526    526 527    527
527    528
19:33:46.372 -> 528    529    529    530    530    532 532    533
532    533
19:33:46.406 -> 533    533    534    535    534    535 535    536
536    537
19:33:46.473 -> 536    536    536    537    537    537 536    537
537    538
19:33:46.506 -> 536    537    536    537    538    537 537    538
537    538
19:33:46.540 -> 537    537    536    536    535    536
19:33:46.584 ->
19:33:46.584 -> done...
Hope that help Ian

The first raw measurement shows that the midpoint is about 520 now. ~ that is about 2.54 volt.
Compared to the 2.35 V you mentioned earlier this is ~20% fluctuation

Rob your:
The first raw measurement shows that the midpoint is about 520 now. ~
that is about 2.54 volt.
Compared to the 2.35 V you mentioned earlier this is ~20% fluctuation
The mid measurement i gave was Brymen DC volt at zero load on output pin
of ACS712
The data points are from ADC output, not sure why they are different.
Ian

The mid measurement i gave was Brymen DC volt at zero load on output pin
of ACS712
The data points are from ADC output, not sure why they are different.

That's what we need to find out.

Can you post your schematic, exactly how you connected the ACS712 to the Processor?

Most important thing is that the GND of the ACS712 and the GND of the Processor are connected.
This forces a common reference for all voltages.
Second, the power supply of both the ACS712 and the Processor should be stable 5V even under a load.
The ACS712 needs it to generate 2.5V as midpoint, and the Processor needs it as a reference for its ADC.

Coming soon:
I'm going to implement a 0.2.8 version that includes this sampling function as it has serious added value for non trivial signals.
It might replace the mA_AC() in time as the form factor is obsolete.

Hello Rob,
I think the present approach of trying to determine the RMS current from
a single cycle is a bit optimistic.
My reasoning for this is two fold, there is always going to be on the
mains noise from sources we have no control over like next doors fridge
etc etc.
Two during our test I notice that the BRYMEN does not give and instant
value of RMS current.
As it takes 2, 3 or 4  seconds from the load being switched on to
present a steady value, likewise when the load is switched off it take
as long as 10 seconds to reach zero.
Hence i think we need a function where one of the parameters is the
number of cycles to sample and see how that test rather than chase
single cycle noise.
What you think?  Ian

Good thoughts!
I have to look at it from every possible use case , the perspective of a library developer.
The library provides one cycle which is the minimum.
A user can call that function in a loop, adjust midpoint every 7 iterations whatever meets his needs. The user can average the values, ignore outliers etc. So many scenario's you cannot parameterize the function to meet all that. So functions should be seen as the building block of a solution.
On the other hand the quality of the software solution can only compensate hardware limitations to some extend. So if there is an electric problem with midpoint the lib cant solve, multiple samples wont fix it.

Rob
Re multi calls to your library. Problem is with multiple calls is the
call setup (stack pushing etc) means you will have a mini dead band from
call to call.
I Still think it better to get in mA_AC() for n cycles, would be
interesting to see the difference between: mA_AC() and mA_AC_Mean_Cycles()
Ian

Implement and test your assumption.
That us the only way to proof that the parameter add value.
I expect that the overhead of a function call is maybe 20x less than a single analogRead(). So you wont notice the difference, but I can be wrong

this could be the code
float RMS_cycles(float frequency, float mVperStep, float mVperAmpere, uint8_t analogPin, uint16_t times)
{
  uint16_t midpoint   = 511;   // UNO midpoint.
  uint32_t period     = round(1000000UL / frequency);
  float    AmpPerStep = mVperStep / mVperAmpere;

  if (times < 1) times = 1;

  float average = 0;

  for (int i = 0; i< times; i++)
  {
    uint16_t samples    = 0;
    float    sumSquared = 0;

    uint32_t start = micros();
    while (micros() - start < period)
    {
      samples++;
      uint32_t current = analogRead(analogPin) - midpoint;
      sumSquared += (current * current);
    }
    float RMS = sqrt(sumSquared / samples) * AmpPerStep;
    average += RMS;
 }

  return average/times;
}

Another option could be a parameter to add the number of seconds the sampling should take.
float RMS_cycles(float frequency, float mVperStep, float mVperAmpere, uint8_t analogPin, uint8_t seconds)
{
  uint16_t midpoint   = 511;   // UNO midpoint.
  uint32_t period     = seconds * 1000000UL;
  float    AmpPerStep = mVperStep / mVperAmpere;
  uint16_t samples    = 0;
  float    sumSquared = 0;

  uint32_t start = micros();
  while (micros() - start < period)
  {
    samples++;
    uint32_t current = analogRead(analogPin) - midpoint;
    sumSquared += (current * current);
  }
  float RMS = sqrt(sumSquared / samples) * AmpPerStep;
  return RMS
}

Hello Rob,
I'll will give both versions a test tonight for you on 100W, 200W and
1kW loads this evening and let you know.
Ian

Created a develop branch 0.2.8 with

add mA_AC_sampling() - triggered by this issue
add getAmperePerStep()
some small optimizations
refactor as preparation for 0.3.0 (mainly move code to .cpp)
improve documentation

Hello Rob, sorry but things domestic busy so only limited testing this
evening, will do more tomorrow.
See below sketch Ian
TheRMS = RMS_Cycles( 50.0, 4.887586, 100.0, ACS712_ANALOG_PIN , 50);
No Load BRYMEN 0.01A LCD RMS 0.1
100W Load BRYMEN 0.433A LCD RMS Jitter 2048.9 to 2062.0 Think jitter is
pretty good
TheRMS = RMS_Duration( 50.0, 4.887586, 100.0, ACS712_ANALOG_PIN , 1);
No Load BRYMEN 0.01A LCD RMS 0.12
100W Load BRYMEN 0.433A LCD RMS Jitter 2111.0 to 2128.6 Think jitter is
pretty good
I think I have a questionable connection from ACS712 to Nano, will look
into this in morning.
Question what is you plan to get present RMS output  into mA's
PS What you think of Arduino IDE V2, I think is amazing :-)
//
//    FILE: ROB_RMS_TEST_SAMPLE_SET_1.ino
//  AUTHOR: Ian Knight, Rob Tillaart
// PURPOSE: To test the Return RMS Function
//    DATE: 2022-08-19
#defineADJUSTABLE_MAX_CURRENT_ANALOG_PIN              A1
#defineHYSTERESIS_CURRENT_IN_MA 100
#include<LiquidCrystal.h>
#defineACS712_ANALOG_PIN                             A0
// initialize the library by associating any needed LCD interface pin
// with the arduino pin number it is connected to
// const int rs = 12, en = 11, d4 = 5, d5 = 4, d6 = 3, d7 = 2; // Working OK
constintrs = 12, en = 11, d4 = 7, d5 = 6, d6 = 5, d7 = 4;
LiquidCrystallcd(rs, en, d4, d5, d6, d7);
floatTheRMS;
longMaxmA; // Adjusted maximum current
//  ----------------------------- Prototypes
voidDisplayToLCDTotalCurrent( void);
voidDisplayToLCDMaxCurrent( void);
//  PARAM         TYPICAL VALUE
//  frequency   = 50.0
//  mVperStep   = 5000.0 / 1023.0  (Assume Arduino UNO ADC) = 4.887586
//  mVperAmpere = 100.0
//  analogPin   = A0
//float RMS_by_sampling( float frequency , float mVperStep , float
mVperAmpere , uint8_t analogPin );
floatRMS_Duration(floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin, uint8_tseconds);
floatRMS_Cycles(floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin, uint16_ttimes);
// ------------------------------------------------ setup()
voidsetup()
{ // set up the LCD's number of columns and rows:
lcd.begin(16, 2);  // Init LCD
Serial.begin( 9600);
//lcd.print("hello, world!");   // Print a message to the LCD.
}
// -------------------------------------------------- loop()
voidloop()
{
//TheRMS = RMS_Cycles( 50.0 , 4.887586 , 100.0 , ACS712_ANALOG_PIN , 50
); // test Hz cycles
TheRMS = RMS_Duration( 50.0, 4.887586, 100.0, ACS712_ANALOG_PIN , 1); //
test duration
DisplayToLCDTotalCurrent();
MaxmA = analogRead( ADJUSTABLE_MAX_CURRENT_ANALOG_PIN );
MaxmA = map( MaxmA , 0, 1023, 0, 20000); // Map ADC 0->1023 to 0->20000 mA
DisplayToLCDMaxCurrent();
}
// -------------------------------------------  RMS_Duration()
floatRMS_Duration(floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin, uint8_tseconds)
{
uint16_tmidpoint   = 511;  // UNO midpoint.
uint32_tperiod     = seconds * 1000000UL;
float   AmpPerStep = mVperStep / mVperAmpere;
uint16_tsamples    = 0;
float   sumSquared = 0;
uint32_tstart = micros();
while(micros() - start < period)
  {
    samples++;
uint32_tcurrent = analogRead(analogPin) - midpoint;
    sumSquared += (current * current);
  }
floatRMS = sqrt(sumSquared / samples) * AmpPerStep;
returnRMS;
}
// --------------------------------------------------- RMS_Cycles()
floatRMS_Cycles(floatfrequency, floatmVperStep, floatmVperAmpere,
uint8_tanalogPin, uint16_ttimes)
{
uint16_tmidpoint   = 511;  // UNO midpoint.
uint32_tperiod     = round(1000000UL/ frequency);
float   AmpPerStep = mVperStep / mVperAmpere;
if(times < 1) times = 1;
floataverage = 0;
for(inti = 0; i< times; i++)
  {
uint16_tsamples    = 0;
float   sumSquared = 0;
uint32_tstart = micros();
while(micros() - start < period)
    {
      samples++;
uint32_tcurrent = analogRead(analogPin) - midpoint;
      sumSquared += (current * current);
    }
floatRMS = sqrt(sumSquared / samples) * AmpPerStep;
    average += RMS;
 }
returnaverage/times;
}
// ------------------------------------------ DisplayToLCDTotalCurrent(
) ----------------------------------
voidDisplayToLCDTotalCurrent( void)
{
lcd.setCursor(0, 1);
lcd.print("                ");// Clear Line
lcd.setCursor(0, 1);
lcd.print( TheRMS );  // print the RMS AC current
}
// ------------------------------------------- DisplayToLCDMaxCurrent()
voidDisplayToLCDMaxCurrent( void)
{
lcd.setCursor(0, 0);// Col, row
lcd.print("                ");// Clear Line
lcd.setCursor(0, 0);
lcd.print( MaxmA );  // print the System Maximum mA
}
// -- END OF FILE --

Question what is you plan to get present RMS output  into mA's

The sampling function will return float mA in 0.2.8
In 0.3.0 I planned to redo all return types. mA_AC() and mA_DC() will also return float.
Especially for the ASC712-5A this gives a bit more accuracy for low currents, think ESP32 with 12 bits ADC
Furthermore I intent to investigate the use of external ADC's e.g ADS1115 ADC which is 16 bit.
This gives a resolution below 1 mA.
Don't know if it will be a new class ACS712_EXT or that it can be build in and add a function to overwrite the analogRead().

PS What you think of Arduino IDE V2, I think is amazing :-)
Not used it yet, I'm still on 1.8.19

Morning Rob, as promised more test data
TheRMS = RMS_Cycles( 50.0, 4.887586, 100.0, ACS712_ANALOG_PIN , 50);
No Load BRYMEN 0.004A LCD RMS 0.25
100W Load BRYMEN 0.43A LCD RMS Jitter 2130.5 to 2135.5
200W Load BRYMEN 0.824A LCD RMS Jitter 2198.5 to 2201.5
1000W Load BRYMEN 4.505A LCD RMS Jitter 2252 to 2254
TheRMS = RMS_Duration( 50.0, 4.887586, 100.0, ACS712_ANALOG_PIN , 1);
100W Load BRYMEN 0.43A LCD RMS Jitter 2175 to 2186
200W Load BRYMEN 0.824A LCD RMS Jitter 2217 to 2223
1000W Load BRYMEN 4.505A LCD RMS Jitter 2251 to 2256
Note Output of ACS712 monitored on scope as follows:
100W PP 140mV to 168mV, RMS 40.9 mV
200W PP 240mV to 256mV, RMS 76.5 mV
300W PP 352mV to 368mV, RMS 116.2 mV
1000W PP 1.2V to 368mV, RMS 421.5 mV See Image
Am about today if more testing required Ian

The BRYMEN measurements look all consistent with each other.
The RMS scope measurements also look consistent, although the RMS measured by scope is ~10% too low.
100 Watt => 40.9 mV RMS with 100mVperAmpere => 0.409 Ampere which is pretty close to the 0.43
200 Watt => 76.5 mV RMS with 100mVperAmpere => 0.765 Ampere which is pretty close to the 0.824
1000 Watt => 421 mV RMS with 100mVperAmpere => 4.21 Ampere which is pretty close to the 4.505

100W Load BRYMEN 0.43A LCD RMS Jitter 2175 to 2186
200W Load BRYMEN 0.824A LCD RMS Jitter 2217 to 2223
1000W Load BRYMEN 4.505A LCD RMS Jitter 2251 to 2256

The output on the LCD is remarkable close to each other while one should expect a factor 10 between 100W and 1000W.
Can you verify you have the right analog port A0 ?

Good Afternoon Rob,
RE your: The output on the LCD is remarkable close to each other while
one should expect a factor 10 between 100W and 1000W.
Can you verify you have the right analog port A0 ?
Yes jumper wire goes from ACS712 Out to NANO A0 (Pin 14) then I plug
another DuPont  jump into scope prob.
Only cheap scope but it does most jobs fairly well, although on the
1000W load i noticed that the sine seems to have a flat top.
Sign of transformer at end of road is saturating and only summer am
expecting blackouts this winter :-(
All best Ian

https://github.com/RobotDynOfficial/RBDDimmer/issues/58

Cheap scopes are remarkable good and useful. I do a lot with an "el cheapo" JYE Tech DSO150 - I have two of those. 95% of the time it is just to confirm there is a signal and that it looks as expected.

Sign of transformer at end of road is saturating and only summer am expecting blackouts this winter :-(

Does not sound like most reliable infrastructure. Do you have backups in place?

RobotDynOfficial/RBDDimmer#58

The Serial print is interrupt based => that disrupts the timing of the dimmer which uses a HWtimer interrupt.

The Serial print is interrupt based => that disrupts the timing of the
dimmer which uses a HWtimer interrupt.
Yes that is the issue; one wonder why they didn't think serial out was
an issue or didn't bother to test it
Give that serial out must be one of the most used feature of Arduino.

That is often a issue with libraries (including non-Arduino), they do not cover all possible needs.
One can use the libs as starting point, or go to an RTOS solution that allows proper scheduling of all tasks.
The learning curve for RTOS is much steeper than for a plain single thread Arduino code.

Afternoon Rob,
So i thought i would put together a test app to gather some data for a
dimmer not controlled by the Arduino and therefore just unmolested
ACS712 data.
This little app main loop is basically just a 10 state, state counter
that tick every 100mS.
Each 100mS tick it reads your ACS712 mA_AC(50) and computes the mean for
10 samples, a 1 second mean.
The dimmer used is a typical domestic light dimmer that you would find
on the lounge wall of many homes.
The test load is 200W at ~240 volts, the dimmer range seems limited to
the lowest value in the data set below.
Also see scope image captures of the ACS712 output at each of the four
measurements i was able to take, plus the app.
Hope this all helps and a looking forward to your ACS library update
when ready.
Let me know other testing you need, all best Ian Code and images below
Dimmer at minimum BRYMEN 0.489A                     LCD MeanmA ~1020
Dimmer at                    BRYMEN 0.6A LCD MeanmA    ~1016
Dimmer at                    BRYMEN 0.7A LCD MeanmA    ~907
Dimmer at maximum BRYMEN 0.815A                     LCD MeanmA ~793
(Think this is very good result given the noise)
//
//    FILE: OVEN_CONTROLLER_PRODUCTION_V4.ino
//    AUTHOR: Ian Knight
//    PURPOSE: Testing Data
//    DATE: 2022-21-Aug.
#include<LiquidCrystal.h>
#include"ACS712.h"// Current sensor
#defineACS_Pin A0
#defineACS712_CURRENT_SENSOR_ANALOG_PIN               A0
#defineADJUSTABLE_MAX_CURRENT_ANALOG_PIN              A1
#defineMEAN_ACS712_SAMPLES 10
#defineSTATE_COUNTER_TICK_RATE 100// in mS
#defineHYSTERESIS_CURRENT_IN_MA 100
#defineOUTPUT_TEST_PIN 8
ACS712ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN, 5.0, 1023, 100);
constintrs = 12, en = 11, d4 = 7, d5 = 6, d6 = 5, d7 = 4;
LiquidCrystallcd(rs, en, d4, d5, d6, d7);
longMaxmA; // Adjusted maximum current
longMeanmA;// AC721 Mean Current
unsignedlongPreviousMillis = 0;
//  ----------------------------- Prototypes
voidDisplayToLCDTotalCurrent( void);
voidDisplayToLCDMaxCurrent( void);
// ------------------------------------------------ setup()
voidsetup()
{ // set up the LCD's number of columns and rows:
Serial.begin(9600);
lcd.begin(16, 2);  // Init LCD
pinMode( OUTPUT_TEST_PIN , OUTPUT);
ACS.autoMidPoint();// Init ACS712
}
// -------------------------------------------------- loop()
voidloop()
{
staticint StateCounterState;
if( ( unsignedlong)( millis() - PreviousMillis ) >=
STATE_COUNTER_TICK_RATE )
 {
 PreviousMillis = millis();// update time
switch( StateCounterState )
  {
case0:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
break;
case1:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
break;
case2:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
break;
case3:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
digitalWrite( OUTPUT_TEST_PIN , HIGH );
lcd.setCursor(0, 0); lcd.print("                ");// Clear Line 0
digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case4:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
digitalWrite( OUTPUT_TEST_PIN , HIGH );
lcd.setCursor(0, 0); lcd.print( "Max mA's: "); lcd.print( 1000);
digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case5:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
break;
case6:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
break;
case7:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
break;
case8:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
lcd.setCursor(0, 1); lcd.print("                ");// Clear Line 1
break;
case9:
   MeanmA += ACS.mA_AC( 50.0);// Read the ACS712 for AC current
   MeanmA /= MEAN_ACS712_SAMPLES;
lcd.setCursor(0, 1); lcd.print( "Cur mA's: "); lcd.print( MeanmA );
   MeanmA = 0;
break;
  }// End state counter state
if( ++StateCounterState > 9)
  StateCounterState = 0;// Back to state Zero
 }// end if millis State Tick Rate
}// End loop()
// ------------------------------------------ DisplayToLCDTotalCurrent(
) ----------------------------------
voidDisplayToLCDTotalCurrent( void)
{
lcd.setCursor(0, 1);
lcd.print("                ");// Clear Line
lcd.setCursor(0, 1);
lcd.print( "Curt I=");
lcd.print( MeanmA );  // print ACS712 AC mean current
}
// ------------------------------------------- DisplayToLCDMaxCurrent()
voidDisplayToLCDMaxCurrent( void)
{
lcd.setCursor(0, 0);// Col, row
lcd.print("                ");// Clear Line
lcd.setCursor(0, 0);
lcd.print( "Max  I=");
lcd.print( MaxmA );  // print the System Maximum mA
}
// ******************************************************* END OF FILE

Hi Ian,
Thanks for the test, I appreciate the time and efforts.
What I notice is that in this last numbers it seems that BRYMEN + LCD ~ 1600 mA
When Brymen goes up lcd goes down?
Or do I just image seeing a pattern?

Hello Rob,
Yes the pattern is a bit odd but these are the values I read:
At minimum dimmer  the mean mA_AC(50) is highest and the nearer the full
sine the lower.
To the point where dimmer is 100% and sine mostly complete mean
mA_AC(50) returns a value close to the BRYMEN.
Note i think when the email was sent it reordered the images but they
have a title/name of the BRYMEN current.
Also in the images the HANTEK RMS volts goes in the right direction (Up
as current goes up)
Again happy to help and i think we are making good progress, i have this
rig as permanent setup now so more testing is easy :-)
You can also ignore the scope ch2 (green pules) as it is just measuring
time it takes for LCD write as want to make sure mA_AC(50) was read at
consistent timing.
Ian
PS Just a thought, in mA_AC() you comment UNO ~160 samples which is
about as fast ADC can go in UNO/NANO
What about a little Nano testing app where just 200 or so raw sample
data (ADC output) is written into an array then dump to serial.
Do this dump for each of the previous dimmer settings  then do the math
on them in a Visual Studio Consul cpp app which would be easier to debug
than embedded.
Dimmer at minimum BRYMEN 0.489A                     LCD MeanmA ~1020
Dimmer at                    BRYMEN 0.6A LCD MeanmA    ~1016
Dimmer at                    BRYMEN 0.7A LCD MeanmA    ~907
Dimmer at maximum BRYMEN 0.815A                     LCD MeanmA ~793
(Think this is very good result given the noise)

Found a bug in mA_AC - https://github.com/RobTillaart/ACS712/issues/21

https://create.arduino.cc/projecthub/daniel232/three-phase-rms-ammeter-with-current-transformers-7a7866
Related article

Hello Rob and many thanks for the interesting post
In the project code (and only had quick look) they take many sample over
a period
const unsigned long sampleTime = 60000UL;   // sample over 60ms, 3
cycles for 50Hz
const unsigned long numSamples = 120UL;
That is why i mentioned in previous post functions to capture n sample
or n cycles.
The other thing i think will help  is to filter noise spike by
validating min/max samples.
This i think you can do by looking at sample either side of min max to
see if measurement is out of range.
Or as i did for noisy accelerometer data is to have a rolling mean of a
few samples.
I still think the ACS712 is a viable solution for most Arduino user,
just matter of getting the algorithm right.
As I said this test rig is permanent so happy to do testing for you Ian

@imk2021
The example in the link uses 3 full cycles to be able to measure the 3 phases independently for one full cycle. It doesn't use averaging the values of multiple cycles in the measurement. It uses an additional RunningAverage object to average the measurements outside the cal to rmsValue(phasePin_1, numSamples);
const unsigned long sampleTime = 60000UL;   // sample over 60ms, 3 cycles for 50Hz
const unsigned long numSamples = 120UL;     // samples number to divide sampleTime exactly, low enough for the ADC

So 120 samples per full cycle   (mA_AC() makes about 150 same order of magnitude)
In the develop branch I added a parameter cycles to the three measurement functions - mA_AC(), mA_AC_sampling() and ma_DC(). The default for cycles = 1.
Please test mA_AC() and mA_AC_sampling()  if they meet your expectations.
Can you time in one sketch how long it takes to do 1000 cycles  - 300 Watt if possible.

(1) with 1000 as parameter - in function averaging
(2) 1000 calls to the function - and average them outside the function.
compare the results (they should roughly be equal)

1000 calls should take ~ 20 seconds.
I am far from convinced that this parameter is the right step forward. I am a strong believer in scenario (2) as that allows the user to be more flexible in taking the average, median, low pass filtering etc. Whatever suits his project.

@imk2021
After analyzing the code again step by step I finally found a serious bug.
It is in the math in the mA_AC_sampling(). Because there is a mix of int and uint16_t math the line
current = analogRead() - _midPoint; was apparently evaluated as unsigned while it should be signed.
This caused -2 being 65533 and squaring that gave a way too big sum and therefor RMS.
Don't know if it is now 100% but I expect the results of mA_AC_sampling() now be better.
Also added 3 extra AC examples to the library.

Rob
I am not sure what to do re your.
After analyzing the code again step by step I finally found a serious bug.
It is in the math in the mA_AC_sampling(). Because there is a mix of
int and uint16_t math the line
|current = analogRead() - _midPoint;| was apparently evaluated as
unsigned while it should be signed.
This caused -2 being 65533 and squaring that gave a way too big sum and
therefor RMS.
Don't know if it is now 100% but I expect the results of
mA_AC_sampling() now be better.
Also added 3 extra AC examples to the library.
Have you updated your library as I already have 0.2.7 installed and
that's what i tested with.
Can't find 0.2.8 so note sure what changes you have made.
Ian

https://github.com/RobTillaart/ACS712/archive/refs/heads/develop.zip

Morning  Rob
Just collected test result for 0.2.8 development library, they look much
better.
The dimmed results still seem a bit off, but better :-)
I am going to tweak my little test app to call    MeanmA += ACS.mA_AC(
50.0 );
Several times in each state, my guess is 3 for first test so 30 sample
calls rather than 10 per second.
To just see what happens, expect some result later today.
Ian
Not Dimmed
100w  Brymen=0.423  MeanmA=375        Image=NotDimmed100w
200w  Brymen=0.824  MeanmA=766        Image=NotDimmed200w
300w  Brymen=1.247   MeanmA=1175    Image=NotDimmed300w
1000w Brymen=4.527   MeanmA=4376    Image=NotDimmed1000w
200w Dimmed
Brymen=0.509   MeanmA=540 Image=200w-LightDimmerBRYMEN-509ma
Brymen=0.607   MeanmA=624 Image=200w-LightDimmerBRYMEN-607ma
Brymen=0.703   MeanmA=645 Image=200w-LightDimmerBRYMEN-703ma
Brymen=0.827   MeanmA=744 Image=200w-LightDimmerBRYMEN-827ma

Thanks!
Put the numbers in a spreadsheet to explore them

Brymen
AC
Brym / AC
Average

423
375
1,1280

824
766
1,0757

1247
1175
1,0613

4527
4376
1,0345

1,0749

509
540
0,9426

607
624
0,9728

703
645
1,0899

827
744
1,1116

1,0292

Observations 1st set
There seems almost a constant factor that drops as current increases.
The device is a 20 A sensor and the first 3 measurements are all in the bottom 6% of its range.
The 4th measurement is at 20% of its range, and is best.
From the datasheet

The sensitivity can be calibrated between 96 - 104, bringing it closer to real values. (try 96)
Noise = 11 mV which is roughly 0.1A and I expect that after calibrating the deviations are all under this 0.1Amp.
Observations 2nd set
Opposite behavior of the factor, it increases as current drops.
The device is a 20 A sensor and all measurements are in the bottom 4% of its range.
As the dimmer causes the form factor to be incorrect it is expected to deviate.
mA_AC_sampling() is expected (by me) to do a better job.
Trend line analysis
The 1st set of 4 gives a formula f(x) = 0.9750 x - 38.4676   with R2 = 1 (very good)
The 2nd set of 4 gives a formula f(x) = 0.6061 x + 237.3085  with R2 = 0.9642 (good)

Hello Rob,
Just thought i would give mA_AC_samples() a quick test before dinner.
Not Dimmed 100w Brymen 431mA, mean of 40 mA_AC_samples() call 421mA
Dimmed 200w Brymen 510mA, mean of 40 mA_AC_samples() call 501mA
Both results i think are very good!
However sometimes No load Brymen 3mA, mean of 40 mA_AC_samples() call
after NANO reset is 27mA but this slowly increases at rate of ~0.5mA per
second
Thus after a few seconds mean mA_AC_samples() reads 100mA or so.
This does not always happen, sometimes after NANO reset the output will
stabilize at about 40 mA.
Code below:
//
//    FILE: OVEN_CONTROLLER_PRODUCTION_V5.ino
//    AUTHOR: Ian Knight
//    PURPOSE: Testing Data
//    DATE: 2022-26-Aug.
#include<LiquidCrystal.h>
#include"ACS712.h"// Current sensor
#defineACS_Pin A0
#defineACS712_CURRENT_SENSOR_ANALOG_PIN               A0
#defineADJUSTABLE_MAX_CURRENT_ANALOG_PIN              A1
#defineMEAN_ACS712_SAMPLES_SETS 10
#defineSTATE_COUNTER_TICK_RATE 100// in mS
#defineHYSTERESIS_CURRENT_IN_MA 100
#defineOUTPUT_TEST_PIN 8
ACS712ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN, 5.0, 1023, 100);
constintrs = 12, en = 11, d4 = 7, d5 = 6, d6 = 5, d7 = 4;
LiquidCrystallcd(rs, en, d4, d5, d6, d7);
longMaxmA = 0; // Adjusted maximum current
// long MeanmA; // AC721 Mean Current
floatMeanmA;// AC721 Mean Current New for multi cycle samples
unsignedlongPreviousMillis = 0;
//  ----------------------------- Prototypes
voidDisplayToLCDTotalCurrent( void);
voidDisplayToLCDMaxCurrent( void);
// ------------------------------------------------ setup()
voidsetup()
{ // set up the LCD's number of columns and rows:
Serial.begin(9600);
lcd.begin(16, 2);  // Init LCD
pinMode( OUTPUT_TEST_PIN , OUTPUT);
ACS.autoMidPoint();// Init ACS712
}
// -------------------------------------------------- loop()
voidloop()
{
staticint StateCounterState;
if( ( unsignedlong)( millis() - PreviousMillis ) >=
STATE_COUNTER_TICK_RATE )
 {
 PreviousMillis = millis();// update time
switch( StateCounterState )
  {
case0:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
digitalWrite( OUTPUT_TEST_PIN , HIGH );
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);// Takes as expected 80mS
digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case1:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case2:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case3:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
//digitalWrite( OUTPUT_TEST_PIN , HIGH );
lcd.setCursor(0, 0); lcd.print("                ");// Clear Line 0..
This takes 9.8 mS
//digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case4:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
//digitalWrite( OUTPUT_TEST_PIN , HIGH );
lcd.setCursor(0, 0); lcd.print( "Max mA's: "); lcd.print( MaxmA );//
This takes 7 mS
//digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case5:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case6:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case7:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case8:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
lcd.setCursor(0, 1); lcd.print("                ");// Clear Line 1
break;
case9:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
   MeanmA /= MEAN_ACS712_SAMPLES_SETS;
lcd.setCursor(0, 1); lcd.print( "Cur mA's: "); lcd.print( MeanmA );
   MeanmA = 0;
break;
  }// End state counter state
if( ++StateCounterState > 9)
  StateCounterState = 0;// Back to state Zero
 }// end if millis State Tick Rate
}// End loop()
#ifdefOLD
// ------------------------------------------ DisplayToLCDTotalCurrent(
) ----------------------------------
voidDisplayToLCDTotalCurrent( void)
{
lcd.setCursor(0, 1);
lcd.print("                ");// Clear Line
lcd.setCursor(0, 1);
lcd.print( "Curt I=");
lcd.print( MeanmA );  // print ACS712 AC mean current
}
// ------------------------------------------- DisplayToLCDMaxCurrent()
voidDisplayToLCDMaxCurrent( void)
{
lcd.setCursor(0, 0);// Col, row
lcd.print("                ");// Clear Line
lcd.setCursor(0, 0);
lcd.print( "Max  I=");
//lcd.print( MaxmA );   // print the System Maximum mA
lcd.print( 0);  // print the System Maximum mA
}
#endif
// ******************************************************* END OF FILE

Those are the numbers we were waiting for.
ACS.mA_AC_sampling() uses all samples it takes for doing the math.
Therefor it will add up all the noise and interpret it as a current.
An improvement could be to ignore values in the noise range?

I have added noise filtering in the develop branch.
Please finish the tests without noise filtering so we get an idea of how it performs at higher loads.

Hello Rob,
So I'll continue to do all the tests tomorrow and leave 0.2.8 library as
currently installed; Pre noise filter.
Now I think it is about time I added into setup  setmVperAmp(float
mVperAmpere) to see how much we are off by.
Questions:
Should I add setmVperAmp(float mVperAmpere) before or after autoMidPoint()
What you think best load  to use to get best value for setmVperAmp()
100w or 1000w
Have good evening Ian

MidPoint is determined without mV so it should not make a big difference. But yes, specific noise can create a small bias.
It is good to keep measuring the 5V power supply too.
You want to know if it drops during measurements as that would shift the midpoint

BTW in the next 0.3.0 release midpoint will be a float to be more accurate. In coming weeks / months I want to investigate external ADC eg 16 bit as an option. Could improve resolution in the lower ranges

Hello Rob, please find below test set three.
As you can see I have added 500w test for completeness.
Also we have an issues where when i turn the load off, MeanmA sometimes
(very intermittent) does not return to zero or close to it, see note
All best Ian
Test Set Three
mA_AC_sampling() 40 calls per sec.
OVEN_CONTROLLER_PRODUCTION_V5
Pre noise reduction version 0.2.8
ACS.setmVperAmp( 99 ); // To set the calibration for ACS712 deviation
Note: Sometimes after switching a test off, MeanmA does not return to
near zero (50mA or so).
      So I have to press the reset button of the Nano to reinitialize
the app, this resolves the issues.
Originally in the code (state case 9) was MeanmA = 0; so I changed this
to MeanmA = 0.0; and it seemed to have fixed it.
However, it happened again during this test set, my app is attached but
i can't see an error in it.
Not Dimmed
100w  Brymen=0.430  MeanmA=414.2
200w  Brymen=0.833  MeanmA=797.5
300w  Brymen=1.247  MeanmA=1220.3
500w  Brymen=2.074  MeanmA=1977.8
1000w Brymen=4.6    MeanmA=4456.5
200w Dimmed
Brymen=0.505   MeanmA=815.5 after reset 515.6
Brymen=0.603   MeanmA=591.5
Brymen=0.702   MeanmA=687.5
Brymen=0.830   MeanmA=812.3
500w Dimmed
Brymen=1.277   MeanmA=1302.9
Brymen=1.404   MeanmA=1416.3
Brymen=1.506   MeanmA=1507.8
Brymen=1.611   MeanmA=1606.9
Brymen=1.701   MeanmA=1690.8
Brymen=1.800   MeanmA=1778.1
Brymen=1.905   MeanmA=1888.9
Brymen=2.007   MeanmA=1982.4
Brymen=2.059   MeanmA=2025.8
//
//    FILE: OVEN_CONTROLLER_PRODUCTION_V5.ino
//    AUTHOR: Ian Knight
//    PURPOSE: Testing Data
//    DATE: 2022-26-Aug.
#include<LiquidCrystal.h>
#include"ACS712.h"// Current sensor
//#define ACS_Pin A0
#defineACS712_CURRENT_SENSOR_ANALOG_PIN               A0
#defineADJUSTABLE_MAX_CURRENT_ANALOG_PIN              A1
#defineMEAN_ACS712_SAMPLES_SETS 10
#defineSTATE_COUNTER_TICK_RATE 100// in mS
#defineHYSTERESIS_CURRENT_IN_MA 100
#defineOUTPUT_TEST_PIN 8
ACS712ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN, 5.0, 1023, 100);
constintrs = 12, en = 11, d4 = 7, d5 = 6, d6 = 5, d7 = 4;
LiquidCrystallcd(rs, en, d4, d5, d6, d7);
longMaxmA = 0; // Adjusted maximum current
// long MeanmA; // AC721 Mean Current
floatMeanmA = 0.0;// AC721 Mean Current New for multi cycle samples
unsignedlongPreviousMillis = 0;
//  ----------------------------- Prototypes
voidDisplayToLCDTotalCurrent( void);
voidDisplayToLCDMaxCurrent( void);
// ------------------------------------------------ setup()
voidsetup()
{ // set up the LCD's number of columns and rows:
Serial.begin(9600);
lcd.begin(16, 2);  // Init LCD
pinMode( OUTPUT_TEST_PIN , OUTPUT);
ACS.setmVperAmp( 99);// To set the calibration for ACS712 deviation
ACS.autoMidPoint();// Init ACS712
}
// -------------------------------------------------- loop()
voidloop()
{
staticint StateCounterState;
if( ( unsignedlong)( millis() - PreviousMillis ) >=
STATE_COUNTER_TICK_RATE )
 {
 PreviousMillis = millis();// update time
switch( StateCounterState )
  {
case0:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
digitalWrite( OUTPUT_TEST_PIN , HIGH );
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);// Takes as expected 80mS
digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case1:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case2:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case3:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
//digitalWrite( OUTPUT_TEST_PIN , HIGH );
lcd.setCursor(0, 0); lcd.print("                ");// Clear Line 0..
This takes 9.8 mS
//digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case4:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
//digitalWrite( OUTPUT_TEST_PIN , HIGH );
lcd.setCursor(0, 0); lcd.print( "Max mA's: "); lcd.print( MaxmA );//
This takes 7 mS
//digitalWrite( OUTPUT_TEST_PIN , LOW );
break;
case5:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case6:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case7:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
break;
case8:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
lcd.setCursor(0, 1); lcd.print("                ");// Clear Line 1
break;
case9:
//..   MeanmA += ACS.mA_AC( 50.0 ); // Read the ACS712 for AC current
   MeanmA += ACS.mA_AC_sampling( 50.0, 4);
   MeanmA /= MEAN_ACS712_SAMPLES_SETS;
lcd.setCursor(0, 1); lcd.print( "Cur mA's: "); lcd.print( MeanmA );
   MeanmA = 0.0;
break;
  }// End state counter state
if( ++StateCounterState > 9)
  StateCounterState = 0;// Back to state Zero
 }// end if millis State Tick Rate
}// End loop()
#ifdefOLD
// ------------------------------------------ DisplayToLCDTotalCurrent(
) ----------------------------------
voidDisplayToLCDTotalCurrent( void)
{
lcd.setCursor(0, 1);
lcd.print("                ");// Clear Line
lcd.setCursor(0, 1);
lcd.print( "Curt I=");
lcd.print( MeanmA );  // print ACS712 AC mean current
}
// ------------------------------------------- DisplayToLCDMaxCurrent()
voidDisplayToLCDMaxCurrent( void)
{
lcd.setCursor(0, 0);// Col, row
lcd.print("                ");// Clear Line
lcd.setCursor(0, 0);
lcd.print( "Max  I=");
//lcd.print( MaxmA );   // print the System Maximum mA
lcd.print( 0);  // print the System Maximum mA
}
#endif
// ******************************************************* END OF FILE

Rob,
The situation where post test power off leave MeanmA displaying a non
zero or near value.
I have repeated this cycle a couple of dozen times and can now reproduce
it as follows:
Power up the test with any load current going thru the ACS712 and MeanmA
is about 25mA
I can repeat this power on/off/on and or press the reset button and
MeanmA is always a nominal  25mA hence the code boots reliably.
However when turning off a say 100w load MeanmA sometimes does not
return to about 25mA or so.
This I can reproduce simple and repeatable as follows:
Power up the system and apply a 100w load.
Switch off the load.
Unplug the ACS712 out pin from analog in A0, lets the analog in A0 float
and MeanmA displays a very large number.
Plug the ACS712 out pin back into analog in A0 and the MeanmA does NOT
return to the nominal  25mA
So it seems that once a large value has be seen at analog A0 the
software losses some  reference point/value.

Hope this helps Ian

Quick look at your code

static int StateCounterState;  has no initial value.
digitalWrite( OUTPUT_TEST_PIN , LOW );  missing in setup().
notice you adjusted ACS.setmVperAmp(99);  Explains improved numbers. (good!)

Power up the test with any load current going thru the ACS712 and MeanmA is about 25mA

I expect it is adding up noise.
Did you test the Noise filtering version already?

Plug the ACS712 out pin back into analog in A0 and the MeanmA does NOT return to the nominal  25mA

Can't explain this scenario, what voltage does the BRYMEN measure on the out pin (frequency?)

This is also what happens with the dimmer, see your scope images (above)
When you do the averaging yourself you can "act upon outliers" after every single measurement.
if (newMeasurement differs less than X % from previous) it is OK
else reuse old Value.

Are you familiar with my runningMedian class, It might be just the trick you need.

Unplug the ACS712 out pin from analog in A0, lets the analog in A0 float and MeanmA displays a very large number.

Yes as it "measures" unknown values and interpret them as good one. Floating lines should be prevented in measurements at all costs. They can disrupt any control process and cause serious damage. You can prevent this by adding a voltage divider of two 1M (or more) resistors to keep the A0 around midpoint.If the ACS changes the 1M are neglectable, if the ACS is disconnected, the two resistors take over.
    5V ------[ 1M ] ------A0------[ 1M ]------GND
                           |
                           |
                          OUT

Another trick is to use only one 1M pull down resistor.
That would give automatic extreme values that

(with mA_AC_sampling) are definitely out of range and easy to recognize and ignore in your code.
(with mA_AC) are identical so min and max are both zero indicating zero mA

The first one is the most safe as the error state is explicit definitely different from "normal" values.

Minimized your test code to a simple loop, to make it more understandable.
//
//    FILE: OVEN_CONTROLLER_PRODUCTION_V5.ino
//    AUTHOR: Ian Knight
//    PURPOSE: Testing Data
//    DATE: 2022-26-Aug.

#include <LiquidCrystal.h>
#include "ACS712.h"// Current sensor

//#define ACS_Pin A0
#define ACS712_CURRENT_SENSOR_ANALOG_PIN               A0
#define ADJUSTABLE_MAX_CURRENT_ANALOG_PIN              A1
#define MEAN_ACS712_SAMPLES_SETS                      10
#define STATE_COUNTER_TICK_RATE                       100// in mS
#define HYSTERESIS_CURRENT_IN_MA                      100
#define OUTPUT_TEST_PIN                               8

ACS712 ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN, 5.0, 1023, 100);

const int rs = 12, en = 11, d4 = 7, d5 = 6, d6 = 5, d7 = 4;
LiquidCrystal lcd(rs, en, d4, d5, d6, d7);

long MaxmA = 0;       // Adjusted maximum current
float MeanmA = 0.0;   // AC721 Mean Current New for multi cycle samples
unsigned long PreviousMillis = 0;

void setup()
{
  // set up the LCD's number of columns and rows:
  Serial.begin(9600);

  lcd.begin(16, 2);         // Init LCD

  pinMode( OUTPUT_TEST_PIN , OUTPUT);
  digitalWrite( OUTPUT_TEST_PIN , LOW );

  ACS.setmVperAmp(99);      // To set the calibration for ACS712 deviation
  ACS.autoMidPoint();       // Init ACS712
}

void loop()
{
  MeanmA = 0.0;

  for (int i = 0; i < MEAN_ACS712_SAMPLES_SETS; i++)
  {
    while (millis() - PreviousMillis < STATE_COUNTER_TICK_RATE);
    PreviousMillis = millis();

    digitalWrite( OUTPUT_TEST_PIN , HIGH );
    //..   MeanmA += ACS.mA_AC( 50.0 );
    MeanmA += ACS.mA_AC_sampling( 50.0, 4);
    digitalWrite( OUTPUT_TEST_PIN , LOW );
  }
  //  calculate the average
  MeanmA /= MEAN_ACS712_SAMPLES_SETS;

  lcd.setCursor(0, 1); lcd.print("                "); // Clear Line 1
  lcd.setCursor(0, 1); lcd.print( "Cur mA's: "); lcd.print( MeanmA );
}    // End loop()

// **** END OF FILE ****

Hello Rob,
I think these development versions of ACS712 library have confused my
system:
As IDE 1.8.19 says  0.2.7 is installed
But IDE 2 RC 9.2 says 0.2.8 is installed, however when i try to
uninstall 0.2.8 from IDE 2 RC 9.2 it reports 0.2.8 is not installed
Hence I am not sure when I build in IDE 2 RC 9.2 which ACS712 library i
am building with.
However I can't see in the arduino library folder tree 0.2.7 or 0.2.8 so
I think they are not there but the IDE's still think they are :-) Ain't
Computers Wonderful!
Now i have done a file search and can see your ACS712-develop library
has a sub folder under arduino and had I a look at the .h and .cpp
and they look the same as the unzipped version off 0.2.8 you say you
have have added a noise filter to.
I
So i think before we test further this library version confusion needs
to be sorted and I don't know how the arduino library structure is managed.
Also OVEN_CONTROLLER_PRODUCTION_V5.ino that i am currently testing with
drifts.
Inasmuch as MeanmA from a cold start or reset will drift from an initial
50mA to 180mA after an hours or so with zero current flow thru the ACS712.
Have a good evening Ian

Think your project setup is affected by noise. You could check with a scope.
the arduino website has an excellent tutorial on libraries. They should be in your personal Arduino folder under libraries. Check preferences in the IDE.
All my libs have a version string, see the .h file
Add Serial.println(ACS712_LIB_VERSION);
It is most of the examples. That should help guard versions.
It is now 6:15 and later today I will merge 0.2.8 and release it as last results are good. (Not perfect)..
Thereafter i want to start with a 0.3.0 soon which will change return types. Mainly from int to float to improve precission. Add some analysis functions, most of that is already written, so can be online almost directly after 0.2.8 is released.
Noise suppression is a topic / issue on its own. That will be investigated for 0.3.x

@imk2021
Can you open a separate issue on the noise level at ZERO amps?

Morning Rob,
Later when 0.2.8 is released i'll retest all so we have a fresh starting
point.
Ian

Good morning!
0.2.8 is released, but possibly not available yet in the library manager.
In the develop branch you can now find the preview of the 0.3.0 version (had some build issues).

Rob,
ACS712 is wired to Nano thus.
ACS712 0V to Nano 0V
ACS712 5V to Nano 5V
ACS712 Out to Nano A0, no other circuitry I just plug in a flying lead
if I want to BREMEN or Scope it
All just jumper-ed on breadboard
Ian

Hello Rob, please find the attached test results:
This data is from a 1kW fan heater so may have slight motor inductive
influence
measure with BRYMEN                                    4.594A
measure with mA_AC();                                   4.437A
measure with RMS_by_sampling();
22:22:42.444 -> 20000
22:22:42.444 -> 0.04888
22:22:42.444 -> 2254.11108
22:22:42.475 -> 20000
22:22:42.475 -> 0.04888
22:22:42.475 -> 2237.93579
22:22:42.514 -> 20000
22:22:42.514 -> 0.04888
22:22:42.514 -> 2237.94189
22:22:42.550 -> 20000
22:22:42.550 -> 0.04888
22:22:42.550 -> 2245.92211
22:22:42.583 -> 20000
22:22:42.583 -> 0.04888
22:22:42.583 -> 2262.14453
22:22:42.623 -> 20000
22:22:42.623 -> 0.04888
22:22:42.623 -> 2254.09643
22:22:42.659 -> 20000
22:22:42.659 -> 0.04888
22:22:42.659 -> 2245.93359
22:22:42.691 -> 20000
22:22:42.691 -> 0.04888
22:22:42.691 -> 2221.63159
22:22:42.731 -> 20000
22:22:42.731 -> 0.04888
22:22:42.731 -> 2230.03393
22:22:42.767 -> 20000
22:22:42.767 -> 0.04888
22:22:42.767 -> 2254.08618
22:22:42.800 -> 20000
22:22:42.800 -> 0.04888
22:22:42.800 -> 2254.08105
I will be at home tomorrow doing the domestic stuff so can test if you
require.
Hope that helps have a good evening Ian.

No direct tests in mind.
As this issue is closed, we might better communicate in issue #23 ?
2254.08105  that looks like exactly a factor 2 from the Brymen...

Hello Rob,
I just thought of an alternative way to using real hardware/embedded
micro  etc to test your mA_AC() function to deal with complex waveform.
Basically use VS2022 community (free) and write a couple of simple
console apps; one to generate a sine wave into an array and or file.
The second is a modified  version of mA_AC() that replaces analogRead()
with read from the array or file record analogReadRecord( n ).
Now you can prove your math really easy without having to upload etc
plus you have a really nice full function debugger in VS2022.
Once this basic mechanize is working you can tweak the sine generator
app to create  sine files of different magnitudes.
You can now hack these sine files where you set to zero some records so
you create a modified sine similar to a dimmed sine.
And or tweak record to have big noise spikes in them. You can then view
the sine files in Excel to check the shape of the etc.
Then just cross compile the VS2022 cpp back into Auduino cpp and test.
I have used this method in the past when using accelerometers to do
tricky math motion analyses.
It works and is much quicker than coding into a tricky to debug
micro-controllers.
Ian

Hello Rob,
Please ignore subject title Professor Jack Stilgoe, this was a copy
paste error as i was reading his work on autonomous car.
Ian

Hello Rob,
I think you will like these results, however i had to hit NANO reset to
clear drift during 500w Dimmed testing, I will look into this later
Ian
Test Set Four 28-Aug-2022 1300
mA_AC_sampling() 40 calls per sec.
OVEN_CONTROLLER_PRODUCTION_V5
released library version 0.2.8
ACS712 Calibration load 1000w Brymen 4476mA
ACS712  ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN , 5.0, 1023, 101 );
MeanmA=4310
ACS712  ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN , 5.0, 1023, 100 );
MeanmA=4365
ACS712  ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN , 5.0, 1023, 99 );
MeanmA=4412
ACS712  ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN , 5.0, 1023, 98 );
MeanmA=4443
ACS712  ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN , 5.0, 1023, 97 );
MeanmA=4480
Therefore all test result below where at  ACS712 Calibration value of 97
Other Load Testing Below:
Not Dimmed
100w  Brymen=0.426  MeanmA=458.2
200w  Brymen=0.823  MeanmA=883.5
300w  Brymen=1.248  MeanmA=1281.9
500w  Brymen=2.048  MeanmA=2067.5
1000w Brymen=4.485  MeanmA=4471.8
200w Dimmed
Brymen=0.48    MeanmA=477.5 Min Dim
Brymen=0.6     MeanmA=591.9
Brymen=0.703   MeanmA=694.5
Brymen=0.816   MeanmA=800.5 Max Dim
500w Dimmed
Brymen=1.188   MeanmA=1176.2 Min  Dim
Brymen=1.301   MeanmA=1285.1
Brymen=1.400   MeanmA=1376.4
Brymen=1.501   MeanmA=1481.0
Brymen=1.603   MeanmA=1585.0
Brymen=1.704   MeanmA=1671.5
Brymen=1.806   MeanmA=1777.7
Brymen=1.906   MeanmA=1894.3
Brymen=2.000   MeanmA=1974.4
Brymen=2.028   MeanmA=2000.5 Max  Dim

Those numbers look almost perfect. they are almost all within a 1% range which is pretty OK.
you can tune the mVperAmpere parameter with decimals, e.g 96.28
```ACS712  ACS( ACS712_CURRENT_SENSOR_ANALOG_PIN , 5.0, 1023, 96.3 );````

I just thought of an alternative way to using real hardware/embedded
micro  etc to test your mA_AC() function to deal with complex waveform.

I did test my concept-code in Excel in a similar way.
filled data of a sinus with a defined noise. and a certain sampling rate and compared the different methods.
Using the real code as you propose was also done. In fact that code is lying around to make an ACS class with an external ADC. Thinking of an MCP49xx (SPI based ADC) which is much faster and would to preprocess while sampling.


Add the i18n support for modules

What is the motivation for adding / enhancing this feature?

Chris (MDM):
Hey, im working on an module and want to add my own i18n file for translation only in the module. Is it possible and how?
I add this structure directly in my /modules/module_name/ folder
But how can i include this files?
pkarw:
Hey Chris, we never did sth like this before :slightly_smiling_face: Currently i18n can be added only on the core or theme levels :disappointed:
you can still use the i18n helpers of course.
This sounds like a good PR to the core  - please take a look at this file: https://github.com/DivanteLtd/vue-storefront/blob/595c284a56f798f625a8d3ea69edbd7c244f4ae9/core/build/webpack.base.config.ts#L29
What are the acceptance criteria

[ ] module can add their own translations / i18n

Can you complete this feature request by yourself?

[ ] YES
[ ] NO

Which Release Cycle state this refers to? Info for developer.
Pick one option.

[x] This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
[ ] (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
[ ] (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

I will take this


When will it be compatible with Mac?

please add mac support

@lcl-101 @cooltings Please close this issue, this is already planned and set to be released with macrodeck 3
Announcement made in the Macrodeck Discord.
https://discord.gg/yQBmHFD8
https://discord.com/channels/869913729939148800/869915818480271410/1186436784704462978

Planned for Macro Deck 3.
Also duplicate. See #376.


[#24024] Stop wrapping light weight functions with Contextful as they add a lot of overhead for functions that are meant to do almost no work.

Fixes #24024
Stop wrapping light weight functions with Contextful as they add a lot of overhead for functions that are meant to do almost no work.

Whole profile is 33.64s. We can eliminate (36.94-19.19)+(92.42-37.9) millis from which leads to a 0.2% performance improvement for the pipeline but leads to substantially larger gains for trivial lambdas. It may lead to a larger improvement as we are reducing the wasteful creation and destruction of the wrapped context.
See attached pprof data.
profile (47).pb.gz

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.


Cold Tier

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Storage.Blobs


vimPlugins.nginx-vim: init at 2021-02-25

Motivation for this change
Add https://github.com/chr4/nginx.vim
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 117118 at 85d8cdd8 run on aarch64-linux 1

2 packages built successfully:

spacevim
vimPlugins.YouCompleteMe


Missing: Get Started '--host' additional dependencies

Clicking the 'additional dependencies' link in the doc, which should take me to "https://docs.localstack.cloud/get-started/#developing", takes me nowhere.

This was already fixed with this PR: https://github.com/localstack/docs/pull/213


Fix description of CMAKE_FIND_ROOT_PATH_MODE_* in cross compiling

This PR corrects the wrong description in cross compiling article.

Thank you for the fix.
Please use the phrase "Fixes #241" in future PR so that the referenced issue gets closed automatically when the PR is merged.


Problem querying RDF containing a triple with an object of type XSD double

I'll demonstrate the problem using the Sparqlify example: https://github.com/SANSA-Stack/SANSA-Examples/blob/develop/sansa-examples-spark/src/main/scala/net/sansa_stack/examples/spark/query/Sparqlify.scala.
Add a triple to src/main/resources/rdf.nt with an object of type XSD double. E.g., simply replace the following triple:
<http://commons.dbpedia.org/resource/Category:People> <http://commons.dbpedia.org/property/width> "100.0"^^<http://dbpedia.org/datatype/perCent> .

with:
<http://commons.dbpedia.org/resource/Category:People> <http://commons.dbpedia.org/property/width> "100.0"^^<http://www.w3.org/2001/XMLSchema#double> .

Run the Sparqlify class in the server/endpoint mode pointing to the rdf.nt as input (--input src/main/resources/rdf.nt). Execute the simple SELECT * WHERE {?s ?p ?o} query in the browser. Observe the error in the server console.
Exception in thread "Thread-37" java.lang.RuntimeException: java.lang.RuntimeException: org.apache.spark.sql.catalyst.parser.ParseException:
mismatched input 'FROM' expecting <EOF>(line 2, pos 0)

Fixed; This was a bug in the datatype to sql-string mapping: Instead of "double" in the generated Spark SQL it was incorrectly "double precision" resulting in the catalyst parse exception with the not very helpful message.


Publish v1.2.0

We should publish v1.2.0 to npm. I would just look through the diff, make sure that linting is :+1: and publish it.

I agree

@greg-js We should aim to publish a new version now! Can you take care of it?

I checked for linting errors, bumped the version number, added the tag and pushed to GH but I can't publish it to npm. Gives me a 404, but I suspect the real reason is collaborator settings in npm. Can you publish it to npm and then I'll write up the changelog and draft the release on GH afterwards :-)


fix: Synchronize all access to firestoreInstanceCache.

Description
Synchronize access to firestoreInstanceCache.
Related Issues

https://github.com/firebase/flutterfire/issues/16668

Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

[X] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[X] All existing and new tests are passing.
[ ] I updated/added relevant documentation (doc comments with ///).
[X] The analyzer (melos run analyze) does not report any problems on my PR.
[X] I read and followed the Flutter Style Guide.
[X] I signed the CLA.
[X] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change.
[X] No, this is not a breaking change.

Closing out in favour of: https://github.com/firebase/flutterfire/pull/16675
@tdickopp - Thank you for raising this issue 🙏


Can I use a model trained with firebase auto ml vision edge immediately?

I want to detect a real-time object with flutter's camera package. Will we be able to use models trained with auto ml edges in the future?

If there is a need, I'll try support AutlML.
Or you can use other plugin like below,

https://github.com/firebase/mlkit-custom-image-classifier
https://github.com/shaqian/flutter_realtime_detection

Thanks 😄

필요한 경우 AutlML 지원을 시도합니다.
또는 아래와 같은 다른 플러그인을 사용할 수 있습니다.

https://github.com/firebase/mlkit-custom-image-classifier
https://github.com/shaqian/flutter_realtime_detection

감사 😄

I applied a model trained with auto ml Edge using the example 'https://github.com/shaqian/flutter_realtime_detection' and I get an error.
I overwrote the tflite file I trained instead of the example file. How can I use it?
Thank you for your attention.

If there is a need, I'll try support AutlML.
Or you can use other plugin like below,

https://github.com/firebase/mlkit-custom-image-classifier
https://github.com/shaqian/flutter_realtime_detection

Thanks 😄

I applied a model trained with auto ml Edge using the example 'https://github.com/shaqian/flutter_realtime_detection' and I get an error.
I overwrote the tflite file I trained instead of the example file. How can I use it?
Thank you for your attention.

I overwrote the tflite file I trained instead of the example file. How can I use it?

Please ask in mlkit-custom-image-classifier.


[A chess game]

Description
would like to make a new chess game
Screenshots
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a SWOC'24 contributor

please assign this to me @pinak22dhir

Hi, I would like to work on this issue. Could you please assign it to me? @pinak22dhir

waiting for commit @Shashikumar-ezhilarasu , happy coding

Thank you ,will update once the work is done .

I'm done creating the pr ,can you please check @pinak22dhir ,Thank you


[Bug]: getServerSideProps not triggered

Provide environment information
package versions used:
"@serwist/next": "^8.4.4",
"@serwist/precaching": "^8.4.4",
"@serwist/sw": "^8.4.4",
Which project is this issue for?
@serwist/next
Link to reproduction - Issues with a link to complete (but minimal) reproduction code help us address them faster

To reproduce
sw.js file:
import { defaultCache } from "@serwist/next/browser";
import { installSerwist } from "@serwist/sw";

// Anything random.
const revision = crypto.randomUUID();

installSerwist({
  // eslint-disable-next-line no-restricted-globals
  precacheEntries: self.__SW_MANIFEST,
  skipWaiting: true,
  clientsClaim: true,
  navigationPreload: true,
  runtimeCaching: defaultCache,
  fallbacks: {
    entries: [
      {
        url: "/offline",
        revision,
        matcher({ request }) {
          return request.destination === "document";
        },
      },
    ],
  },
});

next.config.js
const withSerwist = require("@serwist/next").default({
  cacheOnFrontEndNav: true,
  swSrc: "sw.js",
  swDest: "public/sw.js",
  reloadOnOnline: true,
  disable: process.env.NODE_ENV === "development", // to disable pwa in development
  // ... other options
});

Describe the bug
I recently moved to serwist from next-pwa as i'm slowly going to start migrating to app directory.
While i'm not in app directory yet i noticed that somehow when i do a route change in the browser it seems to pull a fully cached page back and not trigger getServerSideProps anymore and my data comes back empty that i expect to be there.
It's working all fine without service workers involved and with next-pwa this was working properly as well.
If i stay on the page and then actually refresh the browser all the data shows up.
I also tried setting navigationPreloa, clientsClaim and cacheOnFrontEndNav to false without much success.
minimal repo will be tough this seems to also only happen when i run nextjs build. if i enable service worker in local dev environment everything works just fine.
Expected behavior
i expect that my data still comes back from getServerSideProps when a nextjs Link component is clicked.
Screenshots (if relevant)
No response
Additional information (if relevant)
No response

so after doing some digging reverting back to next-pwa i was seeing the same issues show up there. it has to do with the cache strategy in the service worker that is being used there, so maybe this helps with this issue as well but this is what fixed it for me for next-pwa:
https://github.com/vercel/next.js/discussions/51454

@mick-feller oh, thanks for investigating! This behaviour will be changed in v9.

@mick-feller will most likely come with 9.0.0-preview.4! You can use Serwist preview for now, then migrate back to stable later. Up to you, though.

@mick-feller should be fixed in the latest preview :) Closing this issue.

@DuCanhGH upgraded to serwist preview and working like a charm! thanks for the quick fix!


[Question] How to set maximumSize on DialogWindow/ComposeDialog?

Setting maximumSize on ComposeDialog when creating a custom DialogWindow does not restrict resizing, but setting minimumSize does, as seen here:

Custom dialog window implementation
Creating custom dialog window:
TransparentDialog(
    resizable = true,
    maximumSize = Dimension(576, 1024),
    minimumSize = Dimension(360, 360),
) {
    // ...
}

I don't know if this is a Swing or Compose problem.

maximumSize here is JDialogs setter, it's not Compose.
Your snippet relays on other not-published code, so I had to simplify it to reproduce the issue on my end. So, yep Swing ignores max size if isUndecorated == true.
I tried to control it with this workaround:
addComponentListener(object : ComponentAdapter() {
    override fun componentResized(event: ComponentEvent?) {
        val width = size.width.coerceIn(minimumSize.width, maximumSize.width)
        val height = size.height.coerceIn(minimumSize.height, maximumSize.height)
        setSize(width, height)
    }
})

but it doesn't work well - the callback is called with delay causing visual glitches. I'm posting it here just to give you some direction for possible workarounds.
Anyway, I'm closing this topic as it's not related to Compose.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Enforce 4 space indentations on [codeblock]

While I was reading MainLoop, I found the indentation of codeblock in the page messed up.
Even though we states that we need to use 4 spaces in [codeblock]in Improve formatting with BBcode style tags, considering that Godot's default indentation character is \t and alternating between two ways of indentation in a file is quite cumbersome, it's prone to make mistakes like this.
Instead of manually fixing this one page, after reading doc/tools/makerst.py, I figured out we can enforce this by making a small change.
Here is the diff of "Before and After" of the output files of make rst:
https://github.com/yeonghoey/godot/commit/816c20144c7d97ed1e5ee0df83f29dfd57e6a3d3

It's ok to make makerst.py more resilient, but it needs to spit out errors when it encounters such a formatting issue, even if it can work it around when generating the rst.
As we need to fix the XML in any case, otherwise the editor is broken too:

Thank you for feedback.
It seems that we have three options:

Find and fix all of the places where depend on this \t indent removing behavior.
After that, we can delete the statement always use four spaces for indentation and remove all the 4 space indentations within [codeblock] of doc/classes/*.xml
Since this is a breaking change, it may introduce other issues, but eventually, I think it's the best way to go. Considering that documents change far more frequently than the parser code, making documention eaiser and consistent would be worth it.

Add a kind of fmt script which fixes xml files by replacing \twith 4 spaces when it's appropriate. This is not as clear as (1), but asking documentor to run a command is a lot eaiser than making them manually fix indentations. This requires to come up with a new tool script.

Make makerst.py fail and print out an error when we detect an undescired indentation. This is the easiest  way but it still burdens the contributors with manually fixing indentations.

I believe that picking a way to improve really depends on the domain of the problem.
Since I'm pretty new to Godot, can I ask you which way do you think is the best?

I'd go for 3.
The indentation with tabs in the XML is used for the actual XML elements, while the 4-space indentation is used for code blocks. It was actually done this way on purpose to have a clear separation between XML indentation and code indentation.
While it would be easy to tweak both the DocData parser and the rst generator to handle both gracefully, this would mean accepting inconsistent style within the documentation. I prefer to put slightly more work on contributors to have a consistent output, especially since we don't have any good linter or formatter for our XML format.
That being said, an option could be to make DocData be able to load both styles, but also dump with the proper 4-space style. But this could lead to situations where a mix of tabs and spaces produced a correct visual indentation while converting it to tabs would break the actual code block's logical indentation.

About (1), I'm not saying we need to support the mixed style. I'm saying that it's generally better to use one indentation style in a file than to use a two styles for different purposes.
I'm not sure how valuable it is to have a clear indent separation between XML and code, but I do believe that having one single way of indentation within a file is also important for document consistency and easiness to update.

Anyway, I value your opinion and just let me know if you still want to go for (3). I will update my PR

I would say going for (3) is the simplest and least disruptive change, so I'd go for it right now. It doesn't impact the documented workflow nor the format of all files.
Then we can discuss further (maybe in a https://github.com/godotengine/godot-proposals issue?) how to improve the system, possibly going with one of the other options we discussed for Godot 4.0.

I agree with the point. I'll prepare the update to go for (3) for now and check out https://github.com/godotengine/godot-proposals

Overall, I decided to be a little bit conservative here and I didn't make it fail even after we identified a possible issue.
As a side note, it seems that people implicitly agree that the lines within [codeblock] should be indented with \t as much as the open tag [codeblock] before the actual content starts. I thought about adding this check, too, but the more I thought about it, I decided not to do so because it's not codified.

Using the feature, I found some new changes with inconsistent styles and I fixed them.

Looks great! Could you squash the two commits together?

Done. I'm glad you like it :)

Thanks!

Thanks! It was great that I was able to contribute to the project I lvoe


post message for balanced open requests

Posts a message when a balanced channel open request is received.
Files changed:
interface/icons.json
post/get_received_message.js
post/post_settled_invoice.js

https://github.com/alexbosworth/balanceofsatoshis/issues/233

merged it


Error: Unauthorized request from http://x.x.x.x:yyyy

Just reporting this in case you haven't seen this on your own machine:
Error: Unauthorized request from http://<IP_ADDRESS>:8081. This may happen because of a conflicting browser extension to intercept HTTP requests. Please try again without browser extensions or using incognito mode.
    at /Users/theo/projects/monarch/mobile/node_modules/@expo/cli/src/start/server/middleware/CorsMiddleware.ts:26:11
    at call (/Users/theo/projects/monarch/mobile/node_modules/connect/index.js:239:7)
    at next (/Users/theo/projects/monarch/mobile/node_modules/connect/index.js:183:5)
    at suppressRemoteDebuggingErrorMiddleware (/Users/theo/projects/monarch/mobile/node_modules/@expo/cli/src/start/server/middleware/suppressErrorMiddleware.ts:16:3)
    at call (/Users/theo/projects/monarch/mobile/node_modules/connect/index.js:239:7)
    at Immediate.next [as _onImmediate] (/Users/theo/projects/monarch/mobile/node_modules/connect/index.js:183:5)

The built-in react devtools run fine (and doesn't emit that error) and it's also via this port as well, so it might not be an issue.
It doesn't prevent me from running the redux devtools plugin, though.
My setup follows the RTK example you have.

Hello. Thanks for reporting this.
Where exactly is this error being reported? Is this from the Expo CLI or in the browser console when the dev tools are open?

This is when I select the plugin from the CLI after hitting shift + M (in macOS)

When you say this:

It doesn't prevent me from running the redux devtools plugin, though

Does this mean that you are able to use this devtools plugin even though you're getting this error? Does it stop you doing anything?

Works without problems

Ok. In that case I'm going to close this issue. If you're able to reproduce the issue and find out why it's happening then feel free to open a new issue with details about it and we can try to fix it.
Thanks again.

The issue does happen, it's reproducible on my machine, just don't know what causes it. It doesn't seem to interfere with my ability to use the plugin.

I know the issue is happening on your machine, but a proper reproduction would allow us to see the issue on other machines.
If you can figure out the root cause then feel free to open a new issue. A new issue is easier for me to find than a comment on a closed issue.