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.