- OvmsDev - Open Vehicles

Lost flash after 12v battery went flat
by Tom Parker 22 Sep '18

22 Sep '18

My 12v battery went flat and when I got that sorted, my OVMS 3.0 wasn't working. Connecting to the console indicated the flash was corrupt or empty (see below). I did a make flash and it started working. The config store appeared to be empty. $ make monitor MONITOR --- idf_monitor on /dev/ttyUSB0 115200 --- --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) flash read err, 1000 Falling back to built-in command interpreter. OK >ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) flash read err, 1000 Falling back to built-in command interpreter. OK >ets Jun 8 2016 00:22:57

1 0

Fwd: [ovms:2087] Consult on Renault twizy
by Mark Webb-Johnson 19 Sep '18

19 Sep '18

@michael, Could you help this user? I greped for the error text in OVMS v2, v3 and Android, source code, but can’t find it. Regards, Mark. > Begin forwarded message: > > bricoauto has created the ticket 'Consult on Renault twizy': > https://www.openvehicles.com/node/2087#comment-0 > State: new > Priority: normal > > You can visit the following URL to update this ticket: > https://www.openvehicles.com/node/2087#comment-form > > Ticket text: > ------------------------------ > > I have successfully installed the Ovms 3.1 module in my renault twizy, but I > still do not know how to modify parameters. For example with the App, if I > want to modify the speed limitation, it tells me the following error message: > Can bus not in active mode > > I guess that writing or reading by can not be active, because I can not see > the fault logs etc ... > Could you help me with this? > Regards!

2 3

(Hardware) Sharing the bus, J4, J5, J6?
by Brian Greenberg 18 Sep '18

18 Sep '18

Firstly, although the topic seems ripe for it, I couldn't come up with a good pun involving buses or terminators for the subject line. Apologies. As I have previously mentioned, I have a '15 Nissan Leaf, which uses both the CAN0 and CAN1 buses. Everything that should work, works quite nicely when the OVMS (V3.1) module is plugged in on its own. (Although it did take a couple of attempts to find an OBD2 splitter that had all of the needed pins connected....) However, when I add a second OBD2 device (a Bluetooth dongle to feed the Leaf Spy Pro app) the OVMS module appears to lose the CAN1 bus -- vehicle status events like door locks and headlight state stop updating almost (but not quite) entirely. I suspect that both OVMS and Leaf Spy do at least some active polling for status, but my (limited) understanding is that the devices *should* coexist. Any thoughts on what the issue may be? Two possibilities that I have thought of are that, with the OBD2 splitter cable, the high speed CAN bus is formed into an unsupported star, instread of straight serial, topology. The other is that the OVMS module may not be properly terminated -- the schematic and board show that the 120 ohm resistors that terminate the CAN bus are included, but not connected by default -- there are three sets of jumper pads that can be shorted to enable the respective terminators. Would soldering a wire across the J5 (CAN1) jumper help? (And why isn't termination enabled by default? Just curious....) Thanks! Brian. PS: A request to put in the wish list file for V4.... Can the internal expansion bus pins be laid out with the standard 2.54mm pitch? I'm looking at creating a simple board to expose the EGPIO pins on the DB26 port, and finding a 2mm pitch prototype board and headers is a huge pain. -- Brian Greenberg grnbrg(a)grnbrg.org

2 1

Vehicle theft alert
by Greg D. 17 Sep '18

17 Sep '18

Hi folks, Probably a historical reason for this; if not, not a big deal I suppose... I just got an alert that my car was being transported, possibly due to theft/flatbed. Checked the garage, and the car was sleeping peacefully, as expected. A quick check of the status shows that the GPS has lost lock (don't know why), and presume that's the reason for the alert. Checked the code (components/ovms_location)... Is there a reason that the theft alert is not qualified by m_gpslock? I suppose one could thwart the theft alert by covering the car in tin foil first, but it seems like a long shot. Alternatively, is it worth alerting on the loss (and/or restoration) of GPS lock? I'm guessing that might be more annoying than it's worth. Greg

1 1

CAN-RE-Tool
by Tamás Kovács 17 Sep '18

17 Sep '18

I want to run canretool.pl but is have a following problem: Experimental keys on scalar is now forbidden at ..../CRT/Variables.pm line 191. installed perl version is 5.24 subversion 1

2 1

"New" car add
by Tamás Kovács 14 Sep '18

14 Sep '18

Hi, i have a Peugoet iOn, some week ago i buy a OVMS v3.1 kit. Works well the basic functions for my car with Mitsubishi profile. I want to create a own profile for my car for testing, my own code, but i duplicate mitsubishi files in components folder, and all mitsubishi change to peugeot (case sensitive), and vehicle code modified to PI, and duplicate mitsibishi code in main/Kconfig and modify to peugeot, but i can not see in the web interface after make flash. After add it make show a question: add Peugeot to... i write Y, but nothing happen. I use MacOS High Sierra, and atom for modify files.

2 12

v3.1.010 OTA
by Mark Webb-Johnson 11 Sep '18

11 Sep '18

I just released v3.1.010 OTA to ‘main’. Everyone gets it. Regards, Mark.

2 2

MQTT and Ovms Server v3
by Mark Webb-Johnson 30 Aug '18

30 Aug '18

I am far from an expert in MQTT. Not even a novice. So, the work below is ‘best efforts’. Any help / comments / suggestions would be most appreciated. In particular, a big thanks to Jakob for his contributions to this so far. With yesterday’s merge, and commits, we have a very very basic OVMS server v3 implementation. It sends the metrics, and doesn’t crash (much). The overall design is as follows: We use the mongoose mqtt library. We don’t do anything special, and everything is following the mqtt 3.1 standard. MQTT has the concept of topics. Our default prefix for everything is: ovms/<mqtt-username>/<vehicleid>/ (that can be customised with config server.v3 topic.prefix) Metrics are sent as topics. The metric name is added to the topic prefix + “m/“ suffix, and “.” characters converted to “/“ to match the MQTT conventions. The value is simply the metric value (as a string). With our current arrangement, this adds m/m/, m/s/, and m/v/ sub-trees to the the MQTT topic hierarchy. Clients can subscribe to <prefix>/m/# to receive all metrics. The ‘retained’ flag is set on these metrics, at QOS level 0 (so subscribing clients will get a copy of the last known values for these metrics, even with a disconnected vehicle). The metric s.v3.connected is maintained by the ServerV3 code. When a successful MQTT connection is made, and login successful, that is set true (yes). A MQTT last-will-testament is set so that if the OVMS module disconnects the server will automatically update that to false (no). The ‘retained’ flag is set on this metric, at QOS level 0 (so subscribing clients will get a copy of the last known state). Clients can use this to see if the vehicle is connected to the server. Connecting clients are expected to write a “1” value to the <prefix>/c/<clientid> topic, and to repeat that write once a minute. They are also expected to use a last-will-testament on that same topic with value “0”. QOS 1 should be used, and these topics should not be retained. The server V3 code subscribes to this <prefix>/c/# topic, so it gets informed of all connected clients. It can then update the s.v3.peers metric appropriately. Clients are expected to monitor the <prefix>/s/v3/connected topic, so that if it becomes ‘yes’ (true) the client should send <prefix>/c/<clientid> “1” immediately. This mechanism allows a newly connected vehicle to immediately know if one or more clients is connected. The Server v3 sets a timeout for <prefix>/c/<clientid> connections of 2 minutes. If that mqtt topic is not sent again within that time, it is expired (and that client is treated as disconnected). Similar to the v2 code, the server v3 transmits modified metrics once a minute if there are one or more clients connected, or once every ten minutes if there are no clients connected. All the above has been implemented. To reach parity with v2, and exceed it’s functionality in places, we have a few more things to do: Notifications On the vehicle side, I am proposing to use the <prefix>/notify/<type> namespace for these, using QOS 2 messages without retention. Clients can listen to those, if necessary. We can also have a central daemon running that listens to ovms/+/+/n/# topic pattern to receive these notifications and handle appropriately. Using QOS 2 we can confirm the reception of the notification / historical data, and mark it as delivered, appropriately. However, that would only confirm delivery to the MQTT server, not to the central daemon; if the daemon was not running, the notification would be lost. Textual Commands I am proposing to use the <prefix>/cmd/<clientid>/c/ and <prefix>/cmd/<clientid>/r/ namespaces for this, using QOS 2 messages without retention. The value in the /c/ would be the command, and the response would be written to matching the /r/ topic. The commands and responses could be prefixed by an identifier (like in imap protocol) so responses can be matched to commands by the clients). The client side can simply subscribe to itself, and the vehicle side subscribes to <prefix>/cmd/#. In this way, commands cannot be duplicated, and clients don’t see responses to commands they didn’t initiate (which was an issue with v2). Numeric Commands I am not sure if we need to implement the numeric commands, as used in the v2 protocol. It seems to me that we can use textual commands. Config Access I am not sure if we need this, beyond the command processor. If we do, we could expose a /config/ namespace. Events It would be nice to expose events (except for the ticker.* ones, of course). This could be done by a <prefix>/events topic, using QOS 2 and no retention. Logs It would be nice to expose logs. This could be done by a <prefix>/logs topic, using QOS 1 and no retention. Security We need to add SSL support. I am trying to get an authentication plugin for mosquitto / vernemq written so that we can authenticate straight from the OVMS database that is already running on the servers, and give each user their own ovms/<userid>/# namespace. That way, the configuration for v3 on the vehicle/apps/clients is simple - just put in the server username and password (no separate vehicle passwords necessary). I think that is it. The above would form the basis of the specification for this. As this is the basis for future work and direction in OVMS, it is important that we get it right, so all comments / suggestions most welcome. Regards, Mark.

4 15

Production batch 2 and onwards
by Mark Webb-Johnson 29 Aug '18

29 Aug '18

FYI The order for production batch #2 has just been placed: 50x US kits (module + US 3G modem + Hologram sim) 150x EU kits (module + EU 3G modem + Hologram sim) 20x modules only (board + case, but no modem) 5x EU 3G modems (incl. Hologram sim) 5x US 3G modems (incl. Hologram sim) No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags. Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days. This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off. I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months. So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now. Regards, Mark.

3 15

Nissan Leaf, GPIO and "Stop Charging", "Lock/Unlock" commands.
by Brian Greenberg 29 Aug '18

29 Aug '18

I picked up a 2015 Leaf about 3 weeks ago, and found this project a few days later. My 3.1 hardware should arrive from FastTech this week. I've been browsing through the git repos and manuals, and hope to make some small contributions in the future. How interested are you devs in code contributions that require hardware modifications to the vehicle? :) Two things that I am interested in are remotely toggling the door locks, and stopping/disabling an ongoing charge. Neither are currently supported functions in the Leaf, as (if it is possible at all) the codes are unknown. However, both functions are trivially available outside of the car network. To disable charging, it should be quite easy to fake the charge computer into thinking that the J1772 connector is about to be removed -- there is a connector under the hood, just past the L1/L2 socket that carries the socket ground and (low voltage) proximity pin signal to the VCM (Or BCM?). Adding a 330 ohm resistance to the proximity pin tells the car that power is about to be removed, and to stop charging. Door locks will have a fairly easy to locate pair of wires in the front doors that will trigger locking and unlocking. Three GPIO assignments and three opto isolated 12V relays should easily enable the desired functionality. Assuming I can walk this walk, would there be interest in the code? This would be a bit more involved than the single wire connection between the OVMS module and the TCU that is needed to enable the vehicle wake up signal on 2011 and 2012 models..... I'm very impressed with this project, BTW. I've been around open source for years, but I've never seen open hardware development at this level. Brian. -- Brian Greenberg grnbrg(a)grnbrg.org

3 4