Merge pull request #14 from rimi-itk/patch-1

Fix typos

Author: jason-fox

docs/iot-sensors.md

@@ -49,8 +49,8 @@ tutorial:
 -   A **Bell** can be sent a command to activate and ring for a short period
 -   A **Motion Sensor** will activate and send a count when someone is nearby
 -   A **Smart Lamp** can be switched on or off remotely. It can also report on its current state (`ON` or `OFF`). When
-    switched on, a Motion Sensor within the device checks to see if light is needed and will dim if no-one is nearby.
-    Furthermore the device can be report on the current luminosity of the bulb.
+    switched on, a Motion Sensor within the device checks to see if light is needed and will dim if no one is nearby.
+    Furthermore the device can report the current luminosity of the bulb.
 
 As you can see, the **Bell** is an example of a pure actuator, as it only reacts to the given commands. Meanwhile, the
 **Motion Sensor** is an example of a pure sensor, since it will only report on the state of the world as it sees it. The
@@ -73,25 +73,25 @@ e.g.
 <key>|<value>|<key>|<value>|<key>|<value> etc..
 ```
 
-For example a payload such as:
+For example a payload such as
 
 ```text
 t|15|k|abc
 ```
 
-Contains two attributes, one named "t" with value "15" and another named "k" with value "abc" are transmitted. Values in
-Ultralight 2.0 are not typed (everything is treated as a string).
+contains two attributes, one named "t" with value "15" and another named "k" with value "abc". Values in Ultralight 2.0
+are not typed (everything is treated as a string).
 
-Ultralight 2.0 defines a payload describing measures and commands to share between devices and servers but, does not
+Ultralight 2.0 defines a payload describing measurements and commands to share between devices and servers but, does not
 specify a single transport protocol. Instead, different transport protocol bindings (such as HTTP, MQTT and AMQP) can be
 used for different scenarios. For this tutorial we will be using HTTP as a transport protocol.
 
 ## Southbound Traffic (Commands)
 
-HTTP requests generated by the form the Context Broker and passed downwards towards an IoT device (via an IoT agent) are
-known as southbound traffic. Southbound traffic consists of **commands** made to actuator devices which alter the state
-of the real world by their actions. For example a command to alter the state of a lamp to `ON` would switch on the lamp
-in real life. This in turn could alter the readings of other sensors nearby.
+HTTP requests generated by the Context Broker and passed downwards towards an IoT device (via an IoT Agent) are known as
+southbound traffic. Southbound traffic consists of **commands** made to actuator devices which alter the state of the
+real world by their actions. For example a command to alter the state of a lamp to `ON` would switch on the lamp in real
+life. This in turn could alter the readings of other sensors nearby.
 
 ### Push Command using HTTP POST
 
@@ -103,18 +103,18 @@ the endpoint supplied by the device. The body of the POST request holds the comm
 The payload for Ultralight commands has the following format:
 
 ```text
-<device name>@<command>|<param|<param>
+<device_name>@<command>|<param|<param>
 ```
 
 Where `<device_name>` is the entity `id` as held in the context broker, `<command>` is one of the supported commands and
-any additional required values are passed in subsequent parameters for example
+any additional required values are passed in subsequent parameters, for example
 
 ```
 urn:ngsi-ld:Robot:001@turn|left|30
 ```
 
-Will tell a device _"I am known as `id="urn:ngsi-ld:Robot:001"` within the Context Broker. I would like the device
-listening on this endpoint to perform the `turn` command. I have supplied the parameters `left` and '`30` (degrees) as
+will tell a device _"I am known as `id="urn:ngsi-ld:Robot:001"` within the Context Broker. I would like the device
+listening on this endpoint to perform the `turn` command. I have supplied the parameters `left` and `30` (degrees) as
 required for the device to be able to perform the maneuver"_.
 
 The defined Northbound response to an IoT Agent is as follows:
@@ -123,7 +123,7 @@ The defined Northbound response to an IoT Agent is as follows:
 urn:ngsi-ld:Robot:001@turn|Turn ok
 ```
 
-Which is saying _"I have complied with a request from the entity known as `id="urn:ngsi-ld:Robot:001"` within the
+which is saying _"I have complied with a request from the entity known as `id="urn:ngsi-ld:Robot:001"` within the
 Context Broker. The command I have performed was a `turn` command. The result was `Turn ok`"_.
 
 As you can see, because the Southbound command defines the `id` used within the interaction, and the same data is also
@@ -135,11 +135,11 @@ beyond the scope of this tutorial.
 
 ## Northbound Traffic (Measurements)
 
-Requests generated from an IoT device and passed back upwards towards the Context Broker (via an IoT agent) are known as
+Requests generated from an IoT device and passed back upwards towards the Context Broker (via an IoT Agent) are known as
 northbound traffic. Northbound traffic consists of **measurements** made by sensor devices and relays the state of the
 real world into the context data of the system. For example a measurement from a humidity sensor could be relayed back
 into the context broker to indicate that the moisture level of the entity has changed. A subscription could be made to
-be informed of such changes and there provoke further actions (such as turning on a sprinkler)
+be informed of such changes and there provoke further actions (such as turning on a sprinkler).
 
 ### Measurement using HTTP GET
 
@@ -159,7 +159,7 @@ For example the request:
 <iot-agent>/iot/d?i=motion001&d=c|12
 ```
 
-Would indicate that the device `id=motion001` wishes to inform the IoT Agent that is has made a real-world measurement
+would indicate that the device `id=motion001` wishes to inform the IoT Agent that is has made a real-world measurement
 `c` with the value `12`. This would eventually be passed up into the Context Broker.
 
 ### Measurement using HTTP POST
@@ -170,15 +170,15 @@ mandatory:
 
 -   `i` (device ID): Device ID (unique for the API Key).
 -   `k` (API Key): API Key for the service the device is registered on.
--   `t` (timestamp): Timestamp of the measure. Will override the automatic IoTAgent timestamp (optional).
+-   `t` (timestamp): Timestamp of the measure. Will override the automatic IoT Agent timestamp (optional).
 
 Once again the `i` and `k` parameters are mandatory.
 
 #### Device Monitor
 
 For the purpose of this tutorial, a series of dummy IoT devices have been created, which will eventually be attached to
-the context broker. The state of each device can be seen on the UltraLight device monitor web page found at:
-`http://localhost:3000/device/monitor`
+the context broker. The state of each device can be seen on the UltraLight device monitor web page found at
+[`http://localhost:3000/device/monitor`](http://localhost:3000/device/monitor).
 
 ![FIWARE Monitor](https://fiware.github.io/tutorials.IoT-Sensors/img/device-monitor.png)
 
@@ -285,14 +285,14 @@ of dummy devices using Ultralight 2.0 syntax
 
 <h4>Device Monitor</h4>
 
-The device monitor can be found at: `http://localhost:3000/device/monitor`
+The device monitor can be found at [`http://localhost:3000/device/monitor`](http://localhost:3000/device/monitor).
 
 Within this tutorial you will be playing the role of the missing IoT Agent component, making Southbound commands to the
 attached IoT devices and receiving Northbound measurements as the environment changes within the store. All the commands
 are made as HTTP POST requests using Ultralight syntax and therefore are very simple. It is worthwhile keeping an eye on
 the device monitor page as it shows all the Northbound traffic generated by the devices themselves.
 
-> **Note:** In addition to user interactions, All dummy devices will periodically register a heartbeat message
+> **Note:** In addition to user interactions, all dummy devices will periodically register a heartbeat message
 
 ## Bell Commands
 
@@ -330,7 +330,7 @@ If you are viewing the device monitor page, you can see the state of the bell ch
 ## Smart Lamp Commands
 
 The **Smart Lamp** can be switched on and off remotely - it also registers luminosity. It contains a Motion Sensor
-within it and will slowly dim as time passes (provided no movement is detected)
+within and will slowly dim as time passes (provided no movement is detected)
 
 Measurements will be sent to the IoT Agent as the state and/or luminosity changes.