Goose66

Nevermind, just had to delete it and reinstall it. 

Initial question: Are you using the "Discover Devices" button in the MyQ Service node?

Here are the current instructions and my settings:

As you can see in the instructions, the "Custom Configuration Parameters" refers to the "Custom Configuration Parameters" section of the configuration page just below the instructions. Each Custom Configuration Parameter has a "Key" and a "Value." You need the two Custom Configuration Parameters shown: one with key "hostname" and a value of your IP address, and another with the key "token" and a value of the token string from your Bond bridge.
I know sometimes it's so clear  in our heads that it doesn't translate to others. If you can suggest better verbiage, I will consider upgrading the instructions.

The node server can only have one sub-level. I keep all my node server service nodes in one "Node Server" folder, and the garage door openers in a "Perimeter" folder. Alternatively, you can just move them all under a "Garage Door" or "MyQ" folder.

You say you tried it in Chrome, do you mean you typed it into address bar and it worked? If so, then change your HTTP command here to GET.

Turns out you would need to make the Bridge discoverable again to discover new devices added to the bridge if the Bridge was originally discovered by the automatic discovery (i.e., not specifically identified by hostname in the "hostname" Custom Configuration Parameter). I consider this a bug (or an oversight) however, and I have marked it for change in the next version.
The Zeroconf module allows the node server to broadcast a query to the devices on your network and then listens for responses from compatible devices (in this case Bond bridges and SBB devices). It is the same mechanism as Bonjour that Apple uses to discover Apple devices (printers, phones, macs, etc.) across your network. The error you are getting suggests that some other process on your Polisy (and, specifically another user) has the Zeroconf socket connection open and listening for responses. Since I am unaware of any such native process on the Polisy, I am assuming it's another node server. One of the changes implemented in PG3x is that node servers each now run under their own user ID. So if another node server is utilizing Zeroconf (and holding it open), other node servers will fail to initialize Zeroconf since they are now running under different user IDs. 
I have noted this bug and will have to do further analysis to figure out a fix. In the meantime, a workaround for you should be putting the hostname and token values for your current bridge in the "hostname" and "token" Custom Configuration Parameters for the node server (see the instructions under the "Configuration" tab in the PG3 Dashboard). This should cause the node server to skip the automatic discovery of new bridges through Zeroconf and just look for new devices on the bridge(s) you specify in the Custom Configuration Parameters. Note that, based on the "bug" discussed in the first paragraph of this post, if you don't specify the "token" configuration parameter value for your bridge, then the bridge will have to be discoverable (power cycled) for this to work properly.
Let me know if you need any additional help with this, and hopefully I can get these bugs fixed and get a new version out soon.

It was my understanding that turning ON a Program setup in the Alexa integration runs the "Then" branch and turning OFF the Program runs the "Else" branch (see, e.g., https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3#Programs). The "trigger" (really a condition) is not considered.
But if that's not the case, then try a condition that is always true, e.g. "If From 0:00:00 to 23:59:59" and then disable the program so that the ISY won't trigger the program on the condition's boundaries. Alexa should be able to Turn that ON (run the Then branch). 

@drprm1 Received the DM with the log files. Good to know you found the "All Off" command and disabled it. That one really doesn't make much sense in the current ISY ecosystem because so many different types of devices are integrated in the controller. 
Looks like after the initial problem at 6:26 am the MyQ service behaved pretty well, i.e., if you sent an open command they went to "Opening" state and then "Open" state in a few seconds, and if you sent a close command they went to "Closing" and then "Closed" state. Hopefully the physical response you noticed in the door operation was consistent with this. From your door IDs, I am going to guess that you have the MyQ Smart Garage Control system and not actual Chamberlain/Liftmaster door openers. Because this system can only assume the open/closed state from the last position change transmitted by the sensor, it is possible that the MyQ service had a bad internal state and sent an activation to the door even though it was already closed. That would have caused it to actually open, and then when the sensor transmitted the state change, the state changed from "Closing" to "Opening" and then eventually to "Open."
If you check your "History" in the MyQ app, it should show the Close commands coming through around 6:26 am yesterday from your name, and it would be interesting to see if there are subsequent entries with no name changing the state to "Open."
Just to wrap up, the net-net is that I don't really see any To-Dos here for the the MyQ Node Server, and we just need to watch more carefully and see if this weird state tracking error (if that is what it was) happens again.

Good catch! I see the problem here. I am working on a new version with OneTouch macro nodes, and I will fix it in that version.

There is an API call to set the stored state vector for a device. However, I have shied away from it because I'm afraid everyone's use case will be different, and the functionality was already accounted for in the Bond mobile app (along with other configuration functions).
For example, making it a set function seems counterintuitive, in that people may think they are changing the state, and not setting the stored state. In addition, depending on the device, the current stored state vector may include values for power, light, speed, brightness, breeze, timer, etc., making a set function unwieldy. 
However, providing specific commands, such as "Set Stored State to Off" is also problematic, in that there would have to be a lot of them to satisfy everyone's desired usages. For example, your light coming on after a power outage seems like a special case, in that I would think most would default to Off.
I am open to suggestions for an elegant solution here.
Also, for @ISY4Me, you could try adding a network resource to reset the stored state vector. Here is an example CURL command:
curl -H "BOND-Token: {token}" -i https://{hostname}/v2/devices/{device_id}/state -X PATCH -d "{\"light\": 1}"

You are connecting to the Envisalink successfully, it is returning valid data, but it appears that the Envisalink is rejecting the password on login (returns "FAILED"). When you say "tested with web logon" does that mean you logged into the EnvisaLink device on your LAN directly with user ID "user" and the password in the configuration, or that you logged into the EyezOn portal over the web with the password from the configuration? The password for your EnvisaLink device and the password for the EyezOn portal are different. You can reset the password on your EnvisaLink from the EyezOn portal, I believe.
There is a problem in the node server in recognizing the error - it provides the proper bad password notification if the return message is "Failed", but not "FAILED", evidently. I will put that in the TODO list for fixing in the next version.

Just for folks searching in the future, the problems here were 1) bad credentials specified in the Custom Configuration Parameters and 2) an expired/invalid notification for the licensing issue stuck in the PG3 database with nobody (PG3 or node server) clearing it out.

The "connection reset by peer" error in the log is what normally occurs when there is another process connected to the EnvisaLink. You mentioned that you can access the EnvisaLink's web-based configuration page? Try using that to reboot the EnvisaLink then restart the node server.

@Chris McKean Please try upgrading your version of PG3, then reinstalling the node server. Send the new log file if it still fails.

You should be able to drop the KeyPad Linc button in the scene as a controller and the Ceiling Fan in the scene as a responder, then set the Ceiling Fan link type in the scene to "Command" with command "Set Speed" with the parameter "Speed" set to whatever speed number you want.
Turning the scene on should set the fan to the selected speed. Turning the scene off should turn the fan off.
If you leave the link type of the Ceiling Fan in the scene at "Default," then when you turn the scene on it should indeed turn on the fan back to the previously set speed (as remembered by the Bond bridge).
EDIT: I was going to point out that you could also use the Link Type of "Default" and set an On Level percentage, but this does not appear to be an option. Seems like it use to be. You could use a "Command" type of "On" and set a percentage there. The node server was designed to allow the fan to respond to DIM and BRT commands as well, so that an Insteon SwitchLinc Dimmer could be used to control the fan speed, but that appears not to work either due to a design problem in the node server. Right now DIM and BRT commands make the fan change its speed in one speed number increments, instead of the percentage changing the correct amount and then the fan calculating a new speed number from the new percentage, as would be more intuitive.
I don't currently have any Insteon SwitchLincs in my new townhome, and I wasn't going to install any due to Insteon being defunct. However, I do have 10 or 12 switches in boxes and no other alternative right now, so I may install some just to get some basic functions working, then I can play with this design.

A new version v3.0.10 is available that fixes this problem and a few others raised by changes in the Bond v3 API and newer versions of PG3.

When doors have been idle for some period, the Node server is in "inactive" polling mode and polls based on the longpoll setting. When a door state change is detected or a command is sent from the ISY, the Node server switches to an "active" polling and polls based on the shortpoll setting. It remains in active polling mode until there have been no more status changes/commands for 3 minutes. This accounts for the behavior you mentioned on closing because of the 10 second or so alarming period before the door starts moving on remote close (see # 6 in the release notes linked in the pinned topic - https://github.com/Goose66/NSDocs/blob/main/myq-pg3.md). This also accounts for the status taking a minute or more to show up when you open the door via the app and the Node server is in inactive (longpoll) mode. However, I have not experienced this type of behavior on an open, in that when I send an open command from the ISY the door begins to move almost immediately (1 or 2 seconds).
The purpose of this rather convoluted process is that it is important for the Node server to appear like an instance of the mobile app to the MyQ service. Remember that the MyQ Node server is a hack and not an (officially, at least) approved usage of the MyQ API. If we have a bunch of node servers pinging the MyQ service every 10 seconds 24/7, they will detect this and lock us out!

@brians Yes, it had an intermediate folder in the zip file ("evldsc-pg3-3.0.8") in the zip file, as you noted (I uploaded the wrong zip file). I think @bpwwer noticed it and cleaned it up for us. Trophy emoji to Bob!