traccar-web icon indicating copy to clipboard operation
traccar-web copied to clipboard

Render fuel as volume

Open ivan-avalos opened this issue 3 months ago • 8 comments

Currently, Traccar renders fuel without units.

This should, however, be a volume unit.

diff --git a/src/common/components/PositionValue.jsx b/src/common/components/PositionValue.jsx
index 7a6a1843..360bd696 100644
--- a/src/common/components/PositionValue.jsx
+++ b/src/common/components/PositionValue.jsx
@@ -67,6 +67,8 @@ const PositionValue = ({ position, property, attribute }) => {
         return value != null ? formatPercentage(value) : '';
       case 'volume':
         return value != null ? formatVolume(value, volumeUnit, t) : '';
+      case 'fuel':
+        return value != null ? formatVolume(value, volumeUnit, t) : '';
       case 'fuelConsumption':
         return value != null ? formatConsumption(value, t) : '';
       case 'coolantTemp':

ivan-avalos avatar Oct 03 '25 20:10 ivan-avalos

That's because fuel value is not very well standardized.

tananaev avatar Oct 03 '25 20:10 tananaev

Could this be made configurable? (e.g. "Fuel Unit" in device or server settings)

ivan-avalos avatar Oct 03 '25 20:10 ivan-avalos

Anything is possible, but the problem is that it's not well standardized on protocol level.

tananaev avatar Oct 03 '25 20:10 tananaev

That's imo why admins should be able to configure this. Let's say, having no unit by default, but optionally allowing it to be interpreted as volume on a per-device (or server-wide) basis. In our use case, fuel volume is available as an io attribute that we then map to fuel using a computed attribute, but we also want the UI to show it as volume because we know for sure that those sensors report directly in liters.

ivan-avalos avatar Oct 03 '25 20:10 ivan-avalos

No, that's not the right solution. The right solution is to fix it on protocol level.

tananaev avatar Oct 03 '25 20:10 tananaev

Can you elaborate a bit more on that? Correct me if I'm wrong, but AFAIK, in some cases the value of some external sensors can be mapped to custom ASCII fields that have no specific protocol-defined format. In such cases, computed attributes can be used to decode those values into the desired unit. This is thus not always on the protocol level.

ivan-avalos avatar Oct 03 '25 20:10 ivan-avalos

If the protocol is defines specific units, then it should be implemented directly. If not, it should be configurable on the protocol level.

tananaev avatar Oct 03 '25 20:10 tananaev

But what if I have different models of sensors on different devices using the same protocol (one that doesn't specify units), and they all report using different units or formats? Not sure how realistic is this, to be honest, but maybe providing per-device and per-protocol configurable fallbacks would be a good first step.

ivan-avalos avatar Oct 03 '25 21:10 ivan-avalos