@@ -347,6 +347,7 @@ repository:
347
347
` ` `
348
348
349
349
> [!NOTE]
350
+ >
350
351
> If you want to clean up and start over again you can do so with the following command:
351
352
>
352
353
> ```console
@@ -386,8 +387,9 @@ docker run -it --rm --name mqtt-subscriber \
386
387
The terminal will then be ready to receive events
387
388
388
389
> [!NOTE]
389
- > There is no change on whilst running this command. The on screen output will only respond once you have
390
- > completed the next step.
390
+ >
391
+ > There is no change on whilst running this command. The on screen output will only respond once you have completed the
392
+ > next step.
391
393
392
394
# ## Start an MQTT Publisher (2️⃣nd Terminal)
393
395
@@ -531,7 +533,8 @@ This example provisions an anonymous group of devices. It tells the IoT Agent th
531
533
communicating by sending device measures over the `/ul/4jggokgpepnvsb2uv4s40d59ov` **topic**
532
534
533
535
> [! NOTE]
534
- > Measures and commands are sent over different MQTT topics:
536
+ >
537
+ > Measures and commands are sent over different MQTT topics:
535
538
>
536
539
> - _Measures_ are sent on the ` /< protocol> /< api-key> /< device-id> /attrs` topic
537
540
> - _Commands_ are sent on the ` /< api-key> /< device-id> /cmd` topic
@@ -583,8 +586,9 @@ Three types of measurement attributes can be provisioned:
583
586
context broker.
584
587
585
588
> [ !NOTE]
586
- > in the case where individual ` id ` s are not required, or aggregated data is sufficient the ` attributes ` can
587
- > be defined within the provisioning service rather than individually.
589
+ >
590
+ > in the case where individual ` id ` s are not required, or aggregated data is sufficient the ` attributes ` can be defined
591
+ > within the provisioning service rather than individually.
588
592
589
593
#### 3️⃣ Request:
590
594
@@ -643,9 +647,10 @@ The **topic** must be in the following form:
643
647
```
644
648
645
649
> [ !NOTE]
646
- > In the [ previous tutorial] ( https://github.com/FIWARE/tutorials.IoT-Agent ) , when testing HTTP connectivity
647
- > between the Motion Sensor and an IoT Agent, a similar dummy HTTP request was sent to update the ` count ` value. This
648
- > time the IoT Agent is configured to listen to MQTT topics, and we need to post a dummy message to an MQTT topic.
650
+ >
651
+ > In the [ previous tutorial] ( https://github.com/FIWARE/tutorials.IoT-Agent ) , when testing HTTP connectivity between the
652
+ > Motion Sensor and an IoT Agent, a similar dummy HTTP request was sent to update the ` count ` value. This time the IoT
653
+ > Agent is configured to listen to MQTT topics, and we need to post a dummy message to an MQTT topic.
649
654
650
655
When using the MQTT transport protocol, the IoT Agent is subscribing to the MQTT ** topics** and the device monitor will
651
656
be configured to display all MQTT ** messages** sent to each ** topic** - effectively it is showing the list messages
@@ -744,7 +749,7 @@ REST request directly to the IoT Agent's North Port using the `/v2/op/update` en
744
749
eventually be invoked by the context broker once we have connected it up. To test the configuration you can run the
745
750
command directly as shown:
746
751
747
- #### 7️⃣ Request:
752
+ #### 7️⃣ Request:
748
753
749
754
``` console
750
755
curl -iX POST \
@@ -773,7 +778,7 @@ If you are viewing the device monitor page, you can also see the state of the be
773
778
774
779
The result of the command to ring the bell can be read by querying the entity within the Orion Context Broker.
775
780
776
- #### 8️⃣ Request:
781
+ #### 8️⃣ Request:
777
782
778
783
``` console
779
784
curl -X GET \
0 commit comments