Very simple, but failed today after a minor tweak.
Turn on Xmas lights at 30 mins after sunset, which worked fine, was edited this afternoon, well before the projected turn-on time to change it to "10 mins after sunset". The change was saved properly, and no errors resulted.
The turn-off time (11:30pm) was left alone.
But the turn on failed to invoke, and I had to turn the lights on manually.
So, what's the story here? Why is Simple Automation 1.1.4 not working in the simplest case after one tiny edit? Do edits make one wait 24 hours before they start?
I wonder if the time event might have been scheduled for the next day for some reason…
Have you turned on logging? If not, that might help reveal the issue. If all else fails, post a screen shot of the full rule and any logs so that someone from the community may take a look and provide insight.
To make it easier to help you, your help request should include a screenshot of the rule in question, as well as the hub sw version (and even hub model).
You might click the gear icon while looking at the rule and see what the scheduled jobs are.
If you are wondering what an app is doing, you can always check its settings. From Apps page click on gear icon next to the app. There is a Scheduled jobs section that shows upcoming schedules, but more importantly, if the app uses sunrise/sunset you should see an Event Subscriptions section. In your case, the numerical chage is minor, and it doesn't create a new schedule when you click done. It just saves the new offset number. The app will create the schedule when it receives the sunset event from your location. To validate that the sunset occurred at the expected time go to Logs, then Location Events. If you have any questions about the app Settings, please share a screenshot of the rule in question.
The settings are all OK. Not clear why it wouldn't have run at 10 after sunset, assuming the hub itself was running then. You could look at the Location Events in Logs to see if there was a 'sunset' event today.
Yes... I think there's a sunset EVERY day, isn't there?
12/07/2023 04:29:00.039 pm, which was as expected, astronomically speaking
This is what is so frustrating about this type of error, it prompts one to start turning on debug logging on something that is very hard for the user to reproduce.
Not every apparently failed automation is worth any effort to analyze after the fact. If it fails over and over, sure, we should attempt to figure it out. I've been doing this long enough to know that if I really want to find THE answer for everything that happens (or not), that with enough effort the answer may be uncovered. But at some point, the effort is just not worth it. Nothing is perfect in the real world. Is there a bug in Simple Automation for this? Probably not. Is there some deep failure in the hub going on? Probably not. Does that explain what happened? No.
Well, it also failed to turn off last night.
So I turned it off from the device settings, and turn on the logging in the simple automation app.
Here's the problem - I'm still playing with this, trying to make it work for use in 3 homes, 2 which will be unoccupied, and only weekly or so visited by a housekeeper or caretaker in our absence. I've been messing with this for YEARS, through 2 models of hub device, and I'm still scratching my head over things like this.
Given the official statement of position from someone writing the basic firmware, we clearly need both (a) better logging, so we can debug this kind of thing (b) a more aggressive approach toward making the product more reliable. What good is buying watercops and water sensors and installing them all if a simple rule that says "if water is detected, shut off the water main" FAILS? If something that basic cannot be relied upon, then Hubitat is in the toy business, and I am wasting my time trying to automate anything, and need to go back to leaning more on the caretaker to "open" and "close" the house for us.
Perhaps it’s the device, and/or the signal reaching the device. I’ll give my own example, which does not have to do with signal, but the device.
I pulled out an outdoor TP-Link Kasa plug to use with the Christmas lights. Just for a month, so why not use the schedule in the Kasa app right? It had all the settings I needed and even supported sunset offset time. Well it worked once and wouldn’t work again. So I instead added the HA integration for TP-Link Kasa and then brought the device entities back to HE with HADB and setup an HE Basic Automation. It’s worked every day since.
Obviously my example is a software failure on TP-Link’s side, but if it were Z-Wave or Zigbee, a mesh issue could potentially also be the cause.
Whoa, I think you missed my point completely. I didn't make any "official statement", I shared my experience.
You might move this automation into Rule Machine to get much greater refinement of control and logging. It can be imported directly with almost no effort:
This is a good thing to consider, but I've been using the same outdoor Z-wave switch, part of a set of 3 for several years to run lights out by the pool (they have worked flawlessly), and I moved one to serve as the Christmas lights relay.
The location of the relay/outlet is right at the front door, so only a few feet from another Z-wave device, which acts as a strong repeater (A Greenwave PowerNode). The Z-Wave stats on the relay are decent:
So, I can't blame the device, as it is much closer to other Z-Wave devices in its Christmas location than it ever has been out by the pool, so signal strength and connectivity can't be it.
No, there's something going on in the code we can't see - somehow, editing a simple rule trashes that rule for some period of time, or makes it forget what it was doing like an owl tapped on the back of the head with a forefinger.
I'm fairly certain your specific assessment is not true, given years of experience in thousands of hubs with this particular app. But, a failure is still a failure. The advice above to remove it and create a new one is not bad advice. It doesn't answer the question of what happened or why, but if it fixes the problem then it's good advice. It is possible that there is some glitch in your database, and that some of the connectivity for that app is messed up. If that is the case, then creating a new instance of it would fix it.
There is 1 thing to note about going to a RM rule via import. Rule Machine uses a time trigger for the first action with a 'wait' for the second. If the rule is set up after the trigger, the second action won't run for a day. Simple Automation subscribes/schedules both 'on' and 'off' actions. SA works how probably most people think a schedule should work, so a move to RM requires understanding how it works as well.
Yes, that is as one would expect - but changes made to the "on" parameters between the most recent time-driven "off" and the next time-driven "on" should not cause any hiccups, as the change was made AFTER the "off", and well before the next scheduled "on".
But for whatever reason, it didn't do as expected. If its a bug, it will be back, but I do nothing to help diagnose, as I am simply eliminating "simple automation" entirely, as it dared to look at me cross-eyed, so it is gone.
I've got several that have worked for years. I prefer SA for simple on/off schedules. Not sure what your issues are, but I'd suggest doing a Hubitat backup followed immediately by a restore of that backup. That action cleans up database corruption. If that doesn't work I'd suggest deleting and re-creating your SA automation.
So there is no integrity check one can non-destructively run?
No way to dump out the tables, and get a copy of the schema?
A database going gooey could explain lots, and is not confidence inspiring.
