OvmsDev
Threads by month
- ----- 2026 -----
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
June 2024
- 5 participants
- 4 discussions
Michael,
(taking this back to the list, as other developers may have helpful
ideas or suggestions)
from a first check, your new patch (PR #1008) won't help for vehicles
that don't use the poller, like the generic DBC vehicle or the Fiat 500
(plus possibly non-public third party vehicles). As the poller is
normally compiled in, these would need a run time switch to re-enable
the vehicle task, or more suitably default into that configuration and
switch to the poller task only when the poller gets initialized.
How about moving the task back into the vehicle class, but keeping your
task message extensions while doing so, and adding a way for the poller
to hook into the task? The dedicated vehicle task is an essential part
of the vehicle framework, but I do remember some occasions where a
general way to pass custom messages to the vehicle task would have been
helpful to use the task for more than CAN processing.
If the poller shall become avaible as a separate service that can be
used without any vehicle instance (currently not a defined use case),
the construct of a CAN processor task that can be extended for custom
messages (or a message processor task that can subscribe to CAN frames)
could be factored out into a dedicated class or template. The poller
could then create his own instance of that class, if it cannot hook into
an existing one.
Btw, in case you're not aware of this, FreeRTOS also provides queue sets
(https://www.freertos.org/RTOS-queue-sets.html) We haven't used them in
the OVMS yet, but they could be useful, especially if message unions
become large or tasks shall be able to dynamically subscribe to
different message sources.
Regards,
Michael
Am 30.04.24 um 01:20 schrieb Michael Geddes:
> It might be worth reverting, but, I've got a patch suggestion that
> I'll push up which will let me know if I understand everything and
> which might provide a solution.
>
> If this isn't going to work then revert. (P/R coming)
>
> While the poller was still a part of the vehicle class it was probably
> still all ok. The poller had taken over what I assume you are
> talking about as the vehicle task. A call-back fromthe poller was
> calling IncomingPollRxFrame which was then coming from the (now)
> poller task (is that correct?)
>
> While we have OVMS_COMP_POLLER config defined, we could just use the
> poller task to provide the IncomingPollRxFrame call-back from the
> poller (was vehicle?) task.
>
> The problem is when OVMS_COMP_POLLER is undefined, we need an
> alternate (maybe we could use the 'Event' loop then) which is when I
> hacked that bad solution.
>
>
> //.ichael
>
>
> I was thinking though that because everything is being queued we could
> divert some calls into the car
>
> On Mon, 29 Apr 2024, 18:58 Michael Balzer, <dexter(a)expeedo.de> wrote:
>
> Michael,
>
> I've found a severe design flaw with your poller change. Sorry, I
> should have seen that before, and shouldn't have merged this.
>
> You have moved the standard CAN frame processing from the vehicle
> task into the CAN task by changing the vehicle from a CAN listener
> to a CAN callback processor. That will break all kind of things,
> vehicles like the Twizy, Smart and many others rely on frame
> processing being done in the dedicated vehicle task.
>
> This especially induces issues regarding CAN processing capacity,
> as the vehicles rely on having a separate context and not needing
> to decouple complex processing of incoming frames. So this will
> degrade the CAN processing performance seriously in many cases,
> where additional steps involving file or network I/O need to be done.
>
> So this needs to be changed back.
>
> I assumed you introduced a new dedicated poller task but kept the
> vehicle task intact. From your naming
> (OvmsVehicle::IncomingPollRxFrame), it seems you misinterpreted
> the vehicle task's purpose as only being used for polling.
>
> I assume this isn't a small change…? If so we should revert the
> poller merge, to avoid having a defunctional edge build state
> until the fix.
>
>
> Secondly: logging is generally expensive regardless of the log
> level control and log channels enabled. Any log message needs to
> be queued to the log system, so involves a lock and a potential
> wait state (for the queue) & resulting context switch (= minimum
> delay of 10 ms). Therefore, logging must be avoided as far as
> possible in any time critical context, and is forbidden under some
> circumstances, e.g. in a timer callback (see FreeRTOS docs on
> this). The log system load multiplies with connected web clients
> or enabled file logging and enabled debug / verbose level logging
> -- that quickly becomes too much, usually triggering the task
> watchdog.
>
> Your logging of nearly all bus events passing to/from the poller
> (especially the log entry in Queue_PollerFrame) becomes an issue
> on any vehicle that has high frequency running process data frames
> on the bus, like the Twizy or Smart. As a counter measure, I've
> just added a runtime control for all the poller's verbose logging
> (by default now off), and changed some debug level logs to
> verbose. Not sure if I've catched all that may need to be silenced
> by default. Please check all your log calls and place them under
> the new "trace" control flag wherever appropriate.
>
> This won't help avoiding issues with process data frame buses though.
>
>
> Shall I revert the poller merge for now?
>
> Regards,
> Michael
>
>
>
> Am 29.04.24 um 06:18 schrieb Michael Geddes:
>> Btw I included the log changes in the p/r which is a few small
>> commits for the poller.
>>
>> //.
>>
>> On Mon, 29 Apr 2024, 07:20 Michael Geddes,
>> <frog(a)bunyip.wheelycreek.net> wrote:
>>
>> Hey Michael,
>> I've got to work now (it's Monday), but I suspect those
>> 'giving up' are from unsolicited messages on the bus.
>> I can re-order things so that the message will likely be
>> 'dropped (no poll entry)' rather than the time-out message.
>> And make it a verbose log.
>>
>> //.ichael
>>
>> On Mon, 29 Apr 2024 at 00:25, Michael Balzer
>> <dexter(a)expeedo.de> wrote:
>>
>> Michael,
>>
>> forwarding the Twizy logs to you directly, as they
>> contain the user location.
>>
>> He has just verified it's the new version, he says the
>> module stops responding as soon as he turns on the Twizy.
>>
>> His description of his actions is a bit ambiguous, and it
>> seems he didn't enable logging to the file persistently.
>>
>> According to the server, these were the version boot times:
>>
>> 2024-04-28 15:30:56 0 3.3.004-32-g125e0841/ota_0/edge
>> (build idf v3.3.4-849-g6e214dc335 Apr 26 2024 19:16:50)
>> 2024-04-28 16:21:08 0 3.3.004-32-g125e0841/ota_0/edge
>> (build idf v3.3.4-849-g6e214dc335 Apr 26 2024 19:16:50)
>> 2024-04-28 16:38:33 0 3.3.004-63-gf3595561/ota_1/edge
>> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50)
>> 2024-04-28 16:40:57 0 3.3.004-63-gf3595561/ota_1/edge
>> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50)
>> 2024-04-28 16:43:14 0 3.3.004-63-gf3595561/ota_1/edge
>> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50)
>> 2024-04-28 16:46:39 0 3.3.004-63-gf3595561/ota_1/edge
>> (build idf v3.3.4-849-g6e214dc335 Apr 27 2024 07:44:50)
>> 2024-04-28 16:54:44 0 3.3.004-32-g125e0841/ota_0/edge
>> (build idf v3.3.4-849-g6e214dc335 Apr 26 2024 19:16:50)
>>
>> Attached is also his crash debug log -- a2ll doesn't tell
>> much about what happened, but maybe you get an idea from
>> this.
>>
>> After the boot at 16:46, there are immediately lots of
>> these messages:
>>
>> 2024-04-28 16:46:33.792 CEST D (39042) vehicle-poll:
>> Poller: Queue PollerFrame()
>> 2024-04-28 16:46:33.792 CEST D (39042) vehicle-poll:
>> [1]Poller: Incoming - giving up
>>
>> Regards,
>> Michael
>>
>>
>> Am 28.04.24 um 16:44 schrieb Michael Geddes:
>>> Ah. OK.
>>>
>>> I could try to fix the vin thing using the new way of
>>> doing it and get rid of a semaphore?
>>> It would at least identify the problem possibly?
>>>
>>> Michael
>>>
>>>
>>> On Sun, 28 Apr 2024, 22:32 Michael Balzer via OvmsDev,
>>> <ovmsdev(a)lists.openvehicles.com> wrote:
>>>
>>> Not sure if that's the problem, but I've found a
>>> different behaviour with the new PollSetState()
>>> implementation.
>>>
>>> The old version only did anything if the new state
>>> actually was different from the previous one. The
>>> Twizy relies on this behaviour, calling
>>> PollSetState() from the per second ticker (see
>>> OvmsVehicleRenaultTwizy::ObdTicker1).
>>>
>>> The new implementation apparently always sends the
>>> PollState command to the task, and that in turn
>>> always at least locks the poller mutex. Not sure
>>> if/how that could cause the observed issues, but it
>>> definitely adds quite some (unnecessary?)
>>> lock/unlock operations.
>>>
>>>
>>>
>>> Am 28.04.24 um 16:05 schrieb Michael Balzer via OvmsDev:
>>>> The Twizy uses the poller to query the VIN (once)
>>>> and DTCs (every 10 seconds while driving), see
>>>> rt_obd2.cpp.
>>>>
>>>> It also has its own version of the OBD single
>>>> request (OvmsVehicleRenaultTwizy::ObdRequest),
>>>> which was the precursor for the generalized
>>>> version. This is used by custom/user Twizy plugins
>>>> and scripts to access ECU internals.
>>>>
>>>> The Twizy doesn't use IncomingPollRxFrame, but the
>>>> Twizy's IncomingPollReply handler will log any poll
>>>> responses it doesn't know about, so that could lead
>>>> to a lot of log output if something goes wrong there.
>>>>
>>>>
>>>> Am 28.04.24 um 15:49 schrieb Michael Geddes via
>>>> OvmsDev:
>>>>> AFAICT the twizzy doesn't use the poller list at
>>>>> all. So is it missing a call-back or something??
>>>>>
>>>>> I can see a potential problem with
>>>>> IncomingPollRxFrame being called twice as much as
>>>>> it should be but only when there is a poll list.
>>>>> Maybe commenting out this would do it. (I can
>>>>> find another away to get this called on the thread
>>>>> I want). This might be the problem with the smarted
>>>>>
>>>>> void
>>>>> OvmsVehicle::OvmsVehicleSignal::IncomingPollRxFrame(canbus*
>>>>> bus, CAN_frame_t *frame, bool success)
>>>>> {
>>>>> //if (Ready())
>>>>> // m_parent->IncomingPollRxFrame(frame, success);
>>>>> }
>>>>>
>>>>> //.
>>>>>
>>>>>
>>>>> On Sun, 28 Apr 2024 at 21:10, Michael Balzer via
>>>>> OvmsDev <ovmsdev(a)lists.openvehicles.com> wrote:
>>>>>
>>>>> There may also be an issue with the Renault
>>>>> Twizy, I've received a report of a user who is
>>>>> using the edge builds, that the latest build
>>>>> wouldn't work.
>>>>>
>>>>> He reports all kinds of errors and warnings
>>>>> signaled by the car during driving, and
>>>>> switching back to the previous build fixed the
>>>>> issues.
>>>>>
>>>>> I've asked him to provide a debug log excerpt
>>>>> if possible.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 28.04.24 um 14:29 schrieb Michael Geddes
>>>>> via OvmsDev:
>>>>>> OK. That's bad.
>>>>>>
>>>>>> Does the reading work in general?
>>>>>>
>>>>>> Is it just the writing commands?
>>>>>>
>>>>>> Raise a ticket on github and tag me in and we
>>>>>> can address it that way.
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>> On Sun, 28 Apr 2024, 19:49 Thomas Heuer via
>>>>>> OvmsDev, <ovmsdev(a)lists.openvehicles.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The new poller code doesn't seem to work
>>>>>> properly with the smarted.
>>>>>>
>>>>>> D (218831) vehicle-poll:
>>>>>> [1]PollerNextTick(PRI): cycle complete
>>>>>> for ticker=215
>>>>>>
>>>>>> V (218831) vehicle-poll: Standard Poll
>>>>>> Series: List reset
>>>>>>
>>>>>> D (218831) vehicle-poll:
>>>>>> PollSeriesList::NextPollEntry[!v.standard]:
>>>>>> ReachedEnd
>>>>>>
>>>>>> V (218831) vehicle-poll: [1]PollerSend:
>>>>>> Poller Reached End
>>>>>>
>>>>>> D (219691) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> D (219691) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219691) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219691) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219691) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> V (219691) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219691) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> *OVMS#*unlock 22
>>>>>> Vehicle unlocked
>>>>>>
>>>>>> V (219691) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219691) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219691) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> V (219701) vehicle-poll: Pollers:
>>>>>> FrameRx(bus=2)
>>>>>>
>>>>>> D (219701) vehicle-poll: Poller: Queue
>>>>>> PollerFrame()
>>>>>>
>>>>>> *Von:*OvmsDev
>>>>>> <ovmsdev-bounces(a)lists.openvehicles.com>
>>>>>> *Im Auftrag von *Michael Geddes via OvmsDev
>>>>>> *Gesendet:* Sonntag, 28. April 2024 12:27
>>>>>> *An:* OVMS Developers
>>>>>> <ovmsdev(a)lists.openvehicles.com>
>>>>>> *Cc:* Michael Geddes
>>>>>> <frog(a)bunyip.wheelycreek.net>
>>>>>> *Betreff:* [Ovmsdev] OVMS Poller
>>>>>> module/singleton
>>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> The poller singleton code that I've been
>>>>>> working on for over a year now is merged
>>>>>> in. (Thanks Michael for expediting the
>>>>>> final step).
>>>>>>
>>>>>> This includes separate multi-frame states
>>>>>> per bus and multiple poll lists as well
>>>>>> as non-blocking one off queries. As well
>>>>>> as more 'states'.
>>>>>>
>>>>>> I have included some programming
>>>>>> documentation in the change but am happy
>>>>>> to supply more if needed.
>>>>>>
>>>>>> The ioniq 5 code has some examples of how
>>>>>> it can be used. Some examples are:
>>>>>>
>>>>>> * grabbing the vin as a one shot without
>>>>>> blocking
>>>>>>
>>>>>> * having a short list of queries that are
>>>>>> polled quickly for obd2ecu (this also
>>>>>> demonstrates using a shorter frame break
>>>>>> value and then a break after successful a
>>>>>> response)
>>>>>>
>>>>>> Have a play please!
>>>>>>
>>>>>> Also interested in hearing what user
>>>>>> tools might be worth looking at next for
>>>>>> the poller object.
>>>>>>
>>>>>> //.ichael G.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>
>>>>> _______________________________________________
>>>>> 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 * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev(a)lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev(a)lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
7
117
There's an unused variable 'dcc' warning in the below code.
It seems that the 'Perform the callback' is not being 'performed!
Is this deliberate?
//.ichael
void DukOvmsCommandRegisterRun(int verbosity, OvmsWriter* writer,
OvmsCommand* cmd, int argc, const char* const* argv)
{
ESP_LOGD(TAG, "DukOvmsCommandRegisterRun(%s)",cmd->GetName());
auto it = MyDuktape.m_cmdmap.find(cmd);
if (it == MyDuktape.m_cmdmap.end())
{
ESP_LOGE(TAG, "Command '%s' cannot be found in registry",cmd->GetName
());
return;
}
else
{
DuktapeConsoleCommand* dcc = it->second;
// Perform the callback
}
}
3
6
Everyone,
I've just tagged version 3.3.004 and released the build to EAP on
ovms.dexters-web.de -- Mark, please follow up. As usual, we will release
this to MAIN in about a week.
This release has been long overdue, it includes numerous new features,
new vehicles and of course lots of bug fixes.
A huge thank you to everyone involved in this collaborative effort!
Changes since 3.3.003:
- MG EV Added support for MG5 (2020 - 2023) Short Range
- MG EV Added support for MG ZS EV (2023 - ) and MG5 (2020 - 2023) Long
Range
- OVMS Server v3 metrics filtering
New configs:
[server.v3] metrics.include -- Comma-separated list of
metric names (with possible wildcard) matching metrics to send
[server.v3] metrics.exclude -- Comma-separated list of
metric names (with possible wildcard) matching metrics to not send
- Renault Zoe Phase 2: Initial support
- Improved output of bms shell command for narrow windows.
New commands:
bms volt -- Output only voltage info if
available
bms temp -- Output only temperature info
if available
- Hyundai Ioniq 5: Initial support
- Support for specifying units in scripts
New commands:
metrics units -- Display available unit
identifiers
metrics get -- Get at a particular metric
value (with a specified unit)
Extended commands:
metrics set -- Support setting with a
specified unit
Extend functions
OvmsMetrics.Value -- Optionally specify a unit
(and make 'decode' work) and to get values with units.
OvmsMetrics.GetValues -- Optionally specify a unit to
get values with units.
OvmsMetrics.AsFloat -- Optionally specify a unit
New DukTape function
OvmsMetrics.HasValue -- Returns true if the metric
has a valid value.
- Added power consumptions units: kWhP100K,KPkWh,MPkWh
- Consolidate custom trip power consumption metrics to single value
(kWhP100K)
in Kia Niro and Kia Soul
- VFS: sorted directory listings & recursive directory listings
New commands:
vfs rls <path> -- List <path> and all
subdirectory contents
- Vehicle: emit standard events on charge/generator connection type changes
New events:
vehicle.charge.type -- Vehicle charge connection
type has changed (e.g. ccs/type2/…)
vehicle.gen.type -- Vehicle generator connection
type has changed
- CAN logging: add possibility to log events (name) and metrics (JSON
object with name, value, unit)
New configs:
[can] log.events_filters -- comma-separated list of
filters (with possible wildcard) matching an event name
[can] log.metrics_filters -- comma-separated list of
filters (with possible wildcard) matching a metric name
- Add units Bar, Permille
- Add user configuration for groups of metrics
Adds the 'ToUser' unit that converts to the user specified unit.
Add -u to 'metrics list' to view metrics as user units.
- Add completion for metrics set/get as well as units
- Mini Cooper SE: Initial support
- Hyundai Ioniq vFL: trip metrics, range estimations, TPMS, web
configuration,
charge type detection, charge speed & time estimation
New configs:
[xhi] ctp.maxpower -- Default charge power limit
[kW] for charge time estimations, default 0 = unlimited
[xhi] ctp.soclimit -- SOC level [%] for secondary
charge time estimation (sufficient SOC), default 80
[xhi] notify.charge.delay.ccs -- Wait time [sec] for DC charge
power to ramp up before sending the notification, default 15
[xhi] notify.charge.delay.type2 -- … same for AC charging, default 3
[xhi] range.ideal -- ideal new car range [km],
default 200
[xhi] range.user -- typical current user range
[km], default 200
[xhi] range.smoothing -- Number of SOC samples, default
10 = ~ 5% SOC
[xhi] tpms.pressure.warn -- default 230 [kPa]
[xhi] tpms.pressure.alert -- default 220 [kPa]
[xhi] tpms.temp.warn -- default 90 [°C]
[xhi] tpms.temp.alert -- default 100 [°C]
New metrics:
xhi.b.range.user -- actual current user range [km]
xhi.e.state -- General/ignition state flags
- Module: support deep sleep schedules
New commands:
module sleep -- Shutdown all components and
enter deep sleep for a time span or until a specific time.
- Add support for user-configured metrics in the web interface and plugins:
Adds an extra 'units' stream from the websocket containing sub-streams:
- metrics (for the current user unit/label for each metric)
(subscribe to units/metrics)
- prefs (for any user preferences for unit groups/types)
(subscribe to units/prefs)
Adds proxy arrays metrics_user[] , metrics_label[] available to
plugin pages.
Adds various browser javascript functions and methods for plugins
related
to displaying user configurations Auto-converts metric display to user
units in plugins that use attributes
- Cellular: add GPS/GNSS state control commands (for power management)
New commands:
cellular gps [status] -- output current modem GPS/GNSS
subsystem status
cellular gps start -- start modem GPS/GNSS subsystem
cellular gps stop -- stop modem GPS/GNSS subsystem
- CAN framework: add bus reset command
New commands:
can [can1…4] reset -- reset the CAN interface
- Vehicle: add support for custom command handlers, see…
https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsvehicl…
- Renault Twizy: read battery energy available from BMS (thanks to
Martin Bitz)
New metrics:
xrt.b.energy.avail -- Current battery energy
available [kWh] (aged)
xrt.b.energy.full -- Maximum battery energy
capacity [kWh] (aged, needs full charge)
- Add button on web file editor to reload obd2ECU (when obd2ECU is enabled).
- Vehicle: add support for a geofence for valet mode similar to
parking/flatbed warnings.
New Configs:
[vehicle] valet.alarmdistance -- How far away from the original
position before raising an alert (in metres)
[vehicle] valet.alarminterval -- How often the alarm can be
raised in minumtes
- Add metric and events related to obd2ecu process:
New metric:
m.obdc2ecu.on -- Is the OBD2ECU process
currently on.
New events:
obd2ecu.start -- Called after the OBD2ECU
process is started.
obd2ecu.stop -- Called before the OBD2ECU
process is stopped.
- Web UI: Add configuration for Valet and Flatbed geofence to the
Locations config page.
- Network: New 'network ping' command to ping (ICMP) hostname or IP
address. (ESP-IDFv4+ only / needs to be enabled in menuconfig -
Developer Options)
- Vehicle: add automatic module shutdown/reboot based on 12V battery
voltage level
New configs:
[vehicle] 12v.shutdown -- Shutdown voltage level
(default: disabled)
[vehicle] 12v.wakeup -- Reboot minimum voltage level
after shutdown (default: any)
[vehicle] 12v.wakeup_interval -- Reboot test interval in
seconds (default: 60)
New events:
vehicle.alert.12v.shutdown -- 12V shutdown threshold
reached, entering deep sleep
- BYD Atto 3 initial support
- Vehicle: add 12V shutdown delay & notification
New configs:
[vehicle] 12v.shutdown_delay -- Shutdown delay in minutes
(default: 2)
New events:
vehicle.alert.12v.low -- 12V shutdown voltage level
detected
vehicle.alert.12v.operational -- 12V recovered above shutdown level
New notifications:
[alert] batt.12v.shutdown -- Alert about imminent 12V shutdown
- VFS toolkit: add recursive options to mkdir (-p) & rmdir (-r) commands
- Renault-Zoe-Ph1: add Cabin Pre-heat/cool Control
Regards,
Michael
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
5
15
I'm really not sure if this would make enough difference to be useful - but
it's kinda neat.
It's basically a template class that turns y = m * x / d into y = (c *
x) >> n
eg: fast_int_muldiv<int, 10, 3>::op( x )
it is an approximation only, and the larger PREC value you give, the more
precise it is, and the larger integer it would need. So a decent precision
would probably need a 64 bit integer.
I would need to do experiments on the ESP32 to really get an idea. One
thing it does do is turn a multiply and divide (like for imperial units)
into 2 operations.
//.
constexpr unsigned floorlog2(unsigned x)
{
return x == 1 ? 0 : 1+floorlog2(x >> 1);
}
constexpr unsigned ceillog2(unsigned x)
{
return x == 1 ? 0 : floorlog2(x - 1) + 1;
}
/* Use a multiple and shift (right) to approximate a multiply and divide.
* T - the intermediate type used.
* M - The multiplier (1 is fine)
* D - The divisor
* PREC - The precision required for the operation.
*/
template<typename T, unsigned M, unsigned D, unsigned PREC=100>
class fast_int_muldiv
{
public:
static const uint8_t shift = ceillog2(D * PREC);
// Gives the approx multiplier that fits with the chosen shift value .
static const T mult = M* (((T(0x1) << shift)+(D>>1)) / D);
// Perform the operation approx (val * M / D)
static T op(T val)
{
// Make sure there is enough space (16bits) for a value.
static_assert( (8 * sizeof(T)) >= (16 + shift + floorlog2(mult)),
"Use a larger integer or smaller precision");
return ((val * mult) >> shift);
}
};
3
2