[Ovmsdev] Notifications Framework (subtype and filtering)
Michael Balzer
dexter at expeedo.de
Thu May 10 20:11:52 HKT 2018
Geir,
yes, that's the way it's meant.
It's also really easy to add a web UI for your specific configurations. Have a look at OvmsVehicleRenaultTwizy::WebCfgFeatures() for an example / template.
Regards,
Michael
Am 10.05.2018 um 13:29 schrieb Geir Øyvind Vælidalo:
> 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
> 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/3b52617d/attachment-0001.html>
More information about the OvmsDev
mailing list