British localisation

Configuration
1

Hi, just about finished moving my previous devices from Blynk over to HA/ESPHome but have hit a couple of snags. I have a couple of automations involving my car, via the BMW integration and it’s thrown up an issue I’ve come across in the past on other platforms, but I haven’t found a way around it here yet. As most software is written by Americans it tends to be USA-centric and there is a common and incorrect thinking that North America uses the old British units (lbs, inches, miles etc) and the rest of the world is metric. Here in the UK we are a mixture because we never quite managed the transition, so we measure our temperature in ºC, the distance we travel in miles, our petrol in litres (though we still quote and calculate our fuel economy in mpg!) and our beer in pints.
The locale tab lets me pick all US or all metric, neither of which I want. I couldn’t live with seeing temperature in ºF so I’ve picked metric, but I want the “remaining-fuel” entity to display it’s figure in gallons, and most of all, my distances in miles not kilometres. Any way round this? can I create another entity which applies a multiplication factor to bring me to the correct figure? What do oter Brits do?

1 Like
2

I try to ignore the level of wrong assumptions made by US or even EU developers, by using all SI-units.

The prime example of mis-understanding is this change:

IMPERIAL_SYSTEM != US_CUSTOMARY_SYSTEM as the left-pondians have several different standards for miles and gallons - all of which are different from old British Imperial units.

Clearly, they didn’t own a Woolworths school exercise book as a child, with the back page covered with all the Imperial utter nonsense of Gunter’s Chain, perch, rod, etc! :slight_smile:

After years of scientific and engineering training, my brain works in km and km/l. It’s not 30mph, but 48km/h! The good news is km makes a cycle ride sound more impressive.

A template function would likely display your choice of units, but that’s not something I’ve tried.

2 Likes
3

create some template sensors to make the conversion:

eg (in yaml):

template:
  sensor:
    - name: 'Distance'
      unique_id: bmw_distance
      device_class: distance
      unit_of_measurement: mi
      state: "{{ (states('sensor.bmw_distance_in_km')|float * 0.62 ) |round(2) }}"

…something like that, anyway. This example creates sensor.distance which should(!) display in miles.

1 Like
4

Same here. I worked in the US for a couple of years and had to convert to US-Imperial which, as you wrote, is different from ‘proper’-imperial. Drove me nuts.

…but everything is listed in miles here so it’s easier to use that for driving.

2 Likes
5

I too have no great difficulty in dealing with km and km/h when driving in Europe, and use metric exclusively at work, but where the signage and car fuel displays here are Imperial, it makes more sense to have those units displayed.
I’m the “crossover” age that started being educated in Imperial, but came back to infants school for a new term to find our wooden rulers had been covered with red and yellow tape adorned with cm/mm.
I’d be quite happy if we went fully metric, it all seems so much more logical when you cross the channel.

Thanks both, the template function seems an extremely valuable one, time to do some more reading.

6

More logical (full stop).
I honestly don’t understand why we cling to it. It made total sense in its day, but we cling to it as if we’d lose our identity without it. The only argument I can understand right now is the cost to make the change but, doing so is such a sensible long-term thing to do.

1 Like
7

Ok I’ve written a template to the config yaml via SSH and restarted HA, but the new sensor doesn’t appear on the list. Is that how it’s supposed to work or is there another step? I did validate the YAML first.

8

I’m over 50 - and was taught EXCLUSIVELY in SI units throughout my entire UK state education which really makes me wonder about the syllabus at certain institutions!

When mixing conversions, I’d suggest being careful to always show the units - software engineers need always need to remember the Mars Climate Orbiter where NASA learned the hard way that Pounds force != Newtons.

Computing Risks Digest has several horrible tales of such unitaty undoings.

9

Ah forget that, just seen a notification that it’s an invalid config so I have done something wrong.

I’m a few months off 60, hence the straddling of 2 systems.

10

A few things come to mind:

  • Where are your template sensors defined?
    I use a /config/templates.yaml which is included from /config/configuration.yaml with the line template: !include templates.yaml.

  • Reloading configuration.yaml wasn’t enough; a FULL restart of HASS used to be needed, however I think the command menu now has a Reload templates command
    (press c on any screen, and type template to search for the restart command).

  • How are you triggering the calculations?
    My own templates are almost static values, so are only calculated once a day (example below).
    I think without this, the templates are recalculated every time the dependent entity changes.

Example template file

Not exactly what you need, as static values with a trigger: condition, but the known-good example might help.

# templates.yaml
# no "template:" here as in configuration.yaml

- trigger:
    - event: start
      platform: homeassistant
    - platform: event
      event_type: event_template_reloaded
    - platform: time_pattern
      # only needs to change once a day
      hours:   05
      minutes: 05
  sensor:
    - name: Date in Text
      #description: "Date in text format suitable for TTS"
      state: >
          {% set dayofweek = ['Monday','Tuesday','Wednesday','Thursday','Friday','Saturday','Sunday'][now().weekday()] %}
          {% set day = ['1st','2nd','3rd','4th','5th','6th','7th','8th','9th','10th','11th','12th','13th','14th','15th','16th','17th','18th','19th','20th','21th','22th','23th','24th','25th','26th','27th','28th','29th','30th','31th' ][ now().day-1] %}
          {% set month = ['January','February','March','April','May','June','July','August','September','October','November','December'][now().month-1] %}
          {{ dayofweek +', '+ day + ' ' + month + ' '+ now().strftime('%Y') }}
      icon: "mdi:CalendarRange"
11

Interesting to get some more data to confirm the cut-off for matriculation metrication!

12

That’s way beyond me, I think I’m maybe trying to run before I can walk.
I thought I’d just be able to put the template definition in the main configuration.yaml?

This is what I’ve put in

template:
  sensor:
    - name: 'Distance'
      unique_id: bmw_distance
      device_class: distance
      unit_of_measurement: mi
      state: "{{ (states(sensor.330e_remaining_range_total)|float * 0.62 ) |round(2) }}"

but I get this error

Invalid config for [template]: invalid template (TemplateSyntaxError: expected token ',', got 'e_remaining_range_total') for dictionary value @ data['sensor'][0]['state']. Got '{{ (states(sensor.330e_remaining_range_total)|float * 0.62 ) |round(2) }}'. (See /config/configuration.yaml, line 17).

I don’t understand the syntax error. I’ve definitely spelt the sensor name right, but it seems to expect it to end after 330

13

states(‘sensor.mb_update_time’) - the name of the entity must be single quoted

1 Like
14

You can test the template code interactively using Dev tools → Template - and paste in the “{{ template }}” part.

1 Like
15

Thank you, that was it. It now displays on the appropriate card, though unfortunately it still puts “km” after the figure, but I’ve called it “Range in miles” so I’ll know.
The only odd thing was that I had to multiply by 0.38 (ie 100 - 0.62) to get the correct figure.

Edit: Ignore this, when I looked closer, there was an option to change the displayed units to miles and when I did this, the 0.62 multiplier worked fine.

16

Thanks, that will save time in future.

17

What list?

Can you share the sensor lines in your configuration?

1 Like
18

See above, now working. Thanks for your template.

1 Like