G2 misuratori water meter reading (alternatives to AI on the edge?)

Hardware
1

Hi there Home Assistant community!

I want to track my water usage, but I am having trouble with the meter I have. I would like to hear if you people have any ideas how to get around the limitations.

My water company has installed a G2 misuratori water meter (model PFM-R100H T50) in my home and I won’t be eligible for a new meter until 2027. The technical specs can be found here: https://www.g2misuratori.it/themes/user/site/files/2019-10_bfm-bcm-pfm-R200-R100-en.pdf

To the best of my knowledge, this meter does not have a magnet or a reed. I am currently using AI on the edge to read it, however I have been unable to make it work reliably (it keeps misreading the water use by millions of liters). Below is a image of the meter from AI on the Edge:

Ref.PNG
Ref.PNG952×704 42.5 KB

Most of the ready solutions (like HomeWizard) are not compatible with my meter (to my knowledge), much to my chagrin.

I would like to hear if anyone has any alternatives I could have for measuring (even roughly) the water use (something I can attach to the pipes perhaps?). I don’t need it to be exact, but it should be at least somewhat reliable

Thanks!

2

Strange. I use it for my electricity meter, and it’s indeed unreliable, but the pictures I’m able to take are of far less quality than yours

image

3

Switching out to this Horseshoe-shaped universal camera mount for water meter by Zdendys - Thingiverse

I’ve managed to improve the reference image with no glare over the analog meters and only a -0.5 degree fine tune required.

Reference.PNG
Reference.PNG879×810 47.8 KB

Here’s a picture of my latest read showcasing the ROI placement
image

I will report if the AI on the edge device gets funky again.

4

Well, it works well up until it’s supposed to go to the next 1000 liters (Meter does not recognize changing digit when crossing over to new 1000 L - settings to tweak? · jomjol/AI-on-the-edge-device · Discussion #3116 · GitHub). Would have to figure out some way to bump up the liters based on the analogs alone. Perhaps I’ll only send the analog delta data to HA and use that to increment

Will test.

5

Are you actually interested in so many decimals, i.e down to the liter?
Ignoring the analog dials will likely give you 303.5m³ here, and consistent reading thereafter, but at the hundreds of liters resolution, indeed. But heh, just flushing a toilet is already 10L.

If you actually are interested, you probably don’t want “extended resolution”, although I have no clue if it would make a difference.

I’m curious what “Data->Recognition” tells you…

6

Ideally I would like the full information I can get from my water meters (and also as a way to detect potential micro leaks). Also I am being billed down to the actual liter, so it is somewhat relevant.

As per my Github issue, the real problem seems to be the way the last digit on the thousands of liters acts - it is recognized ‘correctly’ per se, but my meter sucks and it should be reading it as the next digit much earlier. So considering that is the issue, I think I can circumvent it by using the delta input from the analog meters with a utility meter (since the analog meters seem to be very accurate from what I’ve seen)

7

how close are the small red dials to the front glas? i’m using a tcrt5000 ir sensor both for our ferraris power meter (disc with a red marker) and a regular gas meter (with a reflecting surface on the last digit), and with precise placing and shielding of external light I get very good results. If you manage to find a position where the passing of the red dial makes a big enough difference in reflectiveness, you can use that to calculate very granular usage.

1 Like
8

So the 303 above?
Might be due to “extended resolution”, as I said before. Nevermind
Also, pretty please, show us what is actually recognized

image
image808×827 110 KB

9

Thank you for response.

Yes, the last digit of the blue boxes is the problem. Whenever the thousand is supposed to change it is still detected as the previous thousand (so if it were supposed to go from 305 to 306, it is still read as 305 until much later).

I will try to fiddle around with the extended resolution option, as you suggest.

Unfortunately, I do not have the recognition page to share from before I reset the previous value. However, my experience is that the only digit being misread is the last blue one (i.e. 306 477.83 instead of 305477.83). I will make sure to reshare once this inevitably happens at the next 1000 liters!

10

I’m not sure how close is close, but if you check the brochure I linked in the first post, you can see they’re about a centimeter or two under the glass, I am not sure if that would be viable.

11

I don’t use analog digits, but that seem to be exactly what it should be.
The 1000L should stay to the previous value until the 100L goes to 0.

In the github ticket, the screenshots you attached seem to be the correct value.
It’s the previous round that detected something wrong, apparently

12

In hindsight, the image from that situation probably does not illustrate the problem as well as I’d like it to.

I will try to boil it down to the core issue:

  • The analog dials count liters from 0-999
  • Whenever the analog dials cross from 999 to 0, the blue digits (thousands of liters) should increment by one
  • However, the meter does the incrementing of the blue digits too gradually, this leads to a Negative Read Rate Errors until it has incremented sufficiently.
13

You might want to play with the digital model.
If you use a “class11” model, the intermediate numbers are not recognized, which might be what you’re after.

See Model Selection - AI on the Edge Device

14

depending on where you live and where you order from the sensor is super cheap, i’d at least give it a try to be honest.

15

okay, different dial (with a bigger and reflective surface), but still worth a shot i would say:

1 Like
16

another idea: just use the analoge dials (green) as data input, and then just simulate the blue numbers by not even reading them, but by just increasing by one every time the green ones go from 999 to 0.

17

This is the automation I ended up doing, where sensor.water_analog is the reading from the analog meters. The > 10 is there as a buffer to avoid small reading errors from incrementing the 1000 liter count input_number.1000s_of_liters.

This also contains some debug for adding information to a To Do list about when the 1000s increment, which is not strictly necessary.

alias: Increment liters
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.water_analog
condition:
  - condition: and
    conditions:
      - condition: template
        value_template: >-
          {{ trigger.from_state.state | float > trigger.to_state.state | float
          }}
      - condition: template
        value_template: >-
          {{ (states('sensor.water_analog') | float -
          states('sensor.water_analog') | float) > 10 }}
action:
  - service: input_number.set_value
    metadata: {}
    data:
      entity_id: input_number.1000s_of_liters
      value: "{{ states('input_number.1000s_of_liters') | int + 1 }}"
  - service: todo.add_item
    target:
      entity_id: todo.water_debug
    data:
      item: >
        {{ now().day }}.{{ now().month }}.{{ now().year }} at {{ now().hour
        }}:{{ now().minute }}:
      description: >
        {{ trigger.from_state.state | float }} {{ trigger.to_state.state | float
        }} 
mode: single

The analog based water meter reading is based on the following code

  - sensor:
      - name: "Watermeter Analog Full"
        state: "{{ states('input_number.1000s_of_liters')|int * 1000 + states('sensor.water_analog')|int }}"