Change telemetry to sensor

Author: PatAltimore

articles/iot-operations/connect-to-cloud/howto-configure-kafka-endpoint.md

@@ -6,7 +6,7 @@ ms.author: patricka
 ms.service: azure-iot-operations
 ms.subservice: azure-data-flows
 ms.topic: how-to
-ms.date: 04/03/2025
+ms.date: 05/21/2025
 ai-usage: ai-assisted
 
 #CustomerIntent: As an operator, I want to understand how to configure data flow endpoints for Kafka in Azure IoT Operations so that I can send data to and from Kafka endpoints.
@@ -1027,7 +1027,7 @@ CloudEvent properties are passed through for messages that contain the required
 | `type`            | Yes      | `ms.aio.telemetry`                                     | `ce-type`            | Passed through as is                                                        |
 | `source`          | Yes      | `aio://mycluster/myoven`                               | `ce-source`          | Passed through as is                                                        |
 | `id`              | Yes      | `A234-1234-1234`                                       | `ce-id`              | Passed through as is                                                        |
-| `subject`         | No       | `aio/myoven/telemetry/temperature`                     | `ce-subject`         | Passed through as is                                                        |
+| `subject`         | No       | `aio/myoven/sensor/temperature`                     | `ce-subject`         | Passed through as is                                                        |
 | `time`            | No       | `2018-04-05T17:31:00Z`                                 | `ce-time`            | Passed through as is. It's not restamped.                                   |
 | `datacontenttype` | No       | `application/json`                                     | `ce-datacontenttype` | Changed to the output data content type after the optional transform stage. |
 | `dataschema`      | No       | `sr://fabrikam-schemas/123123123234234234234234#1.0.0` | `ce-dataschema`      | If an output data transformation schema is given in the transformation configuration, `dataschema` is changed to the output schema.  |

articles/iot-operations/connect-to-cloud/howto-configure-mqtt-endpoint.md

@@ -6,7 +6,7 @@ ms.author: patricka
 ms.service: azure-iot-operations
 ms.subservice: azure-data-flows
 ms.topic: how-to
-ms.date: 04/03/2025
+ms.date: 05/21/2025
 ai-usage: ai-assisted
 
 #CustomerIntent: As an operator, I want to understand how to understand how to configure data flow endpoints for MQTT sources and destinations in Azure IoT Operations so that I can send data to and from MQTT brokers.
@@ -1017,7 +1017,7 @@ CloudEvent properties are passed through for messages that contain the required
 | `type`            | Yes      | `ms.aio.telemetry`                                     | Passed through as is                                                                                    |
 | `source`          | Yes      | `aio://mycluster/myoven`                               | Passed through as is                                                                                    |
 | `id`              | Yes      | `A234-1234-1234`                                       | Passed through as is                                                                                    |
-| `subject`         | No       | `aio/myoven/telemetry/temperature`                     | Passed through as is                                                                                    |
+| `subject`         | No       | `aio/myoven/sensor/temperature`                     | Passed through as is                                                                                    |
 | `time`            | No       | `2018-04-05T17:31:00Z`                                 | Passed through as is. It's not restamped. |
 | `datacontenttype` | No       | `application/json`                                     | Changed to the output data content type after the optional transform stage.                             |
 | `dataschema`      | No       | `sr://fabrikam-schemas/123123123234234234234234#1.0.0` | If an output data transformation schema is given in the transformation configuration, `dataschema` is changed to the output schema.         |

articles/iot-operations/connect-to-cloud/howto-create-dataflow.md

@@ -209,8 +209,8 @@ The message broker endpoint is configured in the Bicep file. For example, the fo
 sourceSettings: {
   endpointRef: 'default'
   dataSources: [
-    'thermostats/+/telemetry/temperature/#'
-    'humidifiers/+/telemetry/humidity/#'
+    'thermostats/+/sensor/temperature/#'
+    'humidifiers/+/sensor/humidity/#'
   ]
 }
 ```
@@ -225,8 +225,8 @@ For example, to configure a source using a message broker endpoint and two topic
 sourceSettings:
   endpointRef: default
   dataSources:
-    - thermostats/+/telemetry/temperature/#
-    - humidifiers/+/telemetry/humidity/#
+    - thermostats/+/sensor/temperature/#
+    - humidifiers/+/sensor/humidity/#
 ```
 
 Because `dataSources` allows you to specify MQTT or Kafka topics without modifying the endpoint configuration, you can reuse the endpoint for multiple data flows even if the topics are different. To learn more, see [Configure data sources](#configure-data-sources-mqtt-or-kafka-topics).
@@ -319,7 +319,7 @@ You can specify multiple MQTT or Kafka topics in a source without needing to mod
 
 #### MQTT topics
 
-When the source is an MQTT (Event Grid included) endpoint, you can use the MQTT topic filter to subscribe to incoming messages. The topic filter can include wildcards to subscribe to multiple topics. For example, `thermostats/+/telemetry/temperature/#` subscribes to all temperature telemetry messages from thermostats. To configure the MQTT topic filters:
+When the source is an MQTT (Event Grid included) endpoint, you can use the MQTT topic filter to subscribe to incoming messages. The topic filter can include wildcards to subscribe to multiple topics. For example, `thermostats/+/sensor/temperature/#` subscribes to all temperature sensor messages from thermostats. To configure the MQTT topic filters:
 
 # [Operations experience](#tab/portal)
 
@@ -344,13 +344,13 @@ Example with multiple MQTT topic filters with wildcards:
 sourceSettings: {
   endpointRef: 'default'
   dataSources: [
-    'thermostats/+/telemetry/temperature/#'
-    'humidifiers/+/telemetry/humidity/#'
+    'thermostats/+/sensor/temperature/#'
+    'humidifiers/+/sensor/humidity/#'
   ]
 }
 ```
 
-Here, the wildcard `+` is used to select all devices under the `thermostats` and `humidifiers` topics. The `#` wildcard is used to select all telemetry messages under all subtopics of the `temperature` and `humidity` topics.
+Here, the wildcard `+` is used to select all devices under the `thermostats` and `humidifiers` topics. The `#` wildcard is used to select all sensor messages under all subtopics of the `temperature` and `humidity` topics.
 
 # [Kubernetes (preview)](#tab/kubernetes)
 
@@ -369,11 +369,11 @@ Example with multiple topic filters with wildcards:
 sourceSettings:
   endpointRef: default
   dataSources:
-    - thermostats/+/telemetry/temperature/#
-    - humidifiers/+/telemetry/humidity/#
+    - thermostats/+/sensor/temperature/#
+    - humidifiers/+/sensor/humidity/#
 ```
 
-Here, the wildcard `+` is used to select all devices under the `thermostats` and `humidifiers` topics. The `#` wildcard is used to select all telemetry messages under all subtopics of the `temperature` and `humidity` topics.
+Here, the wildcard `+` is used to select all devices under the `thermostats` and `humidifiers` topics. The `#` wildcard is used to select all messages under all subtopics of the `temperature` and `humidity` topics.
 
 ---
 

articles/iot-operations/connect-to-cloud/overview-dataflow.md

@@ -6,7 +6,7 @@ ms.author: patricka
 ms.service: azure-iot-operations
 ms.subservice: azure-data-flows
 ms.topic: conceptual
-ms.date: 03/17/2025
+ms.date: 05/21/2025
 
 #CustomerIntent: As an operator, I want to understand how I can use data flows to connect data sources.
 ---
@@ -74,6 +74,6 @@ The local MQTT broker message queue is stored in memory by default. You can conf
 
 ## Related content
 
-- [Tutorial: Send asset telemetry to the cloud by using a data flow](../end-to-end-tutorials/tutorial-upload-messages-to-cloud.md)
+- [Tutorial: Send messages from assets to the cloud using a data flow](../end-to-end-tutorials/tutorial-upload-messages-to-cloud.md)
 - [Create a data flow](howto-create-dataflow.md)
 - [Create a data flow endpoint](howto-configure-dataflow-endpoint.md)

articles/iot-operations/connect-to-cloud/tutorial-mqtt-bridge.md

@@ -6,7 +6,7 @@ ms.author: patricka
 ms.service: azure-iot-operations
 ms.subservice: azure-data-flows
 ms.topic: tutorial
-ms.date: 01/08/2025
+ms.date: 05/21/2025
 
 #CustomerIntent: As an operator, I want to understand how to create a bi-directional MQTT bridge to Azure Event Grid so that I can send and receive messages between devices and services.
 ---
@@ -115,7 +115,7 @@ The max client sessions option allows Azure IoT Operations MQTT to spawn multipl
 
 ## Create a topic space
 
-In the Event Grid namespace, create a topic space named `tutorial` with a topic template `telemetry/#`.
+In the Event Grid namespace, create a topic space named `tutorial` with a topic template `sensor/#`.
 
 # [Bash](#tab/bash)
 
@@ -124,7 +124,7 @@ az eventgrid namespace topic-space create \
   --resource-group $RESOURCE_GROUP \
   --namespace-name $EVENT_GRID_NAMESPACE \
   --name tutorial \
-  --topic-templates "telemetry/#"
+  --topic-templates "sensor/#"
 ```
 
 # [PowerShell](#tab/powershell)
@@ -134,12 +134,12 @@ az eventgrid namespace topic-space create `
   --resource-group $RESOURCE_GROUP `
   --namespace-name $EVENT_GRID_NAMESPACE `
   --name tutorial `
-  --topic-templates "telemetry/#"
+  --topic-templates "sensor/#"
 ```
 
 ---
 
-By using the `#` wildcard in the topic template, you can publish to any topic under the `telemetry` topic space. For example, `telemetry/temperature` or `telemetry/humidity`.
+By using the `#` wildcard in the topic template, you can publish to any topic under the `sensor` topic space. For example, `sensor/temperature` or `sensor/humidity`.
 
 ## Give Azure IoT Operations access to the Event Grid topic space
 
@@ -392,7 +392,7 @@ resource dataflow_1 'Microsoft.IoTOperations/instances/dataflowProfiles/dataflow
         operationType: 'Destination'
         destinationSettings: {
           endpointRef: 'eventgrid'
-          dataDestination: 'telemetry/aio'
+          dataDestination: 'sensor/aio'
         }
       }
     ]
@@ -413,7 +413,7 @@ resource dataflow_2 'Microsoft.IoTOperations/instances/dataflowProfiles/dataflow
         sourceSettings: {
           endpointRef: 'eventgrid'
           serializationFormat: 'Json'
-          dataSources: array('telemetry/#')
+          dataSources: array('sensor/#')
         }
       }
       {
@@ -472,7 +472,7 @@ spec:
   - operationType: Destination
     destinationSettings:
       endpointRef: eventgrid
-      dataDestination: telemetry/aio
+      dataDestination: sensor/aio
 ---
 apiVersion: connectivity.iotoperations.azure.com/v1
 kind: Dataflow
@@ -486,7 +486,7 @@ spec:
     sourceSettings:
       endpointRef: eventgrid
       dataSources:
-        - telemetry/#
+        - sensor/#
   - operationType: Destination
     destinationSettings:
       endpointRef: default
@@ -502,13 +502,13 @@ Together, the two data flows form an MQTT bridge, where you:
 * Use TLS for both remote and local brokers
 * Use system-assigned managed identity for authentication to the remote broker
 * Use Kubernetes service account for authentication to the local broker
-* Use the topic map to map the `tutorial/local` topic to the `telemetry/aio` topic on the remote broker
-* Use the topic map to map the `telemetry/#` topic on the remote broker to the `tutorial/cloud` topic on the local broker
+* Use the topic map to map the `tutorial/local` topic to the `sensor/aio` topic on the remote broker
+* Use the topic map to map the `sensor/#` topic on the remote broker to the `tutorial/cloud` topic on the local broker
 
 > [!NOTE]
 > By default, Azure IoT Operations deploys an MQTT broker as well as an MQTT broker data flow endpoint. The MQTT broker data flow endpoint is used to connect to the MQTT broker. The default configuration uses the built-in service account token for authentication. The endpoint is named `default` and is available in the same namespace as Azure IoT Operations. The endpoint is used as the source for the data flow created in this tutorial. To learn more about the default MQTT broker data flow endpoint, see [Azure IoT Operations local MQTT broker default endpoint](../connect-to-cloud/howto-configure-mqtt-endpoint.md#default-endpoint).
 
-When you publish to the `tutorial/local` topic on the local Azure IoT Operations MQTT broker, the message is bridged to the `telemetry/aio` topic on the remote Event Grid MQTT broker. Then, the message is bridged back to the `tutorial/cloud` topic (because the `telemetry/#` wildcard topic captures it) on the local Azure IoT Operations MQTT broker. Similarly, when you publish to the `telemetry/aio` topic on the remote Event Grid MQTT broker, the message is bridged to the `tutorial/cloud` topic on the local Azure IoT Operations MQTT broker.
+When you publish to the `tutorial/local` topic on the local Azure IoT Operations MQTT broker, the message is bridged to the `sensor/aio` topic on the remote Event Grid MQTT broker. Then, the message is bridged back to the `tutorial/cloud` topic (because the `sensor/#` wildcard topic captures it) on the local Azure IoT Operations MQTT broker. Similarly, when you publish to the `sensor/aio` topic on the remote Event Grid MQTT broker, the message is bridged to the `tutorial/cloud` topic on the local Azure IoT Operations MQTT broker.
 
 ## Deploy MQTT client
 
@@ -621,7 +621,7 @@ You can also check the Event Grid metrics to verify the messages are delivered t
 
 In this tutorial, you learned how to configure Azure IoT Operations for bi-directional MQTT bridge with Azure Event Grid MQTT broker. As next steps, explore the following scenarios:
 
-* To use an MQTT client to publish messages directly to the Event Grid MQTT broker, see [Publish MQTT messages to Event Grid MQTT broker](../../event-grid/mqtt-publish-and-subscribe-cli.md). Give the client a [publisher permission binding](../../event-grid/mqtt-access-control.md) to the topic space you created, and you can publish messages to any topic under the `telemetry`, like `telemetry/temperature` or `telemetry/humidity`. All of these messages are bridged to the `tutorial/cloud` topic on the local Azure IoT Operations broker.
+* To use an MQTT client to publish messages directly to the Event Grid MQTT broker, see [Publish MQTT messages to Event Grid MQTT broker](../../event-grid/mqtt-publish-and-subscribe-cli.md). Give the client a [publisher permission binding](../../event-grid/mqtt-access-control.md) to the topic space you created, and you can publish messages to any topic under the `sensor`, like `sensor/temperature` or `sensor/humidity`. All of these messages are bridged to the `tutorial/cloud` topic on the local Azure IoT Operations broker.
 * To set up routing rules for the Event Grid MQTT broker, see [Configure routing rules for Event Grid MQTT broker](../../event-grid/mqtt-routing.md). You can use routing rules to route messages to different topics based on the topic name, or to filter messages based on the message content.
 
 ## Related content

articles/iot-operations/manage-mqtt-broker/howto-broker-diagnostics.md

@@ -42,7 +42,7 @@ The diagnostics probe regularly runs MQTT operations (PING, CONNECT, PUBLISH, SU
 > [!IMPORTANT]
 > The self-check diagnostics probe publishes messages to the `azedge/dmqtt/selftest` topic. Don't publish or subscribe to diagnostic probe topics that start with `azedge/dmqtt/selftest`. Publishing or subscribing to these topics can affect the probe or self-test checks and result in invalid results. Invalid results can be listed in diagnostic probe logs, metrics, or dashboards. For example, you might see the issue "Path verification failed for probe event with operation type 'Publish'" in the diagnostics-probe logs. For more information, see [Known issues](../troubleshoot/known-issues.md#mqtt-broker-issues).
 >
-> Even though the MQTT broker's [diagnostics](../manage-mqtt-broker/howto-broker-diagnostics.md) produces telemetry on its own topic, you can still get messages from the self-test when you subscribe to the `#` topic. This is a limitation and expected behavior.
+> Even though the MQTT broker's [diagnostics](../manage-mqtt-broker/howto-broker-diagnostics.md) produces diagnostics messages on its own topic, you can still get messages from the self-test when you subscribe to the `#` topic. This is a limitation and expected behavior.
 
 ## Change diagnostics settings