Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relationship Properties on twins #135

Open
sourabhkrishna opened this issue Oct 20, 2022 · 4 comments
Open

Relationship Properties on twins #135

sourabhkrishna opened this issue Oct 20, 2022 · 4 comments

Comments

@sourabhkrishna
Copy link

I've below sample models one for the base device and its relationship, the relationships are provisioned as modules of the device. The relationship has a boolean property "activated" defined. The question is where would this property reside? on the device twin or module twin?

{
    "@id": "dtmi:com:testdevice;1",
    "@type": "Interface",
    "@context": "dtmi:dtdl:context;2",
    "displayName": "Base Device",
    "contents": [
      {
        "@type": "Property",
        "name": "id",
        "schema": "string"     
      },    
      {
        "@type": "Relationship",
        "@id": "dtmi:com:hasrelationship;1",
        "name": "hasrelationship",
        "displayName": "Test Device has Relationship",
        "target": "dtmi:com:testrelationship;1",
        "properties": [
            {
              "@type": "Property",
              "name": "activated",
              "schema": "boolean"
            }
          ]
      }
    ]
  }

{
    "@id": "dtmi:com:testrelationship;1",
    "@type": "Interface",
    "@context": "dtmi:dtdl:context;2",
    "displayName": "Relationship",
    "contents": [
      {
        "@type": "Property",
        "name": "id",
        "schema": "string"     
      }
    ]
  }
@rido-min
Copy link
Member

Hi @sourabhkrishna

DTDL properties can be used to describe device twins or module twins. However, the language itself, neither the IoT Plug and Play conventions have any construct to express the connection between device twins and module twins.

From IoT Hub perspective, these are two complete unrelated entities, you can model a connection between the two with DTDL relationships, in that case is up to you to describe the module model id in the relationtship or in the module twin.

I'd love to better understand your use case related to modules to provide better guidance.

@sourabhkrishna
Copy link
Author

sourabhkrishna commented Oct 21, 2022

@rido-min Our use case for using the module twins is for the Azure Device Update feature as this mandates the device to publish a particular pnp modelId whereas our devices have their own pnp modelId, so in order to separate the firmware update model from the base device model we use module identities for ADU and device identities for the actual device. This 1:1 relationship is described in the DTDL below. However our FW ran into issues while maintaining multiple MQTT connections to IoTHub (one for the device and another for the module), so I'm looking for options wherein if the module twin was updated then the relationship on the device model could have some sort of indication so that FW can switch connections to consume the module twin.

{
            "@id": "dtmi:com:FirmwareModule;1",
            "@type": "Relationship",
            "name": "FirmwareModule",
            "displayName": {
              "en": "Firmware module"
            },
            "description": {"en": "The module used to manage ADU."},
            "minMultiplicity": 0,
            "maxMultiplicity": 1,
            "target": "dtmi:azure:iot:deviceUpdateModel;1"
        },

@sourabhkrishna
Copy link
Author

@rido-min did you get a chance to look at this?

@rido-min
Copy link
Member

I'd suggest to reference the ADU interface as a component, as described in https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-plug-and-play

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants