Wrong Raw Value? #2857
Comments
|
Had the same issues and I was also becoming crazy to understand how to fix |
|
I can add, that I have it the other way around... Not sure whats happening since it does that. 2024-02-03T14:08:56+0100,main,00965.02911,966.02911,966.02911,0.002225,0.01109,no error,10.0,0.0,9.0,6.0,5.1,0.6,3.1,9.0,1.1 |
|
Meanwhile, I have
Yet, no change. Instead of 1017, it still shows 1016.
|
|
On a short test with recent rolling before 15.5, I also realized this. But at this time it seems that it was only wrong on my side. Checking recent PRs show there was a larger change in post-processing strategy recently and I assume it's related to this: #2778 In my opinion it's either a bug in logic or the behaviour of parameter Analog/Digital Transition Start is totally different. |
|
I can also confirm this problem with version 15.5.0 |
|
To me, it appears as if this behaviour only exists when you first start version 15.5.0. |
|
I might have the same problem. Digit x1m3 is sometime recognized correctly as 8 and in some cases as 7... |
|
I have the same problem, worked correctly before. This discussion in the change #2778 is only about early transition, late transition is ignored?? The last digital digit remains a little low (e.g. 2 recognized as 1.9). digits = { 2.0, 5.0, 1.9}; |
I implemented this change. I have to admit, that I experienced the same issue with late transition and a hanging digit, similar to what you describe. I'll have a look into it. |
|
@gec75 How did you set your "Analog/Digital Transition Start" value? I have tested your values with 9.2, then it seems to work. |
|
It was by default 9.2, I also tried with other values... |
Thank you very much ! Decimal-Shift = 3: 777124.1 I reproduced this 3 times in a row by enabling / disabling the Decimal-Shift. |
|
Aaaa! Yes, I also use Decimal shift! |
|
@marcniedersachsen Thanks a lot. This will push me into the right direction. I'll play around with the decimal shift. What shift are you using? Update: okay I see, you are using a shift of 3 |
|
I'm using 3, getting liters (instead of m^3). |
Same with me. But no malfunction since I disabled Decimal-Shift since yesterday 22h. |
|
I could change it... but it will create a big mess in Home Assistant... |
Very much true... I use FHEM and have disabled device logging for temporary testing purposes. Will switch back to decimal-shift = 3 when issue is solved to get liters reported again. |
|
@gec75 I definitely have the ambition to fix this bug. Sure, I's a workaround to disable the conversion to liters, but it's not a proper solution. |
|
I have the same behavior with decimalshift active but 0. Recognized correctly but shows m^3 - 1 |
|
|
I also have the problem that the read value before the decimal point is 1 too high compared to the raw value. The raw value is correct. |
|
Same issue here: The digits before the decimal point are digital, the digits after the decimal point are analogue. The last digital value is always read correctly, but the RAW value is one number too low. What is weird is that sometimes it does work (without me changing anything in between) since the "Previous value" is increasing time to time. See log below: |
|
@gec75 I could reproduce your problem, if decimalShift != 0. I could also fix it locally. I'll provide a PR. |
|
@FrankCGN01 Could you please provide the full screenshot, including the single digits and how they are recognized? |
The main reason was a wrong digital / analog sync, if decimal shifts were != 0. Also fixed hanging digits for late transition, which happened at my own installation only. Also reverted back to the improved unit test system of Slider0007, which seemed to be mistakenly overwritten by someone.
|
@warnmat your bug is fixed! |
|
@rainman110 This is my current configuration. I also updated to the developer version about 1 hour ago. But as I said, since my counter has jumped from 4 to 5 at the first digit after the decimal point, I occasionally only have a "Neg. Rate" error. |
|
@FrankCGN01 I looked at your data. The recognized / inferred numbers seem to be strange. Please look at line 2024-02-11T04:57 and compare it with the next one. In fact, the meter shows less. My changes do not affect the recognition part, only the post processing, that combine digital and analog values. It seems, that the last digit cannot be correctly recognized, probably due to the line that goes through the last number. I could imagine, that it could help adding these values to the training set. |
That's why I have the Digit ROI higher up on the Y-axis. |
|
Please test and provide feedback for this updated development version, which uses post-processing logic from 15.4 again. Firmware for testing can be downloaded here: https://github.com/jomjol/AI-on-the-edge-device/actions/runs/7878286347 |
This is with firmware v15.6.0 and this with your updated development version. Poor image quality (too dark) |
Please open a separate issue for poor image quality. In here please only report in terms of post processing results. Thanks Update: I opened a new issue for image quality issues #2901. |
|
Have tested the developer version and now its using the right value. But the overall picture quality is more blurred then before. The version 15.6 delivered a stable correct recognition beside it was using the wrong value but the new developer version is struggeling recognition because of a worser image quality as before. |
Thanks for your response, sounds good. I opened a new issue for image quality issues #2901. Thanks |
|
I have the same problem after updating to Release 15.6.0. |
Please test and provide feedback for this updated development version, which uses post-processing logic from 15.4 again. Firmware for testing can be downloaded here: https://github.com/jomjol/AI-on-the-edge-device/actions/runs/7878286347 |
|
Not sure if it's the same issue here, using the test/dev version and reading have fluctuated the whole day without any water usage. And just before the screenshot the last digit was reading 8.9 and then it changed to 9. But ask you can see on the analogue, we still need to use 200L before it's a "9" 
|
There are alignment problems with this version: This is 15.6.0: |
|
There was an issue in v15.5, maybe it is related to your issue, please update to rolling where we reverted this regression (#2778).
This is most likely a different issue, please make sure the Reference marks are as far apart as possible and have good contrast. |
I downgraded to 15.3.0 - everything is running flawlessly now. |
|
We just released v15.7.0 which hopefully fixes this issue. |
|
Hi guys, I do have those readings and I do not undestand them:
Every time that the fractions digit goes from 9 to 0, the readings are without the leading 0. Is this the correct behaviour?
Also the main value should be 301 instead of 300. Maybe my meter is not so good and the digits are not changing full but the recognition should "see" 301 in this case. Release: v15.7.0 (Commit: 0d0b018+) Any help is much apprecitated, thank you in advance! |
|
@gabimal Is there a reason why you don't let all digits evaluate as one complete number? |
|
@SybexX thank you for your quick answer! At one point I was thinking to use all digits as one number as you mentioned but I was unsure how it will behave. In this case the decimal shift will be -3? LE: I have added another 3 digits and got 6 in total:
|
|
@gabimal yes, exactly -3 is correct. |
|
@SybexX Thank you for confirming the decimal shift value! |
|
@gabimal Your counter once had 301,051 and in your last picture it has 299,667, from this I conclude that he also counts back |
|
@SybexX Sorry about that. The first picture is the present meter reading and the second image (with all new 6 digits) is the reference image took a while ago. Thank you very much for your help and patience! |
|
Hi! Could someone help, or is this the bug? Raw values: (the Pre Value in this log was manually set by me)
|
|
@SybexX Thanks for the quick response! |
|
@Hausi91 Always reduce the value gradually, e.g. 9.2 > 9.0 > 8.8 > 8.6......... |
|
@SybexX Thanks! As soon as I reduced the "Analog/Digital Transition Start" to 9, I'm much closer to the values I expect. Thank you very much. You're the man! |
The Problem
Raw Value is 1 m³ too small. Despite the Recognized Values are correct, the Raw Value is calculated "one less" (see attached picture)
Version
v15.5.0
Logfile
Expected Behavior
No response
Screenshots
Additional Context
No response
The text was updated successfully, but these errors were encountered: