This isn’t epsilon error though. This is normal measurements. Also, you can just use the history export option on the history page. No sql needed.
That is so random.
Thanks for that, worked!
It’s the only automation doing this TTS, so it is definitely the correct one.
Agreed, and it’s needless recording of the sensor with ±1 degree accuracy. That’s why i fixed measurements to one decimal to eliminate needless history recordings (which is now ignored). I could easily fix it to zero decimals, also, but i keep it to one for “fancy” reasons…
It is just not possible, that this string with rounded value got spoken with more digits from TTS. The TTS is just taking the string. Put your complete template 1:1 from your TTS automation in the dev tools and not a retyped demo as above ans see what is the result.
Do you want me to post a video to prove it? Or are you going to argue that as well. I’m saying it didn’t work as expected and it did in fact speak a whole heap of decimal places. Believe me or not, it’s fact. There is only one automation doing this task so the code I posted is in fact the code that produced the TTS message with many decimal places.
No I’m I just asked, that you post your automation and not a re-typed dev tools statement.
My first post about this issue has the automation TTS message code.
I just updated HA to version 2025.07. And the decision to send RAW values is… bad (to put it mildly). It needs updating all ESPHOME devices, because while the frontend displays the values correctly, incorrect values are being sent via websocket and curl.
As expected, your script proved to be a good base for adding this to View Assist. It is still really rough around the edges but check out the video anyway :D. Turn on sound.
View Assist provides visual feedback to HA Assist.
1 Like
I’m still waiting to update because of this. What kind of change do we have to do in ESPHome to have the same behavior as before? I’ve read different ideas, but not sure about the final correct thing we should do.