- OvmsDev - Open Vehicles

Re: [Ovmsdev] Coding help
by Shane ＠ Kilve Engineering 12 Oct '21

12 Oct '21

Ok thanks Michael sorry I thought it was your doing. Ive added this to the dev mail now BTW I do have direct with sensors in the wheels, I have fitted them myself in my summer wheels, and can read the same id’s in the tpms ecu. If anyone has any help on how to read and write these using the shell and how to implement this it will be much appreciated Regards Shane Hunns > On 10 Oct 2021, at 08:33, Michael Balzer <dexter(a)expeedo.de> wrote: > > Shane, > > first of all, just in case…: you only need to read & write tyre ID sets if you've got a "direct" TPMS with tyre integrated sensors. An indirect system using the ABS & ESP sensor readings doesn't need sensor ID sets. > > I haven't used the ID set part of the tpms framework yet, my car has an indirect TPMS. > > My understanding of Mark's framework is you simply need to implement the read & write hooks, i.e. OvmsVehicle::TPMSRead() & ::TMPSWrite(). They work on an uint32 vector using the same order as the wheel layout. > > For inspiration, see the implementations for these hooks in the Model S (via CAN) and the Roadster (via K-Line extension board). > > I've added Mark to the cc… and btw, this type of question is actually best suited for the developer list. > > Regards, > Michael > > > Am 10.10.21 um 08:53 schrieb Shane(a)Kilve-Engineering.co.uk <mailto:Shane@Kilve-Engineering.co.uk>: >> Morning Michael >> >> Thank you for your email and help, >> I think I have figured out the sensor and pressure part, but in the console the tpms command has the commands to read and write tyre Id sets >> But it says it’s not implemented in this vehicle >> How do I get this implemented? Or will this work once the pressure and temps bit set up? >> >> Regards >> Shane Hunns >> >> >>> On 9 Oct 2021, at 10:23, Michael Balzer <dexter(a)expeedo.de> <mailto:dexter@expeedo.de> wrote: >>> >>> Shane, >>> >>> the metrics system doesn't know about the TPMS sensor IDs, you need to map them in your module. >>> >>> Then simply assign the pressures and temperatures to the metrics. The default sequence is FL,FR,RL,RR. >>> >>> See my mails: >>> - http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/014953.html <http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/014953.html> >>> - http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html <http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html> >>> >>> The metrics are vector metrics, you can set single values in them by position, or simply fill a new vector and assign that as a whole. Template: >>> >>> std::vector<float> tpms_health(4); >>> … >>> tpms_health[i] = read_value; >>> … >>> StdMetrics.ms_v_tpms_health->SetValue(tpms_health); >>> >>> You can use "health" and/or "alert" as you like, for example with some user configurable thresholds. The "alert" metric automatically sends respective alert notifications on change. >>> >>> You can test/simulate this manually by using "metrics set". >>> >>> Regards, >>> Michael >>> >>> >>> Am 07.10.21 um 22:53 schrieb Shane @ Kilve Engineering: >>>> Hi Michael, >>>> >>>> I see that ovms has the ability to read and write tpms ID’s >>>> Ive found the pressure, temp's and id’s in the maxus >>>> >>>> Can you give some guidance on how I can get the read and write id’s part added? >>>> >>>> Regards >>>> Shane >>>> >>>>> On 11 Aug 2021, at 18:28, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>> >>>>> Shane, >>>>> >>>>> simple way: override stub OvmsVehicle::CommandHomelink() with your handler. >>>>> >>>>> Extensible way: implement a custom OvmsVehicle::ProcessMsgCommand(), see Twizy vehicle for an example. >>>>> >>>>> Handler Template: >>>>> >>>>> StringWriter res; >>>>> MyScripts.DuktapeEvalNoResult("abrp.send(1)", &res); >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> >>>>> Am 11.08.21 um 19:10 schrieb Shane @ Kilve Engineering: >>>>>> Hi Michael, >>>>>> >>>>>> I would like to use the homelink buttons on the iOS app to start and stop the ABRP scrip "script eval abrp.send(1)” & "script eval abrp.send(0)” >>>>>> >>>>>> I think ive figured out the set up of the hoteling button to get it into the .cpp & .h files but dont know how to call the script from within the CPP file >>>>>> >>>>>> Any help appreciated >>>>>> >>>>>> Regards >>>>>> Shane Hunns >>>>>> Kilve Engineering Ltd. >>>>>> 0792 0729 316 >>>>>> >>>>>>> On 5 Apr 2021, at 16:01, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>> >>>>>>> Shane, >>>>>>> >>>>>>> the standard deviation isn't the distance between the minimum and maximum, it's a measure of variation from the mean value. >>>>>>> >>>>>>> Standard deviation is one of the main basic statistical analysis tools. Read more on this on the web: https://duckduckgo.com/?q=standard+deviation <https://duckduckgo.com/?q=standard+deviation> >>>>>>> >>>>>>> In the battery chart, the standard deviation is shown as the horizontal stripe with light blue background. The maximum standard deviation observed since the last reset is shown by the two blue lines. >>>>>>> >>>>>>> A high standard deviation, especially under load, means a high cell drift = defective / aged / poorly selected pack. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> Am 05.04.21 um 16:40 schrieb Shane @ Kilve Engineering: >>>>>>>> Hi Michael look as the data below, ignoring there is some rounding up done somewhere >>>>>>>> >>>>>>>> Max 4.240 >>>>>>>> Min 4.200 >>>>>>>> >>>>>>>> That’s 40mv deviation >>>>>>>> Stddev showing 4.35mv 0.00435 its one decimal place out >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Shane >>>>>>>> >>>>>>>>> On 5 Apr 2021, at 07:50, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>> >>>>>>>>> Shane, >>>>>>>>> >>>>>>>>> what makes you think so? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 04.04.21 um 20:47 schrieb Shane @ Kilve Engineering: >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> Me again >>>>>>>>>> It look like the bus framework does the calc incorrect? >>>>>>>>>> Surly stddev should be 0.0435 >>>>>>>>>> And stddev.max should be 0.0437147V >>>>>>>>>> >>>>>>>>>> v.b.p.voltage.avg 4.23496V >>>>>>>>>> v.b.p.voltage.grad -0.00026V >>>>>>>>>> v.b.p.voltage.max 4.24V >>>>>>>>>> v.b.p.voltage.min 4.2V >>>>>>>>>> v.b.p.voltage.stddev 0.00435V >>>>>>>>>> v.b.p.voltage.stddev.max 0.00437147V >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Shane >>>>>>>>>> >>>>>>>>>> <Screenshot 2021-04-04 at 19.45.35.png> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 4 Apr 2021, at 13:26, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>> >>>>>>>>>>> Shane, >>>>>>>>>>> >>>>>>>>>>> vector metrics in general can be set by passing a vector or by using the element setters provided (see API). >>>>>>>>>>> >>>>>>>>>>> But you don't need to set the cell max/min/stddev metrics at all, you only need to feed the cell voltages (and/or temperatures). The BMS framework automatically extracts all statistics values from them. >>>>>>>>>>> >>>>>>>>>>> Btw, regarding your cell voltages: >>>>>>>>>>> >>>>>>>>>>>> 748[7c8]:e113 10 90 10 92 10 93 10 93 10 8e 10 92 10 8f 10 90 10 92 10 6c 10 93 10 93 10 8f 10 91 10 92 10 92 10 92 10 92 10 92 10 92 10 90 10 8e 10 90 10 92 10 8d 10 90 10 91 10 8f 10 8e 10 8f 10 91 10 90 10 90 10 91 10 8e 10 91 10 8e 10 91 10 90 10 8e 10 90 10 92 10 90 10 94 10 91 10 91 10 93 10 90 10 91 10 90 10 8f 10 93 10 92 10 8e 10 90 10 91 10 8b 10 92 10 90 10 91 10 8e 10 90 10 90 10 90 10 91 10 90 10 8f 10 90 10 90 10 8e 10 92 10 8e 10 91 10 89 10 91 10 91 10 91 10 8d 10 8f 10 8d 10 86 10 8a 10 8e 10 8f 10 91 10 90 10 92 10 94 10 88 10 8f 10 94 10 91 10 91 10 91 10 93 10 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>>>>>>>>> >>>>>>>>>>> This looks like 96 cells with a factor of 0.001, e.g. 0x1090 = 4240 * 0.001 = 4.24V. >>>>>>>>>>> >>>>>>>>>>> Assuming you fix your IncomingPollReply() handler to actually use the rxbuf string and you copy the RXB_* macros from the Ioniq VFL code, you can simply do this to process the values: >>>>>>>>>>> >>>>>>>>>>> case 0xe113: >>>>>>>>>>> { >>>>>>>>>>> // Read battery cell voltages 1-96: >>>>>>>>>>> BmsRestartCellVoltages(); >>>>>>>>>>> for (int i = 0; i < 96; i++) { >>>>>>>>>>> BmsSetCellVoltage(i, RXB_UINT16(i*2) * 0.001f); >>>>>>>>>>> } >>>>>>>>>>> break; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Doesn't look that hard, does it? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Michael >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Am 04.04.21 um 12:37 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>> morning peeps, sorry for the newbie question whats different about the cell vmax/vmin i see in metrics_standard.h its a vector? >>>>>>>>>>>> (OvmsMetricVector<float>* ms_v_bat_cell_vmax; // Cell maximum voltages [V]) >>>>>>>>>>>> does that mean i have ot handle these different? if so how? >>>>>>>>>>>> as all i get is errors trying to setvalue to this metric >>>>>>>>>>>> >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp: In member function 'void OvmsVehicleMaxed3::IncomingBmsReply(canbus*, uint16_t, uint16_t, uint8_t*, uint8_t, uint16_t)': >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:159:82: error: no matching function for call to 'OvmsMetricVector<float>::SetValue(float)' >>>>>>>>>>>> StandardMetrics.ms_v_bat_cell_vmax->SetValue((float)value2 / 1000); >>>>>>>>>>>> ^ >>>>>>>>>>>> In file included from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle/vehicle.h:40:0, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.h:32, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:32: >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(std::__cxx11::string) [with ElemType = float; Allocator = std::allocator<float>; std::__cxx11::string = std::__cxx11::basic_string<char>] >>>>>>>>>>>> virtual bool SetValue(std::string value) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: no known conversion for argument 1 from 'float' to 'std::__cxx11::string {aka std::__cxx11::basic_string<char>}' >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(const std::vector<_Tp, _Alloc>&, metric_unit_t) [with ElemType = float; Allocator = std::allocator<float>] >>>>>>>>>>>> bool SetValue(const std::vector<ElemType, Allocator>& value, metric_unit_t units = Other) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: no known conversion for argument 1 from 'float' to 'const std::vector<float, std::allocator<float> >&' >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:162:82: error: no matching function for call to 'OvmsMetricVector<float>::SetValue(float)' >>>>>>>>>>>> StandardMetrics.ms_v_bat_cell_vmin->SetValue((float)value2 / 1000); >>>>>>>>>>>> ^ >>>>>>>>>>>> In file included from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle/vehicle.h:40:0, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.h:32, >>>>>>>>>>>> from /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3/src/vehicle_med3.cpp:32: >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(std::__cxx11::string) [with ElemType = float; Allocator = std::allocator<float>; std::__cxx11::string = std::__cxx11::basic_string<char>] >>>>>>>>>>>> virtual bool SetValue(std::string value) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:747:18: note: no known conversion for argument 1 from 'float' to 'std::__cxx11::string {aka std::__cxx11::basic_string<char>}' >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: candidate: bool OvmsMetricVector<ElemType, Allocator>::SetValue(const std::vector<_Tp, _Alloc>&, metric_unit_t) [with ElemType = float; Allocator = std::allocator<float>] >>>>>>>>>>>> bool SetValue(const std::vector<ElemType, Allocator>& value, metric_unit_t units = Other) >>>>>>>>>>>> ^ >>>>>>>>>>>> /Users/shane/Open-Vehicle-Monitoring-System-3-MGEV/vehicle/OVMS.V3/main/ovms_metrics.h:763:10: note: no known conversion for argument 1 from 'float' to 'const std::vector<float, std::allocator<float> >&' >>>>>>>>>>>> make[1]: *** [src/vehicle_med3.o] Error 1 >>>>>>>>>>>> make: *** [component-vehicle_maxus_edeliver3-build] Error 2 >>>>>>>>>>>> shane@Shanes-MacBook-Pro OVMS.V3 % >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Shane >>>>>>>>>>>> >>>>>>>>>>>>> On 3 Apr 2021, at 12:02, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> OVMS# obd can1 request device -t1000 7e4 7ec 2102 >>>>>>>>>>>>> 7e4[7ec] 2102: Response: >>>>>>>>>>>>> ff ff ff ff c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c5 | ................ >>>>>>>>>>>>> c5 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c4 c4 c4 | .... >>>>>>>>>>>>> >>>>>>>>>>>>> OVMS# obd can1 request device -t1000 7e4 7ec 2103 >>>>>>>>>>>>> 7e4[7ec] 2103: Response: >>>>>>>>>>>>> ff ff ff ff c4 c4 c4 c4 c4 c4 c4 c5 c5 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c4 c4 c4 c4 c5 c5 c5 c4 c5 c5 c5 c4 c5 c4 c4 | ................ >>>>>>>>>>>>> c5 c4 c4 c4 | .... >>>>>>>>>>>>> >>>>>>>>>>>>> OVMS# obd can1 request device -t1000 7e4 7ec 2104 >>>>>>>>>>>>> 7e4[7ec] 2104: Response: >>>>>>>>>>>>> ff ff ff ff c4 c4 c5 c4 c4 c4 c4 c4 c4 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 c4 | ................ >>>>>>>>>>>>> c4 c5 c4 c4 | .... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Your voltages obviously are 16 bit values, so you'll need to use RXB_UINT16() and multiply your loop index by 2. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Michael >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Am 03.04.21 um 12:04 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>> Hi has anyone got a sample of the data for the cell voltages on the ioniq vfl just so I can see how the macro is handling it? Or is it played out the same as below? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Shane >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 29 Mar 2021, at 22:20, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am 29.03.21 um 20:17 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>> can any one tell me what the "v.e.c.login" is and is it need for something to work? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> v.e.c.config yes = ECU/controller in configuration state >>>>>>>>>>>>>>> It's not used by the framework currently. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> also any one with any ideas how to deal with cell voltages in a string this long? took me blumim ages to find the bms when the tx and rx are 128 address apart!! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 748[7c8]:e113 10 90 10 92 10 93 10 93 10 8e 10 92 10 8f 10 90 10 92 10 6c 10 93 10 93 10 8f 10 91 10 92 10 92 10 92 10 92 10 92 10 92 10 90 10 8e 10 90 10 92 10 8d 10 90 10 91 10 8f 10 8e 10 8f 10 91 10 90 10 90 10 91 10 8e 10 91 10 8e 10 91 10 90 10 8e 10 90 10 92 10 90 10 94 10 91 10 91 10 93 10 90 10 91 10 90 10 8f 10 93 10 92 10 8e 10 90 10 91 10 8b 10 92 10 90 10 91 10 8e 10 90 10 90 10 90 10 91 10 90 10 8f 10 90 10 90 10 8e 10 92 10 8e 10 91 10 89 10 91 10 91 10 91 10 8d 10 8f 10 8d 10 86 10 8a 10 8e 10 8f 10 91 10 90 10 92 10 94 10 88 10 8f 10 94 10 91 10 91 10 91 10 93 10 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Simply loop over the cells contained. Have a look at the buffer macro utils, e.g.: >>>>>>>>>>>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/maste… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/maste…> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Shane >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 5 Mar 2021, at 20:45, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OvmsVehicle::PollSetPidList(m_can1, obdii_polls); >>>>>>>>>>>>>>>>> OvmsVehicle::PollSetState(0); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> needs to be done in your vehicle init, i.e. the constructor after RegisterCanBus(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please read the vehicle_obdii module source for a complete polling example. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am 05.03.21 um 17:59 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>>>> Thanks Michael, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Had a try and ended up with this bit added but return anything >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Where am I going wrong? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Shane >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ******* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #include "ovms_log.h" >>>>>>>>>>>>>>>>>> static const char *TAG = "v-edeliver3"; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #include "vehicle_edeliver3.h" >>>>>>>>>>>>>>>>>> #include "metrics_standard.h" >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> namespace { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> const OvmsVehicle::poll_pid_t obdii_polls[] = >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> { 0x7e3, 0x7eb, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xf194, { 10, 10, 10, 10 }, 0, ISOTP_STD }, //VIN >>>>>>>>>>>>>>>>>> { 0x7e3, 0x7eb, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xe003, { 10, 10, 10, 10 }, 0, ISOTP_STD }, //SOH >>>>>>>>>>>>>>>>>> POLL_LIST_END >>>>>>>>>>>>>>>>>> }; >>>>>>>>>>>>>>>>>> }; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OvmsVehicleEdeliver3::OvmsVehicleEdeliver3() >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> ESP_LOGI(TAG, "Start eDeliver3 vehicle module"); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> RegisterCanBus(1,CAN_MODE_ACTIVE,CAN_SPEED_500KBPS); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OvmsVehicleEdeliver3::~OvmsVehicleEdeliver3() >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> ESP_LOGI(TAG, "Stop eDeliver3 vehicle module"); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> memset(m_vin, 0, sizeof(m_vin)); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> //testing polls >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> void OvmsVehicleEdeliver3::IncomingPollReply( >>>>>>>>>>>>>>>>>> canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain) >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> string& rxbuf = med_obd_rxbuf; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> OvmsVehicle::PollSetPidList(m_can1, obdii_polls); >>>>>>>>>>>>>>>>>> OvmsVehicle::PollSetState(0); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // init / fill rx buffer: >>>>>>>>>>>>>>>>>> if (m_poll_ml_frame == 0) { >>>>>>>>>>>>>>>>>> rxbuf.clear(); >>>>>>>>>>>>>>>>>> rxbuf.reserve(length + mlremain); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> rxbuf.append((char*)data, length); >>>>>>>>>>>>>>>>>> if (mlremain) >>>>>>>>>>>>>>>>>> return; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // complete: >>>>>>>>>>>>>>>>>> switch (pid) { >>>>>>>>>>>>>>>>>> case 0xe003: { >>>>>>>>>>>>>>>>>> unsigned int soh_raw = ((unsigned int)rxbuf[0] << 8) | (unsigned int)rxbuf[1]; >>>>>>>>>>>>>>>>>> float soh = soh_raw / 10; >>>>>>>>>>>>>>>>>> StdMetrics.ms_v_bat_soh->SetValue(soh); >>>>>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // end testing polls >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 5 Mar 2021, at 12:37, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> on OBD polling basics: http://lists.openvehicles.com/pipermail/ovmsdev/2020-December/014758.html <http://lists.openvehicles.com/pipermail/ovmsdev/2020-December/014758.html> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 04.03.21 um 19:45 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>>>>>> Good evening Michael, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Or any one that has the time to help, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Ive now successfully retrieved as much info as I can without polling any info for the maxus, but I have have now found an ecu that responds to pid requests. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> For example if I use the obdii pid scanner I get the loads of data back and I’ve decoded some of it, just need a bit of guidance how to write the code to get the same info >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> A part of a scan is as follows >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Scan complete (7e3 e000-e100) >>>>>>>>>>>>>>>>>>>> Scan started : 2021-03-04 18:32:36 GMT >>>>>>>>>>>>>>>>>>>> Last response: 2021-03-04 18:32:39 GMT >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e000 00 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e001 64 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e002 4b >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e003 26 bc >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e004 00 07 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e005 2f >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e006 2e >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e007 02 00 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e008 01 ff >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e009 02 00 >>>>>>>>>>>>>>>>>>>> 7e3[7eb]:e010 02 00 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I know that e003 is SOH = 26bc = 9916 /100 = 99.16% SOH >>>>>>>>>>>>>>>>>>>> And e002 is a temp 4b = 75 / 10 = 7.5 degrees >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So if some one can help me with an example of how to correctly code this one I can work out the rest, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Ive looked through various vehicles but everyone uses different methods and I can’t seem to get one to work for me. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Any help much appreciated >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Shane >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 15 Feb 2021, at 08:05, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I forgot to mention: if you're working on a new vehicle module, you'll also need to start the bus somewhere in your initialization code. Example: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> RegisterCanBus(1, CAN_MODE_ACTIVE, CAN_SPEED_500KBPS); >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Am 15.02.21 um 08:36 schrieb Michael Balzer: >>>>>>>>>>>>>>>>>>>>>> Shane, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Am 14.02.21 um 16:42 schrieb Shane @ Kilve Engineering: >>>>>>>>>>>>>>>>>>>>>>> can any one help me with a bit of code to retrieve ve some data from ecu can1/6f2 00 4c 00 00 01 97 bc 00 as i cant poll this ecu it just broadcasts when its active, ive tried polling it but does not respond, i need to choose one byte and allocate it to a PID. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I don't know what you mean by "allocating a byte to a PID", but if you want to process frames received directly, simply override IncomingFrameCan1() (or …2/3/4 depending on your bus). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Reduced example: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> void OvmsVehicleXYZ::IncomingFrameCan1(CAN_frame_t *p_frame) >>>>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>>>> uint8_t *d = p_frame->data.u8; >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> switch (p_frame->MsgID) >>>>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>>>> case 0x6f2: >>>>>>>>>>>>>>>>>>>>>> // for example, assuming the SOC is in byte 1: >>>>>>>>>>>>>>>>>>>>>> StdMetrics.ms_v_bat_soc->SetValue(d[1]); >>>>>>>>>>>>>>>>>>>>>> break; >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If you're outside a vehicle context, you can register your own CAN receiver by creating a queue and calling MyCan.RegisterListener(). See the vehicle module for an example. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>>>>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OvmsDev mailing list >>>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OvmsDev mailing list >>>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>>>> _______________________________________________ >>>>>>>>> OvmsDev mailing list >>>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OvmsDev mailing list >>>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>>> >>>>>>> -- >>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>>> _______________________________________________ >>>>>>> OvmsDev mailing list >>>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>>> >>>>> >>>>> -- >>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>> >>> >>> -- >>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

MQTT V3 server problems
by Craig Leres 10 Oct '21

10 Oct '21

My ovms boxes have been posting data to a mosquitto mqtt server for 3+ years but this recently broke. I started out wanting to be able to tell when mqtt data for a particular module was stale but I see now that mqtt itself does not track this. I found an old stackoverflow that talked about an experimental mosquitto plugin to do this but I can't find out anything else about it. Another option would be to add a metric/topic with the timestamp of the last update. I think I need some guidance here. But given my modules no longer are able to connect to the server I need to solve that first. Back the the main issue, the primary symptom is once a minute or so I see: 1633741110: Client <unknown> disconnected: Protocol error. 1633741170: New connection from 108.111.222.33:52860 on port 8883. 1633741170: OpenSSL Error[0]: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca 1633741170: Client <unknown> disconnected: Protocol error. I'm using mosquitto 2.0.10 with lets encrypt certs: listener 1883 localhost listener 8883 certfile /usr/local/etc/letsencrypt/live/xse.com/cert.pem keyfile /usr/local/etc/letsencrypt/live/xse.com/privkey2.pem cafile /usr/local/etc/letsencrypt/live/xse.com/chain.pem I'm not really sure when things stopped working. I was running 2.0.8 until sometime in July when the FreeBSD port upgrade to 2.0.10. So maybe that broke it; or maybe this is related to the lets encrypt ca change? Part of my trouble is I don't really understand how mqtt tls works. My assumption was ovms uses the https cert and needs a cafile or capath that includes the self-signed ca that signed the certs my modules use so I changed cafile: cafile /usr/local/etc/mosquitto/certs/XSE-RootCA-4.crt Does ovms generate its own mqtt cert on the fly? Does tls do somethig else? Comparing the mosquitto config to what apache needs for https, I only see the cert, key, and ca; missing is the chain file. Is the problem that my client (the ovms module) can't validate the *server* cert? I don't think so since the error message ("alert unknown ca") doesn't appear in the mosquitto source and I believe it's openssl code. Suggestions would be appreciated. Craig

2 2

OVMS firmware release 3.2.017
by Michael Balzer 30 Sep '21

30 Sep '21

We need to roll out this release directly to "main", "eap" and "edge", see thread "Urgent TLS root certificate issue (Let's Encrypt)" for details. I've just pushed the tag and rolled out the new build on dexters-web.de. Mark, can you please do the same on openvehicles.com? Changes: 2021-09-29 MB 3.2.017 OTA release - Added VEHICLE_POLL_TYPE_ROUTINECONTROL to UDS (ISO 14229) service identifiers list - MG ZS EV: - Moved to 2 car variants architecture: MG EV A (✔ Zombie mode | ❌ GWM authentication | ❌ Poll BCM) and MG EV B (❌ Zombie mode | ✔ GWM authentication | ✔ Poll BCM) - New commands: drl [on | off] Turn on/off daytime running lights drlauth [on | off] (Only for MG EV A) Do BCM authentication then turn on/off daytime running lights auth [all | gwm | bcm] Authenticate with specified ECU - New metrics: v.e.headlights v.e.cooling xmg.v.bat.voltage.vcu xmg.v.bat.coolant.temp xmg.v.bat.resistance xmg.v.bms.cell.voltage.max xmg.v.bms.cell.voltage.min xmg.v.bms.mainrelay.b xmg.v.bms.mainrelay.g xmg.v.bms.mainrelay.p xmg.v.bms.time xmg.v.bat.error xmg.v.radiator.fan xmg.v.dcdc.load xmg.v.vcu.dcdc.mode xmg.v.vcu.dcdc.input.current xmg.v.vcu.dcdc.input.voltage xmg.v.vcu.dcdc.output.current xmg.v.vcu.dcdc.output.voltage xmg.v.vcu.dcdc.temp xmg.v.m.coolant.temp xmg.v.m.torque xmg.v.ignition.state - Modified metrics calculation: v.e.charging12v v.e.on v.m.rpm v.m.temp v.b.temp - Decreased poll intervals for some PIDs for better performance - Fixed issue where Features page shows unchecked check box but value is actually true - Added notifications when reaching SOC & Range Limit. - Display charge time to reach Full/SOC/Range limit. - Display CCS Charging on App. - Add new features page to select car's BMS firmware release to adjust SOC display. - Zoe: add Kangoo to Renault Zoe vehicle module. - New vehicle: Maxus eDeliver 3 via OBD-II Port (MED3) https://docs.openvehicles.com/en/latest/components/vehicle_maxus_edeliver3/… - Maxus eDeliver3: cell volts and temps added to metrics and polling update. - Maxus eDeliver3: Web interface page added for charging and cell metrics - Vehicle: emit standard events on changing v.c.timermode New events: vehicle.charge.timermode.off -- Vehicle charge timer mode has been switched off vehicle.charge.timermode.on -- Vehicle charge timer mode has been switched on - VW e-Up/OBD: detect charge timer mode New metrics: xvu.c.limit.soc.max -- Charge schedule maximum SOC [%] xvu.c.limit.soc.min -- Charge schedule minimum SOC [%] xvu.c.timermode.def -- Charge timer defined & default [bool] - VW e-Up/OBD: optional BMS auto statistics reset between driving & charging New config: [xvu] bms.autoreset -- yes = enable statistics reset, default no - VW e-Up/OBD: add MFD range estimation as SOH source, add config option for SOH source New metrics: xvu.b.soh.charge -- SOH based on charge energy sum [%] xvu.b.soh.range -- SOH based on MFD range estimation [%] New configs: [xvu] bat.soh.source -- 'charge' (default) or 'range' [string] - VW e-Up/OBD: charge time prediction while not charging & full charge with limit New configs: [xvu] ctp.maxpower -- in kW, 0 = unlimited except by car, used when not charging [xvu] ctp.soclimit -- in %, used as informative limit w/o OBD connection - VW e-Up/OBD: charge start notification delay configuration to accomodate current ramp-up New configs: [xvu] notify.charge.start.delay -- in seconds, default 24 - VW e-Up/OBD: polling control for diagnostic/adaptation sessions New command: xvu polling <status|pause|continue> -- temporarily pause OBD2 polling - VW e-Up: added SOC monitoring log New configs: [xvu] log.socmon.storetime -- days, 0=off - VW e-Up: add topping off charge phase support & timer mode change notification - VW e-Up/OBD: read ignition state from ECU, support v.e.gear & v.e.drivemode (v.e.gear only on 2020 model) - New vehicle: Hyundai Ioniq vFL (HIONVFL) https://docs.openvehicles.com/en/latest/components/vehicle_hyundai_ioniqvfl… - Webserver: support TLS (https, wss) using self-signed certificates - New vehicle: Jaguar Ipace (JLRI) - New commands: echo [<text>] […] -- output text sleep <seconds> -- pause script execution - Scripting API: added OvmsVehicle.ObdRequest() - Vehicle: provide momentary ideal range gain/loss speed as a metric, add charge speed to "stat" output, output "stat" charge ETRs in hh:mm format New metric: v.b.range.speed -- Momentary ideal range gain/loss (charge/discharge) speed [kph] - Vehicle: emit standard events on changing v.e.gear & v.e.drivemode New events: vehicle.drivemode.<n> -- Vehicle drivemode has been set to profile <n> (vehicle specific) vehicle.gear.forward -- Vehicle has been put in forward gear vehicle.gear.neutral -- Vehicle has been put in neutral gear vehicle.gear.reverse -- Vehicle has been put in reverse gear - Scripting/Duktape: new heap memory management using fixed amount of system RAM New config: [module] duktape.heapsize -- in KB, default 512, max 1024 New commands: script meminfo -- output heap memory status (JSON) New API calls: meminfo() -- return heap memory status - TLS: removed expired DST root certificate, added new ISRG root certificate for Let's Encrypt Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 3

20th September 2011
by Mark Webb-Johnson 21 Sep '21

21 Sep '21

Ten years ago today, two Tesla Roadster owners met up in Hong Kong and decided to work on a small hobby project. Building on the foundational work of a SMS-only telemetry project, we brought in the designer of that to create what today has grown into OVMS; the Open Vehicle Monitoring System. Over the subsequent weeks we built a small PIC based microcontroller with a single CAN bus, mounted that on SIMCOM 2G cellular evaluation board, coded a simple server, and wrote Apps for Android and iOS. On 22nd October, we announced it to the world, with the following post (on the Tesla Motors Club forums): https://teslamotorsclub.com/tmc/threads/open-vehicle-monitoring-system.6655… <https://teslamotorsclub.com/tmc/threads/open-vehicle-monitoring-system.6655…> Open Vehicle Monitoring System Why? We are a group of enthusiasts who want an interface to be able to talk to our cars remotely, perhaps add on-car displays (such as heads-up speed), and we want to have fun doing it. What is it? The Open Vehicle Monitoring System is three things: A low-cost module that fits in the car. It is powered by the car, talks to the car on the CAN bus, and uses the GSM cellular network to talk to its user. A server. The car module can be configured to either talk to the server (via UDP/IP or TCP/IP over the Internet) or the user directly (via SMS). A cellphone App. This talks to the server (via TCP/IP HTTP protocol) to retrieve messages from the car and issue instructions. Part [1] is all that is required. You can use a cellphone and SMS messages to talk to the App. It requires a SMS messaging plan on the SIM card in the GSM modem in the car. Parts [2] and [3] provide a much more seamless and powerful experience, but are optional. It requires a small data plan on the SIM card in the GSM modem in the car. Even if you choose [2]+[3], you can still use [1] as well (for initial setup as well as ongoing on-demand). The Car Module The car module is the hard part. We require an extremely reliable and low-power module to fit in the car. While it is relatively simple for a hobbyist to create one of these, the hard part is making a common platform that a group of hobbyists can get behind, and to make it very high quality. Home-soldered connections and US$100k electric cars don't go well together. What we've done is take the foundational work done by fuzzy logic and others, to build a base platform module. We've then negotiated with factories in China (we live just over the border in Hong Kong) to get this professionally built. The module plugs into the car DIAG port, which provides both power and a CAN bus connection that the module can transmit/receive messages on. The platform itself is based on a PIC18F2680 processor and SIMCOM GSM module. Factory built and assembled, but based on an open source extendable architecture. You can either buy these modules pre-built, or build your own. Any profits on the sale of hardware will got to charity. The SIMCOM GSM module has the ability to send/receive SMS messages, as well as a built-in IP stack for GPRS communication. It allows the module to talk both communication protocols with very little PIC software required. We decided to use these modules (rather than USB modems) for reliability reasons, as well as the SIMCOM built-in support for IP protocol. The attached picture show the initial prototype we worked with. The square board is the prototype CPU + CAN controller based on Fuzzylogic's design. This is a rough proof-of-concept prototype, but you can see the quality of factory production we're getting. The final version re-works the CPU+CAN board to be rectangular and fit as a plug-in piggy-back on the SIMCOM module we've sourced. We've also re-worked the board layout to separate the CAN bus across a cicuit-board divide (to keep the CAN signals very simple and physically separated from the rest of the components). In the final version, we also extend the unused I/O pins of the CPU out on expansion pins (to allow for such things as in-vehicle displays). It all fits in a small case, is extremely low power, and has two LEDs for diagnostics and a windscreen / rear window stick-on GSM antenna for optimal reception. Overall, the design is very elegant and extremely robust. The in-car module can be configured to just be a passive listener on the CAN bus, but can also be an active participant and transmit control messages onto the bus. It can even just relay CAN bus messages over the Internet to the Server/App. It is very flexible and has enough RAM and ROM to do some interesting things. Users can either follow the schematics to build their own compatible boards, or buy them pre-made from us. We expect to be able to charge just US$99+shipping for pre-assembled in-car modules (the CPU+CAN controller module, SIMCOM GSM module, car DIAG cable, housing box and GSM antenna). This is a non-profit endeavor, with any profits inadvertently made being donated to charity. The Server The server is a simple open source server which talks two protocols - one to the car and the other to the cellphone App. The car protocol is built on UDP using encrypted communication packets. Two passwords are used - one to talk to the server and the other to talk to the App. If the car module wants to send a message to the server, it uses the first password. Once the server receives the message, it can decrypt and act on the instruction contained. Communications of this type are used for network registration and PUSH notification messages to Apple/Android phones, or other alerts. If the car module wants to send a message to the user, it uses the second password. The server has no ability to decrypt such messages, so merely passes them on to the cellphone App transparently. The cellphone App itself decrypts and acts on the message. In this way, as only the car module and cellphone App have the password, the server has no way to spy/eavesdrop on these messages. Communications of this type are used for such things as car GPS location updates. The server also includes a web interface for basic functions such as setting the password, registering the car and checking status. The CellPhone App The API to the car and the server is open and will be published. Anyone can write to it, and we hope they will. Initially, we intend to release a standard iPhone and Android App, but anyone is welcome to follow the API and write their own. A screen shot of the prototype iPhone App we are working on is attached. Open Source The entire project will be open source - from the hardware schematics to the APIs to the car and server firmware. We will be loading up what we have onto github within the coming few weeks. The purpose of this project is to get the community of Tesla, and other, tinkerers to be able to expand the project. We can't do it all, and there is so much to do. What we are doing is providing an affordable and flexible base that the community can work on and extend. Everything is open, and APIs are public. Other car modules can talk to the server, and other Apps can show the status and control the car. This will be a foundation that will hope others will interface to and and build upon. When will it be ready? We have been working hard on this for the past couple of months. Initial prototypes have been made and tested; and we are very happy with the choice of factory and their work. The hardware design is now being finalized and we will soon be ready to start the first production run. If there is sufficient interest, final hardware will be available within the next two-to-three weeks. If we can't get sufficient interest, we'll just build it for ourselves and not worry about the larger community. How does it compare to the Tesla Tattler? The Tattler will be an off-the-shelf product offering a purely-SMS controlled solution to controlling roadster charging (as well as other such functions). It is built on some fairly sophisticated hardware and requires no user 'tinkering' to get it working. From our understanding, you just plug it in and play. It connects to the car in the same way as OVMS, but the cellular modem is very different. This project is as an open-source extensible framework based on SMS and UDP/IP control, for enthusiasts. It is designed to be controlled by SMS, websites and/or cellphone Apps. Thanks So many people to thank. W.Petefish for sourcing the car connector, Fuzzylogic for the original hardware and software design and demonstration of it working, Scott451 for figuring out many of the Roadster CAN bus messages, and many others for showing that this kind of thing can work in the real world. Please help us by answering the survey, so we can gauge interest. Any questions? Ask away... Thanks, markwj and foxium. OVMS has come so far since those early days, and that is thanks to our community. We’ve grown to 3.5MB of firmware (up from the original fitting in 64KB), with support for about two dozen vehicle types. Over the years we have had 50 developers directly contribute to the project, and currently another 150 or so indirectly helping out. So, ten years later; happy birthday, OVMS. And a huge thank you to everyone involved. Regards, Mark.

5 4

Duktape heap memory management
by Michael Balzer 08 Sep '21

08 Sep '21

Everyone, the poor JSON encoding performance reminded me of another issue we've had with Duktape since integration: the overall slowly degrading performance of the whole system over time. I did some new analysis on this effect using the task monitoring, which showed it's become worse lately up to the point where Duktape needs more than a second to perform the garbage collection after just 24 hours of uptime. It turned out this effect is also one of the major causes for the very bad JSON encoding performance, i.e. needing up to 10 seconds for a simple object of 5 x 1440 values, and eating 15-20% of CPU time on a permanent base (instead of the tolerable 5-6% right after boot). Doing a "script reload" would help, but only temporarily and not near the point of a freshly booted system. I didn't find anything about such an effect for Duktape in general, so I turned to examining possible ESP32 specific causes, and finally found the culprit: the esp-idf memory management, or more precisely, it's issues with fragmentation in SPIRAM. Duktape is probably one of the main fragmentation drivers due to the nature of Javascript memory management (garbage collection). There has been some discussion on this by neoniousTR, who also was involved in the SPIRAM bug hunt: https://www.esp32.com/viewtopic.php?t=8628 The dlmalloc adaptation of neoniousTR unfortunately isn't usable for us, as it exceeds our available IRAM. It also was based on a much earlier esp-idf release, and doesn't support the extensions and options we use. Espressif have introduced a new memory manager to address these issues, but only in esp-idf release 4.3. We'll need to go there one day, but that's nothing we can do short term: https://github.com/espressif/esp-idf/releases/tag/v4.3 → "Heap: Switched heap algorithm to one based on TLSF, improves performance especially when using a high number of allocations in PSRAM" So I've tried another option: I've removed the Duktape heap from the standard system memory management. I've added a separate umm_malloc instance just for the heap, which can work very fast because it doesn't need to take care of locking or poisoning. On Duktape startup, a fixed amount of SPIRAM gets allocated for the Javascript heap. The amount is 512 KB by default, which should be sufficient for most cases. I've added a configuration for this, config module duktape.heapsize, and a meminfo command to provide some insight. The results are: * Overall Duktape speedup of at least factor 3, up to factor 8 * Garbage collection runs now need below 100 ms even with large scripts running * Duktape average CPU usage dropped to 1-2% * Barely noticeable overall performance degradation after a week of continuous operation Of course, your mileage may vary, feedback is welcome. It still degrades, which is kind of expected, as Duktape isn't the only system component doing dynamic memory allocations. I think esp-idf 4.3 may offer a significant overall performance increase for us, just by replacing the current memory management by a more sophisticated implementation. As a side effect, JSON encoding is now much faster (by up to factor 8). CBOR has become only about 30% faster, which is probably due to CBOR needing much less memory allocations. CBOR is still factor 3 faster on average than JSON, so still the preferred choice for storage & transmission. Details & code: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/1bc… Note: there are three new Kconfig variables that need to be set to enable the new Duktape memory management. The sdkconfig.default.hw31 includes the new configuration, if doing a "make", simply accept all defaults. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 14

Duktape JSON vs. CBOR serialization performance
by Michael Balzer 31 Aug '21

31 Aug '21

Everyone, when debugging some lost events due to Duktape queue overflows, I stumbled across a major Duktape performance issue in the JSON serialization support: encoding the AuxBatMon history data object of 5 arrays with 1440 numbers each (JSON size ~ 30 K) took ~ 12 seconds. I searched the Duktape repository for this and found a "fastpath" optimization we can use but didn't enable, so I tried that: that took down the encoding time to ~ 8 seconds. Unfortunately, that's as good as it gets with JSON in Duktape. So I checked the CBOR support (https://duktape.org/guide.html#builtin-cbor) and that works much better. Encoding the AuxBatMon history to CBOR takes ~ 500 ms. That's still not really good, but acceptable. To enable using CBOR for data exchange with the web frontend as well, I've included the CBOR-JS library by Patrick Gansterer, and added a binary output option for Javascript commands. I've changed the AuxBatMon and PwrMon plugins to use CBOR instead of JSON, and both work and load much faster now. I strongly suggest updating the plugins if you use them. If you implement a plugin with some kind of data storage or transfer of larger objects to the web frontend, do not use JSON, use CBOR instead. I've added a section to our manual on this: https://docs.openvehicles.com/en/latest/userguide/scripting.html#cbor Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

Re: [Ovmsdev] OVMS v3.3 hardware
by Derek Caudwell 21 Aug '21

21 Aug '21

There is a software host usb solution for non-S2 chips here: https://esp32.com/viewtopic.php?t=19949 Not sure how thoroughly it has been tested though...

1 0

Re: [Ovmsdev] OVMS v3.3 hardware
by Derek Caudwell 20 Aug '21

20 Aug '21

I was thinking along these lines, https://github.com/chegewara/esp-idf/tree/master/examples/peripherals/usb/t… https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference… by using the usb lines to transfer data the current Uart level shift is not needed and it does not rely on the simcom firmware supporting gsm multiplexing on the serial interface.

2 1

Re: [Ovmsdev] OVMS v3.3 hardware
by Derek Caudwell 19 Aug '21

19 Aug '21

For future versions of the daughter board (and main) is it worth adding the USB D+- lines and move away from the Uart interface?

2 1

Re: [Ovmsdev] GPS location glitch (flatbed theft false alert)
by Craig Leres 17 Aug '21

17 Aug '21

Wow, this is a good bug; got another one today (see attached). Is there a reasonable strategy for suppressing these? I'm happy to share recent server logs offline (but I don't post them to the internet/list). Craig

4 12