- OvmsDev - Open Vehicles

OPENVEHICLES.COM server relocation
by Mark Webb-Johnson 11 Apr '26

11 Apr '26

Apologies for the late notice, but I need to urgently relocate the openvehicles.com server. This will likely cause some outages, as follows: Within the next few hours, the website will move. It will be unavailable during that time. Similarly, the api.openvehicles.com <http://api.openvehicles.com/> services (OVMS server v3 and mosquito) will move. There should be no interruption, other than DNS switch times (< 1 hour). I plan to take down the mail server early tomorrow morning (Hong Kong time), and it will likely be down for the most of the day. The will likely be night time for USA and Europe. Once all the mailing list data has been transferred, I will re-enable the mail server, and send an announcement here to confirm. Regards, Mark.

1 1

Firmware size approaching 4 MB limit
by Michael Balzer 07 Apr '26

07 Apr '26

Everyone, with the latest vehicle additions, the firmware size has now grown to 4,015,328 bytes in build 3.3.005-485-gc4664881. Our flash partitioning scheme is currently designed to provide three firmware partitions (factory, ota_0 & ota_1) of 4MB = 4,194,304 bytes each. So we've now got 178,976 bytes = ~4% left. Options beyond the 4 MB limit: a) split features, e.g. vehicle support, into two or more builds b) repartition into two firmware partitions of 6 MB each, reusing the factory partition for OTA c) switch to an ESP32 WROOM module with 32 MB flash (possible?) We've got some time left, new vehicles normally don't need that much space, I just wanted to raise awareness. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

5 33

Help
by Tamás Kovács 05 Apr '26

05 Apr '26

I noticed the following on my car, a Hyundai Ioniq AE 28kWh. Unfortunately, the 12V battery discharged several times in the cold weather and I was looking for a solution to fix this. The selected car kept the car awake all the time and the consumption was > 500mA. Then I started switching the module to NONE when I wasn't driving it or charging it and then I ran into the error that polling doesn't work anymore. I'm attaching a command output. If I restart OVMS (module reset), it works fine again until I switch to NONE. -- Kovács Tamás

1 0

VW e-Golf: working on comfort CAN / climate scheduler support
by Andreas Jansson 04 Apr '26

04 Apr '26

Hi all, I'm Andreas, based in Sweden, owner of a 2019 VW e-Golf. I've just joined the list to let you know I'm working on adding comfort CAN support to the e-Golf vehicle module, with climate scheduler control as the primary goal. With VW discontinuing the Car-Net app due to the decommissioning of 2G, e-Golf owners lost the ability to trigger climate controls remotely. The car's built-in e-manager timer still works, but can't be changed remotely. That's the gap I'm trying to close. The existing e-Golf module (PR #1327) reads SoC, odometer, range and charge status via the diagnostic and powertrain CAN buses at J533, but the comfort CAN has remained unimplemented. A few things I'm leaning on: - thomasakarlsen/e-golf-comfort-can has comfort CAN traces from an actual e-Golf showing BAP traffic on the climate and scheduler LSGs - MIGINC/BAP_RE documents the MQB BAP protocol structure and Climatronic ID mappings - drgrandios/ovmslogs has annotated e-Up BAP frame decoding that maps closely to what appears in the e-Golf traces Cross-referencing these makes the scheduler write path look doable, and the e-Up implementation in OVMS looks like a useful reference. I'm working in a fork (investigation branch) where I'm collecting all relevant context and building a test suite before touching any car-side code. I have an OVMS module and will be doing all testing on my own car before anything comes near a PR. If there are other e-Golf owners on the list, or anyone who has looked at this before, I'd be glad to hear from you. Fork: https://github.com/slothish/Open-Vehicle-Monitoring-System-3-VWeGolf/tree/i… Andreas

2 1

Firmware release 3.3.006
by Michael Balzer 18 Mar '26

18 Mar '26

Everyone, I suggest making the OTA repartitioning the closing feature for the 3.3.006 release (to be accompanied by Android App release 5.2.4). Feature development has settled a bit lately, and crashes are mostly eliminated. I especially haven't seen a single heap corruption in the last weeks. The remaining crash reports still hint at a possible common issue with transitions from mobile to wifi, but otherwise seem to be more caused by individual misconfigurations like bad event script behaviour now. Release 3.3.005 was on 2025-07-18. We've got three new vehicles since 3.3.005 (Maxus T90, Fiat e-Doblo & VW e-Golf), and a lot of improvements especially on the Smart vehicle support, so I'd say 3.3.006 is due. If you've got anything important in the making that should be included, please reply. Regards, Michael -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

3 3

Draft P/R - Retrying starting of ECU Can
by Michael Geddes 12 Mar '26

12 Mar '26

I have a draft for a little issue I was encountering where the ECU CAN was not starting. It was possibly happening in a hot car? It was compounded by the state going to ON despite it not actually starting. I have moved the map loading into the ECU Task, and I retry turing the CAN on in the task until it starts or is killed. I've also put some mutexes around the value map access. I was contemplating just moving the map reload into the thread, but then the dump still should be mutexed. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1350 It still needs some more testing, but feedback wouldbe welcome. //.

1 0

Re: [Ovmsdev] Firmware size approaching 4 MB limit
by Craig Leres 26 Feb '26

26 Feb '26

[I'm having trouble with dkim, *only* with lists.openvehicles.com ...] On 2/25/26 12:10, Michael Balzer wrote: > your backtrace is in is_safe_write_address() -- is it possible you > forgot to change your sdkconfig? > >> One big âgotchaâ I found was that we need to >> set CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ABORT= >> and CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ALLOWED=y in our >> sdkconfig - otherwise the partition table cannot be re-flashed. Of course you're right... Ok, that works better. The only nit I have is that it left me with the boot partition set to factory, not sure what happens if you try booting with that set after the factory partition was renamed. Craig

2 1

Re: [Ovmsdev] Firmware size approaching 4 MB limit
by Michael Balzer 26 Feb '26

26 Feb '26

Craig, your backtrace is in is_safe_write_address() -- is it possible you forgot to change your sdkconfig? > One big ‘gotcha’ I found was that we need to > set CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ABORT= > and CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ALLOWED=y in our > sdkconfig - otherwise the partition table cannot be re-flashed. Regards, Michael Am 25.02.26 um 20:09 schrieb Craig Leres: > I tried 3.3.005-714-gbcf42700. Unfortunately the upgrade step results > in a crash. > > > > OVMS# ota > Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM SIM7600 > Firmware: 3.3.005-714-gbcf42700-dirty/factory/main (build idf > v3.3.4-854-g9063c8662 Feb 25 2026 10:36:43) > Partition type: v3-f12 (factory, ota1, ota2) > Partition table: 0x8000 > Running partition: factory > Boot partition: factory > Factory image: 3.3.005-714-gbcf42700-dirty > OTA_O image: 3.3.005-714-gbcf42700-dirty > OTA_1 image: 3.3.005-711-g4feca695-dirty > OVMS# ota partitions list > Partition table: > Label Type Subtype Address Size > nvs data nvs 0x00009000 16 KB > otadata data ota 0x0000d000 8 KB > phy_init data phy 0x0000f000 4 KB > factory app factory 0x00010000 4 MB > ota_0 app ota_0 0x00410000 4 MB > ota_1 app ota_1 0x00810000 4 MB > store data fat 0x00c10000 1 MB > Digest: cfe36765a6bfe1b802a2abd4ec9f6851 pass > OVMS# ota partitions upgrade > Upgrade partition table to new format (y/n): y > 0x00009000 Skipping over data/nvs partition > 0x0000d000 Skipping over data/ota partition > 0x0000f000 Skipping over data/phy partition > 0x00010000 Converted factory partition to 6MB OTA 0 > 0x00610000 Converted OTA 0 partition to 6MB OTA 1 > 0x00c10000 Moved data/fat partition up one position > Recalculated MD5 checksum > Clearing trailing old MD5 checksum record > Erasing old partition table (4096 bytes at 0x00008000)... > > > > > sea 4 % ./backtrace.sh 0x400891b7:0x3ffebbd0 0x40089451:0x3ffebbf0 > 0x401c82cc:0x3ffebc10 0x40084cfa:0x3ffebc30 0x4018397d:0x3ffebc60 > 0x40180c03:0x3ffebcf0 0x40180c3f:0x3ffebd20 0x40146bdd:0x3ffebd40 > 0x40289911:0x3ffebd60 0x400e1091:0x3ffebd80 0x40137f55:0x3ffebe40 > 0x400e077d:0x3ffebe70 0x400e0a10:0x3ffebea0 0x400e0a43:0x3ffebf50 > 0x401566d1:0x3ffebf70 0x40157ed7:0x3ffebfb0 0x401582e1:0x3ffebfe0 > 0x40158593:0x3ffec050 0x40154aa2:0x3ffec0b0 0x4015a2fe:0x3ffec0d0 > 0x401442ec:0x3ffec100 0x40144415:0x3ffec160 > + xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891b7:0x3ffebbd0 > 0x40089451:0x3ffebbf0 0x401c82cc:0x3ffebc10 0x40084cfa:0x3ffebc30 > 0x4018397d:0x3ffebc60 0x40180c03:0x3ffebcf0 0x40180c3f:0x3ffebd20 > 0x40146bdd:0x3ffebd40 0x40289911:0x3ffebd60 0x400e1091:0x3ffebd80 > 0x40137f55:0x3ffebe40 0x400e077d:0x3ffebe70 0x400e0a10:0x3ffebea0 > 0x400e0a43:0x3ffebf50 0x401566d1:0x3ffebf70 0x40157ed7:0x3ffebfb0 > 0x401582e1:0x3ffebfe0 0x40158593:0x3ffec050 0x40154aa2:0x3ffec0b0 > 0x4015a2fe:0x3ffec0d0 0x401442ec:0x3ffec100 0x40144415:0x3ffec160 > /home/sea/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 > > /home/sea/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 > > /home/sea/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/spi_flash/flash_ops.c:124 > > /home/sea/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/spi_flash/flash_ops.c:220 > (discriminator 2) > components/ovms_ota/src/ovms_partitions.cpp:394 > components/ovms_ota/src/ovms_ota.cpp:1088 > components/ovms_ota/src/ovms_ota.cpp:1088 > main/ovms_shell.cpp:67 > main/ovms_shell.cpp:80 (discriminator 2) > components/console_ssh/src/console_ssh.cpp:527 > main/ovms_console.cpp:184 > components/console_ssh/src/console_ssh.cpp:420 > components/console_ssh/src/console_ssh.cpp:420 > components/console_ssh/src/console_ssh.cpp:420 > components/mongoose/mongoose/mongoose.c:1701 > components/mongoose/mongoose/mongoose.c:1701 > components/mongoose/mongoose/mongoose.c:1701 > components/mongoose/mongoose/mongoose.c:1701 > components/mongoose/mongoose/mongoose.c:1701 > components/mongoose/src/mongoose_client.cpp:52 > main/ovms_netmanager.cpp:1000 > main/ovms_netmanager.cpp:980 > > -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

Re: [Ovmsdev] Registering / Web pages for Scripted Implementation
by Michael Balzer 08 Feb '26

08 Feb '26

Michael, 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. 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. For reference: baseline memory usage of Duktape with our builtin libs (PubSub etc) is currently ~130 KB. The current ECU toolkit plugin for the UpMiiGo adds ~70 KB to that. ABRP probably is in the same ballpark, similar complexity. 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. Regards, Michael Am 08.02.26 um 14:17 schrieb Michael Geddes: > Answers below > > On Sun, 8 Feb 2026, 16:52 Michael Balzer, <dexter(a)expeedo.de> wrote: > > 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. > > Ok. Will add something for that. > > > 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? > > 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. > > 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. > > > 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. > > 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. > > Regards, > Michael > > > Am 08.02.26 um 09:17 schrieb Michael Geddes: >> 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). >> >> 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. >> >> 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'. >> >> 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). >> >> //.ichael >> >> >> On Sun, 8 Feb 2026 at 15:52, Michael Balzer via OvmsDev >> <ovmsdev(a)lists.openvehicles.com> wrote: >> >> 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. >> >> IMO a scripted vehicle should be basically a standard plugin. >> >> 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. >> >> 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. >> >> 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). >> >> 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). >> >> 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. >> >> Regards, >> Michael >> >> >> Am 08.02.26 um 01:20 schrieb Michael Geddes via OvmsDev: >>> Just a thought, but being able to add custom metrics would >>> do a lot. Non-persisting metrics would handle temporary >>> variables too no? >>> >>> Responding to temporary metric change events would then >>> allow Responding to changes to polled variables. >>> >>> Also note that the poller.Add requires a unique id which >>> means the same one added twice will just overwrite the >>> previous one. >>> //. >>> >>> >>> On Sat, 7 Feb 2026, 21:44 Michael Geddes, >>> <frog(a)bunyip.wheelycreek.net> wrote: >>> >>> 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). >>> >>> 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. >>> >>> OvmsPoller.Poll.Request() also allows you to do one-off >>> calls with a call back for the response (so not blocking). >>> >>> Have a look at the scripting help.. it's all there. >>> >>> I was thinking we could have a special >>> OvmsVehicleScripted() that when selected loads files >>> from a certain configured directory. Like >>> >>> /sd/vehicles/Ioniq5/ >>> init.js >>> shutdown.js >>> events/ >>> ticker1.js >>> >>> Then the init.js could call back to provide the vehicle >>> a name, and set up some events and polling. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> So anyway, much of that stuff you were talking about is >>> already done. >>> >>> //.ichael >>> >>> On Sat, 7 Feb 2026, 21:23 Mark Webb-Johnson, >>> <mark(a)webb-johnson.net> wrote: >>> >>> Michael, >>> >>> 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. >>> >>> My thoughts on how this should work are: >>> >>> 1. 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. >>> 2. 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(…). >>> 3. The ‘auto’ system, and ‘vehicle module’, >>> ‘vehicle list’, etc, commands, then just treat >>> these javascript vehicles the same as any other. >>> 4. Obviously all the base vehicle class functions >>> would need to have callbacks / exposed to >>> javascript implementations. >>> 5. For CAN bus, I see two options: >>> 1. 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. >>> 2. 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. >>> 6. 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? >>> >>> >>> I suggest to just focus on passive listening (DBC >>> and an optional CAN ID callback). Fist build the >>> registration functions callable from Javascript. >>> >>> 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. >>> >>> Regards, Mark. >>> >>>> On Feb 7, 2026, at 8:17 AM, Michael Geddes via >>>> OvmsDev <ovmsdev(a)lists.openvehicles.com> wrote: >>>> >>>> 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. >>>> >>>> To clarify - I'm not sure about all these pieces- >>>> they are just suggestions that I would love some >>>> feedback on. >>>> >>>> * Have a special 'Duktape' vehicle that then can >>>> be set to load up a special folder location >>>> containing all the pieces >>>> o Add in an extra folder for events? (cf >>>> requiring DukTape event registration) >>>> * Be able to set the vehicle name (for the menu) >>>> * Allow adding the standard battery monitor page >>>> (I have code for updating the bms code nearly >>>> ready to ship) >>>> * Adding custom configuration pages (I'm thinking >>>> a call-back to fetch the page layout or a >>>> callback object or something?) >>>> * Defining ranges for the main dashboard >>>> * Can already add duktape implemented commands - >>>> should there be a specific folder for vehicle >>>> implementation or leave as-is? >>>> >>>> What other pieces are we missing to be able to >>>> handle new vehicles in duktape? >>>> >>>> //.ichael >>>> >>>> . >>>> >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev(a)lists.openvehicles.com >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>> >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.openvehicles.com >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> >> -- >> Michael Balzer *Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gma…> >> Fon 02330 9104094 * Handy 0176 20698926 >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> > > -- > Michael Balzer *Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gma…> > Fon 02330 9104094 * Handy 0176 20698926 > > -- Michael Balzer * Am Rahmen 5 * D-58313 Herdecke Fon 02330 9104094 * Handy 0176 20698926

1 0

Registering / Web pages for Scripted Implementation
by Michael Geddes 08 Feb '26

08 Feb '26

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. To clarify - I'm not sure about all these pieces- they are just suggestions that I would love some feedback on. - Have a special 'Duktape' vehicle that then can be set to load up a special folder location containing all the pieces - Add in an extra folder for events? (cf requiring DukTape event registration) - Be able to set the vehicle name (for the menu) - Allow adding the standard battery monitor page (I have code for updating the bms code nearly ready to ship) - Adding custom configuration pages (I'm thinking a call-back to fetch the page layout or a callback object or something?) - Defining ranges for the main dashboard - Can already add duktape implemented commands - should there be a specific folder for vehicle implementation or leave as-is? What other pieces are we missing to be able to handle new vehicles in duktape? //.ichael .

3 6