Domoticz

RidingTheFlow,

I faked the value of the IDX to the actual meter reading.
Flush the toilet, count 7 pulses on the TCTR5000 sensor, yet the value is updated to value +14. What could cause this or how can I fix it?

Fully agree your script is very robust, but in Domoticz strange things happen it seems.

RidingTheFlow,

I faked the value of the IDX to the actual meter reading.
Flush the toilet, count 7 pulses on the TCTR5000 sensor, yet the value is updated to value +14. What could cause this or how can I fix it?

Fully agree your script is very robust, but in Domoticz strange things happen it seems.

RidingTheFlow,

I faked the value of the IDX to the actual meter reading.
Flush the toilet, count 7 pulses on the TCTR5000 sensor, yet the value is updated to value +14. What could cause this or how can I fix it?
Fully agree your script is very robust, but in my case 1 liter is counted as 2 ticks and the delta becomes 2. Should I just divide the delta by 2? or subtract 1?

I increased bouncetime to 2000 but that does not help. Should it be longer or does not help in this case?
fixed:
Changed instead of WATER_DELTA +=1 and now the increment never becomes more than 1 liter per tick. Let see how this behaves....

Its not a script problem, the problem that your PI getting two signals for each meter increment. Looks like false edges, I had same issues with my sensors until I did some tweaking.

How have you connected the sensor (I mean schematics)? Did you use shielded cable/what pullup resistor, etc? How long is the cable?
Could it that be that metal detector actually sending pulse twice per counter increment?

If you don't do it properly on hardware side you most likely will suffer from EM interference which will cause false interrupts. Raspberry GPIO not really suited for long cables without some tweaking.

JelleB wrote:fixed:
Changed

Code: Select all

def gpio_intr(pin):
    if pin == WATER_GPIO:
        global WATER_DELTA
        with WATER_COUNTER_LOCK:
            WATER_DELTA = 1

instead of WATER_DELTA +=1 and now the increment never becomes more than 1 liter per tick. Let see how this behaves....

Sorry to say it, but you didn't really "fix"it. Now instead of too many ticks you will get too little sometimes. It will lose ticks if interrupt happens more than once in update cycle. You need to fix noise on your interrupts or whatever other way to make sensor actually signal it once per watermeter increment...

Well, maybe not fixed, but it works. I'd rather have a few liters too many or too sort than than the usage get doubled.

E.g. when I open several taps in the house, on the terminal I see several ticks in a row, but count visually only 1 revolution (liter) of the meter and 1 sensor on/off.
and I have updated the Domoticz total usage by json to reflect the actual meter reading and will track the differences the next couple of days.

If so you better just divide usage by 2 and convert to int when you update, but keep increment in interrupt - that will make more or less correct usage without assuming that meter can't blink faster then update interval.

Though myself I found that errors accumulate pretty quick and had to really fix the false triggers. I've used 2.2K pull up resistor on cable and gpiozero library to great result (I will post updated script with gpiozero soon after I test it for a bit).

How would the divide by 2 and INT value look like?
?

I haven't used shielded cable, cable is some 2.5 m long and runs next to fuse box etc, so EM interference is very well possible.

Have the TCTR5000 connected directly to GPIO. The sensor has a potmeter to adjust.

JelleB wrote:How would the divide by 2 and INT value look like?

Lowercase int

I haven't used shielded cable, cable is some 2.5 m long and runs next to fuse box etc, so EM interference is very well possible.

Have the TCTR5000 connected directly to GPIO. The sensor has a potmeter to adjust.

Potmeter adjust sensitivity of sensor, it's unlikely to help with signal robustness. Though it may help you to fine tune pulse length (so its not too short but no false pulses). I recommend doing this with simple script which just prints GPIO value in infinite loop, you turn meter and tune pot for good pulse length.

See if with divide by two you get numbers which will diverge to much. If they eventually will, you'll have to fight interference.
One thing I definitely would recommend is to add a proper pull-up resistor at the start of the cable (near PI) between 3.3V and sensor signal line - about 2.2K
Raspberry Pi internal pullup is about 60K and will do no help with such long cable.

i got this error after a new tick , dummy counter is not updating! pls help needed

Water counter tick: 1
HTTP Error 401: Unauthorized
Water delta 1

this is the script:

#!/usr/bin/env python

#imports
import time
import RPi.GPIO as GPIO
import json
import urllib2
import threading

#vars
GET_URL = 'http://localhost:8080/json.htm?type=devices&rid=%d'
SET_URL = 'http://localhost:8080/json.htm?type=com ... &svalue=%d'
WATER_DELTA = 0
WATER_IDX = 221
WATER_GPIO = 27
WATER_COUNTER_LOCK = threading.Lock()

def gpio_intr(pin):
if pin == WATER_GPIO:
global WATER_DELTA
with WATER_COUNTER_LOCK:
WATER_DELTA = 1
print 'Water counter tick: %d' % WATER_DELTA

def main():
global WATER_DELTA

GPIO.setmode(GPIO.BCM)
GPIO.setup(WATER_GPIO, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.add_event_detect(WATER_GPIO, GPIO.RISING, callback=gpio_intr, bouncetime=100)

while True:
time.sleep(5)

WATER_DELTA_POST = WATER_DELTA

if WATER_DELTA_POST != 0:
try:
res = json.load(urllib2.urlopen(SET_URL % (WATER_IDX, WATER_DELTA_POST)))
if res['status'] != 'OK':
raise Exception('Domoticz json error')
with WATER_COUNTER_LOCK:
WATER_DELTA -= WATER_DELTA_POST
except Exception as e:
print e

print 'Water delta %d ' % (WATER_DELTA_POST)

if __name__=="__main__":
main()


EDIT: Solved....domoticz PW protected

You need to add localhost to "local networks" in settings or add password in script.