Dear Community,
My task seems to be very common:
I want to use the GPIOs of the Raspberry Pi to read in the Gas consumtion in my house. The Gas volume meter offers to read an impuls triggered by a magnet every 1l by means of a reed-contact.
Everything worked well:
GPIO-Thing installed
Channels configered as pulled up and inversed. So the normal status with the reedcontact connected being Normally Open is OFF. As I pull down the signal via the reed-contact being installed between the GPIO-Pin and GND (as the magnet passes by) I see the status change to ON and fall back to OFF after a few seconds.
As a next step I defined the item “Gas_Volume_50e” and the following rule to increase it:
rule "CounterWasserzaehlerZisterne"
when
Item PigpioLocal_InputGPIO25x22 received update ON
// or Time cron "* * * * * ? *" //only for testing
then
postUpdate(Wasserzaehler_Zisterne_50e, Wasserzaehler_Zisterne_50e.state as Number + 1)
logInfo("Ansgar", "Zisterne 50e delivered another 1 l to: " + Wasserzaehler_Zisterne_50e.state)
end
Testing the new installation, I face two different problems:
The item’s status falls back to “NULL” when the raspberry is restarted. Since “Null + 1” doesn’t make sense the counter doesn’t start to run… This problem seems to be connected to failure of persistance. But all other items are logged without any problems and without any special invitation to do so!?
Once set the item’s state to 0 it starts to count. But the number increases 5 to 6 x each time the magnet passes by instead of only 1. I assume the reason is bouncing of the reed contact.
Does anyone already have a similar system running and had similar problems?
The old fashioned way to debounce switches in hardware, with a small capacitor, still works.
Your rule might behave better if you trigger from changed. It is possible to update Items to the same state repeatedly, which will fire rule triggered from update.
A look in your events.log will show you what your sensor Item is doing by way of changes.
Hardware faults aside, openHAB is not meant to count pulses like this. I would suggest something like MQTTany that has a pulse counter built in and would report pulses periodically to OH. It can also perform the calculation for you and send the computed rate to OH for the reporting period.
Whow!
just posted and already three answers to my questions! Thanks for that!
I still have some new issues now:
what capacitor would you recommend and what additional resistors? Most information I can find about the issue of rebouncing recommend to pullup or pulldown with an external resistor - why not using the internal one?
the mqtt solution sounds a bit like running in circles - or I don’t get the clou. I understand the idea is to go GPIO → MQTTany → MQTT broker → OpenHAB instead of GPIO → OpenHAB!?
Let’s go back a step. For ancient technology, reed switches are really rather good performers, and don’t really suffer contact bounce. So let’s be sure to identify the correct problem before applying fixes.
What’s the timing of this sequence? Your events.log will have datestamped records of each counter change.
You’re using GPIO binding,presumably?
This feels very similar to
@Ansgar you are correct about the order of communication when using MQTTany. Understand though that it was designed to run on a remote Pi and not the same device running OH, but it can be run on the same device if need be.
So my issue was linked to this issue, but it isn’t the same thing.
PIR is not a switch but a logic gate on/off.
piscope (and now o-scope) confirm there is no bounce.
The issue is that piscope shows a single up or down. (New) Secondary attach to pigpiod shows a single up/down. The only thing reporting up/down/up or down/up/down is OpenHAB.
This issue is not the same in background, but is a second instance of the OpenHAB Binding seeming to have issues.
Dear Helpers,
again thank you for assisting me to get the connection done to work properly.
Amongst your suggestions, I tried around many things. One was to connect a 35uF elko in parallel to a S0-Counter and somehow buggered the appropriate GPIO-Input (it’s now always on and even configured as output only changes from 2.4/3.2V for 0/I).
The good news: for whatever reason the pulses are counted correctly without anything changed.
This applies for the counters with reed-contacts.
Going next step I have 4 electrical counters with S0-interface. Also those started to count almost at a factor of 5 but after first correction of the accumulated value they do fine! I cannot explain the effect but am convinced I didn’t change anything!
And finally I installed a tcrt5000 to read a water meter that didn’t have any interface. Again: it counts to quick - I’m curious if it works out itself as well…
