Multiple unit systems for mixed-up Canadian

As a Canadian, I can say that we have one foot in the metric system and the other in Imperial. I measure my weight and height in imperial, use 2"x4"s for construction, but do all my measurements in metric. Likewise, air temperature is in Celsius, but water temperature is in Fahrenheit. Perhaps this is because our nearest neighbour is the USA.

All of this leads me to ask the following. I have configured HA to use metric in the Configuration. I am working on defining a generic_thermostat integration for my pool heater. As per my first paragraph, I would like to use Fahrenheit for this, rather than Celsius that is defined for everything else.

Is there a way to do this so that it displays correctly in the front-end?

1 Like

Didn’t know that. Is it all Canadians or specific to some regions?

IIRC, HA do temperature conversion by itself, so if you have Celsius defined, it will convert any Fahrenheit it sees in Celsius. Bottom-line: Will be tricky if possible at all…

I believe it is wide-spread, though I would never claim to speak for all Canadians.

Thanks or the info… I wonder if I can find a custom card that would allow me to do this.

I don’t know about the generic thermostat, but with templates and at least some other platforms you can specify unit_of_measurement: "°F"

One other thing; once the value is in the “recorder” (history) database as one unit of measurement, HA will show that unit until the first record ages out of the database. Apparently HA only looks at the first one when deciding how to display a value. Lots of hits on this if you search this forum.

Speaking as a Canuck, it’s specific to the topic’s author. :wink:

I’m comfortable using either unit system but gravitate to one or the other depending on the application. I imagine other Canadians do this as well and (speculation) it may depend on their generation (i.e. Canada adopted the metric system in the mid-70’s).

I think this droll Reddit post summarizes it nicely:

Examples of the peculiarity of my own choices:

  • Thermostat temperature is in celsius.
  • Indoor/outdoor temperature sensors are in celsius.
  • Oral thermometer is in celsius.
  • Oven temperature is in fahrenheit.
  • Pool temperature is in fahrenheit.

There’s probably some way to change the oven’s unit system but then the first few things baked in it would probably be incinerated … :slight_smile:


Off-topic but my pet peeve is that various groceries are advertised in cost per pound but on the receipt the cost is recorded in the official unit system, so cost per kilogram. They should scrap cost per pound (except that it appears to be cheaper that way since a pound is slightly under half a kilogram).

4 Likes

The integration defaults to using your selected unit system so if it’s metric, it will be displayed in metric. Unlike a Template Sensor which has a unit_of_measurement option, the integration doesn’t have it.

That’s what I feared… thanks for confirming. Thank you to everyone for humouring (or is it humouring?) me on this one.

Have you considered making a custom sensor that you convert from Celsius to Farenheit`template:

  - sensor:
      - name: "pool_temperature_f"
        unit_of_measurement: "F"
        state: "{{ states('sensor.pooltemperature')|float * 1.8 }}"
        state: "{{ states('sensor.pool_temperature_f')|float + 32 }}"

I may not have the syntax correct. I will try this and let you know how it works.

Unless I have misunderstood the original request, the goal is to display temperature in Fahrenheit in the generic_thermostat integration (not in a Template Sensor). It’s being used to control a pool heater.

I could be totally off base but using this sensor in a virtual thermostat would meet the requirements.

This is the configuration I used -

- platform: template
  sensors:
# Convert entiy from Farenheit to Celsius
    main_floor_temperature_c_0:
      friendly_name: "main floor thermostat temperature celsius 0"
      unique_id: "Main_Floor_Temperature_in_Celsius_0"
      value_template: "{{ states('sensor.main_floor_temperature')|float - 32 }}"

    main_floor_temperature_c:
      friendly_name: "main floor thermostat temperature celsius"
      unique_id: "Main_Floor_Temperature_in_Celsius"
      value_template: "{{ states('sensor.main_floor_temperature_c_0')|float * 0.555555555555 | round(1) }}"

This is the configuration for a generic thermostat

#
#Create a generic thermostat for a pool
#Use fahrenheit temperature sensor 
#
climate:
  - platform: generic_thermostat
    name: Pool Thermostat
    heater: switch.yourcontrolmechanism
    target_sensor: sensor.pooltemperaturesensor
    min_temp: 60
    max_temp: 80
    target_temp: 76
    away_temp: 60

FWIW, the generic_thermostat integration will use almost anything you throw at it, including an input_number entity for target_sensor and an input_boolean for heater. It’s happy as long as:

  1. target_sensor contains a numeric value
  2. heater accepts an on/off command

The numeric values could be in Kelvin, Celsius, Fahrenheit, or Rankine, the generic_thermostat integration doesn’t concern itself with the unit system.

The issue is that the generic_thermostat will be displayed, by the Thermostat card, using the default unit system (in this case metric instead of imperial units). It doesn’t have a configuration option to change the displayed unit system.

Screenshot from 2021-06-22 16-04-52

One way around this would be to use a custom thermostat card such as nervetattoo’s Simple Thermostat Card which allows you to choose an alternate temperature unit (or show none).

unit string|bool: Override the unit to display. Set to false to hide unit

That was my experience. Hopefully there will be an update at some point for those of us who straddle both worlds! :wink:

This is what it would look like in a simple thermostat. I know I have some round off that I need to fix.
I have tried setting the unit_of_measure to C in customizations but that does not work.

Here is the simple thermostat setup:

I think the ultimate units handling would allow the creation of custom units and apply custom units to an entity.