2020-01-22 09:48:00 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/google_assistant/report_state.py", line 45, in async_entity_state_listener
if entity_data == old_entity.query_serialize():
File "/usr/src/homeassistant/homeassistant/components/google_assistant/helpers.py", line 442, in query_serialize
deep_update(attrs, trt.query_attributes())
File "/usr/src/homeassistant/homeassistant/components/google_assistant/trait.py", line 892, in query_attributes
response["humidityAmbientPercent"] = round(float(current_humidity))
ValueError: could not convert string to float:
What’s odd is I can’t find anything in my configuration.yaml that references humidityAmbientPercent, nor in Node Red that I can find. I have numerous references to humidity in general including:
I’m guessing that on startup there’s some aspect of this not ready/defined. Maybe. But the traceback seems to indicate this relates to google assistant, which isn’t something I exactly configure other than a bunch of excludes and rooms.
It does not seem to do any harm, but leaves me curious if I have something configured incorrectly?
You don’t provide an else. Meaning if {% if (states('sensor.den_humidity')|float(0.0) > 0.0) and (states('sensor.living_room_humidity')|float(0.0) > 0.0) and (states('sensor.master_bedroom_humidity')|float(0.0) > 0.0) %} resolves to false, you’re sending '' to the sensor. That will produce a ValueError. This is what’s happening on startup for you.
EDIT: I’m having trouble reading today.
Anyways, what I said above is true minus the startup part.
The component that’s having issues is google_assistant. So what humidity devices are you sending to google_assistant?
Verify that those states can convert to a float. I.e. Look for humidity sensors that are ‘unknown’, have no state, or contain units INSIDE the state.
I don’t have anything for google assistant per-se. I use the cloud version, and have simply:
cloud:
google_actions:
filter:
exclude_entities:
- media_player.living_room_cast
- media_player.den_cast
lots more
entity_config:
group.interior_lights:
room: Interior
lots more with just specifying rooms
It must be something it is sucking in during its discovery or whatever it does?
At least after startup all humidity sensors show a value that’s valid and a float. That’s why I wonder if there is a race condition on startup?
Since there is only one, a possibility is an MQTT humidity sensor – I have only one of those. There’s no explicit configuration for it, but in states it shows fine.
But none of them are defined, as it were – they come naturally from the integrations either zwave or mqtt. Other than the calculations noted above, I do not have any explicit definition for them, so I am unsure how to approach determining the issue. The only real clue I have is that there is 1 error and only one humidity sensor comes from mqtt, there are half a dozen from z-wave.
Are there any debug modes or similar to get more info as to what sensor is involved (or maybe better, what to do about it, since they aren’t explicit)?
I’m not sure how to figure it out from logs. I tried just debug, but the browser window kept crashing with too much volume. Limited to google_config I got nothing. Limited to core I got a lot of stuff but nothing that seemed relevant, lots of battery and other seemingly unrelated items surrounding the error.
However, I realized that humidity sensors were being sent to google assistant but it appears google cannot do anything with them, so I put them in the exclude. Once there, the error message went away.
I’m still guessing there is a bug, a race condition of sorts, in that code, but since you can’t (apparently?) do anything with humidity sensors in google, it seems pointless to send them.
I’d be willing to bet you can ask ‘hey google, what’s the humidity of xxxx’. I don’t have a google home, so I wouldn’t know. I doubt that the dev’s would add something that couldn’t be used. And from looking at the code, they added a lot to handle humidity sensors.
Yep, you nailed it. I tried variations like “what’s the master bathroom humidity” without success but reversing it worked. It’s very weird how some phrases confuse it. So maybe I should send them over, I’ll take some out at a time and see if I can tell which one is throwing it.
interior_average_humidity:
friendly_name: Interior Average Humidity
device_class: humidity
unit_of_measurement: "%"
value_template: >
{% if (states('sensor.den_humidity')|float(0.0) > 0.0) and (states('sensor.living_room_humidity')|float(0.0) > 0.0) and (states('sensor.master_bedroom_humidity')|float(0.0) > 0.0) %}
{{ ((states('sensor.den_humidity')|float + states('sensor.living_room_humidity')|float + states('sensor.master_bedroom_humidity')|float) / 3.0) | round(2) }}
{% endif %}
They are all z-wave. I may not have done that right, I was trying to test in the IF statement to see if the values were valid. Is there a more appropriate way?
My speculation it was MQTT seems misplaced – it’s a calculation so it could be any of the zwave (or all) that are not ready yet when google_assistant code tries to send them.
Ah… so here’s the thing – when I return a value it throws off all the graphs, making them auto-scale to zero (or 100 or some such). I guess I could try to pick something moderate to through it off less.
But what I want it to do is, effectively, NOT have a value until… well, it has a real value.
I’ll try unknown. It’s been a long time, but my recollection is they returned something else that parsed to zero but wasn’t and gave an error, but I may need to recreate the original problem to see why I did this.
It looks like “unknown” may work. I recreated the original problem, when I just had the value calculation. What happens is this causes the average to go to zero on restart.
Which was annoying, so I tried to be sure I had all the values before I let it return a value. Apparently google is unhappy with no value, but happy with “unknown”. At least so far, until this causes some other issue.
