- OvmsDev - Open Vehicles

Problems ms_v_charge_mode
by Geir Øyvind Vælidalo 02 Dec '17

02 Dec '17

I’m having problems setting ms_v_charge_mode. I do it this way, but it fails at runtime: StdMetrics.ms_v_charge_mode->SetValue( chademo ? "performance" : "standard"); This is the trace I get, so it seems to fail somewhere else: I (6451) events: Signal(vehicle.charge.mGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x400883c3 PS : 0x00060633 A0 : 0x8008708a A1 : 0x3ffc6b30 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130 A2 : 0x3ffc6384 A3 : 0x3ffc6c78 A4 : 0x00060620 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000038 A9 : 0x3ffb33b8 A10 : 0x3ffb131c A11 : 0x00060623 A12 : 0x00060623 A13 : 0x3ffce1ec A14 : 0x3ffce1ec A15 : 0x3ffc6a70 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffa Backtrace: 0x400883c3:0x3ffc6b30 0x40087087:0x3ffc6b50 0x400860f1:0x3ffc6b70 0x4008771b:0x3ffc6b90 0x40087818:0x3ffc6bc0 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130 0x40087087: vTaskPlaceOnEventListRestricted at /Users/goev/esp/esp-idf/components/freertos/./tasks.c:4446 0x400860f1: vQueueWaitForMessageRestricted at /Users/goev/esp/esp-idf/components/freertos/./queue.c:2392 0x4008771b: prvProcessTimerOrBlockTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839 0x40087818: prvTimerTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839 It looks like it has something to do with the Signal event, but I ‘m still not that good using gbd to find out what actually makes this fail. Any one got a clue? Regards, Geir

3 7

Leaf Updates
by Tom Parker 02 Dec '17

02 Dec '17

Hi, I ported over support for Gen 2 Chargers and polling for the battery Ah capacity and the "Hx" value in https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/9 3 Questions: In v2 we checked whether transmit mode was enabled, I'm not seeing similar logic in the Telsa Roadster module. I've commented out the checks in the leaf code for the time being. In v2 I abstracted the hardware interactions necesary to write to the canbus into a function void vehicle_nissanleaf_send_can_message(short id, unsigned char length, unsigned char *data). In v3 we call canbus::Write(const CAN_frame_t* p_frame). Do we want to add a similar simpler "send to this buffer with this can id" method to the canbus object? The Leaf doesn't use any of the extended can features so a simple interface for the simple case seems to make sense. For the moment I've implemented it within the leaf codebase, see void OvmsVehicleNissanLeaf::SendCanMessage(uint16_t id, uint8_t length, uint8_t *data) in the pull request. I've also porting over the remote command features, I like the interface presented to the car modules to implement these. I need to wait until tomorrow to test these on a real car so haven't sent a pull request yet. I'm very close to finished on porting the leaf support!

2 4

Fwd: Fiat 500e Support?
by Mark Webb-Johnson 30 Nov '17

30 Nov '17

Anybody using Fiat 500e, or interested? I can’t find much online. This might be a good test case for what we can do with RE-TOOLS on OVMS v3. Regards, Mark > Begin forwarded message: > > Subject: Fiat 500e Support? > Date: 30 November 2017 at 11:24:52 PM HKT > To: support(a)openvehicles.com > > Hello > > I'm curious if there is any plan for OVMS to support the Fiat 500e? The Fiat factory telematics system deactivates 3 years from the original vehicle sale and is non renewable, so another solution would be ideal. > > I have a 2013 500e with deactivated telematics, and our roommate has a 2014 with working telematics. If any data could be captured from the car with working telematics (branded as Fiat Access) to assist integrating OVMS I'd love to help. > > The Fiat Access telematics provides vehicle location, battery level, tire pressure, setting the charge schedules, locking / unlocking the car, and starting the climate control.

1 0

Real authentication for SSH server
by Stephen Casner 27 Nov '17

27 Nov '17

I have updated the SSH server code in OVMS to remove temporary built-in passwords for jack and jill and public keys for hansel and gretel. Instead there is now real authentication code that fetches passwords and public keys from the config: - We keep the host key for the server in ssh.server:key. If none exists when the server is started then a background task is forked to create one, using the key generator in WolfSSL with entropy from esp_random(), and install it into the config. - The key generation also calculates the SHA256 fingerprint of the host key and stores it in ssh.info:fingerprint so that users can verify the key when connecting from a new client. The fingerprint is displayed when the generation is complete and can be viewed any time with "config list ssh.info". - Passwords may be stored under param password with the instance being the associated username. Alternatively, if there is no password configured for a username then the password stored under instance "module" is used. - RSA public keys may be stored under param ssh.keys with the instance being the associated username. The key format is as generated on a Linux or Mac system by the command "ssh-keygen -b 2048 -t rsa". This could be a key you already have or a new one made for this purpose. Only the one long string of the base64-encoded key should be stored, not including the "ssh-rsa" at the beginning or the user ID at the end. The key is stored with a command like this: config set ssh.keys casner AAAAB3NzaC1yc2EAAAADAQAB...C6p5jcbf4NCnX Public key authentication is really convenient because most client systems allow authenticating the private key once per login on the client and storing the decrypted private key in a key server. Then each session to the OVMS is authenticated automatically without requiring a password to be entered. WARNING: If the config does not contain any passwords (including for "module") nor any public keys, then authentication is considered disabled and any user can log in with no password or a random password. -- Steve

1 0

StdMetrics.ms_v_env_parktime
by Geir Øyvind Vælidalo 27 Nov '17

27 Nov '17

«Quick» question: StdMetrics.ms_v_env_parktime, is it seconds since the car was parked, which means we should update it in Ticker1? Or is it the time when the car was parked? Looking at V2 and the OVMS-V2conversion in V3, it looks to me like the first, but looking at the Twizy-module it looks like the latter. I guess setting the start time should be enough. When sending packets to V2-server, we could easily calculate the seconds: time(NULL)-ms_v_env_parktime. Unless ms_v_env_parktime is 0, then we’re not parked. The same could then be done for ms_v_charge_minutes too. Geir

2 4

Debugging
by Geir Øyvind Vælidalo 22 Nov '17

22 Nov '17

Hi guys! I’ve moved most of the Kia Soul code from V2 to V3. I set the vehicle module and everything is just fine, until I connect it to my car. Then the Kia module crashes. I can’t make out why looking at the little info it prints out. I see some of your are talking about gdb-stub, but I have never used gbd and need some help. How do I debug? What options do I have? Hope someone has a simple guide for a noob like me 😜 Thanks! Geir

3 5

Anybody else having trouble compiling today?
by Greg D. 21 Nov '17

21 Nov '17

Hi folks, I just fetched the latest updates, and I'm getting a bunch of errors in console_ssh.cpp and console_ssh.h. Variables not declared in scope, that sort of thing... I did a 'make app_flash', same as always. Any ideas? Greg

3 4

A promiscous wifi client
by Mark Webb-Johnson 20 Nov '17

20 Nov '17

I’ve committed a change to the esp32wifi component, to try to support a promiscuous mode for the wifi client. This should make it work the way it does on cellphones, computers, and pretty much all equipment. Rather than specifying a specific wifi AP to connect to, it just connects to whichever it can (based on where it has connected to in the past). Up until now, we’ve supported the wifi client mode as follows: config set wifi.ssid <SSID> <password> wifi mode client <SSID> That seems to work well, and reconnection now seems pretty robust. What I’ve committed today supports this variant: config set wifi.ssid <SSID1> <password> config set wifi.ssid <SSID2> <password> … etc wifi mode client The module should then connect to either SSID1 or SSID2, whichever comes into range. I’ve got no idea how phones, laptops, etc, actually implement it, and can’t find much information on the ESP32 resources or forums. There is certainly no magic ‘here is a list of SSIDs - connect to whichever comes close’ function in the wifi libraries. So, I ended up implementing the following logic: Bring up the wifi as a client, in station mode. Every 30 seconds or so, do a wifi scan of available SSIDs. If we find a SSID within range, that has a matching name in config wifi.ssid, we try to actively connect to it. For this, we pick the first SSID we find that matches. If we don’t manage to connect (get disconnected), or there is no SSID in range that matches anything in config wifi.ssid, wait for 30 seconds, then go back and scan again. It’s not elegant, but seems to work. Change is isolated in esp32wifi.{h,cpp}, which is pretty small and manageable at the moment. Please give it a go, and let me know how it works out for you. Regards, Mark. P.S. Also found (and cleaned up) a big stonking memory leak in ‘wifi scan’.

3 14

Wifi with spaces in the SSID
by Tom Parker 19 Nov '17

19 Nov '17

It appears that you cannot set a configuration value with a name containing spaces. It almost works, but it doesn't seem to store them correctly: OVMS > config set wifi.ssid "Wifi With Spaces" secretpassword OVMS > config list wifi.ssid wifi.ssid AndroidAP Wifi With Spaces OVMS > wifi mode client "Wifi with spaces" Error: SSID password must be defined in config wifi.ssid So it thinks it has a configuration value for that network but it doesn't work. When you reboot the OVMS you find that the configuration item was stored with only the first word of the SSID: OVMS > config list wifi.ssid wifi.ssid AndroidAP Wifi

2 2

Random Crashes
by Tom Parker 17 Nov '17

17 Nov '17

Hi, I've got the my v3 OVMS plugged into a car using the hologram sim and cell network for connectivity. I'm updating the odometer metric with the monotonic metric and made the attached graph. I'm assuming the ovms has rebooted each time the graph goes back to zero. The actual connectivity seems pretty good as there aren't many jumps in the graph where data was not being updated on the server, the most obvious one being just before 4am. I think the y axis might be in tenths of a second, as it's only been sending this data for a little less than 24 hours, which is only 86,000 seconds or so. Is it possible to write the logs to an SD Card so when it crashes I can inspect what happened? Otherwise I'll leave it on my desk plugged into my laptop for a while and see if it reproduces there -- the only difference would be the power supply so I'm guessing it will. thanks.

3 2