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> 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

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Mark, I sent a new pull request. I moved the pin code to password-store. Does it look correct? Geir

10. mai 2018 kl. 13:29 skrev Geir Øyvind Vælidalo <geir@validalo.net>:

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 <mailto: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 <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

…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@validalo.net <mailto:geir@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@webb-johnson.net <mailto: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:

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@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 >  Commit: 7516c9681055ec7986a94ccb8cfb29bda5f1bce8 >      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7516... >  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... >  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... >      **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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> 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 <mailto:OvmsDev@lists.openvehicles.com> 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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Great 🙂 I’ll cancel my last pull request and I’ll use password pin instead of password pincode. Best regards, Geir

10. mai 2018 kl. 14:16 skrev Mark Webb-Johnson <mark@webb-johnson.net>:

Ok

On 10 May 2018, at 8:13 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

...

…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@validalo.net <mailto:geir@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@webb-johnson.net <mailto: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:** <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 <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 <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 <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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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@webb-johnson.net <mailto: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:

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@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  Commit: 7516c9681055ec7986a94ccb8cfb29bda5f1bce8      https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7516...  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...  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...      **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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> 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 <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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

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.

Yep. Found one of those today. Tesla Roadster: charge started notifications didn’t show current properly, because that takes a few seconds to appear. Fix made was to delay charge start notifications until 15 seconds into the charge. In general, I’m finding our ‘time’ metrics really useful. We have charge time (v.c.time), and park time (v.e.parktime). Probably a good to add v.e.drivetime to complement those and track how long the vehicle has been not parked. Regards, Mark.

On 10 May 2018, at 7:08 PM, Michael Balzer <dexter@expeedo.de> wrote:

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

...

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:** <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>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

What I’m trying to do is create a generic algorithm that works for as many vehicles as possible. If a particular vehicle needs particular support, it can override and handle itself appropriately. I’ve delayed the charge start report for all those pre-states (including charging, topoff, heating). I’m guessing that when heating (for example) transitions to charging, the current level should be fine and we can report immediately. For Tesla roadster it goes heating->preparing->charging. What does the current approach look like on the Twizy? Regards, Mark.

On 13 May 2018, at 6:42 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

Am 12.05.2018 um 15:51 schrieb Mark Webb-Johnson:

...

...

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.

Yep. Found one of those today.

Tesla Roadster: charge started notifications didn’t show current properly, because that takes a few seconds to appear. Fix made was to delay charge start notifications until 15 seconds into the charge.

I just saw you made that change for all vehicles instead of only for the roadster. I'm really not sure about that, it feels like a workaround.

Your change also breaks the notifications on state transitions during the charge. The "topoff" phase on the Twizy is equivalent to the CV (constant voltage) charge phase, so "charging" goes over to "topoff" at some indeterminate time into the charge.

I don't know how "heating" works on the Roadster, but "heating" would normally also seemlessly proceed to "charging".

Regards, Michael

...

In general, I’m finding our ‘time’ metrics really useful. We have charge time (v.c.time), and park time (v.e.parktime). Probably a good to add v.e.drivetime to complement those and track how long the vehicle has been not parked.

Regards, Mark.

...

On 10 May 2018, at 7:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

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

...

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:** <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>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Looks good. I think this approach is general enough. Regards, Mark. P.S. For roadster, the topoff is just a different type of charge (I think triggered when you press Top-Off on the in-car control, to top-off an already fully charged battery). So, it occurs at the middle of the charge, just the same as ‘charging’. Regards, Mark

On 13 May 2018, at 4:08 PM, Michael Balzer <dexter@expeedo.de> wrote:

Am 13.05.2018 um 03:43 schrieb Mark Webb-Johnson:

...

What I’m trying to do is create a generic algorithm that works for as many vehicles as possible. If a particular vehicle needs particular support, it can override and handle itself appropriately.

I’ve delayed the charge start report for all those pre-states (including charging, topoff, heating). I’m guessing that when heating (for example) transitions to charging, the current level should be fine and we can report immediately. For Tesla roadster it goes heating->preparing->charging.

So the current implementation will also only notify on i.e. heating but not on the transition from heating to charging, because the charge time counter starts on heating. That may be sufficient, but users may want to also or only get a notification on the actual charge start. Heating may take quite some time in very cold climate.

The base problem seems to result from a lack of a common definition / consent on the meaning of the states. I always understood and used "topoff" not as a pre-state but as a finishing state. My definition would look like this: charging: main charge phase (constant current phase, full speed) topoff: finishing charge phase (constant voltage phase, cell balancing) done: standard completion of a full charge prepare: any kind of preparation phase timerwait: waiting for a timer based charge start heating: heating up cells before charge in cold climate stopped: any kind of charge stop before the standard completion ("done")

A normal charge process is: [timerwait →] [heating →] [prepare →] charging → [topoff →] done

…with [] being optional states. The charge process can start at any state, i.e. if the battery is warm and nearly full, it would start at topoff.

You normally want to get a notification on "topoff" entry if you're on the road and want to go on as quickly as possible.

That's the process for the Twizy. The Twizy doesn't have a prepare phase (it has technically but it's too short to bother), charge voltage and current are stable on the bus when the charge start is signaled.

On the Tesla Roadster, if the current is not stable during the first 15 seconds, it would seem to be a natural mapping to set that phase as state "prepare". But I remember the phases are taken directly from the bus on the roadster implementation.

For a general base solution, your approach of a delayed notification would work if we didn't use ms_v_charge_time as a base but a separate charge phase time that is reset on each phase change.

The phase delay then can be applied to all state change notifications, and the delay can be configurable / controllable by the vehicle, possibly varying per state (callback hook).

As that makes the process very flexible and even supports the old scheme (by returning 0 as a delay) I've just implemented that, please check and comment.

I've set the default delay to 3 seconds, that should be sufficient for all vehicles with direct bus→state mappings.

Regards, Michael

...

What does the current approach look like on the Twizy?

Regards, Mark.

...

On 13 May 2018, at 6:42 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

Mark,

Am 12.05.2018 um 15:51 schrieb Mark Webb-Johnson:

...

...

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.

Yep. Found one of those today.

Tesla Roadster: charge started notifications didn’t show current properly, because that takes a few seconds to appear. Fix made was to delay charge start notifications until 15 seconds into the charge.

I just saw you made that change for all vehicles instead of only for the roadster. I'm really not sure about that, it feels like a workaround.

Your change also breaks the notifications on state transitions during the charge. The "topoff" phase on the Twizy is equivalent to the CV (constant voltage) charge phase, so "charging" goes over to "topoff" at some indeterminate time into the charge.

I don't know how "heating" works on the Roadster, but "heating" would normally also seemlessly proceed to "charging".

Regards, Michael

...

In general, I’m finding our ‘time’ metrics really useful. We have charge time (v.c.time), and park time (v.e.parktime). Probably a good to add v.e.drivetime to complement those and track how long the vehicle has been not parked.

Regards, Mark.

...

On 10 May 2018, at 7:08 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

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

> 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:** <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>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ 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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Steve, I meant from the CAN bus point of view. The original documentation for this had: ID 100, B1=0x95, B2=0x01 charge mode is “charging” ID 100, B1=0x95, B2=0x02 charge mode is "topoff" One of my old can bus dumps (labelled 20120218.charge.topoff.crtd) shows this: 5193698.348 R11 100 95 4 1 64 57 2 E 2 5193706.208 R11 100 95 D A 64 57 2 E 2 5193709.798 R11 100 95 1 5 64 57 2 E 2 5193918.339 R11 100 95 4 9 64 57 2 E 2 (duplicates removed, for clarity) That is 0x04 -> 0x0d -> 0x01 -> 0x04 (done -> preparing -> charging -> done). No ‘topoff’. In fact a search for ‘100 95 2’ (or ‘100 95 02’) doesn’t match anything in any logs I have. So perhaps, it doesn’t exist or is a Tesla Roadster 1.5 only thing? Or maybe it is that car automatically tops itself off after 24 hours of being plugged in? Regards, Mark.

On 13 May 2018, at 11:45 PM, Stephen Casner <casner@acm.org> wrote:

On Sun, 13 May 2018, Mark Webb-Johnson wrote:

...

P.S. For roadster, the topoff is just a different type of charge (I think triggered when you press Top-Off on the in-car control, to top-off an already fully charged battery). So, it occurs at the middle of the charge, just the same as ‘charging’.

I wouldn't say it is a different type of charge as much as pressing the Top-Off button means "try some more". That button is only present when the normal charging has finished and the VDS is still showing the charging screen. The Touch Screen Users Manual says this about the message that can appear in the status line at the top of the charging screen:

Topping Off Charge - Automatic charging is in progress because the fully charged vehicle has been sitting for a while. To maintain a full charge, a plugged in vehicle periodically tops itself off.

And this about the button:

TOP-OFF - You can initiate "top off" charging manually.

So it really just means to resume charging to fill back to the intended level to compensate for charge that has dissipated while sitting.

In the Roadster is there any CAN bus indication when the charging process transitions from the full-speed phase to the tapering phase?

-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev