[Feature request]: PnP - Dynamic Telemetry for Modbus (or any other model)

[uriel-kluk]

@usivagna, @rido-min Make the Modbus Properties a Map to setup the configuration

and make the Telemetry to use the "Key" as the filed name

{"VoltAN":123.2}

Note: VoltAN is the name of the field and it is dynamically plugged into the telemetry. IoT Central will need some flag to understand that this field comes from the configuration, maybe something like this: {"DKey":"VoltAN", "DValue":123.2} and the tool understands that it needs to flatten the JSON.

Here is the DTDLv2 model that describes the properties

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:MeshSystems:tXs_modbus;2",
  "@type": "Interface",
  "displayName": {
    "en": "Modbus"
  },
  "contents": [
    {
      "@type": "Property",
      "displayName": {
        "en": "BaudRate"
      },
      "name": "BaudRate",
      "schema": "integer",
      "writable": true
    },
    {
      "@type": "Property",
      "displayName": {
        "en": "Operation"
      },
      "name": "Operation",
      "writable": true,
      "schema": {
        "@type": "Map",
        "mapKey": {
          "name": "Key",
          "schema": "string"
        },
        "mapValue": {
          "name": "Value",
          "schema": "dtmi:MeshSystems:tXs_modbusOperation;1"
        }
      }
    }
  ],
  "schemas": [
    {
      "@id": "dtmi:MeshSystems:tXs_modbusOperation;1",
      "@type": "Object",
      "fields": [
        {
          "name": "UnitId",
          "schema": "integer"
        },
        {
          "name": "RegisterType",
          "schema": {
            "@type": "Enum",
            "valueSchema": "integer",
            "enumValues": [
              {
                "@type": "EnumValue",
                "enumValue": 1,
                "name": "READ_COILS"
              },
              {
                "@type": "EnumValue",
                "enumValue": 2,
                "name": "READ_DISCRETE_INPUTS"
              },
              {
                "@type": "EnumValue",
                "enumValue": 3,
                "name": "READ_HOLDING_REGISTERS"
              },
              {
                "@type": "EnumValue",
                "enumValue": 4,
                "name": "READ_INPUT_REGISTERS"
              },
              {
                "@type": "EnumValue",
                "enumValue": 5,
                "name": "WRITE_SINGLE_COIL"
              },
              {
                "@type": "EnumValue",
                "enumValue": 6,
                "name": "WRITE_SINGLE_REGISTER"
              },
              {
                "@type": "EnumValue",
                "enumValue": 7,
                "name": "READ_EXCEPTION_STATUS"
              },
              {
                "@type": "EnumValue",
                "enumValue": 15,
                "name": "WRITE_MULTIPLE_COILS"
              },
              {
                "@type": "EnumValue",
                "enumValue": 16,
                "name": "WRITE_MULTIPLE_REGISTERS"
              },
              {
                "@type": "EnumValue",
                "enumValue": 17,
                "name": "REPORT_SLAVE_ID"
              },
              {
                "@type": "EnumValue",
                "enumValue": 22,
                "name": "MASK_WRITE_REGISTER"
              },
              {
                "@type": "EnumValue",
                "enumValue": 23,
                "name": "WRITE_AND_READ_REGISTERS"
              }
            ]
          }
        },
        {
          "name": "PollingIntervalMs",
          "schema": "integer"
        },
        {
          "name": "StartAddress",
          "schema": "integer"
        },
        {
          "name": "DataType",
          "schema": {
            "@type": "Enum",
            "valueSchema": "integer",
            "enumValues": [
              {
                "@type": "EnumValue",
                "enumValue": 1,
                "name": "MB_int16"
              },
              {
                "@type": "EnumValue",
                "enumValue": 2,
                "name": "MB_bcd32"
              },
              {
                "@type": "EnumValue",
                "enumValue": 3,
                "name": "MB_logBase2"
              },
              {
                "@type": "EnumValue",
                "enumValue": 4,
                "name": "MB_float32"
              },
              {
                "@type": "EnumValue",
                "enumValue": 5,
                "name": "MB_float32swap"
              },
              {
                "@type": "EnumValue",
                "enumValue": 7,
                "name": "MB_int32"
              },
              {
                "@type": "EnumValue",
                "enumValue": 11,
                "name": "MB_uint16"
              },
              {
                "@type": "EnumValue",
                "enumValue": 12,
                "name": "MB_bcd16"
              },
              {
                "@type": "EnumValue",
                "enumValue": 13,
                "name": "MB_int64"
              },
              {
                "@type": "EnumValue",
                "enumValue": 15,
                "name": "MB_uint64"
              },
              {
                "@type": "EnumValue",
                "enumValue": 16,
                "name": "MB_double64"
              }
            ]
          }
        }
      ]
    }
  ]
}

[usivagna]

Thanks for filing this feedback @uriel-kluk , I'll review this with the dev team in our next engineering sync next week and update the thread accordingly.

[usivagna]

@uriel-kluk Can you clarify what the benefit of this change would be? Are you simplify looking to reduce changes in the config?

[uriel-kluk]

With the existing approach, the PnP declaration needs to know apriori the registers it needs to read. Stroy: As a system integrator, I want to deploy the Modbus module and select the register map, without having to recompile and without having to publish specialized PnP models that are dependant on the current device that I connect downstream.

On Wed, Oct 14, 2020 at 1:27 PM Ugan Sivagnanenthirarajah < notifications@github.com> wrote:

@uriel-kluk https://github.com/uriel-kluk Can you clarify what the benefit of this change would be? Are you simplify looking to reduce changes in the config?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/iot-plug-and-play-bridge/issues/39#issuecomment-708581365, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2NCA76CFV2SJMQIPCLFOLSKXUQVANCNFSM4SIALCEA .

-- *Uri Kluk*, CTO

An IoT Solutions Innovator

p: 317.661.4800 w: mesh-systems.com https://www.linkedin.com/company/mesh-systems-llc

[usivagna]

Hi @uriel-kluk, I'm currently in discussions with others in the IoT Plug and Play platform team on whether this is a supported scenario, and how best to accommodate this ask. Typically today, device makers do need a priori knowledge to create a IoT Plug and Play model. In the case of scenarios like this we are working on providing updated guidance to partners. I'll update this thread as soon as I can share more.

[usivagna]

Thank you for your interest in the IoT Plug and Play bridge, unfortunately due to new innovations in Azure IoT and changes in product strategy we have come to the decision to deprecate the IoT Plug and Play bridge. Thank you to the community for your support on this journey. The repo is planned to be archived as a read-only repository on November 30th 2023. Thank you to everyone who contributed bug fixes and new adapters for connecting devices with IoT Plug and Play. You can find the latest IoT innovations at https://techcommunity.microsoft.com/t5/internet-of-things-blog/bg-p/IoTBlog. Please note that any use of archived repositories introduces more risks from a security standpoint and should be done with caution.