[Ovmsdev] Javascript

Michael Balzer dexter at expeedo.de
Sat Dec 22 23:22:45 HKT 2018


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 at webb-johnson.net <mailto:mark at 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 at acm.org <mailto:casner at acm.org>> wrote:
>>>
>>> Mark has asserted that the ACC functions could be implemented with
>>> events and scripting.  I'm trying to investigate how to do this, so
>>> I'm reaching back a few months to this message about javascript
>>> support.  When I try Mark's helloworld.js example I get an immediate
>>> crash, as shown below.  Any idea why?
>>>
>>>                                                       -- Steve
>>>
>>> OVMS# vfs cat /store/scripts/helloworld.js
>>> OvmsPrint("Hello world!\n”);
>>> OVMS# . helloworld.js
>>> abort() was called at PC 0x401b8892 on core 1
>>> 0x401b8892: duk_default_fatal_handler at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>>
>>>
>>> Backtrace: 0x40097f6b:0x3ffe15b0 0x400980c3:0x3ffe15d0 0x401b8892:0x3ffe15f0 0x402481dd:0x3ffe1610 0x401ba5c7:0x3ffe1630 0x401c1ae9:0x3ffe1650
>>> 0x401c89da:0x3ffe1670 0x401c9e6b:0x3ffe1860 0x401c9ed1:0x3ffe1880 0x401ce2cf:0x3ffe18b0 0x400f0488:0x3ffe18d0 0x400f05b9:0x3ffe18f0 0x400e5766:0x3ffe1940
>>> 0x400e5849:0x3ffe1980 0x400e589a:0x3ffe19c0 0x400f06bf:0x3ffe19e0 0x400f3a8b:0x3ffe1a00 0x400f3c2e:0x3ffe1a60 0x400f06f3:0x3ffe1ad0 0x4024388e:0x3ffe1af0
>>> 0x400e3295:0x3ffe1b10 0x400e8635:0x3ffe1b40 0x400e87fd:0x3ffe1b70 0x400e3151:0x3ffe1b90 0x400e3160:0x3ffe1bb0 0x400f27b9:0x3ffe1bd0
>>> 0x40097f6b: invoke_abort at /Users/casner/src/github/esp-idf/components/esp32/panic.c:670
>>>
>>> 0x400980c3: abort at /Users/casner/src/github/esp-idf/components/esp32/panic.c:670
>>>
>>> 0x401b8892: duk_default_fatal_handler at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>>
>>> 0x402481dd: duk_fatal_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27715
>>>
>>> 0x401ba5c7: duk__uncaught_minimal at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>> (inlined by) duk_err_longjmp at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:49682
>>>
>>> 0x401c1ae9: duk_throw_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>>
>>> 0x401c89da: duk_js_compile at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>>
>>> 0x401c9e6b: duk__do_compile at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>>
>>> 0x401c9ed1: duk_compile_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>>
>>> 0x401ce2cf: duk_eval_raw at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27339
>>>
>>> 0x400f0488: script_ovms(bool, int, OvmsWriter*, char const*, __sFILE*, bool) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_script.cpp:77
>>>
>>> 0x400f05b9: script_run(int, OvmsWriter*, OvmsCommand*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_script.cpp:133
>>>
>>> 0x400e5766: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_command.cpp:162
>>>
>>> 0x400e5849: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_command.cpp:162
>>>
>>> 0x400e589a: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_command.cpp:162
>>>
>>> 0x400f06bf: Execute(microrl*, int, char const* const*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_shell.cpp:48
>>>
>>> 0x400f3a8b: new_line_handler at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/microrl/microrl.c:620
>>>
>>> 0x400f3c2e: microrl_insert_char at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/microrl/microrl.c:668
>>>
>>> 0x400f06f3: OvmsShell::ProcessChar(char) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_shell.cpp:73
>>>
>>> 0x4024388e: OvmsShell::ProcessChars(char const*, int) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_shell.cpp:80 (discriminator 2)
>>>
>>> 0x400e3295: ConsoleAsync::HandleDeviceEvent(void*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/console_async.cpp:170
>>>
>>> 0x400e8635: OvmsConsole::Poll(unsigned int, void*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_console.cpp:151
>>>
>>> 0x400e87fd: OvmsConsole::Service() at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/ovms_console.cpp:131 (discriminator 1)
>>>
>>> 0x400e3151: ConsoleAsync::Service() at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/console_async.cpp:81
>>>
>>> 0x400e3160: non-virtual thunk to ConsoleAsync::Service() at ??:?
>>>
>>> 0x400f27b9: TaskBase::Task(void*) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/task_base.cpp:156
>>>
>>>
>>> Entering gdb stub now.
>>> $T0b#e6GNU gdb (crosstool-NG) 7.10
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> Reading symbols from /Users/casner/src/github/ovms/vehicle/OVMS.V3/build/ovms3.elf...done.
>>> Remote debugging using /dev/cu.SLAB_USBtoUART
>>> 0x40097f6b in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/panic.c:140
>>> 140            *((int *) 0) = 0;
>>> (gdb) bt
>>> #0  0x40097f6b in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/panic.c:140
>>> #1  0x400980c6 in abort () at /Users/casner/src/github/esp-idf/components/esp32/panic.c:149
>>> #2  0x401b8895 in duk_default_fatal_handler (udata=0x0, msg=0x3f4730b8 "uncaught error")
>>>   at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:16634
>>> #3  0x402481e0 in duk_fatal_raw (ctx=0x3ffd4478, err_msg=0x3f4730b8 "uncaught error")
>>>   at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27715
>>> #4  0x401ba5ca in duk__uncaught_minimal (thr=0x3ffd4478)
>>>   at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:49604
>>> #5  duk_err_longjmp (thr=0x3ffd4478)
>>>   at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:49682
>>> #6  0x401c1aec in duk_throw_raw (ctx=0x3ffd4478)
>>>   at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/duktape/src/duktape.c:27697
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>> (gdb)
>>>
>>>
>>>> On Mon, 9 Jul 2018, Mark Webb-Johnson wrote:
>>>>
>>>>
>>>> I’ve enabled the javascript support in the ovms_scripts module. You can now write script files using the javascript language, and they will be run by the
>>>> duktape engine. Any script file ending with “.js” extension will be treated as javascript.
>>>>
>>>> I’ve also added OvmsCommand and OvmsPrint extension commands.
>>>>
>>>> Two examples:
>>>>
>>>> OVMS# vfs cat /store/scripts/helloworld.js
>>>> OvmsPrint("Hello world!\n”);
>>>>
>>>> OVMS# . helloworld.js
>>>> Hello world!
>>>>
>>>> OVMS# vfs cat /store/scripts/ota.js
>>>> OvmsPrint(OvmsCommand("ota status"));
>>>>
>>>> OVMS# . ota.js
>>>> Running partition: factory
>>>> Boot partition:    factory
>>>> Firmware:          3.1.008-40-g9254170-dirty/factory/edge (build idf v3.1-dev-1583-g0fb2019f Jul  9 2018 08:49:48)
>>>> Server Available:  3.1.008-37-g939416c (no update required)
>>>>
>>>> Sat Jul 7 16:00:45 UTC 2018 Automated build (markhk8)
>>>> ...
>>>>
>>>> A useful example would be to have a script that runs on location.leave, and checks the v.e.gear metric for vehicle in Drive, before firing off the homelink
>>>> to close the garage door.
>>>>
>>>> Like all good things, the opportunity for evil is forever prevalent (and truly scary):
>>>>
>>>> OVMS# vfs cat /store/scripts/bruteforce.js
>>>> for (var pin = 1000; pin < 10000; pin++)
>>>> {
>>>> OvmsCommand("unlock " + pin);
>>>> }
>>>>
>>>> OVMS# . bruteforce.js
>>>> V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e8 03 00 40 | .......@
>>>> V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e9 03 00 40 | .......@
>>>> V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 ea 03 00 40 | .......@
>>>> V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 eb 03 00 40 | .......@
>>>> V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ec 03 00 40 | .......@
>>>> V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ed 03 00 40 | .......@
>>>> V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ee 03 00 40 | .......@
>>>> V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ef 03 00 40 | .......@
>>>> V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 f0 03 00 40 | .......@
>>>> V (1421394) canlog: TX can1 id 102 len 8: 0b 03 00 00 f1 03 00 40 | .......@
>>>> ...
>>>>
>>>> I’ll leave it up to an exercise to the reader to change that script to use DukOvmsMetricValue() to monitor the v.e.locked metric to record success.
>>>>
>>>> Note that this is very hacky and experimental at the moment. A better approach seems to be to have a javascript task running, initialised at boot with a
>>>> user’s javascript program. That can have timers, and whatever else it needs, to do it’s stuff. Then, scripts executed are run in the context of that task.
>>>> The current implementation is really just a proof of concept. The OvmsPrint is particularly kludgy (a better implementation would be to hook to the duktape
>>>> I/O system). Duktape is also currently running in internal RAM, although changing it to use SPI RAM should not be hard.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>> From: GitHub
>>>>>
>>>>> Branch: refs/heads/master
>>>>> Home:   https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3
>>>>> Commit: f1736f927df582c5ff374ef5d8c3a565e8f67295
>>>>>    https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f1736f927df582c5ff374ef5d8c3a565e8f67295
>>>>> Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>>> Date:   2018-07-09 (Mon, 09 Jul 2018)
>>>>>
>>>>> Changed paths:
>>>>>  M vehicle/OVMS.V3/main/ovms_command.cpp
>>>>>
>>>>> Log Message:
>>>>> -----------
>>>>> Javascript: Add a OvmsCommand function to execute an OVMS command
>>>>>
>>>>>
>>>>> Commit: 69427f4ac0cf68dc462b05752936befe4be22256
>>>>>    https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/69427f4ac0cf68dc462b05752936befe4be22256
>>>>> Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>>> Date:   2018-07-09 (Mon, 09 Jul 2018)
>>>>>
>>>>> Changed paths:
>>>>>  M vehicle/OVMS.V3/main/ovms_script.cpp
>>>>>
>>>>> Log Message:
>>>>> -----------
>>>>> Javascript: Add a OvmsPrint function to be able to print a string
>>>>> JavaScript: Support .js script files (executed with javascript engine)
>>>>>
>>>>>
>>>>> Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/925417081d8e...69427f4ac0cf
>>>>>    **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/
>>>>>
>>>>>    Functionality will be removed from GitHub.com <http://GitHub.com> on January 31st, 2019.
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181222/83877b90/attachment.htm>


More information about the OvmsDev mailing list