-
Couldn't load subscription status.
- Fork 14
Description
The documentation says these fields are sets, but that is probably for the old version when they were just a repeated error code. Now each is a list of SensorDiagnostic messages, which is richer than just a enum value, including messages and vendor diagnostic codes.
Even if we consider the documentation referring only to the internal SensorDiagnostic.diagnostic_code when saying values cannot be repeated, it sounds like now there could be some situation where maybe we use the same SensorDiagnosticCode to handle different vendor codes (at the moment we basically have only UNKNOWN and INTERNAL, so any device having richer vendor specific diagnostic code will probably result in this situation.
frequenz-api-common/proto/frequenz/api/common/v1alpha8/microgrid/sensors/sensors.proto
Lines 117 to 137 in 2678cee
| // List of warnings for the microgrid sensor. | |
| // | |
| // !!! note | |
| // This list is treated as a set, and therefore its members will be unique, | |
| // i.e., no state will exist twice in this list. | |
| // | |
| // !!! note | |
| // This list is expected to have warnings if and only if the sensor is | |
| // reporting warnings. | |
| repeated SensorDiagnostic warnings = 3; | |
| // List of errors for the microgrid sensor. | |
| // | |
| // !!! note | |
| // This list is treated as a set, and therefore its members will be unique, | |
| // i.e., no state will exist twice in this list. | |
| // | |
| // !!! note | |
| // This list is expected to have errors if and only if the sensor is in | |
| // an error state. | |
| repeated SensorDiagnostic errors = 4; |
I suggest changing the wording to just say this is a list without giving much more guarantees than that to keep this flexible. If we wanted to restrict it more, we should define what constitutes a unique SensorDiagnostic (I guess same diagnostic_code AND vendor_diagnostic_code).