<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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>
<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>
<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 class="moz-cite-prefix">Am 08.02.26 um 09:17 schrieb Michael
Geddes:<br>
</div>
<blockquote type="cite"
cite="mid:CAH0p7u+P4urJ1W3cBNjnhoY7Lp6HhozZV-vczF_Y1NtS5uJEJw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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 gmail_quote_container">
<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"
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"
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" 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_-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"
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></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" 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"
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 * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
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" 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 class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</body>
</html>