Water meter digitizer - Version 2 - all-in-device - including MQTT

Hardware DIY
21

Then please change to a newer one. I just released v5.0.0 by today (2020-12-06)

1 Like
22

Thank you, updated and then everything was recognized correctly. Hope the next „Nulldurchgang“ is running smooth.

23

Hi @jomjol,
Short feedback: the recognition is very good, but since the update I have the problem that the device is hanging up from time to time and I have to restart the device by unplugging. Sometimes the problem is announced by a very slow web interface. Do you have any recommendations to solve it?

24

Hi,
after a restart, I have the following situation (see picture):

grafik
grafik1994×1540 513 KB

The preset value is 1166.4562 and the device sends a Value with “N” so openhab can not recognize it right as Number. I think there is a new problem with the zero crossing…
Is there something I haven’t right configured?

[PostProcessing]
DecimalShift = 0
PreValueUse = true
PreValueAgeStartup = 720
AllowNegativeRates = false
;MaxRateValue = 0.1
ErrorMessage = true
CheckDigitIncreaseConsistency = true

Thank you for your help in advanced!

25

Hi Johannes,
it looks like the prevalue was not used here, otherwise the “N” should not be there in the corrected value. If you water consumption is so low, that the “N” is longer than the 720 minute (PreValueAgeStartup) AND you had a reboot for some reasons in between, then this would disable the prevalue.
It will reset automatically once the “7” is readable of if you reset the prevalue by hand (=menue).
Best regards,
jomjol

26

Thank you, actually it’s running with a manual preset. What is the maximum value for PreValueAgeStartup? I don’t think that my water consumption is so „slow“. We are 4 people (2 kids).

Have a nice evening!

27

Thanks jomjol!
Finally my esp32-cam arrived and after a bit of tinkering i got it to work. :slight_smile:
I also used your 3d printed case, fits perfectly, thanks for that!

So i used the “Train_CNN_Digital-Readout_Version_7.1.0.tflite” file, is that correct?

watermeterfirstry
watermeterfirstry956×792 126 KB

I tried different positions of the flashlight reflection on the glass and this gave me the best results so far. Is it possbile to train the AI to recognize the remaining darker ROI’s or are they just too dark?
What’s the best way for me to improve the training for the LCD? Familiarize myself with the training using Keras in a python environment?

Again thanks alot for sharing this awesome project!

Greetings
Yves

28

Hi Yves,
you could try to put a black sticker at the position of the reflexion. This could decrease the maximum brightness, giving the camera a change to give the other numbers more contrast.
Training can be done in Python, you find a Jupyter notebook here: https://github.com/jomjol/neural-network-digital-counter-readout
Other option would be to send me some pictures (not more than 2-3 for each digit under different illumionation) and I could put it in the next training session. The very dark numbers a pretty on the limit.
Best regards,
jomjol

29

Hi Jomjol,
great idea with the black sticker! I repositioned the “reflection” closer to the numbers and with the sticker, it now works perfectly! I haven’t had a wrong reading since, i even deactiveated the consistency check. :slight_smile:

I can send you pictures of my LCD digits if that helps for furhter training, but as i said it now works perfectly!

Again many many thanks for this!

Best Regards,
Yves

30

Hello @jomjol,

Actually the device is running without measurement failures, but from time to time the device gets unresponsive (no web interface and no measurement values via mqtt). Do you know what can cause this? A wlan access point is only a few meters away. Is ist possible to add a mqtt last will topic, so when the device is off I will switch a plug to restart the device, and is it possible to add a mqtt topic to restart the device?

Thank you for all your effort on this!!!

Best regards

Johannes

31

Hello @johannesbonn,
the newest rolling has now a LWT message defined. It will write “connection lost” to the TopicError - specified in Config.ini.
But if this happens, a restart via MQTT or Web-Interace will not work anymore :-).
In principle the restart can be triggered via http-access already: http:\\IP-ADRESS\reboot

Reason for stucking: the non responsiveness is rather strange. Normaly in case of failure, the ESP32 reboots pretty reliable. There are two critical points:

  1. SD-card failure - but then a restart will not help anymore. Newest version reduces the writting significatly
  2. Power supply - you need a very stable 5V power device. During image taking and calculation the power consumption is increasing strongly. Long cable, low performance USB power device are reported to be critical.

What version are you using?

Best regards,
jomjol

32

Thank you! I have changed my power supply from 1A to 2,5A. I use version 5.0.0 from 06.12.

Happy new year!

33

@jomjol this looks interesting. Are you planning to sell these as a kit by any chance? I love the idea but its bit too much of DYI-ing for me.

1 Like
34

Hi, What is the Max rate for taking pictures to get good values for waterflow rate? 5min is very long, how fast is the esp32 for analog Standard watermeters with 4 digits and 4 analog counters?

And another question, is there anyone who can 3d print me the watermeters case like described in the first post (for money)?

Or can someone give me a Adress of a Internet shop where i can send the thingiverse file? How much would this case be round about? 5 Euros? 10, 20, 50 Euros? (german Shop would be preffered)

35

there’s a lot of 3d print on demand available - also in Germany. also have a look on etsy.com, there’s plenty of 3D-printers on etsy, not only selling predesigned stuff but are open for sending in 3D-files.

36

Hi, i´m using this project quite a while - but forgot it and didn´t do much with it inside openhab, only sending mqtt to openhab and show the raw value…

Now i want to integrate it a little bit more into openhab. I first used persistence to save the results inside rrd4j. But now i saw, that i often get wrong values… I was thinking, when the watermeter-esp detects wrong values, it will not send anything and keep the old ones?

My counter is 700,1234 and sometimes i get 90700,1234 - so my rrd4j graph is useless, i only see big jumps. Then after one or more readings i get the right values back, maybe 700,4567.

Should i look into the watermeter to change some settings or is it a better way to filter those wrong readings inside openhab (with a proxy item, which only sends good readings to the real rrd4j-item)?

37

The new persistence has filters. Maybe you can use that?

38

First off: always solve issues at the root, so yes, try to fix it at the esp-level.

If it’s a non-fixable bug, you can work around it. I for one route data from my heating controller, which has a factory bug over Node-Red and I’m using the filter node there. So I don’t even resend faulty readings to openHAB. If you only use the watermeter readings for history and grafics, you can use persistence filters. If you apply actions in rules to item states, you should consider doing something outside OH also. I don’t know a way to filter incoming item states (yet?).

39

My idea was to send the mqtt-values to an item watermeter_proxy and then do some calculations, maybe check if the value is much bigger then the last one. If the value is ok, i will send the watermeter_proxy to my real item watermeter_value and only this will be send to rrd4j.

40

That’s also an possibility. But: it scales, if you have multiple items for this kind of proxy-item behaviour. In that case, you could put the logic into a script, that expects the values for the filter and the name of the “correct” item. After the rules fires with the filter-rules onChange of the initial item it then updates the “correct” item.