I’ve also added OvmsCommand and OvmsPrint extension commands.

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/f1736f927df582c5ff374ef5d8c3a565e8f67295
Author: Mark Webb-Johnson <mark@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/69427f4ac0cf68dc462b05752936befe4be22256
Author: Mark Webb-Johnson <mark@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/925417081d8e...69427f4ac0cf
     **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.