Tom,

Thanks for finding this, and pointing it out.

I think I have a better implementation of this, by exposing the ostringstream precision+fixed parameters to metric accessor AsString(). That means we can do this, even if converting between units. That is committed, and pushed, so I don't think this pull is needed and can be dropped.

This is implemented as:

  virtual std::string AsString(const char* defvalue = "", metric_unit_t units = Other, int precision = -1);

  if (precision > 0)
    {
    ss.precision(precision); // Set desired precision
    ss << fixed;
    }

I think that is a pretty clean implementation, and backwards-compatible. I did consider putting precision as a parameter to the metric itself, but different protocols may require different precisions, so probably better to have it exposed as it is. Maybe later we can have a default precision (in the same way as we have default units at the moment).

I also started the work on expanding the structure for ovms_server_v2 in general. It handles peer connections, and the blinking antenna on the App works well now. We should now be able to implement all of that as all the tools are in place. I think that should be my next target - get the ovms_server_v2 100% compatible with OVMS v2. The features/parameters are going to be a challenge.

Regards, Mark.

On 2 Nov 2017, at 4:57 PM, Tom Parker <tom@carrott.org> wrote:

I found that the android client crashes when my leaf with v3 hardware is charging. This is because it expects integers for some values and throws NumberFormatException parsing if it encounters a floating point string. The AsString() method on float metrics returns a floating point string and we have a bunch of metrics that used to be integers but are now (correctly) floats.

I've sent a pull request with one possible solution https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/6 but I'm pretty sure it's the wrong solution. I added a special case unit conversion to integer, but having done this I think an AsIntString(default, unit) method on the floating point metrics would be a more appropriate api. As I've written it, you can't combine a unit conversion and a rounding to integer.

Thoughts?

I also sent another pull request for a minimal implementation of the charger state related values in the v2 protocol, and some small leaf fixes.

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev