💬 Rain Gauge

[Enfeet]

@dbemowsk i use first found online calculator http://onlinemschool.com/math/assistance/figures_area/circle/
and... strange.... it gives other result ;-) So my calculations are incorrect ;-(
A = 1 4 π d2 = 1 4 π 1122 = 3136 π ≈ 9852.032512

SY
Sergey

[Enfeet]

@Enfeet o! d=122 not 112... uff correct ;-)

[dbemowsk]

@Enfeet I have been trying to wrap my head around the formulas for this. I have been basing numbers off of the formulas on this instructables page and after looking at his numbers, I think he has them wrong too. He states :

rainfall height = volume of rain collected / catchment area

In my rain collector, the length and breadth were 11 cm by 5 cm respectively giving a catchment area of 55 sq.cm. So a collection of 9 milliliters of rain would mean 9 cc/55 sq.cm = 0.16363... cm = 1.6363... mm = 0.394 inches.

9cc/55 is 0.16363 cm, but 1.6363 mm does not equal 0.394 inches as stated in the article. According to the conversion I did it is 0.064421. Did I do a calculation wrong?

[Enfeet]

@dbemowsk I think it's time to look in a book ;-) "The amount of precipitation is expressed in millimeters of a layer of water that would be formed from the precipitation, if they did not evaporate, did not seep into the soil and would not drain. Numerically, the amount of precipitation in millimeters is equal to the amount of kilograms of water left on the site in 1 sq.meter, i.e. 1 mm = 1 kg / 1 m2.

[Enfeet]

@Enfeet Precipitation intensity
"Strong" is called rain, if it drops from 15 to 49 mm in 12 hours. Precipitation is also "very strong" when it falls from 50 mm in 12 hours.
"Strong snow" - the amount of precipitation from 7 to 19 mm for 12 hours. "Very heavy snow," when its amount exceeds 20 mm in 12 hours.

[dbemowsk]

@Enfeet I understand that, my point was I guess more that it gets confusing when the person that wrote the article gets the numbers wrong. The other part that can get a little confusing in this at times is the units of measure and the conversions. When you talk about mm (length) vs mm2 (area) vs mm3 (volume) and you start mixing these together in the calculations. I am in the US, so I work with imperial measures, so then there is the conversions from metric to imperial on top of that. The thing that I think the guy that wrote the article got wrong was his conversion to imperial measure (inches of rainfall). That is more what I was trying to wrap my head around.

[Enfeet]

@dbemowsk Sorry, i m living in metric units ;-) But, i think it can be calculated logically. Just look at a DIY project: https://www.education.com/science-fair/article/DIY-rain-gauge/ The logic is to attach a scale to a bottle and measure the mm or inches of rain occured. Our goal is recalculate the number of impulses to the amount of precipitation depending on square of our bucket. So it's possible to take a bottle with the same square like our bucket, attach a scale (inches or mm does not matter) and let collect all water out of our measuring gauge i.e. take a litter or half flow it to a gauge and collect after. And finally just divide measured level of collected water to the number of impulses counted....
Sorry if method is not clear... ;-) I can draw an idea in a pictures ;-)

[Enfeet]

Ups! After 3 days.....

[schmucke]

What kind of powersupply is a good one, if i have errors with bouncing/fakerain?

[Enfeet]

@schmucke I'm using 5V 1Amp from tiny mobile charger https://www.thingiverse.com/thing:2171813

[schmucke]

I have the following problem:

Every Time, if a normal switch with a led bulb is switching, the arduino is count one up...

[mfalkvidd]

Sounds like the hardware debouncing described in the troubleshooting section might be needed.

[schmucke]

I have just one build, but i use 300ohm. I think, thats to small :/

[kotzer]

nice idea, nice project, nice documentation, nice result :+1: :heart: :heart:
but i've a problem with the led. this is only HIGH when the arduino boots up for ~2 secs. then set to 0 (LOW).

i adjusted some debugging message to find out, what exactly happens, but am stucking here.. in the loop it goes into slowFlash(), but there nothing is called against the led_pin (because of if (millis() - pulseStart < 100UL))

what am i doing wrong?
why is the led only fired at startup, but not when trapped (manually closed the reed switch for short time to simulate some rain)?
what was the intension of the led? (nothing could be found in description & video of pete)
@petewill I don't see the led in your vid... where is it?

[itbeyond]

Folks, A question of interest. I have had my gauge working great for several months but it has just started to play up. It seems to crash after a few hours. I have not plugged in a debug/console or anything as yet but decided to have a good look at the code and I have noticed that every hour the system cycles through updating EPROM values to cascade the rain rates. I have also noted with interest a comment in the API that mentions some 300K updates as max for the EPROM - I just looked at the Ardunio documentation and it states 100K read/write cycles till EPROM failure. If I am reading this right then maybe my problems are related to dead EPROM storage caused after months of hourly write cycles - Is this a possibility and if yes should we not look at another method of update management for the gauge - I do not want to have to trash an Arduino every few months, I am looking at the code and need more time to get a full handle on it however there appears to be write cycles every hour even if the values have not changed. Is this something to investigate? Is there a way to know if an Arduino EPROM has failed due to excessive write cycles?

[mfalkvidd]

@itbeyond there are 8,760 hours in a year, so 100,000 writes should last more than 10 years.
MySensors does not re-write the same data if the data has not changed, so a save call does not always result in a write.
The code uses a ring buffer to lessen the risk of writing too much to a single eeprom position.

So eeprom writes should not be a problem. But maybe Arduino clones can't handle 100,000 writes?

I guess an alternative could be to store the data in ram and send it to the controller periodically so the data can be fetched when the Arduino (re)boots. Or do the aggregation on the controller, where ram and storage is plentiful.

The best way I know to detect eeprom failures is to repeatedly read and measure time for each read. On esp8266 I've seen reads that take more than 100x normal time when the eeprom was damaged.

[itbeyond]

@mfalkvidd thanks for the important info on the saveState - I have not looked at the API code in this respect and if it does not write same data this is a very good. I have also looked into the code some more there are 4 possible writes per hour which using your maths is 35k write per year so it still should be good for a few years (clones well yes who knows). I may have another problem but I am not sure what - if I reboot it is runs fine for several hours and randomly seems to stop sending data however even if the EPROM is stuffed it should not affect the temp, hum and light level sensors. I may be seeing some funny humid reading so the DHT could be faulty also - I may replace this firstly and see what the result is. Thanks for the response.

[Enfeet]

Hi all,

finally i rewrite a code for myself. There is no More EEPROM usage at all.
I'm using MajorDoMo (http://majordomohome.com/) and it more suitable for me to have a 10 minutes counts from Rain Gauge.

Here is my new code:

#define MY_RFM69_ENABLE_ENCRYPTION

/**
 * 
 Author: Sergey E. Yakovlev
 Date: 2017/02/25 u001
 
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2015 Sensnology AB
 * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
*/

#define SKETCH_NAME "Enic Rain Gauge"
#define SKETCH_VERSION "0.1"
#define DWELL_TIME 40  // this allows for radio to come back to power after a transmission, ideally 0 
#define DHT_ON // uncomment out this line to enable DHT sensor



// Enable debug prints to serial monitor
//#define MY_DEBUG
//#define MY_DEBUG_VERBOSE
//#define MY_NODE_ID AUTO
#define MY_NODE_ID 15
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY RF69_433MHZ
#define MY_RFM69_NETWORKID 100
#define MY_RFM69_TX_POWER 31

#include <MySensors.h>
#include <Adafruit_Sensor.h>
#include <DHT_U.h>
#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
#define CHILD_ID_RAIN_LOG 3  // Keeps track of accumulated rainfall
int tipSensorPin = 3; // Pin the tipping bucket is connected to. Must be interrupt capable pin
int ledPin = 5; // Pin the LED is connected to.  PWM capable pin required
#define DHTPIN       8         // Pin which is connected to the DHT sensor.
// Uncomment the type of sensor in use:
//#define DHTTYPE           DHT11     // DHT 11 
#define DHTTYPE           DHT22     // DHT 22 (AM2302)
//#define DHTTYPE           DHT21     // DHT 21 (AM2301)
char buff[10];
unsigned long SEND_FREQUENCY = 60000*10; // Minimum time between send (in milliseconds). We don't wnat to spam the gateway.
DHT_Unified dht(DHTPIN, DHTTYPE);
#define TIP_SENSOR_PIN 3
//d=112 mm
//11689.863832 mm2 =  116,89863832 cm2
//42,77209787776081 mm
//88 89 91 91 90 = 89,8
//0,4763039852757329
#define CALIBRATE_FACTOR 48 // amount of rain per rain bucket tip e.g. 5 is .05mm
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
MyMessage msgRain(CHILD_ID_RAIN_LOG, V_RAIN);

sensors_event_t event;
unsigned long lastSend;               //Last Send millis()
unsigned long lastTipTime=millis();
volatile unsigned int rainBucket=0;

void presentation()  {
  // Register all sensors to gw (they will be created as child devices)
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  wait(DWELL_TIME);
  present(CHILD_ID_RAIN_LOG, S_RAIN);
  wait(DWELL_TIME);

#ifdef DHT_ON
  present(CHILD_ID_HUM, S_HUM);
  wait(DWELL_TIME);
  present(CHILD_ID_TEMP, S_TEMP);
  wait(DWELL_TIME);
#endif


//  M_DEBUG_PRINTLN(F("Sensor Presentation Complete"));
}

void setup()
{
  // Set up the IO
  pinMode(TIP_SENSOR_PIN, INPUT);
  attachInterrupt (digitalPinToInterrupt(TIP_SENSOR_PIN), sensorTipped, FALLING);  // depending on location of the hall effect sensor may need CHANGE
  pinMode(ledPin, OUTPUT);
  digitalWrite(ledPin, HIGH);

}

void loop(){
  unsigned long now = millis();
  if (now - lastSend > SEND_FREQUENCY) {
  send(msgRain.set((float)rainBucket / 100, 1));
  rainBucket=0;
  wait(DWELL_TIME);

  // Get temperature event and print its value.
  double t = -1;
  dht.temperature().getEvent(&event);
  if (isnan(event.temperature)) {
    debug(PSTR("!USR:DHT:Error reading temperature!\n"));
  } else {
      t = event.temperature;
      dtostrf(t,6,(uint8_t)2,buff); 
      debug(PSTR("USR:DHT:t=%s\n"),buff);
      send(msgTemp.set(buff)); 
  }
  // Get humidity event and print its value.
  double h = -1;
  dht.humidity().getEvent(&event);
  if (isnan(event.relative_humidity)) {
    debug(PSTR("!USR:DHT:Error reading humidity!\n"));
  } else {
      h = event.relative_humidity;
      dtostrf(h,6,(uint8_t)2,buff); 
      debug(PSTR("USR:DHT:h=%s\n"),buff);
      send(msgHum.set(buff));        
  }
    lastSend=now;
  }
}
void sensorTipped()
{
  unsigned long thisTipTime = millis();
  if (thisTipTime - lastTipTime > 100UL)
  {
    rainBucket += CALIBRATE_FACTOR; // adds CALIBRATE_FACTOR hundredths of unit each tip
  }
  lastTipTime = thisTipTime;
}

And now i able to see when it was a rain and how strong it was ;-)

---

SY
Sergey

[petewill]

@itbeyond Like @mfalkvidd pointed out eeprom writes are done to multiple locations so it actually gets 120 hours before the same eeprom location is used. So, 120 X 100,000 is over 1,000 years (if my math is right). That should be enough :)

The good thing about using eeprom is that you won't loose any data if your gateway is down or the communication is lost for some reason.

I think you are correct debugging other areas like the DHT. Also, is there a chance your arduino got wet? That could also cause issues.

[haroon552]

Hi, dear how can we connect with application or something to watch and to connect with nidemcu?