Rate Change no longer grows with time #2505
Comments
|
Not analysed as much as @adellafave did 👍, because I was looking at existing issues first 😉, but I came here, because I noticed the same issue (form the behaviour). Have a |
|
Maybe a false flag from my side (or another bug), because I'm not on |
|
I just ran into this issue last night and came to the same conclusion as @adellafave. I calculated my "MaxRateValue" as a maximum volume of water that could theoretically flow through my pipes per minute. One of my readings were skipped because of incorrect digit recognition/negative value. During that/the next reading, my sprinklers were running and a "large" volume of water was used. On the next reading attempt, it got the correct values from the image/meter, but failed because the difference between the "previous" and "read" was greater than my calculated max rate. Since this error, the difference between the "reads" and the "previous" values has continued to grow, while being divided by my static "Interval" rate of 3. This growing number is compared against a static "MaxRateValue" and will never break free of the error loop. I see @adellafave submitted a pull request #2511 in July that states should fix this issue but the merge has yet to happen. |
|
I'm having the same problems with v15.3.0. |
|
Since the fix is not yet merge officially, what would be the easiest way for me to get this fix on my device? |
|
I have based the mentioned PR on the latest release (15.7.0) and let GitHub actions build the firmware: https://github.com/dsander/AI-on-the-edge-device/actions/runs/8638590079?pr=1 The change seems to be working well for me, the meter no longer gets stuck. AI-on-the-edge-device__update__1_merge_(aa612a1).zip |
|
Yes, the issue is till happening with And even while knowing latest since |
The Problem
In #1839 a line of code was added to the RateChange type logic to update the lasttime with the image time in the case of a RATE TOO HIGH error. Previously, lasttime was only updated upon success. This seems to have the effect of not allowing Rate Change to catch up over time. Is this intentional? If a single jump goes over the Rate Change limit, an error is declared, but since the Prevalue is not updated yet the meter keeps running, the delta only gets larger over time and the interval time stays fixed. This causes a Rate Too High error to become unrecoverable without manually updating a prevalue. Please evaluate if this was intended functionality.
Version
Development-Branch: rolling (Commit: 61efe1a)
Logfile
Expected Behavior
Because the difference is alway divided by 3 minutes now instead of a number that grows with the time since last valid reading, the system is never able to catch up and the error simply grows over time.
I would have expected that the first delta went over rate by a little, then the next time around it would see a delta of 6 minutes, and if the new difference was within bounds for a 6 minutes delta then it would be accepted, otherwise it would try again next time for a 9 minute delta, etc.
Each time the time divisor typically grew to allow the allowed delta to grow over time.
Screenshots
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: