Add threshold parameter for negative rate detection

[caco3]

The Feature

the negative rate detection has no tolerance, thus the slightest more negative value triggers a neg. rate error.
I see this quite often, but its always around exact 2.0000000063191692e-05 resp. 0.00002000000006319169 (my smallest analoque pointer is on 0.0001) wich is 5 times smaller than my smallest analogue pointer..

A threshold for this error would be handy.

[SybexX]

In my personal version I did it like this:

if (PreValueUse && NUMBERS[j]->PreValueOkay)
{
    if (NUMBERS[j]->Nachkomma > 0)
    {
        double _difference1 = (NUMBERS[j]->PreValue - (5 / pow(10, NUMBERS[j]->Nachkomma)));
        double _difference2 = (NUMBERS[j]->PreValue - (1 / pow(10, NUMBERS[j]->Nachkomma)));
        double _difference3 = (NUMBERS[j]->PreValue + (5 / pow(10, NUMBERS[j]->Nachkomma)));
        double _difference4 = (NUMBERS[j]->PreValue + (1 / pow(10, NUMBERS[j]->Nachkomma)));

        if (((NUMBERS[j]->Value >= _difference1) && (NUMBERS[j]->Value <= _difference3) && (NUMBERS[j]->isExtendedResolution))
            || ((NUMBERS[j]->Value >= _difference2) && (NUMBERS[j]->Value <= _difference4) && (!NUMBERS[j]->isExtendedResolution)))
        {
            NUMBERS[j]->Value = NUMBERS[j]->PreValue;
            NUMBERS[j]->ReturnValue = std::to_string(NUMBERS[j]->PreValue);
        }
    }

    if ((!NUMBERS[j]->AllowNegativeRates) && (NUMBERS[j]->Value < NUMBERS[j]->PreValue))
    {
        ...........
    }

    if ((NUMBERS[j]->useMaxRateValue) && (NUMBERS[j]->Value > NUMBERS[j]->PreValue))
    {
        ............
    }
}
..........

[caco3]

Grundsätzlich ist die Funktionalität schon einkompiliert:
https://github.com/jomjol/AI-on-the-edge-device/blob/rolling/code/components/jomjol_flowcontroll/ClassFlowPostProcessing.cpp#L852

// Include inaccuracy of 0.2 for isExtendedResolution.
if ((NUMBERS[j]->Value >= (NUMBERS[j]->PreValue-(2/pow(10, NUMBERS[j]->Nachkomma))) ...

Wenn ich mir vom ESP 2/pow(10, NUMBERS[0]->Nachkomma) ausrechnen lasse, gibt das bei 5 Nachkomastellen 0.00002000000000000000
Mein Error ist jedoch minimal grösser: 0.00002000000006319169

Ich vermute, dass das ein Rundungsfehler ist. Schliesslich lässt sich 0.00002 gar nicht rundungsfrei als flout/double darstellen:

Siehe https://www.h-schmidt.net/FloatConverter/IEEE754.html

Ich denke, die richtige Lösung ist, die 0.2 auf 0.25 zu erhöhen:

// Include inaccuracy of 0.25 for isExtendedResolution.
if ((NUMBERS[j]->Value >= (NUMBERS[j]->PreValue-(2.5/pow(10, NUMBERS[j]->Nachkomma))) ...

Das entspricht dann 0.0000250000000000000 und sollte keine Nebeneffekte haben.

@jomjol, was Denkst Du dazu?

[SybexX]

Szenario, Wasserzähler ändert sein Wert nicht:

1. Startwert für NUMBERS[j]->Value und NUMBERS[j]->PreValue 123.45678

2. NUMBERS[j]->Value = 123.45679 >>> NUMBERS[j]->PreValue = 123.45679

3. NUMBERS[j]->Value = 123.45677 >>> NUMBERS[j]->PreValue = 123.45679

4. NUMBERS[j]->Value = 123.45676 >>> NUMBERS[j]->PreValue = 123.45679 >>> Fehler Neg. Rate - Read:...

5. NUMBERS[j]->Value = 123.45680 >>> NUMBERS[j]->PreValue = 123.45680

6. NUMBERS[j]->Value = 123.45678 >>> NUMBERS[j]->PreValue = 123.45680

7. NUMBERS[j]->Value = 123.45677 >>> NUMBERS[j]->PreValue = 123.45680 >>> Fehler Neg. Rate - Read:...

8. NUMBERS[j]->Value = 123.45676 >>> NUMBERS[j]->PreValue = 123.45680 >>> Fehler Neg. Rate - Read:...

9. NUMBERS[j]->Value = 123.45678 >>> NUMBERS[j]->PreValue = 123.45680

10. NUMBERS[j]->Value = 123.45679 >>> NUMBERS[j]->PreValue = 123.45680

11. NUMBERS[j]->Value = 123.45677 >>> NUMBERS[j]->PreValue = 123.45680 >>> Fehler Neg. Rate - Read:...

12. NUMBERS[j]->Value = ........

Dies ist ein normales Szenario und kommt meistens in der Nacht vor, wo kein Wasser verbraucht wird.
Ich gehe mal davon aus dass es bei jeden so ähnlich sein wird,
bei Einigen wird es stärkere Schwankungen und bei Anderen etwas schwächere geben.
Deshalb überprüfe ich immer auf +/- Differenz und habe den Wert auf 5 (PreValue +/- 0.00005) gesetzt.

Mit meiner Erweiterung sieht es dann so aus:

1. Startwert für NUMBERS[j]->Value und NUMBERS[j]->PreValue 123.45678

2. NUMBERS[j]->Value = 123.45679 >>> NUMBERS[j]->PreValue = 123.45678

3. NUMBERS[j]->Value = 123.45677 >>> NUMBERS[j]->PreValue = 123.45678

4. NUMBERS[j]->Value = 123.45676 >>> NUMBERS[j]->PreValue = 123.45678

5. NUMBERS[j]->Value = 123.45680 >>> NUMBERS[j]->PreValue = 123.45678

6. NUMBERS[j]->Value = 123.45678 >>> NUMBERS[j]->PreValue = 123.45678

7. NUMBERS[j]->Value = 123.45677 >>> NUMBERS[j]->PreValue = 123.45678

8. NUMBERS[j]->Value = 123.45676 >>> NUMBERS[j]->PreValue = 123.45678

9. NUMBERS[j]->Value = 123.45678 >>> NUMBERS[j]->PreValue = 123.45678

10. NUMBERS[j]->Value = 123.45679 >>> NUMBERS[j]->PreValue = 123.45678

11. NUMBERS[j]->Value = 123.45677 >>> NUMBERS[j]->PreValue = 123.45678

12. NUMBERS[j]->Value = ........

Ich weiß dass dadurch die Letzte Stelle nicht wirklich brauchbar ist, jedoch ist mir dies persönlich auch egal,
da sie sowieso nicht wirklich zuverlässig ist.

[friedpa]

Das ist mir auch schon aufgefallen, kannst Du daraus eine Rolling machen?
Überhaupt hat es in den letzten Monaten keinen Master mehr gegeben..... sollte es da nicht wieer einmal einen geben?

[caco3]

@SybexX Ja, mach doch mit deinen Änderungen mal einen Branch, dann teste ich das bei mir mal.

@friedpa Wir haben rolling jeweils dann in den master gemerged, wenn wir ein neues Release gemacht haben. Und ja, ich denke, es wäre wieder einmal Zeit dafür.

Ich muss zugeben, dass ich nach dem letzten Release (15.7.0) etwas frustriert war, da so viele Leute gesagt haben, es funktioniere bei ihnen nicht. Es gab da ja zahlreiche neue Einstellmöglichkeiten, und ich denke, die Leute waren einfach zu bequem (um nicht zu sagen faul), sich damit zu befassen und sind lieber auf eine alte Version zurück. Ich vermute, das wird beim nächsten Release wieder ähnlich tönen :(

Wenn ich mir aber unsere Download-Statistik anschaue (https://caco3.github.io/AI-on-the-edge-device_release-history/), hat die 15.7.0 mit über 20'000 Downloads mehr Downloads als jedes andere Release. Wenn wir da wirklich gröbere Fehler eingebaut hätten, würden wir mehr Supportanfragen sehen.

[Ingo-Knito]

Dies ist zwar etwas off-topic, aber vielleicht erwähnenswert: Meiner Meinung nach ist die 15.7 äußerst stabil - und ich habe eine Menge (aktuell 24) am laufen.

Allerdings hatte ich reproduzierbar Probleme nach dem Update auf die 15.7 mit der ext. Beleuchtung. Immer wieder viel zu dunkel trotz Einstellung in der Konfiguration und Referenzimage.

Ja, alle Optionen bei der Beleuchtung kurz angefasst und gespeichert. Aus meiner Sicht werden bei einem Update nicht alle beleuchtungsrelevanten Parameter in der config.ini gesetzt. Daher vielleicht die Kommentare?

[caco3]

@Ingo-Knito Danke für dein Feedback! Könntest Du diese Issues in einem separaten bug report dokumentieren? Ich verwende keine externen LEDS, daher kann ich das selber nicht testen. AN der Ansteuerung der LEDs haben wir aber (soviel ich weis) nichts geändert. Es müsste also an den Kamera-Einstellungen liegen.
Ev. ist ja der Fehle rim aktuellen rolling schon gefixt?

P.S: Wie kommst Du auf 24 Zähler? Sind die alle in deinem Haushalt oder verteilt?

[Ingo-Knito]

Nein, im Rolling ist es wahrscheinlich nicht gefixt. Der letzte Test vor zwei Wochen war nicht positiv.
Das Problem ist, dass man es nur optisch sieht. Die Version selbst läuft absolut perfekt. Da die ext. LED viel zu dunkel leuchten,
läuft das Alignment gegen die Wand und auch die Erkennung läuft schief.

Zum Test habe ich die gesamte [TakeImage]-Section übernommen und dann hat es funktioniert. Die Section hat inzw. deutlich mehr Einträge in der Ini. Vermutlich werden die beim Update nicht alle gesetzt und führen dann zu defaults.

Die Zähler sind auf aktuell zehn Gebäude verteilt. Längere Geschichte :-)

Ich setze mal einen Test auf, führe ein Update durch und erstelle dann einen Issue.

[SybexX]

Mit CamGainceiling kannst du die Belichtung des Bildes erhöhen und dadurch die LED Intensity reduzieren können (um eventuele Spiegelungen/Reflektionen im Bild zu reduzieren). Ich habe den Wert auf x8 stehen und konnte dadurch die LED Intensity von 80 auf 45 reduzieren. Wenn der Wert zB. auf x2 steht, kannst du noch so helles Licht haben und das Bild bleibt dunkel.

[Ingo-Knito]

Guter Tipp. Werde das mal testen.

Gut wäre es, wenn der Wert im UI eingestellt werden könnte - gefunden habe ich den im UI nicht. Weder im ReferenzImage noch in der Experten-Konfiguration.

Daher direkt in der config.ini editiert.

[Ingo-Knito]

Hmm. Verständnisproblem bei mir.

Vielleicht wird beim Update das CamGainceiling auf X2 gesetzt. Dann würde es passen, warm das Photo nach einem Update dunkel bleibt

[SybexX]

Er ist unter Settings/Configuration zu finden, zumindest beim rolling. Der Standardwert ist eigentlich x4.
Das Problem bei den Kameraeinstellungen ist, dass fast alle Einstellungen voneinander abhängig sind.
CamGainceiling wird zB. soweit ich weiß, nur beachtet wenn Auto-Exposure Control 2 aktiviert ist.

[SybexX]

https://github.com/SybexX/AI-on-the-edge-device/actions/runs/10257348244

[caco3]

@SybexX Danke, werde es testen. Ich habe aber keinen Weg, es real zu provozieren, daher ist wohl das einzige Indiz für die Verbesserung, dass der neg. rate error nicht mehr kommt.

Ich habe mir deinen commit angeschaut. Da scheinen neben dem Fix auch ganz viele Formatierungsänderungen dabei zu sein. Ich würde vorschlagen, dass Du das in separate PRs oder mindestens separate Commits aufteilst, damit das review einfacher geht.

[SybexX]

Die meisten Formatierungsänderungen wurden von Visual Studio Code gemacht^^

[caco3]

@SybexX Your fix looks good, I had far less neg. rate errors in the last weeks.
I suggest you add a PR and we merge it.

[SybexX]

There are several approaches that are possible:

1. we use a fixed value
2. we make the value adjustable via the config page
3. we make the value dependent on the decimal places (value = 123.456 >>> +/- 0.003) (value = 123.4567 >>> +/- 0.0004)
4. We make the value dependent on the type of ROI (digital/analog/digital+analog), my digital numbers are far more reliable than the analog ones (digital: value = 123.456 >>> +/- 0.002) (analog/digital+analog: value = 123.456 >>> +/- 0.005)

Variants 1, 3 or 4 are probably more user-friendly
However, we will probably achieve the best result with variant 2

Which variant do we want to take?

[caco3]

I would go with variant 2. There are tons of different meters and some users even report that their water meter effectively slightly turns backwards over night. This if we use a fixed value, it is just a question of time until somebody requests a different value.

If we keep it configurable, we can avoid this.
It helps the user more if we properly explain the functionality and how to set it.
As a start value we could go with 0.0002 since most water meters have 4 analogue pointers.
The documentation then could suggest to use the decimal position of the smallest ROI times 2 (`0.000x -> 0.0002).

For the record my last 180 neg rate errors ordered by the rate:

Logarythmic:

[SybexX]

What do we want to call the variable then? In terms of function, it is very close to hysteresis.
PreValueHysterese?

[caco3]

Hysteresis indeed would be the technically correct term, but I am not sure if it would be understandable.
What about neg. rate threshold?

[SybexX]

[caco3]

Thanks @SybexX for this enhancement!
#3195