I have the same error message but can’t see any indication which template is causing it, any ideas on how to find which one is producing this ?
2019-05-28 08:06:13 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/automation/__init__.py", line 280, in async_trigger
if not skip_condition and not self._cond_func(variables):
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/automation/__init__.py", line 401, in if_action
return all(check(hass, variables) for check in checks)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/automation/__init__.py", line 401, in <genexpr>
return all(check(hass, variables) for check in checks)
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/condition.py", line 352, in template_if
return async_template(hass, value_template, variables)
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/condition.py", line 331, in async_template
value = value_template.async_render(variables)
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/template.py", line 191, in async_render
return self._compiled.render(kwargs).strip()
File "/usr/local/lib/python3.7/site-packages/jinja2/asyncsupport.py", line 76, in render
return original_render(self, *args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 1008, in render
return self.environment.handle_exception(exc_info, True)
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.7/site-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'
Haha. Thanks everyone! I’m still learning, so for me my goal is to get something working. I wasn’t thinking about optimization, but I’ll update it!
@Holdestmade - Again, for me I had two times that I was subtracting from one another, but in my case one of my values was returning “None” instead of a time since that calendar had no events on it.
To figure out which one it was I copied my entire value_template into the template editor in Home Assistant, which is down with the developer tools at the bottom of the sidebar.
Then, I edited that block removing all of the code around the two variables that I was trying to subtract from one another. So I started with:
For me, that top one (nick_calendly.attributes.start_time) was the calendar that had no events and was returning “None” instead of a time, so I added the additional logic to check for that first and return “off” if it didn’t have any events.
So to get this working I had also setup a sensor called date_time that just returned the current time every minute and was using that in my calculation for this. It looks like you have replaced my need for that using now().timestamp().
I just wanted to verify that I should be able to delete that date_time sensor all together (since it was created just to get this to work) and this template value will still update itself every minute.
Thanks for the reply but my first issue is finding which template is causing the error, I have many and everything seems to work OK, just getting that error in the log every now and then. I see from your log you have “Update for sensor.calendly_event_offset fails” but in mine it just says “Error doing job: Task exception was never retrieved”
I guess I could just go through all until I find it !
Oh yeah, sorry about that. I have no idea why your error doesn’t show the specific template like mine does. Good news is that you should be able to narrow it down to templates that have some kind of subtraction in them. ¯\_(ツ)_/¯
Found it. It was a time condition in an automation checking the last_triggered attribute and when HASSIO is restarted or just automations reloaded, the last_triggered gets set to None. Obvious now but you can’t subtract a None from a time.
Thanks for your help, I didn’t even notice the subtraction symbol in the error message, thought it was just a hyphen ! and that enabled me to look through just the subtract templates.
After a restart, an automation’s last_triggered attribute remains at whatever date/time it was previously triggered. If it was never triggered then the attribute will be set to null (which is represented for templating purposes as None).
In the following screenshot, ‘hyphen_tester’ was triggered yesterday. When Home Assistant was restarted today, the automation’s last_triggered displays yesterday’s date/time.
In contrast, ‘boolean_tester’ is an automation I used a long time ago then commented it out in the automation file. Today I uncommented the code, restarted Home Assistant and the automation’s last_triggered is null.
The only substantive difference from your configuration is neither of my two systems (production and test) use hass.io.
Production:
arch
i686
dev
false
docker
false
hassio
false
os_name
Linux
python_version
3.6.7
timezone
America/redacted
version
0.89.1
virtualenv
true
Test:
arch
x86_64
dev
false
docker
true
hassio
false
os_name
Linux
python_version
3.7.3
timezone
America/redacted
version
0.91.0
virtualenv
false
I have many automations on my test system. I create them while helping solve problems for community members, then I comment them out in the automations.yaml file. Here are three automations on my test system. Two of them were previously commented out and were uncommented for this experiment (then the test system was restarted). Those two appear with last_triggered = null.
I triggered the two automations (not manually from the Services page but via their defined triggers) and the States page shows their updated last_triggered attribute.
As per the scientific method, the existence of black swans disproves the theory that all swans are white. An automation’s last_triggered attribute can survive a restart/reload.
Now is it because both systems aren’t hass.io or is it due to something else?
If they did, it would’ve already been posted because, as you said:
Given that (based on old telemetry data) the number of hass.io users is just over half of all installations, if the issue is indeed limited to hass.io then it would explain the ‘lots of posts’ aspect. Or not. It’ll take a few more black, non-hass.io swans to come forward and shore up my theory.
I use hassio for production and a venv on ubuntu for development. Both behave the same way. I would assume it’s driven by logbook & recorder because that’s where events are stored/pulled.
For what it’s worth. I restrict recorder to only capture a small list of lights and sensors. I restrict history for the same list of lights and sensors. I do not restrict logbook at all. All 3/4 of my automations properly show the last triggered after restart. The 4th causes a restart, so i’m assuming it doesn’t capture the time… in time.
It’s not the installation flavor (venv, docker, hass.io, hassbian) but that silly remedy all too frequently recommended to everyone to fix their automation on/off woes. Namely this one:
initial_state: true
Here’s how I tested it:
I added initial_state: true to one of the three automations on my test server, restarted Home Assistant and, ta-dah, its last_triggered is now null.
I triggered the automation and its last_triggered is assigned a date/time.
I reloaded automations and, boom, the automation’s last_triggered is reset to null.
FWIW, I don’t use inital_state: true in my automations and simply allow the restore feature to do its job.
Because you drank the Kool-aid. I see far too many posts recommending it as a panacea for the issue of automations turned off at startup.
The focus ought to be on finding the cause as opposed to effectively disabling the restore feature by adding initial_state: true to each and every automation.
My test system gets restarted at least two times a day (often many more times plus reloading of automations) and I have yet to see all my automations disabled on startup. Yes, I know others aren’t so lucky but the Kool-aid solution is just a massive band-aid over the underlying problem. Plus we now know it has a side-effect (restarts/reloads purge last_triggered).
Yep you’re right, I removed initial_state from all my Automations and they keep their last_triggered attrribute. Many thanks for figuring it out and taking the time
