<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I think JS addable custom metrics are a crucial element here, as
most vehicles provide extended info not covered by the standard
metrics. But metrics should not be the means to implement vehicle
internal temporary variables.<br>
<br>
IMO a scripted vehicle should be basically a standard plugin.<br>
<br>
That way we have a simple way of adding these, and we also already
have the web plugins bundled to cover custom config & monitoring
pages of a scripted vehicle.<br>
<br>
The plugin's JS module then provides an internal object scope for
any temporary variables and event handlers needed in one place. I.e.
not separate files for actions / handlers, but load & parse all
necessary code on JS init, and especially no need to use metrics for
internal temporary variables.<br>
<br>
The vehicle factory would get a JS API to register/deregister a
scripted vehicle, and the module would export a defined standard set
of entry points to be called by the vehicle factory to load/unload a
scripted vehicle (and what else might be needed).<br>
<br>
The load call would then do all the necessary metrics & event
& command registrations, load the DBC file and install a custom
polling list, and enable the plugin's web pages & hooks (these
should be disabled until then, that may need an extension to the
plugin definition, and probably an API call to avoid having to
change the web plugin config directly).<br>
<br>
Btw, regarding plugin web pages, especially for configuration pages
it would be nice (but not crucial) to have some JS based form input
widget rendering helpers similar to the `PageContext` utils.
Currently a web plugin needs to include the HTML code, which really
isn't that complicated with the bootstrap components, so this really
is more of a nice2have.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 08.02.26 um 01:20 schrieb Michael
Geddes via OvmsDev:<br>
</div>
<blockquote type="cite"
cite="mid:CAH0p7uJ7bdLdCjS6u6MLOfyyv9wYZ4zZMeetjnkUhrDiaMiOTw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>Just a thought, but being able to add custom metrics would
do a lot. Non-persisting metrics would handle temporary
variables too no?
<div dir="auto"><br>
</div>
<div dir="auto">Responding to temporary metric change events
would then allow Responding to changes to polled variables. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Also note that the poller.Add requires a
unique id which means the same one added twice will just
overwrite the previous one.</div>
<div dir="auto">//.</div>
<br>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Sat, 7 Feb 2026, 21:44
Michael Geddes, <<a
href="mailto:frog@bunyip.wheelycreek.net"
moz-do-not-send="true" class="moz-txt-link-freetext">frog@bunyip.wheelycreek.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div dir="auto">The active polling is already
implemented with OvmsPoller.Poll.Add() which hooks
into my poller stuff (which was pretty much the
whole reason I started down that road).</div>
<div dir="auto"><br>
</div>
<div>This allows you to send polled messages and
either let DBC files handle the listening, or it has
its own decode function. The decode system actually
uses the DBC code, but multiframe responses are
handled with slightly different buffers.</div>
<div><br>
</div>
<div>OvmsPoller.Poll.Request() also allows you to do
one-off calls with a call back for the response (so
not blocking).</div>
<div><br>
</div>
<div>Have a look at the scripting help.. it's all
there.</div>
<div><br>
</div>
<div>I was thinking we could have a special
OvmsVehicleScripted() that when selected loads
files from a certain configured directory. Like</div>
<div><br>
</div>
<div>/sd/vehicles/Ioniq5/</div>
<div> init.js</div>
<div> shutdown.js</div>
<div> events/</div>
</div>
ticker1.js
<div><br>
</div>
<div>Then the init.js could call back to provide the
vehicle a name, and set up some events and polling.</div>
<div><br>
</div>
<div>We could add in events/ so that there's a choice
between adding the events in init.js or responding by
running js or other scripts.</div>
<div><br>
</div>
<div>At the moment we have special targets in dbc/ or
decode {} sections that are metrics, and I'm just
adding in the ability to handle the battery
voltage/temp averaging code bms.v.1 and to set
elements in vector metrics.</div>
<div><br>
</div>
<div>We could have other types of special targets that
could be in-memory and then be either polled or
triggered events on change or something.</div>
<div><br>
</div>
<div>So anyway, much of that stuff you were talking
about is already done.</div>
<div><br>
</div>
<div>//.ichael</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 7 Feb
2026, 21:23 Mark Webb-Johnson, <<a
href="mailto:mark@webb-johnson.net"
target="_blank" rel="noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">mark@webb-johnson.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Michael,
<div><br>
</div>
<div>Happy to support you with this. I am
currently completing my work on the partition
rearrangement, and when done I can assist with
this. Perhaps I can try to implement a vehicle
type in pure Javascript? My current daily
driver Model 3 is well documented, but only
has stubbed OVMS support.</div>
<div><br>
</div>
<div>My thoughts on how this should work are:</div>
<div><br>
</div>
<div>
<ol>
<li>The vehicle base class should have a
companion helper class for pure javascript
vehicle implementations (extend the
current vehicle_duktape). This would be in
the components/vehicle directory.</li>
<li>Javascript vehicles are implemented as
plugins, and they can call that companion
class to register their vehicle type and
callback functions. So plugin loads,
registers itself with vehicle_duktape,
which in turn does
the MyVehicleFactory.RegisterVehicle(…).</li>
<li>The ‘auto’ system, and ‘vehicle module’,
‘vehicle list’, etc, commands, then just
treat these javascript vehicles the same
as any other.</li>
<li>Obviously all the base vehicle class
functions would need to have callbacks /
exposed to javascript implementations.</li>
<li>For CAN bus, I see two options:</li>
<ol>
<li>For passive listening, DBC files are
primarily used. Just need an ability
(may already exist) for the javascript
vehicle to attach one to the CAN bus.</li>
<li>For active polling, we would need to
either come up with some new format (I
know torque and other such apps have a
proprietary definition file format for
PIDs that we could adapt from) or just
define the polling table from
javascript.</li>
</ol>
<li>In both options, we would also need to
be able to override and have particular
passively listened CAN IDs, or actively
polled PIDs, callback to javascript for
custom processing. I suspect it would be
helpful to have a time limit on these
callbacks - so if for example you specify
1000ms then you would only get the
callback at most once a second. Javascript
will be much more overhead than C++
handling these CAN messages, and in most
cases we don’t need them updated that
regularly. Think of a battery SOC - does
it really need to update 10 or 100 times a
second for our purposes?</li>
</ol>
</div>
<div><br>
</div>
<div>I suggest to just focus on passive
listening (DBC and an optional CAN ID
callback). Fist build the registration
functions callable from Javascript.</div>
<div><br>
</div>
<div>After I'm done with partitions, I’ll have a
look at this code in more detail as it has
been a while since I’ve worked on that part.</div>
<div><br>
</div>
<div>Regards, Mark.<br
id="m_-4859176707975213627m_-3195181911818417925m_-6900673230859709630lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Feb 7, 2026, at 8:17 AM, Michael
Geddes via OvmsDev <<a
href="mailto:ovmsdev@lists.openvehicles.com" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">With this talk about
running out of space on the devices, I
wanted to open up a discussion about
how we might organise a vehicle
implementation in Duktape.
<div><br>
</div>
<div>To clarify - I'm not sure about
all these pieces- they are just
suggestions that I would love some
feedback on.</div>
<div><br>
</div>
<div>
<ul>
<li> Have a special 'Duktape'
vehicle that then can be set to
load up a special folder
location containing all the
pieces</li>
<ul>
<li>Add in an extra folder for
events? (cf requiring DukTape
event registration)</li>
</ul>
<li>Be able to set the vehicle
name (for the menu)</li>
<li>Allow adding the standard
battery monitor page (I have
code for updating the bms code
nearly ready to ship)</li>
<li>Adding custom configuration
pages (I'm thinking a call-back
to fetch the page layout or a
callback object or something?)</li>
<li>Defining ranges for the main
dashboard</li>
<li>Can already add duktape
implemented commands - should
there be a specific folder for
vehicle implementation or leave
as-is?</li>
</ul>
What other pieces are we missing to
be able to handle new vehicles in
duktape?</div>
<div><br>
</div>
<div>//.ichael</div>
<div>
<div><br>
</div>
</div>
<div>. </div>
<div><br>
</div>
<div><br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a
href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</body>
</html>