Most gerbils are aware that Silverstone makes high-end PC enclosures, most of them with elegant styling and aluminum construction. The company’s cases don’t get as full-boat weird as competitor Lian Li’s, but someone in upper management clearly lets the engineers go a little crazy with some of the accessories in the product catalog. One of the somewhat off-the-wall categories Silverstone gets into is its three-model line of PC remote controls. The original models, the SST-ES01-PCI and SST-ES01-PCIe, were released in 2016. These cards plugged into PCI or PCIe slots and toggled the power and reset buttons of the host PC with an RF remote control from up to 66 feet (20 meters) away. A second model, the ES02-USB, was released this year. The new model performs the same functions as the old one, but it’s powered by a USB header.
All three of these devices work according to simple principles. The power and reset buttons on a PC are connected to switches that close an open circuit when pressed. Every gerbil that has built a PC has had to squint at microscopic screen-printing on a motherboard while fussing with those fiddly little cables and their usually-non-standard layouts. Silverstone’s PC remotes work by closing the same circuit via electronically-actuated switches. The most impatient gerbils have probably rubbed screwdriver tips or other metal objects against pairs of pins in a front panel header block while testing a motherboard to do pretty much the same thing. Silverstone’s machines listen for an RF signal and short wires together to simulate a button press.
Let’s detour for a moment and talk about three scenarios where a remote starter like this might be useful. My wife and I spent a couple days in the hospital waiting on a new addition to our family recently. Little Baby Manion isn’t too mobile right now, but eventually, bouncing baby Brooke will be crawling around and poking things to see what happens. A PC with a remote power switch could have the front panel buttons disconnected entirely for immunity from small children’s investigative fingers. Cat owners might use the remote for a similar reason.
Remote desktop, SSH, and FTP are wonderful tools for accessing computer resources when you are not seated in front of the machine with the desired resources. Accessing those goodies becomes more difficult if the machine crashes or a power outage causes an unplanned shutdown. A wireless remote-operated power button could allow a frustrated user to power-cycle the machine and regain access to the resources.
A device like this can let me be lazy, too. My family room shares a wall with my garage, so I store my HTPC out there. I added HDMI and USB keystone jacks to wall plates on either side of the wall that separates the garage from the family room so that I don’t have to listen to or look at the HTPC. The system works well, but every once in a while I have to run out to the garage and grab a step stool so that I can tap the power button when the machine won’t wake from sleep. Users with more remote HTPC placement might have bigger hoops to jump through.
My first impression after reading about Silverstone’s devices for the first time was that the remote controls were a wonderful idea, but they got me thinking about ways to improve them with my hacker “skills.” First, the remote switch would be more useful if it didn’t require a dedicated remote control. Most people have a smartphone with them these days, and it’s not as likely to get lost as a tiny, single-purpose fob. Second, the devices don’t appear to be able to press and hold the power button, as is sometimes required in the event of a system crash. Perhaps a gerbil with some first-hand experience with Silverstone’s devices can chime in on this matter. In any case, I thought I could do better with a custom-built remote starter, so I set out to see whether I could translate my proposed improvements into an actual device.
Drawing up some plans
First off, I don’t profess to be an electronics expert. The closest I got to electrical engineering was playing with resistors in second-semester physics lab in college. In my testing, these circuits were functional and no magic smoke was released. I am also not an expert in network security. I am simply applying the little bit that I do know about the matter to make something reasonably safe. Gerbils who chose to follow these instructions do so at their own peril. Anyone following these directions should probe all wires with a digital multimeter (DMM) before connecting anything. All pinouts and voltages are based on the ATX12V v2.4 standard. If you encounter a voltage other than +5V or ground, stop immediately. It should go without saying, but unplug the PC before connecting any wires, too.
At least one gerbil has read this far and has already put paws to keyboard to say something about how programming a microcontroller is too complicated and that using a Belkin Wemo or other Wi-Fi enabled power switch to remotely power off a computer would be easier. I have a couple Wemo switches in my house, and they work well. Unfortunately, they don’t require any authentication when accessed on a local network. Anyone with a Linux box and access to my network could signal a Wemo unit to switch on or off. Worse yet, if a device with Amazon’s Alexa is on the same network, it can control a Wemo switch with nothing more than a voice command. In addition, the power buttons on the front of the computer would be rendered useless by a Wi-Fi switch. Overall, I don’t think this approach accomplishes the goals set out for this project, and the complete lack of any authentication bolsters my decision to go in a different direction.
A Raspberry Pi Zero W has the GPIO pins to be able to accomplish the design goals, and the $10 price wouldn’t break the bank. The Pi Zero W has the ability to send and receive TLS-encrypted communications. I saw two problems with this approach. First, the Pi Zero W supplies are still a bit thin on the ground. More importantly, Raspberry Pi boards have been very finicky when it comes to power outages in my experience. The device does no good if a brownout has caused the Pi to become unresponsive. After all, the device has to be more fault-tolerant than the system it monitors and controls. The popular Raspberry Pi 3 has even more connectivity and can be configured to run from a more robust storage medium, but the $35 price and the Pi 3’s peak current draw of 2.4A are both too high for this application.
The NodeMCU development board
I have some experience using Espressif’s ESP8266 microcontroller. The ESP8266 is a tiny chip with built-in Wi-Fi capability. ESP8266 development boards are available on eBay and Amazon for as little as $2 shipped, but those boards are missing some convenient extras. Just a couple extra dollars nets a NodeMCU development board with its extra digital and analog general-purpose input-output (GPIO) pins, a couple of on-board buttons, a voltage regulator for converting +5V to the ESP8266’s native +3.3V, and a built-in USB-to-serial chip that makes programming and powering the device much more convenient.
The ESP8266 doesn’t have the processing punch or the software libraries needed to be able to act as the server in TLS-encrypted transmissions, but it does have the ability to operate as a very basic HTTP server, an MQTT client, and a WPA2-encrypted Wi-Fi access point.
When the device is in AP mode, the user can attach to the non-internet-connected AP broadcast by the ESP8266 and navigate to 192.168.4.1 in any web browser. The web interface presents buttons to press the power switch for a moment (0.2 seconds), five seconds, or 30 seconds. The user can also configure the Wi-Fi and MQTT settings through the same web interface. Since commands are transmitted over an isolated, encrypted Wi-Fi network protected by a unique password, we can assume that even “unencrypted” HTTP communications are not subject to easy snooping.
If MQTT options are given, the device will listen for commands from an MQTT broker, allowing somewhat more secure control over the power switch while remaining connected to the primary Wi-Fi network. Use of MQTT is inherently less secure, but I think the risk can be minimized by using an access control list in the MQTT broker software. Essentially, the device subscribes to one MQTT topic for commands and publishes status messages on a second topic. The subscription topic can be set up with permissive subscription access but restrictive publication settings. I set up my own broker so that only one MQTT user has publication and subscription access to the topic going to the remote start device. A second, less privileged user has subscribe-only access to that same topic. Another topic used for messages from the device to the broker has permissive access control in both directions, because I don’t care if anyone on my network is snooping on those messages. Our MQTT messages are sent as plain text, so I make sure to only publish to the restricted topic from the MQTT server itself. That way, the publication password is not broadcast.
Control over a remote power switch wouldn’t give a rogue agent a user’s private information or bank account number, but teenage offspring turning off your PC in the middle of a Netflix binge session could certainly be annoying. The ESP8266 uses WPA2 with TKIP and AES, and TKIP cannot be disabled. For maximum safety, users should not have clients connected to the access point unless the device is actively in use. Local attackers can potentially gain access to TKIP-enabled WPA2 networks by forcing a connected client to disconnect and analyzing the resulting connection handshake when the client reconnects. The device is not 100% secure, but I suspect that Silverstone’s device is perhaps more susceptible to local attackers with a bit of RF hacking ability. If your Wi-Fi network has been owned, you have bigger problems on your hands than someone turning your computer off.
The required resistors and optocouplers
To make the contraption more electrically robust, the remote starter design uses integrated circuits called optocouplers to isolate the NodeMCU side from the PC side of the monitoring and control circuits. Optoisolators work by separating two circuits from each other with an insulating gap between them. One side powers a special LED, and the other side contains a transistor that activates in response to illumination from that LED. The LED and the transistor are both packed inside of a small plastic housing. The optocoupler protects the device on the control side of the circuit from happenings on the transistor side. In this case, the optocoupler is going to act like a tiny low-power relay.
I picked up a pack of ten Sharp PC817 optocouplers on Amazon for under $6 with Prime shipping. A more patient gerbil could get ten pieces for under a dollar direct from China, and those in bigger cities could probably pop into an electronics supply house and walk out with a handful of them. The completed device will require two optocouplers. One is for the the power button circuit and the second one is for a circuit that allows the NodeMCU to tell if the attached PC is powered on or not.
Each optocoupler needs a a 220Ω resistor to knock down the voltage on the LED side of the device down to about 1.2V, the operating voltage of the LED inside the optocoupler. I used two resistors from a giant assortment of resistors I bought on eBay for less than $10. Connections can be made using with pieces of solid-core 22 AWG wire cut to length.
A little piece of stripboard is also required. The resistors, wires, and perfboard can be sourced just about anywhere that sells hobbyist electronics parts, including ebay, Amazon, or Radio Shack. Those with lots of circuit prototyping experience can use any type of proto board they like. I like strip board because it frees me from having to make solder bridges.
Anyone at home planning to build one of these devices will have to make their own decisions as to how to wire things up. The device really only needs four wiring connections: constant +5V power, switched +5V power, ground, and the positive wire of the power button front panel connector. I decided to use three separate ground connections for the device power, power sensing, and power button circuits, but this is not necessary.
ATX pinout diagram by Collab, update by Sbmeirow, source: Wikimedia Commons
In my experience, the trickiest one to find is a constant +5V source. Most enthusiast systems will have constant +5V on pin nine of the ATX power connector. This wire is typically purple, but owners of high-fashion power supplies with all-black cabling will need to count wires and refer to ATX pin diagrams. If in doubt, probe carefully with a DMM. Many motherboards also offer constant +5V through one or more of the USB headers. Pins one and two of USB 2.0 headers are +5V and are usually red. If your PC will charge a smartphone even when it is turned off, tapping into USB header wires is an option. The motherboard in my HTPC does not provide power to USB devices when it is shut off, so I had to go to the ATX connector wiring for power. I have a Lenovo SFF machine with an external power brick that had no constant +5V wiring inside the case at all. In a machine like this, power from an external source is probably the only available option. The PCI and PCIe connectors have +5V pins, but that is territory probably best left unexplored.
The power button wiring can really only be tapped in one location, but this location is almost always very easy to find and identify. One could easily tap into the power button wiring. I decided instead to make a T-harness that connects to the motherboard front panel connector, the existing power button wiring, and to the wiring from my NodeMCU project board. It was easy to make using DuPont wires and empty connector shells from eBay. It required only a couple of solder joints and some heat shrink tubing to make. When the positive power button wire is connected to ground, the PC will power up or down, so do not leave it loose inside the case.
Custom T-harness for power button circuit connections
Switched +5V power, on the other hand, is ubiquitous inside a PC case. The ATX connector has several switched +5V wires, which are usually orange. Four-pin Molex and SATA power connectors also have +5V switched wires, which are normally red. Those looking not to void their power supply warranty could tap into a cheap power splitter or Molex-to-SATA power adapter cable. Ground connections can be found in just about every PC connector. Ground wires are usually black, but some power supplies use black wires for everything. Tapping an extension cables for the 24-pin ATX connector is another option for those looking not to void their power supply’s warranty.
I made all of my connections with solder, but other options are available. Thicker wires, like those in the ATX connector, can be tapped with 3M red t-tap (3MRTT) connectors. The tap connects to a male spade terminal, and these can usually be disconnected at least a couple of times. Thinner wires don’t work reliably with t-taps; these thin wires can be tapped using UR IDC connectors. UR IDC connectors provide a great connection with corrosion protection and strain relief, but you do have to cut the tapped wire to use them. Regular pliers can crimp UR IDC connectors in a pinch, but UR crimping pliers make it much easier. Soldering requires no additional materials and provides reliable connections, but has little strain resistance. Pick your poison.
Giving it a brain
After the necessary wires inside the PC have been identified and tapped, the next step is to program the NodeMCU. The first step in this process is to install the Arduino IDE from Arduino.cc. The IDE is available for Windows, Mac OS X 10.7 or newer, and Linux. I don’t have a Mac, and I have only used the IDE on Windows, so alternative OS users following along at home will have to do some of their own research. I’m sure only minor deviations from the instructions are all that would be necessary. Because we are not using genuine Arduino hardware, the wonderful people at Arduino don’t see a dime. Consider donating money so its developers can continue their fine work.
Out of the box, the Arduino IDE really only supports Arduino boards and their clones. The developers are such upstanding people that they blessed the IDE with the ability to support third-party boards like the ESP8266-based NodeMCU used in this project. Adding the third-party board support is easy, but not exactly intuitive. Adafruit has a wonderful tutorial, but it is written for Adafruit’s Huzzah dev board, which doesn’t have a USB port. Setting up for the NodeMCU is even easier because we don’t need to fidget with pins or buy a separate USB-to-serial device to get things working.
To add the board support needed for this project, start the Arduino IDE, then click File, Preferences. A window with many options will pop up. Enter “http://arduino.esp8266.com/stable/package_esp8266com_index.json” in the field labeled “Additional Boards Manager URLs:” and click OK. Next, click Tools, Board, and select Boards Manager. Type “8266” in the field labeled “Filter your search”. Only one option should appear, so click Install. This might take a minute depending on the state of your computer and your Internet connection. When that is done, click Tools, Board, and select “NodeMCU 1.0 (ESP-12E Module)”. The IDE is now ready to program our mighty mite NodeMCU dev board.
The USB-to-serial chip on the NodeMCU requires a driver. Every NodeMCU I have used has a CH340 chip, but given the grab-bag nature of the boards, some units may have FTDI 232 or other USB-to-serial chips. The CH340’s Windows driver is available from the Chinese manufacturer’s web site, here. Installation is very simple and takes only a second, though the installer will not really give any indication that it has completed its work.
Now that the Arduino IDE is ready and the serial driver is installed, plug the NodeMCU into the PC using a microUSB cable. Windows might take a moment to recognize the new hardware. When Windows stops thrashing and gnashing its teeth, go back into the Arduino IDE.
Flashing the final code onto the NodeMCU and connecting it to the system would be fool-hardy. Testing the board is quite simple, and the board support downloaded in earlier steps includes some code that can help test the integrity of the NodeMCU. Select File, Examples, ESP8266, Blink. The IDE will probably pop open a new window with some simple code. This short program is the “Hello World” of displayless microcontrollers. For now, try not to get bogged down in what the code does—the goal is to make sure the IDE and the NodeMCU work together. Select Tools, Port, and the correct COM port for the NodeMCU. Typically, COM1 is not the NodeMCU. Note that the COM port number will probably change if a different USB port is used.
With the first test code loaded and the correct COM port selected, select Sketch, Upload, or press Ctrl-U. The program should compile, then the IDE should upload the compiled code to the NodeMCU. The blue LED on the NodeMCU will flash rapidly while it receives code from the PC. The compile time and upload speed will vary by computer, but I expect it’ll always take longer than one would expect from such simple code. If everything worked, the blue light on the NodeMCU should blink slowly, turning on for one second, then turning off for one second. If you are anything like me, you will probably now waste an hour changing the numbers in the code to make the device blink faster and slower.
If compilation fails, check to make sure the correct board is selected in Tools, Board and reload the example code to make sure it wasn’t modified in some way. If the upload fails, try selecting a different COM port from the options in the Tools, Port menu. The third (less likely) scenario is that the PC does not provide enough power for the NodeMCU over the USB port. Try a different port (don’t forget to change the COM port in Tools, Port) or try a different PC.
Assuming the IDE and driver software are set up and working properly, the next step is to download the testing and final source code from TR. I’ve provided Arduino sketches to test the power sensing and control circuits on the device, so you can make sure that the project board is put together properly before flashing the final code and installing the contraption in a PC.
Putting it all together
The next step is to connect the NodeMCU to the little electronics parts described earlier. The circuit designs are simple. A decent soldering iron will be very helpful. A $15 Radio Shack number with a fine tip will probably get the job done, but a decent soldering station will work much better. I used a Weller WES51. Some 0.5-mm solder and some 22 AWG solid core wiring is pretty much required. We are going to connect our NodeMCU and the other parts to the stripboard. Put the parts on the plain plastic side of the stripboard so the legs stick out the side with the copper tracks. When placing the resistors and optocouplers, bend the legs out a little bit so that the parts don’t fall out of turning the stripboard over for soldering.
Stripboard is great because the pins of the board going left to right (or up to down depending on perspective) are connected by copper strips embedded in the surface of the plastic board. The user doesn’t need to make any solder bridges because that work has already been done. The tracks can be broken by twisting a 9/64″ or 5/32″ drill bit by hand in one of the holes to strip away the embedded copper. The tracks below the NodeMCU, the resistors, and the optocouplers will eventually need to be broken this way. Be sure to break the tracks below the NodeMCU because the pins on the left side have different functions from the pins on the right. The NodeMCU will not be able to boot and could be damaged if these connections are not broken.
Start by positioning the NodeMCU on the stripboard and pushing the legs through the holes. It should probably be biased close to the left side of the stripboard because all the external components are connected to the right side of the NodeMCU board. Connect one of the NodeMCU’s +3.3V pins to a 220Ω resistor. Resistors are not polar, so the direction of the resistor does not matter. Connect the other side of the resistor to pin one of the PC817 optocoupler. The PC817 package has a little circle embossed to mark pin one. Pin two is right next to pin one. Connect pin two to the D1 pin on the NodeMCU using a little piece of wire cut to length. The NodeMCU will maintain a high signal on this pin unless a power button press is requested, then the pin will go low (to ground) and the optocoupler will trigger. Connect a couple of wires to pins three and four of the optocoupler package and terminate them in the manner required by the planned method of connection to the PC’s power button wiring. I used a right-angle header connector to allow easy removal and reinstallation of the device.
Connect pin three of the optocoupler to one of the NodeMCU’s ground pins and pin four to the D2 pin on the NodeMCU. When the power sensing optocoupler received +5V from the PC, its internal transistor will complete a circuit between pin D2 and ground, informing the NodeMCU that the attached PC is on. Connect the second 220Ω resistor to pin one of the sensing optocoupler. Connect wires of appropriate length to the other side of the resistor and to pin two of the sensing optocoupler. The wire on pin two will connect to the PC’s ground wiring and the other wire will connect to one of the PC’s switched +5V wires.
Once all the components are positioned, solder them to the board. Make sure to file away the stripboard tracks below the NodeMCU, the resistors, and the optocouplers. If the tracks are not clipped, problems up to and including the release of magic smoke and damage to the components are practically guaranteed. Trim off the legs of the NodeMCU and the resistors as desired. The optocoupler’s legs are shorter and probably don’t need to be clipped.
Strain relief on all wires going from the NodeMCU to the PC is highly recommended. As I mentioned before, I used a right angle male header pin connector so I can detach and reattach the wiring going to the PC. Strain relief is an extra benefit. If the wires are pulled too hard, the connector will come loose without permanent damage.
The first test is to make sure the NodeMCU is still working after soldering. Connect the device to a running PC using a microUSB cable. The blink sketch should run and the LED should flash on and off, alternating each second. If the NodeMCU is not working, the most likely scenario is that one of the copper tracks below one of the components has not been broken or excess solder has linked to adjacent tracks together. Double-check these and plug the device back in. Proceed to the next step only after the blink sketch is working.
Now test the circuits on the assembled device. Go ahead and open “testButtonControl.ino” in the Arduino IDE and flash it to the NodeMCU using the same steps used to flash the blink sketch. Connect a digital multimeter set to measure resistance to the outputs of the power button control optocoupler (pins three and four). The multimeter should alternate every five seconds between infinite resistance (no connection) and a measurement of less than 10Ω. Some resistance is part of the bargain with the optocouplers, but in my experience, anything less than about 25Ω will work. The onboard LED should blink on and off in time with these changes in resistance. If the resistance does not switch back and forth, check the serial output of the device in the Arduino IDE. If the LED doesn’t blink, try flashing the sketch onto the NodeMCU again. If the LED does not flash, carefully inspect all connections. Take extra care that things that should not be connected are indeed not connected.
Once the “testButtonControl” sketch is working as it should, flash the “testSense.ino” sketch onto the NodeMCU using the Arduino IDE. The new sketch will illuminate the onboard LED when 5VDC is connected to the input pins of the optocoupler in the power-sensing circuit. You will need a +5V source for this test; the PC switched +5V and ground wires described in the previous section should work for this purpose. The optocoupler’s input is polar, so if the LED doesn’t blink, double-check the polarity of the input. If the blink, “testButtonControl.ino”, and “testSense.ino” sketches all work, it is time to flash the final sketch onto the NodeMCU.
The main sketch relies on some external software libraries to work. Luckily all of the required libraries can be installed from within the Arduino IDE. Open the Sketch menu, select Include Library, then Manage Libraries. A new window will pop up in the foreground. Click in the search box and enter “ArduinoJSON”. A library by that name should appear at the top of the results. Select the newest version and click install. Next, enter “PubSubClient” in the search box and install the newest version of the library. The rest of the needed libraries are included in the main ESP8266 Arduino Core library.
The main sketch is called “PCRemote.ino”, but its code is spread across multiple Arduino sketch files. Opening any of them should open several tabs in the Arduino IDE. No changes from previous settings should be needed, but the whole thing is open source. The current version provides the ability to change the Wi-Fi credentials as needed and the ability to flash new firmware over the air when the device is in AP mode. Open the Serial Monitor window by clicking the magnifying glass icon near the top-left corner of the main IDE window. Disconnect everything except the USB cable and flash the “PCRemote.ino” sketch. The sketch should compile and flash. When flashing is complete, some activity should occur in the Serial Monitor window as the newly flashed sketch boots up. Text about the device should appear, followed by a pause of up to 30 seconds as the firmware initializes the probably-blank file system on the SPIFFS portion of the NodeMCU’s flash chip.
When the file system is initialized, the device boots in a “factory defaults” mode. The NodeMCU starts its own Wi-Fi access point with a name based on its MAC hardware ID. Mine is called ESP-E80BD2, but every chip will have a unique name that starts with “ESP-“. The default AP has no password, so use another device to connect to the AP. If your smartphone or tablet has a “Smart Wi-Fi” feature, you will need to disable it, as the feature detests Wi-Fi APs without internet access. Windows PCs seem to take longer than expected to connect to a non-internet-connected AP, but should eventually connect. The Serial Monitor output should contain the device’s IP address, which should be 192.168.4.1.
Navigate to this address and the device will demand a new name for the AP and a password of at least eight characters. The device will accept the existing hostname, but the password length is not negotiable. The AP name and password may contain up to 64 characters, but compatibility with other devices probably drops off after 32 characters. I recommend a strong password, but the device itself will accept anything you offer.
When you’ve finished setting up the device as you like, click “Submit AP configuration”. The device will save the settings to its internal flash memory and reboot. The first soft reboot after flashing always causes ESP8266 devices to hang, so you will have to unplug and replug the NodeMCU to get it going again. You will also have to close the Serial Monitor and re-open it to be able to see any additional serial communication. After this reboot, the device will start an AP with the name and password specified in the previous step. The device can be left in this state permanently. To access the device’s actual abilities, you’ll need to do navigate to its web UI, select Change Device Mode, then connect to the AP, visit 192.168.4.1 in a browser tab, and select the length of time to press the power button.
If you don’t want to broadcast an extra SSID all the time, proceed to the next step: setting up Wi-Fi station mode credentials and optional MQTT settings. MQTT will not work unless the device is in station mode, so enter the station mode configuration first. The station SSID is the name of your primary router, the current AP password is the one you set up just a few moments ago, and the station password is your main router’s password. Once you have entered this information, click “Submit station configuration.”
The next big option is whether or not to use the MQTT settings. As mentioned before, MQTT makes the device slightly less secure, as it will accept MQTT commands from a broker to press the power button while it is connected to your main Wi-Fi network. It will not accept power button commands over the web interface while connected to a Wi-Fi network as a client. If you can’t or won’t use MQTT, the remote starter device will sit on your Wi-Fi network by default. The “Change device mode” page will present the option to put the NodeMCU into AP mode. When this mode is selected, the device will reboot into AP mode, where you can connect to the AP using the device password and access all of the power button and configuration options. I wish it was simpler, but the difficulty of using SSL/TLS on a NodeMCU web server makes these extra steps necessary.
You will need an MQTT broker to use the device’s MQTT functions. The open-source Mosquitto MQTT client seems to work well, and it runs on pretty much anything, including Windows and Linux on most architectures. I would recommend that the MQTT broker runs on a computer with high availability and and that you not run the broker on the PC whose power you are attempting to control. I have a pair of always-on Linux machines in the basement, so each one runs Mosquitto and controls a NodeMCU device attached to the other machine, in a sort of Cold War mutually-assured-destruction kind of arrangement. I highly recommend the use of passwords and an MQTT access control list before rolling out one of these devices. Steve Cope has written a page with a simple introduction to setting up passwords and an ACL in Mosquitto.
If you decide to use MQTT with this PC remote starter contraption, you will need to enter the MQTT configuration details. Most of this work is largely self-explanatory, but the “MQTT Timeout” and “Reboot on MQTT fail” options probably require some clarification. The MQTT timeout is the number of consecutive failed MQTT connection attempts that are allowed before the device takes action; zero means infinite reconnects are allowed. I suggest using some value other than zero here, as failed MQTT reconnect attempts can make the web interface a bit laggy. If the “Reboot on MQTT fail” option is not selected, the device will simply stop trying to connect to the MQTT broker when this threshold is reached. If the same option is checked, it will reboot into a temporary AP mode when the number of consecutive failed attempts exceeds the MQTT timeout value. The device pauses five seconds between connection attempts, so a timeout value of 180 means about 15 minutes of repeated failed connection attempts before a reboot. In any case, if you enter MQTT configuration information, the device will not work very well if the MQTT broker is unavailable.
As for that temporary AP mode, two conditions will push the device into this mode. The first is the just-mentioned combination of the MQTT timeout and “Reboot on MQTT fail” options. The second condition is a failure to connect to the specified Wi-Fi network. If either of these conditions are encountered, the device boots into AP mode for one hour, then attempts to reconnect to the primary Wi-Fi network. If the device connects to the Wi-Fi network, the MQTT timeout counter starts from zero. The graceful handling of Wi-Fi network and MQTT broker failures took more time than anything else in this project, and I still don’t feel great about this solution. I welcome comments or emails about this topic. I tried to copy the way that other devices like the Google Chromecast, which also lacks a display or input devices, handle these types of failures.
Home sweet home
With this work done, we have nothing left to do save for mounting the device. Make sure not to allow the back side of the project board rest against any conductive surface. I drilled holes in my PC chassis and used nuts, bolts, and plastic washers to elevate the circuit board about 1/4″ above the metal chassis. A board made from 1/8″ hardboard or plastic could also protect the back of the circuit board. Self-adhesive Velcro can then be used to mount the plastic or hardboard backer board onto some part of the computer enclosure.
Connect the wires from the NodeMCU to the appropriate wires on the PC and test it out. I suggest disconnecting power from any bootable drives during this testing. When you’re satisfied that everything works, reconnect the boot drive and start up the PC. In most cases, a simulated tap of the power button should put the computer to sleep, and a long press should turn it off. Windows offers a wealth of options regarding how it will respond to such a press. If something doesn’t work, check the connections to the PC. T-taps and male spade quick connects can take a little practice to get perfect. In particular, the crimping process often bends the male spade within the connector.
The bill of materials for this project was much less than the $25 Silverstone asks for its prebuilt solution. While the vast majority of users will prefer the company’s plug-and-play approach, I’m happy I can control my device without carrying around any extra hardware. The project is simple enough to assemble in about an hour, and the programming is already done.
I had to perform a lot of trial and error in the process of developing this device, but the kinks are ironed out at this point. The original design featured a circuit to activate the PC’s reset button. The optocoupler could not create a low enough resistance value to trigger one of my test systems to reboot. Another one of my test systems did not have a reset button at all. I left the reset circuit out of the final design because these applicability and reliability concerns outweighed the rather limited utility of a remote reset button. A shut down and power up is always better than a reset anyway.
The most likely evolution of this device is one based on the ESP8266’s successor, the ESP32. The ESP32 replaces the ESP8266’s single-core, 80 MHz processor with a dual-core unit running at 180 MHz or 240 MHz. The amount of memory on tap rises from 160 KB to a mighty 520 KB. This added grunt should allow the ESP32 to bypass all the cloak-and-dagger stuff needed to make this project work. As great as this sounds, the software infrastructure for the ESP32 just isn’t there yet. Development boards have become available at competitive prices just in the last month or so.
I hope at least some of you are willing to take the plunge and try to build one of these devices yourself. You could have some fun, learn a little bit about hobbyist electronics and microcontrollers, and build something at least a little bit useful. I should add that the design of this device could be readily adapted to control the power of pretty much any device that uses momentary switches, such as a garage door opener. If you come up with a novel use for this project beyond controlling your PC remotely, be sure to share.