[Ovmsdev] OVMS Poller module/singleton
Michael Geddes
frog at bunyip.wheelycreek.net
Sat Jun 22 06:30:19 HKT 2024
Perfect. Thanks.
Michael
On Fri, 21 June 2024, 23:41 Michael Balzer via OvmsDev, <
ovmsdev at lists.openvehicles.com> wrote:
> Michael,
>
> "data" notifications correspond to the V2/MP "historical" message type:
>
> -
> https://docs.openvehicles.com/en/latest/protocol_v2/messages.html#historical-data-update-message-0x48-h
>
> So a record type of "*-LOG-Poll" would be OK, but I suggest using
> "*-LOG-PollStats" to be more precise.
>
> The record ID needs to be an integer, and the default V2 server database
> defines this to be a 32 bit signed integer. Note that sending a new record
> won't overwrite an existing one with the same ID, as the timestamp is part
> of the primary key. I suggest using your report line number.
>
> You can provide a header as line 0 then, or you can leave adding a header
> to the download tool (as do all the other data records up to now). If you
> use my server, you can download all data from the car UI, if you use
> another public server, you can still use my download tool via this page:
>
> - https://dexters-web.de/downloadtool?lang=EN
>
> Download tools other than the ones I provide in my web UI are the scripts
> in the server repository's client directory:
>
> -
> https://github.com/openvehicles/Open-Vehicle-Server/tree/master/clients
>
> The most simple form is shown by the "serverlog.sh" script, for adding
> headers see e.g. "rt_fetchlogs.sh". I normally let my server send me the
> logs by mail on a daily base, these include all historical data files with
> headers added.
> Assuming record type "*-LOG-PollStats", I've just added auto headers to
> my tool based on your template as follows:
>
> - type,count_hz,avg_util_pm,peak_util_pm,avg_time_ms,peak_time_ms
>
> (keeping the header style consistent with the other logs)
>
> So you can now simply send the data rows, the tool will prepend the header
> once on each download.
>
> Regards,
> Michael
>
>
> Am 19.06.24 um 11:10 schrieb Michael Geddes:
>
> Sure, I can do that.
> I did it this way because it was easier and could mostly do it in one
> message. As soon as I added spaces for alignment it pushed the message over
> 2 notifications. Also, I wasn't sure about making a new Data type and how
> that worked.
>
> I'm assuming something like: *-LOG-Poll would work (unless you want to
> suggest something else) The next 2 cols seem to be ID and lifetime.
> What do I use as an ID? Can it be an alpha string or does it have to be a
> number? (LIke using the first column descriptor). I'm not sure
> how the ID column is treated. I _could_ just send a line number for the
> dump group I guess?
>
> These are the columns I have. I can force the two cols to be always
> permille.
> "Type","Count (hz)","Avg utlization (permille)","Peak utlization
> (permille)", "Avg Time (ms)","Peak Time (ms)"
>
> Type is the only alpha column.. but if I can use that for the ID I guess
> that would be better?
>
> How would I provide a header if I wanted to? Is there some indicator
> saying it's a header line? I'm not sure I want to - just asking.
>
> //.ichael
>
> On Wed, 19 June 2024, 00:11 Michael Balzer via OvmsDev, <
> ovmsdev at lists.openvehicles.com> wrote:
>
>> Michael,
>>
>> I've received the new drive report notifications now; these need to be
>> changed: please do not use text notifications to transport CSV data. That's
>> what "data" notifications are meant for, which are stored in their raw form
>> on the server for later retrieval. See e.g. the vehicle trip & grid logs
>> for reference on how to build the messages, or have a look at the specific
>> Twizy and UpMiiGo data messages.
>>
>> Data notifications also are designed to transport one row at a time, so
>> you normally don't run into buffer size issues. A header can be supplied as
>> a row, but you normally add one when downloading the data from the server,
>> so tools don't need to filter these out. I provide headers automatically on
>> my server for known message types, just send me your template and I'll
>> include that.
>>
>> Apart from that, the timing statistics now seem to work pretty well,
>> providing valuable insights.
>>
>> Regards,
>> Michael
>>
>>
>>
>> Am 14.06.24 um 08:59 schrieb Michael Geddes:
>>
>> Thankyou.
>> I was more worried that we might be waiting on each other.
>>
>> I don't think I have quite the correct able to test on my friends Leaf
>> properly, or does it use the standard cable?
>>
>> Anyway, let me know what I can do to.
>>
>> //.ichael
>>
>> On Fri, 14 Jun 2024 at 14:46, Michael Balzer via OvmsDev <
>> ovmsdev at lists.openvehicles.com> wrote:
>>
>>> Sorry, I know I'm behind with PRs.
>>>
>>> I'll try to find some time this weekend.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 14.06.24 um 08:31 schrieb Michael Geddes via OvmsDev:
>>>
>>> Was this all good? I want to make sure I get to the bottom of this
>>> whole issue asap!
>>>
>>>
>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1018
>>>
>>> Was there something else you needed me to work on to make sure this all
>>> works for all supported cars?
>>>
>>> //.ichael
>>>
>>> On Sun, 26 May 2024 at 21:15, Michael Balzer via OvmsDev <
>>> ovmsdev at lists.openvehicles.com> wrote:
>>>
>>>> OK, I see now why it wouldn't send the notification: the V2 & V3 server
>>>> register for notifications up to COMMAND_RESULT_NORMAL = 1024 characters.
>>>>
>>>> The report quickly becomes larger than 1024 characters, so the
>>>> notifications no longer get sent via the server connectors.
>>>>
>>>> You need to either reduce the size, split the report, or use data
>>>> notifications instead.
>>>>
>>>> On the reset value init: for my float targeting smoothing helper class
>>>> for the UpMiiGo, I implemented a gradual ramp up from 1 to the requested
>>>> sample size. You can do something similar also with powers of 2. IOW, yes,
>>>> initialization from the first values received is perfectly OK.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 26.05.24 um 14:35 schrieb Michael Geddes:
>>>>
>>>> It _*should*_ already be sending a report on charge stop.
>>>>
>>>> MyEvents.RegisterEvent(TAG, "vehicle.charge.stop",
>>>> std::bind(&OvmsPollers::VehicleChargeStop, this, _1, _2));
>>>>
>>>> Reset on charge start/vehicle on is a good idea.
>>>>
>>>> A question – would it be silly if the first value after a reset, rather
>>>> than using 0 average to start with, if the average got set to the initial
>>>> value? I’m in 2 minds about it. It would make the average more useful
>>>> quicker.
>>>>
>>>> //.ichael
>>>>
>>>> On Sun, 26 May 2024, 19:39 Michael Balzer via OvmsDev, <
>>>> ovmsdev at lists.openvehicles.com> wrote:
>>>>
>>>> As the averages quickly decline when idle, an automatic report should
>>>> probably also be sent on charge stop.
>>>>
>>>> Also, I think you should automatically reset the timer statistics on
>>>> drive & charge start.
>>>>
>>>> First stats from charging my UpMiiGo:
>>>>
>>>> Type | count | Utlztn | Time
>>>> | per s | [‰] | [ms]
>>>> ---------------+--------+--------+---------
>>>> Poll:PRI Avg| 1.00| 0.723| 0.716
>>>> Peak| | 1.282| 3.822
>>>> ---------------+--------+--------+---------
>>>> Poll:SRX Avg| 7.72| 1.246| 0.184
>>>> Peak| | 3.128| 1.058
>>>> ---------------+--------+--------+---------
>>>> RxCan1[7ae] Avg| 2.48| 0.915| 0.362
>>>> Peak| | 1.217| 1.661
>>>> ---------------+--------+--------+---------
>>>> RxCan1[7cf] Avg| 4.76| 1.928| 0.397
>>>> Peak| | 2.317| 2.687
>>>> ---------------+--------+--------+---------
>>>> RxCan1[7ed] Avg| 3.38| 1.251| 0.327
>>>> Peak| | 8.154| 12.273
>>>> ---------------+--------+--------+---------
>>>> RxCan1[7ee] Avg| 0.21| 0.066| 0.297
>>>> Peak| | 0.225| 1.690
>>>> ---------------+--------+--------+---------
>>>> TxCan1[744] Avg| 1.49| 0.022| 0.011
>>>> Peak| | 0.032| 0.095
>>>> ---------------+--------+--------+---------
>>>> TxCan1[765] Avg| 3.89| 0.134| 0.027
>>>> Peak| | 0.155| 0.113
>>>> ---------------+--------+--------+---------
>>>> TxCan1[7e5] Avg| 2.32| 0.038| 0.013
>>>> Peak| | 0.295| 0.084
>>>> ---------------+--------+--------+---------
>>>> TxCan1[7e6] Avg| 1 0.21| 0.002| 0.008
>>>> Peak| | 0.010| 0.041
>>>> ---------------+--------+--------+---------
>>>> Cmd:State Avg| 0.00| 0.000| 0.007
>>>> Peak| | 0.005| 0.072
>>>> ===============+========+========+=========
>>>> Total Avg| 27.46| 6.324| 2.349
>>>>
>>>>
>>>> Overall healthy I'd say, but let's see how it compares.
>>>>
>>>> 7ed is the BMS, the peak time is probably related to the extended cell
>>>> data logging -- I've enabled log intervals for both cell voltages &
>>>> temperatures.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> Am 26.05.24 um 08:42 schrieb Michael Balzer via OvmsDev:
>>>>
>>>> The notification works on my devices, it only has a garbled per mille
>>>> character -- see attached screenshot. The same applies to the mail version:
>>>>
>>>>
>>>> Poller timing is: on
>>>>
>>>> Type | count | Utlztn | Time
>>>>
>>>> | per s | [‰] | [ms]
>>>>
>>>> ---------------+--------+--------+---------
>>>>
>>>> Poll:PRI Avg| 0.25| 0.119| 0.382
>>>>
>>>> Peak| | 0.513| 0.678
>>>>
>>>> ---------------+--------+--------+---------
>>>>
>>>> RxCan1[597] Avg| 0.01| 0.004| 0.021
>>>>
>>>> Peak| | 0.000| 0.338
>>>>
>>>> ---------------+--------+--------+---------
>>>>
>>>> RxCan1[59b] Avg| 0.01| 0.011| 0.053
>>>>
>>>> Peak| | 0.000| 0.848
>>>>
>>>> ---------------+--------+--------+---------
>>>>
>>>> Cmd:State Avg| 0.01| 0.002| 0.012
>>>>
>>>> Peak| | 0.000| 0.120
>>>>
>>>> ===============+========+========+=========
>>>>
>>>> Total Avg| 0.28| 0.135| 0.468
>>>>
>>>>
>>>> The encoding is a general issue. The character encoding for text
>>>> messages via V2/MP is quite old & clumsy, it's got an issue with the degree
>>>> celcius character as well. We previously tried to keep all text messages
>>>> within the SMS safe character set (which e.g. lead to writing just "C"
>>>> instead of "°C"). I'd say we should head towards UTF-8 now. If we ever
>>>> refit SMS support, we can recode on the fly.
>>>>
>>>> Regarding not seeing the notification on your phone:
>>>>
>>>> a) Check your notification subtype/channel filters on the module. See
>>>> https://docs.openvehicles.com/en/latest/userguide/notifications.html#suppress-notifications
>>>>
>>>> b) Check your notification vehicle filters on the phone (menu on
>>>> notification tab): if you enabled the vehicle filter, it will add the
>>>> messages of not currently selected vehicles to the list only, but not raise
>>>> a system notification. (Applies to the Android App, no idea about the iOS
>>>> version)
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> Am 26.05.24 um 06:32 schrieb Michael Geddes:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I'm trying to finalise this now .. and one last thing is that I don't
>>>> get the report coming to my mobile. I'm using the command:
>>>>
>>>> MyNotify.NotifyString("info", "poller.report", buf.c_str());
>>>>
>>>>
>>>>
>>>> Where the buffer string is just the same as the report output. Should
>>>> I be using some other format or command?
>>>>
>>>> I get "alert" types (like the ioniq5 door-open alert) fine to my mobile.
>>>>
>>>>
>>>>
>>>> Michael.
>>>>
>>>>
>>>>
>>>> On Sun, 19 May 2024, 12:51 Michael Balzer via OvmsDev, <
>>>> ovmsdev at lists.openvehicles.com> wrote:
>>>>
>>>> A builtin web UI for this seems a bit over the top. Builtin web config
>>>> pages should focus on user features, this is clearly a feature only needed
>>>> during/for the development/extension of a vehicle adapter. Development
>>>> features in the web UI are confusing for end users.
>>>>
>>>> If persistent enabling/disabling is done by a simple config command
>>>> (e.g. "config set can poller.trace on"), that's also doable by users.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> Am 19.05.24 um 02:06 schrieb Michael Geddes:
>>>>
>>>> I was so focused on how I calculated the value that I totally
>>>> missed that ‰ would be a better description. I could also use the system
>>>> 'Ratio' unit... so % or ‰.
>>>>
>>>>
>>>>
>>>> I'll make space to put 'Avg' on the row. Was trying to limit the width
>>>> for output on a mobile. I agree it would make it easier to understand.
>>>>
>>>> Totals also makes sense.
>>>>
>>>>
>>>>
>>>> Should I make this a configuration that can be set on the web-page?
>>>> I'd probably use a configuration change notification so that the very bit
>>>> setting is sync'd with the 'configuration' value.
>>>>
>>>>
>>>>
>>>> //.ichael
>>>>
>>>>
>>>>
>>>> On Sat, 18 May 2024, 14:05 Michael Balzer, <dexter at expeedo.de> wrote:
>>>>
>>>> I'm not sure whether the 'max' should be the maximum of the smoothed
>>>> value.. or the maximum of the raw value.
>>>>
>>>>
>>>> It should normally be the maximum of the raw value I think, the maximum
>>>> of the smoothed value cannot tell about how bad the processing of an ID can
>>>> become.
>>>>
>>>> The naming in the table is a bit confusing I think. (besides: I've
>>>> never seen "ave" as the abbreviation for average)
>>>>
>>>> If I understand you correctly, "time ms per s" is the time share in per
>>>> mille, so something in that direction would be more clear, and "length ms"
>>>> would then be "time [ms]".
>>>>
>>>> The totals for all averages in the table foot would also be nice.
>>>>
>>>> Maybe "Ave" (or avg?) also should be placed on the left, as the "peak"
>>>> label now suggests being the peak of the average.
>>>>
>>>> Btw, keep in mind, not all "edge" users / testers are developers (e.g.
>>>> the Twizy driver I'm in contact with), collecting stats feedback for
>>>> vehicles from testers should be straight forward. Maybe add a data/history
>>>> record, sent automatically on every drive/charge stop when the poller
>>>> tracing is on?
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> Am 18.05.24 um 02:28 schrieb Michael Geddes:
>>>>
>>>> You did say max/pead value. I also halved the N for both.
>>>>
>>>> I'm not sure whether the 'max' should be the maximum of the smoothed
>>>> value.. or the maximum of the raw value.
>>>>
>>>> This is currently the raw-value maximum.
>>>>
>>>> The problem is that the middle column is the maximum of the {{sum over
>>>> 10s} / (10*1000,000)
>>>>
>>>> I could easily change the 'period' to 1s and see how that goes.. was
>>>> just trying to reduce the larger calculations.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Usage: poller [pause|resume|status|times|trace]
>>>>
>>>>
>>>> OVMS# poller time status
>>>> Poller timing is: on
>>>> Type | Count | Ave time | Ave length
>>>> | per s | ms per s | ms
>>>> -------------+----------+-----------+-----------
>>>> Poll:PRI | 1.00| 0.559| 0.543
>>>> peak | | 0.663| 1.528
>>>> -------------+----------+-----------+-----------
>>>> Poll:SRX | 0.08| 0.009| 0.038
>>>> peak | | 0.068| 0.146
>>>> -------------+----------+-----------+-----------
>>>> CAN1 RX[778] | 0.11| 0.061| 0.280
>>>> peak | | 0.458| 1.046
>>>> -------------+----------+-----------+-----------
>>>> CAN1 RX[7a8] | 0.04| 0.024| 0.124
>>>> peak | | 0.160| 0.615
>>>> -------------+----------+-----------+-----------
>>>> CAN1 TX[770] | 0.05| 0.004| 0.016
>>>> peak | | 0.022| 0.102
>>>> -------------+----------+-----------+-----------
>>>> CAN1 TX[7a0] | 0.02| 0.002| 0.011
>>>> peak | | 0.010| 0.098
>>>> -------------+----------+-----------+-----------
>>>> CAN1 TX[7b3] | 0.01| 0.001| 0.006
>>>> peak | | 0.000| 0.099
>>>> -------------+----------+-----------+-----------
>>>> CAN1 TX[7e2] | 0.02| 0.002| 0.011
>>>> peak | | 0.010| 0.099
>>>> -------------+----------+-----------+-----------
>>>> CAN1 TX[7e4] | 0.08| 0.008| 0.048
>>>> peak | | 0.049| 0.107
>>>> -------------+----------+-----------+-----------
>>>> Cmd:State | 0.00| 0.000| 0.005
>>>> peak | | 0.000| 0.094
>>>>
>>>>
>>>>
>>>> On Fri, 17 May 2024 at 15:26, Michael Geddes <
>>>> frog at bunyip.wheelycreek.net> wrote:
>>>>
>>>> This is what I have now.
>>>>
>>>> The one on the end is the one MIchael B was after using an N of 32.
>>>> (up for discussion).
>>>>
>>>>
>>>>
>>>> The middle is the time spent in that even t per second. It
>>>> accumulates times (in microseconds), and then every 10s it stores it as
>>>> smoothed (N=16) value.
>>>>
>>>> The Count is similar (except that we store a value of '100' as 1 event
>>>> so it can be still integers and has 2 decimal places).
>>>>
>>>>
>>>>
>>>> Every received poll does a 64bit difference to 32bit (for the elapsed
>>>> time) and 64bit comparison (for end-of-period).
>>>>
>>>> It also does 1x 32bit smoothing and 2x 32bit adds.
>>>>
>>>>
>>>>
>>>> Then at the end of a 10s period, it will do a 64bit add to get the next
>>>> end-of-period value, as well as the 2x 32bit smoothing calcs.
>>>>
>>>>
>>>>
>>>> This is from the Ioniq 5 so not any big values yet. You can certainly
>>>> see how insignificant the TX callbacks are.
>>>>
>>>> I'll leave it on for when the car is moving and gets some faster
>>>> polling.
>>>>
>>>>
>>>>
>>>> OVMS# poll time status
>>>> Poller timing is: on
>>>> Type | Count | Ave time | Ave Length
>>>> | per s | ms per s | ms
>>>> -------------+----------+-----------+-----------
>>>> Poll:PRI | 1.00| 0.540| 0.539
>>>> Poll:SRX | 0.03| 0.004| 0.017
>>>> CAN1 RX[778] | 0.06| 0.042| 0.175
>>>> CAN1 TX[770] | 0.04| 0.002| 0.008
>>>> Cmd:State | 0.01| 0.001| 0.005
>>>>
>>>>
>>>>
>>>> ----------------------8<--------------------------------
>>>>
>>>>
>>>>
>>>> Nice smoothing class (forces N as a power of 2):
>>>>
>>>> constexpr unsigned floorlog2(unsigned x)
>>>> {
>>>> return x == 1 ? 0 : 1+floorlog2(x >> 1);
>>>> }
>>>> /* Maintain a smoothed average using shifts for division.
>>>> * T should be an integer type
>>>> * N needs to be a power of 2
>>>> */
>>>> template <typename T, unsigned N>
>>>> class average_util_t
>>>> {
>>>> private:
>>>> T m_ave;
>>>> public:
>>>> average_util_t() : m_ave(0) {}
>>>> static const uint8_t _BITS = floorlog2(N);
>>>> void add( T val)
>>>> {
>>>> static_assert(N == (1 << _BITS), "N must be a power of 2");
>>>> m_ave = (((N-1) * m_ave) + val) >> _BITS;
>>>> }
>>>> T get() { return m_ave; }
>>>> operator T() { return m_ave; }
>>>> };
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, 16 May 2024 at 10:29, Michael Geddes <
>>>> frog at bunyip.wheelycreek.net> wrote:
>>>>
>>>> Thanks Michael,
>>>>
>>>>
>>>>
>>>> My calculations give me ((2^32)-1) / (1000*1000*3600) = only 1.2 hours
>>>> of processing time in 32bit. The initial subtraction is 64bit anyway and I
>>>> can't see a further 64bit addition being a problem. I have the calculations
>>>> being performed in doubles at print-out where performance is not really an
>>>> issue anyway. (Though apparently doing 64 bit division is worse than
>>>> floating point).
>>>>
>>>>
>>>>
>>>> In addition
>>>>
>>>> * I currently have this being able to be turned on and off and reset
>>>> manually (only do it when required).
>>>>
>>>>
>>>>
>>>> * For the lower volume commands, the smoothed average is not going to
>>>> be useful - the count is more interesting for different reasons.
>>>>
>>>>
>>>>
>>>> * The total time is quite useful. Ie a high average time doesn't matter
>>>> if the count is low. The things that are affecting performance are stuff
>>>> with high total time. Stuff which is happening 100 times a second needs to
>>>> be a much lower average than once a second.
>>>>
>>>>
>>>>
>>>> * A measure like 'time per minute/second' and possibly count per
>>>> minute/seconds as a smoothed average would potentially be more useful. (or
>>>> in addition?)
>>>>
>>>> I think we could do _that_ in a reasonably efficient manner using a 64
>>>> bit 'last measured time', a 32 bit accumulated value and the stored 32 bit
>>>> rolling average.
>>>>
>>>> It would boils down to some iterative (integer) sums and
>>>> multiplications plus a divide by n ^ (time periods passed) - which is a
>>>> shift - and which can be optimised to '0' if 'time-periods-passed' is more
>>>> than 32/(bits-per-n) - effectively limiting the number of iterations.
>>>>
>>>> The one issue I can see is that we need to calculate 'number of
>>>> time-periods passed' which is a 64 bit subtraction followed by a 32 bit
>>>> division (not optimisable to a simple shift).
>>>>
>>>>
>>>>
>>>> * I'm also happy to keep a rolling (32bit) average time.
>>>>
>>>> Even if you assume averages in the 100ms, 32bit is going to happily
>>>> support an N of 64 or even 128.
>>>>
>>>> Am I right in thinking that the choice of N is highly dependent on
>>>> frequency. For things happening 100 times per second, you might want an N
>>>> like 128.. where things happening once per
>>>>
>>>> second, you might want an N of 4 or 8. The other things we keep
>>>> track of in this manner we have a better idea of the frequency of the thing.
>>>>
>>>>
>>>>
>>>> How about we have (per record type):
>>>>
>>>> * total count (since last reset?) (32 bit)
>>>>
>>>> * smoothed average of time per instance (32 bit)
>>>>
>>>>
>>>>
>>>> * ?xx? total accumulated time since last reset (64bit) ?? <-- with
>>>> the below stats this is much less useful
>>>>
>>>>
>>>>
>>>> * last-measured-time (64 bit)
>>>>
>>>> * accumulated count since last time-period (16bit - but maybe 32bit
>>>> anyway for byte alignment?)
>>>>
>>>> * smoothed average of count per time-period (32bit)
>>>>
>>>> * accumulated time since last time-period (32bit)
>>>>
>>>> * smoothed average of time per time-period (32bit)
>>>>
>>>>
>>>>
>>>> It's possible to keep the
>>>>
>>>>
>>>>
>>>> Is this going to be too much per record type? The number of 'records'
>>>> we are keeping is quite low (so 10 to 20 maybe) - so it's not a huge memory
>>>> burden.
>>>>
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>> //.ichael
>>>>
>>>> On Thu, 16 May 2024 at 03:09, Michael Balzer via OvmsDev <
>>>> ovmsdev at lists.openvehicles.com> wrote:
>>>>
>>>> esp_timer_get_time() is the right choice for precision timing.
>>>>
>>>> I'd say uint32 is enough though, even if counting microseconds that can
>>>> hold a total of more than 71 hours of actual processing time. uint64 has a
>>>> significant performance penalty, although I don't recall the overhead for
>>>> simple additions.
>>>>
>>>> Also & more important, the average wouldn't be my main focus, but the
>>>> maximum processing time seen per ID, which
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240622/1e2602f1/attachment-0001.htm>
More information about the OvmsDev
mailing list