VW e-Golf: vehicle images and a pre-conditioning target temperature

[Nueueuet]

VW e-Golf: vehicle images and a pre-conditioning target temperature

Three commits, each standing on its own.

Add VW e-Golf vehicle images

Photographs of a 2016 e-Golf in white, taken by the car's owner and contributed
under the project's licence, cut out and fitted to the three sizes the app uses:
the three-quarter view, the top view the climate and charge pages compose
overlays onto, and the map marker. Listed as a vehicle type next to the e-Up,
and added to the overlay and map galleries so it can be reached either way
through the editor.

Keep the AC arrows from stretching the car underneath

Independent of the e-Golf and worth a look on its own — it affects every vehicle
except the Leaf.

topview_ac_arrows is a vector sized in dp and drawn for the Leaf's 320x560 top
view. Every other car image is a nodpi bitmap of a different size, so on a
normal-density screen the arrows rasterise several times larger, the
LayerDrawable adopts their size as its own, and every layer below is stretched
to their aspect ratio. The car visibly widens the moment climate control starts,
and the arrows land wherever the stretch puts them.

The overlay is now wrapped so it reports the base image's size and fits itself,
centred, inside it. For the Leaf nothing changes. Measured on a 250x485 top
view: 671x1315 with and without the overlay, where before the climatising state
came out 743 px wide.

Climate tab: target temperature for the VW e-Golf

The e-Golf keeps its pre-conditioning setpoint in the car's stored
BatteryControl profile, and the module reads and writes it there. It is not
carried by the v2 protocol and cannot be derived from metrics, so the tab asks
the module directly: xvg ccstatus when it opens, xvg cctemp <15.5..30.0> when
the slider is released. On release rather than while dragging, so an adjustment
costs one write on the car's comfort bus instead of one per step.

valid=0 in the reply means the module has not read the car's profile yet, so
the slider stays where it is rather than snapping to a placeholder. After a write
the tab re-reads the car instead of trusting what it just sent.

Shown for car_type == "VWEG" only; everywhere else the group stays gone and the
tab looks exactly as before. The card gained a right-hand button column used only
in that layout, so the start button falls under the thumb instead of across the
card from it.

Firmware side: the two commands are
openvehicles/Open-Vehicle-Monitoring-System-3#1507. Until that lands, the slider
is only reachable on a module built from that branch — it is gated on the car
type, so no other vehicle sees it either way.

Testing

• Emulator, against a live module over cellular: the tab opens, ccstatus comes
  back, and the slider snaps to the car's stored 18.0 °C. Moving it writes, the
  car's BCU echoes, and the value survives a re-read.
• Both climate states compared side by side for the arrows fix.
• Rebased onto today's master (5.3.0) and rebuilt; the new custom-image support
  in CarRenderingUtils is untouched by these changes.

[dexterbg]

Issues to resolve/discuss:

• The images need to be optimized, see Wiki.
• Setting the climate control target temperature is a far too common operation to be introduced with vehicle-specific custom commands. This is worth to become part of the V2 message protocol, i.e. get a dedicated MP command or extend MP command 26, and probably also introduce a standard metric and add that to the D message. A dedicated MP command (27?) would be needed for the current capabilities system, as that can only transport MP command codes, not argument support. To complete the control options, a corresponding shell command needs to be defined as well (e.g. climatecontrol target). Make a proposition on the developer list.

Regards,
Michael