[Ovmsdev] Notifications Framework (subtype and filtering)

Michael Balzer dexter at expeedo.de
Thu May 10 19:08:17 HKT 2018


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:
>>
>>  1. A config parameter ‘notifications’, with individual instances to turn on/off the notifications. Default is all enabled.
>>
>>  2. 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
>>
>>  3. 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
>
>
>> On 9 May 2018, at 9:33 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>
>> 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:
>>>
>>> *From: *GitHub <noreply at github.com <mailto:noreply at github.com>>
>>> *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
>>> *To: *mark at webb-johnson.net <mailto:mark at webb-johnson.net>
>>> *Reply-To: *GitHub <noreply at github.com <mailto:noreply at github.com>>
>>>
>>>  Branch: refs/heads/master
>>>  Home:   https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3
>>>  Commit: 7516c9681055ec7986a94ccb8cfb29bda5f1bce8
>>>      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7516c9681055ec7986a94ccb8cfb29bda5f1bce8
>>>  Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>  Date:   2018-05-09 (Wed, 09 May 2018)
>>>
>>>  Changed paths:
>>>    M vehicle/OVMS.V3/main/test_framework.cpp
>>>
>>>  Log Message:
>>>  -----------
>>>  test framework commands for testing can bus tx/rx
>>>
>>>
>>>  Commit: 183d26dc107bb21cd956776228d0a24030b115db
>>>      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/183d26dc107bb21cd956776228d0a24030b115db
>>>  Author: Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
>>>  Date:   2018-05-09 (Wed, 09 May 2018)
>>>
>>>  Changed paths:
>>>    M vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp
>>>    M vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp
>>>    M vehicle/OVMS.V3/components/vehicle/vehicle.cpp
>>>    M vehicle/OVMS.V3/components/vehicle_kiasoulev/src/vehicle_kiasoulev.cpp
>>>    M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_battmon.cpp
>>>    M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_notify.cpp
>>>    M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_sevcon.cpp
>>>    M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_sevcon_faults.cpp
>>>    M vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/vehicle_renaulttwizy.cpp
>>>    M vehicle/OVMS.V3/main/ovms_boot.cpp
>>>    M vehicle/OVMS.V3/main/ovms_notify.cpp
>>>    M vehicle/OVMS.V3/main/ovms_notify.h
>>>
>>>  Log Message:
>>>  -----------
>>>  Notifications: Framework extensions to add support for subtypes on notifications, and automatic filtering by subtype and distribution mechanism
>>>
>>>
>>> Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/57d8f1b449d6...183d26dc107b
>>>      **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/
>>>
>>>      Functionality will be removed from GitHub.com <http://github.com/> on January 31st, 2019.
>>
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180510/757f59bf/attachment.htm>


More information about the OvmsDev mailing list