Open dharezlak opened 8 years ago
UI uses device.custom_id (parameter.measurement_type_name)
template to generate chart labels.
@dharezlak Could you suggest a suitable label (by providing examples)?
This issue has been originally reported by @balis with https://github.com/ismop/eitwid/issues/105. As it was a DAP-only issue I moved it here. I suppose @balis should have more details on it.
@balis We'll need a more detailed explanation of what kinds of labels are required. Could you give us some examples?
I propose to treat this issue as a possibility to fix all naming problems we currently have in DAP. In device, parameter we have following values:
Parameter.name
Parameter.measurement_type_unit
Parameter.measurement_type_name
(I know that measurement_type_*
are in different model but from serialization point of view these values are serialized as parameter values).
Currently in UI we need to cheat and use something like:
// X axis name - this is not OK
chartSeries.setName(device.getCustomId() + " (" + parameter.getMeasurementTypeName() + ")");
// Y axis name - this is fine
parameter.getMeasurementTypeName() + " [" + parameter.getMeasurementTypeUnit() + "]"
As you can see we use getMeasurementTypeName()
to present something meaningful to the user, but instead we should be using:
// e.g. UT2 (Temperature)
chartSeries.setName(device.getCustomId() + " (" + parameter.getName() + ")");
// Y axis name - this is fine
parameter.getMeasurementTypeName() + " [" + parameter.getMeasurementTypeUnit() + "]"
Now we cannot do this, because there is a lot of "unknown parameter" parameter names. It would be also nice to have meaningful device name (e.g. Światłowód 245m
) instead of custom id which can looks as follow: ASP.POMIARY_GESO_1000.F_0245
@mkasztelnik I agree that the values of Parameter.parameter_name
need some massaging since right now this field mostly duplicates Parameter.custom_id
(or else is set to unknown parameter
by the parameter discovery service). I could write a script to convert these values to something useful (e.g. "Światłowód 254m"). Should I?
Regarding Device
, I don't want to reuse custom_id
as a human-readable label - it was not meant for that purpose. Instead, I can add a separate field (e.g. device_name
) and initialize it to whatever you want (e.g. "Czujnik temperatury" or similar).
@nowakowski it would be nice to make it right :smile: As I was proposing above it would be nice to have unified axis name formatting in UI for all series like:
// e.g. UT2 (Temperature)
chartSeries.setName(device.getName() + " (" + parameter.getName() + ")");
// Y axis name - this is fine
parameter.getMeasurementTypeName() + " [" + parameter.getMeasurementTypeUnit() + "]"
To make it possible correct data in DAP is needed.
According to device name I meant exactly how you describe it. As you can see I already changed device.getCustomId()
into Device.getName()
in my example.
@nowakowski any update of this issue? This is quite urgent for implementing https://github.com/ismop/eitwid/issues/136
@mkasztelnik Yeah, there is progress. While I'm not sure if we can close this issue altogether, I have worked with Daniel Kessler to re-register NS sensors and it seems he's finally happy with the result:
Piotrze O to chodziło. Teraz mogę wybierać co mnie interesuje. Super.
Note, however, that Daniel has also asked me to provide wildcard support in the Device filter (Analysis view) so he could input something like "Neosentio3*_1_4". I told him it was a GUI issue and suggested filing an eitwid ticket.
Can we move this issue forward? Things to do:
name
field to the Device entity and initialize it with the current value of the custom_id
field.For #90 we could do the following:
Device.name
to Poziom wody
,Parameter.parameter_name
to poziom dla czujnika 1
, poziom dla czujnika 2
, poziom zadany
, średni poziom dla czujników 1 i 2
, zużycie energii pomp
, aktywność pompy 1
oraz aktywność pompy 2
.@dharezlak Can do.
Device prefixes:
Measurement type prefix:
Change labels of NS sensors on charts to more meaningful, such that allow identification of the sensors' locations. For example "neosentio.3_26_0_4 (Temperatura)". However, Daniel Kessler said that these IDs may change.