Unsupported operand type(s) for -: 'NoneType' and 'float'

Configuration
21

OK, thanks for trying it out, I’ve replied to the post above as it’s more relevant, hopefully someone else has an idea why !

22

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.

23

@123 @Holdestmade

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.

24

I found the culprit.

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.

25

I’ll give that a try thanks, all mine have it !
Only because I’ve trouble in the last when some automations turned off on restart.

26

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).

27

Yep, I see it way too often. I don’t use it either.

28

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