deviceLinks.name should not be empty

[GCoxCasey]

In the lucid.schema.json, for deviceLinks both the num and name properties are mandatory.
We believe it would be useful if the name was also not allowed to be empty.

This is the existing schema definition (version 3.1)

"deviceLinks": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "name": {
              "type": "string"
            },
            "num": {
              "type": "integer"
            }
          },
          "required": [
            "name",
            "num"
          ],
          "additionalProperties": false
        }
      }

We would like to suggest adding 'minLength' as shown below:

"deviceLinks": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "name": {
              "type": "string"
              "minLength": 1,
            },
            "num": {
              "type": "integer"
            }
          },
          "required": [
            "name",
            "num"
          ],
          "additionalProperties": false
        }
      }

[GCoxCasey]

We did a little more investigation, we think the intention of deviceLinks listed in the capabilities section of the Device Profile is to specify the name and number (num) ALL the deviceLinks that are available to ALL field device types that use this version of the Device profile.

deviceLinks are also listed in the configuration.json payload of UP/configuration and DOWN/configuration.
We believe the intention here is:

1. To be able to specify configuration properties for a specific deviceLink (e.g. connectionString)
2. To be able to enable/disable a devicelink or a per FD basis (disabling is done by omitting a deviceLink from the configuration.json.
3. The set of deviceLinks an FD supports is hardcoded in the Device profile, the name and num are readonly.
4. In the configuration.json the num/name of any deviceLink is expected to match one of the deviceLinks defined in the Device Profile (although the num would be enough).
5. Additional deviceLinks (not listed in the Device Profile) cannot be added in the configuration.json.

We also think the same understanding applies to the Channel objects.
If our understanding is correct, some documentation updates may help make this clearer.

[davisonm]

During the Lucid Technical Working Group on 15th June 2026, this issue and related emails from MD and GCC were discussed. No resolution was determined and issues were left for further discussion.

MDs original email was as below:
The device profile require that the device links are listed and named e.g.

"deviceLink": [
{
"num": 1,
"name": "Onboard IO"
},
{
"num": 2,
"name": "Calc"
}
],

However the configuration also contains device link information e.g.

"deviceLink": [
{
"num": 1,
"name": "Onboard IO",
“conn”: “192.168.0.1:502”
},
{
"num": 2,
"name": "Calc"
}
],

The only thing that the configuration seems to add is a confirmation that a device link is in use and possible connection information for that device link. So, as a bare minimum, the repetition of the name (which should be the same?) is unnecessary. My questions are as follows:

1. Is the specification of every device link in the device profile in appropriate, should we in fact be saying only how many can exist? For example, if a device has an IP port, it could connect a large number of PLCs with Modbus or Profibus or the like, but these may not be named at the time of specifying the device profile. Maybe it would be better if the device profile said there could be up to 10 and the existence and naming of each would be a matter for the configuration.
2. Should we be avoiding the repetition of the name in the device profile and the device configuration?
3. Would the fact that device links could change between configurations make any difference to an SA? For example, in one config the device link 0 is Calc and in another (possibly for the same device) the device link 1 is Calc.
4. In the JSON Schema, the definition of device link in the device profile is at line 920 and only defines “name” and “num”, both of which are required. In the Field Device Profile.json file there is another definition at line 348 which includes the “conn” element, which is optional. Which of these is the correct definition? Or have I become confused between the definition of something for the configuration and something for the device profile?

[davisonm]

Guy's response was as follows:

I raised a ticket around some of this:
deviceLinks.name should not be empty · Issue #107 · LucidProtocol/Lucid-Specification

We were struggling with the intention of it and it turns out we applied some of our validations incorrectly due to misunderstandings.

In short, I think its okay as it is and although it appears the DeviceProfile.json in Github appears to have incorrect maxObjects/totalobjects for deviceLink and Channels - I think they are okay too.

The way I understand it now is:
• The Capability section of the Device Profile lists all the deviceLinks that this TYPE of device CAN support.
• The configuration.json then lists the subset of deviceLinks in use by an INSTANCE of an FD.

So the num/name properties are readonly and come from the deviceProfile, the configuration.json can only ever reference deviceLinks which appear in the deviceProfile.
I imagine the configuration including the name as well as the num is just convenience (maybe for confidence too) - only the number is really required.

I think, Channels work the same way.

It makes sense to me that channels are physical therefore the Device Profile should specify them on a per Device Type basis
I think devicelinks are very similar in the sense pf physical IO and calculation points, but maybe it blurs when connecting to PLCs.

So in answer to the questions:

1. Is the specification of every device link in the device profile in appropriate, should we in fact be saying only how many can exist? For example, if a device has an IP port, it could connect a large number of PLCs with Modbus or Profibus or the like, but these may not be named at the time of specifying the device profile. Maybe it would be better if the device profile said there could be up to 10 and the existence and naming of each would be a matter for the configuration.
   The configuration.json can add extra configuration which is not hard coded in deviceProfile, for example ConnectionString (called conn).
   But you make a good point about the name, in case of physical and Calc Points I guess you would not want those changed.

2. Should we be avoiding the repetition of the name in the device profile and the device configuration?
   The examples in the DeviceProfile.json Github do appear not to match between Capability and objectTypes.
   Is there a case to use the name incase a device profile version modified the use of the DeviceLinks (reallocating a number to a different name)

3. Would the fact that device links could change between configurations make any difference to an SA? For example, in one config the device link 0 is Calc and in another (possibly for the same device) the device link 1 is Calc.
   We could catch it if the names were kept in both Capability and objectType Sections (but duplication tends to be bad) and it was pointed out ObjectTypes is actually optional (at the moment)

4. In the JSON Schema, the definition of device link in the device profile is at line 920 and only defines “name” and “num”, both of which are required. In the Field Device Profile.json file there is another definition at line 348 which includes the “conn” element, which is optional. Which of these is the correct definition? Or have I become confused between the definition of something for the configuration and something for the device profile?
   The Schema definition for deviceLinks also has "additionalProperties": false so I think that makes "conn" illegal.
   But I think it does make sense for deviceLinks to have extended properties.

I did wonder if the CapbilitySection should talk about an additional deviceLinkType (instead of deviceLink) but then Configuration could create limited numbers of devicelinks of each devicelinkType.
Something Like:

deviceLinkType maxObjects Extended Fields
Physical 1 n/a
Calculated 1 Interval
Modbus 5 PLC Id, Connection String
ProfiBus 5 PLC Id, Connection String

Then you could have 5 deviceLinks linking to Modbus, each could have its own name and other configuration fields relevant to its Type.
But this would obviously be more complicated.