<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Michael,<br>
<br>
ideally most metrics logic would already be in the DBC, and I don't
think a user will normally need to load more than two, maybe three
vehicle plugins.<br>
<br>
Even if so, we've got plenty of SPIRAM left to assign to Duktape.
Default is 512 KB, and can be changed by the user via config module
duktape.heapsize. We wouldn't have any issues with raising the
default to 1 MB.<br>
<br>
For reference: baseline memory usage of Duktape with our builtin
libs (PubSub etc) is currently ~130 KB.<br>
<br>
The current ECU toolkit plugin for the UpMiiGo adds ~70 KB to that.
ABRP probably is in the same ballpark, similar complexity.<br>
<br>
Rather RAM hungry is the aux battery monitor, as the 24 hour per
minute recording of 5 float metrics actually uses quite some RAM.
There's certainly a more efficient way to implement that, especially
the array slice operations need to copy the whole array.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 08.02.26 um 14:17 schrieb Michael
Geddes:<br>
</div>
<blockquote type="cite"
cite="mid:CAH0p7uJoH1SfXD0+OvTrKvh+f_TrZxAZpwOQiMY6_9ySthm9sg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="auto">
<div>Answers below<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 8 Feb 2026,
16:52 Michael Balzer, <<a
href="mailto:dexter@expeedo.de" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">dexter@expeedo.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> You're right, if the DBC engine or poller need
some extra variables, these must not be JS variables.
Metrics OTOH should be used only for vehicle or system
states & sensor readings that are meant to be
exposed to all components & users, so some extra
internal variable container shared between DBC/polling
and JS makes sense.<br>
</div>
</blockquote>
</div>
</div>
<div dir="auto">Ok. Will add something for that.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
I don't yet see the issue with the duktape vehicle
objects & commands, can you elaborate on this, or
provide an example of the issue you see?<br>
<br>
The plugin way would make scripted vehicles simply
extend the list of available vehicle types, enabling
adding multiple of these as needed and switching
between these without an additional level / separate
way to configure these. From a user perspective they
should behave just like native vehicle modules.<br>
</div>
</blockquote>
</div>
</div>
<div dir="auto">Ok. Makes sense to have the extra modules in
the list.. I was thinking that we wouldn't want to have
loaded the extra modules into duktape. Hence the idea of a
manifest we could include in the list. Then when that was
selected it could load the plugin... or make it available.
Also then it could be unloaded similarly.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> <br>
I think using standard `PubSub` event handlers for a
scripted vehicle is most convenient, as these enable
direct access to the plugin's internal model &
methods, so these don't need to be exposed via an
export.<br>
<br>
The Tasmota Smart Plug plugin is probably a good
example for a plugin including event handling,
configuration & a status plugin with a live update
stream.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 08.02.26 um 09:17 schrieb Michael Geddes:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On temporary variables: I was more
thinking of the ones that are set from the
poller and dbc engine, not other scripting ones
(which I agree can be just duktape variables).
<div><br>
</div>
<div>
<div>Regular polls should not be calling back
into the scripting engine directly. If, for
example, there is an OBD value that needs
more than a simple factor or unit conversion
(which can be handled directly) you could
use a non-persisted metric as a stepping
stone to set a more concrete metric. If
this is NOT acceptable, then we would need a
mechanism or prefix or something, that would
allow us to store the value in a shared
std::map which could be made available to
the duktape interface. So a target in DBC
of _temp_myvariable could then have
'myvariable' available in duktape somehow.</div>
</div>
<div><br>
</div>
<div>I see what you mean by the standard
plugin.. but then there are certain duktape
objects and commands that require an active
vehicle.. which is why I was thinking that a
special vehicle object could activate this
plugin on load. We could still leverage off
standard plugin stuff (which makes sense, I
should have a look at that), but it could be
enabled/disabled by the special vehicle type.
The vehicle plugins could have a standard
registration file so that we could then have a
drop-down with the available plugin-vehicles
specified, allowing you to switch between
different 'plugin vehicles'.</div>
<div><br>
</div>
<div>In the example of having scripted event
files, I was thinking that this could be on
top of javascript events (if, for example, you
wanted to use shared variables).</div>
<div><br>
</div>
<div>//.ichael</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 8 Feb
2026 at 15:52, Michael Balzer via OvmsDev <<a
href="mailto:ovmsdev@lists.openvehicles.com"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</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> 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>Am 08.02.26 um 01:20 schrieb Michael
Geddes via OvmsDev:<br>
</div>
<blockquote type="cite">
<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">
<div dir="ltr" class="gmail_attr">On
Sat, 7 Feb 2026, 21:44 Michael
Geddes, <<a
href="mailto:frog@bunyip.wheelycreek.net" rel="noreferrer"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">frog@bunyip.wheelycreek.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 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" rel="noreferrer noreferrer"
target="_blank"
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_-3826454560591843993m_5564737715104608343m_-4764154765576746796m_-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 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 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 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></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Michael Balzer * <a
href="https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g"
target="_blank" moz-do-not-send="true">Am Rahmen 5 * D-58313 Herdecke</a>
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a
href="mailto:OvmsDev@lists.openvehicles.com"
rel="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>
</blockquote>
</div>
</div>
</blockquote>
<br>
<pre cols="72">--
Michael Balzer * <a
href="https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g"
target="_blank" moz-do-not-send="true">Am Rahmen 5 * D-58313 Herdecke</a>
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</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>