Launch Data (ActiveX Classname):   PH_AlexaWemo.phalexawemo

Initialization Data:A full path and filename to the plugin INI file. A base configuration INI file can be found in the plugins directory at c:\powerhome\plugins\phalexawemo.ini. Details on how to configure the INI are provided below.

This plugin provides the ability to control and interact with PowerHome using an Amazon Alexa and the smart home interface. Alexa supports a number of SmartHome technologies but the majority of them require an app specific to the technology to be installed as a plugin to your Alexa and then linking that plugin to your account for the specific technology. There are a couple of SmartHome protocols supported by Alexa that do NOT require installing a plugin and/or linking to an app/account for the technology. Those two protocols are the Philips Hue bridge and the Wemo device support. This plugin works by emulating Wemo devices that Alexa can control. A proper integration of PowerHome and Alexa (and hopefully Google Home) will be in the works but for now this plugin should suffice for basic control.

The plugin supports the creation of virtual Wemo devices that are either "plugs" or "dimmers" but Alexa only supports the functionality of plugs (on or off) for Wemo devices that are not linked to the Wemo app. What that means is that you'll be able to control devices with either on or off commands...you won't have access to dimmer or level commands. While the plugin supports status requests for the virtual devices, for some reason this is not supported by an Alexa device (Echo, Dot, etc) and is only supported in the Alexa app.

With each virtual Wemo device you define, you will give the device a "Name". This is the name you will use when speaking to Alexa to invoke an on or off command. For each virtual device you'll also be able to specify the actions you wish PowerHome to take for the "On", "Off", and "Status" commands. Each action can be one of several types: None, Device Control string, Macro ID, Formula ID, or Raw Formula. You can also specify whether a trigger will be fired for each action.

The base configuration INI (c:\powerhome\plugins\phalexawemo.ini) is listed below:

[Setup]
devicecount=2
startingport=8200

;*leave upnpserverip blank to use any available IP
upnpserverip=

;*leave upnpdevices blank so that ALL devices below will have their UPNP info echoed back on an M-SEARCH
;To limit the M-SEARCH response to certain devices, enter a comma separated list of device numbers (no spaces)
;It is sometimes necessary to limit the number of devices as Alexa is not able to discover a large number of devices
;and may require you to discover them in groups.
upnpdevices=

;*debug=0 no debug trigger fired. debug=1 debug trigger is fired (command 255). debug=2 Error Exceptions trigger is fired (command 256). debug=3 Debug and Error triggers are fired.
debug=0

;*device actiontypes must be one of the values listed below
;0 = none
;2 = device status
;4 = macro
;6 = formula
;8 = raw formula
;add 1 to any of the above to fire a trigger (command num = device num, option 1 = On, option 2 = off, option 3 = status)

[device_1]
name=Kitchen Test Light
;*leave ip blank to use the default machine ip
ip=
;*set port to 0 or leave blank to use ports based off of startingport
port=
devicetype=0
actionontype=3
actionon=INSTEON+KITCHEN+ON
actionofftype=3
actionoff=INSTEON+KITCHEN+OFF
actionstatustype=3
actionstatus=INSTEON+KITCHEN

[device_2]
name=Family Room Test Light
ip=
port=
devicetype=1
actionontype=3
actionon=INSTEON+FAMILYRM+ON
actionofftype=3
actionoff=INSTEON+FAMILYRM+OFF
actionstatustype=2
actionstatus=INSTEON+FAMILYRM

Keep in mind when reviewing the file above that the ";" character at the start of a line in an INI file indicates the line is a comment. It is not an actual part of the configuration. The first section you'll see is the [setup] section. You'll start by defining the total number of virtual Wemo devices you would like to emulate in the "devicecount" parameter. In the sample above, we've defined two virtual Wemo devices. The next parameter is the "port". Actual Wemo devices have each have a unique IP address and typically the same default port. In actual use, the Wemo device will change the port in use up and or down 1 or 2 values but for the most part what distinguishes one Wemo device from another is the IP address and not the port. In the Wemo emulator, the plugin is running on the PowerHome machine which would typically have a single IP address. To distinguish between multiple virtual devices, each device will have a unique port. Alexa doesnt really care that the IP address is the same and the port isnt in the standard range so this works well. The "port" parameter should be set with your starting port of the first virtual device. The plugin will then increment this port number for each subsequent device. If the starting port is 8200, then [device_1] will have port 8200, [device_2] will have port 8201, etc. Care should be taken that you don't reuse ports that may already be in use on the PowerHome machine depending upon how many virtual devices you have.

Emulating a Wemo device requires at least 2 servers. One is a UPNP (Universal Plug-n-Play) server that uses the UDP protocol that is used for device discovery. The other is the actual webserver that is built into each Wemo device and is what the "port" parameter is assigned to. Since the UPNP server uses a specific port, we use a single instance of this server to handle the UPNP requirements of ALL the virtual Wemo devices. The "upnpserverip" parameter allows you to specify the specific IP on the PowerHome machine that you want the UPNP server to be associated with. Since most machines will have a single IP, just leave this parameter blank to use the default.

The "upnpdevices" parameter is also usually left blank, especially during initial virtual Wemo device discovery and during normal use. When Alexa searches for "New Devices", it sends a special UPNP command that any listening device that matches the search term will respond to. UDP traffic is a connectionless protocol and essentially a "broadcast" and hope someone hears it. Since it is likely that you already have a fair amount of devices in your home that are UPNP compliant along with however many virtual Wemo devices you create, that can be ALOT of traffic and almost always, some of it is missed and unacknowledged. So if your Alexa is having a difficult time discovering ALL your virtual Wemo devices, you can set the "upnpdevices" parameter to a comma separated list of device numbers (the numbers of the devices you're having trouble discovering) that you wish to respond to the UPNP search command and having devices that have already been discovered NOT responding to help reduce traffic.

The last [setup] parameter is the "debug" parameter. In normal use (assuming everything is working properly), you'll set this to 0. If you are debugging issues, then you can set this parameter to either 1, 2, or 3 to fire "Debug" triggers, "Exception" triggers, or both Debug and Exception triggers. In these triggers you would typically log the [TEMP?] variables to a file or display them onscreen in a messagebox (trust me, logging to a file is easier with the amount of traffic).

After the [setup] section, you will have a [device_?] section for each device you've specified up to the "devicecount" parameter. The first parameter for a device is the "name" parameter. This is the name you'll use to invoke control from Alexay and should be unique from any other virtual Wemo device (or other actual devices that may be in use by Alexa). The "ip" parameter allows you to specify a specific IP to use for the device if you do have multiple IP's associated with your PowerHome machine. Usually you'll leave this parameter blank. The "port" parameter allows you to override the "startingport" parameter and specify a specific port that this virtual device will use. The "devicetype" parameter will be either 0 or 1. 0 is used to have the virtual device appear as a Wemo "plug" and 1 is used to have the device appear as a Wemo "dimmer". As stated earlier, Alexa does not support the "dimmer" functionality without being linked to the Wemo app so you can use either but probably best to just set to 0 for all devices.

The 6 remaining parameters for a device consist of 3 pairs of parameters. One pair for the "On" action, one pair for the "Off" action and one pair for the "Status" action. For each action type, you can use the values 0, 2, 4, 6, or 8 for the following action types: None, Device Control string, Macro ID, Formula ID, Raw Formula. For each action type, you can also add the value 1 to ALSO fire a Generic Plugin trigger when the Alexa invokes the action. After setting the action type, you'll then declare the actual action based upon the action type you chose.

Keep in mind that your actions DONT have to actually reflect an actual device. You can create a virtual device named "Good Night" and then have it fire a macro that performs any number of actions you choose.

The following controller commands are supported by this plugin and can be activated by using the ph_picmd( ) function:

Command	Parm1	Description
0	0	Returns a string listing all the parameters specified for all the devices configured (1 thru DeviceCount)
0	1 thru DeviceCount	Returns a string listing all the parameters for the specified Device number in Parm1

Command	Option	Description
1 thru DeviceCount	1	This trigger is fired when Alexa sends an "On" command to a virtual Wemo device that matches the Device Number specified in the Command parameter if the "On" Action Type for that device is set to fire a trigger (Action Type values 1,3,5,7,9).
1 thru DeviceCount	2	This trigger is fired when Alexa sends an "Off" command to a virtual Wemo device that matches the Device Number specified in the Command parameter if the "Off" Action Type for that device is set to fire a trigger (Action Type values 1,3,5,7,9).
1 thru DeviceCount	3	This trigger is fired when Alexa sends a "Status" command to a virtual Wemo device that matches the Device Number specified in the Command parameter if the "Status" Action Type for that device is set to fire a trigger (Action Type values 1,3,5,7,9).
255	1	If the debug parameter is set to 1 or 3, this trigger fires when the HTTP server for a virtual Wemo device is successfully created.
255	2	If the debug parameter is set to 1 or 3, this trigger fires when ALL the HTTP servers have been created for the virtual Wemo devices.
255	3	If the debug parameter is set to 1 or 3, this trigger fires when the UPNP Listener server is successfully created.
255	4	If the debug parameter is set to 1 or 3, this trigger fires when the UPNP server receives an M-SEARCH message.
255	5	If the debug parameter is set to 1 or 3, this trigger fires if a matching Search Term from an M-SEARCH message is found.
255	6	If the debug parameter is set to 1 or 3, this trigger fires when the UPNP server sends a response to an M-SEARCH message..
255	7	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server accepts a request.
255	8	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP successfully receives a request.
255	9	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server sends a response for SETUP.XML
255	10	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server sends a response for SetBinaryState
255	11	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server sends a response for GetBinaryState
255	12	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server sends a response for unknown requests
255	13	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server completes a response for an HTTP request
255	14	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server sends a response for METAINFOSERVICE.XML
255	15	If the debug parameter is set to 1 or 3, this trigger fires when a virtual Wemo device HTTP server sends a response for EVENTSERVICE.XML
256	1	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs when trying to determine the plugin local IP
256	2	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs when initializing an HTTP server for a Wemo device
256	3	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs when initializing the UPNP server
256	4	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs when receiving a UPNP multicast request
256	5	If the debug parameter is set to 2 or 3, this trigger fires if an error occurs when sending a UPNP unicast response
256	6	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs when sending a UPNP unicast response
256	7	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs during an HTTP Accept
256	8	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs during an HTTP Read
256	9	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs during an HTTP Initial Send
256	10	If the debug parameter is set to 2 or 3, this trigger fires if an exception occurs during an HTTP Callback Send