Some questions have come up about the name and documentation for this signal, and I think we need to understand it a little bit better.
The current docs say this:
fuel_consumed_since_restart - 0 - 4294967295.0 L (this goes to 0 every time the vehicle restarts, like a trip meter)
I wrote this with the assumption that between trips in the car, the vehicle interface would be powered off. During testing, this isn't always the case and some developers are noticing it messes up their expectations. Technically, the value doesn't get set to 0 unless the unit is power cycled - the docs gloss over this fact and make a bad assumption.
Two possible options proposed by Dave Boll:
Add some smarts
If we keep the signal name and docs, we should make it always do what it says - the vehicle interface will need to have some additional intelligent to detect if the ignition goes off/on and set the fuel consumption back to 0. That's just a couple of lines of code in the handlers for ignition and fuel consumption.
Pro: saves the developer some work
Con: Developers who don't care about ignition on/off now have to handle it resetting to 0
Rename the signal, make fewer promises
Consider the signal to be useful only for providing deltas in fuel consumption and name it as such. Make no promises about when it may or may not restart, only that it will monotonically increase if the vehicle interface hasn't restarted.
I prefer the second option, I'll elaborate more later.
Some questions have come up about the name and documentation for this signal, and I think we need to understand it a little bit better.
The current docs say this:
fuel_consumed_since_restart - 0 - 4294967295.0 L (this goes to 0 every time the vehicle restarts, like a trip meter)
I wrote this with the assumption that between trips in the car, the vehicle interface would be powered off. During testing, this isn't always the case and some developers are noticing it messes up their expectations. Technically, the value doesn't get set to 0 unless the unit is power cycled - the docs gloss over this fact and make a bad assumption.
Two possible options proposed by Dave Boll:
Add some smarts
If we keep the signal name and docs, we should make it always do what it says - the vehicle interface will need to have some additional intelligent to detect if the ignition goes off/on and set the fuel consumption back to 0. That's just a couple of lines of code in the handlers for ignition and fuel consumption.
Rename the signal, make fewer promises
Consider the signal to be useful only for providing deltas in fuel consumption and name it as such. Make no promises about when it may or may not restart, only that it will monotonically increase if the vehicle interface hasn't restarted.
I prefer the second option, I'll elaborate more later.