I know that heading might be confusing but here's what I'm running up against: I have rules (had them in Rule Machine Legacy and Rule Machine) that trigger based off of Mode changes (I imagine most of us do). Several weeks ago, I noticed that not all of the actions were completing. It always seems to revolve around smart outlets and only mode changes that happen automatically via Mode Manager (timed, sunrise, sunset, etc.) - everything else is fine.
I am one that has had the Peanut plugs and used them for years, before finding out a couple of years ago that they caused issues. I have officially replaced them all (I had a few left as of a month or two ago and pulled the rest out when I found my Zigbee network offline - presumably due to one of them going rogue).
I had a mess when it came to rules. I first assumed that maybe this issue was happening because I multiple rules being triggered by the same event, so I merged them all together (splitting some out into multiple rules in some cases so now I only have one rule firing per mode change). For example, maybe I had a switch turning on when the mode became Day or Evening and then I had two other rules, one for mode becoming Day and another for mode becoming Evening. I now only have the two individual rules (I moved the first rule's actions into the other two and deleted it).
I also had a mix of Rule Machine and Rule Machine Legacy, so I migrated all rules from Rule Machine Legacy to Rule Machine and removed it.
Mode Manager Legacy was disabled but still there so I removed it as well.
I thought all of this cleanup had fixed things but I still have problems with these Centralite outlets, specifically, not turning on when triggered by an automatic Mode Manager mode change. The rules trigger fine when clicking "Run Actions" or even when changing the mode by hand in a dashboard. Other actions (changing virtual switches, turning on/off thermostats, etc.) seem to be fine but I can't say that for 100% certainty. I just haven't noticed those actions not completing whereas the switches are almost if not 100% daily.
I looked around as best I could on the community and didn't see anything like this and I also thought about posting this in the Mode Manager topic, but I wasn't sure that was the culprit either.
I don't know what else to do to try to fix this. Any thoughts?
Enable all logging on the rules in question, and see what you find in "Logs." In short, there's a claim here that Rule Machine isn't working, but there's a good chance there's an issue with the device/network or Rule logic itself, and this will help you figure out where the problem really is (including possibly the rule if there are no logs at all or something unexpected in the,, but logs will give clues as to where to start).
Good point and I've done that for the 4 rules that get triggered on each of the mode changes.
I probably should have noted that I did look at the devices themselves and I could see some things in the logs that might be telling. Right now I'm focusing on my "Day Rules" rule:
Mode Manager changes the mode to "Day" at sunrise or 7am, whichever is earlier. All of the actions are being sent, but the first one ("Bubbles Light") isn't completing. You can see it on the Device page in the "Events" where the command was sent, but it wasn't turned on:
The two events at 7:17 were me manually changing the mode to "Night" and then back to "Day" and as you can see, the command was sent and the outlet responded.
I have never had it not work when I was doing it manually via dashboard (when I get home this evening, I'll try it about 5 or 10 times and can report back) but it never works at 7am lately. It's like there's a difference between a manual change and an automatic one driven by "Mode Manager".
Before I made the changes I described earlier, it was always my "Night Rules" that didn't work. Now it's plaguing the "Day Rules". "Evening Rules" and "Away Rules" seem to work perfectly.
You have not provided any logs for the rule (or device, though the rule is likely to be more interesting at this point in the troubleshooting process). To be clear, I'm talking about the Logs page in the UI, and likely Past Logs once you get there, unless you happen to have had live logs already opened at the time when the entries were generated. You can filter by app (e.g., this rule) or device, and I would to make it easier.
But "Events" on the device, which you did provide, is a bit more interesting in recent platform versions than it was in the past--not only does it show events (as the name suggests) but also commands that were sent to the device and what app did it. So, while we can't see all the details (again, Logs are helpful here), it does appear that your rule sent an "On" command to this device, as you'd expect based on your rule actions.
Therefore, I don't think you're dealing with a rule problem here, at least for this specific thing. If you're sending an "On" command but the device isn't turning on, you are dealing with a device or driver problem.
In this case, I'd start by seeing if commands work as expected when run manually from the device detail page. You can also make sure you're using the best driver for this device (probably Generic Zigbee Outlet if this is the Centralite device you mentioned?), and if "Current States" don't update as expect (which shouldn't affect this but could affect your later actions that have the "command only if on" option enabled), try running "Configure" to see if it helps.
Also, since we are probably dealing with Zigbee: any smart bulbs on this Zigbee network?
Yes, sorry. I have a hard time distinghishing between "Events" and "Logs" sometimes. It's all essentially logs to my IT brain Here is the "Logs" output for the "Day Rules" rule from this morning (not really much we didn't already know from "Events":
The logs for the device itself tell a similar story (it's like the command at 7am wasn't received on either day):
Agreed, I don't think it's a rule problem. It seems to be more "Mode Manager" related, to me. Commands to the device when run manually work fine every time. It's not like with the Peanuts I had where sometimes they just wouldn't respond. I'm not having any issues with manual actions not completing.
Manual mode changes work fine as well. You can see in the "Logs" output above that the "Day Rule" rule was triggered twice. Once by automatic "Mode Manager" change at 7am and then I changed the mode manually at 7:13. The rule fired fine both times but the switch only came on the second time (same as yesterday - per the "Events" screenshots above).
I do have one other possibility - could it be two rules triggering at the same time? The only two I notice having trouble with are my "Day Rules" and "Night Rules" which fire at sunrise or 7am, whichever comes earlier (so 7am currently), and 10:15pm, respectively.
I also have another rule that fires every 15 minutes and does refreshes of various sensors.
Could the two be butting heads?
I fired both the "Night Rules" and "Day Rules" 3x this morning manually (via manual mode change) and all actions completed perfectly. It has to be something with the timing of the automatic runs or the automatic runs themselves.
Eeek! I'm not sure about that particular generation, but many Osram/Sylvania bulbs are, like many Zigbee bulbs, reported to be problematic on Zigbee networks with non-bulb devices in that they try to repeat but do so poorly, dropping messages they are supposed to route. This can cause hard-to-troubleshoot problems with other Zigbee devices. See the "Tips..." section in the How to Build a Solid Zigbee Mesh | Hubitat Documentation for more tips but also a note specifically on bulbs.
There is a lot of guessing going out without a lot of logs to support these claims (and again, actual logs from the Logs page are what I'm talking about; looking at Events can be useful, but Logs will generally have more information, especially for apps that usually do not create their own events). This document may be helpful for general troubleshooting tips:
Along those lines, if you suspect there is a problem with Mode Manager, I'd enable logging for Mode Manager and see what they say. If Mode Manager successfully changes the mode to Day (or whatever you're looking for), I'd say it can be ruled out as a problem. Its only role is to change mode; it is not responsible for triggering other apps.
If logs or command history suggest that your driver is sending an "on" but it's not actually turning on, you are almost certainly dealing with a device or mesh problem--and if these are Zigbee devices, I wouldn't be surprised if bulbs on the network were culprits.
That does seem to be what the logs say and I trust you but I don't understand why would I be having zero issues with any devices aside from these two rules?
I have seen my Zigbee network go awry before (with the aforementioned Peanuts) and that's not happening here. When those were causing issues, I'd ask a device to do something manually, via automation, via Google Home, etc. and it might reply or it might not. Many times the status would be wrong too (it would be off and say on, etc.). Is that what you would expect?
I even have other mode-based rules that work with these same devices and they fire properly 100% of the time ("Evening Rules" which triggers 30 minutes before sunset always turns on the same lights that "Night Rules" turns off plus one or two others) and it is having zero issues.
I'm not trying to argue I'm just trying to understand and figure out the pattern between what works and what doesn't.
I will review the logs (not events) in more detail in the morning. I commented out some debugging statements from a user app (that didn't have the option to disable them) so they will be a little less cluttered and easier to review.
I'm just making (educated, I hope) guesses based on the information provided, so I don't really know either--just trying to point you to more things that might help. The problematic behavior you described before is certainly a clearer problem, but Zigbee bulbs won't necessarily cause consistent failure, just occasionally dropped messages. So yeah, it shouldn't be just this app, but it could just be coincidence that it's all you've noticed so far (and maybe it's controlling more devices or doing so more quickly in a row compared to other apps or you doing it manually, which could make the luck worse).
In any case, logs are usually the best tool to know where to start troubleshooting, so hopefully they'll give better clues!
So I changed the "Device Refresh" rule I mentioned earlier (instead of every 15 minutes I specified minutes 14, 29,:44, and 59) and last night and this morning, both "Night Rules" and "Day Rules" completed all their actions. I know one day does not a pattern make, but it does seem the two have a hard time running simultaneously.
I suppose that could be more evidence that the Zigbee network isn't 100% or it could just be that I shouldn't try to refresh so many devices all at once.
At any rate, here are the logs from this morning with logs from the "Device Refresh" rule and from the "Day Rules" rule (not that this will tell us much since all actions completed just fine):
If your Zigbee devices are sometimes unreliable and you have these bulbs on that network, I'd again mention that they would be my first suspect for the cause of problems. But even on a "normal" network, I sometimes find it better to space commands farther apart when dealing with lots of devices at the same time (this being the meaning of "metering" in apps that offer this option, though new apps are unlikely to offer it, given improvements in serial processing on the Z radios on the hub that we've been told should make it less needed).
For Zigbee devices, if you put them in Groups and Scenes (a group) or Room Lighting, you can also enable Zigbee group messaging, which should also cut down on traffic if the command to all devices is the same. Just a few other ideas!
Maybe once or twice I promise I will take a look at them but honestly (and I'm surprised by this by what I've read in what you posted above), they've given me no trouble. I've had them for a couple of years and they've worked great and, once I got the Peanut plugs removed, everything else has as well (until all of this I guess lol).