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.
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
On 03/11/17 14:04, Mark Webb-Johnson wrote:
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.
Agreed your implementation is much better.
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.
Given users can do setup with the usb console with no special hardware, it might not be necessary to bring all the features and parameters to the v2 protocol. Instead it might be better to work on the v3 protocol & clients and make the early users use the console? I haven't looked much at what the other vehicle modules do with the features and parameters, are there any vehicles that users adjust them so much plugging into the usb is inconvenient?
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.
This pull request ( https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7 ) is still outstanding
Am 06.11.2017 um 09:57 schrieb Tom Parker:
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.
Given users can do setup with the usb console with no special hardware, it might not be necessary to bring all the features and parameters to the v2 protocol. Instead it might be better to work on the v3 protocol & clients and make the early users use the console? I haven't looked much at what the other vehicle modules do with the features and parameters, are there any vehicles that users adjust them so much plugging into the usb is inconvenient?
You'll be able to submit all commands via SMS/text command as well, you just need to use the new syntax. I've implemented my specific features as config vars now, as they give much more freedom. I think it's good to map at least the old standard parameters and features to their respective new config variables, i.e. PARAM 5 <=> config modem apn, so clients can continue using these, but that should be sufficient for compatibility.
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.
This pull request ( https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7 ) is still outstanding
I think deriving the car_chargestate string from the charge flags is not correct. We've currently got… OvmsMetricString* ms_v_charge_state; // charging, topoff, done, preparing, heating, stopped OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricString* ms_v_charge_substate; // tba... …but no longer their numerical equivalences as metrics -- assuming they are no longer necessary. Are they? I.e. do we need the numerical values other than for the old V2 protocol? I'd else translate the old codes to their old numerical values just for the "S" msg. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I've just pushed a rework of the v2 stat message including some more metrics and automatic code/key translations for charge state & mode. It works well on my test vehicle. The translation utilities can also be used to set the code metrics if you stick to the integer keys internally. Still missing is the substate. From the v2 code it can have these values: - 0 = undefined - 1 = charge stop request - 3 = charging by request - 7 = cable not connected - 14 = charge interrupted That's a bit mixed scope… are these all substates to support? Regards, Michael Am 06.11.2017 um 18:37 schrieb Michael Balzer:
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. This pull request ( https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7 ) is still outstanding I think deriving the car_chargestate string from the charge flags is not correct. We've currently got…
OvmsMetricString* ms_v_charge_state; // charging, topoff, done, preparing, heating, stopped OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricString* ms_v_charge_substate; // tba...
…but no longer their numerical equivalences as metrics -- assuming they are no longer necessary. Are they? I.e. do we need the numerical values other than for the old V2 protocol?
I'd else translate the old codes to their old numerical values just for the "S" msg.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Probably best to double-check in the iOS and Android Apps for what they use. For iOS, all I see is a check for chargesubstate == 0x07. Same for Android. I think it is ok just to use those substates for the moment. Long-term, we don’t really want/need this substate metric anyway. Regards, Mark.
On 7 Nov 2017, at 6:01 AM, Michael Balzer <dexter@expeedo.de> wrote:
I've just pushed a rework of the v2 stat message including some more metrics and automatic code/key translations for charge state & mode.
It works well on my test vehicle. The translation utilities can also be used to set the code metrics if you stick to the integer keys internally.
Still missing is the substate. From the v2 code it can have these values:
- 0 = undefined - 1 = charge stop request - 3 = charging by request - 7 = cable not connected - 14 = charge interrupted
That's a bit mixed scope… are these all substates to support?
Regards, Michael
Am 06.11.2017 um 18:37 schrieb Michael Balzer:
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. This pull request ( https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7> ) is still outstanding I think deriving the car_chargestate string from the charge flags is not correct. We've currently got…
OvmsMetricString* ms_v_charge_state; // charging, topoff, done, preparing, heating, stopped OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricString* ms_v_charge_substate; // tba...
…but no longer their numerical equivalences as metrics -- assuming they are no longer necessary. Are they? I.e. do we need the numerical values other than for the old V2 protocol?
I'd else translate the old codes to their old numerical values just for the "S" msg.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Translations extended & fixed: _states_: case 1: code = "charging"; break; case 2: code = "topoff"; break; case 4: code = "done"; break; case 13: code = "prepare"; break; case 14: code = "timerwait"; break; case 15: code = "heating"; break; case 21: code = "stopped"; break; default: code = ""; _substates_: case 0x01: code = "scheduledstop"; break; case 0x02: code = "scheduledstart"; break; case 0x03: code = "onrequest"; break; case 0x05: code = "timerwait"; break; case 0x07: code = "powerwait"; break; case 0x0d: code = "stopped"; break; case 0x0e: code = "interrupted"; break; default: code = ""; Regards, Michael Am 07.11.2017 um 02:57 schrieb Mark Webb-Johnson:
Probably best to double-check in the iOS and Android Apps for what they use.
For iOS, all I see is a check for chargesubstate == 0x07. Same for Android.
I think it is ok just to use those substates for the moment. Long-term, we don’t really want/need this substate metric anyway.
Regards, Mark.
On 7 Nov 2017, at 6:01 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I've just pushed a rework of the v2 stat message including some more metrics and automatic code/key translations for charge state & mode.
It works well on my test vehicle. The translation utilities can also be used to set the code metrics if you stick to the integer keys internally.
Still missing is the substate. From the v2 code it can have these values:
- 0 = undefined - 1 = charge stop request - 3 = charging by request - 7 = cable not connected - 14 = charge interrupted
That's a bit mixed scope… are these all substates to support?
Regards, Michael
Am 06.11.2017 um 18:37 schrieb Michael Balzer:
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. This pull request ( https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7 ) is still outstanding I think deriving the car_chargestate string from the charge flags is not correct. We've currently got…
OvmsMetricString* ms_v_charge_state; // charging, topoff, done, preparing, heating, stopped OvmsMetricString* ms_v_charge_mode; // standard, range, performance, storage OvmsMetricString* ms_v_charge_substate; // tba...
…but no longer their numerical equivalences as metrics -- assuming they are no longer necessary. Are they? I.e. do we need the numerical values other than for the old V2 protocol?
I'd else translate the old codes to their old numerical values just for the "S" msg.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Tom Parker