March 2019 - OvmsDev - Open Vehicles

Home assistant integration
by Lance Tjessem 11 Mar '19

11 Mar '19

Curious if anybody has considered making a Home Assistant ( https://www.home-assistant.io) integration for OVMS? Read some values from mine just using simple HTTP API requests but it'd be cool to have a proper component for it. I'd do it myself, but I'm not really familiar with Python so it would be slow going.

3 3

Google is going to kill GCM
by Mark Webb-Johnson 11 Mar '19

11 Mar '19

Just found out that google is going to kill GCM (1st April 2019 - surely not a joke?). Presumably that will affect our Android push notifications. Changes don’t seem excessive, and it seems we can still use our old GCM registrations so may be limited to server side for the moment? @Michael are you aware of this issue? Regards, Mark.

2 3

Leaf 30kwh GIDs behaviour on 0x5bc
by Anko Hanse 11 Mar '19

11 Mar '19

Was not happy with the behaviour I was seeing on CAN msg 0x5bc and the GIDs, Battery Energy Available and SOC_newcar we are deriving from them. For some reason it was randomly either show the expected value, and at other times would go to gids=375. Note that gids=375 is a special number: energy = gids * GEN_1_WH_PER_GID = 375 * 80 = 30 kwh !!! So I decided to trace more info on this CAN msg in my 30kwh leaf. Conclusion: - nl_gids actually toggles between current_gids and max_gids - d[5] & 0x10 is the flag that indicates which of these two is in the current message. So on a 30kwh leaf we can derive m_gids, m_battery_energy_available AND m_battery_energy_capacity all from the 0x5bc message! Am still running a trace on 0x59e to see what the exact behaviour there is, but probably we can ignore that message for the 30kwh model. Below trace results show: - d[0]...d[7] raw values, - xm is a typo for the mx multiplexer variable as used for the estimated charge time (d[5] and d[6]) - cur_gids is the nl_gids value (d[0] and d[1]) - exp_gids is an indication of expected gids: 375 * SOC / 100 (without taking SOH into account) - SOC is soc_instrument. During charging: V (3689688) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 78 b7 10 1f ff, xm=0 cur_gids=375 exp_gids=131 soc= 35%[0m V (3689788) v-nissanleaf: CAN1 0x5bc = 1d 80 f0 78 b7 00 a0 f0, xm=5 cur_gids=118 exp_gids=131 soc= 35%[0m V (3689888) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 78 b7 11 03 2a, xm=8 cur_gids=375 exp_gids=131 soc= 35%[0m V (3689988) v-nissanleaf: CAN1 0x5bc = 1d 80 f0 78 b7 01 64 92, xm=11 cur_gids=118 exp_gids=131 soc= 35%[0m V (3690088) v-nissanleaf: CAN1 0x5bc = 5d c0 50 78 b6 12 5f ff, xm=18 cur_gids=375 exp_gids=131 soc= 35%[0m V (3690188) v-nissanleaf: CAN1 0x5bc = 1d 80 50 78 b6 02 bf ff, xm=21 cur_gids=118 exp_gids=131 soc= 35%[0m V (3690288) v-nissanleaf: CAN1 0x5bc = 5d c0 50 78 b6 13 1f ff, xm=24 cur_gids=375 exp_gids=131 soc= 35%[0m .. and so on with cur_gids=118 and SOC slowly climbing During driving: V (338837) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b7 00 1f ff, xm=0 cur_gids=308 exp_gids=348 soc= 93%[0m V (338937) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 10 a0 3c, xm=5 cur_gids=375 exp_gids=348 soc= 93%[0m V (339037) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b7 01 00 96, xm=8 cur_gids=308 exp_gids=348 soc= 93%[0m V (339137) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 11 60 d2, xm=11 cur_gids=375 exp_gids=348 soc= 93%[0m V (339237) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b7 02 5f ff, xm=18 cur_gids=308 exp_gids=348 soc= 93%[0m V (339337) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b6 12 bf ff, xm=21 cur_gids=375 exp_gids=348 soc= 93%[0m V (339437) v-nissanleaf: CAN1 0x5bc = 4d 00 f0 64 b6 03 1f ff, xm=24 cur_gids=308 exp_gids=348 soc= 93%[0m .. and so on with cur_gids=308 and SOC slowly decreasing Parked overnight: V (14108065) v-nissanleaf: CAN1 0x5bc = 5d c0 8c 64 b6 10 1f ff, xm=0 cur_gids=375 exp_gids=206 soc= 55%[0m V (14108165) v-nissanleaf: CAN1 0x5bc = 2d 80 8c 64 b6 00 a0 b4, xm=5 cur_gids=182 exp_gids=206 soc= 55%[0m V (14108265) v-nissanleaf: CAN1 0x5bc = 5d c0 8c 64 b6 11 02 58, xm=8 cur_gids=375 exp_gids=206 soc= 55%[0m V (14108365) v-nissanleaf: CAN1 0x5bc = 2d 80 f0 64 b7 01 63 66, xm=11 cur_gids=182 exp_gids=206 soc= 55%[0m V (14108465) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 12 5f ff, xm=18 cur_gids=375 exp_gids=206 soc= 55%[0m V (14108575) v-nissanleaf: CAN1 0x5bc = 2d 80 f0 64 b7 02 bf ff, xm=21 cur_gids=182 exp_gids=206 soc= 55%[0m V (14108675) v-nissanleaf: CAN1 0x5bc = 5d c0 f0 64 b7 13 1f ff, xm=24 cur_gids=375 exp_gids=206 soc= 55%[0m ... and so on with no changes to cur_gids and SOC So improved handler code for the 0x5bc message should be something like: if (nl_gids != 1023) { if ( (m_battery_type->AsInt(BATTERY_TYPE_2_24kWh) == BATTERY_TYPE_2_30kWh) && // <-- Not sure if we need this or if d[5] & 0x10 is always 0 anyway on older models ???? (d[5] & 0x10 == 0x10) ) { m_battery_energy_capacity->SetValue(nl_gids * GEN_1_WH_PER_GID, WattHours); } else { m_gids->SetValue(nl_gids); m_battery_energy_available->SetValue(nl_gids * GEN_1_WH_PER_GID, WattHours); // new car soc -- 100% when the battery is new, less when it's degraded uint16_t max_gids = MyConfig.GetParamValueInt("xnl", "maxGids", GEN_1_NEW_CAR_GIDS); float soc_new_car = (nl_gids * 100.0) / max_gids; m_soc_new_car->SetValue(soc_new_car); // we use the instrument cluster soc from 0x1db unless the user has opted otherwise if (MyConfig.GetParamValueBool("xnl", "soc.newcar", false)) { StandardMetrics.ms_v_bat_soc->SetValue(soc_new_car); } } }

2 2

Dead OVMS
by Geir Øyvind Vælidalo 05 Mar '19

05 Mar '19

Hi guys, My newest OVMS-unit just died. It’s the one I use for development on the e-Niro :-( Opening it up, I noticed that the outermost pin on C1 was loose and a few of the pins on the modem was bent. I can’t flash the ESP as it won’t respond at all. Is the quality control good enough? Anyone else got problems with their unit? I have opened at ticket at fasttech, so I hope I can get it sorted out quickly. I had such a good momentum :-( Regards, Geir

2 1

Callout for JDM Nissan Leaf VINs
by Anko Hanse 04 Mar '19

04 Mar '19

This is related to feature requests #180 and #181 (automatic detection of model-year and battery size). For USA and EU style VINs we might have a method of deriving the year and battery size. Unfortunately cars made for the Japanese Domestic Market and frequently imported 2nd hand into Australia and New Zealand do not use a VIN but instead have some sort of serial number in the form of ZE0-123456 or AZE0-123456. I have posted a request on a NZ forum (www.geekzone.co.nz<http://www.geekzone.co.nz/>) for people to email me their JDM style VIN combined with year (and possibly month) and battery size. Note that LeafSpy-Pro also toggles with another VIN-like number, I'm interested in that too if people can get it. If not then just the ZE0- or AZE0- number is fine... Possibly any NZ OVMS users seeing this post can do the same and also email me those details or reply here. For privacy reasons I would suggest to mask the lowest digits of your VINs, i.e: AZE0-2003xx, Dec 2015, 30kwh, 230JT11122000xxx Hopefully that will give us some new insights... I very much hope our collective powers can confirm that ZE0-1xxxxx and AZE0-1xxxxx is 24kwh, AZE0-2xxxxx is 30kwh, AZE1-1xxxxx is 40kwh and possibly AZE1-2xxxxx will be 62kwh :-)

3 14

Power states clarification
by Greg D. 02 Mar '19

02 Mar '19

Hi folks (mostly Mark, probably), I just noticed that there is a power command for OBD2ECU as well as ext12v. I understand (or thought I did) what controlling the ext12v power does, but how is "power" related to OBD2ECU? Is this related to firing up the opened CAN bus, or is there some tie to the ext12v power? I have manually created scripts for vehicle.on and vehicle.off to explicitly control ext12v, so that an attached HUD will follow the key. We talked about having this sort of thing done automatically, but I didn't think it was ever implemented, nor what the particulars would be regarding some of the device corner cases. Is that what is happening here? Related, what do the other states do? (Sleep, deepsleep, etc.) Thanks, Greg

3 3