From db9322c89525862fa37d48b2bcc743f23a1d08ab Mon Sep 17 00:00:00 2001 From: Jason Fox Date: Tue, 4 Jun 2024 10:18:30 +0200 Subject: [PATCH] Switch to WSL --- FIWARE IoT Sensors.postman_collection.json | 2 +- README.es.md | 6 +++--- README.ja.md | 8 +++----- README.md | 9 +++++---- 4 files changed, 12 insertions(+), 13 deletions(-) diff --git a/FIWARE IoT Sensors.postman_collection.json b/FIWARE IoT Sensors.postman_collection.json index 3faa503..7bd0fdf 100644 --- a/FIWARE IoT Sensors.postman_collection.json +++ b/FIWARE IoT Sensors.postman_collection.json @@ -2,7 +2,7 @@ "info": { "_postman_id": "4d0c5bf7-9f5d-42aa-b11d-c8994b5bc26e", "name": "FIWARE IoT Sensors", - "description": "This tutorial is an introduction to IoT devices and the usage of the \n[UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual) Protocol for \nconstrained devices. The tutorial introduces a series of dummy IoT devices which are displayed within the browser and\nallows a user to interact with them. A complete understanding of all the terms and concepts defined in this\ntutorial is necessary before proceeding to connect the IoT devices to the Orion Context Broker via a real IoT Agent. \n\nThe `docker-compose` files for this tutorial can be found on GitHub: \n\n![GitHub](https://fiware.github.io/tutorials.Historic-Context/icon/GitHub-Mark-32px.png) [FIWARE 201: Introduction to IoT Sensors](https://github.com/Fiware/tutorials.IoT-Sensors)\n\n\n# What are IoT devices?\n\n> \"All our knowledge begins with the senses.\"\n>\n> — Immanuel Kant (Critique of Pure Reason)\n\nThe [Internet of Things](https://www.linux.com/news/who-needs-internet-things) (IoT) is a network of physical\ndevices which are able to connect to a network and exchange data. Each \"thing\" or \"smart device\" is a gadget\nwith embedded electronics and sofware which can act as a sensor or actuator. Sensors are able to report the\nstate of the real-world around them. Actuators are responsible for altering the state of the system, by responding\nto a control signal.\n\nEach device is uniquely identifiable through its embedded computing system but is able to inter-operate within the\nexisting Internet infrastructure.\n\nFIWARE is a system for managing context information. For a smart solution based on the Internet of Things,\nthe context is provided by the array of attached IoT devices. Since each IoT device is a physical object which\nexists in the real world, it will eventually be represented as a unique entity within the context.\n\nIoT devices can range from simple to complex. Here are some examples of IoT devices which will be used within this tutorial:\n\n* A **Smart Door** is an electronic door which can be sent commands to be locked or unlocked remotely.\n It can also report on its current state (`OPEN`, `CLOSED` or `LOCKED`), \n* A **Bell** can be sent a command to activate and ring for a short period\n* A **Motion Sensor** can be queried to return the number of people who have passed by since it was last reset\n* A **Smart Lamp** can be switched on or off remotely. It can also report on its current state (`ON` or `OFF`).\n When switched on, a motion sensor within the device checks to see if light is is needed and will dim if no-one is nearby.\n Furthermore the device can be report on the current luminocity of the bulb.\n\nAs you can see, the **Bell** is an example of a pure actuator, as it only reacts to the given commands. Meanwhile the \n**Motion Sensor** is an example of a pure sensor, since it will only report on the state of the world as it sees it.\nThe other two devices are able to both respond to commands and report on state in a meaningful way.\n\nThe state information held within each device, as it will eventually be seen within the Context Broker is defined in in the diagram below:\n\n![](https://fiware.github.io/tutorials.IoT-Sensors/img/entities.png)\n\n# What is Ultralight 2.0?\n\n[UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual) is a lightweight text based protocol for constrained devices and communications where\nbandwidth and device memory resources are limited. The payload for measurement requests is\na list of key-value pairs separated by the pipe `|` character. \n\ne.g.\n\n```\n||||| etc..\n```\n\nFor example a payload such as:\n\n```\nt|15|k|abc\n```\n\nContains two attributes, one named \"t\" with value \"15\" and another named \"k\" with value \"abc\" are transmitted. \nValues in Ultralight 2.0 are not typed (everything is treated as a string).\n\nUltralight 2.0 defines a payload describing measures and commands to share between devices and servers but, \ndoes not specify a single transport protocol. Instead, different transport protocol bindings (such as HTTP,\nMQTT and AMQP) can be used for different scenarios. For this tutorial we will be using HTTP as a transport protocol.\n\n## Southbound Traffic (Commands)\n\nHTTP requests generated by the from the Context Broker and passed downwards towards an IoT device (via\nan IoT agent) are known as southbound traffic. Southbound traffic consists of **commands** made to \nactuator devices which alter the state of the real world by their actions. For example a command\nto alter the state of a lamp to `ON` would switch on the lamp in real life. This in turn could alter\nthe readings of other sensors nearby.\n\n### Push Command using HTTP POST \n\n\nSetting up the southbound communication between an IoT Agent and IoT devices is known as provisioning.\nThis ensures that the IoT Agent holds sufficient information to be able to contact each IoT device.\nIn other words it knows where to send commands and which commands are supported. In order to send a\ncommand to a device, the IoT Agent sends a POST request to the endpoint supplied by the device. The body of the POST request holds the command.\n\nThe payload for Ultralight commands has the following format:\n\n```\n@||\n```\n\nWhere `` 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 : \n\n```\nurn:ngsi-ld:Robot:001@turn|left|30\n```\n\nWill 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\nendpoint 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 manuever\"*.\n\nThe defined Northbound response to an IoT Agent is as follows:\n\n```\nurn:ngsi-ld:Robot:001@turn|Turn ok\n```\n\nWhich is saying *\"I have complied with a request from the entity known as `id=\"urn:ngsi-ld:Robot:001\"` within the Context Broker.\nThe command I have performed was a `turn` command. The result was `Turn ok`\"*\".\n\nAs you can see, because the Southbound command defines the `id` used within the interaction, any response can always be associated to an entity\nheld within the Context Broker.\n\nPush commands can only be used if the device is able to supply a separate endpoint for listening to southbound traffic, an alternative polling mechanism\ncan be used when all interactions are initiated from the device itself, but this is beyond the scope of this tutorial\n\n\n## Northbound Traffic (Measurements)\n\nRequests generated from an IoT device and passed back upwards towards the Context Broker (via an \nIoT agent) are known as northbound traffic. Northbound traffic consists of **measurements** made\nby sensor devices and relays the state of the real world into the context data of the system.\nFor example a measurement from a humidity sensor could be relayed back into the context broker\nto indicate that the moisture level of the entity has changed. A subscription could be made\nto be informed of such changes and there provoke further actions (such as turning on a sprinkler) \n\n\n### Measurement using HTTP GET \n\n\nA device can report new measures to the IoT Platform using an HTTP GET request to a \"well-known\" endpoint\n(the path `/iot/d`) along with the following query parameters:\n\n* `i` (device ID): Device ID (unique for the API Key).\n* `k` (API Key): API Key for the service the device is registered on.\n* `t` (timestamp): Timestamp of the measure. Will override the automatic IoTAgent timestamp (optional).\n* `d` (Data): Ultralight 2.0 payload.\n\nThe `i` and `k` parameters are mandatory.\n\nFor example the request:\n\n```\n/iot/d?i=motion001&d=c|12\n```\n\nWould indicate that the device `id=motion001` wishes to inform the IoT Agent that is has made a real-world measurement `c` with\nthe value `12`. This would eventually be passed up into the Context Broker.\n\n### Measurement using HTTP POST \n\nHTTP POST can also be used. Again the path will be `/iot/d`, but in this case, `d` (Data) is not necessary - \nthe key-value pairs of the measurement are passed as the body of the request. '`i` and `k` query parameters are\nstill mandatory:\n\n* `i` (device ID): Device ID (unique for the API Key).\n* `k` (API Key): API Key for the service the device is registered on.\n* `t` (timestamp): Timestamp of the measure. Will override the automatic IoTAgent timestamp (optional).\n\nOnce again the `i` and `k` parameters are mandatory.\n\n\n#### Device Monitor\n\nFor the purpose of this tutorial, a series of dummy IoT devices have been created, which will eventually be attached to the context broker.\nThe state of each device can be seen on the UltraLight device monitor web-page found at: `http://localhost:3000/device/monitor`\n\n![FIWARE Monitor](https://fiware.github.io/tutorials.IoT-Sensors/img/device-monitor.png)\n\n\n# Architecture\n\nThe demo application will only make use of a single custom component acting as a set of\ndummy IoT devices. Every IoT device will be using the [UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual) protocol running over HTTP.\nSince all interactions are initiated by HTTP requests, the entities can be containerized and run from exposed ports. \n\n![](https://fiware.github.io/tutorials.IoT-Sensors/img/architecture.png)\n\nThe necessary configuration information can be seen in the services section of the associated `docker-compose.yml` file:\n\n```yaml\n context-provider:\n image: quay.io/fiware/cp-web-app:latest\n hostname: context-provider\n container_name: context-provider\n networks:\n - default\n expose:\n - \"3000\"\n - \"3001\"\n ports:\n - \"3000:3000\"\n - \"3001:3001\"\n environment:\n - \"DEBUG=proxy:*\"\n - \"PORT=3000\"\n - \"IOTA_HTTP_HOST=iot-agent\"\n - \"IOTA_HTTP_PORT=7896\"\n - \"DUMMY_DEVICES_PORT=3001\" # Port used by the dummy IOT devices to receive commands\n - \"DUMMY_DEVICES_API_KEY=4jggokgpepnvsb2uv4s40d59ov\"\n```\n\nThe `context-provider` container is listening on two ports: \n\n* Port `3000` is exposed so we can see the web-page displaying the Dummy IoT devices.\n* Port `3001` is exposed purely for tutorial access - so that cUrl or Postman can make UltraLight commands\n without being part of the same network.\n\n\nThe `context-provider` container is driven by environment variables as shown:\n\n| Key |Value|Description|\n|-----|-----|-----------|\n|DEBUG|`proxy:*`| Debug flag used for logging |\n|PORT|`3000`|Port used by web-app which displays the dummy device data |\n|IOTA_HTTP_HOST|`iot-agent`| The host name of the missing IoT Agent - used in a later tutorial | \n|IOTA_HTTP_PORT|`7896` | The port that the missing IoT Agent will be listening on. `7896` is a common default for UltraLight over HTTP |\n|DUMMY_DEVICES_PORT|`3001`|Port used by the dummy IoT devices to receive commands |\n|DUMMY_DEVICES_API_KEY|`4jggokgpepnvsb2uv4s40d59ov`| Random security key used for UltraLight interactions - this will be used in a later tutorial to ensure the integrity of interactions between the devices and the missing IoT Agent |\n\nThe other `context-provider` container configuration values described in the YAML file are not used in this tutorial.\n\nWhen describing the messages being passed through a working smart solution we will refer to two further components which\nare not used in this tutorial, but will be needed to complete the system subsequently.\n\n* The Orion Context Broker server is used for holding the context data of the smart solution. As you know all \n interactions with the context broker must be made using [NGSI](https://swagger.lab.fiware.org/?url=https://raw.githubusercontent.com/Fiware/specifications/master/OpenAPI/ngsiv2/ngsiv2-openapi.json)\n* An IoT Agent acts as a middleware component converting [NGSI](https://swagger.lab.fiware.org/?url=https://raw.githubusercontent.com/Fiware/specifications/master/OpenAPI/ngsiv2/ngsiv2-openapi.json) \n requests (from the context broker) into a protocol \n (such as [UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual))\n usable by the IoT devices themselves.\n\nIt is therefore necessary to understand a sample device protocol first, and comprehend how \nmessages are passed through the system to subsequently understand the purpose of the IoT Agent\nmiddleware. In this tutorial you will be playing the role of an IoT Agent making commands to\ndevices and receiving measurements from them.\n\n\n# Prerequisites\n\n## Docker\n\nTo keep things simple all components will be run using [Docker](https://www.docker.com). **Docker** is a container technology\nwhich allows to different components isolated into their respective environments. \n\n* To install Docker on Windows follow the instructions [here](https://docs.docker.com/docker-for-windows/)\n* To install Docker on Mac follow the instructions [here](https://docs.docker.com/docker-for-mac/)\n* To install Docker on Linux follow the instructions [here](https://docs.docker.com/install/)\n\n**Docker Compose** is a tool for defining and running multi-container Docker applications. A \n[YAML file](https://raw.githubusercontent.com/Fiware/tutorials.Entity-Relationships/master/docker-compose.yml) is used\nconfigure the required services for the application. This means all container sevices can be brought up in a single \ncommmand. Docker Compose is installed by default as part of Docker for Windows and Docker for Mac, however Linux users \nwill need to follow the instructions found [here](https://docs.docker.com/compose/install/)\n\n## Cygwin \n\nWe will start up our services using a simple bash script. Windows users should download [cygwin](http://www.cygwin.com/) to provide a\ncommand line functionality similar to a Linux distribution on Windows. \n\n# Start Up\n\nAll services can be initialised from the command line by running the bash script provided within the repository:\n\n```console\n./services create; ./services start;\n```\n\nThis command will also import seed data from the previous [Stock Management example](https://github.com/Fiware/tutorials.Context-Providers) on startup.\n\n>:information_source: **Note:** If you want to clean up and start over again you can do so with the following command:\n>\n>```console\n>./services stop\n>``` \n>\n\n# Communicating with IoT Devices\n\nTo follow the tutorial correctly please ensure you have the device monitor page available in your browser and click on the page to enable audio\nbefore you enter any cUrl commands. The device monitor displays the current state of an array of dummy devices using Ultralight 2.0 syntax\n\n#### Device Monitor\n\nThe device monitor can be found at: `http://localhost:3000/device/monitor`\n\nWithin this tutorial you will be playing the role of the missing IoT Agent component, \nmaking Southbound commands to the attached IoT devices and receiving Northbound measurements\nas the environment changes within the store. All the commands are made as HTTP POST requests\nusing Ultralight syntax and therefore are very simple. It is worthwhile keeping an eye on the \ndevice monitor page as it shows all the Northbound traffic generated\nby the devices themselves. \n\n\n\n\n", + "description": "This tutorial is an introduction to IoT devices and the usage of the \n[UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual) Protocol for \nconstrained devices. The tutorial introduces a series of dummy IoT devices which are displayed within the browser and\nallows a user to interact with them. A complete understanding of all the terms and concepts defined in this\ntutorial is necessary before proceeding to connect the IoT devices to the Orion Context Broker via a real IoT Agent. \n\nThe `docker-compose` files for this tutorial can be found on GitHub: \n\n![GitHub](https://fiware.github.io/tutorials.Historic-Context/icon/GitHub-Mark-32px.png) [FIWARE 201: Introduction to IoT Sensors](https://github.com/Fiware/tutorials.IoT-Sensors)\n\n\n# What are IoT devices?\n\n> \"All our knowledge begins with the senses.\"\n>\n> — Immanuel Kant (Critique of Pure Reason)\n\nThe [Internet of Things](https://www.linux.com/news/who-needs-internet-things) (IoT) is a network of physical\ndevices which are able to connect to a network and exchange data. Each \"thing\" or \"smart device\" is a gadget\nwith embedded electronics and sofware which can act as a sensor or actuator. Sensors are able to report the\nstate of the real-world around them. Actuators are responsible for altering the state of the system, by responding\nto a control signal.\n\nEach device is uniquely identifiable through its embedded computing system but is able to inter-operate within the\nexisting Internet infrastructure.\n\nFIWARE is a system for managing context information. For a smart solution based on the Internet of Things,\nthe context is provided by the array of attached IoT devices. Since each IoT device is a physical object which\nexists in the real world, it will eventually be represented as a unique entity within the context.\n\nIoT devices can range from simple to complex. Here are some examples of IoT devices which will be used within this tutorial:\n\n* A **Smart Door** is an electronic door which can be sent commands to be locked or unlocked remotely.\n It can also report on its current state (`OPEN`, `CLOSED` or `LOCKED`), \n* A **Bell** can be sent a command to activate and ring for a short period\n* A **Motion Sensor** can be queried to return the number of people who have passed by since it was last reset\n* A **Smart Lamp** can be switched on or off remotely. It can also report on its current state (`ON` or `OFF`).\n When switched on, a motion sensor within the device checks to see if light is is needed and will dim if no-one is nearby.\n Furthermore the device can be report on the current luminocity of the bulb.\n\nAs you can see, the **Bell** is an example of a pure actuator, as it only reacts to the given commands. Meanwhile the \n**Motion Sensor** is an example of a pure sensor, since it will only report on the state of the world as it sees it.\nThe other two devices are able to both respond to commands and report on state in a meaningful way.\n\nThe state information held within each device, as it will eventually be seen within the Context Broker is defined in in the diagram below:\n\n![](https://fiware.github.io/tutorials.IoT-Sensors/img/entities.png)\n\n# What is Ultralight 2.0?\n\n[UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual) is a lightweight text based protocol for constrained devices and communications where\nbandwidth and device memory resources are limited. The payload for measurement requests is\na list of key-value pairs separated by the pipe `|` character. \n\ne.g.\n\n```\n||||| etc..\n```\n\nFor example a payload such as:\n\n```\nt|15|k|abc\n```\n\nContains two attributes, one named \"t\" with value \"15\" and another named \"k\" with value \"abc\" are transmitted. \nValues in Ultralight 2.0 are not typed (everything is treated as a string).\n\nUltralight 2.0 defines a payload describing measures and commands to share between devices and servers but, \ndoes not specify a single transport protocol. Instead, different transport protocol bindings (such as HTTP,\nMQTT and AMQP) can be used for different scenarios. For this tutorial we will be using HTTP as a transport protocol.\n\n## Southbound Traffic (Commands)\n\nHTTP requests generated by the from the Context Broker and passed downwards towards an IoT device (via\nan IoT agent) are known as southbound traffic. Southbound traffic consists of **commands** made to \nactuator devices which alter the state of the real world by their actions. For example a command\nto alter the state of a lamp to `ON` would switch on the lamp in real life. This in turn could alter\nthe readings of other sensors nearby.\n\n### Push Command using HTTP POST \n\n\nSetting up the southbound communication between an IoT Agent and IoT devices is known as provisioning.\nThis ensures that the IoT Agent holds sufficient information to be able to contact each IoT device.\nIn other words it knows where to send commands and which commands are supported. In order to send a\ncommand to a device, the IoT Agent sends a POST request to the endpoint supplied by the device. The body of the POST request holds the command.\n\nThe payload for Ultralight commands has the following format:\n\n```\n@||\n```\n\nWhere `` 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 : \n\n```\nurn:ngsi-ld:Robot:001@turn|left|30\n```\n\nWill 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\nendpoint 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 manuever\"*.\n\nThe defined Northbound response to an IoT Agent is as follows:\n\n```\nurn:ngsi-ld:Robot:001@turn|Turn ok\n```\n\nWhich is saying *\"I have complied with a request from the entity known as `id=\"urn:ngsi-ld:Robot:001\"` within the Context Broker.\nThe command I have performed was a `turn` command. The result was `Turn ok`\"*\".\n\nAs you can see, because the Southbound command defines the `id` used within the interaction, any response can always be associated to an entity\nheld within the Context Broker.\n\nPush commands can only be used if the device is able to supply a separate endpoint for listening to southbound traffic, an alternative polling mechanism\ncan be used when all interactions are initiated from the device itself, but this is beyond the scope of this tutorial\n\n\n## Northbound Traffic (Measurements)\n\nRequests generated from an IoT device and passed back upwards towards the Context Broker (via an \nIoT agent) are known as northbound traffic. Northbound traffic consists of **measurements** made\nby sensor devices and relays the state of the real world into the context data of the system.\nFor example a measurement from a humidity sensor could be relayed back into the context broker\nto indicate that the moisture level of the entity has changed. A subscription could be made\nto be informed of such changes and there provoke further actions (such as turning on a sprinkler) \n\n\n### Measurement using HTTP GET \n\n\nA device can report new measures to the IoT Platform using an HTTP GET request to a \"well-known\" endpoint\n(the path `/iot/d`) along with the following query parameters:\n\n* `i` (device ID): Device ID (unique for the API Key).\n* `k` (API Key): API Key for the service the device is registered on.\n* `t` (timestamp): Timestamp of the measure. Will override the automatic IoTAgent timestamp (optional).\n* `d` (Data): Ultralight 2.0 payload.\n\nThe `i` and `k` parameters are mandatory.\n\nFor example the request:\n\n```\n/iot/d?i=motion001&d=c|12\n```\n\nWould indicate that the device `id=motion001` wishes to inform the IoT Agent that is has made a real-world measurement `c` with\nthe value `12`. This would eventually be passed up into the Context Broker.\n\n### Measurement using HTTP POST \n\nHTTP POST can also be used. Again the path will be `/iot/d`, but in this case, `d` (Data) is not necessary - \nthe key-value pairs of the measurement are passed as the body of the request. '`i` and `k` query parameters are\nstill mandatory:\n\n* `i` (device ID): Device ID (unique for the API Key).\n* `k` (API Key): API Key for the service the device is registered on.\n* `t` (timestamp): Timestamp of the measure. Will override the automatic IoTAgent timestamp (optional).\n\nOnce again the `i` and `k` parameters are mandatory.\n\n\n#### Device Monitor\n\nFor the purpose of this tutorial, a series of dummy IoT devices have been created, which will eventually be attached to the context broker.\nThe state of each device can be seen on the UltraLight device monitor web-page found at: `http://localhost:3000/device/monitor`\n\n![FIWARE Monitor](https://fiware.github.io/tutorials.IoT-Sensors/img/device-monitor.png)\n\n\n# Architecture\n\nThe demo application will only make use of a single custom component acting as a set of\ndummy IoT devices. Every IoT device will be using the [UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual) protocol running over HTTP.\nSince all interactions are initiated by HTTP requests, the entities can be containerized and run from exposed ports. \n\n![](https://fiware.github.io/tutorials.IoT-Sensors/img/architecture.png)\n\nThe necessary configuration information can be seen in the services section of the associated `docker-compose.yml` file:\n\n```yaml\n context-provider:\n image: quay.io/fiware/cp-web-app:latest\n hostname: context-provider\n container_name: context-provider\n networks:\n - default\n expose:\n - \"3000\"\n - \"3001\"\n ports:\n - \"3000:3000\"\n - \"3001:3001\"\n environment:\n - \"DEBUG=proxy:*\"\n - \"PORT=3000\"\n - \"IOTA_HTTP_HOST=iot-agent\"\n - \"IOTA_HTTP_PORT=7896\"\n - \"DUMMY_DEVICES_PORT=3001\" # Port used by the dummy IOT devices to receive commands\n - \"DUMMY_DEVICES_API_KEY=4jggokgpepnvsb2uv4s40d59ov\"\n```\n\nThe `context-provider` container is listening on two ports: \n\n* Port `3000` is exposed so we can see the web-page displaying the Dummy IoT devices.\n* Port `3001` is exposed purely for tutorial access - so that cUrl or Postman can make UltraLight commands\n without being part of the same network.\n\n\nThe `context-provider` container is driven by environment variables as shown:\n\n| Key |Value|Description|\n|-----|-----|-----------|\n|DEBUG|`proxy:*`| Debug flag used for logging |\n|PORT|`3000`|Port used by web-app which displays the dummy device data |\n|IOTA_HTTP_HOST|`iot-agent`| The host name of the missing IoT Agent - used in a later tutorial | \n|IOTA_HTTP_PORT|`7896` | The port that the missing IoT Agent will be listening on. `7896` is a common default for UltraLight over HTTP |\n|DUMMY_DEVICES_PORT|`3001`|Port used by the dummy IoT devices to receive commands |\n|DUMMY_DEVICES_API_KEY|`4jggokgpepnvsb2uv4s40d59ov`| Random security key used for UltraLight interactions - this will be used in a later tutorial to ensure the integrity of interactions between the devices and the missing IoT Agent |\n\nThe other `context-provider` container configuration values described in the YAML file are not used in this tutorial.\n\nWhen describing the messages being passed through a working smart solution we will refer to two further components which\nare not used in this tutorial, but will be needed to complete the system subsequently.\n\n* The Orion Context Broker server is used for holding the context data of the smart solution. As you know all \n interactions with the context broker must be made using [NGSI](https://swagger.lab.fiware.org/?url=https://raw.githubusercontent.com/Fiware/specifications/master/OpenAPI/ngsiv2/ngsiv2-openapi.json)\n* An IoT Agent acts as a middleware component converting [NGSI](https://swagger.lab.fiware.org/?url=https://raw.githubusercontent.com/Fiware/specifications/master/OpenAPI/ngsiv2/ngsiv2-openapi.json) \n requests (from the context broker) into a protocol \n (such as [UltraLight 2.0](http://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual))\n usable by the IoT devices themselves.\n\nIt is therefore necessary to understand a sample device protocol first, and comprehend how \nmessages are passed through the system to subsequently understand the purpose of the IoT Agent\nmiddleware. In this tutorial you will be playing the role of an IoT Agent making commands to\ndevices and receiving measurements from them.\n\n\n# Prerequisites\n\n## Docker\n\nTo keep things simple all components will be run using [Docker](https://www.docker.com). **Docker** is a container technology\nwhich allows to different components isolated into their respective environments. \n\n* To install Docker on Windows follow the instructions [here](https://docs.docker.com/docker-for-windows/)\n* To install Docker on Mac follow the instructions [here](https://docs.docker.com/docker-for-mac/)\n* To install Docker on Linux follow the instructions [here](https://docs.docker.com/install/)\n\n**Docker Compose** is a tool for defining and running multi-container Docker applications. A \n[YAML file](https://raw.githubusercontent.com/Fiware/tutorials.Entity-Relationships/master/docker-compose.yml) is used\nconfigure the required services for the application. This means all container sevices can be brought up in a single \ncommmand. Docker Compose is installed by default as part of Docker for Windows and Docker for Mac, however Linux users \nwill need to follow the instructions found [here](https://docs.docker.com/compose/install/)\n\n## WSL \n\nWe will start up our services using a simple bash script. Windows users should download the [Windows Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install) to provide a\ncommand line functionality similar to a Linux distribution on Windows. \n\n# Start Up\n\nAll services can be initialised from the command line by running the bash script provided within the repository:\n\n```console\n./services create; ./services start;\n```\n\nThis command will also import seed data from the previous [Stock Management example](https://github.com/Fiware/tutorials.Context-Providers) on startup.\n\n>:information_source: **Note:** If you want to clean up and start over again you can do so with the following command:\n>\n>```console\n>./services stop\n>``` \n>\n\n# Communicating with IoT Devices\n\nTo follow the tutorial correctly please ensure you have the device monitor page available in your browser and click on the page to enable audio\nbefore you enter any cUrl commands. The device monitor displays the current state of an array of dummy devices using Ultralight 2.0 syntax\n\n#### Device Monitor\n\nThe device monitor can be found at: `http://localhost:3000/device/monitor`\n\nWithin this tutorial you will be playing the role of the missing IoT Agent component, \nmaking Southbound commands to the attached IoT devices and receiving Northbound measurements\nas the environment changes within the store. All the commands are made as HTTP POST requests\nusing Ultralight syntax and therefore are very simple. It is worthwhile keeping an eye on the \ndevice monitor page as it shows all the Northbound traffic generated\nby the devices themselves. \n\n\n\n\n", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" }, "item": [ diff --git a/README.es.md b/README.es.md index ae903ce..4120969 100644 --- a/README.es.md +++ b/README.es.md @@ -42,7 +42,7 @@ A lo largo de este tutorial se usan comandos [cUrl](https://ec.haxx.se/), pero t - [Arquitectura](#arquitectura) - [Prerequisitos](#prerequisitos) - [Docker](#docker) - - [Cygwin](#cygwin) + - [WSL](#wsl) - [Inicio](#inicio) - [Comunicando con los dispositivos IoT](#comunicando-con-los-dispositivos-iot) - [Comandos de campana](#comandos-de-campana) @@ -253,9 +253,9 @@ docker version Por favor, asegúrese de que está utilizando la versión 18.03 o superior de Docker y la versión 1.21 o superior de Docker Compose y actualícela si es necesario. -## Cygwin +## WSL -Comenzaremos nuestros servicios usando una simple consola de comando - o bash script. Los usuarios de Windows deben descargar [cygwin](http://www.cygwin.com/) para proporcionar una funcionalidad de línea de comandos similar a la de una distribución de Linux en Windows. +Comenzaremos nuestros servicios usando una simple consola de comando - o bash script. Los usuarios de Windows deben descargar the [Windows Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install) para proporcionar una funcionalidad de línea de comandos similar a la de una distribución de Linux en Windows. # Inicio diff --git a/README.ja.md b/README.ja.md index 5824c40..30789e9 100644 --- a/README.ja.md +++ b/README.ja.md @@ -40,7 +40,7 @@ Context Broker に接続する前に、このチュートリアルで定義さ - [アーキテクチャ](#architecture) - [前提条件](#prerequisites) - [Docker](#docker) - - [Cygwin](#cygwin) + - [WSL](#wsl) - [起動](#start-up) - [IoT デバイスとの通信](#communicating-with-iot-devices) - [ベル・コマンド](#bell-commands) @@ -379,12 +379,10 @@ docker version Docker バージョン 20.10 以降と Docker Compose 1.29 以上を使用していることを確認 し、必要に応じてアップグレードしてください。 - - -## Cygwin +## WSL シンプルな bash スクリプトを使用してサービスを開始します。Windows ユーザは -[cygwin](http://www.cygwin.com/) をダウンロードして、Windows 上の Linux ディスト +[を使用して Windows に Linux をインストールする方法](https://learn.microsoft.com/ja-jp/windows/wsl/install) をダウンロードして、Windows 上の Linux ディスト リビューションと同様のコマンドライン機能を提供する必要があります。 diff --git a/README.md b/README.md index 95347a9..3a57cdb 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,7 @@ The tutorial uses [cUrl](https://ec.haxx.se/) commands throughout, but is also a - [Architecture](#architecture) - [Prerequisites](#prerequisites) - [Docker](#docker) - - [Cygwin](#cygwin) + - [WSL](#wsl) - [Start Up](#start-up) - [Communicating with IoT Devices](#communicating-with-iot-devices) - [Bell Commands](#bell-commands) @@ -312,10 +312,11 @@ docker version Please ensure that you are using Docker version 20.10 or higher and Docker Compose 1.29 or higher and upgrade if necessary. -## Cygwin +## WSL -We will start up our services using a simple bash script. Windows users should download [cygwin](http://www.cygwin.com/) -to provide a command-line functionality similar to a Linux distribution on Windows. +We will start up our services using a simple bash script. Windows users should download the +[Windows Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install) to provide a command-line +functionality similar to a Linux distribution on Windows. # Start Up