REED switch input, reading out gas-meter (was: Connection of pir sensor)

[VoyteckPL]

Which gpio pins are used to connect pir sensor? Is it possible to use reed sensor instead? I would lile to use this project for gas meter.

[VoyteckPL]

So it takes ~500 microampers without cut and ~11 microampers with cut?

[Torxgewinde]

Yepp, it should be in the ballpark. The pull-up resistor used for the reed-switch will increase the sleep-current to a bit above 11 µA, but I do not have a device for measuring such low currents at home to accurately give a figure.

BTW: "Cznas na bateriach" is in seconds, in your screenshot 830440 should translate to 9 days, 14 hours, 40 minutes and 40 seconds. That is the approximate time since last reset or power-up (the clock has a huge drift because its time-base is an oscillator instead of a quartz-cristal, so do not trust this value fully, but coarsely it should give the time since start). The other figures and units seem correct.

[VoyteckPL]

Ok so after 2 weeks:

Unfortunately there is difference. I still have 1000 ms debounce setting.

[Torxgewinde]

Well, at least it is quite close. The current sketch is improved and could address your error-margin:

• If WiFi and/or MQTT connection takes very long, it will just give up sooner. This helps to not miss a revolution of the gasmeter while it was trying to submit a new value. I observed this error with my gasmeter and the default timings are for a high gas-consumption-rate (like when showering). I prefer to miss a transmission, instead of having a missed count. With the next transmission it will just use the correct value then, so it might be increased by more than one step-count.
• The counter start value can be placed as a retained value into the subtopic MQTTRootTopic+"/config/counter", it will be picked up by pressing reset or by powering up the Firebeetle.
• The debounce time can be placed into as a reatined value into the subtopic MQTTRootTopic+"/config/debounceTime", it will be picked up by pressing reset or by powering up the Firebeetle.
• I decided against reading the counter from the MQTT server to save battery and to avoid picking up an outdated value. In the discussion above I gave a hint where this can be added to the sketch if this is needed for your use case, but I'd like to not have it that way for my sketch.
• Mechanically I had to readjust/move my reed-switch a couple of times as it was somewhat insensitive. It took me a couple of tries to really mount it at a good spot.

TL;DR: Please try the new sketch, WiFi timeouts and a too large debounce time might be responsible for the error you observed.

[VoyteckPL]

Will do! Thanks for explaining.

[Torxgewinde]

I just noticed, your software-counter is higher than the gasmeter-counter. That is something I did not see with my setup and might be due to the reed-switch and perhaps bouncing. This might also hint why your setup required such a high debounce time.

You can make sure the reed-switch is working well with the very minimal sketch:

const int ReedPin = 4;
const int ledPin = 2;

void setup() {
  pinMode(ledPin, OUTPUT);
  pinMode(ReedPin, INPUT_PULLUP);
}

void loop() {
  digitalWrite(ledPin, digitalRead(ReedPin));
}

That sketch just lights up the LED, when the reed switch is pulled to ground. It helps to check the reed-switch.

[VoyteckPL]

The reed switch is definately fine. I tested it on Tasmota for over 2 months and it was 1:1 all the time. Never lost a single impulse😬

[Torxgewinde]

Please try the most current version of the sketch and adjust the debounceTime. 1000ms for debounce is surprisingly large, but perhaps you need to even increase it further in your setup (strange indeed, but who knows).

Here, with my setup, it counts correctly since last week (about ~8 to 12 m³ per day) without error. The only thing I observed, that indeed it sometimes cannot transmit immediately and aborts the connection due to timeout, but still counts correctly. As soon as the transmissions go through again to the MQTT-broker, the counter is correct. So, I think the sketch is not too far of.

The energy consumption is OK for transmitting that often, but in my setup I will decrease the number of transmissions at some stage to make the battery last longer. I am now at about ~60% capacity since start of development with a 2000mAh LiPo battery.

[VoyteckPL]

This doesn't seem to work anymore. I tried multiple times :(

Yes, to start from a certain value:

• Power down the ESP32
• Send a retained message with the meter-value in counts. If the meter reads for example 123.45 m³ send: mosquitto_pub -t "Keller/Gaszaehler/counter" -h server.lan -u "username" -P "password" -m "12345" -r
• Power on the ESP32, it will now learn the value from the MQTT-Broker. It does only look for the broker-value after power-on or when reset is pressed.

What I would also suggest (if possible) to abb configurable debounce time via MQTT so it is possible to change without updating firmware :)

[VoyteckPL]

So here is V1 case ;)

[VoyteckPL]

Update : after latest firmware update I'm unable to upload new firmware to device.

[Torxgewinde]

Hi, The most recent sketch has a slightly changed topic for the initial counter, that is learned when resetting or powering on the ESP32:

• The counter start value can be placed as a retained value into the subtopic MQTTRootTopic+"/config/counter", it will be picked up by pressing reset or by powering up the Firebeetle.
• The debounce time can be placed into as a reatined value into the subtopic MQTTRootTopic+"/config/debounceTime", it will be picked up by pressing reset or by powering up the Firebeetle.

This means:

• Power down the ESP32
• Send a retained message with the meter-value in counts. If the meter reads for example 123.45 m³ send: mosquitto_pub -t "Keller/Gaszaehler/config/counter" -h server.lan -u "username" -P "password" -m "12345" -r and for a debounce time of 1111 ms mosquitto_pub -t "Keller/Gaszaehler/config/debounceTime" -h server.lan -u "username" -P "password" -m "1111" -r
• Power on the ESP32, it will now read the value sfrom the MQTT-Broker. It does only look for the broker-value after power-on or when reset is pressed.

The hardware in the case looks good, well done.

About not being able to flash: The sketch itself has nothing that can "brick" an ESP32. The flashing procedure is part of the hardware, the ESP32 and bootloader. Please try to load a minimal sketch, the Arduino IDE has a few examples that just blink a LED or print something to the serial port. Those should always work, or otherwise your hardware, cabling or software has an issue. When handling electronic devices, short circuits, broken connections and even ESD (=electrostatic static discharge) can damage the electronics. I just hope this did not happen to your board. Loading a very basic sketch is useful to narrow down the issue. HTH.

[VoyteckPL]

I was trying to erease flash with esptool.py and I get response "wrong boot mode detected (0x13)". The latest firmware is loaded and working but I wanted to load with other wifi credentials and I couldn't. I also tried Arduino IDE and esptool web. I also tried with holding boot button and pressing that other button - nothing... Maybe there is some combination that will force different boot mode?

[Torxgewinde]

We are going a bit off-topic here: The behavior seems to be observed by others as well and there is some discussion at https://github.com/espressif/esptool/issues/741. I, myself haven't experienced it yet and I do not need to press buttons to upload sketches. Hopefully it guides you into the right direction to upload sketches again.

[VoyteckPL]

Ok. So far few days testing counter is 1:1. I will mount it outside soon. Great job

[VoyteckPL]

Last 3 weeks tests: device didn't loose a single pulse. It is 1:1 all the time.

[Torxgewinde]

Very nice, same for my setup.

I will close the issue for now as it seems we have reached an acceptable revision. There is potential to save more power, but I think it is quite OK for now.

[VoyteckPL]

Thanks. Great job. I will test in longer period and see battery life.

[Torxgewinde]

Sure, just add it to this issue.

Actually, I am quite happy to hear it is also working for you. I myself am now also happy, because finally I can monitor my gasmeter and without the "nudge" to start coding, I would probably still procrastinate it. I guess we all have busy lives...

Pozdrawiam serdecznie!

[VoyteckPL]

From 01.03 till today 24.09 I went from 4.2 to 3.8v which is a great success. Charging batteries now for the winter. We will see how it goes. Never lost a single unit.