Earthquake switch for a ceiling fan

Hi Guys,
This is my first post. I hope you're all well.
Though I've written a few small sketches for testing purposes, I'm still a newbie to Arduino and what it can do.

I live in earthquake prone Japan, and for my first project I want to build an automatic shutdown switch for a ceiling fan that will power it down in the event of an earthquake. The thought of five blades 52" in diam spinning around over our heads with an earthquake in progress is not very comforting. The catch is that the command to shut it down must come from the remote control receiver that came with the fan. This is because the built-in control unit has a "instant stop" feature that stops the rotation in a few seconds instead of a minute or more if the power were cut by simply hitting the fan's wall switch.

My thought is to rig an earthquake sensor switch at the fan mount (easily done) and have it output a logic level to an Arduino housed just above the fan body. The Arduino would then transmit the "fan off" radio code to the fan's receiver located in the canopy, which is the metal cone that hides the wire connections and physical attachment to the ceiling. The distance from the Arduino to the rx is only a foot or so so high power is not necessary. To Keep It Simple and improve reliability, however, I would rather not hack into the existing receiver, only tap into it with radio waves, as it was intended to be operated. That will avoid voiding the warranty and allow me to easily revert back to the original design if the project fails to meet its objectives.

I need to know how to do the following:

  1. How to capture the RF stop code from the remote tx on an oscilloscope. What circuit do I need?
  2. How to duplicate the stop code using Arduino software.
  3. How to build, or what to buy, a mini tx with the same frequency as the handheld remote that will transmit the stop code from the Arduino. What shield do I need?

The fan is an American Hunter, model 26420, with Hunter Remote model 27224. The remote uses RF, not IR. I don't know the frequency. That too, would need to be determined.

Many thanks in advance for any help you can give!

You can probably just use a transistor across the stop button pins in the remote to keep things simple.

http://web.comporium.net/~shb/irmods.htm

I would take a guess at it being 433mhz, as most RF switches usually are. Luckily there is a library for this very problem, its called RCswitch and allows you to read the code from the control and transmit the code once you know what it is.

All you need is a 433mhz RX and TX module, the cheap chinese models will work fine. Once you have them wired up its as simple as:

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();
int ldrValue;
int ldrPin = 0;
void setup() {

  Serial.begin(9600);
  
  // Transmitter is connected to Arduino Pin #10  
  mySwitch.enableTransmit(10);

  // Optional set pulse length.
  // mySwitch.setPulseLength(320);
  
  // Optional set number of transmission repetitions.
  // mySwitch.setRepeatTransmit(15);
  
}

void loop() {

ldrValue = analogRead(ldrPin);  
 
  Serial.print("Analog reading = ");
  Serial.print(ldrValue);    

  if (ldrValue < 300) {
    mySwitch.send(4927279, 24); //here is the code for my transmitter, found using the RCswitch lib
  } else if (ldrValue > 301) {
    mySwitch.send(4927271, 24);
 
  }
  delay(100);
}

Excuse the messy code, it works :wink: This allows me to turn my lights on and off depending how dark it is(its set up with a LDR).
With the mySwitch.setRepeatTransmit(15); option you could set it to repeatedly send the code to ensure it is recieved by the fan. This should do the job and seems relatively cheap to get up and running, Im sure you could pick up the RF modules from Akihabara if you're nearby.

Many thanks, thegeekway, for this info! That certainly is a good start.

I assume that one of these tx/rx pairs would work: http://www.robotshop.com/ca/433mhz-high-sensitivity-transmitter-receiver-pair-rxa33.html

I'm still confused, however, on how the Arduino sends the stop code to the mini-tx so the fan's rx can decode and execute it. If I read the referenced library correctly, it suggests attaching the handheld remote to the Arduino just long enough to store the code in the Arduino's memory. I assume that it will convert the code into some text form that I will then write into the Arduino's program. My intention is to thereafter detach the Arduino from the handheld and move it to the fan where it will reside permanently in a box above the fan body. Attached to the Arduino's output pin will be the input to the mini-tx. When an earthquake occurs, the Arduino will detect the event and send the stop code to the mini-tx, which will then broadcast it to the fan's built-in rx, which will then execute the command. The mini-rx that comes with the mini-tx/rx pair isn't needed as the fan's built-in rx will be retaining its normal functions. Is this the normal approach to solving these problems?

Questions:

  1. The fan's rx has dip switches that are used to change frequencies to avoid interference from other household devices. Is the mini-tx similarly adjustable?
  2. Will the mini-tx convert the code to the proper modulation format or does the Arduino do this? If the latter, how do I make the Arduino do this?

I don't want to permanently attach anything to my handheld as that will "borgify" it to the point where it won't be used. The idea is to retain the original handheld as is and have the Arduino duplicate its stop code signal when an event occurs.

Again, many thanks for your help on this!

Hi, that RX/TX will work fine, you just need to ensure the fan is setto 433mhz, which after a little browsing seems to be the case. You wont need to modify anything,first of all just plug in the RX module to your Arduino (VCC, GND, Data[Pin2]) and load up the sketch RecieveDemo from the examples folder. Once running press the stop button on your remote and in the serial monitor it should give you the remote code information. Copy and paste it somewhere safe for now and create and simple sketch to test it works:

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();

void setup() {

  Serial.begin(9600);
  
  // Transmitter is connected to Arduino Pin #10  
  mySwitch.enableTransmit(10);

  // Optional set pulse length.
  // mySwitch.setPulseLength(320);  
  
}

void loop() {

  /*using decimal code */
  mySwitch.send(5393, 24); //replace 5393 with your code

  delay(20000);
}

And if everything is working ok, your fan should stop. Then it is just a case of hooking up your detection method and using a little extra code to get it working.

Thanks, I'll try that. I have some parts to order first, including a fan. I wanted to get this problem worked out before spending the money on the fan and parts as they're really hard to return from Japan if I make a mistake. Thanks to your help, I think I now have a good handle on it.

Regarding your code, can you tell me what the 24 is for?

mySwitch.send(5393, 24); //replace 5393 with your code

And the "set pulse length" variable of 320us is the length of the data stream from each push of a button on the handheld, correct? Is that an industry standard or just what you've found works best?

Thanks again.

The library (btw: I wrote it :slight_smile: ) is functional for all ordinary low cost devices with a SC5262 / SC5272, HX2262 / HX2272, PT2262 / PT2272, EV1527, RT1527, FP1527 or HS1527 (maybe more/other ones I only know these) chipset built in the remote handset and as you don't know much about your system there is absolutely no guarantee that it will work as is with your fan because:

  • The frequency might be another. Common frequencies are 315, 433, 868MHz (usually for simple remotes. mostly depends on what is legal in your region) or 2,4GHz (usually more complex things like wifi, bluetooth, video, xbee)
  • (I don't think so but) the modulation AM/FM might be different
  • The encoding might be another (there is no official standard but there is a good chance to reverse engineer this)
  • There might be any kind of security system to prevent your system to be used by others. The systems for opening car doors often use a "rolling code" (=>keeloq) for example. That is sending a different code each time you press the button, based on a algorithm known to the transmitter and known to the receiver. Obviously these algorithms are closed source so I'd say it's nearly impossible to control these devices (except soldering a optocoupler/relay/transistor to the buttons on the genuine remote control)

Regarding your code, can you tell me what the 24 is for?

It's the bit length. The code is send binary and must be 24bits long.
5393 = 1010100010001b and to make it 24bits it is zero filled to 000000000001010100010001b

And the "set pulse length" variable of 320us is the length of the data stream from each push of a button on the handheld, correct? Is that an industry standard or just what you've found works best?

Something of the kind. It's the time for sending 1/4 bit... I can tell more about it if you're really interested in all the details :slight_smile:
I think I've once seen a certain valid range in a datasheet and in practical experience there are values between 250 and 500us. You may set it to the value measured from your original remote and it might be useful to experiment with different values for fine tuning but in fact it shouldn't make a difference cause as I believe the receiver doesn't detect absolute but relative timings.

Hello, sui, it's good to make your acquaintance. You have some great stuff here. While I'm no stranger to computers, dealing with micro-controller code is a new experience for me. Your work here has shortened my learning curve considerably.

I suspected as much about the code length, but had no idea the pulse length only represented 1/4 bit. I would be interested in learning more about that, if/when you get the chance.

As for the Hunter remote, I have heard that it is not very robust in terms of filtering unwanted signals. There have been reports that electrical and/or RF interference can make the fan turn on by itself. Usually it is caused by other nearby RF controlled devices which is why there are four dip switches to help you switch to a frequency that is not so noisy, but often this can occur in the middle of the night when such devices shouldn't be in use. Have any of your RF devices shown that behavior? I doubt that'll become a problem for me here, but if it does, what I learn here will help me a lot in tracking it down and correcting it.

kmpres:
I suspected as much about the code length, but had no idea the pulse length only represented 1/4 bit. I would be interested in learning more about that, if/when you get the chance.

The transmission method for AM transmitters/receivers is called On-Off Keying. That means the transmitter is actually switched on (the receiver receives a High-Level) or off (the receiver receives Noise/Low-Level). The line coding for these chipsets is defined as (t is the pulse length):

  • switching on for a period of 1t and switching off for a period of 3t represents a bit value of 0
  • switching it on for a period of 3t and off for 1t represents a bit value of 1
  • switching it on for a period of 1t and off for 31t represents the synchronization bit, which is sent between the transmission of complete values

A typical 24Bit value looks like this:

And due to the fact that the transmission is indeed not very robust, every value has to be sent a couple of times (10x by default in the library or as long as you press the button on the remote)

As for the Hunter remote, I have heard that it is not very robust in terms of filtering unwanted signals. There have been reports that electrical and/or RF interference can make the fan turn on by itself. Usually it is caused by other nearby RF controlled devices which is why there are four dip switches to help you switch to a frequency that is not so noisy, but often this can occur in the middle of the night when such devices shouldn't be in use. Have any of your RF devices shown that behavior? I doubt that'll become a problem for me here, but if it does, what I learn here will help me a lot in tracking it down and correcting it.

I think it's absolutely impossible to switch these devices by interferences or noise - they only react to a very specific sequence. It's more likely that one of your neighbours is using a similar device (if the remote is configured with only 4 dip switches it is only possible to control up to 16 different fans) or has sniffed your remote and wants to annoy you :slight_smile:

Well... I remember when I was a child I had a RC car which reacted to walkie talkies but that was analogue technique...

Ah, that explains a lot. No need for fancy modulation when you can just turn the carrier on and off. Reminds me of Morse Code. It's also good to know that these circuits are not wildly subject to interference. I'd been thinking that a loose ground or maybe nearby lightning was causing some people's fans to turn on by themselves, but you think it's more likely that a neighbor's fan or other nearby RF device is turning them on. Probably not a problem for me in the Japanese country village where I live.

Thanks for the cool graphic. It really nails the concept down for me.

Any updates? I'm really curious about this project :wink:

It will take a few weeks for parts to arrive from the US, including the fan. I'm also studying for a big certs test so I'll be preoccupied with that until the end of the month. :cold_sweat:

In the mean time, I've added an xBee shield to the design so I can program the Arduino remotely without having to remove it from the fan.

I'll keep you posted.

That a good question. I installed ceiling fans for many years, I do not understand myself. Instructions for the majority of fans say that hot air rises, so in warm weather you want the fan to move air to cool the cold weather you want to push room.In warm air down. This sounds reasonable. Even in the switch will pull the air toward the right and down until you blow the air over his shoulder to the left.

Interesting. I'm not sure what you said but it's interesting.:smiley: You're correct, though. In warm weather you want the fan to blow down to directly cool the occupants. This takes advantage of the wind-chill phenomenon. In cool weather you want the fan to blow towards the ceiling to circulate the warm air that tends to collect there and spread it around the room. This makes your heaters work more efficiently.

Any progress on this?

What about using a sound fork and tilt sensor and a relay for making it. Use the sound fork as the object of vibration and get the vibration using tilt sensor.

Have to fix that sound fork in the wall or ground.

Just an idea.