Closed joeyphant closed 4 years ago
Hi @joeyphant ,
can severity (HIGH, MEDIUM, LOW) not cover that for you? Or is there a DEVICE_ERROR with severity low and a DEVICE_INFO with severity high in your scenario?
The type
field does indicated the type of origin (from a device or somewhere in the infrastructure)
Hi @ameinhardt, Severity could cover that, yes. But I don't like the idea of having an implicit meaning behind the severity. Different solutions/services using PPMP might have different implicit meanings behind the severity.
Currently our scenario does not support a DEVICE_ERROR with severity low or a DEVICE_INFO with severity high. However, there might be scenarios in the future where this needs to be supported.
Thanks for the clarification of the current usage of the type
field. While the usage does not fit my requested changes, the name of the field certainly does. That's why I also included DEVICE_
prefix in all new values.
Hi @joeyphant , @ameinhardt , I think if we don't have the specific requirement currently we shouldn't add fields we don't need. Better to keep it as simple as needed instead of adding to many options to the enum.
@ameinhardt , @muelsen , After clarifying again, there are errors with different severities in our scenario.
Maybe we could rename type
to source
. Then, type
is free for identifying the message type as in ['INFO', 'WARNING', 'ERROR']. severity
would still remain.
Any objections?
hi @joeyphant, I added your suggestion in the schema. Thanks for the patience
In order to determine the actual type of the message which was sent by the device, the possible values for the
Type
enumeration should be extended.Current values:
DEVICE
,TECHNICAL_INFO
Additional values:DEVICE_INFO
,DEVICE_WARNING
,DEVICE_ERROR
A device might sent a list of messages where only one is an error and the others only contain informational content