Am 13.05.2018 um 03:43 schrieb Mark Webb-Johnson:
What I’m trying to do is create a generic algorithm that works for
as many vehicles as possible. If a particular vehicle needs
particular support, it can override and handle itself
appropriately.
I’ve delayed the charge start report for all those
pre-states (including charging, topoff, heating). I’m guessing
that when heating (for example) transitions to charging, the
current level should be fine and we can report immediately. For
Tesla roadster it goes heating->preparing->charging.
So the current implementation will also only notify on i.e. heating
but not on the transition from heating to charging, because the
charge time counter starts on heating. That may be sufficient, but
users may want to also or only get a notification on the actual
charge start. Heating may take quite some time in very cold climate.
The base problem seems to result from a lack of a common definition
/ consent on the meaning of the states. I always understood and used
"topoff" not as a pre-state but as a finishing state. My definition
would look like this:
- charging: main charge phase (constant current phase, full
speed)
- topoff: finishing charge phase (constant voltage phase, cell
balancing)
- done: standard completion of a full charge
- prepare: any kind of preparation phase
- timerwait: waiting for a timer based charge start
- heating: heating up cells before charge in cold climate
- stopped: any kind of charge stop before the standard
completion ("done")
A normal charge process is: [timerwait →] [heating →] [prepare →]
charging → [topoff →] done
…with [] being optional states. The charge process can start at any
state, i.e. if the battery is warm and nearly full, it would start
at topoff.
You normally want to get a notification on "topoff" entry if you're
on the road and want to go on as quickly as possible.
That's the process for the Twizy. The Twizy doesn't have a prepare
phase (it has technically but it's too short to bother), charge
voltage and current are stable on the bus when the charge start is
signaled.
On the Tesla Roadster, if the current is not stable during the first
15 seconds, it would seem to be a natural mapping to set that phase
as state "prepare". But I remember the phases are taken directly
from the bus on the roadster implementation.
For a general base solution, your approach of a delayed notification
would work if we didn't use ms_v_charge_time as a base but a
separate charge phase time that is reset on each phase change.
The phase delay then can be applied to all state change
notifications, and the delay can be configurable / controllable by
the vehicle, possibly varying per state (callback hook).
As that makes the process very flexible and even supports the old
scheme (by returning 0 as a delay) I've just implemented that,
please check and comment.
I've set the default delay to 3 seconds, that should be sufficient
for all vehicles with direct bus→state mappings.
Regards,
Michael
What does the current approach look like on the
Twizy?
Regards, Mark.
Mark,
Am 12.05.2018 um 15:51
schrieb Mark Webb-Johnson:
A
minor issue: binding the actual notification to
a single metric introduces a dependance on the
CAN frame or processing order if the
notification content depends on other metrics as
well.
Yep. Found one of those today.
Tesla Roadster: charge started
notifications didn’t show current properly, because
that takes a few seconds to appear. Fix made was to
delay charge start notifications until 15 seconds
into the charge.
I just saw you made that change for all vehicles instead
of only for the roadster. I'm really not sure about
that, it feels like a workaround.
Your change also breaks the notifications on state
transitions during the charge. The "topoff" phase on the
Twizy is equivalent to the CV (constant voltage) charge
phase, so "charging" goes over to "topoff" at some
indeterminate time into the charge.
I don't know how "heating" works on the Roadster, but
"heating" would normally also seemlessly proceed to
"charging".
Regards,
Michael
In general, I’m finding our ‘time’
metrics really useful. We have charge time
(v.c.time), and park time (v.e.parktime). Probably a
good to add v.e.drivetime to complement those and
track how long the vehicle has been not parked.
Regards, Mark.
Mark,
I'll take care of the web UI for the
notification config, but not for 006.
A minor issue: binding the actual
notification to a single metric introduces a
dependance on the CAN frame or processing
order if the notification content depends on
other metrics as well.
This applies especially to the charge start
notification. It is sent synchronously on
the ms_v_charge_state change, but also
includes info from multiple other metrics.
If those other metrics have not been updated
when the state change comes in, the
notification info will be inconsistent.
Vehicles implementing a separate state
metrics processing can work around this by
reordering the metrics updates so the state
update is always last, but a vehicle setting
metrics directly from the incoming frames
(i.e. mapping based) may not be able to do
so easily. We'll have to remember this when
designing the mapping, i.e. add the ability
to buffer some data and define ordered
metrics transactions. Or maybe there's a
more simple solution to this.
There are two more framework notification
candidates, "charge.sufficient" and
"batt.alert.minsoc", but they can wait for
007.
I think we’re about ready
for 3.1.006 now? I need to test
Michael’s new initial config system, but
that code is in place so should be good
to go.
There was only one tester (besides me) of
the wizard yet, so more testing is
important.
Regards,
Michael
Am 09.05.2018
um 15:50 schrieb Mark Webb-Johnson:
The modifications below have
been implemented. Works for me on the
bench.
Individual vehicle modules
can turn this off (it defaults to on) by
setting m_autonotifications=false in
their constructor. Implementations can
also override the individual Notify…()
functions to disable particular
notifications, or customise the output.
For example, a Tesla Model S module may
want to override NotifyValetHood() and
send the alert as ‘frunk’ rather than
‘hood’.
For those testing this with
individual vehicle support, you should
be able to see the following
standardised vehicle alerts now:
- charge.started (a
charge session has started)
- heating.started (the
battery is being heated, as part
of a charge session)
- charge.stopped (a
charge session has been
interrupted)
- charge.done (a charge
session has completed normally)
- valet.enabled (valet
mode has been enabled)
- valet.disabled (valet
mode has been disabled)
- valet.hood (the vehicle
hood has been opened, while in
valet mode)
- valet.trunk (the
vehicle trunk has been opened,
while in valet mode)
- alarm.sounding (the
vehicle alarm is sounding)
- alarm.stopped (the
vehicle alarm has stopped)
- batt.12v.alert (the 12v
battery is at a critically low
voltage level)
- batt.12v.recovered (the
12v battery voltage level has
recovered)
I’ll be updating the user
guide documentation now, as there are
quite a lot of configuration options for
this now. Should finish by tomorrow.
I think we’re about ready
for 3.1.006 now? I need to test
Michael’s new initial config system, but
that code is in place so should be good
to go.
Perhaps people can commit
what they have this week, and we will
build a 3.1.006 OTA release at the
weekend?
As always,
comments/suggestions/improvements
welcome.
Regards, Mark.
It is
time to implement vehicle
notifications (charge started, charge
completed, charge interrupted, etc) in
the vehicle modules I am supporting.
It seems that this can be done in the
vehicle.{h,cpp} framework in a
standard manner, and work across all
vehicle types. However, I guess that
will break any notifications already
being produced by other vehicle types.
My suggestion is:
- A config parameter
‘notifications’, with individual
instances to turn on/off the
notifications. Default is all
enabled.
- OvmsVehicle::MetricModified
picks up metric changes and
issues the standard
notifications (checking
‘notifications’ parameter
appropriately).
- charge_mode=>charging:
Notify charge started
- charge_mode=>topoff: Notify
charge started
- charge_mode=>heating:
Notify battery heating started
- charge_mode=>done:
Notify charge completed
- charge_mode=>stopped:
Notify charge interrupted
- valet_mode=>on:
Notify valet mode enabled
- valet_mode=>off:
Notify valet mode disabled
- alarm=>on:
Notify alarm is sounding
- alarm=>off:
Notify alarm is off
- All the above should
be suppressed for the initial
setting of each parameter. I
will have to look into metrics
to see how best that should be
done; one neat way is to keep a
modification count (rather than
the current m_defined boolean).
Does that make sense?
Any objections/suggestions?
Regards, Mark
I’ve extended the
notifications framework to include
the concept of notification
subtypes. This is in addition to
the existing notification base
types.
This allows us to
automatically filter
notifications based on the
granular subtypes. The filtering
is done at the framework level,
so all notification listeners
need to do is turn it on (when
they register).
I have identified
the following standard subtypes,
and updated quite a few modules
to use them:
- charge.stopped
- charge.state
- batt.alert
- batt.12v (seems
similar to batt.alert, but
not yet decided)
- homelink
- debug.crash
- xks.aux
- xrt.battmon
- xrt.power
- xrt.gps
- xrt.trip
- xrt.sevcon
- xrt.logs
- xrt.reset
I would really
rather have all the alert types
standardised (including things
like trip logs, gps tracking,
etc) and working across all
vehicle types. But this at least
is a starting point.
An example of it
working is:
OVMS# notify
raise text info test
hello
Raise text
notification for
info/test as hello
I (25618)
ovms-server-v2: Send
MP-0 PIhello
OVMS#
config set notify test
none
Parameter
has been set.
OVMS#
notify raise text info
test hello
Raise
text notification for
info/test as hello
OVMS#
config set notify
test ovmsv2
Parameter
has been set.
OVMS#
notify raise text
info test hello
Raise
text notification
for info/test as
hello
I
(71368)
ovms-server-v2:
Send MP-0 PIhello
I am working on
the vehicle module automated
alerts we previously
discussed, and this is a
pre-requisite. New
standardised subtypes will
come with that (such as
charge.start, charge.done,
etc).
Regards, Mark.
Begin forwarded
message:
Subject:
[openvehicles/Open-Vehicle-Monitoring-System-3]
7516c9: test framework
commands for testing can
bus tx/rx
Date:
9
May 2018 at 9:18:53 AM HKT
_______________________________________________
OvmsDev mailing list
OvmsDev@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@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