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