- OvmsDev - Open Vehicles

DA26 breakout
by Mark Webb-Johnson 07 Apr '19

07 Apr '19

If you have work to do on this DA26 expansion ports, this is pretty cool and well built: https://www.aliexpress.com/item/26-Pin-D-SUB-DB26-3-Rows-Serial-Parallel-Po… <https://www.aliexpress.com/item/26-Pin-D-SUB-DB26-3-Rows-Serial-Parallel-Po…>

2 3

Android App v3.12.2 in Play Store
by Michael Balzer 07 Apr '19

07 Apr '19

Whoa. Our first public App update since …drumroll… June 2014 :) I didn't get any bug reports for my 3.12.2 beta release, so I just finished some last details and uploaded it. May take some hours to appear in the Play Store. As change history has grown a bit beyond the allowed 500 chars for the release info, I've added a history page to the Wiki: https://github.com/openvehicles/Open-Vehicle-Android/wiki/History I'm afraid it's just the condensed gitlog though. I hope users won't get confused, sure could need some refinement. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

10 47

Kia e-Niro
by Geir Øyvind Vælidalo 06 Apr '19

06 Apr '19

Hi guys, I’ve sent a pull request with the support for the new Kia e-Niro. It is mostly on the same level of functionality as for the Kia Soul, with the exception of the estimated range! Everything needs to be polled in this car, so it has been quite time-consuming to find all the other data. I’ve found a ton of fun commands to control everything from the lights to the power seats, but the range is nowhere to be found :-( I’ll try to update the user guide and the list of supported metrics as soon as I can. BTW, as I have had the «pleasure» of going through the setup process a few times the last couple of months, I must say the process has become really slick! Well done! Best regards, Geir

2 1

Tesla Model S & X
by Mark Webb-Johnson 06 Apr '19

06 Apr '19

After months of stagnation, I am finally making some progress on Tesla Model S and X support. As a start, tonight’s edge update decodes the elusive estimated and ideal ranges. These cars are incredibly complex. Dozens of modules, 4 active CAN buses, an Ethernet network, two displays, and one of the busiest CAN buses I’ve ever seen. The CAN messages themselves are often packed tightly on bit (not byte) boundaries, so real hard to find the individual information items. The architecture itself is quite neat. There is a freertos based CAN gateway at the back of the Centre Information Display (CID). That takes all the CAN buses and gateways them to a single Ethernet connection joining the infotainment and other control systems. If the CID wants to transmit on the CAN bus (for example, to lock/unlock the doors), it sends a command to the gateway that converts it to a CAN bus message. Incoming CAN bus messaged get converted to UDP broadcasts. There is a great diagnostics tool built into the CID, but it is locked down by strong encryption. Rather than tear down my wife’s car, I think this is a better solution: It came from a scrapped, insurance written-off, Model S. I’ve also got this, but not much use for what I am doing at the moment. It didn’t take long to break into the diagnostics displays: And that is my first new message decode - the display SOC%, as well as rated and estimated ranges plus Wh/mile consumption. There is a huge amount of information there. Like the Tesla Roadster 1050 displays, on steroids... Hundreds of messages, all coming off the Ethernet. At the moment, the car is not connected, so I am just looking at messages from the MCU and Gateway themselves. But even that is close to 80 messages. I can see the values transmitted, and bus they are transmitted on, but no idea of CAN ID#, data length, or encoding. So, it is painstaking going through them one by one. The MCU messages themselves are a summary of car status, and look pretty good. Because they are isolated on the bench, it is relatively easy to work with them as a starting subset, and I am concentrating on the ones useful to OVMS (battery status, charge status, etc). It seems we have full charge status available, including supercharging, and the reason for charge termination. Once I’ve got the MCU messages decoded, it will be time for: $ nc mycar.local 3000 | nc bench.local 3000 to send all the data from the car to the bench and see what is displayed. I can then mess with the messages (fuzzing) to try to identify IDs and then data. The result of this work should be full OVMS support, and three DBC files describing the data. It would be much easier to have OVMS directly connected to the Ethernet, but Tesla will probably at some time lock that down, and it is so troublesome to take the dash apart to man-in-the-middle that. Regards, Mark.

2 1

Fasttech stock status
by Michael Balzer 01 Apr '19

01 Apr '19

Mark, any idea when the modules will be in stock again? Until a few days ago it was just the EU kit, so users could assemble the base module + modem, but now the base module is also sold out. Thanks, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 4

Hologram spacebridge (IP tunnel)
by Michael Balzer 31 Mar '19

31 Mar '19

FYI: after recognizing it's free I just tried the hologram spacebridge tunneling. Both http (+ws) and ssh work via the tunnel, they're just very slow. I think the bad speed is mostly due to the very slow PPP implementation. The web framework will run into timeouts on many page requests, but once loaded is in fact usable. Executing commands via http /api/execute works nicely. The ssh connection works even better, just feels like good'ol GPRS. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Revised RegisterCommand arg defaults
by Stephen Casner 16 Mar '19

16 Mar '19

I have made a widespread commit to flip the sense of the default value for the 'bool secure' argument in RegisterCommand() to be true rather than false. Very few instances of RegisterCommand() took advantage of the argument defaults because 'secure' defaulted to false when most instances needed true. In addition, the default for the 'max' arg was INT_MAX whereas most instances should have max = 0, so that default is also changed. And lastly, a new default value NULL was added for the 'execute' function pointer. It was not necessary to change any of the calls to RegisterCommand() other than those that used the secure = false default. However, I decided to go ahead and review all the instances in the code and change them to make maximal use of the arg defaults so that the existing code can serve as a useful pattern for the addition of new commands. In particular, for secure, non-terminal commands, such as the top-level "framework" commands, the model should simply be: RegisterCommand("name", "Title"); For secure, terminal (sub)commands that don't require any additional parameters, the model should be: RegisterCommand("name", "Title", execute); This model also applies if the command has children but the command itself wants to execute a default operation if no subcommand is specified. It is incorrect to specify min = 0, max = 1 to indicate an optional subcommand; that is indicated by the presence of the execute function at the same time as a non-empty children array. The default usage string will list all the children. Any command with required or optional parameters should provide a usage string hinting about the parameters in addition to specifying the min and max number of parameters: RegisterCommand("name", "Title", execute, "usage", min, max); I found several instances of commands with parameters that left the usage string empty. If you recognize some of these as yours, please add hints for the parameters in the usage string: cmd_ecu->RegisterCommand("list","Show OBDII ECU pid list",obd2ecu_list, "", 0, 1); cmd_re->RegisterCommand("list","List RE records",re_list, "", 0, 1); cmd_dbc->RegisterCommand("list","List RE DBC records",re_dbc_list, "", 0, 1); cmd_discover_list->RegisterCommand("changed","List changed records",re_list_changed, "", 0, 1); cmd_discover_list->RegisterCommand("discovered","List discovered records",re_list_discovered, "", 0, 1); cmd_test->RegisterCommand("strverscmp", "Test strverscmp function", test_strverscmp, "", 2, 2); The following one includes a usage string, but since the parameter is optional (indicated by min = 0), the usage should be "[<url>]", so I made that change: cmd_otaflash->RegisterCommand("http","OTA flash http",ota_flash_http,"<url>",0,1,true); The iMiEV and Kia Soul command hierarchies marked the top-level command as secure but all the subcommands as not secure. This does not make sense as the subcommands could not be reached if not enabled. Furthermore, a subcommand to unlock the doors should be secure indeed. This commit changes all the subcommands to be secure. Similarly, the 'status' subcommands for 'server v2' and 'server v3' were marked not secure, apparently with the intention of letting the status be examined without enabling, but the top-level commands were marked secure so the status command could not be reached. The status subcommands are now marked secure. -- Steve

1 0

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 10 Mar '19

10 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 10 Mar '19

10 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