July 2018 - OvmsDev - Open Vehicles

Dexter'web API
by Tim Jackson 28 Sep '19

28 Sep '19

Hi there all, I have 2 of the latest units, and I am running a Nissan Leaf and e-NV200.. I have 2 questions 1. Is there an API for dexter-web.de <http://dexter-web.de/> site? 2. Is there any updated documentation on the current API on TMC? Thanks Tim

2 2

3G network
by Stein Arne Sordal 03 Jul '19

03 Jul '19

Hi I guess this question is basically for Mark, In Norway the telecom providers have decided to turn off almost all of the 3G network soon and focus on 4G only. Any plan for 4G modem? Kind regards, Stein Arne Sordal

6 12

Can buses stop after some time
by Tom Parker 02 Jun '19

02 Jun '19

Hi all, I synced up with master about a week ago and since then I've seen both can busses stop working. I still see the 12v battery metric changing, but everything that comes from the car stops. Rebooting the module with "module reset" does not seem to fix it, while make app-flash monitor does fix it. I haven't tried make monitor on it's own. Is anyone else seeing behavior like this? Sorry for the vague bug report. I'll spend some time later this weekend to try to gather more information.

7 45

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

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

Collecting information on the Fiat 500e
by Jason Perkins 15 Feb '19

15 Feb '19

OVMS team, As an owner of a Fiat 500e I was very interested when I stumbled across this project on the TMC forums. The Fiat factory telematics system deactivates 3 years from the original vehicle sale and is non renewable. I think FCA wants to kill the whole system at this point (it's been replaced with the corporate UConnect system) 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. I believe the actual control unit was adapted from some kind of remote-disablement system used in europe (the Fiat literature calls this the Vehicle Tracking Module). The Fiat has a normal J1962 plug, but does not have OBDII protocol support. Like the Kia Soul the powertrain CAN on pin 6 / 14 and the body CAN on 1 / 9. There's no telling how long the telematics will keep working on our roommates '14, so doing a capture sooner than later would be good. I'm open to any suggestions on how best to do this. The car related diag tools I have on hand are: ELM327 Bluetooth, Ross-Tech VCDS (For VW / Audi Products), and AlfaOBD (which can talk to most of the modules in the 500e - but not the VTM :( ), and an adapter to swap the CAN wires so a standard interface can get to the Body CAN. Thanks! -J

5 28

Poor wifi performance
by Stephen Casner 09 Jan '19

09 Jan '19

I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here. For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased? When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit? For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist). The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed. Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console? -- Steve

4 46

Javascript
by Mark Webb-Johnson 23 Dec '18

23 Dec '18

I’ve enabled the javascript support in the ovms_scripts module. You can now write script files using the javascript language, and they will be run by the duktape engine. Any script file ending with “.js” extension will be treated as javascript. I’ve also added OvmsCommand and OvmsPrint extension commands. Two examples: OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n”); OVMS# . helloworld.js Hello world! OVMS# vfs cat /store/scripts/ota.js OvmsPrint(OvmsCommand("ota status")); OVMS# . ota.js Running partition: factory Boot partition: factory Firmware: 3.1.008-40-g9254170-dirty/factory/edge (build idf v3.1-dev-1583-g0fb2019f Jul 9 2018 08:49:48) Server Available: 3.1.008-37-g939416c (no update required) Sat Jul 7 16:00:45 UTC 2018 Automated build (markhk8) ... A useful example would be to have a script that runs on location.leave, and checks the v.e.gear metric for vehicle in Drive, before firing off the homelink to close the garage door. Like all good things, the opportunity for evil is forever prevalent (and truly scary): OVMS# vfs cat /store/scripts/bruteforce.js for (var pin = 1000; pin < 10000; pin++) { OvmsCommand("unlock " + pin); } OVMS# . bruteforce.js V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e8 03 00 40 | .......@ V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e9 03 00 40 | .......@ V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 ea 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 eb 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ec 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ed 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ee 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ef 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 f0 03 00 40 | .......@ V (1421394) canlog: TX can1 id 102 len 8: 0b 03 00 00 f1 03 00 40 | .......@ ... I’ll leave it up to an exercise to the reader to change that script to use DukOvmsMetricValue() to monitor the v.e.locked metric to record success. Note that this is very hacky and experimental at the moment. A better approach seems to be to have a javascript task running, initialised at boot with a user’s javascript program. That can have timers, and whatever else it needs, to do it’s stuff. Then, scripts executed are run in the context of that task. The current implementation is really just a proof of concept. The OvmsPrint is particularly kludgy (a better implementation would be to hook to the duktape I/O system). Duktape is also currently running in internal RAM, although changing it to use SPI RAM should not be hard. Regards, Mark. > Begin forwarded message: > > From: GitHub > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: f1736f927df582c5ff374ef5d8c3a565e8f67295 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f17… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-07-09 (Mon, 09 Jul 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms_command.cpp > > Log Message: > ----------- > Javascript: Add a OvmsCommand function to execute an OVMS command > > > Commit: 69427f4ac0cf68dc462b05752936befe4be22256 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/694… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-07-09 (Mon, 09 Jul 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms_script.cpp > > Log Message: > ----------- > Javascript: Add a OvmsPrint function to be able to print a string > JavaScript: Support .js script files (executed with javascript engine) > > > Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/92… > **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ > > Functionality will be removed from GitHub.com on January 31st, 2019.

3 14

esp32can issue
by Michael Balzer 04 Nov '18

04 Nov '18

Frank Demes reported a very strange CAN behaviour. He managed to get a CRTD log of one incident. The effect is triggered by an unknown cause freezing the CAN rx task for short periods of time, i.e. 70 - 120 ms. This alone should be no problem, the RXFIFO will probaly overflow, but that is handled by our driver, so except some messages lost this should not be an issue. Unfortunately, something goes completely wrong: a) on the overrun event, the last valid message is delivered multiple times (i.e. 5 times) b) after resolving the overrun, a garbled message is received. The garbled message contains a valid byte sequence in the wrong place, i.e. bytes 5-8 would be valid if they were bytes 1-4. Bytes 1-4 cannot have been read from the bus, so something is going very wrong here. I have walked through the esp32can driver and checked the SJA1000 documentation but have no clue what is going wrong. Any ideas? CRTD excerpt below. (Frame 155 is reflected by the module with byte 1 changed from 07 to 01 to limit the charge current. The problem is, it also reflects the garbled message, which causes the charger to stop.) Regards, Michael ---------------------------------------------------------------------------------------- … 274.341 1R11 155 07 97 E4 54 4B A8 00 6C 274.341 1T11 155 01 97 E4 54 4B A8 00 6C 274.351 1R11 155 07 97 E5 54 4B A8 00 6C 274.351 1T11 155 01 97 E5 54 4B A8 00 6C 274.361 1R11 155 07 97 E5 54 4B A8 00 6C 274.361 1T11 155 01 97 E5 54 4B A8 00 6C 274.371 1R11 423 03 22 FF FF 00 E0 00 DB 274.371 1R11 426 00 38 01 00 4D 7E 00 274.371 1R11 597 20 A4 03 B1 2F 00 01 53 274.371 1R11 627 00 00 00 274.371 1R11 155 07 97 E5 54 4B A8 00 6C 274.371 1T11 155 01 97 E5 54 4B A8 00 6C 274.381 1R11 155 07 97 E5 54 4B A8 00 6C 274.381 1T11 155 01 97 E5 54 4B A8 00 6C 274.391 1R11 5D7 FF FF 01 E4 53 80 00 - normal up to here !!! CAN RX is blocked here for ~70 ms !!! … interrupts disabled? by whom? 274.461 1R11 599 00 00 4D 7E 1E 26 FF FF 274.461 1R11 436 00 0E 3C B2 00 00 274.461 1R11 155 07 97 E5 54 4B A8 00 6C 274.461 1R11 424 11 40 15 26 47 64 00 48 274.461 1R11 425 0A 1D 44 FF FE 40 01 1F 274.461 1R11 556 30 63 07 30 73 07 30 7A 274.461 1T11 155 01 97 E5 54 4B A8 00 6C ← reflection for 155 still works here !!! next RX pause, ~90 ms this time !!! !!! ID 599 has a period of 100 ms, but we now get it 5 times: 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1CEV Error intr=58445 rxpkt=27132 txpkt=528128 errflags=0x15433 rxerr=0 txerr=0 rxovr=2 txovr=0 txdelay=17 crtd fprintf bug compensation: 274.551 1CEV Error rxpkt=58445 txpkt=27132 errflags=528128 intr=0x15433 rxerr=0 txerr=0 rxovr=2 txovr=0 txdelay=17 errflags=528128 = 08 0F 00 0x08 = IR: Data overrun 0x0F = SR: Bus OK, error limit not yet reached, RX & TX idle, RXFIFO overrun, RX buffer full 0x00 = ECC: - 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 155 07 97 E6 54 4B A8 00 6C RX "A" 274.551 1R11 155 07 97 E6 54 4B A8 00 6C RX "B" 274.551 1R11 155 07 97 E7 54 4B A8 00 6C RX "C" 274.551 1R11 423 03 22 FF FF 00 E0 00 DB 274.551 1R11 426 00 38 01 00 4D 7E 00 274.551 1R11 597 20 A4 03 B1 2F 00 01 53 274.551 1R11 627 00 00 00 274.551 1T11 155 01 97 E6 54 4B A8 00 6C reflection "A" 274.551 1CEV TX_Queue T11 155 01 97 E6 54 4B A8 00 6C reflection "B" 274.551 1CEV TX_Queue T11 155 01 97 E7 54 4B A8 00 6C reflection "C" 274.551 1T11 155 01 97 E8 54 4B A8 00 6C reflection "D" !!! 120 ms pause !!! 274.671 1R11 155 07 97 E8 54 4B A8 00 6C RX "D" → "D" was sent to the listeners & reflected by vehicle::IncomingFrame() then, before the LogFrame() call was processed, the CAN task was paused for 120 ms and now it's getting really weird: 274.671 1R11 155 07 08 2A A0 07 97 E7 54 RX "E": invalid frame / garbled message! … this frame certainly was not on the bus! bytes 2-4 (08 2A A0) = complete nonsense, not matching any frame on the bus bytes 5-8 (07 97 E7 54) = normally bytes 1-4 (!) of ID 155 - copy / memory error? … very unlikely - CAN RX handling error? … doesn't seem so - RXFIFO message window bug? 274.671 1CEV Error intr=58458 rxpkt=27134 txpkt=528128 errflags=0x15456 rxerr=0 txerr=0 rxovr=3 txovr=0 txdelay=19 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1T11 155 01 97 E6 54 4B A8 00 6C 274.671 1CEV TX_Queue T11 155 01 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 F2 54 4B A8 00 6C 274.671 1R11 155 07 97 F3 54 4B A8 00 6C 274.671 1R11 423 03 22 FF FF 00 E0 00 DB 274.671 1R11 426 00 38 01 00 4D 7E 00 274.671 1R11 597 20 A4 03 B1 2F 00 01 53 274.671 1R11 627 00 00 00 274.671 1R11 155 07 97 F5 54 4B A8 00 6C 274.671 1R11 155 07 97 F6 54 4B A8 00 6C 274.671 1R11 5D7 FF FF 01 E4 53 80 00 274.671 1R11 599 00 00 4D 7E 1E 26 FF FF 274.671 1R11 155 07 97 F7 54 4B A8 00 6C 274.671 1R11 436 00 0E 3C B2 00 00 274.671 1R11 041 A0 07 97 F5 54 4B A8 00 274.671 1T11 155 01 97 E7 54 4B A8 00 6C 274.671 1T11 155 01 08 2A A0 07 97 E7 54 reflection of invalid msg "E" → charge terminates due to error -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

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

31 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