-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REED switch input, reading out gas-meter (was: Connection of pir sensor) #4
Comments
Hi,
In general reading a reed-switch should also be able to trigger the wakeup. Depending on the number of times it wakes the processor, just counting the events and transmitting a few times a day might be required to achieve good runtime. This certainly requires several changes, but is certainly achievable. |
Thanks. Is there any chance you could help me with the code? I can see you made a pro job here. I'm a total noob when it comes to arduino. I see there are some pir specific option like ignore after motion etc. I would be grateful if you could help. |
@VoyteckPL : Sure, I am willing to assist, however I am not coding it for you. I am also interested in measuring my gasmeter with a reed switch or the ESP32 internal hall sensor. If you have specific questions I suggest you post code and we can discuss and tweak it until it works. If the result is indeed powersaving enough, that is something I can only imagine but not promise yet. It SHOULD be OK in my opinion. |
Ok. When Firebeetle arrives I will do some testing. When I look at your code it seems to be good for reed switch with very little adjustments. |
That's cool. I also ordered a REED switch to test it and am looking forward to collaborate. |
Nice! My firebeetle should arrive tomorrow 🙂 |
I also need to check with the current Arduino-IDE. The working versions are:
Maybe some path have changed and need to be updated. I will also use the current IDE and see what might have changed... Edit: added MQTT library info |
Ok I will check and report back |
It also compiles, uploads and send serial output with:
It should compile and run. I haven't entered my WiFi-credentials yet and a full test. |
Fantastic. Thanks. I will do some testing today. |
Yay! I was able to compile. The problem was I didn't have 2.0.6 Board Definition installed. I had to manually add this link to preferences : https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json By default it was only 1.0.6. |
Ok so I sucessfully uploaded firmware! :) My reed sensor should be between pins GND and D12 (GPIO4) right? I won't be using that 3rd cable for 3.3V as I would for PIR sensor. |
Yes, if you use D12 you won't have to lookup other To provide current to the sensor, a Pullup or Pulldown resistor must be actived. The Arduino function The 3.3V is not required, right. |
Thank you!
I suppose that is all. I'm really sorry I can't help with the coding. I'm sure this solution will become very popular. I tested zigbee and it was not reliable (no signal quality info, loosing packets) |
Ok, no worries. Please chime back in anytime when you feel like picking up the project again and thank you for the hints, surely it helps when working on it again. |
No problem. If I could support you some other way - I'm open 😉 we can talk on WhatsApp if you wish. |
To read the Reed-switch and light the LED accordingly:
To read the reed-switch and debounce with a second:
It is not done yet, but this is what I currently have. |
Amazing work! Let me know if I can buy you a coffee somehow! |
One question : in this example if gas meter stops or OPEN or CLOSED position will it always go to deep sleep? |
The idea is, that it wakes up by changes to the reed-state. Only if the magnet is present (trigger) and still present after a second (for debounce) it increments the counter and transmits the counter via MQTT. To conserve battery it sleeps most of the time. What is missing to wakeup every N-counts or every N-hours to transmit the whole status and the offset to start counting from. It is work in progress and not done yet! |
Just one more clue ;) Usually one revolution of gas meter is 0.01 m3. It would be nice to have it with the decimals as result in MQTT rather than converting in from 1 to 0.01 in frontend. |
Yes, i changed "counter" to be a "retained" value now. That way the broker will store the value even when resetting the ESP32 or changing the battery. The new behavior will be:
Conversion of counts to actual qubic-meters m³ might follow. I am happy if battery runtime can be checked and is acceptable - that is my main concern for now.
|
I also wonder what happends when MQTT server will be down (due to electricity failure). What will happen with retain message with current counter value. Wouldn't it be better to store it in EEPROM? |
Not sending the full details is to send as little as possible (to preserve battery). I implemented now:
The slight error after power-on is not worth the effort to get rid of it. Replacing the battery (hopefully) happens once or twice per year and miscounting by one under certain circumstances is not worth the effort IMHO. If the MQTT-broker gets down the ESP32 is still keeping the counter. The ESP32 only "learns" the retained value at first-start (=power-cycle or reset). Every time the ESP32 transmits the counter, it is now "retained", thus refreshed from the ESP32. To really loose the broker value and the ESP32, both must be restarted at more or less the same time. Since I plan to have the ESP32 running from battery, this would be a rare coincidence --> Acceptable IMHO.
|
I'm impressed. I will connect it to my gas meter soon and run some tests 🙂 is it possible to send mqtt message with current gas meter value so it is possible to sync current state? |
Yes, to start from a certain value:
|
Good news: It counts and runs from battery, Bad news: it misses a few revolutions. I am afraid there is still something to be done to read the reed-switch properly. |
Mine is in sync so far |
In my case it was missing some counts when the gas-heater was ramping up to the maximum power. For such cases I had to reduce the BOUNCE_TIME to 500msec. This might be a value that needs to be adjusted to each reed-setup and gas-heater. If your setup is working there is no need to change it, in my case it was necessary. Here is the sketch in its current revision. I also implemented the reaction to all states I could imagine and coded it very verbose to not miss a state:
|
One question. What is the unit of measurement of time on batteries and active time? |
The battery unit is in Volt. Active Time is the time the ESP32 is in active mode in milliseconds. BatteryRuntime is the time since power-up/reset in seconds (as float, "seconds.subseconds" ). BatteryRuntime does not have a very accurate clock source, so it is just a course time.
|
Ok, about the Low-Power-Pad, there is a lot of power that is drawn by the RGB-LED even if it is not emitting light. For my particular reed-switch I adjusted the bounce-time down to 150 ms, but if 1000 ms works for your setup I would just keep it that way. @imabot2 has an informative and detailed article in his blog about the low-power-pad: https://lucidar.me/en/esp32/power-consumption-of-esp32-firebeetle-dfr0654/ |
So it takes ~500 microampers without cut and ~11 microampers with cut? |
Yepp, it should be in the ballpark. 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. |
Well, at least it is quite close. The current sketch is improved and could address your error-margin:
TL;DR: Please try the new sketch, WiFi timeouts and a too large debounce time might be responsible for the error you observed. |
Will do! Thanks for explaining. |
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:
That sketch just lights up the LED, when the reed switch is pulled to ground. It helps to check the reed-switch. |
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😬 |
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. |
This doesn't seem to work anymore. I tried multiple times :(
What I would also suggest (if possible) to abb configurable debounce time via MQTT so it is possible to change without updating firmware :) |
This comment was marked as off-topic.
This comment was marked as off-topic.
Hi,
This means:
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. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Ok. So far few days testing counter is 1:1. I will mount it outside soon. Great job |
Last 3 weeks tests: device didn't loose a single pulse. It is 1:1 all the time. |
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. |
Thanks. Great job. I will test in longer period and see battery life. |
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! |
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. |
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.
The text was updated successfully, but these errors were encountered: