Yes, I’m just noticing that myself. (I have a checkout of the dev branch I’ve been testing this on. Also discussing this in another forum topic.)
It’s looking like this is the right thing to do…
Assuming you have my sun.py component in custom_components, then try this:
cd custom_components
sudo -u homeassistant mkdir sun
sudo -u homeassistant mv sun.py sun/__init__.py
sudo -u homeassistant ln -s /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/automation/sun.py sun/automation.py
Then restart. Also note that you may need to adjust these instructions depending on how you installed HA and what version of Python you’re using.
The idea is to turn the sun.py module into a package, and then to make the automation’s sun platform part of this package. (I do it here via a symbolic link, which should automatically “pick up” new versions. But you could also do it by copying the file.)
If you try this, please let me know how it works for you.
Can you copy the file? If not, can you get it from github?
I haven’t thoroughly investigated yet, but the new loading system seems to be having trouble with automation’s sun platform (i.e., <homeassistant>/components/automation/sun.py) when there is a custom version of the sun component. It wants the custom sun component to be a “complete package”, including automation’s sun platform. Without it there are errors and/or automations with sun triggers might be silently turned off.
Sorry, not following you. Triggers and conditions are two different things. Triggers control when the automation action(s) should run, whereas conditions control if the action(s) will run when one of the triggers fires. The last_triggered attribute just records the last time the action(s) were run, whether due to trigger/condition processing, or by the automation being manually triggered (via the automation.trigger service.)
Exactly! Last_triggered doesn’t record the last time the automation was triggered, but the last time actions were run.
I had an automation with a condition the last_triggered of that automation needed to be >120. Since that condition was never met, the attribute last_triggered was never set. And the automation never ran. Catch22
Moving all conditions to the action part solved the issue, and now all runs perfectly well.
So the attribute last_triggerd should really be called last_action_ran…
I always expected the attribute to be set on triggering of the automation…
this solution has another great advantage: one can check the conditions upon manually triggering. With the condition in the condition part of the automation, manually triggering would jump over the conditions to the action part immediately. Moving these conditions to the action part, evaluates these conditions too, so one can see if the automation works as designed…
Ah, ok. I understand. Yes, this isn’t the only place where terms are overloaded in HA. “State” and “trigger” are definitely two terms that have multiple meanings depending on how they are used. “Attribute” is another one.
Sorry Linux isn’t my area of expertise…
I looked up ln and I am guessing that in lieu of creating a link you want me to take a copy of the HA file sun.py from GitHub and put it into my local custom_components/sun folder?
So, yeah, I can do all that. The concern I have is how I will know when/if I can put it all back to how it is ‘supposed’ to be. And if I can’t what happens if the core sun.py component is ever updated?
Something seems to me to be not quite right with all this…
(And I don’t mean your custom component.)
For custom components, this is now how it’s “supposed to be.” They purposely decided to make using custom components more complicated. They thought it was a good idea, but I suspect they didn’t realize how much of an effect this would have. But, it is what it is, and hopefully it will be better in the long run (which I’m sure was the thinking.)
First, I tried to update the standard sun component, but it was rejected. They don’t want to update it anymore. They want to replace it, but nobody has signed up to do that AFAIK. (Look back in this topic and you’ll see what I’m talking about.)
But, if you ever want to go back to the standard sun component, simply delete the custom_components/sun folder and restart. Presto magico, you’re back to the standard sun component!
I know this isn’t a great situation, but it’s due to the “great migration”, and there’s not much I can do about it, other than try to figure out how to deal with it.
Sorry to labour the point but if it is important which version of HA I am on, what will happen when I next upgrade (he says, wondering if it is sometimes a misnomer )?
The funny (“funny” as in “sad”) part of this is the automation sun platform doesn’t actually use the sun component! Both the sun component, and the automation sun platform, use the sun helper (homeassistant/helpers/sun.py). So this is all “make work” for no good reason.
yes, I am aware of that now. My main system is still on 84.3 while my other is on 87.1 . The first doesnt ‘know’ yet, the second is lenient …so no issues just yet, not even a warning at all. Even when using the Check Homeassistant Configuration add-on, there are no warnings whatsoever. I wonder why that add-on even exists…
)?
I’ve learned a lot in this thread, one of them being I won’t update to 0.88 just yet…
But seriously, I have no idea; I don’t use hassio.