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@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@validalo.net <mailto:geir@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@webb-johnson.net <mailto:mark@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:
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
On 9 May 2018, at 9:33 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@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@github.com <mailto:noreply@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@webb-johnson.net <mailto:mark@webb-johnson.net> Reply-To: GitHub <noreply@github.com <mailto:noreply@github.com>>
Branch: refs/heads/master Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3> Commit: 7516c9681055ec7986a94ccb8cfb29bda5f1bce8 https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7516... <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7516c9681055ec7986a94ccb8cfb29bda5f1bce8> Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@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/183d... <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/183d26dc107bb21cd956776228d0a24030b115db> Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@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/57d... <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/ <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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev