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
ok I will Steven, not using card-templates myself, but do use some jinja templating… in Lovelace cards (Markdown, template-entity-row)
I was able to adjust the markdown :
style: |
ha-card {
background-color: transparent;
box-shadow: none;
font-size: 15px;
font-weight: 300;
}
ha-markdown {
padding-top: 1px !important;
padding-left: 1px !important;
padding-bottom: 0px !important;
}
type: markdown
Since upgrade to ver. 111 the history cards behave strange. Eg. If I add a history card for a binary sensor it shows me the correct history status:
Then, if I refresh the webpage (SHIFT+click on refresh) the history card will transform into:
Basically the active (green) status is gone (all active statuses are gone).
This is happening in latest version of Firefox 77.0.1, but also in other browsers eg. Opera/Chrome.
Is anybody experiencing same behavior maybe?
Thanks.
could this be it:
{% set player = 'sensor.plex' %}
{% if states(player) != '0' %}
{%- for attr in states[player].attributes %}
{%- if not attr in ['friendly_name','unit_of_measurement','icon','entity_picture'] %}
{{attr}} is watching {{states[player].attributes[attr]}}
{%- endif %}
{%- endfor %}
{% else %} Watching Plex: {{states(player)}}
{% endif%}
nope, the error indicates that the object you’re iterating through is None. Attributes is always a dictionary. If it exists, it can be iterated.
hmm, only other for I can find (with a non existing attributes.source for now, thank goodness) is this:
{% set km = states('input_number.quakes_near')|float %}
{% set location = states('input_select.quakes_near') %}
{% set ns = namespace(count=0) %}
{% for s in states.geo_location|selectattr('attributes.source','eq','usgs_earthquakes_feed') %}
{% if distance(s.entity_id,location) < km %}
{% set ns.count = ns.count + 1 %}
{%- endif %}
{% endfor %}
{{ns.count}}
should there be a guard here too? which isn’t too obvious using a for loop…(sorry for misusing this thread, promise to take a next one to a dedicated one, apologies)