From 96a8d7bb012cd27761de8d2d9f18e779a0aafc15 Mon Sep 17 00:00:00 2001 From: Mikkel Ricky Date: Tue, 1 Oct 2024 13:54:52 +0200 Subject: [PATCH 1/2] Fix typos --- docs/iot-sensors.md | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/docs/iot-sensors.md b/docs/iot-sensors.md index e7ea31d..cf4cd0b 100644 --- a/docs/iot-sensors.md +++ b/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. ||||| 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 -@| +@| ``` Where `` is the entity `id` as held in the context broker, `` 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/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,7 +170,7 @@ 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. @@ -292,7 +292,7 @@ attached IoT devices and receiving Northbound measurements as the environment ch 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. From 9128abdea54ea1e233ccb35b517fec6e14d459c4 Mon Sep 17 00:00:00 2001 From: Mikkel Ricky Date: Thu, 3 Oct 2024 11:04:53 +0200 Subject: [PATCH 2/2] Add links on localhost URLs --- docs/iot-sensors.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/iot-sensors.md b/docs/iot-sensors.md index cf4cd0b..b7e18fe 100644 --- a/docs/iot-sensors.md +++ b/docs/iot-sensors.md @@ -177,8 +177,8 @@ 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,7 +285,7 @@ of dummy devices using Ultralight 2.0 syntax

Device Monitor

-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