[Ovmsdev] Javascript

Mon Jan 7 18:44:41 HKT 2019

Hi Mark,

Great news about scripting.

Which of your comments below are still to be addressed?

Note that this is very hacky and experimental at the moment. A better approach seems to be to have a javascript task running, initialised at boot with a user’s javascript program. That can have timers, and whatever else it needs, to do it’s stuff. Then, scripts executed are run in the context of that task.

The current implementation is really just a proof of concept. The OvmsPrint is particularly kludgy (a better implementation would be to hook to the duktape I/O > system). 

Duktape is also currently running in internal RAM, although changing it to use SPI RAM should not be hard.

Thanks,
Rob

Am 09.07.2018 um 07:40 schrieb Mark Webb-Johnson:
>
> I’ve enabled the javascript support in the ovms_scripts module. You can now write script files using the javascript language, and they will be run by the
> duktape engine. Any script file ending with “.js” extension will be treated as javascript.
>
> I’ve also added OvmsCommand and OvmsPrint extension commands.
>
> Two examples:
>
>     OVMS# vfs cat /store/scripts/helloworld.js
>     OvmsPrint("Hello world!\n”);
>
>     OVMS# . helloworld.js
>     Hello world!
>
>
>     OVMS# vfs cat /store/scripts/ota.js
>     OvmsPrint(OvmsCommand("ota status"));
>
>     OVMS# . ota.js
>     Running partition: factory
>     Boot partition:    factory
>     Firmware:          3.1.008-40-g9254170-dirty/factory/edge (build idf v3.1-dev-1583-g0fb2019f Jul  9 2018 08:49:48)
>     Server Available:  3.1.008-37-g939416c (no update required)
>
>     Sat Jul 7 16:00:45 UTC 2018 Automated build (markhk8)
>     ...
>
>
> A useful example would be to have a script that runs on location.leave, and checks the v.e.gear metric for vehicle in Drive, before firing off the homelink to
> close the garage door.
>
> Like all good things, the opportunity for evil is forever prevalent (and truly scary):
>
>     OVMS# vfs cat /store/scripts/bruteforce.js
>     for (var pin = 1000; pin < 10000; pin++)
>       {
>       OvmsCommand("unlock " + pin);
>       }
>
>     OVMS# . bruteforce.js
>     V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e8 03 00 40 | .......@
>     V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e9 03 00 40 | .......@
>     V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 ea 03 00 40 | .......@
>     V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 eb 03 00 40 | .......@
>     V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ec 03 00 40 | .......@
>     V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ed 03 00 40 | .......@
>     V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ee 03 00 40 | .......@
>     V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ef 03 00 40 | .......@
>     V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 f0 03 00 40 | .......@
>     V (1421394) canlog: TX can1 id 102 len 8: 0b 03 00 00 f1 03 00 40 | .......@
>     ...
>
>
> I’ll leave it up to an exercise to the reader to change that script to use DukOvmsMetricValue() to monitor the v.e.locked metric to record success.
>
> Note that this is very hacky and experimental at the moment. A better approach seems to be to have a javascript task running, initialised at boot with a
> user’s javascript program. That can have timers, and whatever else it needs, to do it’s stuff. Then, scripts executed are run in the context of that task. The
> current implementation is really just a proof of concept. The OvmsPrint is particularly kludgy (a better implementation would be to hook to the duktape I/O
> system). Duktape is also currently running in internal RAM, although changing it to use SPI RAM should not be hard.
>
> Regards, Mark.
>
>> Begin forwarded message:
>>
>> *From: *GitHub
>>
>>  Branch: refs/heads/master
>>  Home:   https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3
>>  Commit: f1736f927df582c5ff374ef5d8c3a565e8f67295
>>      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f1736f927df582c5ff374ef5d8c3a565e8f67295
>>  Author: Mark Webb-Johnson <http://lists.openvehicles.com/mailman/listinfo/ovmsdev <mailto:http://lists.openvehicles.com/mailman/listinfo/ovmsdev>>
>>  Date:   2018-07-09 (Mon, 09 Jul 2018)
>>
>>  Changed paths:
>>    M vehicle/OVMS.V3/main/ovms_command.cpp
>>
>>  Log Message:
>>  -----------
>>  Javascript: Add a OvmsCommand function to execute an OVMS command
>>
>>
>>  Commit: 69427f4ac0cf68dc462b05752936befe4be22256
>>      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/69427f4ac0cf68dc462b05752936befe4be22256
>>  Author: Mark Webb-Johnson <http://lists.openvehicles.com/mailman/listinfo/ovmsdev <mailto:http://lists.openvehicles.com/mailman/listinfo/ovmsdev>>
>>  Date:   2018-07-09 (Mon, 09 Jul 2018)
>>
>>  Changed paths:
>>    M vehicle/OVMS.V3/main/ovms_script.cpp
>>
>>  Log Message:
>>  -----------
>>  Javascript: Add a OvmsPrint function to be able to print a string
>> JavaScript: Support .js script files (executed with javascript engine)
>>
>>
>> Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190107/30c8a013/attachment.html>