Simple Automation Rule just stopped working

app:492023-12-13 23:59:00.202infoact: anti-Turn On

app:492023-12-12 23:59:00.146infoact: anti-Turn On

app:492023-12-11 23:59:00.112infoact: anti-Turn On

app:492023-12-11 16:59:00.224infoact: Turn On

app:492023-12-10 23:59:00.337infoact: anti-Turn On

app:492023-12-10 16:59:00.271infoact: Turn On

app:492023-12-09 23:59:00.124infoact: anti-Turn On

app:492023-12-09 16:59:00.382infoact: Turn On

app:492023-12-08 23:59:00.193infoact: anti-Turn On

app:492023-12-08 16:59:00.216infoact: Turn On

app:492023-12-07 23:59:00.125infoact: anti-Turn On

app:492023-12-07 16:59:00.256infoact: Turn On

app:492023-12-06 23:59:00.185infoact: anti-Turn On

app:492023-12-06 16:58:00.218infoact: Turn On

app:492023-12-05 23:59:00.171infoact: anti-Turn On

app:492023-12-05 16:58:00.335infoact: Turn On

app:492023-12-04 23:59:00.271infoact: anti-Turn On

There was another recent report of an existing Simple Automation that stopped working. It may be coincidence, but tagging @bravenel in case this is possibly a systematic issue

This has the hallmark of a device or mesh network problem. If the app log shows the command being issued (as it does) and the device didn't respond, then you need to dig into what is happening with the device or the mesh network. First thing to do is to test the device thoroughly from its device page.

Totally different situation.

As I stated above, all of the devices work just fine from the respective device pages. Nothing has changed in my environment at all. All of the devices work properly and I have not altered anything in the last 3-6 months (other than system updates).

In fact everything worked fine today (all 4 devices on at sunset -30).

I have seen other cases where rules start to fail due to the hub resources getting pushed to the limits. Especially found on rules with waits in them, the rule will start and then never finish. Typically this would be caused from custom apps or drivers, especially ones making a lot of IP connections. It is compounded if those drivers or apps cannot connect to the destination and keep trying over and over again.

Another possibility is that you are having a rapid decline in memory which has been happening randomly to people on 2.3.6 firmware. A database backup and restore typically fixes it, so I would suggest just trying that as it cannot really hurt anything. It is explained in this pinned post: ‼ READ FIRST - Before Posting in Get Help as well as a lot of other info and tips.

Thanks. Trying that now. Thoughts on whether this might fix the random unresponsiveness of the hub in general? Every month or so it simply "goes to lunch" and does not come back until I unplug and replug in the power. (I mostly fixed this with the daily reboot of the hub with the reboot app, but it still happens sometimes.)

Possibly, if there is any sort of issues with the database that process will clean it up when you do the restore. The lockups and power pulls may have created some database issues. Your daily reboot may also be hurting more than helping. I would at a min set it to weekly. If you need to reboot more than that something else is going on.

Will do, thanks.

One more question. I have a few rules/devices I don't use anymore, but I have them in the rules still because it was difficult to set them up and if I ever need them again, I figure having a working rule (that isn't being used) is no harm/no foul. Is this true? Should I remove them? Is there a way to save off specific rules/device types?

You can open the rule and click the show app settings and detail for the rule. The little gear icon at the top right. From there you can click export/import/clone.

Export the rule to a file and if you need it again you can import back in.

Cool. Thank you! I removed all rules and devices that were no longer being used. Hopefully that'll clear out some room too. I now have approx 19 devices and 6 simple automation rules and 3 mirror me items.

That's a pretty light load, the hub should normally have no issues with that, running for a long time. I have over 50 devices and all sorts of apps and integrations, which is still a pretty light load for this hub. I typically only reboot for updates, but am on the beta versions so have more updates than most.

It's not been reliable enough for me to count on it yet. Hopefully this export/import of the db will solve my issues.

So I did the export/import and it kinda worked for a bit and now this week the outside light rule and the foyer light rule (both of which are basically turn on a device at 30 mins before sunset and turn off the device at either 23:00 or 23:59 depending on the rule) just simply do not turn on the devices. It's a mixture of Z-Wave and Zigbee devices. ALl of the devices work from the hub if you manually choose them, but none seem to work via the rule. Am I doing something wrong? This is VERY frustrating to have something work without having to think about it for months and now I cannot get it to work consistently.

Have you updated to 2.3.7? There was significant memory improvements in that build. Then you can also do a reboot with the "Rebuild" option selected to rule out any database issues left over from 2.3.6.

Also, show us the rule.

I have seen in the past rules with waits in them fail on the second part when the hub is overloaded with poorly coded wifi drivers / apps that keep hammering TCP connections when devices are offline. Usually this generates a lot of errors logs. So it would also be a good idea to review the past logs, you can even filter it to warn and also error, to see if anything stands out.

1 Like

On 2.3.7.145. Just did another export/import/reload to be safe.

I also have a fairly complex rule that runs when I open my back patio door and it works perfectly fine. So just not understanding why these rules just stop working for no apparent reason.

I don't have that many rules. :slight_smile:

:point_down:

Check the logs as I suggested up above.

Also, you can click the gear icon for those rules, and look for the scheduled jobs. I think the way that rule is made you should have two scheduled jobs on each.