feat: [UCR] Attribute protocol info in device #1287
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lenny-goodell
requested changes
Nov 29, 2023
| Any users that create Device Profiles and Devices that have protocol-specific attribute values. | ||
|
|
||
| ## Description | ||
| The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister's). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. |
There was a problem hiding this comment.
Suggested change
| The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister's). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. | |
| The Device Profile **describes** the device type and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device type using the same protocol but different configuration (e.g. different Modbus HoldingRegister's). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus device types, there will need to be two different Device Profiles, even though the device types are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. |
There was a problem hiding this comment.
The first change (addition of 'type') was fixed. The last three are correct as-is.
- '...and the same device using...' describes a manufacturer who built two of the same devices, but specified different configurations for the two.
- The last two uses of device flagged also describe a manufacturer who build two of the same devices, but specified different configurations for the two.
| ## Description | ||
| The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister's). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. | ||
|
|
||
| If the protocol information resides in the Device, which describes a specific (instance of a) device, only a single Device Profile is needed as all devices of the same type can use the same Device Profile. This becomes more important as you have more devices, potentially increasing the number and management of Device Profiles when a single one will do. |
There was a problem hiding this comment.
I am confused by this statement since this is how it is today (i.e. protocol in the device definition), but it doesn't support your need of a single Device Profile for all types of a Device.
| --> | ||
|
|
||
| ## Requirements | ||
| The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device as well as the Device Profile (for backward compatibility). |
There was a problem hiding this comment.
Suggested change
| The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device as well as the Device Profile (for backward compatibility). | |
| The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device definition as well as the Device Profile (for backward compatibility). |
There was a problem hiding this comment.
Are you requesting that the Device definition's protocol be expanded for to support the more detail specifics (e.g. HoldingRegister) or the Device Profile be expanded with protocol specifics, which are currently in the Device definition?
| ## Requirements | ||
| The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device as well as the Device Profile (for backward compatibility). | ||
|
|
||
| - If only the Device contains a protocol-specific attribute, it is used for that device. |
There was a problem hiding this comment.
Suggested change
| - If only the Device contains a protocol-specific attribute, it is used for that device. | |
| - If only the Device definition contains a protocol-specific attribute, it is used for that device. |
|
|
||
| - If only the Device contains a protocol-specific attribute, it is used for that device. | ||
| - If only the Device Profile contains a protocol-specific attribute, it is used for all Devices having that Device Profile. | ||
| - If both the Device Profile and the Device contain a protocol-specific attribute, the entry in the Device overrides the one in the Device Profile. |
There was a problem hiding this comment.
Suggested change
| - If both the Device Profile and the Device contain a protocol-specific attribute, the entry in the Device overrides the one in the Device Profile. | |
| - If both the Device Profile and the Device definition contain a protocol-specific attribute, the entry in the Device definition overrides the one in the Device Profile. |
lenny-goodell
changed the title
|
@dmocek, you also need to add this UCR to the UCR TOC here: https://docs.edgexfoundry.org/3.1/design/TOC/ |
dmocek
force-pushed
the
protocol-info-in-device
branch
from
8d555b1 to
6da37a5
Compare
Signed-off-by: Darryl Mocek <darryl.mocek@oracle.com>
Signed-off-by: Darryl Mocek <darryl.mocek@oracle.com>
Signed-off-by: Darryl Mocek <darryl.mocek@oracle.com>
Signed-off-by: Darryl Mocek <darryl.mocek@oracle.com>
dmocek
force-pushed
the
protocol-info-in-device
branch
from
6da37a5 to
ec2f394
Compare
Signed-off-by: Darryl Mocek <darryl.mocek@oracle.com>
|
All issues have been addressed. |
Comment on lines
+30
to
+35
| The requirement is to support the protocol-specific attribute values (e.g. HOLDING_REGISTER's) in the Device definition as well as the Device Profile (for backward compatibility). | ||
|
|
||
| - If only the Device definition contains a protocol-specific attribute, it is used for that device. | ||
| - If only the Device Profile contains a protocol-specific attribute, it is used for all Devices having that Device Profile. | ||
| - If both the Device Profile and the Device definition contain a protocol-specific attribute, the entry in the Device definition overrides the one in the Device Profile. | ||
|
|
There was a problem hiding this comment.
The problem I see with this approach is the common protocol details in the device definition are repeated for every instance of a specific device type. Each time a device object is instantiated the common protocol details have to be known so they can be specified in the device definition. Currently the common protocol details are specified once in the Device Profile and the Define Definitions only contain the device instance specific protocol details
What if the Device Profile Resource attribute could be partition by protocol allowing the Device Services to pick the attributes base on the protocol name already specified in the Device definition.
Something like:
name: "SwitchA"
isHidden: true
description: "On/Off , 0-OFF 1-ON"
attributes:
modbus-tcp:
{ primaryTable: "COILS", startingAddress: 0 }
modbus-rtu:
{ primaryTable: "COILS", startingAddress: 1 }
There was a problem hiding this comment.
Agree, the fomat of the profile resource attribute is free, so users can define multiple protocol information in the device resources. It's simpler than adding the protocol resource attribute to Device.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Attribute protocol information in the Device UCR.