Hi Steve, I don't see any evidence that there is a recursive loop here, just the buffers stacking up, causing the overflow. Odd, though, this used to work. Not sure what else changed at that time besides the logging level; if I recall, it was part of a larger update. But given that we have a RAM fix coming, is it worth messing with this? Greg Stephen Casner wrote:

Greg,

Unless there is a bug causing infinite recursion or something, you may have sufficient free RAM to allow increasing the size of the stack for the task that is getting the stack overflow and achieve successful operation.

-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Ha, yes. Sorry. I bumped it up to 6144 (seems like a popular value), and that fixed it. So, two questions: 1. What should a proper value be? I used 6144 only because I'd seen it used elsewhere. 2. Shall I push this for permanence? Thanks, Greg Stephen Casner wrote:

Greg,

It sounds to me like you are conflating stack overflow with running out of heap space. You are not having a problem (yet) of running out of heap space, you have a stack size that is configured too small for your program's requirements. From what I saw in your earlier message, you need to change the creation of the Housekeeping task to specify a larger stack.

-- Steve

On Sun, 25 Feb 2018, Greg D. wrote:

...

Hi Steve,

I don't see any evidence that there is a recursive loop here, just the buffers stacking up, causing the overflow. Odd, though, this used to work. Not sure what else changed at that time besides the logging level; if I recall, it was part of a larger update.

But given that we have a RAM fix coming, is it worth messing with this?

Greg

Stephen Casner wrote:

...

Greg,

Unless there is a bug causing infinite recursion or something, you may have sufficient free RAM to allow increasing the size of the stack for the task that is getting the stack overflow and achieve successful operation.

-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

I second that, the normal stack usage for the Housekeeper is already quite close to 4K: Number of Tasks = 19       Stack:  Now   Max Total    Heap 32-bit SPIRAM Task 3FFD3718 14 Housekeeping      356  3396  4096   91940      0      0 So I also think 6K should be the default. Regards, Michael Am 26.02.2018 um 08:54 schrieb Stephen Casner:

Greg,

Presuming that you are not doing some activity in the Housekeeping task that should really be done in some other task, and presuming that the activity you are doing is not something unreasonable, then indeed you have found a valid need for a larger stack and the change should be committed. The value 6144 is a reasonable step up.

-- Steve

On Sun, 25 Feb 2018, Greg D. wrote:

...

Ha, yes. Sorry. I bumped it up to 6144 (seems like a popular value), and that fixed it.

So, two questions: 1. What should a proper value be? I used 6144 only because I'd seen it used elsewhere. 2. Shall I push this for permanence?

Thanks,

Greg

Stephen Casner wrote:

...

Greg,

It sounds to me like you are conflating stack overflow with running out of heap space. You are not having a problem (yet) of running out of heap space, you have a stack size that is configured too small for your program's requirements. From what I saw in your earlier message, you need to change the creation of the Housekeeping task to specify a larger stack.

-- Steve

On Sun, 25 Feb 2018, Greg D. wrote:

...

Hi Steve,

I don't see any evidence that there is a recursive loop here, just the buffers stacking up, causing the overflow. Odd, though, this used to work. Not sure what else changed at that time besides the logging level; if I recall, it was part of a larger update.

But given that we have a RAM fix coming, is it worth messing with this?

Greg

Stephen Casner wrote:

...

Greg,

Unless there is a bug causing infinite recursion or something, you may have sufficient free RAM to allow increasing the size of the stack for the task that is getting the stack overflow and achieve successful operation.

-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Merged. On Mon, 26 Feb 2018, Greg D. wrote:

Excellent. Change pushed to my fork; pull request created.

Thanks!

Greg

Michael Balzer wrote:

...

I second that, the normal stack usage for the Housekeeper is already quite close to 4K:

Number of Tasks = 19 Stack: Now Max Total Heap 32-bit SPIRAM Task 3FFD3718 14 Housekeeping 356 3396 4096 91940 0 0

So I also think 6K should be the default.

Regards, Michael

Am 26.02.2018 um 08:54 schrieb Stephen Casner:

...

Greg,

Presuming that you are not doing some activity in the Housekeeping task that should really be done in some other task, and presuming that the activity you are doing is not something unreasonable, then indeed you have found a valid need for a larger stack and the change should be committed. The value 6144 is a reasonable step up.

-- Steve

On Sun, 25 Feb 2018, Greg D. wrote:

...

Ha, yes. Sorry. I bumped it up to 6144 (seems like a popular value), and that fixed it.

So, two questions: 1. What should a proper value be? I used 6144 only because I'd seen it used elsewhere. 2. Shall I push this for permanence?

Thanks,

Greg

Time component is fully implemented now. It support stale timeouts, re-elections, maintaining SNTP, etc. Regards, Mark.

On 3 Mar 2018, at 8:42 PM, Michael Balzer <dexter@expeedo.de> wrote:

Greg,

I've just added ext12v and obd2ecu to the auto init system & web config.

So except for the metric set command, you should now be able to start your module without a script.

The autostart sequence is slightly different from yours, the obd2ecu init is done after the vehicle module init, as I see the vehicle module as the data provider for the obd2ecu module -- correct me if I'm wrong.

Can you please verify the start sequence is working as expected?

Regards, Michael

Am 25.02.2018 um 22:08 schrieb Greg D.:

...

Here's my system.start event file: OVMS > vfs cat /store/events/system.start/mystartup obdii ecu start can3 power ext12v on wifi mode client gregnet3 # power simcom on vehicle module TR server v2 start metric set v.b.soc 55 OVMS > (Before you ask, the setting of the soc metric is so that I can see the server is actually talking to the module, when the module's on the bench.)

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

For the ext12v auto, I suggest it would be best to control this from the CarOn metric (v.e.on). Turn on ext12v when the car is switched on, and turn it off when the car is switched off. Regards, Mark.

On 4 Mar 2018, at 11:47 AM, Greg D. <gregd2350@gmail.com> wrote:

Hi Michael,

Looks good!

The order for starting the obdii ecu task and the vehicle it draws data from isn't critical; nothing bad will happen if by some chance the OBDII device starts requesting information before the vehicle task makes it available. I suppose, the "most correct" sequence would start the vehicle task, then the obdii ecu task, then enable the ext12v power last, but in practice and by design there is no issue with starting any of them in pretty much any order. Worst case, the device it would get zeros if it wins the race, but I catch those internally and prevent the apparent lack of a running ICE engine from causing the device to shut down by supplying dummy information.

The only thing missing in the web server, I suppose, would be a way to customize the PID-to-Metric mapping. I supply a default for the most common ones, but there are many more possible if you are using, say, an ELM 327 dongle with Torque-like application. Changing the mapping is easily done through the shell (unless you want to tackle that with the web server too). 'config set obd2ecu.map <pid> <metric>' to set the mapping, and 'obdii ecu list' to display the mapping and current values.

Thanks for doing this!

Greg

Michael Balzer wrote:

...

Greg,

I've just added ext12v and obd2ecu to the auto init system & web config.

So except for the metric set command, you should now be able to start your module without a script.

The autostart sequence is slightly different from yours, the obd2ecu init is done after the vehicle module init, as I see the vehicle module as the data provider for the obd2ecu module -- correct me if I'm wrong.

Can you please verify the start sequence is working as expected?

Regards, Michael

Am 25.02.2018 um 22:08 schrieb Greg D.:

...

Here's my system.start event file: OVMS > vfs cat /store/events/system.start/mystartup obdii ecu start can3 power ext12v on wifi mode client gregnet3 # power simcom on vehicle module TR server v2 start metric set v.b.soc 55 OVMS > (Before you ask, the setting of the soc metric is so that I can see the server is actually talking to the module, when the module's on the bench.)

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

The auto init settings that Michael implemented are for when you plug the module in, so I'm thinking it would probably be good to turn the ext12v on so you can see the HUD device come alive. Key on then off would put the HUD to sleep with the scripts, completing the product installation checkout. This is what I had in my system.start script, which has been replaced by the auto init process.

The problem would be that would also happen if module was rebooted. I think it is fine if the ‘auto’ control only copes with the basic use cases. Anything more sophisticated, and it should be turned off and manual scripts used. Simplest ‘auto’ solution is to turn on and off, with the car. Regards, Mark

On 4 Mar 2018, at 1:11 PM, Greg D. <gregd2350@gmail.com> wrote:

Right. Forgot I have 1-line event scripts for vehicle.on and vehicle.off to do the runtime control of ext12v. This works very well with a HUD-type device, but not so much if you're driving the SyncUp Drive dongle (Wifi hotspot), as you would want it on when the car is awake but not on, e.g. while charging. I have not figured out a good algorithm for the dongle, as not all of the useful triggers appear to be connected. vehicle.asleep isn't for the Roadster, for example, so it never turns off. This means that there's no way to implement an automatic ext12v power control. The best solution may be hardware (electrical) instead of software, by driving the 12v into the OBDII connector from the 12v accessory port instead of from the OBMS module, as on the Roadster it's on whenever the car is awake (including charging). The OVMS module would remain powered from the diagnostic connector, which has 12v on continuously.

The auto init settings that Michael implemented are for when you plug the module in, so I'm thinking it would probably be good to turn the ext12v on so you can see the HUD device come alive. Key on then off would put the HUD to sleep with the scripts, completing the product installation checkout. This is what I had in my system.start script, which has been replaced by the auto init process.

Greg

Mark Webb-Johnson wrote:

...

For the ext12v auto, I suggest it would be best to control this from the CarOn metric (v.e.on). Turn on ext12v when the car is switched on, and turn it off when the car is switched off.

Regards, Mark.

...

On 4 Mar 2018, at 11:47 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:

Hi Michael,

Looks good!

The order for starting the obdii ecu task and the vehicle it draws data from isn't critical; nothing bad will happen if by some chance the OBDII device starts requesting information before the vehicle task makes it available. I suppose, the "most correct" sequence would start the vehicle task, then the obdii ecu task, then enable the ext12v power last, but in practice and by design there is no issue with starting any of them in pretty much any order. Worst case, the device it would get zeros if it wins the race, but I catch those internally and prevent the apparent lack of a running ICE engine from causing the device to shut down by supplying dummy information.

The only thing missing in the web server, I suppose, would be a way to customize the PID-to-Metric mapping. I supply a default for the most common ones, but there are many more possible if you are using, say, an ELM 327 dongle with Torque-like application. Changing the mapping is easily done through the shell (unless you want to tackle that with the web server too). 'config set obd2ecu.map <pid> <metric>' to set the mapping, and 'obdii ecu list' to display the mapping and current values.

Thanks for doing this!

Greg

Michael Balzer wrote:

...

Greg,

I've just added ext12v and obd2ecu to the auto init system & web config.

So except for the metric set command, you should now be able to start your module without a script.

The autostart sequence is slightly different from yours, the obd2ecu init is done after the vehicle module init, as I see the vehicle module as the data provider for the obd2ecu module -- correct me if I'm wrong.

Can you please verify the start sequence is working as expected?

Regards, Michael

Am 25.02.2018 um 22:08 schrieb Greg D.:

...

Here's my system.start event file: OVMS > vfs cat /store/events/system.start/mystartup obdii ecu start can3 power ext12v on wifi mode client gregnet3 # power simcom on vehicle module TR server v2 start metric set v.b.soc 55 OVMS > (Before you ask, the setting of the soc metric is so that I can see the server is actually talking to the module, when the module's on the bench.)

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Greg, thanks for testing & feedback. I'm working on the Twizy web UI now. If you'd like to implement the obd2ecu configuration, add it to the obd2ecu module. Have a look at the rt_web module for an example on how to extend the webserver from another module, it's really easy. For the PID mapping, I think a tabular form like for the Wifi config would be suitable. You can copy that form as a template, it's in the web_cfg module and consists of three methods: * HandleCfgWifi -- main handler & Javascript * OutputWifiTable -- table view * UpdateWifiTable -- table controller The Javascript for adding and deleting table rows can be used for any table form, you just need to change the row template. Regards, Michael Am 04.03.2018 um 04:47 schrieb Greg D.:

Hi Michael,

Looks good! 

The order for starting the obdii ecu task and the vehicle it draws data from isn't critical; nothing bad will happen if by some chance the OBDII device starts requesting information before the vehicle task makes it available.  I suppose, the "most correct" sequence would start the vehicle task, then the obdii ecu task, then enable the ext12v power last, but in practice and by design there is no issue with starting any of them in pretty much any order.  Worst case, the device it would get zeros if it wins the race, but I catch those internally and prevent the apparent lack of a running ICE engine from causing the device to shut down by supplying dummy information.

The only thing missing in the web server, I suppose, would be a way to customize the PID-to-Metric mapping.  I supply a default for the most common ones, but there are many more possible if you are using, say, an ELM 327 dongle with Torque-like application.  Changing the mapping is easily done through the shell (unless you want to tackle that with the web server too).  'config set obd2ecu.map <pid> <metric>' to set the mapping, and 'obdii ecu list' to display the mapping and current values.

Thanks for doing this!

Greg

Michael Balzer wrote:

...

Greg,

I've just added ext12v and obd2ecu to the auto init system & web config.

So except for the metric set command, you should now be able to start your module without a script.

The autostart sequence is slightly different from yours, the obd2ecu init is done after the vehicle module init, as I see the vehicle module as the data provider for the obd2ecu module -- correct me if I'm wrong.

Can you please verify the start sequence is working as expected?

Regards, Michael

Am 25.02.2018 um 22:08 schrieb Greg D.:

...

Here's my system.start event file:

OVMS > vfs cat /store/events/system.start/mystartup obdii ecu start can3 power ext12v on wifi mode client gregnet3 # power simcom on vehicle module TR server v2 start metric set v.b.soc 55 OVMS >

(Before you ask, the setting of the soc metric is so that I can see the server is actually talking to the module, when the module's on the bench.)

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Steve, yes, we definitely should include a charting lib, so we can do nice real time dashboards and statistics. I need to check some new projects first. I've been using Flot for business backends, but it's become very outdated now. New libs to check currently on my list: - http://www.chartjs.org/ - https://gionkunz.github.io/chartist-js/index.html - https://www.highcharts.com/ - https://www.fusioncharts.com/ Regards, Michael Am 04.03.2018 um 17:49 schrieb Stephen Casner:

Michael,

Is there a graphing package that would be feasible to include in our web server?

-- Steve

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Highcharts can be used free for non-commercial projects: https://www.highcharts.com/products/highcharts/#non-commercial …but is quite fat, as well as chart.js and FusionCharts. Chartist-js is my current preference. Gauges can be done otherwise, but they also don't need to be super fancy. Canvas Gauges needs 13 kB gzipped, which is quite a lot for just gauges. http://bernii.github.io/gauge.js/ would be my choice, that's just 4.8 kB gzipped. Maybe the gauge charts in chartist-js even are sufficient, with some extra lines of code to add a pointer, but another 4.8 kB wouldn't hurt too much given the just 10 kB of chartist. Regards, Michael Am 05.03.2018 um 03:19 schrieb Mark Webb-Johnson:

I use highcharts in my day job. Good, but expensive and not easily licensable for embedded. Open Source would also be a better fit.

I suspect that avoiding commercial charting libraries will limit our choice.

Maybe splitting the requirements into two would help (rather than trying to find one that does both):

1. Charts (bar, line, pie, etc)

http://www.chartjs.org/ https://gionkunz.github.io/chartist-js/index.html

2. Gauges

https://canvas-gauges.com/

I’m certainly looking for something similar for the App side.

Regards, Mark

...

On 5 Mar 2018, at 2:43 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

Steve,

yes, we definitely should include a charting lib, so we can do nice real time dashboards and statistics.

I need to check some new projects first. I've been using Flot for business backends, but it's become very outdated now.

New libs to check currently on my list:

- http://www.chartjs.org/ - https://gionkunz.github.io/chartist-js/index.html - https://www.highcharts.com/ - https://www.fusioncharts.com/

Regards, Michael

Am 04.03.2018 um 17:49 schrieb Stephen Casner:

...

Michael,

Is there a graphing package that would be feasible to include in our web server?

-- Steve

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

I've decided for Highcharts. My list of requirements was:   - Open source / free for non-commercial use   - SVG / CSS based   - Responsive & touch support   - Live updates with smooth transition   - Lightweight, no external dependancies   - Clean API   - optional: Gauges included Well, no surprise, none of the current candidates is a 100% match for these. I had to rule out Chartist.js very fast after beginning to fiddle about with it -- it's got no support for data update animations. It's been promised for a v2 rework about two years ago. The best match is Highcharts, the second best is amCharts. They are very close, and have quite similar concepts and API. Highcharts has won because it's got less weight, but amCharts remains an option, possibly with a custom compilation of charts. I've pushed the integration of the current Highcharts v6.0.7 including a live monitoring UI for the Twizy battery cells and a general gauge dashboard for all vehicles. The dashboard needs to be configured for the vehicle specs. I've added a simple vehicle callback OvmsVehicle::GetDashboardConfig() to set them as a JSON string, and a default configuration that should fit as a starting point for vehicles using 96s battery setups. I've done some first drives using the dashboard in my Twizy, it's a valuable addition. I'm going to add the drivemode buttons to it, so I've got my complete cockpit on that screen. We may add some more indicators, i.e. for charge times and alert conditions like tire pressure. Tell me what you'd like to have included on the dashboard. Regards, Michael Am 04.03.2018 um 19:43 schrieb Michael Balzer:

Steve,

yes, we definitely should include a charting lib, so we can do nice real time dashboards and statistics.

I need to check some new projects first. I've been using Flot for business backends, but it's become very outdated now.

New libs to check currently on my list:

- http://www.chartjs.org/ - https://gionkunz.github.io/chartist-js/index.html - https://www.highcharts.com/ - https://www.fusioncharts.com/

Regards, Michael

Am 04.03.2018 um 17:49 schrieb Stephen Casner:

...

Michael,

Is there a graphing package that would be feasible to include in our web server?

-- Steve

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Michael, You da man… Very cool. Particularly impressed with the animation on the gauges. This is exactly what I want for the App v3: Convert to a cross-platform environment (Android, iOS, desktops) Have various connection options to get metrics (server v2, server v3 (mqtt), bluetooth BLE GATT, etc) Have custom dashboards - tie a metric to a sizeable gauge at a place on a grid Make our standard screens work the same way User customisable Regarding the web dashboard, my main suggestion is to make it customisable. Allow multiple named dashboards that can be switched between, and allow the definition of metric tied to gauge type at a specific position. It can be grid based (I use 4 x 3 for work dashboards, with individual gauges able to be sized from 1x1 up to full screen 4x3 - but for this more fine-grained may be desirable). I can’t wait to get this in my car. Just need to get Model S support working properly. Regards, Mark.

On 4 Apr 2018, at 12:08 AM, Michael Balzer <dexter@expeedo.de> wrote:

I've decided for Highcharts. My list of requirements was:

- Open source / free for non-commercial use - SVG / CSS based - Responsive & touch support - Live updates with smooth transition - Lightweight, no external dependancies - Clean API - optional: Gauges included

Well, no surprise, none of the current candidates is a 100% match for these. I had to rule out Chartist.js very fast after beginning to fiddle about with it -- it's got no support for data update animations. It's been promised for a v2 rework about two years ago.

The best match is Highcharts, the second best is amCharts. They are very close, and have quite similar concepts and API. Highcharts has won because it's got less weight, but amCharts remains an option, possibly with a custom compilation of charts.

I've pushed the integration of the current Highcharts v6.0.7 including a live monitoring UI for the Twizy battery cells and a general gauge dashboard for all vehicles.

The dashboard needs to be configured for the vehicle specs. I've added a simple vehicle callback OvmsVehicle::GetDashboardConfig() to set them as a JSON string, and a default configuration that should fit as a starting point for vehicles using 96s battery setups.

I've done some first drives using the dashboard in my Twizy, it's a valuable addition. I'm going to add the drivemode buttons to it, so I've got my complete cockpit on that screen.

We may add some more indicators, i.e. for charge times and alert conditions like tire pressure. Tell me what you'd like to have included on the dashboard.

Regards, Michael

Am 04.03.2018 um 19:43 schrieb Michael Balzer:

...

Steve,

yes, we definitely should include a charting lib, so we can do nice real time dashboards and statistics.

I need to check some new projects first. I've been using Flot for business backends, but it's become very outdated now.

New libs to check currently on my list:

- http://www.chartjs.org/ - https://gionkunz.github.io/chartist-js/index.html - https://www.highcharts.com/ - https://www.fusioncharts.com/

Regards, Michael

Am 04.03.2018 um 17:49 schrieb Stephen Casner:

...

Michael,

Is there a graphing package that would be feasible to include in our web server?

-- Steve

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev