[DOCS-463] Revised docs to update glossary terms (#597)

* Fixing glossary terms

* Revised corrections

.gitignore

@@ -5,3 +5,6 @@
 .DS_Store
 _build
 _static/capabilities.zip
+.firebaserc
+database.rules.json
+firebase.json

architecture/index.rst

@@ -62,7 +62,7 @@ Connectivity management
 Connectivity Management is the layer that connects your SmartThings Hub, the client devices (mobile phones) to SmartThings servers and to the cloud as a whole.
 The Connectivity Management layer is comprised of:
 
--  Hub Connectivity that connects your hub to the cloud.
+-  Hub Connectivity that connects your Hub to the cloud.
 -  Client Connectivity that connects your client devices to the cloud.
 
 These are the highways by which your messages are sent to the internet.
@@ -72,15 +72,15 @@ Device Handler execution
 
 The SmartThings system determines what type of device you are using based on Device Handlers.
 Once the Device Handler is selected, the incoming messages are parsed by that particular Device Handler.
-The input to the Device Handler is a set of device-specific messages, and the output of the Device Handler is normalized SmartThings events.
-Note that one message can lead to many SmartThings events.
+The input to the Device Handler is a set of device-specific messages, and the output of the Device Handler is normalized SmartThings Events.
+Note that one message can lead to many SmartThings Events.
 
 Subscription management
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-When events are created in the SmartThings platform, they don't inherently do anything besides publish that they've happened.
-Instead of events triggering change, SmartApps are configured with subscriptions that listen for defined events.
-The purpose of the subscription management layer is to match up events that are triggered by the Device Handlers with the SmartApp that is using them.
+When Events are created in the SmartThings platform, they don't inherently do anything besides publish that they've happened.
+Instead of Events triggering change, SmartApps are configured with subscriptions that listen for defined Events.
+The purpose of the subscription management layer is to match up Events that are triggered by the Device Handlers with the SmartApp that is using them.
 
 SmartApp execution
 ^^^^^^^^^^^^^^^^^^
@@ -92,11 +92,11 @@ Any data that needs to persist throughout SmartApp instances must be stored in a
 Web UI and IDE
 ^^^^^^^^^^^^^^
 
-The Web UI sits on top of all of the other technology and allows you to monitor your devices, hubs, locations and many other aspects of your SmartThings system.
+The Web UI sits on top of all of the other technology and allows you to monitor your devices, Hubs, Locations and many other aspects of your SmartThings system.
 
 You have full control of the configuration, including editing, adding, removing, and even creating SmartApps.
 To create, you write code within the IDE for SmartApps and Device Handlers.
-SmartThings also has an integrated simulator that allows you to simulate any devices, so it's not required to own the devices you develop for.
+SmartThings also has an integrated Simulator that allows you to simulate any devices, so it's not required to own the devices you develop for.
 
 Important concepts
 ------------------
@@ -117,7 +117,7 @@ This means that you execute a command, and assume it will turn on in due time, w
 You cannot be guaranteed that your command has been executed, because another SmartApp could interact with your end device, and change its state.
 For example, you might turn a light switch on, but another app might sneak in and turn it off.
 
-If you need to know if a command was executed, you can subscribe to an event triggered by the command you executed and check its timestamp to ensure it fired after you told it to.
+If you need to know if a command was executed, you can subscribe to an Event triggered by the command you executed and check its timestamp to ensure it fired after you told it to.
 You will, however, still have latency issues to take into consideration, so it's impossible to know the exact current status at any given time.
 
 The SmartApps platform follows eventually consistent programming, meaning that responses to a request for a value in SmartApps will eventually be the same, but in the short term they might differ.
@@ -126,7 +126,7 @@ Containers
 ^^^^^^^^^^
 
 Within the SmartThings platform, there are three different “containers” that are important concepts to understand.
-These are: *accounts, locations,* and *groups.*
+These are: *accounts, Locations,* and *groups.*
 These containers represent both security boundaries and navigation containers that make it easy for users to browse their devices.
 
 The diagram below shows the hierarchical relationship between these containers.
@@ -153,7 +153,7 @@ Finally, locations contain Groups or Devices.
 Groups
 ^^^^^^
 
-Groups are meant to represent a room or other physical space within a location.
+Groups are meant to represent a room or other physical space within a Location.
 This allows for devices to be organized into groups making navigation and security easier.
 A group can contain multiple devices, but devices can only be in a single group.
 Further, nesting of groups is not currently supported.
@@ -199,7 +199,7 @@ SmartThings cloud
 The SmartThings platform assumes a "Cloud First” approach.
 This means that in order to use all supported devices and automations, and to ensure that the SmartThings mobile application reflects the correct state of your home, the SmartThings Hub will need to be online and be connected to the SmartThings cloud.
 
-The second generation of the hub, the Samsung SmartThings Hub, allows for some hub-local capabilities.
+The second generation Hub, the Samsung SmartThings Hub, allows for some Hub-local capabilities.
 Certain automations can execute even when disconnected from the SmartThings cloud.
 This allows SmartThings to improve performance and insulate the user from intermittent internet outages.
 
@@ -223,13 +223,13 @@ Put simply, if there is no Hub, then the SmartApps layer must run in the cloud!
 
 **Scenario: SmartApps may run across both cloud- and Hub-connected devices**
 
-As a corollary to the first point above, since there are use cases where devices are not hub-connected, SmartApps might be installed to use one device that is hub-connected, and another device that is cloud-connected, all in the same app.
+As a corollary to the first point above, since there are use cases where devices are not Hub-connected, SmartApps might be installed to use one device that is Hub-connected, and another device that is Cloud-connected, all in the same app.
 In this case, the SmartApp needs to run in the cloud.
 
 **Scenario: There may be multiple Hubs**
 
 While the mesh network standards for ZigBee and Z-Wave generally eliminate the need for multiple SmartThings Hubs, we didn’t want to exclude this as a valid deployment configuration for large homes or even business applications of our technology.
-In the multi-hub case, SmartApps that use multiple devices that are split across hubs will run in the cloud in order to simplify the complexity of application deployment.
+In the multi-Hub case, SmartApps that use multiple devices that are split across hubs will run in the cloud in order to simplify the complexity of application deployment.
 
 **Scenario: External service integration**
 
@@ -255,27 +255,27 @@ Hubs and Locations
 ------------------
 
 To efficiently manage performance, the SmartThings platform scales its cloud server architecture horizontally with *sharding*.
-Sharding helps reduce the latency between the hub and the cloud, and handles increasing capacity.
+Sharding helps reduce the latency between the Hub and the cloud, and handles increasing capacity.
 As a developer you must note the impact of sharding on how you work with the SmartThings IDE.
 
-When you first install SmartThings app on your mobile phone, create your user account and claim your hub, the SmartThings platform automatically assigns your hub to the location and connects your location/hub to a particular shard.
+When you first install SmartThings app on your mobile phone, create your user account and claim your Hub, the SmartThings platform automatically assigns your Hub to the Location and connects your Location/Hub to a particular shard.
 Before starting your development, you must note that:
 
-- Your location/hub is connected to a *specific* SmartThings shard, based on the geographical location of the hub, and,
-- You must ensure that you are logged into the URL of this specific shard on IDE. Since the location is always connected to the correct shard URL, you can do this by clicking on your location from "My Locations" page after you log in.
+- Your Location/Hub is connected to a *specific* SmartThings shard, based on the geographical location of the Hub, and,
+- You must ensure that you are logged into the URL of this specific shard on IDE. Since the Location is always connected to the correct shard URL, you can do this by clicking on your Location from "My Locations" page after you log in.
 
 .. note::
 
-    If for some reason you are not seeing your hub in the IDE, then from *My Locations* page select the location and it will prompt you to log into correct shard where you can see your hub.
+    If for some reason you are not seeing your Hub in the IDE, then from *My Locations* page select the Location and it will prompt you to log into correct shard where you can see your Hub.
 
 Consequences of sharding
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 In practice, some consequences of sharding are:
 
-- A global layer, with a few specific services, spans across all shards while all other services are owned by the specific shard itself (which, as emphasized above, is location-dependent). A few global layer services are: user account creation, authorization, OAuth authentication, mappings of location-to-shard, users-to-locations and hub-to-locations. All data that is down from the location level are managed by the specific shard.
+- A global layer, with a few specific services, spans across all shards while all other services are owned by the specific shard itself (which, as emphasized above, is Location-dependent). A few global layer services are: user account creation, authorization, OAuth authentication, mappings of Location-to-shard, users-to-Locations and Hub-to-Locations. All data that is down from the Location level are managed by the specific shard.
 - A shard does not share information with another shard. For example, a common login across the shards does not exist yet. You will have to log in to each shard, although the userid and password will be the same (see the note above). At the same time, note that SmartThings mobile app users do not have to log in again because mobile client OAuth tokens are shared across the shards.
-- SmartApps and Device Handlers are now published in a specific shard and not for your entire account. For example, if you have a hub in North America and another hub in Europe, you will need to publish your SmartApp twice, one in each location, i.e., shard.
-- Note that since a hub is assigned to a location, if you delete a location, the hub becomes unclaimed. Conversely, it is possible for a location to exist without a claimed hub at that location.
+- SmartApps and Device Handlers are now published in a specific shard and not for your entire account. For example, if you have a Hub in North America and another Hub in Europe, you will need to publish your SmartApp twice, one in each Location, i.e., shard.
+- Note that since a Hub is assigned to a Location, if you delete a Location, the Hub becomes unclaimed. Conversely, it is possible for a Location to exist without a claimed Hub at that Location.
 
 .. |Container Hierarchy| image:: ../img/architecture/overview.png

arduino/index.rst

@@ -31,15 +31,15 @@ You can download the `SmartThings Arduino Library here <http://cl.ly/ZMHh>`__.
 Pairing the shield
 ------------------
 
-To join the shield to your SmartThings hub, go to “Add SmartThings” mode in the
+To join the shield to your SmartThings Hub, go to “Add SmartThings” mode in the
 SmartThings app by hitting the “+” icon in the desired location, and then press the Switch button on the shield. You should see the shield appear in the app.
 
 To unpair the shield, press and hold the Switch button for 6 seconds and release. The shield will now be unpaired from your SmartThings Hub. Make sure to delete from your account if you plan to re-pair it!
 
 Changing the Device Handler
 ---------------------------
 
-By changing the Device Handler in the SmartThings cloud you can change how to interact with your Arduino + ThingShield. When a shield first pairs, it has no functionality and only serves to help identify the device in the mobile app. We have some pre-built Device Handlers that you can use for most functionality. One pre-built Arduino device handler is the “On/Off Shield (example)”
+By changing the Device Handler in the SmartThings cloud you can change how to interact with your Arduino + ThingShield. When a shield first pairs, it has no functionality and only serves to help identify the device in the mobile app. We have some pre-built Device Handlers that you can use for most functionality. One pre-built Arduino Device Handler is the “On/Off Shield (example)”
 
 To change your Device Handler, log into `http://graph.api.smartthings.com/` and click on “Devices” Navigate to and click on the Arduino ThingShield then click on “Edit” on the bottom left of the page.
 
@@ -51,7 +51,7 @@ Hit the "Update" button
 
 Your Arduino will now be able to accept the commands "on" "off", and "hello"
 
-`Here is what the Arduino sketch looks like <https://gist.github.com/aurman/6546221>`__ and here is the `device handler <https://gist.github.com/aurman/6862503>`__.
+`Here is what the Arduino sketch looks like <https://gist.github.com/aurman/6546221>`__ and here is the `Device Handler <https://gist.github.com/aurman/6862503>`__.
 
 `Here is a different Device Handler that can read a string sent from an Arduino and display it in a tile <https://gist.github.com/aurman/6546257>`__.
 

cloud-and-lan-connected-device-types-developers-guide/building-cloud-connected-device-types/building-the-device-type.rst

@@ -1,26 +1,26 @@
 Building the Device Handler
 ===========================
 
-The Device Handler for a cloud-connected device is generally the same as any other device handler. 
+The Device Handler for a Cloud-connected device is generally the same as any other Device Handler.
 The means in which
-it handles sending and receiving messages from its device is a little bit different. 
-Let's walk through a cloud connected
-device handler example.
+it handles sending and receiving messages from its device is a little bit different.
+Let's walk through a Cloud-connected
+Device Handler example.
 
 The Parse method
 ----------------
 
-The parse method for cloud connected devices will always be empty. In a
-cloud connected device, event data is passed down from the service
-manager, not from the device itself, so the parsing is handled in a
+The parse method for Cloud-connected devices will always be empty. In a
+Cloud-connected device, Event data is passed down from the Service
+Manager, not from the device itself, so the parsing is handled in a
 separate method. The Device Handler doesn't interface directly with
 a hardware device, which is what parse is used for.
 
 Sending commands to the third-party cloud
 -----------------------------------------
 
-Usually the actual implementation of device methods are delegated to its service manager. This is because the service
-manager is the entity that has the authentication information. To invoke a method on the parent service manager,
+Usually the actual implementation of device methods are delegated to its Service Manager. This is because the Service
+Manager is the entity that has the authentication information. To invoke a method on the parent Service Manager,
 you simply need to call it in the following format:
 
 .. code-block:: groovy
@@ -30,7 +30,7 @@ you simply need to call it in the following format:
 As with any other device-type, you need to define methods for all of the
 possible commands for the capabilities you'd like to support. Then when
 a user calls this method, it will pass information up to the parent
-service manager, who will make the direct connection to the third party
+Service Manager, who will make the direct connection to the third party
 cloud. You might for example want to turn a switch on, so you would call
 the following.
 
@@ -44,8 +44,8 @@ Receiving Events from the third-party cloud
 -------------------------------------------
 
 The Device Handler continuously polls the third-party cloud through
-the service manager to check on the status of devices. When an event is
-fired, they can then be passed to the child device handler. Note that
+the service manager to check on the status of devices. When an Event is
+fired, they can then be passed to the child Device Handler. Note that
 poll runs every 10 minutes for Service Manager SmartApps.
 
 In the device-type handler:
@@ -92,7 +92,7 @@ Generating Events at the request of the Service Manager
 -------------------------------------------------------
 
 You won't generate events directly within the Service Manager, but
-rather request that they are generated within the Device-type handler.
+rather request that they are generated within the Device Handler.
 For example:
 
 In the service manager:
@@ -101,7 +101,7 @@ In the service manager:
 
     childName.generateEvent(data)
 
-In the device handler:
+In the Device Handler:
 
 .. code-block:: groovy
 
@@ -110,4 +110,4 @@ In the device handler:
         sendEvent(name: name, value: value)
       }
       return null
-    }
+    }

cloud-and-lan-connected-device-types-developers-guide/building-cloud-connected-device-types/division-of-labor.rst

@@ -1,9 +1,9 @@
 Division of Labor
 =================
 
-The Cloud-connected device paradigm consists of a Service Manager and Device Handlers. 
+The Cloud-connected device paradigm consists of a Service Manager and Device Handlers.
 The purpose of this guide is
-to introduce you to the core concepts of cloud connected device development, and provide some examples to help you get
+to introduce you to the core concepts of Cloud-connected device development, and provide some examples to help you get
 started.
 
 
@@ -19,7 +19,7 @@ your connection to be able to make future interactions with the device.
 Device Handler responsibilities
 -------------------------------
 
-The device handler is responsible for creating and receiving device
+The Device Handler is responsible for creating and receiving device
 specific messages, and allowing them to work within the SmartThings
 infrastructure. It takes in a SmartApp specific command and outputs
 device specific commands to be passed to the cloud. It also allows you
@@ -29,7 +29,7 @@ needed.
 How it all works
 ----------------
 
-The following depiction gives a general overview of how a cloud connected device works. Take note of
+The following depiction gives a general overview of how a Cloud-connected device works. Take note of
 the Service Manager and Device Handler. We will dive into how to build these next.
 
 .. image:: ../../img/architecture/cloud_overview.png

cloud-and-lan-connected-device-types-developers-guide/building-cloud-connected-device-types/index.rst

@@ -1,14 +1,14 @@
 Building Cloud-connected Device Types
 =====================================
 
-Cloud-connected devices use a third-party service to accomplish device communication. 
+Cloud-connected devices use a third-party service to accomplish device communication.
 An example of such a device is the
 Ecobee thermostat.
 
-When developing a device handler for a cloud connected device, you must create a service manager SmartApp that will handle authenticating with the 3rd party service, communicating with the device, and reacting to any device changes that occur.
+When developing a Device Handler for a Cloud-connected device, you must create a Service Manager SmartApp that will handle authenticating with the third-party service, communicating with the device, and reacting to any device changes that occur.
 
-This guide overviews the concept of the service manager/device handler architecture and
-also gives an example of both the service manager and device handler creation.
+This guide overviews the concept of the Service Manager/Device Handler architecture and
+also gives an example of both the Service Manager and Device Handler creation.
 
 Table of Contents: