Just seems wasteful to have a dozen metrics for this. Expensive in ram, bandwidth, and mqtt. Every vehicle module would have to set the unused ones to ‘no’ (due to the way mqtt retained topics work). If we add a new capability, all the vehicle modules would have to be changed to set it to ’no'.
Your suggestion is cleaner, but more expensive.
Regards, Mark.
> On 12 Jul 2018, at 5:34 PM, Robin O'Leary <
ovmsdev@caederus.org> wrote:
>
> On Thu, Jul 12, 2018 at 08:56:25AM +0800, Mark Webb-Johnson wrote:
>> I think the capabilities are useful, but need to be done in a better, more future-proof, way. Relying on protocol v2 commands is limited.
> ...
>> My suggestion is:
>>
>> Create a standard metric ‘v.capabilities’.
>> Have the vehicle modules set that metric with their capabilities, as a comma-separated list of the commands supported:
>
> Mapping things to strings seems rather roundabout.
> Would it not be better to have individual boolean capabilities?
>
> v.capability.chargemode = yes/no
> ...
> v.capability.climate = yes/no
> _______________________________________________
> OvmsDev mailing list
>
OvmsDev@lists.openvehicles.com>
http://lists.openvehicles.com/mailman/listinfo/ovmsdev