I am about to embark on a project that involves a ton of wireless controls and sensors.
I like the sound of xbee, but to the tune of what $50 per station I simply cannot afford them all. Also in most cases all I need is binary state
I have some zenith wireless light switches that seem like they would work for the sending portion. Any input there, or suggestion of an remote sensor along these lines?
I am about to embark on a project that involves a ton of wireless controls and sensors.
Are they all going to be transmitting at the same time? If so that is a big problem for a simple system.
Tell us about the project.
Is there one master, or can every station start transmitting ?
At what distance ?
You want a ton of wireless controls and sensors, and also something super simple. Is it okay if commands get lost ?
How many data is going to be transmitted ?
Have you made a choice for the frequency ?
For the 315MHz/433MHz modules, the VirtualWire library is very good. But the data rate is very slow.
There are libraries for many nodes that work together. I have never tried that, but I would like to use it someday.
For many stations, you need a hardware chip that controlls the communication. Like the CC1101, CC2500, C3000.
No simultaneous communication is necessary. These will all be in the same 1bdr apartment, maybe try in different rooms but that is not a strict requirement. On average the master will communicate, at a guess, with one station per hour. These will be simple commands, like "turn on relay", or requests like "what is the temperature?" - I think I am set for the commands, with those Home Depot zenith remote light switches. I have taken a few apart and they look like they fit the bill. Reading back, say, a temperature or switch state, however, is something that I have no idea how to do yet. I mean, the xbee would be great, but then with the number of stations this becomes like a thousand dollar project!
Oh, and to be specific - one master / all stations are passive. Dropped communications are fine (think udp vs tcp). I have not chosen any frequencies yet, except that those cheap switches look good for some stations and obviously have a single fixed frequency.
Its unclear whether you want bi directional transmission capability or not , but if so you need radio modules
that are bi directional and that limits you to Xbees or the NRF series of modules.
If uni directional transmission is OK, then you can use the much cheaper and simpler 433.92 Mhz ASK modules.
Most remote light switches are uni directional.
This seems something for the 315MHz/433MHz modules. Those that can only switch on and off (ASK modules).
The 315MHz is legal in the us, the 433MHz is legal in Europe.
Those remote switches use a bad protocol. There is a library for that protocol, RCSwitch, but that library has bad programming.
My suggestion is to use the very cheap 315MHz/433MHz transmitter/receivers. Be sure to buy the receivers with a crystal ! The most cheap ones are tuned with a coil. If I turn the core of the coil for 20 degrees, it is already mis-tuned.
Use the VirtualWire library with those modules. The VirtualWire library uses a well designed signal, and it is working remarkably well. You can resent the data a few times to be sure it will be received.
http://www.airspayce.com/mikem/arduino/
The VirtualWire requires an interrupt, and if other interrups occur, it might interfere with the timing.
I use VirtualWire with the XTEA encryption and a randon number. When for example the same temperature is measured, a totally different signal is sent.
I add an identifier for the module number and a counter. If I resend the data to be sure, the counter will be the same, so the receiver knows that the data is already received.
I have a dedicated Arduino to receive the signals. That way the VirtualWire runs without problems. The received data is going directly into EEPROM (the location is determined with the module number) with a timestamp. In my main Arduino I request data from dedicated arduino via I2C if needed.
I had to add the timestamp when data is received and stored in EEPROM. That way I can tell if the data is 5 minutes old, or that something did go wrong when it is 5 days old. The timestamp is the actual 32-bit unix time, this is requested via internet when the main Arduino starts, and that is passed on to the dedicated Arduino.