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