I could understand using a range if you thought that the trigger just didn't work for specific times, but I don't understand why you'd want to add a condition, who's only function is to stop an action triggering outside of a time range.
As far as I can tell, the problem is the rule triggering in the first place....
@bobbles: the IF testing really shouldn’t be necessary, he is just trying to run straight actions. RM4 doesn’t require to have conditions as part of the rule.
@ThinkSta: can you enable the logging for tiggers, events and actions and open a second browser window with the log open to see what is happening at the time the trigger should fire? Post a screenshot of the log window here and we should be able figure that out.
As stated above, this isn't necessary here. You don't need conditionals in Rule actions at all, so the ones provided by the original poster should simply run whenever the trigger fires. This is exactly what you can do if you don't need to test for anything. (Many examples have conditionals for two reasons: first to replicate "actions for true" and "actions for false" from older versions of RM, and second because often your trigger is a sensor "changed" and you want to test for which state it changed to, say when motion active does one thing and inactive another.)
From their description, it sounds more likely that the hub time is off and perhaps the trigger never fires for that reason. Enabling logging as suggested above is one way to try to pinpoint this, but I'd also add manually checking the hub time shortly before and after the expected trigger time to see if that could be the case. If it is, is the time zone set correctly in Settings? If it is and the time just drastically drifts away, you may have a different problem Support may need to help with.
In addition to the test not being needed at all, you also don't need a range for time. If one has this condition:
As you can see it was true. You can have Time of Day conditions that are true for exactly one minute, the minute specified. Or you can have between two times, and that is true from the first second of the first minute to the 59th second of the ending minute.
So it's just gone 6am, and the app hasn't triggered. Here are the logs showing motion detection & IFTTT before/after 6am:
This is the rule as it currently stands:
And this is the time:
(although the first time I loaded the settings the time was wrong, pressing "Update from browser" corrected this)
Hi all. Whilst I appreciate the IF - THEN SHOULD NOT be necessary, and indeed I have rules that are built very similar to the OP's rule, I was offering something to try to see if he could get it to work.
I notice that this has not been done yet. It would be interesting to see if it works.
Hi bobbles,
I really appreciate your efforts on this - thank you. In practice, we can see from my log that the rule isn't triggering in the first place, therefore there would be no opportunity for hubitat to get to the actions and conditions to evaluate.
Chris
2 Likes
Do you have logging turned on for that rule? If not, do so. Also, are you using 24 hour time?
I am also having this issue. I have multiple time triggers on a rule and only some of them fire. Even worse, trying to edit the actions generates an exception. I'm guessing that the rule editor munged something up.
As you were advised in that other topic, delete that rule and recreate it. Something has gotten hosed up. Once you create it again, show us the app status page where it has Scheduled Jobs at the bottom. We need to see if all of them are there as expected since they weren't before for some reason.
1 Like
Hi there,
Yes all logging options turned on, and 24 hour clock.
I would prefer to explore other possibilities before I go to that extent, given that it is a complicated rule and will take well over an hour to recreate.
Perhaps you could try (re)creating a smaller "test" rule like the original poster here did in the first post in the thread. If you can't get that to work, no sense in trying with the larger rule.
Please show the app status page Scheduled Jobs section, and the rule, here or by PM.
I started a new rule from scratch (even though the original was hardly complicated) that just turned on the heater at 6am. Worked a charm this morning, so have now expanded the new rule to turn the heater on, delay, then turn off. Will see if this works tomorrow morning.
If creating a new rule has resolved this issue, does this mean that even very simple rules can be corrupted or ignored by hubitat somehow?
More info about periodic triggers and the trigger editor
They are not being properly updated when triggers are changed.
For example, I had an "every 5 minutes" trigger that was working correctly. I then added a "5 and 50 minutes past the hour" trigger and deleted the "every 5 minutes" trigger.
The rule is still triggering every 5 minutes, and the schedule jobs table shows:
periodicHandler 2019-08-21 4:50:00 PM EDT 2019-08-21 4:45:00 PM EDT PENDING 0 */5 * * * ? *
Furthermore, the trigger editor now generates an exception so I can't edit the triggers (despite the 5,10 trigger showing in the trigger list).
java.lang.ClassCastException: null (selectTriggers)
A clone of the rule has the same behavior (can't edit the triggers). When first created it has no scheduled jobs. Interestingly, at first the "run actions" button was not visible, but when I turned on logging for the rule and reloaded the page, it appeared. This also apparently caused the correct 5,50 scheduled job to appear, and the trigger is firing properly -- but still can't be edited.
We don't know what happened to your rule. The answer to your question is no, but there is always the possibility of an unresolved bug.
Did you hit Update Rule or Done after making this change?
If you clone a broken rule, the clone will be broken. So this is not a good plan. Whenever you create a clone, it will not have any scheduled jobs or event subscriptions until it has been edited and Done hit.
"Did you hit Update Rule or Done after making this change?" -- Pretty sure I hit done and returned to the main page for the rule.
"If you clone a broken rule, the clone will be broken. So this is not a good plan. Whenever you create a clone, it will not have any scheduled jobs or event subscriptions until it has been edited and Done hit." -- Well, I was experimenting to determine the scope of the problem. Note that even though the rule is "broken" and the trigger can't be edited (I updated to 2.1.4.119) it is triggering correctly (after doing something like selecting the actions but then backing out). So whatever is preventing the trigger editor from running is not preventing the trigger from being triggered.
