extern unsigned char car_charge_b4; // B4 byte of charge stateextern unsigned int car_chargepower; // Charge Power (1/10 kW)extern unsigned char car_lockstate; // Lock Stateextern char sys_features[FEATURES_MAX]; // System featuresextern unsigned char net_link; // Network link statusextern unsigned int car_max_idealrange; // Maximum ideal range in milesextern 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 stoppedextern unsigned int car_12v_current; // 12V (DC converter) current in 1/10 Aextern signed int car_chargefull_minsremaining; // ETR for 100%extern signed int car_chargelimit_minsremaining_range; // ETR for range limitextern signed int car_chargelimit_minsremaining_soc; // ETR for SOC limitextern unsigned int car_chargelimit_rangelimit; // Range limit (in vehicle units)extern unsigned char car_chargelimit_soclimit; // SOC% limitextern signed char car_coolingdown; // >=0 if car is cooling downextern unsigned char car_cooldown_chargemode; // 0=standard, 1=storage, 3=range, 4=performanceextern unsigned char car_cooldown_chargelimit; // Charge Limit (amps)extern signed int car_cooldown_tbattery; // Cooldown temperature limitextern unsigned int car_cooldown_timelimit; // Cooldown time limit (minutes) remainingextern unsigned char car_cooldown_wascharging; // TRUE if car was charging when cooldown startedextern unsigned char car_SOCalertlimit; // Low limit of SOC at which alert should be raised
On 8 Oct 2017, at 5:40 PM, Tom Parker <tom@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev