- OvmsDev - Open Vehicles

Reducing wifi/netmanager log messages
by Stephen Casner 18 Jan '19

18 Jan '19

When driving, and therefore out of range of the home wifi, the following messges emitted every 10 seconds will fill up the log: I (2019-01-04 03:46:36.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:36.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:36.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:36.989) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:46.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:46.899) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:46.949) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:46.999) esp32wifi: STA disconnected with reason 201 I (2019-01-04 03:46:56.839) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (2019-01-04 03:46:56.889) netmanager: Set DNS#0 8.8.8.8 I (2019-01-04 03:46:56.939) netmanager: Set DNS#1 8.8.4.4 I (2019-01-04 03:46:56.979) esp32wifi: STA disconnected with reason 201 I'd like to add code to suppress those messages when there is no change in state. Any objections? -- Steve

3 11

2019
by Mark Webb-Johnson 16 Jan '19

16 Jan '19

Firstly, a very belated merry xmas, and happy 2019 to everyone. I hope that you all got to spend good times with friends and family, as I did. I’ve been travelling, and just got back home to a very large eMail inbox. During my travels, I did manage to re-work the javascript framework to be single task based. That seems to work well, and now I’m back I will test on my car. The new framework is backwards compatible - apart from memory usage (one more task with a stack), it has no impact to the flow. It will, however, allow us to extend this a lot more and become much more useful. Assuming no issues, I will be able to commit that soon. As we are up to 144 commits since 3.1.011, perhaps it is well past due for 3.1.012? I was hoping that Espressif would have fixed the bug related to wear levelling version upgrades that Michael helped to identify, but not yet. Any objections to a 3.1.012 release to EAP at the end of this week? The CE/FCC certification work is progressing. No issues so far. I’ll let you know as soon as we get near completion for this. I’m working through my inbox now, and will reply individually to questions there. Regards, Mark.

2 6

Web framework documentation
by Michael Balzer 13 Jan '19

13 Jan '19

I've added a readme to the directory including all examples I've done so far: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/tree/maste… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Password characters not received correctly
by Stephen Casner 10 Jan '19

10 Jan '19

Has anyone else seen this phenomenon? While connected to the USB serial console and needing to issue the "enable" command and then enter the module password, there have been a few instances where I know I typed the password correctly and yet OVMS said no. In fact, sometimes it would say the password was wrong three times in a row when I was typing very carefully each key in sequence. I added some code to print out the characters that had been received if the password was invalid. I discovered that some, but not all, of the characters were received as zero (NULL) instead of what I typed. The last several times this has not occurred, though, so I don't have a lot of datapoints. I've looked at the code and don't see any obvious way this could happen. My best guess is some kind of timing problem between the UART driver and my console_async code calling uart_read_bytes(). -- Steve

2 1

Hey you in there! Your door knocker fell off!
by Stephen Casner 09 Jan '19

09 Jan '19

When I was plugging a cable into the micro-USB connector on my OVMSv3.0 board the connector came off. This was a bit of a scare! Even though the connector uses through-hole pins for physical attachment, I guess there is some flexing of the solder as the cable is inserted or removed. I have not done that many insertions, though; it's the other end of the cable with a full-size USB connector that gets exercised. Fortunately I was able to reflow the solder for both the through-hole pins and the ity-bity surface-mount electrical connections using a fine-tip soldering iron so operation was restored. So this is just a word of caution to be gentle! -- Steve p.s. The subject is a reference to Firesign Theatre for those of us old enough to have burned up time in college listening to their albums.

1 0

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

Web UI plugin support / metric displays
by Michael Balzer 08 Jan '19

08 Jan '19

Just a short intro for those that haven't followed the git log: the web framework now supports plugins, which currently can contain HTML to be used as a page or as an extension to an existing page. I'm now working on documentation and simplification of the framework features to make writing plugins easy. Users most often asked for an option to extend the dashboard or add a custom dashboard. That's now very simple using the plugin system and the standard metrics displays. To install the metrics demo: * Add a page plugin "demo.metrics", with… * …page "/usr/demo/metrics" * …label "Metrics Demo" * …menu "Tools" * …auth "None" or "Cookie" * …content copied from: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/maste… Please have a look at the page and tell me if you miss something. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 2

Anyone else get an ESP-EYE from espressif?
by Stephen Casner 07 Jan '19

07 Jan '19

Because I contributed some code back to espressif for esp-idf they sent to me a gift of their new ESP-EYE development board plus a T-shirt. Did anyone else get this gift? The ESP-EYE board includes a camera and the notes indicate that it is supposed to do facial recognition but there is very little information available at this point. See https://www.cnx-software.com/2019/01/02/esp-eye-esp32-ai-development-board/ -- Steve

2 1

Javascript - Documentation
by Robert Sharpe (Electric Vehicle Consultant) 07 Jan '19

07 Jan '19

Hi, In order to help new users access the power of the OVMS I have pulled together some of the scripting documentation. It is mainly from http://bit.ly/2FcqnyS and is in a draft section in a http://bit.ly/2sdkgmh that will later be integrated into User Manual once reviewed. I don't have an OVMS unit at the moment so cant test myself. So it would be great if those with experience of using the scripting feature could review/add to the above document as necessary. You will need to request access, mainly so that I can come back to specific people if I need to clarify anything (rather than pinging the entire group). Also happy to take known issues not in the http://bit.ly/2CUS8KX and capture in github. Thanks, Rob

1 1

Javascript
by Robert Sharpe (Electric Vehicle Consultant) 07 Jan '19

07 Jan '19

Hi Mark, Great news about scripting. Which of your comments below are still to be addressed? 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. Thanks, Rob Am 09.07.2018 um 07:40 schrieb Mark Webb-Johnson: > > 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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev <mailto:http://lists.openvehicles.com/mailman/listinfo/ovmsdev>> >> 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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev <mailto:http://lists.openvehicles.com/mailman/listinfo/ovmsdev>> >> 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 <http://github.com/> on January 31st, 2019. > > > > _______________________________________________ > OvmsDev mailing list > http://lists.openvehicles.com/mailman/listinfo/ovmsdev > http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0