We’re update buddies! 
Anybody see this issue? After updating to 0.111, I noticed that the lux values from my Xiaomi motion sensors are not logged into InfluxdB. The data stops right when I updated HA to 0.111. The entity IDs have not changed. I restarted inFluxdB just to see, and there’s still no data flowing to it. But the motion sensor states are working, and you can see the lux values when looking at the entity IDs and in badges within HA. So there data is getting to HA, but not into InfluxDB.
sorry to say this is not my experience at all…
Though the frontend seems to be available sooner, in my setup that is of no real advantage since it takes almost another 2.5 minutes before the rest of the system is initialized completely. Iow, I won’t touch it, even if the first frontend is loaded after, admitted, just a few seconds. Showing all empty placeholders for most of the button-cards and other templated sensors, based on integrations that aren’t yet initialized…
Total startup time has improved somewhat, though I would call it night and day.
But, maybe even more important, talking about snappier, I’d say on the contrary. My fastest system was definitely 110.+.
Both local or remote, it takes more effort for the system to respond to frontend action. The connecting cogwheel in the app re-appears, where 110.+ had done away with that almost completely.
No Ive only changed 2 integrations, Synology, which was already there but changed quite a bit, and added the new Core integration for Plugwise, which I had running in beta.
So, not sure if these could cause that.
sorry to say, it is back… 
I am not using cache so please stop trying to load from it.
2020-06-11 20:48:10 ERROR (MainThread) [homeassistant.components.tts] Error on load tts: a84abdc5547c22054b401ac07624fe115bb034d7_nl_-_google_translate not in cache!
2020-06-11 20:48:10 ERROR (MainThread) [homeassistant.components.tts] Error on load tts: a84abdc5547c22054b401ac07624fe115bb034d7_nl_-_google_translate not in cache!
2020-06-11 20:48:10 ERROR (MainThread) [homeassistant.components.tts] Error on load tts: a84abdc5547c22054b401ac07624fe115bb034d7_nl_-_google_translate not in cache!
2020-06-11 20:48:10 ERROR (MainThread) [homeassistant.components.tts] Error on load tts: a84abdc5547c22054b401ac07624fe115bb034d7_nl_-_google_translate not in cache!
2020-06-11 20:48:10 ERROR (MainThread) [homeassistant.components.tts] Error on load tts: a84abdc5547c22054b401ac07624fe115bb034d7_nl_-_google_translate not in cache!
not sure if this has anything to do with the responsiveness (less snappy), but I’ve never seen my browser ask me to save up to 1.2 gb data?:
Updated to 0.111.1 smoothly. Only small issue was that I need to also reload the lovelace resources for some cards to reappear. Not a big deal but takes away from the hands off experience. Definitely alot faster starting the container and having a visible frontend.
Hey I noticed the Ford Remote Start on your dash, do you have Ford integrated? If so, how? Thanks in advance.
1 Like
It’s not a Ford integration unfortunately, just an input_text with a fancy entity_picture: icon. I have a script that simply sends a TTS with the following: “Alexa, ask My Ford Mobile skill to start my car with PIN 1234.” The remote start PIN is stored in that input_text so I can change it from the UI without having to update the script itself.
Nothing really smart about it, but saves me from having to remember/speak those voice commands.
1 Like
ok thanks - I upgraded from 0.109.7 so it was working there ok… You seen any update/info on the issue/fix?
Hi,
I’m runnin home assistant on my Pi4 using docker.
I used the supervised installer i think 1 or 2 years ago.
but when i do:
sudo docker logs $(sudo docker ps -aqf "name=homeassistant") -f
i see a lot of these messages:
Pseudo-terminal will not be allocated because stdin is not a terminal.
Somebody knows why or how to fix it?
It happened after updating to 0.111.x but supervisor logs are still working…
Thanks!
Bye
Guys,
I see the following error after upgrading to 0.111.1:
2020-06-12 10:01:49 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/hassio/discovery.py”, line 97, in async_process_new
service, context={“source”: “hassio”}, data=config_data
File “/usr/src/homeassistant/homeassistant/data_entry_flow.py”, line 129, in async_init
flow, flow.init_step, data, init_done
File “/usr/src/homeassistant/homeassistant/data_entry_flow.py”, line 197, in _async_handle_step
f"Handler {flow.class.name} doesn’t support step {step_id}"
homeassistant.data_entry_flow.UnknownStep: Handler DomainConfigFlow doesn’t support step hassio
Everything is working so i don’t know what this means…
to illustrate the above, ive juste updated to 0.111.1 (went smooth as before, so thanks!) the kick start works fine, taking about 1 minute in my setup to get to the domain automation and then it takes a real good time to get to the new step. Why is not disclosed in the log:
2020-06-12 10:02:42 INFO (MainThread) [homeassistant.setup] Setup of domain automation took 3.5 seconds.
2020-06-12 10:05:03 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /supervisor/options request
2020-06-12 10:05:03 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /discovery request
2020-06-12 10:05:03 ERROR (MainThread) [homeassistant.components.hassio.discovery] Can't read discover info:
2020-06-12 10:05:11 ERROR (MainThread) [homeassistant.components.hue.light] Timeout fetching light data
2020-06-12 10:05:17 ERROR (MainThread) [homeassistant.components.plugwise] Timeout fetching Smile data
All I can see is the old (ever since 0.80, and never been answered or even acknowledged…) hassio errors are still here, not sure why the issue report I filed was closed at all… 102.1 (was 0.80.0b0): Can't read discover info · Issue #17266 · home-assistant/core · GitHub and re-open: Can't read discover info · Issue #30751 · home-assistant/core · GitHub
@dshokouhi:
When updating from xiaomi aqara to this Miio configuration: do I get new devices or are the existing ones migrated?
HI Paulus,
back to this again, and I can confirm the custom-ui errors to be solved, by checking for the state, before trying to read attributes of it.
person.marijn:
templates:
entity_picture: >-
if (entities['sensor.marijn_picture']) return entities['sensor.marijn_picture'].state;
return '/local/family/marijn_not_home.png';
maybe even using
return '/local/homeassistant/ha_animated_not_home.gif';
as to show startup activity is still going on 
however, this is more difficult, and long standing:
'None' has no attribute 'attributes'
litters the startup log, which has been mentioned UndefinedError: 'None' has no attribute 'attributes' and above, caused by templates referencing unitialized entities. Same problem in fact, but now in core…
the log offers nothing to go on:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/connection.py", line 95, in async_handle
handler(self.hass, self, schema(msg))
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 265, in handle_render_template
state_listener()
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 253, in state_listener
msg["id"], {"result": template.async_render(variables)}
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 230, in async_render
raise TemplateError(err)
homeassistant.exceptions.TemplateError: UndefinedError: 'None' has no attribute 'attributes'
2020-06-12 10:53:14 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.2847230992] Error handling message: Unknown error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 228, in async_render
return compiled.render(kwargs).strip()
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 1090, in render
self.environment.handle_exception()
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 832, in handle_exception
reraise(*rewrite_traceback_stack(source=source))
File "/usr/local/lib/python3.7/site-packages/jinja2/_compat.py", line 28, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
File "/usr/local/lib/python3.7/site-packages/jinja2/sandbox.py", line 407, in getattr
value = getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'None' has no attribute 'attributes'
During handling of the above exception, another exception occurred:
and repeats itself many many times…
Question: could the logger be improved upon in a way the offending template could be identified and named?
In which case it would be easy peasy add a guard in the template for the entity.
Those are jinja errors. You aren’t checking for existence on some of your templates.
yes, I understand, that’s why asked if the logger could identify the template (must be possible since it generates an error, the source for the error is in the system somewhere), so I can
btw it doesnt always happen, I just restarted after a change and had zero errors…
Search for your uses of states.domain.object_id.attributes. This is why using state_attr is suggested
Yes, I am aware of that, and always write the templates in the states() or state_attr() form.
Maybe it is as with the js templates in custom-ui: only happening on templates using the state of another entity. Of course using template sensors, that is very often the case, so the search is rather endless…
It’s not from custom ui. Your errors are referencing jinja.
sure, no confusion there…
just got another cryptic one… no lead whatsoever:
2020-06-12 12:48:13 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.2881955472] Error handling message: Unknown error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/connection.py", line 95, in async_handle
handler(self.hass, self, schema(msg))
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 265, in handle_render_template
state_listener()
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 253, in state_listener
msg["id"], {"result": template.async_render(variables)}
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 228, in async_render
return compiled.render(kwargs).strip()
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 1090, in render
self.environment.handle_exception()
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 832, in handle_exception
reraise(*rewrite_traceback_stack(source=source))
File "/usr/local/lib/python3.7/site-packages/jinja2/_compat.py", line 28, in reraise
raise value.with_traceback(tb)
File "<template>", line 4, in top-level template code
TypeError: 'NoneType' object is not iterable
why even bother logging this without source of the error, or a direct link to the websocket_api.http.connection.2881955472 which, as far as I know is untracable either?
btw, I think (hope) to have found the culprits for the earlier attributes error, a set of rather complex template sensors:
frontdoor_schedule:
friendly_name: Frontdoor schedule
value_template: >
{{state_attr('sensor.hue_schedule','119').conditions[3].value}}
#{{states.sensor.hue_schedule.attributes['119'].conditions[3].value}}
have 13 of these, so there you go…
Try checking your Lovelace config as well. I use my card-templater custom card in several parts of mine and found I had a few uses of attributes that I needed to replace with state_attr to make the errors go away.
Stop looking at the top of the error. Look bottom up always. It’s a stack. This is how errors work in python.
Your issue is that you’re iterating through an object that doesn’t exist on startup. So look at for loops with at least 4 lines where the 4th line is performing the iteration.
1 Like