Reinventing the Wireless Plug With ESP8266

by NLD in Circuits > Remote Control

13017 Views, 43 Favorites, 0 Comments

Reinventing the Wireless Plug With ESP8266

20191022_143053.jpg
R2.png
IMG_2689.JPG
20191022_141411.jpg

2025 update: as this project proved to be extremely useful a new version was calling for itself. Instead of creating a new Instructable I will just replace the schematics and codes here as there were some issues with the old one, namely:


  1. The Wemos D1 relay board was badly engineered, although at the beginning all worked, in 2 years of constant operation 80% of the plugs failed, this was due to some components on it died from the back emf, then the relay did not get enough power anymore either to close or open leading to unreliable operation.
  2. As I described it in the old article using a shield was a bad idea to begin with, therefore the relay circuit is now fully incorporated into this board, if I went so far why not do the same with the ACS712, to make it even better all the current components can be ordered from the LCSC store, basically only your Wemos D1 mini which needs to be bought separately and it can be plugged into the ready made board.
  3. All the input/outputs were moved to "safe pins" see the explanation later on why.
  4. All the regular double sided traces were replaced with even thicker copper zones.
  5. I have removed the extra article about the "Arduino based smart plug" and the SSL support as both turned to be a bad idea


In this tutorial I will describe how to create a secure and reliable wireless plug based on the tiny ESP8266 D1 Wemos mini for controlling appliances in your home.

Cheap 433MHz Remote Controlled Switches have their advantage of being cheap and easy to use, you buy them push 1-2-3-4 ON/OFF on the remote and they just work out-of-the-box but from security point of view they are terrible, only that does not control them who don't want to. Someone can walk up to your home with 4-5 different set of remotes and with a good chance he is now in control of at least some of your wireless plugs. This by itself would not even be an issue if they would not be unreliable. 95% of the time they work but what about the 5% when they don't. That is unacceptable for engineers. Most of these remotes implement repeated resending to increase the success rate (when you push the button on a remote once it sends the ON packet multiple times and hopes for the best). You might want to control some more important components than lights like solenoids or motors with these and since they don't contain a transmitter, don't signal back. There is no way for you to know if the device you sent the command to, turned ON or OFF.

I started to design this plug with barebone Atmega328P due to it's low power consumption and it was just enough for the purpose but when trying to implement wireless encryption with such a tiny MCU I ran into difficulties so it remained a PoC. I will still include my research in a chapter, it might be useful for someone in the future. As a side note here at the start that playing with the mains voltage (110V/230V) is dangerous, if you have just started with electronics you should only build low voltage circuits, this build is only for experienced engineers (build it for your own risk).

Harware Design

20190820_082922.jpg
20190831_160828.jpg
20190901_133655.jpg
20190901_133434.jpg
20190901_143830.jpg
IMG_2692.JPG
WeMos-D1-Mini-Safe-GPIO-Pins.png

After not having enough different Home Easy, Intertechno switches in my home I have bought a bunch of secondhand Home Easies again (due to they had a working Arduino Library already) but then I sadly noticed that this series using different encoding or preamble, the Intertechnos (with mechanical rotary selectors) regularly misaligned when they were re-plugged and all of them can be considered unreliable due to the way they work so it was finally time to design my own wireless plug and stop using these commercial :smart: plugs once and for all.

These wireless plugs are very simple devices, they powering their main circuits with a cheap inefficient transformerless power supply (TPS) circuit which steps the mains (230/110V) down to lower voltages (then regulates it AC->DC) what the circuit needs. Then there is a 433Mhz RX module (which looks familiar (same?) to what we can buy for the Arduino's) which goes into the main MCU which processes the data (some more advanced devices can be put into learning mode) and if the incoming signal matches with the ON/OFF signal then they turn the relay ON/OFF.

There are plenty of good tutorials on Instructables about how do they work and how to use them with the Arduino such as: https://www.instructables.com/id/Using-433MHz-Remote-Controlled-Switches-on-Arduino/

I used different models of HE (Home Easy), Intertechno, noname switches in the past what I can sort into 5 categories:

1, Single signal ON/OFF switch with RCswitch library. These devices are the worst, they don't have a specific ON or OFF signal they will go into ON position the first time they are connected to the main then they basically flip flopping, you cannot determine the state. They are not good for anything, avoid them.

2, Wireless ONLY smart plugs with dials/dip switches, they can be only turned ON/OFF with the remote there are 2 dials to adjust the GROUPS/SWITCHES like Group III Switch C. The problem with these dials that even from small fractions (pulling the plug out and replugging it) they can shift out of position, also since there is no manual ON/OFF button on the device if your remote control fails or you just want to switch the thing on right now you are out of luck. Avoid these as well.

3, Wireless plugs with manual ON/OFF (same as the category before but with manual override).

4, Wireless plugs with learning mode switch. In this mode once the programming switch is pushed in for 5-10 seconds the plug enters into learning mode which is indicated by the LED blinking. The devices look for a certain signal set matching the manufacturers predefined codes (eg code of Group II Switch A) once they detect this the blinking stops and the device learned the code (paired).

5, 3+4 combined, these are the best kind of outlets you can get. I never run into any issues with them that they forgot the code and you can easily reprogram them if you have to.

But none of these cheapies will ever be anywhere close as good as this project. There are 2 more major issues with the commercial outlets: one is interference (try to plug 2 smart plugs right next to each other and see what happens or rather what is NOT happening). Since they are using the same bands, encodings you can be unintentionally turning on/off your neighbors devices in a flat. The 433Mhz signal is fairly good with passing through walls and the signal strength is not bad either since the remotes work from mini 12V batteries. This just leads to the second point that they have zero security. If anyone knows about you are using wireless plugs to turn on/off some of your devices all he has to do is go close to your house with 4-5 different remotes made for the major brands and most likely he will be lucky.

With the ESP32 already succeeded the ESP8266 and offers dual cores and other goodies the question is why did I chose the ESP8266 and in particular the Wemos D1 Mini for this build? The answer is: the size. At the time of my original design idea (2018) this seemed to be the smallest board compared to other ESP32 boards and it even had a relay shield. With this shield it stayed within the 25mm height limit of the HE wireless plug, however as you will see eventually the case had to be extended. Regardless that the ESP8266 is under the ESP32 in performance you cannot even compare it in processing power to any Arduino boards, it would be something like 10x better (16Mhz Vs 160Mhz) with a lot more memory as well.

Old and new smartplug design:

In case of my old setup there was a Raspberry PI (which later got swapped out to a PC104 running NetBSD for industrial gradyness :P) -> Arduino -> 433 Mhz transmitter controlling ALL the wireless plugs it also introduced a single point of failure. What if the PI or Arduino (not likely) crashes, then all the home control is down.

This new design is completely decentralized (no blockchains yet :P), the only point of centralization is the wireless access point and if you worry about that you can just easily link multiple APs in a WDS net and the plugs will connect automatically to whichever is on and reachable. The wifi connection is extremely quick, the device connects and reachable in 1-2 seconds after powering on.

Extending the functionality:

As it is a way faster MCU than what the original "smart plug's" had what else can be done with it:

-State detection: as I mentioned this was the main reason why I designed this circuit to always know if the device is ON or OFF, this value is stored constantly in a global variable and also written to the FLASH. This yields complete reliability over the old approach which was send the command X times to the "smartplug" via 433Mhz radio and hope for the best. Here in case of m2m communication the remote machine exactly knows if the device is reachable on https and can resend the command X times if it's not and TCP/IP is guaranteeing reliability and automatic packet resend in case of lost/duplicated packets on wifi.

-Current metering: ACS712 was added for current measurement. Since the AC voltage is constant 230/110V we can determine the power (Watts) or the power consumption during time period (Watt Hours). I have left the PowerAVG calculation in from EOL, it could come handy in situations where you need to do the same thing (create alerts to see if a device is finished the work). Matter of fact this whole code is based on EOL, this project could easily replace it if wifi would go so far as my basement :P

-Keep state over restarts: Fortunately having such a great mini computer built in, this feature is now easily accessible. Device state can be saved in the FLASH: although the write cycle for ESP8266 is limited somewhere around 100K for the FLASH if you consider that the plug will be turned ON and OFF one single time every day and the state will be saved to the FLASH right away that is only 730 writes/year so it should not be an issue for the next 100 years.

-Programmable timer: I added this feature just to demonstrate that even if you add the functionality of a regular wireless plug + a timer plug together they still cannot compete with my project. Of course the ESP8266 can easily do programmed turn ONs and OFFs as well and it will be even more accurate because it sync with NTP every day while a cheap timer plug drifts off with seconds, minutes over time.

If you are still not satisfied with the functionality of the new plug a smaller Multi User Dungeon can be still implemented over TELNET :D

While having all these features is nice, I always implement manual control (at least a single push button to manually be able to turn the device ON or OFF).

Bill of materials

  1. 1X HLK-PM01 5V/0.6A isolated power supply
  2. 1X Wemos d1 mini
  3. 1X Wemos d1 mini relay shield (integrated into the board)
  4. 3X 300 ohm resistors
  5. 1X 10Kohm resistor
  6. 1X 2K2ohm resistor
  7. 1X RGB 4pin LED (Common Anode)
  8. 1X Push button
  9. 1X ACS712 20A (integrated into the board)
  10. 1X Fuse holder
  11. 1X 10A fuse

Wemos D1 mini hardware

Microcontroller ESP-8266EX

Operating Voltage 3.3V

Digital I/O Pins 11

Analog Input Pins 1(Max input: 3.2V)

Clock Speed 80MHz/160MHz

Flash 4M bytes

Length 34.2mm

Width 25.6mm

Weight 3g

Note: This board has one terrible inconsistent pinout, to make it a bit more consistent I have printed and using the Blue Arduino pinout everywhere.

Some pins were moved to the "safe pins", its explained here why: https://lastminuteengineers.com/wemos-d1-mini-pinout-reference/


The circuit board is attached and can be easily imported into EasyEDA (you can also order the components to be pick and placed on it, however the exact same ones will not be available too long, you need to chose a similar component when they are not in store eg: another 10k film resistor, the only way to replace these is to delete them from the sketch and add a new one which is in store).

Case Design

20191022_143243.jpg
20190901_142117.jpg
placement.png

I have designed this board to be fitted into the HE874/HE878 wireless plug/dimmer cases (although no matter how I ordered the components it would not fit because I wanted to keep the middle push button, the LED and the screw hole(s) at the same place). 3D printing cannot compete with hard melted plastic and although this plug is still kinda expensive at the time of writing (15$) you might be able to pickup a bunch second hand/for parts on smaller auction sites for a low price. The HomeEasy series of wireless plugs and dimmers have similar form factors as well so the board can be easily modified to fit into another models case. The board ended up to be longer than what could be fitted into the plugs original case so I have created a 3D printed extension box to complete the case.

If you wonder how did I manage to fit my components in the case perfectly. It' is not due to precisely measuring everything (although I did do some prior measurements with a ruler) but just pulling a simple trick of printing out the board to regular paper, cutting it out, placing the components on top, adjusting and rinse and repeat until it's perfect.

Original board dimensions:

Board length: 47.000 mm

Board width: 47.000 mm

Board height: 25.000 mm

New board dimensions:

Board length: 97.000 mm

Board width: 47.000 mm

Board height: 25.000 mm

3D printed expansion component:

Cuboid length: 50.000 mm

Cuboid width: 48.000 mm

Cuboid height: 25.000 mm

One disadvantage of the HE plugs that they are using the very much disliked T - security screws and of course I didn't have them in any of my sets so what I did was just get a cheap not chromated throwaway screwdriver and cut a V in the middle of it with my diamond dremel head and voila security is now defeated, if you have bunch of regular T or X screws in the same size just throw the originals away don't put them back.

The top extension box is basically a 3 sided cuboid which is glued into the top of the HE plug around the bottom and side plates with strong 2 component glue.

Unfortunately at the time of writing I did not have access to a 3D printer so this small esthetic work will remain for later.

Circuit Design

20190901_142123.jpg
tiberium_v5_2025.jpg

As with other projects I advise against using Transformerless Power Supplies with all of your Arduino/ESP/Raspi projects. Here is a brief explanation of why:

https://hackaday.com/2017/04/04/the-shocking-truth-about-transformerless-power-supplies/

Originally I actually planned to hack the old plugs, leaving the TPS, the button, the relay and the LED in place and de-soldering everything else from the board but I'm glad that I changed my mind about it.

In the circuit I only had one small issue, that the ESP8266 and ESP32 are 3.3V boards, all the pins are also 3.3V rated and NOT 5 volt tolerant however the ACS712 current sensor is: "5.0 V, single supply operation" which means that you don't operate the sensor from 3.3V or not even 4.8V, you operate the thing from precisely 5V otherwise the voltage reference changes and the whole measurement will be incorrect. The solution therefore was to operate the whole circuit from 5V, take the 5V directly to the ACS and the ESP8266 (it has rectifier on board no worries), then put in a small voltage divider to the ACS712 DATA OUTPUT pin which will result a value not exceeding 3V and the AnalogRead mapping 0-1023 will be the similar as what you would get using a regular Arduino with the sensor (in the software section you will see the adjustments I have made including a small correction of reducing the AmpsRMS to get around the same value as my wallplug meter gives me (take it with a grain of salt tho, this is not some thousand dollar current measurement device just another cheapie from China so you can adjust the code for your needs, the hardware does not require modifications). Also stacking up on HLKPM-05 is a good investment since you can just use them in all your Arduino projects.

One common mistake a lot of ESP8266 and ESP32 tutorials about push buttons, leds and interfacing with Arduino modules commit is putting 5V directly to the GPIOs. Just don't! You can consider the 5V pin as the only pin in this circuit where you should be using 5V, it goes into the ESP8266 regulated to 3.3V and from that point use the 3.3V for everything.

The rest of the circuit is straightforward and does not require any explanation. I have doubled the copper both sides and at manufacturing set the thickness of the copper to 2oZ (per side) to be able to handle the max 10A and a 10A MAX rated fuse was also added (not to be cheapskates), I also like to have a spare soft glued safely somewhere in the box for immediate replacement. If an appliance faulty and shorting the mains out, that might break the fuse but will no way ruin the plug.

Just a note, as I managed to blow up some of these standard Arduino relays in the past: regardless that they are rated for 10A these can even withstand max current of 15-16A for shorter time periods, and the ACS 20A so the first thing which will go is the fuse.

The relay shield was meant to be put on top of the Wemos D1 mini, this is not just dangerous since there is a small airgap between the 230V mains and the metal shielding plate of the wifi but in-practical in my build so I have reversed the order and put the relay directly down to my PCB which is soldered into the PCB with DIP female sockets on top of it where the Wemos will slide into. At the relay shield, two out of the three original screw terminals are connected to the board from the 3rd (always connected) the flux was removed and cut out as it would just interfere with the trace going underneath it and we don't need it. On box of the extension board the screw terminal connectors with the high voltage part are hidden, only the USB has a breakout hole.


The whole board can be ordered assembled now as I switched to SMDs. The power supply, RGB led, switch and the extender pins for the Wemos are the only ones not added.


LED Colors

The LED colors show the state of the plug which can be the following:

1, Yellow blinking (not associated with the AP, lost connection to the AP)

2) Purple blinking (connected to wifi but can't get time data from the NTP server)

2, Red ON (plug turned on manually through the push button)

3, Blue ON (plug turned on remotely through https - computer control)

4, Green ON (plug is in time switched mode - time control)

The states can overwrite each other. For example the plug was turned on manually but there is a time ON event, the color will be Red first then it goes to Green to reflect the last state.

Software Design

20191022_143223.jpg

As this is my first ES8266 project I run into a multitude of issues, but overcoming them was a great experience. If you just want to build the plug you can download the Arduino sketch do minor configurations to fit your needs (wifi network settings, ssl certificate generation, user/pass for auth, nodename etc) then it is enough to read this section and take it as granted. If you are interested in the why read the next Software Issues section.

To provide an out-of-the-box software package I have packed my customized NTP library in a .ZIP, all you will need is the ESP8266 Arduino library what you can download with the board manager.

For IDE use: Arduino 1.8.9 or higher version

For build -as I mentioned it in the code- use:

Build settings:

-Use upload/serial: 115200

-Use CPU/ram: 160Mhz/4M flash

-Use SIPFFS: 1M /4M

-Use erase sketch + wifi

The base code is same as EOL, it's looping constantly and calculating the current/power consumption but with some extras. First of all the logic to determine the type of load was moved out of the code, it will just give back the date, uptime, relay state, current consumption, power consumption and average power consumption beyond turning the relay on or off.

For security I have finally decided to switch from the good old TELNET to HTTPS since the Wemos is more than equipped to handle SSL connections. Therefore the usual xcomm() function is only used to take commands from serial (when debugging). A basic http authentication is also implemented.

https://user:pass@ip/

will get you a nice user friendly page to turn the device ON or OFF and displays the stats however I mostly use these plugs for Machine 2 Machine communication (eg: one raspi checking the outside sun brightness by measuring the time to charge a small cap, once the threshold is reached (night) it contacts the plug directly to turn ON the lights. For this I have made a simple api:

https://user:pass@/m2m/

Where the command will be interpreted and the result is not some web 3.0 fancy but the usual one liner ending with \r\n.

%Node Name_ON/OFF%,%DATETIME%,%UPTIME%,%Current%,%Power%,%PowerAVG%

R1_ON,2019-05-14T08:26:32,0000-01-01T01:00:00,1,230,230
R1_OFF,2019-05-14T08:26:32,0000-01-01T01:00:00,0,0,0


This way the requesting machine can do everything from a basic shell script with basic tools like curl and awk.

OK let's move on to securing the plug. This will bring us to creating SSL certificate and setting an username and password for HTTP authentication.

I prefer using self signed certificate (and included the default example here just to make the code compile out of the box but you should change the certificate with your own).

BearSSL has it's limitation of 1024 bit max key length unfortunately so I could not use my own LAN CA which makes 2048 bit keys by default so I had to redo the procedure.

HOW TO GENERATE YOUR OWN CERTIFICATE/KEY PAIR

A sample script, "make-self-signed-cert.sh" is provided in the ESP8266WiFi/examples/WiFiHTTPSServer directory. This script can be modified (replace "your-name-here" with your Organization name). Note that this will be a *self-signed certificate* and will *NOT* be accepted by default by most modern browsers. They'll display something like, "This certificate is from an untrusted source," or "Your connection is not secure," or "Your connection is not private," and the user will have to manully allow the browser to continue by using the "Advanced/Add Exception" (FireFox) or "Advanced/Proceed" (Chrome) link.

I strongly recommend using 1024 bit certificate instead of 512 bit, there is virtually no page load speed gain using a weaker certificate (I talk about this in the next chapter) and you might run into issues with browsers such as:

The server certificate included a public key that was too weak. Error code: SSL_ERROR_WEAK_SERVER_CERT_KEY

There are some guides on the net detailing how to use LetsEncrypt (this only makes sense if you put the plug on the Internet on a public domain) but that might not be such a great idea, you can read more about it in the next section.

Led colors and plug states

The LED colors were described in the hardware section, here I would just make a small note that the plug not just stores down the cause of the latest ON state (manual,time,computer control) but the cause of the latest OFF state as well.

I realize it is a bit of over perfecting it but why not. The original V1 design when you plugged the plug in it read back the relay state which was a simple 0 or 1 and turned the relay on however the internal state was always COMP_ON afterwards.

For this I did a simple trick that instead of storing down 0 or 1, it stores decimals: 1, 2, 3 - ON states / 4, 5, 6 - OFF states.

I have changed all the references in the code.

At init (before even reading the DB) the relay state is 4 which is manual off.

After reading the DB if the state is lower equal to 3 then turn the plug on otherwise off.

The relay_off command does not know or care about states 4, 5, 6 since that is the result, not the cause. It expects either 1, 2, 3 which by the way will all have the same effect turning the relay off it is just for the STATUS variable update so when it is called from the DB readback function it will substract -3 from the value resulting the original 1, 2, 3.

NTP Code & the uptime & the timer

What is NTP and how does it work is explained here: https://lastminuteengineers.com/esp8266-ntp-serve...

In a nutshell from the computers point of view it is just an unsigned long which gets compared with the UNIX epoch (January 1, 1970). The computer keep increasing it in every loop and once in a while it connects to an NTP server to sync the value from there. As we don't want to hammer the NTP server in every 5 minutes with requests the code gets the time from the NTP once a day.

I have rewritten the NTPClient of https://github.com/arduino-libraries/NTPClient

and was planning on removing evil strings because of https://hackingmajenkoblog.wordpress.com/2016/02/...

but I give up on that since the webserver code deeply uses strings in all of it's sublibs, it would be pointless and I don't know if they have the same effects on the ESP8266s memory since it's way more powerful than an Arduino. The original idea was to have a completely String free code but this never happened.

Additional super important function (uptime) was added into the NTP library which is basically starts after the first successfully NTP sync when the current time is determined, the system will set the start date variable as epoch and will be comparing to that.

The UNIX epoch goes from 1970/01/01 for a reason, if it would be going from 0000/01/01 then an UL (Unsigned long) would not be enough to store it. Matter of fact there is a problem with the systems using 32bit INTs to store the NTP long value, it will overflow soon (in 2038 soon enough :P).

  1. Unsigned Long Max: 4294967295
  2. Signed INT MAX: 2147483647
  3. Seconds ~ 1970->2019 1545264000
  4. Seconds ~ 0000->2019 63671184000
  5. Seconds in a year: 31536000

So I did the same clever trick as I did in my Coffee Maker project the uptime is calculated by the getFormattedDate() function will subsract - 1970 from the years.

Time switch functionality

10 timer entries can be defined through commands.

The plug can be programmed from serial (DEBUG MODE) with:

TIMER,1,ON,20,30

TIMER,2,OFF,22,30

TIMER_CLEAR - clears all timing

TIMER_QUERY - queries all entries

The time values will be stored down in a db file on the SPIFFS. This DB file will be read and verified at every boot (the file must contain exactly 10 lines, otherwise the code assumes it to be corrupted and will recreate it with empty entries). If the verification succeeds then as the next step the code will load the values into global variables not to hammer the filesystem anymore.

The format of the DB file is simple:

1,20,30

Where the first column is the event type ( 0 - timer entry disabled, 1 - ON, 2 - OFF). The line number directly corresponds to the variable number (line1 -> t1, line2 -> t2 ...).

To keep things simple since the plug will rarely be programmed, in case of ANY time set commands, the time will be set in the corresponding global variable (t1-t10) first then the whole time DB will be written to the flash, this way all kind of dupes, corruptions, order, record processing etc. can be avoided.

At the start of each void loop() the code will quickly go through only the time entries which are enabled and uses the ntp gethour and get minute functions to get the values and compare it with the global integers to turn things on or off.

The standard way is to set the timers is through the web frontend. For this I have developed a second request processor called handleTimer(), the way of handling GET/POST requests from the forms is quite different from the usual PHP but I made sure to implement proper input validation. This server only accepts exactly 4 arguments and all 4 will be converted into unsigned integers and validated. In case of any errors the code will not proceed with setting the time.

After a time set request was successful, the global variable for that specific time entry will be immediately updated (timer goes active) and then the timer db will be recreated and written out to the flash.

I would note that without modifying the code it is not possible to use this plug even just as a timer without network connection (it would defeat any purpose at the first place) because it MUST get it's time value from the NTP server.

Same goes for the Wifi, if it can't connect to an AP at start, it will still restore the last relay state first (ON/OFF) but then the execution will hang forever until it can connect.

At an earlier version the timer was a BUILD feature, however I spent quite a lot of time on the timer code :P so I have decided to rather make it dynamic. You can turn the whole timer functionality ON/OFF from the webpage any time. The reason why I did this because the timer table generation increases the page load speed and you might don't want that functionality anyway. Turning OFF the timer will leave the DB entries intact. You can also chose to CLEAR the whole time DB with 1 button in which case all entries will be zeroed and the timer will become disabled. By default the timer is disabled.


CODE IS MOVED TO GITLAB: https://gitlab.com/instructables/tiberium1/

Conclusion and ToDo List

20191020_164820.jpg

V5: As I summarized the code only had small changes however the boards failed over the years so they got redesigned.

The last major todo is to to develop a working Android app.


Is the plug ECO friendly compared to the commercial alternatives? I would say it's pretty good in power consumption compared to just how much more it can do. Although I did not have precise meters to measure the consumption other than my cheapo wallplug meter, an Intertecho in idle consumed so low the meter could not measure it, a Home Easy HE877 consumed 0.5W standby (both on or off states), my plug consumes 0.5W standby and 1W relay on and I would say that is a great number which just shows how inefficient those cheap Transformerless Power Supplies are.

Could be said that this project is over complicating the original design. You have a device, push the button and it will turn a device ON or OFF but what's under the hood is a lot more. If you building systems where the highest reliability is expected then the best is to use a centralized relay board to control everything, unfortunately more often than not we don't own the building where we live and rewiring it is not an option so if you need reliability and security this project might be a good trade-off for remote control.