Question: How to adjust for lagging digit (late transition)?

[odrobnik]

Hi,

I have the issue that the following image is recognized with the most right digit as 8, but should be 9 because the first analog arrow already points to two. How do I adjust my config for that?

[odrobnik]

Here are the data table values from the transition:

2024-10-17T07:48:54+0200,main,278993.4,278994.4,278994.4,0.000000,0.0,no error,2.0,7.0,8.4,9.7,9.2,3.2,4.2
2024-10-17T07:53:54+0200,main,278994.1,278995.1,278995.1,0.140000,0.7,no error,2.0,7.0,8.4,9.7,9.3,4.2,1.0
2024-10-17T07:58:54+0200,main,278994.0,278995.1,278995.1,0.000000,0.0,no error,2.0,7.0,8.3,9.7,9.3,4.1,1.0
2024-10-17T08:03:54+0200,main,278000.5,,278995.1,,0.0,Neg. Rate - Read:  - Raw: 278000.5 - Pre: 278995.1 ,2.0,7.0,8.4,9.8,10.0,0.5,5.9
2024-10-17T08:08:54+0200,main,278000.5,,278995.1,,0.0,Neg. Rate - Read:  - Raw: 278000.5 - Pre: 278995.1 ,2.0,7.0,8.4,9.7,10.0,0.6,5.9

[caco3]

it seems you need the oposite of https://jomjol.github.io/AI-on-the-edge-device-docs/Watermeter-specific-analog---digital-transition/

[odrobnik]

I think there needs to be a way to give higher priority to the first analog digit, because that shows exactly the transition.

[caco3]

@haverland Do you see a way to handle this issue?
@odrobnik seems to have a very odd meter with late transitions.

[ghost]

What I see is 8.4 on the digit and the analog pointer runs to zero. I have the feeling that in some water meter models digits and pointers are not directly related - at least not the transition of the digits.

I'm wondering if we could solve the problem by simply using the digit as a reference at the analog / digital transition instead of the analog pointer and making the “negative” option so that it doesn't lead to an error in that case.

[Sourcer63]

Chiming in here: the inelligent zero crossing adjustment as described in the documentation is not working for me. My meter takes rally long until the last digital digit completes its change. So every 1 m3, it needs a few hundred liters before the change is actually recognized.
As you can see in the picture, a correct reading of 193.99 m3 is followed by a reading of 193.0xx where it should have been corected to 193.0x. No way to correct this, no matter what I use in the configuration settings. I would have thought that the algorithm is smart enough to not forget that the previous reading was just a few liters less, rather than a full 1 m3.

[Sourcer63]

I tried all that with no avail. The best setting is 9.9, which gives a correct reading up to x.99. However, then the first analog indicator stays below zero, i.e. too low, So instead of seeing for example x.010, the pointers would be x.91 - probably the reason why the algorithm misinterprets it.

IMHO it should not be too difficult to use the previous trend rather than just looking at the previous value. I mean, why should a meter suddenly display 1m3 lower consumption?

[Sourcer63]

This picture may better illustrate what I mean:

Previous value was 193.9917. Raw reading now is 193.0630 and the last digit before the decimal point is moving from 3 to 4, but it will need some 100-200 liters more before it is really recognized by the algorithm. So either I have totally misconfigured the setup or the algorithm cannot cope with the inconsistency of my meter. I am using dig-cont_0620_s3_q and ana-cont_1208_s2_q. But regardless of the models, a previous reading of 193.99 followed by 19x.05 should not be too difficult to decode to 194.05

Let me know if I should upload the data file for further info.

[SybexX]

Maxratevalue and Maxratetype are intended to prevent large jumps in value if the setting is set/used correctly.
There are tons of different water meters, with some the algorithm works correctly and with others it does the opposite.
In order to cover as many as possible, you need a lot of parameters, which then makes handling more difficult.

[Sourcer63]

Thanks, but this is neither an answer to the problem nor does it help in any way. :-)

What I am suggesting doesn't need any parameter and is based on simple logic: a household watermeter - assume 'no negative rate allowed' if you like - must never show a negative rate value. So a negative reading by the algorithm could (and IMHO should) trigger an automatic correction if the last correct reading was a x.9 value and now is x.0.

[SybexX]

This would help you in this position of the meter, but it would cause problems for others. The different behavior of the water meters does not follow any logic and that is why it is so difficult to cover all water meters. If you think logically, you look for the cause and not for compensation for a problem. And the cause in this case is the water meter, which deviates from the norm^^
We are a small team and do this in our free time, so we cannot address each water meter individually.
ps: Der Ton macht die Musik

[Sourcer63]

That's what I call steamrolling. So much about tone.

I can't change the cause, the meter belongs to the water provider. Cheap stuff.

Nevermind and thanks anyway.

[Sourcer63]

the appropriate files

Sorry, I am lost. Which are the appropriate files?

[SybexX]

Of course, adapt the wlan.ini and possibly preconfigure the AI-on-the-edge-device__manual-setup__test2_(866cf5d)-2.zip\sd-card.zip\config\config.ini or transfer the configs from the old one to the new one ( MQTT, InfluxDB ...........).

[Sourcer63]

File system on the SD seems to be damaged. I am reformatting and start all over again with 15.7.0

[Sourcer63]

OK, back to 15.7.0, then updated to your update_test2.

[Sourcer63]

Results from the first zero crossing:

Three screenshots for 194.9948, 195.0025 and 195.0143 m3. The system reports the last two as 194.xx, suppresses them and keeps the last 194.x reading. You can see that the 0.1 needle has not crossed zero yet, due to poor mechanics of the meter, I'll report how many more liters are needed until the current code recognizes the 195 value.