- OvmsDev - Open Vehicles

TPMS Bug in ovms_server_v2.cpp?
by Chris van der Meijden 09 Mar '20

09 Mar '20

Hi all, as I can't find the CAN-ID's for TPMS for the VW e-Up at the moment, I thought I just disable the feature, so the app won't display the TPMS boxes unnecessarily. In OVMS v2 this was possible by setting car_stale_tpms = -1 so the last number sent by the "W" message to the server was -1. With that -1 the app will not display the TMPS boxes. The code in ovms_server_v2.cpp for the message is now extram::ostringstream buffer; buffer << "MP-0 W" << StandardMetrics.ms_v_tpms_fr_p->AsString("0",PSI) << "," << StandardMetrics.ms_v_tpms_fr_t->AsString("0") << "," << StandardMetrics.ms_v_tpms_rr_p->AsString("0",PSI) << "," << StandardMetrics.ms_v_tpms_rr_t->AsString("0") << "," << StandardMetrics.ms_v_tpms_fl_p->AsString("0",PSI) << "," << StandardMetrics.ms_v_tpms_fl_t->AsString("0") << "," << StandardMetrics.ms_v_tpms_rl_p->AsString("0",PSI) << "," << StandardMetrics.ms_v_tpms_rl_t->AsString("0") << ((stale)?",0":",1") ; Transmit(buffer.str().c_str()); and that gives no room for sending a -1 as far as I understand it. Is this a bug, a feature, or am I missing something? Thanx for help Greetinx Chris

2 3

WifiConsole V1.0
by Michael Balzer 04 Mar '20

04 Mar '20

FYI: I've just implemented an OVMS v3 style replacement for the SimpleConsole: https://github.com/dexterbg/WifiConsole V3 makes it pretty easy now to add stuff like this. It's using a script plugin to provide custom functions via the web API. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 28

E-niro notifications
by Mark Webb-Johnson 01 Mar '20

01 Mar '20

Can someone familiar with e-niro have a look at this: https://www.openvehicles.com/node/2450 <https://www.openvehicles.com/node/2450> The user is getting a large number of ’Not charging’ notifications, while driving. He thinks it might be related to regen. Thanks, Mark.

1 0

Website changes
by Mark Webb-Johnson 29 Feb '20

29 Feb '20

I’ve released a bunch of changes to the theme and design of the www.openvehicles.com <http://www.openvehicles.com/> website. Trying to make it more informative to new users. It is about half done (still got to do the pages for existing users, links, etc), but live now. Regards, Mark.

2 1

Paranoia
by Mark Webb-Johnson 24 Feb '20

24 Feb '20

Reviewing the OVMS v3 code, I found that v2 protocol paranoid support was not there. Not sure why it was overlooked (perhaps because I hate it both from a crappy encryption, as well as support headache, point of view). I’ve added it back in today. It shouldn’t affect normal module-server-app connections at all. It has had only cursory testing, but seems to work. It is enabled by ‘config set server.v2 paranoid yes’, and ensuring that the module password is the same in the app and on the module. The default is off. I suggest to keep this as a command line option, as it really makes support even more of a headache than it already is. If users know what they are doing, they can enable it themselves (and support themselves). I do notice a bug in the ovms_server.pl code when switching from normal to paranoid; the normal messages are not removed from the database (they should be) - I’ll try to address that in the new server code. Regards, Mark.

1 0

Pushover
by Tamás Kovács 20 Feb '20

20 Feb '20

I updated my fork with the main repo and now pushover not working. I send a test message, and get the following in logs: I (548904) webserver: HTTP GET /cfg/notification I (553254) webserver: HTTP POST /cfg/notification I (553284) pushover: Sending message teszt with priority 0 E (570654) mongoose: mg_ssl_mbed_log 0x3fa44e14 mbedtls_ssl_fetch_input() returned -1 (-0x0001) E (570654) mongoose: mg_ssl_mbed_log 0x3fa44e14 ssl_get_next_record() returned -1 (-0x0001) E (570654) mongoose: mg_ssl_mbed_log 0x3fa44e14 mbedtls_ssl_read_record() returned -1 (-0x0001) E (570654) mongoose: mg_ssl_if_mbed_err 0x3fa44e14 SSL error: -1 I (570654) pushover: PushoverMongooseCallback(MG_EV_CONNECT=-3:) E (570654) pushover: Connection failed I (570664) ovms-server-v2: Send MP-0 PIConnection failed

2 1

General suggestions for adding support for a new vehicle to OVMS
by Mark Webb-Johnson 19 Feb '20

19 Feb '20

I created this forum post, which some may find helpful. Please feel free to add comments to it (at the link below) to feedback your experience and suggestions. General suggestions for adding support for a new vehicle to OVMS <https://www.openvehicles.com/node/2437> Before we start, I would like to say thank you. Your time is valuable and your contributions are appreciated. OVMS is an open source community project, and we rely on our developers to take this project forward. New vehicle support comes from the owners of those vehicles developing that support, along with the help of other experienced developers working on other vehicles or framework components. We work together to extend the project. The first step is to sign up for the developer's mailing list, and let people here know that you are working on a particular car. Perhaps other owners are also interested and can help. Next is physical hardware reconnaissance. You need to find out what sort of communications buses your car has, what vehicle modules (ECUs) are connected, what speed the buses run at, where the diagnostic connectors are, and what each pin does. The OBDII connector is pretty standard in modern cars, but is often not the only connector. It is often common to see many different types of communication buses such as CAN, LIN, K-Line, and others. Of particular interest is any communication buses connecting the car to its user visible displays or telematics modules. Google is your friend here. You can also look for service manuals, or talk to your friendly mechanic. The absolute last resort is to get out a multimeter, trace cables and measure signals. For OVMS, you are in particular looking for CAN bus networks. The next step is to look for documented signals on those communications buses. Network traffic is commonly either polled (the diagnostic tool sends a request for a particular piece of information, and the vehicle module replies with the current value), or active (the information is broadcast repeatedly, usually at a set interval). Most cars use a combination of both. Sometimes these are published as online resources on enthusiast websites, and other times the manufacturer or diagnostic tool supplier has the information. There are standardised formats for this (such as DBC for active networks, and PIDs for polled). You then need to look for existing diagnostic screens and information. As well as the general user interface of the car (temperature displays, speedometer, etc), there may also be maintenance screens and lower level diagnostics. These are incredibly useful for the work you will be doing. OK, now it is time to step away from the Internet and go to the actual car. You are going to want to record the traffic on the car communication buses, while doing different activities (such as charging the car, parked idle, driving, reversing, turning, etc). We call these "CAN bus dumps". Write down notes next to each dump, describing what you were doing, where, when, and what the key metrics shown in the car were (state of charge, odometer, speed, type of charge, charge rate, etc). The tools I use for this are OVMS (with an appropriate cable to connect it to the car networks) and SavvyCAN (a cross platform application you can run on a laptop) - you can connect the two over WiFi. It is a good idea to have the car reachable by wifi, which allows you to do a lot of work from inside your house (rather than in the driver's seat with the laptop propped up on the steering wheel). Now is the time to look for specific metrics. You can find the full list in the OVMS documentation, but we suggest you start with basic things like car on/off state, gear selection, speed, State of Charge (SOC), range displays, etc. I always go for SOC as my first target, as it gives instant gratification. At this stage, you will be looking for a particular metric, and you are going to be comparing what signals are on the car's communication buses against what is displayed on the car's diagnostic display. This may not be a 1-to-1 relationship. For example, the odometer may display to the nearest kilometre, but the metric on the car communication bus may be in 1/10ths of a mile. Other metrics are in floating point, or different byte orders. Often the change in a metric is the biggest clue - a SOC would increase during a charge and decrease during a drive, for example. SavvyCAN can help with this. When a door opens, you would expect the appropriate signal on the CAN bus to change appropriately. Once you've found a few metrics, it is time to add support. You will need some programming knowledge here, and be very familiar with computers. We use the C++ language, which is like C on steroids - vehicle modules are not complex and there are plenty of example vehicles to learn from. Setup your build environment (the developer's guide has the detail for this), clone the OVMS firmware to your own GitHub account, and try to build the standard firmware and flash it to your module. Then, add a stub for your vehicle. Just a piece of code that allows you to select the vehicle but does nothing (you will create components/vehicle_ and modify main/Kconfig to add it as an optional vehicle). Modify your vehicle module to initialise the appropriate CAN bus support, and decode the metrics you know. Flash it to your module, then fire up the App and get the instant gratification of being able to see your battery level (for example). You won't have every metric supported at this time - just get a few working and you'll be encouraged to find more. Now it is time to contribute. Add, commit, and publish your changes to your own GitHub repository, then use the GitHub tools to send in a pull request (for us to merge your code back). Please don't forget to add some documentation, so others can share in what you have achieved. From that point on, it is an iterative journey. Discovering and adding more metrics, and then starting to look for things like door lock/unlock functionality, etc. I find this a fascinating journey - the process of discovery is to me even more rewarding than the final vehicle support. Again, thank you for your contributions, and happy hacking! Mark.

2 1

SSL Support
by Mark Webb-Johnson 18 Feb '20

18 Feb '20

Given that we use the mongoose library for most of our stuff, adding SSL support should not be hard. This would finally bring strong encryption and server side authentication. Given the number of attacks now on IoT devices that would not be a bad thing. I think what we need is: A set of helper functions to make it easier for components to use SSL. Build on top of mongoose. A way to manage a list of trusted Certificate Authorities, including adding to the trusted list via: Components providing Certificate Authorities in firmware. Certificate Authorities in configuration. Extensions to ovms_server_v2 to support an SSL connection option. Extensions to ovms_server_v3 to support an SSL connection option. Extensions to the Ovms Server v2 code to support an SSL connection listener. Extensions to the iOS App to support an SSL connection option. Extensions to the Android App to support an SSL connection option. Migration of any components already supporting SSL to this new standardised approach. Then we can open up the discussion of the whole thing of passwords. We have far too many of these at the moment (user account+password, vehicle ID, server password, module password, hologram account+password, etc). Once we have an encrypted connection, we don’t need to use the password for encryption, but merely for authentication. That simplifies things, as we can perhaps just use the user account+password for most things (giving access to all vehicles registered under that user account - in a similar way to MQTT does it already for ovms_server_v3). I will take on the majority of this project. I can do #1, #2, #3, #4, #5, and #6). If anyone has any feedback on requirements, please let me know. Regards, Mark.

3 15

"Vehicle is idling": A new "Feature"?
by Greg D. 18 Feb '20

18 Feb '20

Hi folks, I'm starting to get an alert "Vehicle is idling / stopped turned on" when my Roadster is charging. Seems to occur every hour. Is this something new with OVMSv3, or did something change / break on my car? Greg

3 13

MBEDTLS
by Mark Webb-Johnson 17 Feb '20

17 Feb '20

Some issues with our MBEDTLS: We have '#define MG_SSL_IF_MBEDTLS_MAX_FRAG_LEN 2048’ in our mongoose mg_tocals.h and that overrides the maximum message fragment set in sdkconfig. Result was we can’t connect to any server that sends more than 2048 bytes in it’s handshake (and supports the max fragment length option). Fix is to simply remove it, and allow our sdkconfig to work. Our mbedtls by default doesn’t debug anything, including warnings. That makes it very hard to find problems (like #1, above). I changed it (in ovms_tls component) to log at level #1 (just warnings and errors), which should be fine. I think that also needs 'CONFIG_MBEDTLS_DEBUG=y’ in sdkconfig. So, suggest to set appropriately. We should be verifying expired certificates, as our ntp time/date is reliable. So, suggest to set 'CONFIG_MBEDTLS_HAVE_TIME_DATE=y’ in sdkconfig to enable this. All committed and pushed. Regards, Mark.

1 0