Reviewing our current apps, and server v2 protocol, I’m seeing a problem. We never completed implementing the vehicle capability system, and feature creep seems to have added a bunch of things dependent on specific vehicles with specific capabilities (some standard and some custom). Not all of these are documented. Examples include: Does the vehicle have the ability to pre-heat / pre-cool? Custom OVMS v2 protocol commands > 200 haven’t been documented anywhere (but seem to be used in at least the Android App). In general, does a particular vehicle type support a particular feature? It seems that only option the apps have at the moment are to either include custom vehicle specific code in the app (acceptable when the particular function is only ever implemented by one specific vehicle, but imho a problem when it is generic enough that it starts applying to more than one vehicle type), or to just show the UI, fire off the command when the button is pressed, and handle the ‘not implemented’ response. It is pretty ugly to provide someone a button, but then give them a nasty error message when they press it. In protocol v2, we do (did?) have a car capabilities message: Car Capabilities message 0x56 “V” <https://docs.openvehicles.com/en/latest/protocol_v2/messages.html#car-capabilities-message-0x56-v> This message is sent <cartoserver> “C”, or <servertoapp> “s”, and transmits the vehicle capabilities. It was introduced with v2 of the protocol. <data is comma-separated list of vehicle capabilities of the form: C<cmd> indicates vehicle support command <cmd> C<cmdL>-<cmdH> indicates vehicle will support all commands in the specified range But it seems never implemented in the v3 module firmware, not supported at all in MQTT, and not exposed to the vehicle.{h, cpp} at all. The old PIC based firmware did support it (with default being "C1-6,C40-41,C49” from what I can see in the old firmware). Unless anyone has any better ideas, I suggest we: Extended vehicle.{h, cpp} to provide a callback for vehicles to provide their capabilities. Extend ovms_server_v2 to generate the ‘V’ message from those capabilities. Create a standard metric to store these capabilities (for v3 mqtt protocol apps). Extend the apps to support the ‘V’ message and behave appropriately. Update each of the existing v3 firmware vehicle support code to set capabilities appropriately. Document (in v2 protocol guide) the custom commands. Perhaps consider what other things could be provided in these messages apart from ‘C’ (OVMS v2 protocol commands). For example, TPMS. Regards, Mark.