[Ovmsdev] V3 progress

Sun Oct 8 22:29:24 HKT 2017

I’ve added the standard metrics that I could work out, and pushed that to the main. About 80 in total now. That should work for 99% of the functionality, and is a nice format for MQTT and GATT (although more work for v2 server protocol).

The ones I haven’t done are:

extern unsigned char car_charge_b4; // B4 byte of charge state
extern unsigned int car_chargepower; // Charge Power (1/10 kW)
extern unsigned char car_lockstate; // Lock State
extern char sys_features[FEATURES_MAX]; // System features
extern unsigned char net_link; // Network link status
extern unsigned int car_max_idealrange; // Maximum ideal range in miles

extern signed int car_power; // Current battery power level (1/10 kW)
extern unsigned long car_energy_used; // Energy used on trip (Wh)
extern unsigned long car_energy_recd; // Energy recovered on trip (Wh)

extern unsigned char car_stopped_mincnt; // Minute countdown while stopped

extern unsigned int car_12v_current; // 12V (DC converter) current in 1/10 A

extern signed int car_chargefull_minsremaining;  // ETR for 100%
extern signed int car_chargelimit_minsremaining_range; // ETR for range limit
extern signed int car_chargelimit_minsremaining_soc; // ETR for SOC limit
extern unsigned int car_chargelimit_rangelimit;   // Range limit (in vehicle units)
extern unsigned char car_chargelimit_soclimit;    // SOC% limit

extern signed char car_coolingdown;              // >=0 if car is cooling down
extern unsigned char car_cooldown_chargemode;    // 0=standard, 1=storage, 3=range, 4=performance
extern unsigned char car_cooldown_chargelimit;   // Charge Limit (amps)
extern signed int car_cooldown_tbattery;         // Cooldown temperature limit
extern unsigned int car_cooldown_timelimit;      // Cooldown time limit (minutes) remaining
extern unsigned char car_cooldown_wascharging;   // TRUE if car was charging when cooldown started

extern unsigned char car_SOCalertlimit;           // Low limit of SOC at which alert should be raised

As they seem either vehicle-specific, or internal working variables.

I think they should be fairly self-explanatory, although in places I’ve renamed them to make more sense (e.g. MS_V_CHARGE_MINUTES and MS_V_CHARGE_KWH, rather than car_chargeduration and car_chargekwh). I’ve also dropped a few that were really duplicating the same basic information.

Do the best you can, and if you can’t work out how to get something in particular, let me know or leave it as a “TODO” marked in the code.

Thanks, Mark

> On 8 Oct 2017, at 5:40 PM, Tom Parker <tom at carrott.org> wrote:
> 
> On 04/10/17 02:30, Mark Webb-Johnson wrote:
>> I just added the very basic ones, as a starting point and proof of concept. Hadn’t decided if I needed anything special for the bitmapped ones at the time (either a new MetricBitmap type, or extend MetricInt). Looking at how things have evolved, and bearing in mind the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit should be a metric of their own. Not too hard for ovms_server_v2 to convert that back to an integer bitmap, for backwards compatibility. To do that, car_doors1 becomes:
> 
> I fully support the concept of storing the data in the most appropriate format and serializing it into the v2 message in the v2 server code. I like the idea of storing the bit field stuff as separate boolean objects. I don't know if you can do anything clever with C++ to use less memory while preserving a nice API within the vehicle code, but we probably have enough memory to not need to worry too much?
> 
>> So, if you have time, please go ahead and add the other standard ones that are simple and shared across all cars.
> 
> I'll add them as I need them for porting the leaf code. I don't support most of the "standard" metrics in the leaf code so it won't be all of them.
> 
>>> Is anyone working on the v2 server support code to send the S and D messages?
>> 
>> Nope. Not at the moment. I’ve stubbed it.
> 
> I've implemented an S message using the TPMS as an example and the few metrics that we already have. I found the android client can't cope with an empty value, so I had to modify the if undefined return the empty string behavior in the AsString implementations in subclasses of OvmsMetric. I'm currently "learning" how C++ inheritance works and am in a twisty maze of complier errors. I'll explain what I'm doing tomorrow and hopefully there is an obvious answer. Once I've sorted that out I'll send a pull request (I hacked it by hard coding values that work for a v2 android client which presumably breaks other things. What I want to do is replace the existing methods with ones that takes an argument to return as a default value, and re-implement the existing no-argument methods in terms of the new method).
> 
> I'm at the point where I can take it for a drive on my phone's wifi hotspot.
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171008/8c256acf/attachment.htm>