Add a Hydrometer Device Class

JosiahKerley · August 28, 2022, 6:56pm

At home I use esphome hydrometers as part of my fermentation process and would like to be able to use a specified, ‘Hydrometer’ device class with the units of either Specific Gravity, Brix, or Plato.
i.e., in the way I use:

  - platform: adc
    pin: A0
    id: brew_hydrometer_1_battery_level
    name: "Brew Hydrometer 1 Battery Level"
    unit_of_measurement: '%'
    device_class: battery

to denote the fact that an analog input to a voltage divider should result in a battery level, I would like to use device_class: hydrometer to inform HA that the accelerometer I use should result in specific gravity.

FloatingBoater · August 28, 2022, 8:18pm

Hi,
Is that via an iSpindel device?

The hardware concept so clever I bought one immediately, but am currently still drinking my previous batch of brewing so haven’t tried the calibration nor MQTT + different firmware options yet.

Would you mind sharing the rest of your work in progress config please?

I have experience of custom MQTT sensor and device class config after writing custom firmware for plant watering complete with HASS auto-configuration which works well. The main trick is not trying to be too clever with JSON transformations if you can choose what to MQTT publish.

As you’ve already done for the battery, it’s a case of picking the MQTT topic, icon, unit_of_measurement, and device_class. Percentage + generic might well be the best option for the SG without a pull-request.

There is a Python header file with all the #define options, but it’s the same as device class docs.

James

FloatingBoater · September 29, 2022, 1:05pm

Hi,
The path may be a little clearer to create an iSpindel automation with full long-term stats graphing of SG.

Release 2022.10 BETA includes a binding for a similar Bluetooth device to the open hardware WLAN/MQTT iSpindel device.

Poking around in the GitHub source, there is a definition for Units.SPECIFIC_GRAVITY which suggests there is a way SG can be used as a (custom?) HASS unit, although note properties device_class and state_class are missing (and not in const.py definitions either) which is a bit confusing:

github.com

home-assistant/core/blob/e7764b8bf19027cbebf0e0e38178fa20037cdac1/homeassistant/components/tilt_ble/sensor.py#L43

    
      
          from .const import DOMAIN
          
          
SENSOR_DESCRIPTIONS = {
              (DeviceClass.TEMPERATURE, Units.TEMP_FAHRENHEIT): SensorEntityDescription(
                  key=f"{DeviceClass.TEMPERATURE}_{Units.TEMP_FAHRENHEIT}",
                  device_class=SensorDeviceClass.TEMPERATURE,
                  native_unit_of_measurement=TEMP_FAHRENHEIT,
                  state_class=SensorStateClass.MEASUREMENT,
              ),
              (DeviceClass.SPECIFIC_GRAVITY, Units.SPECIFIC_GRAVITY): SensorEntityDescription(
                  key=f"{DeviceClass.SPECIFIC_GRAVITY}_{Units.SPECIFIC_GRAVITY}",
                  state_class=SensorStateClass.MEASUREMENT,
              ),
              (
                  DeviceClass.SIGNAL_STRENGTH,
                  Units.SIGNAL_STRENGTH_DECIBELS_MILLIWATT,
              ): SensorEntityDescription(
                  key=f"{DeviceClass.SIGNAL_STRENGTH}_{Units.SIGNAL_STRENGTH_DECIBELS_MILLIWATT}",
                  device_class=SensorDeviceClass.SIGNAL_STRENGTH,
                  native_unit_of_measurement=SIGNAL_STRENGTH_DECIBELS_MILLIWATT,
                  state_class=SensorStateClass.MEASUREMENT,

Although digging through Python dependency trees in Git isn’t my strong point, the lack of code in const.py suggests this is a custom unit, and a feature request for both HASS core DeviceClass.SPECIFIC_GRAVITY and ESPhome is needed to add SG properly. The 2022.10 release _might_make this clearer when all the code is in the release branch.

Personally, whilst ESPhome firmware would be great, a MQTT definition with units would be enough to get my next brew batch monitored.

James

Yorkie88 · November 5, 2022, 6:52am

@FloatingBoater I think it comes from the bottom of here:

github.com

Bluetooth-Devices/sensor-state-data/blob/f33a12880008d95096e2845bc0b44f682439a902/src/sensor_state_data/units.py

from __future__ import annotations

from typing import Final

from .enum import StrEnum

# These are currently the same as Home Assistant sensors


class Units(StrEnum):
    # #### UNITS OF MEASUREMENT ####
    # Apparent power units
    POWER_VOLT_AMPERE: Final = "VA"

    # Power units
    POWER_WATT: Final = "W"
    POWER_KILO_WATT: Final = "kW"
    POWER_BTU_PER_HOUR: Final = "BTU/h"

    # Reactive power units

This file has been truncated. show original

And it’s just “SG” so I’m not sure how that works within homeassistant - I might try and fiddle with my iSpindel MQTT config messages as it’s currently sending SG as degrees Plato which is confusing

Oh, and there is a closed pull request in the iSpindel firmware repository for the tilt value to get a unit of measurement (degrees) so it shows as a graph not a state, which is annoying in homeassistant but easily fixed by fiddling with MQTT config messages. Maybe something similar could be added for SG but it’s tricky when there isn’t really a unit for it, it’s just a ratio as I understand it (very new to brewing)