[Ovmsdev] [Open-Vehicle-Monitoring-System] Driven km and Charge done message (#105)

Wed May 8 08:52:17 HKT 2013

Michael,

Rethinking this, I'm pretty sure it can be done just by looking at car state, with all the notification code removed from the vehicle modules.

The core of what I'm suggesting is to make the alerts more granular, and to give the user more control over what alerts he receives (as opposed to the current situation where they are pretty hard coded into the vehicle modules). And to standardise the available alerts across all vehicle types (as all current alerts in all current vehicle modules, so we don't lose anything).

The problem is demonstrated by NET_NOTIFY_CHARGE just saying charge has ended and being used in two ways at the moment - some modules always signal it after a charge completes, others only when a charge is interrupted. The decision of what to do is currently per-vehicle (not per-user decision). It is also wrong, sometimes, as it is just a general signal to send out current status (which may have changed by the time the alert is actually sent).

What I'm suggesting is to have the vehicle modules set shared status variables (car_soc, car_doors1, etc), as they do at the moment, and not to call NET_NOTIFY_* at all.

For example, the vehicle modules already set the 'charging' bit, so we can use that to internally infer a charge has started / stopped. We even have a charge status that we could look at, if the charge ends, to determine if this is an interrupted charge.

Things like charge reaching N% SOC / Nmiles could also be centrally determined and available for all cars.

The new centralised shared module would monitor the car status, determine the status of the car (charging, parked, driving, etc), and internally signal these alerts as necessary. It would also raise the actual NET_NOTIFY notifications, based on a richer set of user preferences.

So, more granular, more uniform, and let the user choose what sort of alerts he gets.

Apart from the code required for user-specified granular control, I think this would actually be a saving in code size and just 2 or 3 extra bytes of RAM.

Regards, Mark.

On 8 May, 2013, at 1:56 AM, Michael Balzer wrote:

> Mark,
> 
> maybe I don't get the point: isn't that the way it's working already? I.e.
> 
>       net_req_notification(NET_NOTIFY_CHARGE);
> 
> sets the bit, the net module polls the bitmap and sends the message by SMS and/or NET as configured.
> 
> Do you mean to split the common NET_NOTIFY_CHARGE bit into it's separate types?
> 
> If so, what is the benefit of doing this in the vehicle module? An SMS user will need all messages, so why not put the NET config into the App?
> 
> Regards,
> Michael
> 
> 
> Am 06.05.2013 05:13, schrieb Mark Webb-Johnson:
>> Michael(s),
>> 
>> Is it better to move this notification stuff out of the vehicle modules into one single separate module? Then, we can have user controlled settings to control what is alerted, in one single central place.
>> 
>> I'm thinking of just a couple of global bitmaps. When an event happens (charge interrupted, charge stopped, charge started, etc), the vehicle module just sets the appropriate bitmap.
>> 
>> The central module polls those bitmaps, and if any are set it alerts (as configured) and then clears the bitmap. It can also trigger notifications elsewhere in the firmware (for example for the advanced charge control I'm working on).
>> 
>> Nice thing about this is that we can migrate to it vehicle module by vehicle module.
>> 
>> What do you think?
>> 
>> Regards, Mark.
>> 
>> On 5 May, 2013, at 5:58 PM, Michael Jochum wrote:
>> 
>>> Hi,
>>> 
>>> i implement the "charge complete" message, cause at work i have some probs with the voltage. I must reduce the current to 14,5A to get the charge done.
>>> But sometimes i got an error too. Second is that i got a reminder that my car is full and i can release the cord so an other car can charge.
>>> I think a "switch" is a good idea. So the user can got the messages he want.
>>> 
>>> Now we have a other part to think about:
>>> We can set the Volt/Ampera to start the charge based on departure time. But now the OVMS sends every 28 MInutes a message "not charging" until charge starts. I know that this is a problem since we don't have the right CAN ID. I'm still looking for.
>>> Do you think we can stop sending this messages without having the ID?
>>> 
>>> Bye
>>> Michael J.
>>> 
>>> 
>>> Am 03.05.2013 um 12:53 schrieb Michael Balzer <dexter at expeedo.de>:
>>> 
>>>> Mark, Michael,
>>>> 
>>>> for the Twizy I've been sending alerts on charge completion from the beginning. That's my preference, but I also received no complaints from other users up to now. If you're limited to SMS, this is also the only sensible way IMO, you'd otherwise need to query the charge state manually using the "STAT?" command.
>>>> 
>>>> So may be the configuration could be on the App side? The App could check for the notification text.
>>>> 
>>>> I also send an additional optional alert on partial completion (sufficient charge level = "topping off"), that can be set by the "CA" command -- IMO quite useful and as well suitable as a standard function.
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Am 03.05.2013 02:51, schrieb Mark Webb-Johnson:
>>>>> 
>>>>> Michael (J),
>>>>> 
>>>>> I merged this.
>>>>> 
>>>>> I'm a unsure about the message when charge is done part. You have it set to alert whenever a charge completes (even if normally up to 100% SOC), which is not normally. We would usually only alert if the charge is interrupted.
>>>>> 
>>>>> Michael B: What do you do for Twizy on this? Do we need a standard option that the user can set to be alerted whenever a charge is completed (no matter succeed / fail)?
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>>> From: "Michael J." <notifications at github.com>
>>>>>> Subject: [Open-Vehicle-Monitoring-System] Driven km and Charge done message (#105)
>>>>>> Date: 3 May, 2013 3:55:48 AM GMT+08:00
>>>>>> 
>>>>>> Add CAN ID with driven km on Battery for calc for expected km
>>>>>> Add Messagen when Charhe is done
>>>>>> 
>>>>>> Commit Summary
>>>>>> 
>>>>>> Driven km and Charge done message
>>>>>> File Changes
>>>>>> 
>>>>>> M vehicle/OVMS.X/net_msg.c (1)
>>>>>> M vehicle/OVMS.X/vehicle_voltampera.c (32)
>>>>>> Patch Links:
>>>>>> 
>>>>>> https://github.com/markwj/Open-Vehicle-Monitoring-System/pull/105.patch
>>>>>> https://github.com/markwj/Open-Vehicle-Monitoring-System/pull/105.diff
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> 
>>>> -- 
>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>> <dexter.vcf>_______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> <dexter.vcf>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130508/7b2bd005/attachment-0001.html>