Render fuel as volume
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':
That's because fuel value is not very well standardized.
Could this be made configurable? (e.g. "Fuel Unit" in device or server settings)
Anything is possible, but the problem is that it's not well standardized on protocol level.
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.
No, that's not the right solution. The right solution is to fix it on protocol level.
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.
If the protocol is defines specific units, then it should be implemented directly. If not, it should be configurable on the protocol level.
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.