Remote control light and fan switch

[masud]

Can anybody please help me to make "remote control light and fan switch". For 2 light and 1 fan speed contro. I need the diagram and the program and advive. My mail: masud4455@yahoo.com. Thanks.

[Spider1211]

Re: Remote control light and fan switch

You post is too vague. What kind of power do you plan on controlling? How many watts are the lamps and fan? From you post, I understand you need 3 button, 2 for each light and 1 for the fan (to turn ON & OFF)? Are they all in the same room?

[masud]

Re: Remote control light and fan switch

I want to control only one cilling fan with speed
Control and two room light on/off, (220v input).
Watts are common as the room light and a cilling fan.

[Spider1211]

Re: Remote control light and fan switch

How many speed is your fan? I assume the lights are normal FL or LED tube (40W)? Post picture of your fan controller box (inside also).

[masud]

Re: Remote control light and fan switch

9 speed of fan.

[televizora]

Re: Remote control light and fan switch

Info about the fan itself? You want to control it with PWM or have 9 separate terminals for the different speeds? You can use MC in both cases. Like PIC18F84A.
But not directly, you have to galvanically separate the outputs of the MC from the mains.

[Curious.George]

Re: Remote control light and fan switch

Info about the fan itself? You want to control it with PWM or have 9 separate terminals for the different speeds? You can use MC in both cases. Like PIC18F84A.
But not directly, you have to galvanically separate the outputs of the MC from the mains.

It makes much more sense to separate the (user control) inputs from the MCU and let the MCU "ride the mains" (transformerless power supply). Particularly if you intend the "controls" to be remotely located -- coupled to the MCU via an RF or Ir link.

You just treat the MCU as if it was a "passive" internal to the device (like a run cap).

But, developing an MCU solution may be beyond the OP's capabilities/resources.

E.g., rather than design/program/build something to allow me to turn the garage lights on/off from inside my car, I just salvaged the control board off an old garage door opener and wired the relay on the board to switch power to the garage light, instead of the GDO's internal light that it was originally designed to control. I then "programmed" one of the extra buttons on the car's remote to talk to THAT opener. Press one button to open/close the door, another to turn the light on (let it self-extinguish just like it would in the original GDO)

[televizora]

Re: Remote control light and fan switch

It makes much more sense to separate the (user control) inputs from the MCU and let the MCU "ride the mains" (transformerless power supply). Particularly if you intend the "controls" to be remotely located -- coupled to the MCU via an RF or Ir link. You just treat the MCU as if it was a "passive" internal to the device (like a run cap).

I would never ever connect MCU via transformerless power supply. The MCU-s need stable input voltage. And switched mode power adapter costs almost nothing.
You always separate the control part from the commutation part if you can. This is a must.
I would use MCU, connect the output to a transistor, and would use the transistor to switch a relay.

[Curious.George]

Re: Remote control light and fan switch

I would never ever connect MCU via transformerless power supply. The MCU-s need stable input voltage. And switched mode power adapter costs almost nothing.

You've obviously never designed high volume electronic equipment? Every PENNY of cost is questioned as to its need. As the user will never come into physical contact with the MCU, there is no need to galvanically isolate it -- any more than there is a need to isolate the gate control signal of a simple dimmer.

A switched mode power supply HAS a cost. For loads with high variation (harder to design as "transformerless") the MCU can regulate it's own power supply (the MCU controls the "switch" that gates power to it's regulated supply). But, the load that the MCU and triac drives represent in this particular application are largely constant so no need for that capability.

You always separate the control part from the commutation part if you can. This is a must.

WHO says "it's a must"? Is there some law of nature that would be violated? Some "regulation"?

I would use MCU, connect the output to a transistor, and would use the transistor to switch a relay.

And others would use smaller and less costly implementations. A few seconds with google:

http://www.seekic.com/circuit_diagra...t_diagram.html

http://www.seekic.com/circuit_diagra...t_diagram.html

https://www.homemade-circuits.com/si...fan-regulator/

http://www.seekic.com/circuit_diagra...er_module.html

Do you see any transformers or other isolation devices in the schematics? Relays? Do you see any "switching power supplies"? Instead, a simple zener acting as a shunt regulator and the impedance of the line coupling cap to "drop" the line voltage (220VAC) to the operating voltage of the zener (6V). Is there some reason the IC's powered by those circuits can't be microcontrollers?

http://www.hamradio.in/circuits/fan_regulator.php

"Since there is no transformer for power-line isolation, the user must be very careful and assess the risks from electric shock hazards."

There's a big difference between how hobbyists (with lots of time and little concern for RECURRING costs as they're only building "one") and industry approach design problems! (Do you really think a hobbyist would design a TV to fail after a couple of years of service??)

[televizora]

Re: Remote control light and fan switch

You've obviously never designed high volume electronic equipment?

I work with computer equipment. So my approach is to galvanically isolate as much as I can or connect to a single ground point. This way you cannot burn something via the current that can run between two points with a different ground reference via the common GND conductor.
It's absolutely true that you can use ballast cap and power MCU from the line directly. But now we speak about amateur that doesn't even know what kind of fan he has. We have to be cautious in our advises not to kill someone. The chip that makes a switched mode PSU to work is fed voltage almost directly from the line - the PWM IC. The truth is that I would rather prefer to isolate from the line and work with low voltage just to be safe. And I mainly work with digital IC-s and low voltages. So this is my approach. One can do what you say, but has to be sure that noone can get in direct contact with the mains. I like double insulated equipment. In this case he has to build something that he probably would never build a second time.
Nevertheless, you cannot run a 230V fan directly from a MCU and you have to use other element to commutate the mains. PWM PSU-s use transistors connected to a IC. But if he has a fan with 9 separate terminals for the different speeds(I highly doubt it) he can just connect the MCU to a PSU, connect 9 transistors and use them to drive 9 relays. Because you cannot drive a relay directly from a MCU.
If we have a FAN that can be PWM controlled, the best approach is to power the MCU from the mains, use a transistor to commutate the mains. Or opto-isolator. I have a plenty of 9 and 12V PSU-s from routers, so it's not a big deal for me. In the first case with 9 terminals he can just use a simple 9 position rotary switch.

[Curious.George]

Re: Remote control light and fan switch

I work with computer equipment. So my approach is to galvanically isolate as much as I can or connect to a single ground point. This way you cannot burn something via the current that can run between two points with a different ground reference via the common GND conductor.

Unless you ADD such a path, one isn't going to magically grow!

Hard to imagine he's going to create an MCU solution -- isolated or not -- any quicker, easier or cheaper than, for example:

https://www.homemade-circuits.com/si...fan-regulator/

"If all you've got is a hammer, then everything looks like a nail" -- MCUs aren't a panacea.

[televizora]

Re: Remote control light and fan switch

"If all you've got is a hammer, then everything looks like a nail" -- MCUs aren't a panacea.

Analog circuits often rely on a many components that have to be with precise values if you want a working circuit. Digital circuits have a fault tolerance and recovery.
Also, complex things are much easier to do with MCU-s, because you can program the MCU what to do.

[Curious.George]

Re: Remote control light and fan switch

Analog circuits often rely on a many components that have to be with precise values if you want a working circuit. Digital circuits have a fault tolerance and recovery.
Also, complex things are much easier to do with MCU-s, because you can program the MCU what to do.

How often do you see "one percent" tolerances specified for analog components? Caps are often +-20% or more -- and often used for timing-related roles. 5% for R's. Wanna guess what you see for L's? I.e., analog circuits are inherently imprecise AND STILL WORK.

Analog circuits automatically recover (unless catastrophic failure). MCUs resort to hacks like watchdogs and brownout detection to prevent them from PERMANENTLY locking up.

If you design anything safety-critical, you don't rely on an MCU/MPU/CPU to enforce your safety but, rather, an ANALOG CIRCUIT that is simpler and far more robust than a microcontroller and umpteen lines of code.

I'm an EE. I've been designing products with microprocessors (before microcontrollers came on the scene) for over 40 years (can you spell i4004?). I'm well aware of their capabilities AND limitations. The "hammer-nail" analogy is a good one for folks who see every problem as needing an MCU-solution. (it likewise applies to folks who think they can come up with an analog circuit to address every problem)

[As a kid, I used to repair pinball machines, "part time". I recall meeting an older technician, one day. He looked at my VOM and asked what it was. I told him what it was, what it could do, how I was using it to troubleshoot the machines, etc. He pulled a length of wire out of his pocket that was obviously old -- the insulation cracked, wire frayed, etc. And, proceeded to show me (in a "fatherly way") how he could do everything that I claimed my meter could do with just that bit of wire. Because he knew the ESSENCE of those actions and could do away with all the fluff that my meter brought to the party!]

Analog circuits can typically be inspected IN THEIR ENTIRETY just by looking at a one or two page schematic. One can write a piece of code that you will likely NEVER understand, completely -- and you'd be hard-pressed to know if that was due to its inherent complexity (i.e., it NEEDS to be this complicated) OR incompetence (i.e., this guy didn't know what he was doing!). That's why you see so many latent bugs in even simple pieces of software -- because the developer couldn't see the forest that he was standing IN!

Witness how easily folks repair/patch SOMEONE ELSE'S hardware designs vs. how clueless they are at "patching" foreign code.

[televizora]

Re: Remote control light and fan switch

How often do you see "one percent" tolerances specified for analog components? Caps are often +-20% or more -- and often used for timing-related roles. 5% for R's. Wanna guess what you see for L's? I.e., analog circuits are inherently imprecise AND STILL WORK.

I'm an EE.

These days, analog circuits are used only to do simple tasks. Everything else is digital. This is because many circuits can interact between themselves and with standard levels and interfaces this is a trivial job. In manufacturing, many companies rely on PLC-s to control critical processes. What I am trying to say is that it's extremely difficult to do complex tasks with analog circuits.
I offered a MCU, because it's much easier for me to program MCU, that relies on little periphery than to design an analog circuit that is specific to the task, and If I don't like it's imprecise behavior to scrap it and start all over again.
It's much more difficult to predict the behavior of a analog circuit in different conditions. For example, if you rely on a resonant circuit, built with capacitors and etc, it would be much more flawed than if you use MCU with it's internal clock generator. And yet, I agree that if you don't need something precise, sometimes it's much easier to accomplish simple tasks with analog circuits.
P.s Im a CE

[Curious.George]

Re: Remote control light and fan switch

These days, analog circuits are used only to do simple tasks. Everything else is digital.

When was the last time you saw a microcontroller in a power supply?

Until recently, most home thermostats ("temperature controllers") were MECHANICAL systems (bimetallic strip and mercury switch).

Voltage regulators in cars used to be "tuned relays".

This is because many circuits can interact between themselves and with standard levels and interfaces this is a trivial job.

All components interact with each other using standard levels and interfaces -- impedance/admittance, current, voltage.

How often have you worked on a "digital" system with more than one logic family? I worked on a box that used HiNil (google it), MECL3, 10K, CMOS and TTL. Because each has specific attributes that were apporpriate in THEIR portion of the system. And the "interface" to the UUT was very sophisticated ANALOG modules (so the voltage levels and transition times could be programmed).

In manufacturing, many companies rely on PLC-s to control critical processes.

And much of the field connects to those PLCs using standardized ANALOG interfaces -- 4-20mA loops, etc. (why hasn't everything standardized on ProfiBus if digital is so much "cleaner"?)

What I am trying to say is that it's extremely difficult to do complex tasks with analog circuits.

Where digital circuits excel is MEMORY; it's expensive to make an analog circuit that has to remember state for any period of time. With memory comes SEQUENCING -- you need to know where you ARE in order to advance to where you WANT to be.

[Note, none of this requires a microcontroller]

I offered a MCU, because it's much easier for me to program MCU, that relies on little periphery than to design an analog circuit that is specific to the task, and If I don't like it's imprecise behavior to scrap it and start all over again.

It may be easier for YOU to program (and REprogram) it. That's not necessarily the case with the OP. I'd wager the schematic I offered woul dbe easier for him to acquire parts AND TOOLS to fabricate than selecting an MCU, learning the programming language, acquiring the tools and successfully implementing the design.

Unless you just want to copy a design -- in which case, I've already offered completed designs!

It's much more difficult to predict the behavior of a analog circuit in different conditions. For example, if you rely on a resonant circuit, built with capacitors and etc, it would be much more flawed than if you use MCU with it's internal clock generator.

I can make the same claims re: an MCU. Have you analysed how the circuit (code) would behave if there was noise on one of the IRQ lines? (are you going to resort to an ANALOG circuit/component to fix that problem? :> ) What if the processor hiccups and ends up halted or in a tight "do nothing" loop? Will you rely on a watchdog to FIX your implementation (sort of like "replace fuse if circuit misbehaves")?

And yet, I agree that if you don't need something precise, sometimes it's much easier to accomplish simple tasks with analog circuits.

I worked on a controller that regulates the "weights" of tablets as they are being formed. A single machine can form 1,000,000 tablets / hour -- about 200 every second! Each has to meet specific acceptance criteria (you want to be sure the dosage in your Viagra isn't too high or low, eh!) But, there are normal variations in the process that lead to variations in the finished product.

In addition to weeding out any INDIVIDUAL tablets that are out of tolerance, you want to tweek the process as it is running (if you shut it down, you will end up discarding several hundred tablets each time it's stopped and then restarted; so, you make the adjustments WHILE its running).

Historically, this was done with a simple ANALOG PID controller that could be implemented in a large pack of cigarettes (neglecting the knobs and indicators). The entire circuit could be spread out on a table and examined, in detail, to verify that it behaved as expected. (tablets that are used for pharmaceutical purposes must be produced in "regulated" conditions to ensure the safety of the product produced)

When this was "computerized", it became "wonderful and complex". Suddenly, the simple indicators weren't sufficient -- you "needed" a graphic display. And, the simple controls were similarly inadequate -- now a keyboard is "essential" to operate it! And, man-years of labor to design and program.

Plus, the persistent uncertainty that there might be bugs in the code! (gasp!)

A box that was previously small, inexpensive, reliable and readily "validated" suddenly became large (monitor, keyboard, computer), expensive, finicky and an exercise in trust ("HOPE it's working properly!")

The "Feeping Creaturism" that is virtually inevitable with programmed devices!

My current design uses a multitude of processors "distributed" to address the specific needs of the application. I synchronize the local timebases in them -- over the network -- to better than 50ns using sophisticated control algorithms. In those cases where I know the processors to be located in close proximity, I "run a SYNC wire" between them -- the "analog" solution. Despite having the same code running on those processors as is used to synchronize them with the remaining "remote" processors. Which task is "simpler"? Which achieves better performance and less uncertainty?

P.s Im a CE

I'm an EE/CS. I can design a power supply, amplifier, CPU (I've designed two), "custom chip", etc. I design programming languages (I'm working on another, presently), compilers, operating systems (my sixth, so far!) as well as "applications". I pick the skillset that is most appropriate and performant to the problem at hand (e.g., use a dedicated wire to synchronize nearby processors but a complex protocol to synchronize them from afar) regardless of "personal appeal".

Because not all problems are "nails".

The trick is then to educate those who must "maintain" my work so they understand why particular implementation decisions were made -- instead of assuming it was just the "easiest thing for me".

[televizora]

Re: Remote control light and fan switch

I argue with you just for the sake if the argument. Meanwhile we learn things.
I prefer MCU because I don't need application specific circuit. I don't need to invent logic, just to write what I want the MCU to do. For everything else you are absolutely right. And yes, I would be idiot not to rely on WDT. And you are right, everything in it's nature is analog. Digital is just fixed set of levels. What makes digital superior in some areas is that digital is more noise resistant and precise, unless we need, the unprecise and Wideband. I also use many types of analog circuits to complement the digital. Simple things I like to do analog. PWM on the other hand with user input is not much simpler to design with analog discrete components. This is why PSU-s have dedicated PWM IC-s. It's much more reliable to limit the number of parts to it's minimum, unless this means much higher price

[Curious.George]

Re: Remote control light and fan switch

I argue with you just for the sake if the argument. Meanwhile we learn things.

Of course! "If two people agree, one of them is superfluous!" :>

I prefer MCU because I don't need application specific circuit. I don't need to invent logic, just to write what I want the MCU to do.

I prefer software solutions because I can tackle more problems with a smaller variety of "solutions". And, because I can add features that would be tedious for me to get right, "first time" (I have colleagues who would opt for "discrete" solutions for exactly the opposite reason).

With VHDL/Verilog, I now find it easy to design custom hardware without having to "invent logic". E.g., I had to prototype a circuit last week and it was easier to just write some VHDL and "burn" an FPGA than it would have been to wire-up a bunch of chips to do the same thing. But, I won't use an FPGA design in production simply because the "bunch of chips" approach is cheaper (and, more maintainable "after-the-sale")

And yes, I would be idiot not to rely on WDT.

My point was that there are insidious issues that come up in an MCU design that wouldn't manifest in a discrete one. And, that those can render the MCU solution "non-functional" whereas the discrete solution may just end up with "suboptimal performance".

[televizora]

Re: Remote control light and fan switch

Yep, nevel dealt seriously with VHDL. Not because I don't wish, but because it's not so big country with fewer opportunities for building custom hardware. So my approach is if I can't build custom IC, the closest thing I can do is to use MCUs readily available as jack of all trades. And this is preferable than building a circuit with many discrete elements, which makes it more prone ti failure.
Software solutions and MCus allow me to handle many variables with fewer hardware, make decisions, handle exceptions and update features without the need of complete rework.
And yes, some low tech solutions are better sometimes. If I need to turn on a fan, I would use thermistor and transistor(and relay if its 230v), not MCU. But if I need to handle different conditions, it's simpler to use MCU. Software one can update easily than hardware.

[Curious.George]

Re: Remote control light and fan switch

Yep, nevel dealt seriously with VHDL. Not because I don't wish, but because it's not so big country with fewer opportunities for building custom hardware.

You don't have to create (full) "custom chips" to benefit from VHDL. You can use it to design FPGAs that act like "programmed circuits".

For example, I designed a graphics processor many years ago that included an instruction that would "draw" (write into memory) the next "dot" on a line. So, if a line was 100 dots long (regardless of "angle"/slope on the screen), it took 100 instructions to completely draw it into memory. (this is probably 10-20 times faster than it would have been, otherwise, with a "conventional", off-the-shelf processor!) At the time, I had to create the logic to do that using MSI TTL components. Nowadays, I would just write some VHDL and let the VHDL compiler figure out how to program a particular FPGA to perform that identical function.

I could put much of the processor IN the FPGA!

There are commercial offerings that pair an MCU with an FPGA so you can let the MCU do the boring stuff and have the FPGA deal with any "special operations" or "special I/O" (e.g., build a PWM controller in the FPGA)

Software solutions and MCus allow me to handle many variables with fewer hardware, make decisions, handle exceptions and update features without the need of complete rework.

This is a double-edged sword, "in production". There, you are faced with cost pressures (to keep PRICE down/profit up). So, you dutifully design the bare minimum that you need to get the (original!) job done.

Then, some Marketing twit comes along and says the company can make a gajillion dollars by offering some new "simple" feature. That, usually, doesn't FIT in the original implementation you came up with! Now, you have to explain why you have to start over instead of just making some "simple" changes to the existing product.

"We decided we could sell a lot more of these Quonset huts as starter homes if they bedrooms on a SECOND FLOOR..."