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