[Ovmsdev] Notifications Framework (subtype and filtering)

Michael Balzer dexter at expeedo.de
Thu May 10 20:13:43 HKT 2018


…or I can add the PIN to the vehicle config page, if this is a generally useful field.

Regards,
Michael


Am 10.05.2018 um 14:09 schrieb Mark Webb-Johnson:
>
> It is getting to be a big system, with very little documentation.
>
> The ‘password’ config parameter is a general store for passwords. It is writeable by the user, but not readable. Firmware modules can read it just fine.
>
> I suggest we use:
>
>     OVMS# config set password pin 1234
>
>
> Just use that for your pin at the moment, and we’ll work out how best to use it for commands like LOCK/UNLOCK/VALET/UNVALET/etc later.
>
> I have just added a bool PinCheck to OvmsVehicle. You can call that with the provided PIN and it will check against config password/pin (also returning false
> if the password/pin is not defined in config).
>
> Regards, Mark.
>
>> On 10 May 2018, at 7:29 PM, Geir Øyvind Vælidalo <geir at validalo.net <mailto:geir at validalo.net>> wrote:
>>
>> I agree, but until now there was no protection at all. 
>>
>> I haven’t had too much time to spend on OVMS, so there are so many parts of OVMS I don’t know nothing about, like the password store 🙂
>> Can I just advice the users to do this: config set password pincode 1234
>> And then verifying the pin code in code by comparing it with MyConfig.GetParamValue("password","pincode»)?
>> Is that the way it is meant to be used?
>>
>> If so I can change that very quickly.
>>
>> Best regards,
>> Geir
>>
>>> 10. mai 2018 kl. 13:06 skrev Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>:
>>>
>>> I see the PIN code there.
>>>
>>> Probably ok for the moment, but I’m thinking that in general it would be good to have that vehicle pin code stored in the password config store, protected
>>> and available to all vehicles. We don’t need multiple vehicle-specific PINs in the one module.
>>>
>>> Then, if defined we should use it to verify PINs locally before sending to the car. Privileged commands (such as scripts) could send it directly. We could
>>> also implement some protection in those basic commands again brute-force attacks. These pins are a real weakness is vehicle security systems.
>>>
>>> Regards, Mark.
>>>
>>>> On 10 May 2018, at 5:08 PM, Geir Øyvind Vælidalo <geir at validalo.net <mailto:geir at validalo.net>> wrote:
>>>>
>>>> This is great, Mark! 
>>>>
>>>> I’ve sent a pull request with changes where I’ve cleaned up the notifcations on the Kia Soul.
>>>>
>>>> Best regards,
>>>>
>>>> Geir
>>>>
>>>>> 9. mai 2018 kl. 15:50 skrev Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>:
>>>>>
>>>>>
>>>>> 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 <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> 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/28b7805e/attachment.htm>


More information about the OvmsDev mailing list