Wrong Raw Value?

[Kornelius777]

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

[0d00h00m00s] 2024-02-03T10:13:22 <INF> [MAIN] =================================================
[0d00h00m00s] 2024-02-03T10:13:22 <INF> [MAIN] ==================== Start ======================
[0d00h00m00s] 2024-02-03T10:13:22 <INF> [MAIN] =================================================
[0d00h00m00s] 2024-02-03T10:13:22 <INF> [MAIN] PSRAM size: 8388608 byte (8MB / 64MBit)
[0d00h00m00s] 2024-02-03T10:13:22 <INF> [MAIN] Total heap: 4380111 byte
[0d00h00m04s] 2024-02-03T10:13:26 <INF> [MAIN] Camera info: PID: 0x26, VER: 0x42, MIDL: 0x7f, MIDH: 0xa2
[0d00h00m04s] 2024-02-03T10:13:26 <INF> [SDCARD] Basic R/W check started...
[0d00h00m04s] 2024-02-03T10:13:26 <INF> [SDCARD] Basic R/W check successful
[0d00h00m04s] 2024-02-03T10:13:26 <INF> [SNTP] TimeServer: pool.ntp.org
[0d00h00m04s] 2024-02-03T10:13:26 <INF> [SNTP] Configuring NTP Client...
[0d00h00m04s] 2024-02-03T11:13:26 <INF> [SNTP] Time zone set to CET-1CEST,M3.5.0,M10.5.0/3
[0d00h00m04s] 2024-02-03T11:13:27 <INF> [SNTP] time zone: +0100 Delta to UTC: 3600 seconds
[0d00h00m04s] 2024-02-03T11:13:27 <INF> [SNTP] Time is already set: 2024-02-03 11:13:27
[0d00h00m04s] 2024-02-03T11:13:27 <INF> [MAIN] CPU frequency: 160 MHz
[0d00h00m04s] 2024-02-03T11:13:27 <INF> [SDCARD] Folder/file presence check started...
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [SDCARD] Folder/file presence check successful
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [MAIN] Tag: 'v15.5.0', Release: v15.5.0 (Commit: 019069c+), Date/Time: 2024-02-02 12:57, Web UI: Release: v15.5.0 (Commit: 019069c+)
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [MAIN] Reset reason: Via esp_restart
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [WLANINI] SSID: XXXXXXXX
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [WLANINI] Password: XXXXXXXX
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [WLANINI] Hostname: watermeter
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [WLANINI] DNS: 192.168.150.199
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [MAIN] WLAN config loaded, init WIFI...
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [WIFI] Automatic interface config --> Use DHCP service
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [WIFI] Set hostname to: watermeter
[0d00h00m05s] 2024-02-03T11:13:27 <INF> [WIFI] Init successful
[0d00h00m08s] 2024-02-03T11:13:30 <INF> [WIFI] Connected to: XXXXXXXX, RSSI: -52
[0d00h00m09s] 2024-02-03T11:13:32 <INF> [WIFI] Assigned IP: 10.10.4.230
[0d00h00m09s] 2024-02-03T08:15:03 <INF> [SNTP] Time is synced with NTP Server pool.ntp.org: 2024-02-03 08:15:03
[0d00h00m11s] 2024-02-03T08:15:04 <INF> [MAIN] Device info: CPU cores: 2, Chip revision: 100
[0d00h00m11s] 2024-02-03T08:15:04 <INF> [MAIN] SD card info: Name: USD00, Capacity: 60350MB, Free: 998MB
[0d00h00m13s] 2024-02-03T08:15:06 <INF> [MAIN] Initialization completed successfully
[0d00h00m16s] 2024-02-03T08:15:09 <INF> [LOGFILE] Set log level to INFO
[0d00h00m16s] 2024-02-03T08:15:09 <INF> [MQTT IF] Init
[0d00h00m16s] 2024-02-03T08:15:09 <INF> [MQTT IF] Client started, waiting for established connection...
[0d00h00m16s] 2024-02-03T08:15:09 <INF> [MAINCTRL] Starting Flow...
[0d00h00m16s] 2024-02-03T08:15:09 <INF> [MAINCTRL] Round #1 started
[0d00h01m02s] 2024-02-03T08:15:55 <ERR> [POSTPROC] main: Raw: 01016.5170, Value: , Status: Neg. Rate - Read: - Raw: 01016.5170 - Pre: 1017.5660
[0d00h01m02s] 2024-02-03T08:15:55 <INF> [MAINCTRL] Round #1 completed (46 seconds)
[0d00h02m45s] 2024-02-03T08:17:38 <INF> [POSTPROC] SetPreValue: PreValue for main set to 1017.510000
[0d00h03m20s] 2024-02-03T08:18:13 <INF> [MAINCTRL] Round #2 started
[0d00h04m05s] 2024-02-03T08:18:58 <ERR> [POSTPROC] main: Raw: 01016.5170, Value: , Status: Neg. Rate - Read: - Raw: 01016.5170 - Pre: 1017.5100
[0d00h04m05s] 2024-02-03T08:18:59 <INF> [MAINCTRL] Round #2 completed (45 seconds)
[0d00h05m52s] 2024-02-03T08:20:46 <INF> [POSTPROC] SetPreValue: PreValue for main set to 1016.517000
[0d00h06m09s] 2024-02-03T08:21:02 <INF> [MAINCTRL] Round #3 started
[0d00h06m54s] 2024-02-03T08:21:47 <INF> [POSTPROC] main: Raw: 01016.5170, Value: 1016.5170, Status: no error
[0d00h06m54s] 2024-02-03T08:21:47 <INF> [MAINCTRL] Round #3 completed (45 seconds)

Expected Behavior

No response

Screenshots

Additional Context

No response

[spanzetta]

Had the same issues and I was also becoming crazy to understand how to fix Try changing the size/position of ROI of one or two pixels and see if it changes

[gjsiiger]

I can add, that I have it the other way around... So the raw value is correct 0965.02911, however it keeps reporting 966.02911.

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

[Kornelius777]

Meanwhile, I have

• wiped the SD Card and re-written the 15.5.0 files on it (edited the wlan.ini, of course),
• gone through the installation routine (initial setup of alignment, ROIs etc),
• executed another OTA Update with the 15.5.0 update file

Yet, no change.

Instead of 1017, it still shows 1016.

[0d00h00m59s] 2024-02-03T14:29:55 <DBG> [CNN] Processing Number 'main'
[0d00h00m59s] 2024-02-03T14:29:55 <DBG> [CNN] ROI #0 - TfLite
[0d00h00m59s] 2024-02-03T14:29:55 <DBG> [CNN] CNN Type: DoubleHyprid10
[0d00h01m02s] 2024-02-03T14:29:58 <DBG> [CNN] After Invoke
[0d00h01m02s] 2024-02-03T14:29:58 <DBG> [CNN] _num (p, m): 0 1 9 _val (p, m): 0.996094 0.003906 0.000000 result: 0.003906 _fit: 1.000000
[0d00h01m02s] 2024-02-03T14:29:58 <DBG> [CNN] ROI #1 - TfLite
[0d00h01m02s] 2024-02-03T14:29:58 <DBG> [CNN] CNN Type: DoubleHyprid10
[0d00h01m03s] 2024-02-03T14:29:59 <DBG> [OTA FILE] download_get_handler
[0d00h01m03s] 2024-02-03T14:29:59 <DBG> [MAIN SERVER] info_get_handler
[0d00h01m05s] 2024-02-03T14:30:01 <DBG> [CNN] After Invoke
[0d00h01m05s] 2024-02-03T14:30:01 <DBG> [CNN] _num (p, m): 1 2 0 _val (p, m): 0.992188 0.000000 0.007812 result: 0.992188 _fit: 1.000000
[0d00h01m05s] 2024-02-03T14:30:01 <DBG> [CNN] ROI #2 - TfLite
[0d00h01m05s] 2024-02-03T14:30:01 <DBG> [CNN] CNN Type: DoubleHyprid10
[0d00h01m07s] 2024-02-03T14:30:03 <DBG> [CNN] After Invoke
[0d00h01m07s] 2024-02-03T14:30:03 <DBG> [CNN] _num (p, m): 0 1 9 _val (p, m): 0.996094 0.000000 0.000000 result: 0.000000 _fit: 0.996094
[0d00h01m07s] 2024-02-03T14:30:03 <DBG> [CNN] ROI #3 - TfLite
[0d00h01m07s] 2024-02-03T14:30:03 <DBG> [CNN] CNN Type: DoubleHyprid10
[0d00h01m10s] 2024-02-03T14:30:06 <DBG> [CNN] After Invoke
[0d00h01m10s] 2024-02-03T14:30:06 <DBG> [CNN] _num (p, m): 1 2 0 _val (p, m): 0.996094 0.000000 0.000000 result: 1.000000 _fit: 0.996094
[0d00h01m10s] 2024-02-03T14:30:06 <DBG> [CNN] ROI #4 - TfLite
[0d00h01m10s] 2024-02-03T14:30:06 <DBG> [CNN] CNN Type: DoubleHyprid10
[0d00h01m13s] 2024-02-03T14:30:09 <DBG> [CNN] After Invoke
[0d00h01m13s] 2024-02-03T14:30:09 <DBG> [CNN] _num (p, m): 7 8 6 _val (p, m): 0.992188 0.000000 0.007812 result: 6.992188 _fit: 1.000000
[...]
[0d00h01m16s] 2024-02-03T14:30:12 <ERR> [POSTPROC] main: Raw: 01016.8099, Value: , Status: Rate too high - Read: 1016.8099 - Pre: 42.0134 - Rate: 974.7965

[Slider0007]

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: https://github.com/jomjol/AI-on-the-edge-device/pull/2778

In my opinion it's either a bug in logic or the behaviour of parameter Analog/Digital Transition Start is totally different.

[Knallochse]

I can also confirm this problem with version 15.5.0

[Kornelius777]

To me, it appears as if this behaviour only exists when you first start version 15.5.0. After the initial start, I accepted the reading being 1 m³ too low, adjusted the Previous Value accordingly. After the watermeter showed approximately 1 m³ consumption, all of a sudden, the value jumped to the correct reading. Once more, I confirmed the Previous Value (which now was the correct one). No hickup since. Just the initial start was quite "rumbly".

[marcniedersachsen]

I might have the same problem. Digit x1m3 is sometime recognized correctly as 8 and in some cases as 7...

[gec75]

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). But the analog digits have well passed 0, and there is no correction upwards),

digits = { 2.0, 5.0, 1.9}; analogs = { 0.8, 8.8, 9.9, 0.1}; expected = "252.090"; wrong result: 251.090!!

[rainman110]

The last digital digit remains a little low (e.g. 2 recognized as 1.9). But the analog digits have well passed 0, and there is no correction upwards),

digits = { 2.0, 5.0, 1.9}; analogs = { 0.8, 8.8, 9.9, 0.1}; expected = "252.090"; wrong result: 251.090!!

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.

[rainman110]

@gec75 How did you set your "Analog/Digital Transition Start" value? I have tested your values with 9.2, then it seems to work.

[gec75]

It was by default 9.2, I also tried with other values...

[marcniedersachsen]

The last digital digit remains a little low (e.g. 2 recognized as 1.9). But the analog digits have well passed 0, and there is no correction upwards), digits = { 2.0, 5.0, 1.9}; analogs = { 0.8, 8.8, 9.9, 0.1}; expected = "252.090"; wrong result: 251.090!!

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.

Thank you very much ! I noticed yesterday that this issue seems to be caused by the Post-Processing "Decimal-Shift":

Decimal-Shift = 3: 777124.1 Decimal-Shift = off: 778.1241 <- thats the correct value !

I reproduced this 3 times in a row by enabling / disabling the Decimal-Shift.

[gec75]

Aaaa! Yes, I also use Decimal shift!

[rainman110]

@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

[gec75]

I'm using 3, getting liters (instead of m^3).

[marcniedersachsen]

I'm using 3, getting liters (instead of m^3).

Same with me. But no malfunction since I disabled Decimal-Shift since yesterday 22h.

[gec75]

I could change it... but it will create a big mess in Home Assistant... Currently it is caught by negative rate...

[marcniedersachsen]

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.

[rainman110]

@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.

[ohkaja]

I have the same behavior with decimalshift active but 0. Tried to disable it, no change. Came directly from 15.4.

Recognized correctly but shows m^3 - 1

[ohkaja]

[FrankCGN01]

@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 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. I have set the decimal shift to -3 because my counter also displays the first 3 digits after the decimal point as a digital value. Only the 4th digit after the decimal point is analogue.

[knonem]

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. Tried disabling "Decimal Shift" and "Analog/Digital Transition Start" with the same result.

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:

[0d00h01m15s] 2024-02-10T14:39:26 <ERR> [POSTPROC] main: Raw: 00652.8144, Value: , Status: Neg. Rate - Read: - Raw: 00652.8144 - Pre: 653.8020
[0d00h06m14s] 2024-02-10T14:44:25 <ERR> [POSTPROC] main: Raw: 00652.8157, Value: , Status: Neg. Rate - Read: - Raw: 00652.8157 - Pre: 653.8020
[0d00h11m14s] 2024-02-10T14:49:25 <ERR> [POSTPROC] main: Raw: 00652.8165, Value: , Status: Neg. Rate - Read: - Raw: 00652.8165 - Pre: 653.8020
[0d00h16m15s] 2024-02-10T14:54:25 <ERR> [POSTPROC] main: Raw: 00652.8165, Value: , Status: Neg. Rate - Read: - Raw: 00652.8165 - Pre: 653.8020
[0d00h21m15s] 2024-02-10T14:59:25 <ERR> [POSTPROC] main: Raw: 00652.8170, Value: , Status: Neg. Rate - Read: - Raw: 00652.8170 - Pre: 653.8020
[0d00h36m15s] 2024-02-10T15:14:25 <ERR> [POSTPROC] main: Raw: 00652.8176, Value: , Status: Neg. Rate - Read: - Raw: 00652.8176 - Pre: 653.8171
[0d00h46m15s] 2024-02-10T15:24:25 <ERR> [POSTPROC] main: Raw: 00652.8257, Value: , Status: Neg. Rate - Read: - Raw: 00652.8257 - Pre: 653.8176
[0d00h56m15s] 2024-02-10T15:34:25 <ERR> [POSTPROC] main: Raw: 00652.8311, Value: , Status: Neg. Rate - Read: - Raw: 00652.8311 - Pre: 653.8257
[0d01h01m15s] 2024-02-10T15:39:25 <ERR> [POSTPROC] main: Raw: 00652.8311, Value: , Status: Neg. Rate - Read: - Raw: 00652.8311 - Pre: 653.8257
[0d01h06m15s] 2024-02-10T15:44:25 <ERR> [POSTPROC] main: Raw: 00652.8311, Value: , Status: Neg. Rate - Read: - Raw: 00652.8311 - Pre: 653.8257
[0d01h16m15s] 2024-02-10T15:54:25 <ERR> [POSTPROC] main: Raw: 00652.8414, Value: , Status: Neg. Rate - Read: - Raw: 00652.8414 - Pre: 653.8311
[0d01h21m15s] 2024-02-10T15:59:25 <ERR> [POSTPROC] main: Raw: 00652.8414, Value: , Status: Neg. Rate - Read: - Raw: 00652.8414 - Pre: 653.8311
[0d01h26m15s] 2024-02-10T16:04:25 <ERR> [POSTPROC] main: Raw: 00652.8414, Value: , Status: Neg. Rate - Read: - Raw: 00652.8414 - Pre: 653.8311
[0d01h31m15s] 2024-02-10T16:09:25 <ERR> [POSTPROC] main: Raw: 00652.8414, Value: , Status: Neg. Rate - Read: - Raw: 00652.8414 - Pre: 653.8311
[0d01h36m15s] 2024-02-10T16:14:25 <ERR> [POSTPROC] main: Raw: 00652.8503, Value: , Status: Neg. Rate - Read: - Raw: 00652.8503 - Pre: 653.8311
[0d01h41m15s] 2024-02-10T16:19:25 <ERR> [POSTPROC] main: Raw: 00652.8503, Value: , Status: Neg. Rate - Read: - Raw: 00652.8503 - Pre: 653.8311
[0d01h46m15s] 2024-02-10T16:24:25 <ERR> [POSTPROC] main: Raw: 00652.8503, Value: , Status: Neg. Rate - Read: - Raw: 00652.8503 - Pre: 653.8311
[0d01h51m15s] 2024-02-10T16:29:26 <ERR> [POSTPROC] main: Raw: 00652.8503, Value: , Status: Neg. Rate - Read: - Raw: 00652.8503 - Pre: 653.8311
[0d01h56m15s] 2024-02-10T16:34:25 <ERR> [POSTPROC] main: Raw: 00652.8516, Value: , Status: Neg. Rate - Read: - Raw: 00652.8516 - Pre: 653.8311
[0d02h01m15s] 2024-02-10T16:39:25 <ERR> [POSTPROC] main: Raw: 00652.8516, Value: , Status: Neg. Rate - Read: - Raw: 00652.8516 - Pre: 653.8311
[0d02h06m15s] 2024-02-10T16:44:25 <ERR> [POSTPROC] main: Raw: 00652.8516, Value: , Status: Neg. Rate - Read: - Raw: 00652.8516 - Pre: 653.8311
[0d02h11m15s] 2024-02-10T16:49:25 <ERR> [POSTPROC] main: Raw: 00652.8736, Value: , Status: Neg. Rate - Read: - Raw: 00652.8736 - Pre: 653.8311
[0d02h21m15s] 2024-02-10T16:59:25 <ERR> [POSTPROC] main: Raw: 00652.8765, Value: , Status: Neg. Rate - Read: - Raw: 00652.8765 - Pre: 653.8749
[0d02h26m15s] 2024-02-10T17:04:25 <ERR> [POSTPROC] main: Raw: 00652.8799, Value: , Status: Neg. Rate - Read: - Raw: 00652.8799 - Pre: 653.8749
[0d02h31m15s] 2024-02-10T17:09:25 <ERR> [POSTPROC] main: Raw: 00652.8833, Value: , Status: Neg. Rate - Read: - Raw: 00652.8833 - Pre: 653.8749
[0d02h41m15s] 2024-02-10T17:19:25 <ERR> [POSTPROC] main: Raw: 00652.8853, Value: , Status: Neg. Rate - Read: - Raw: 00652.8853 - Pre: 653.8850
[0d02h46m15s] 2024-02-10T17:24:25 <ERR> [POSTPROC] main: Raw: 00652.8892, Value: , Status: Neg. Rate - Read: - Raw: 00652.8892 - Pre: 653.8850
[0d02h51m15s] 2024-02-10T17:29:25 <ERR> [POSTPROC] main: Raw: 00652.8892, Value: , Status: Neg. Rate - Read: - Raw: 00652.8892 - Pre: 653.8850
[0d02h56m15s] 2024-02-10T17:34:25 <ERR> [POSTPROC] main: Raw: 00652.8999, Value: , Status: Neg. Rate - Read: - Raw: 00652.8999 - Pre: 653.8850
[0d03h01m15s] 2024-02-10T17:39:25 <ERR> [POSTPROC] main: Raw: 00652.8999, Value: , Status: Neg. Rate - Read: - Raw: 00652.8999 - Pre: 653.8850
[0d03h06m15s] 2024-02-10T17:44:25 <ERR> [POSTPROC] main: Raw: 00652.9046, Value: , Status: Neg. Rate - Read: - Raw: 00652.9046 - Pre: 653.8850
[0d03h16m15s] 2024-02-10T17:54:25 <ERR> [POSTPROC] main: Raw: 00652.9046, Value: , Status: Neg. Rate - Read: - Raw: 00652.9046 - Pre: 653.9046
[0d03h31m15s] 2024-02-10T18:09:25 <ERR> [POSTPROC] main: Raw: 00652.9094, Value: , Status: Neg. Rate - Read: - Raw: 00652.9094 - Pre: 653.9077
[0d03h41m15s] 2024-02-10T18:19:25 <ERR> [POSTPROC] main: Raw: 00652.9108, Value: , Status: Neg. Rate - Read: - Raw: 00652.9108 - Pre: 653.9103

[rainman110]

@gec75 I could reproduce your problem, if decimalShift != 0. I could also fix it locally.

I'll provide a PR.

[rainman110]

@FrankCGN01 Could you please provide the full screenshot, including the single digits and how they are recognized?

[FrankCGN01]

@rainman110 I had taken these pictures shortly before, but they show the same problem:

[FrankCGN01]

@rainman110 However, since the counter jumped to 159.5009 tonight, the error no longer appears. Here are the pictures and the Data files of the last 2.5 days (if that helps)

data_2024-02-11.txt data_2024-02-10.txt data_2024-02-09.txt

[warnmat]

I do have the same issue. Have seen the comment about the decimal shift. Because I made a first installation 2 days ago it was OK for me to try with and without decimal shift activated. Have set decimal shift to 3, 0 and turned off. All with the same result. The recognized value is correct but the Raw value shows 1m³ less than the expected one. Digits in front of the decimal point are Digital and the one behind it are analogue. Recognition fits perfectly.

[Slider0007]

Please test and provide feedback for the proposed change (#2887) from @rainman110, which should address the issue. Firmware for testing can be downloaded here: https://github.com/jomjol/AI-on-the-edge-device/actions/runs/7858471145

[Kornelius777]

Works nicely. Previous Value had been saved, update works flawless. Current Value correctly read. Thank you very much!

[gec75]

It also works for me.... although it is a little strange. It shows "Raw Value": 0253311.96, "Value": 254311.96" Why is the "raw value" 1 smaller?? The image looks absolutely correct (recognized digital numbers 2, 4.9, 4 )

[rainman110]

@gec75 nice to hear. Can you please post all the recognized digits? I am gonna look into, why the raw value is reported too low.

[gec75]

You can look here... the recognition seems very good, but the "raw" value is reported -1 (for last digital number, I still use shift 3)

[penapena]

I get value +1 error on versions 15.5.5, 15.5.6 and the version posted above. On version 15.5.4 everything is recognized and posted correctly.

[Slider0007]

I get value +1 error on versions 15.5.5, 15.5.6 and the version posted above. On version 15.5.4 everything is recognized and posted correctly.

@rainman110: Can you please have a look to this as well

[FrankCGN01]

@penapena Check whether the read value is correct again when the first digit after the decimal point jumps to 5. That's how it was for me. Previously I always had the Read Value +1 compared to the RAW Value, which was always correct.

[rainman110]

@penapena I can reprocuce the bug. Your analog value is behaving wierd though. Can you provide, at which first analog values the last digit start and ends changing from 4->5? The strange thing is, that the digit is already changing, while the analog is pretty small. It's exactly the same as in my home actually. In my case, I need to adapt the Analog to Digital Transition value.

[rainman110]

@FrankCGN01 Your first example works nicely.

The second example is a bit strange, since the last digit (2) is recoginzed as 2.5. Therefore, I get 159.5032 instead of 159.5022. What is you analog to digital transition value?

[rainman110]

@warnmat your bug is fixed!

[FrankCGN01]

@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.

[rainman110]

@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.

[penapena]

@penapena I can reprocuce the bug. Your analog value is behaving wierd though. Can you provide, at which first analog values the last digit start and ends changing from 4->5? The strange thing is, that the digit is already changing, while the analog is pretty small. It's exactly the same as in my home actually. In my case, I need to adapt the Analog to Digital Transition value.

That's why I have the Digit ROI higher up on the Y-axis.

[Slider0007]

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

[FrankCGN01]

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)

[Slider0007]

@FrankCGN01:

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.

[warnmat]

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.

[Slider0007]

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

[JWRu]

I have the same problem after updating to Release 15.6.0. However, the raw value is only false (least significant digit of the digital section) when the analog recognition is used. My other devices (electricity meter, gas meter) show a correct raw value.

[Slider0007]

I have the same problem after updating to Release 15.6.0. However, the raw value is only false (least significant digit of the digital section) when the analog recognition is used. My other devices (electricity meter, gas meter) show a correct raw value.

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

[gjsiiger]

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"