The metrics module publishes duktape interfaces “OvmsMetricValue” and “OvmsMetricFloat” to retrieve the value of the passed metric name (string).

The vehicle module issues a number of events regarding charge state:

vehicle.charge.start when charging starts
vehicle.charge.stop when charging ends
vehicle.charge.prepare when the charge port door is opened
vehicle.charge.finish when the charge port door is closed
vehicle.charge.pilot.on when the pilot signal is received
vehicle.charge.pilot.off when the pilot signal goes off
vehicle.charge.state when charge state changes

The idea is to hook into the required charge event, to run a javascript script. For example, “vehicle.charge.pilot.on” to pickup the pilot signal. That script can then check the location state, and possibly other metrics, and act appropriately (such as issuing commands to cool down, etc).

That is how it should work today. But is largely untested. As you have found, if duktape hits a fatal error in the script, it aborts and the module reboots.

I really want to re-work this so that there is a duktape task always running. My idea is to hook it in to the ‘auto’ system Michael developed (so it can be configured to run or not, and also be disabled if the system repeatedly crashes during startup). That task would load all the scripts and run always. Then events would be fed into that task using the javascript event system. We can also more elegantly handle script exceptions and reload when scripts change. Javascript then runs alongside the rest of the system - timers can be used, and code logic / data values can persists between events. We can also use SPIRAM rather than internal RAM. I am working on this, but I want to get the architecture right.

Regards, Mark.

On 21 Dec 2018, at 10:14 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

I’m travelling at the moment. Should be back to a PC tomorrow and I will try to give you a full reply.

I think JavaScript is the way to do this. That was the intent anyway. The issue is that I think the way we have the JavaScript at the moment is not correct. It needs to be a task that runs continuously, and events fed into it. At the moment it is launched for each event. If a task, then it can have timers and full functionality.

Regards, Mark

On 21 Dec 2018, at 9:56 AM, Stephen Casner <casner@acm.org> wrote:

Mark has asserted that the ACC functions could be implemented with
events and scripting. I'm trying to investigate how to do this, so
I'm reaching back a few months to this message about javascript
support. When I try Mark's helloworld.js example I get an immediate
crash, as shown below. Any idea why?

                                                      -- Steve

OVMS# vfs cat /store/scripts/helloworld.js
OvmsPrint("Hello world!\n”);
OVMS# . helloworld.js
abort() was called at PC 0x401b8892 on core 1
0x401b8892: duk_default_fatal_handler at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339

Backtrace: 0x40097f6b:0x3ffe15b0 0x400980c3:0x3ffe15d0 0x401b8892:0x3ffe15f0 0x402481dd:0x3ffe1610 0x401ba5c7:0x3ffe1630 0x401c1ae9:0x3ffe1650 0x401c89da:0x3ffe1670 0x401c9e6b:0x3ffe1860 0x401c9ed1:0x3ffe1880 0x401ce2cf:0x3ffe18b0 0x400f0488:0x3ffe18d0 0x400f05b9:0x3ffe18f0 0x400e5766:0x3ffe1940 0x400e5849:0x3ffe1980 0x400e589a:0x3ffe19c0 0x400f06bf:0x3ffe19e0 0x400f3a8b:0x3ffe1a00 0x400f3c2e:0x3ffe1a60 0x400f06f3:0x3ffe1ad0 0x4024388e:0x3ffe1af0 0x400e3295:0x3ffe1b10 0x400e8635:0x3ffe1b40 0x400e87fd:0x3ffe1b70 0x400e3151:0x3ffe1b90 0x400e3160:0x3ffe1bb0 0x400f27b9:0x3ffe1bd0
0x40097f6b: invoke_abort at /Users/casner/src/github/esp-idf/components/esp32/panic.c:670

0x400980c3: abort at /Users/casner/src/github/esp-idf/components/esp32/panic.c:670

0x401b8892: duk_default_fatal_handler at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339

0x402481dd: duk_fatal_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27715

0x401ba5c7: duk__uncaught_minimal at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
(inlined by) duk_err_longjmp at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:49682

0x401c1ae9: duk_throw_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339

0x401c89da: duk_js_compile at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339

0x401c9e6b: duk__do_compile at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339

0x401c9ed1: duk_compile_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339

0x401ce2cf: duk_eval_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339

0x400f0488: script_ovms(bool, int, OvmsWriter*, char const*, __sFILE*, bool) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_script.cpp:77

0x400f05b9: script_run(int, OvmsWriter*, OvmsCommand*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_script.cpp:133

0x400e5766: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_command.cpp:162

0x400e5849: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_command.cpp:162

0x400e589a: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_command.cpp:162

0x400f06bf: Execute(microrl*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_shell.cpp:48

0x400f3a8b: new_line_handler at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/microrl/microrl.c:620

0x400f3c2e: microrl_insert_char at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/microrl/microrl.c:668

0x400f06f3: OvmsShell::ProcessChar(char) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_shell.cpp:73

0x4024388e: OvmsShell::ProcessChars(char const*, int) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_shell.cpp:80 (discriminator 2)

0x400e3295: ConsoleAsync::HandleDeviceEvent(void*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/console_async.cpp:170

0x400e8635: OvmsConsole::Poll(unsigned int, void*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_console.cpp:151

0x400e87fd: OvmsConsole::Service() at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_console.cpp:131 (discriminator 1)

0x400e3151: ConsoleAsync::Service() at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/console_async.cpp:81

0x400e3160: non-virtual thunk to ConsoleAsync::Service() at ??:?

0x400f27b9: TaskBase::Task(void*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/task_base.cpp:156

Entering gdb stub now.
$T0b#e6GNU gdb (crosstool-NG) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
Reading symbols from /Users/casner/src/github/ovms/vehicle/OVMS.V3/build/ovms3.elf...done.
Remote debugging using /dev/cu.SLAB_USBtoUART
0x40097f6b in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/panic.c:140
140            *((int *) 0) = 0;
(gdb) bt
#0 0x40097f6b in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/panic.c:140
#1 0x400980c6 in abort () at /Users/casner/src/github/esp-idf/components/esp32/panic.c:149
#2 0x401b8895 in duk_default_fatal_handler (udata=0x0, msg=0x3f4730b8 "uncaught error")
  at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:16634
#3 0x402481e0 in duk_fatal_raw (ctx=0x3ffd4478, err_msg=0x3f4730b8 "uncaught error")
  at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27715
#4 0x401ba5ca in duk__uncaught_minimal (thr=0x3ffd4478)
  at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:49604
#5 duk_err_longjmp (thr=0x3ffd4478)
  at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:49682
#6 0x401c1aec in duk_throw_raw (ctx=0x3ffd4478)
  at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27697
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

On Mon, 9 Jul 2018, Mark Webb-Johnson wrote:

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/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.

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev