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/f173... 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/6942... 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/925... **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.
That's very cool, thanks. Btw: truly scary is the car system that doesn't provide even the most simple protection against brute force attacks. Regards, Michael 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/f173... Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto: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/6942... Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto: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/925... **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 OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
More scary that I reported the issue to the manufacturer just over a year ago, and they still won’t even acknowledge the problem as a concern. Regards, Mark.
On 10 Jul 2018, at 6:40 AM, Michael Balzer <dexter@expeedo.de> wrote:
That's very cool, thanks.
Btw: truly scary is the car system that doesn't provide even the most simple protection against brute force attacks.
Regards, Michael
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 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3> Commit: f1736f927df582c5ff374ef5d8c3a565e8f67295 https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f173... <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f1736f927df582c5ff374ef5d8c3a565e8f67295> Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto: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/6942... <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/69427f4ac0cf68dc462b05752936befe4be22256> Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto: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/925... <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/925417081d8e...69427f4ac0cf> **NOTE:** <note:**> This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-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 OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> 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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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/f173... 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/6942... 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/925... **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.
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/f173... 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/6942... 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/925... **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
The location module publishes a duktape interface “OvmsLocationStatus”. Passed a string location name, it returns true if the vehicle is currently in that location. The command module publishes a duktape interface “OvmsCommand” that allow an arbitrary command to be executed. 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/f173... 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/6942... 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/925... **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
Sort of a mini "node.js"? That will take the scripting capabilities to a new level, looking forward to this. Just saw duktape also has a node.js like module loader in the extras directory, supplying the require() function etc. -- very nice. There are some embedded real node.js implementations, even one running on duktape, but that may be a bit over the top ;-) Regards, Michael Am 22.12.18 um 14:03 schrieb Mark Webb-Johnson:
The location module publishes a duktape interface “OvmsLocationStatus”. Passed a string location name, it returns true if the vehicle is currently in that location.
The command module publishes a duktape interface “OvmsCommand” that allow an arbitrary command to be executed.
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 <mailto: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 <mailto: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/f173... Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto: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/6942... Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto: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/925... **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 OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Steve, I get this: OVMS# vfs cat /sd/helloworld.js OvmsPrint("Hello world\n"); OVMS# . /sd/helloworld.js Hello world Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31. 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/f173... 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/6942... 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/925... **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
Mark, There is a blank line at the end of your script that I don't have. Perhaps that is required for javascript? I'll try that soon. On the other hand, crashing when the input format isn't as desired is not the best error handling approach. I do have some deviations from sdkconfig.default.hw31, but not in the spec for the duktape library. -- Steve On Sat, 22 Dec 2018, Mark Webb-Johnson wrote:
Steve,
I get this:
OVMS# vfs cat /sd/helloworld.js OvmsPrint("Hello world\n");
OVMS# . /sd/helloworld.js Hello world
Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31.
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/f173... 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/6942... 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/925... **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.
Steve, I just tried this: OVMS# vfs append 'OvmsPrint("Hello World\n");' /store/scripts/helloworld.js OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello World\n"); OVMS# . helloworld.js Hello World OVMS# So no, the blank line isn't necessary. Regards, Michael Am 22.12.18 um 09:14 schrieb Stephen Casner:
Mark,
There is a blank line at the end of your script that I don't have. Perhaps that is required for javascript? I'll try that soon. On the other hand, crashing when the input format isn't as desired is not the best error handling approach.
I do have some deviations from sdkconfig.default.hw31, but not in the spec for the duktape library.
-- Steve
On Sat, 22 Dec 2018, Mark Webb-Johnson wrote:
Steve,
I get this:
OVMS# vfs cat /sd/helloworld.js OvmsPrint("Hello world\n");
OVMS# . /sd/helloworld.js Hello world
Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31.
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/f173... 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/6942... 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/925... **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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, I used the same sequence of commands that you did. The only difference is that I did not capitalize World and I did include an exclamation point after it (since I did copy/paste from Mark's message). Maybe it is an insufficient free memory problem. But I just tried again via an ssh console with this starting condition: Free 8-bit 91352/230700, 32-bit 1236/3144, SPIRAM 4032872/4194252 That should be sufficient. Attached is a diff of sdkconfig.default.hw31 to my sdkconfig. The only thing I noticed that might be an explanation is the optimization level set to RELEASE vs DEBUG. -- Steve On Sat, 22 Dec 2018, Michael Balzer wrote:
Steve,
I just tried this:
OVMS# vfs append 'OvmsPrint("Hello World\n");' /store/scripts/helloworld.js OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello World\n"); OVMS# . helloworld.js Hello World OVMS#
So no, the blank line isn't necessary.
Regards, Michael
Am 22.12.18 um 09:14 schrieb Stephen Casner:
Mark,
There is a blank line at the end of your script that I don't have. Perhaps that is required for javascript? I'll try that soon. On the other hand, crashing when the input format isn't as desired is not the best error handling approach.
I do have some deviations from sdkconfig.default.hw31, but not in the spec for the duktape library.
-- Steve
On Sat, 22 Dec 2018, Mark Webb-Johnson wrote:
Steve,
I get this:
OVMS# vfs cat /sd/helloworld.js OvmsPrint("Hello world\n");
OVMS# . /sd/helloworld.js Hello world
Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31.
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/f173... 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/6942... 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/925... **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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Well, I have tried several stages of rebuilding, but I still get an immediate crash from duktape. First I updated sources for ovms and esp-idf (the previous pull was October 29). Still crashed. Then I changed from RELEASE to DEBUG to be like sdkconfig.default.hw31 but that failed to link because I still had bluetooth configured so there was not enough space in IRAM, so I removed bluetooth and made clean. Still crashed. Then I backed off to straight sdkconfig.default.hw31, though the make procedure then added some more defaults that should be checked in. Still crashed. The most obvious question is whether there is something wrong with my javascript file so that duktape is legitimately considering it in error, but the source looks clean: OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n”); OVMS# I don't have any other ideas yet. -- Steve On Sat, 22 Dec 2018, Stephen Casner wrote:
Michael,
I used the same sequence of commands that you did. The only difference is that I did not capitalize World and I did include an exclamation point after it (since I did copy/paste from Mark's message).
Maybe it is an insufficient free memory problem. But I just tried again via an ssh console with this starting condition:
Free 8-bit 91352/230700, 32-bit 1236/3144, SPIRAM 4032872/4194252
That should be sufficient.
Attached is a diff of sdkconfig.default.hw31 to my sdkconfig. The only thing I noticed that might be an explanation is the optimization level set to RELEASE vs DEBUG.
-- Steve
On Sat, 22 Dec 2018, Michael Balzer wrote:
Steve,
I just tried this:
OVMS# vfs append 'OvmsPrint("Hello World\n");' /store/scripts/helloworld.js OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello World\n"); OVMS# . helloworld.js Hello World OVMS#
So no, the blank line isn't necessary.
Regards, Michael
Am 22.12.18 um 09:14 schrieb Stephen Casner:
Mark,
There is a blank line at the end of your script that I don't have. Perhaps that is required for javascript? I'll try that soon. On the other hand, crashing when the input format isn't as desired is not the best error handling approach.
I do have some deviations from sdkconfig.default.hw31, but not in the spec for the duktape library.
-- Steve
On Sat, 22 Dec 2018, Mark Webb-Johnson wrote:
Steve,
I get this:
OVMS# vfs cat /sd/helloworld.js OvmsPrint("Hello world\n");
OVMS# . /sd/helloworld.js Hello world
Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31.
Regards, Mark.
Steve…
OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n*”*);
…is that closing quote really a typographic one? If so, try replacing that by a straight one. Regards, Michael Am 22.12.18 um 23:50 schrieb Stephen Casner:
Well, I have tried several stages of rebuilding, but I still get an immediate crash from duktape.
First I updated sources for ovms and esp-idf (the previous pull was October 29). Still crashed.
Then I changed from RELEASE to DEBUG to be like sdkconfig.default.hw31 but that failed to link because I still had bluetooth configured so there was not enough space in IRAM, so I removed bluetooth and made clean. Still crashed.
Then I backed off to straight sdkconfig.default.hw31, though the make procedure then added some more defaults that should be checked in. Still crashed.
The most obvious question is whether there is something wrong with my javascript file so that duktape is legitimately considering it in error, but the source looks clean:
OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n”); OVMS#
I don't have any other ideas yet.
-- Steve
On Sat, 22 Dec 2018, Stephen Casner wrote:
Michael,
I used the same sequence of commands that you did. The only difference is that I did not capitalize World and I did include an exclamation point after it (since I did copy/paste from Mark's message).
Maybe it is an insufficient free memory problem. But I just tried again via an ssh console with this starting condition:
Free 8-bit 91352/230700, 32-bit 1236/3144, SPIRAM 4032872/4194252
That should be sufficient.
Attached is a diff of sdkconfig.default.hw31 to my sdkconfig. The only thing I noticed that might be an explanation is the optimization level set to RELEASE vs DEBUG.
-- Steve
On Sat, 22 Dec 2018, Michael Balzer wrote:
Steve,
I just tried this:
OVMS# vfs append 'OvmsPrint("Hello World\n");' /store/scripts/helloworld.js OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello World\n"); OVMS# . helloworld.js Hello World OVMS#
So no, the blank line isn't necessary.
Regards, Michael
Am 22.12.18 um 09:14 schrieb Stephen Casner:
Mark,
There is a blank line at the end of your script that I don't have. Perhaps that is required for javascript? I'll try that soon. On the other hand, crashing when the input format isn't as desired is not the best error handling approach.
I do have some deviations from sdkconfig.default.hw31, but not in the spec for the duktape library.
-- Steve
On Sat, 22 Dec 2018, Mark Webb-Johnson wrote:
Steve,
I get this:
OVMS# vfs cat /sd/helloworld.js OvmsPrint("Hello world\n");
OVMS# . /sd/helloworld.js Hello world
Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, Thank you! With the (small) font I'm using I could not easily see that the closing double quote was not the 7-bit ASCII one. I had copy/pasted that from Mark's message, so some software must have done him a favor when he prepared his message. I hate "smart" quotes. Thanks also for fixing the usage string expansion. I don't know how to explain my writing of the wrong function other than perhaps I was copy/pasting from some other file of mine that worked differently or the design evolved and I didn't change the function. The bug was not detected because every instance of '$' was followed by 'C' so find_first_of("$C") still found the right position and the text in usage strings was all lower case so no other 'C' was found. There's only one instance of $G used (in the "power" command) and it follows a $C so again the wrong function still found the right position. -- Steve On Sun, 23 Dec 2018, Michael Balzer wrote:
Steve...
OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n*"*);
...is that closing quote really a typographic one? If so, try replacing that by a straight one.
Regards, Michael
Am 22.12.18 um 23:50 schrieb Stephen Casner:
Well, I have tried several stages of rebuilding, but I still get an immediate crash from duktape.
First I updated sources for ovms and esp-idf (the previous pull was October 29). Still crashed.
Then I changed from RELEASE to DEBUG to be like sdkconfig.default.hw31 but that failed to link because I still had bluetooth configured so there was not enough space in IRAM, so I removed bluetooth and made clean. Still crashed.
Then I backed off to straight sdkconfig.default.hw31, though the make procedure then added some more defaults that should be checked in. Still crashed.
The most obvious question is whether there is something wrong with my javascript file so that duktape is legitimately considering it in error, but the source looks clean:
OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n"); OVMS#
I don't have any other ideas yet.
-- Steve
On Sat, 22 Dec 2018, Stephen Casner wrote:
Michael,
I used the same sequence of commands that you did. The only difference is that I did not capitalize World and I did include an exclamation point after it (since I did copy/paste from Mark's message).
Maybe it is an insufficient free memory problem. But I just tried again via an ssh console with this starting condition:
Free 8-bit 91352/230700, 32-bit 1236/3144, SPIRAM 4032872/4194252
That should be sufficient.
Attached is a diff of sdkconfig.default.hw31 to my sdkconfig. The only thing I noticed that might be an explanation is the optimization level set to RELEASE vs DEBUG.
-- Steve
On Sat, 22 Dec 2018, Michael Balzer wrote:
Steve,
I just tried this:
OVMS# vfs append 'OvmsPrint("Hello World\n");' /store/scripts/helloworld.js OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello World\n"); OVMS# . helloworld.js Hello World OVMS#
So no, the blank line isn't necessary.
Regards, Michael
Am 22.12.18 um 09:14 schrieb Stephen Casner:
Mark,
There is a blank line at the end of your script that I don't have. Perhaps that is required for javascript? I'll try that soon. On the other hand, crashing when the input format isn't as desired is not the best error handling approach.
I do have some deviations from sdkconfig.default.hw31, but not in the spec for the duktape library.
-- Steve
On Sat, 22 Dec 2018, Mark Webb-Johnson wrote:
Steve,
I get this:
OVMS# vfs cat /sd/helloworld.js OvmsPrint("Hello world\n");
OVMS# . /sd/helloworld.js Hello world
Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31.
Regards, Mark.
Steve, thanks for confirming, I've added an issue on this: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/179 Regarding the bug: lucky find due to "PC" in the new backup usage string. No need to explain, we're all human. Regards, Michael Am 23.12.18 um 01:53 schrieb Stephen Casner:
Michael,
Thank you! With the (small) font I'm using I could not easily see that the closing double quote was not the 7-bit ASCII one. I had copy/pasted that from Mark's message, so some software must have done him a favor when he prepared his message. I hate "smart" quotes.
Thanks also for fixing the usage string expansion. I don't know how to explain my writing of the wrong function other than perhaps I was copy/pasting from some other file of mine that worked differently or the design evolved and I didn't change the function. The bug was not detected because every instance of '$' was followed by 'C' so find_first_of("$C") still found the right position and the text in usage strings was all lower case so no other 'C' was found. There's only one instance of $G used (in the "power" command) and it follows a $C so again the wrong function still found the right position.
-- Steve
On Sun, 23 Dec 2018, Michael Balzer wrote:
Steve...
OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n*"*); ...is that closing quote really a typographic one? If so, try replacing that by a straight one.
Regards, Michael
Am 22.12.18 um 23:50 schrieb Stephen Casner:
Well, I have tried several stages of rebuilding, but I still get an immediate crash from duktape.
First I updated sources for ovms and esp-idf (the previous pull was October 29). Still crashed.
Then I changed from RELEASE to DEBUG to be like sdkconfig.default.hw31 but that failed to link because I still had bluetooth configured so there was not enough space in IRAM, so I removed bluetooth and made clean. Still crashed.
Then I backed off to straight sdkconfig.default.hw31, though the make procedure then added some more defaults that should be checked in. Still crashed.
The most obvious question is whether there is something wrong with my javascript file so that duktape is legitimately considering it in error, but the source looks clean:
OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n"); OVMS#
I don't have any other ideas yet.
-- Steve
On Sat, 22 Dec 2018, Stephen Casner wrote:
Michael,
I used the same sequence of commands that you did. The only difference is that I did not capitalize World and I did include an exclamation point after it (since I did copy/paste from Mark's message).
Maybe it is an insufficient free memory problem. But I just tried again via an ssh console with this starting condition:
Free 8-bit 91352/230700, 32-bit 1236/3144, SPIRAM 4032872/4194252
That should be sufficient.
Attached is a diff of sdkconfig.default.hw31 to my sdkconfig. The only thing I noticed that might be an explanation is the optimization level set to RELEASE vs DEBUG.
-- Steve
On Sat, 22 Dec 2018, Michael Balzer wrote:
Steve,
I just tried this:
OVMS# vfs append 'OvmsPrint("Hello World\n");' /store/scripts/helloworld.js OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello World\n"); OVMS# . helloworld.js Hello World OVMS#
So no, the blank line isn't necessary.
Regards, Michael
Am 22.12.18 um 09:14 schrieb Stephen Casner:
Mark,
There is a blank line at the end of your script that I don't have. Perhaps that is required for javascript? I'll try that soon. On the other hand, crashing when the input format isn't as desired is not the best error handling approach.
I do have some deviations from sdkconfig.default.hw31, but not in the spec for the duktape library.
-- Steve
On Sat, 22 Dec 2018, Mark Webb-Johnson wrote:
> Steve, > > I get this: > > OVMS# vfs cat /sd/helloworld.js > OvmsPrint("Hello world\n"); > > OVMS# . /sd/helloworld.js > Hello world > > Maybe your SDKCONFIG different than mine? I am using the sdkconfig.default.hw31. > > Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner