Possible Reason 1: Incorrect Device Twin Configuration
Question
You are building an industrial IoT solution where, using several S1 IoT hubs, you collect telemetry data from a number of field sensors.
The data collected by the IoT hubs must be forwarded to a Blob Storage container.
In addition, each message needs to be stamped with the name of the IoT hub and the location of the device.
In order to add this data to your messages, you use the following CLI statements to create enrichments:
az iot hub message-enrichment create --key myIotHub --value $iothubname --endpoints EnrichedSensorData az iot hub message-enrichment create --key DeviceLocation --value $twin.tags.location --endpoints EnrichedSensorDataDuring the tests runs with multiple devices connected, you see that the size of the messages is around 2 kB, most of them are enriched as expected and stamped with the hub name and the device location, but messages from one of the sensors contain the "$twin.tags.location" string instead of the actual location.
What are the two possible reasons for that?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D. E.Correct Answers: B and D.
Option A is incorrect because the size of the message has no effect on the values added by the enrichments.
Option B is CORRECT because if, for some reason, the sensor doesn't have a device twin, the twin tag property doesn't exist.
Option C is incorrect because IoT hubs in the Standard (S1, S2, S3) tier all support device twins.
This can't be the problem.
Option D is CORRECT because if there is no “location” property under the “tags”, it will result in stamping the string instead of the value of the property.
Option E is incorrect because message enrichment is available for all IoT hubs, regardless of their tier.
References:
Based on the scenario provided, there are two possible reasons why the messages from one of the sensors contain the "$twin.tags.location" string instead of the actual location:
The sensor sending the message has no device twin: The enrichment being applied to the messages is based on the device twin tags. Device twin is a JSON document that stores device metadata and configuration information. The device twin can be used to store additional information about the device, such as its location. If the sensor sending the message does not have a device twin associated with it, then the message enrichment will not be able to add the device location to the message. As a result, the message will contain the "$twin.tags.location" string instead of the actual location.
The device twin does not have a "location" tag: Another reason why the messages from one of the sensors contain the "$twin.tags.location" string instead of the actual location is if the device twin associated with the sensor does not have a "location" tag. The message enrichment is specifically looking for the "location" tag in the device twin to add the device location to the message. If the device twin does not have this tag, the message enrichment will not be able to add the device location to the message. As a result, the message will contain the "$twin.tags.location" string instead of the actual location.
It is worth noting that the other options provided in the answer choices (A, C, and E) are not related to the issue described in the scenario. The size of the messages being around 2 kB does not exceed the limit for IoT Hub message size, so it is unlikely that the issue is due to oversized messages. The IoT Hub tier being S1 is also not related to the issue, as there are no known limitations with message enrichment in the S1 tier. Additionally, message enrichment by the sensor's IoT hub is supported, as evidenced by the fact that most messages are being enriched as expected.
