The en vogue way of measuring rainfall in commercial rain guages today seems to be 'count the drops' -- where you have a container that drips a known volume of liquid per drop.  With a warming device, this then also will work with snow.  These are nice because there are no moving parts.

Then there's the tip-bucket kind but that entails moving parts (which also can therefore become non-moving parts)

Thirdly, there's the use of a wheel linked to a rotary encoder and a having a number of small rain catchers (think ferris wheel) to make the wheel spin.

In any of these cases the commonly available 'groove opto coupler' sensor could be adapted easily to the task.

Example part:  http://www.electrodragon.com/?product=groove-opto-coupler-optical-sensor-for-arduino-speed-counting

Yes, you would need to define and implement some sort of disassembly/reassembly mechanism.  Such as numbering and sending multiples of the max packet size so they can be put back into the correct order at the receiving end.  Along with that would go incorporating a checkum to assure everything sent was received correctly.

You also have - at most - 4ms transmission intervals before you must relinquish the pipe you are talking into.  Do not forget that.

Is there something to explain what this is that might help the uninitiated (me and others, I'm sure) figure out what this is?  I am reluctant to download what appears may be some code without knowing what I'm getting.  I wouldn't know what to do with it if I DID download it.

Ouch, particularly for such a high-ticket item.  Is there not a formal test suite for pre/post release testing?

What about one of those flex resistor sensors? 

https://www.sparkfun.com/products/8606

I got mine delivered.  They are not what you are looking for.  Maybe these are?

http://www.gree-leds.com/productshow.asp?ArticleID=68501ZT653

I hope you observed the fact the nRF24L01 is a 3.3v device and powered it off the 3v3  pin!

The pingpair example is a good one to start with.  Easy to set up and get it going. 

I second the other poster that the serial port speed would seem to be set wrong.  If the nRF24L01 is not working right, you'll still typically see all zeros or all ones from the .printDetails() when it is called.

The first one I ever tried to wire up, I got mixed up about which way the pins were designated vis a vis the diagram I was referring to.  Be sure you recheck that carefully.

On the plus side, I actually applied power to the wrong pins a couple times at the outset and the little buggers survived.

Being LVDS they would not really be useful without adding lots of hardware to drive the display via the LVDS interface.  Not the sort of thing an Arduino would be able to do/

But if you make your living repairing laptop screens, it could be a very good deal.

Just using Ethernet here.

By the way, I POST some data to a webserver in the following manner.  Note the two 'replace' lines.  My quick and dirty url encoding that satisfied my particular needs although it's not a general solution:

Code:

void AlarmLogger::_serverPostMessage2(radiopacket_t data, String sTime) {

  String PostData = "message=";
  PostData += data.payload.type2.message;
  PostData += "&sensor=";
  PostData += data.sensor_id;
  PostData += "&event=";
  PostData += data.payload.type2.message_code;
  PostData += "&time=";
  PostData += sTime;

  Serial.println(PostData);
 
  PostData.replace('\0',' ');
  PostData.replace(' ', '+');
 
  if (_client.connect(_logger_ip, _logger_port)) {

    Serial.print(F("Connecting..."));

    _client.print(  F("POST /logger.php"));
    _client.println(F(" HTTP/1.1"));
    _client.println(F("Host: 192.168.0.9"));
    _client.println(F("User-Agent: Arduino/1.0"));
    _client.println(F("Content-Type: application/x-www-form-urlencoded"));
    _client.println(F("Connection: close"));
    _client.print(  F("Content-Length: "));
    _client.println(PostData.length());
    _client.println();
    _client.println(PostData);
    _client.stop();

    Serial.println(F("Posted"));
  }
  else {
    Serial.println(F("Did not connect"));
  }
}

A couple of points:

• the "+" is not an error. GET/POST data has a well-defined character set.  Anything outside the set of allowed characters is converted to an allowed representation -- e.g., a <space> becomes a '+', and '+' becomes %2B (ASCII code for '+' represented as a hexadecimal value).
  
  You may use apostrophe OR double-quote to delimit strings sent to the browser.  So you can enclose attributes in apostrophes while the string containing your HTML tag can be delimited with the double-quote:

client.print(" 'maxlength=' ");  // Extra white-space added for clarity of explanation

The rules for correctly-formed http messages are well documented in laborious-to-read RFC specifications like RFC-2616.  You can probably figure out what you need to do by using Firefox with something like the HTTPfox addin.  The RFC is well-suited to curing insomniacs.

I just bought 10 for $5 on eBay over the weekend.  They have the female clamp for LED strips at one end and the 4 pin plug suitable for the typical LED power supply at the other end.  I plan to lop of the pin end

Also, aliexpress.com is the low-volume outlet for alibaba.com.  You will find 10, 20, 50 quantities more easily on the former than the latter.

I just assembled  my first cat and kitten tonight and will try to find time this week to get them online to see how well it works.  I intend to wire them up to some disused CAT5 in my house and some sensors.

I assumed it would talk SPI over pins 11-13 (plus one other for SS) with an Uno, but the example provided uses pins 0, 1 and 2 for an 'SPI LCD' device.  So that kind of surprised me.  Pin 13 is not even routed to any of the 3 RJ45 jacks.   So that leaves one doing their SPI more slowly via software.  I don't suppose that's problem in practice - for remote sensor and control links.

I bought one of these kits and plan on using it to do some home automation stuff.   Since I have all this Cat5 in the walls and attic already and its not used since I went Wi-Fi, it seemed like a no-brainer.

Had to go on hiatus for a little while... I'm back.

I have an Uno working fine now (thousands of cycles over the past several days with no lock ups) with the same code/configuration as I started out with.  I went to a Mega2560 base and that also worked, but I really wanted the Uno form factor.  So on a lark I ordered up a couple of SainSmart's 'black' uno boards they have been offering recently on eBay and calling 'new improved'.  For some reason they work fine in my application.  I can not explain why.  They DO use a different variant of the ATMega chip, but as far as I can tell from perusing the datasheets that's merely packaging, nothing new inside.  The only 'new improved' features appear to be a switchable 3.3/5V supply and 2 more analog pins.

Odd that TWO true-blue Uno's caused me to experience the identical problem but not the SainSmart's.  I assume the things are wired up the same, other than the ATMega chip difference.  The 5 volt rail measures the same on both so evidently not a power supply issue.