[Ovmsdev] Automatic vehicle notifications

Fri May 25 15:55:26 HKT 2018

> I solved that for the Twizy by initializing to the empty state (key 0) and not setting the charge state until it actually changes.

Really trying to avoid that. The idea of the metrics system was to just have the vehicle modules simply set the metric value, and have the metric system itself handle whether it was changed, unit conversion, etc.

Looking at the implementation, we have:

public:
    OvmsMetric* m_next;
    const char* m_name;
    metric_unit_t m_units;
    std::bitset<METRICS_MAX_MODIFIERS> m_modified;
    uint32_t m_lastmodified;
    uint16_t m_autostale;
    bool m_defined;
    bool m_stale;

I think all we would have to do is add a ‘bool m_firstdefined’, with appropriate logic. True the first time it is defined, but false for subsequent changes. Vehicle module can use this to not issue those charge notifications if firstdefined. Not sure about byte alignment on those m_defined and m_stale bools - they don’t seem optimal the way they are. I think we can probably do this with zero additional ram requirement.

> Not sure if we can use external RAM for metrics.

I don’t see why not. I’ll have a look at it as part of this work.

Regards, Mark

> On 25 May 2018, at 3:39 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> 
> Am 25.05.2018 um 04:25 schrieb Mark Webb-Johnson:
>> Re-visiting this, we don’t seem to have done the ‘low SOC’ notification yet. Should be quite simple, so I will handle this.
> 
> OK.
> 
>> We’re also not handling the module reset correctly and issuing charge notifications when the module starts up. This is more tricky. Should we just suppress all notifications within the first N seconds after boot-up (to give the vehicle modules time to set things correctly). Or should we only notify if this is not the first time the value has been set (add a modification count to the base metric system so we can see how many times the value has been modified)?
> 
> I solved that for the Twizy by initializing to the empty state (key 0) and not setting the charge state until it actually changes.
> 
> If the reset happens during a charge, I get a new charge start notification, but that is OK as it also informs me that the charge monitoring had a reset and could not record the full process. If that would be suppressed, I would need a dedicated "I crashed" notification.
> 
> Adding change counters just for this seems to be unnecessary overhead. Not sure if we can use external RAM for metrics.
> 
> Regards,
> Michael
> 
>> Regards, Mark.
>> 
>>> On 25 Apr 2018, at 2:45 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>> 
>>> We can also add the "sufficient SOC/range reached" notifications, the low SOC alert and the low 12V alert to the framework.
>>> 
>>> Porting the low 12V detection is on my list for today/tomorrow. For the sufficient SOC/range notifications, I currently still (mis-)use the topoff state, which is irritating to users.
>>> 
>>> Notification config should include a channel selection for each, so users can choose which of them to get by SMS. May be combinable, i.e. instead of a bool, use a set of ("ip", "sms")?
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 25.04.2018 um 03:13 schrieb Mark Webb-Johnson:
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at 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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180525/432dd025/attachment.htm>