Sorry to ask, but this one has me baffled …
The configuration for the sump level sets it to 1 decimal:
The overview and history displays match:
But on the Developer / States display as well as email and app alerts, it comes up with 13 decimal places:
What’s the magic to get these last 2 resolutions to match to the sensor setting of 1 decimal place?
Thanks.
Display precision in settings is only for HA front end, it will never effect the actual state. You need to do that with a round() filter and set the precison in what ever template you’re using to for your email and app alerts. Something like…
{{ states('sensor.esphome_01_jsn_sr04t_distance') | round(1) }}
What precision and type is the variable for the distance sensor in your code that generates the data? The yaml code for your SR04T?
Check in your debug code.
You are not going to get an improvement in precision by converting it to another type.
As the value of a state in HA it’s always a string, so if you want to change it’s precision when sending the value via notify or what ever it needs to become a float (which is what the device is supplying anyways before it becomes an HA sensor state). round(1) does this without having to mess with the device firmware.
Rick, thank you for mentioning the Round(1) function - app messages and emailed texts are coming through with selected precision … except when the sensor reading is unavailable from the ESP32 due to loss of Wifi communications. At those times no message is sent and this error is raised:
Is there any way to trap that error and send the ‘unavailable’ status?
IOT7712, the sensor data is coming from an ESP32:
esphome:
name: esphome-01
friendly_name: ESPHome-01
min_version: 2025.11.0
name_add_mac_suffix: false
esp32:
board: esp32dev
framework:
type: esp-idf
# Example configuration entry
sensor:
- platform: ultrasonic
trigger_pin: GPIO5 # D5
echo_pin: GPIO18 # D18
name: "JSN-SR04T Distance"
update_interval: 5s
unit_of_measurement: "cm"
accuracy_decimals: 1
timeout: 1.0m
filters:
- filter_out: nan
- round: 3
- lambda: |-
if (!infinity) return NAN;
if (x < 0.25 || x > 4.5) return NAN; // Return NAN for out-of-range values
return x * -100 +33; // Convert meters to -cm and compensate
- filter_out: nan # to filter out nan from lambda
- median: # to get rid of outliers and spikes (see Forum)
window_size: 5
send_every: 1
send_first_at: 1
# Enable logging
logger:
# Enable Home Assistant API
api:
port: 6053
batch_delay: 50ms # Reduce latency for real-time applications
listen_backlog: 2 # Allow 2 pending connections in queue
max_connections: 6 # Allow up to 6 simultaneous connections
max_send_queue: 10 # Maximum queued messages per connection before disconnect
encryption:
key: "---"
reboot_timeout: 30min
# Allow Over-The-Air updates
ota:
- platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
This may be where you are losing precision. Is it evaluating correctly?
Check your ‘NAN’ logic too.
IOT7712 - the decimals:1 and round: 3 are being applied to the measurement in meters which then gets multiplied by -100 to convert to xy.z cm below the floor and 33 is then added to compensate for the height of the sensor above the floor.
The sensor readings have been looking really good.
What gets evaluated first? Does there need to be brackets here?
HA’s has_value() test/filter will check if the sensor has a valid value (aka not unavailable or unknown), you can catch it with something like…
{% if has_value('sensor.esphome_01_jsn_sr04t_distance') %}
{{ states('sensor.esphome_01_jsn_sr04t_distance') | round(1) }}
{% else %}
The distance is currently {{ states('sensor.esphome_01_jsn_sr04t_distance') }}, apologies for the inconvenience.
{% endif %}
# or
{{ states('sensor.esphome_01_jsn_sr04t_distance') | round(1) if has_value('sensor.esphome_01_jsn_sr04t_distance')
else states('sensor.esphome_01_jsn_sr04t_distance') }}
HA templating docs for ‘states’
If you share the automation or script that it’s being used in we might be able to give you a more relevant option, but the above should get you there.
Experience indicates the calculation observes correct order of operations and produces the correct answer.
Rick, input and successfully tested the second suggestion, thank you!
Here’s the current coding:
alias: Test notification to Pixel 4a app 1501hrs
description: ""
triggers:
- trigger: time
at: "15:01:00"
conditions: []
actions:
- action: notify.mobile_app_pixel_4a
metadata: {}
data:
message: >-
Test notification to app 1501hrs
Sump Level: {{ states('sensor.esphome_01_jsn_sr04t_distance') | round(1)
if has_value('sensor.esphome_01_jsn_sr04t_distance')
else states('sensor.esphome_01_jsn_sr04t_distance') }}
data:
channel: Test
mode: single
Good to hear 
.
Try this too:
{{ states('sensor.esphome_01_jsn_sr04t_distance', True, True) }}
As for the long number of digits, I assume ESPHome sends it as text and then when HA gets it then it’s the old string → float → string conversion.
homeassistant:/config# python3 -c 'print("Round-trip:{:.30f}".format(float("59.2")))'
Round-trip:59.200000000000002842170943040401