Sure would be nice if customers could rollback the updates.
Since updating new "platform updates" earlier this week noticed a couple of rules stopped working. One for example has been working fine and now, can reproduce the heck out of it.
I have a couple of zigbee outlet (switches) that I use as momentary off to turn our touch lamps off via Alexa, when cycled on, the lamps are ready to go be lit up by touch.
But this week, the outlets don't get cycled back on.
I ended up having to stick a periodic scheduler in to force the action to fire. Not a good solution.
Another rule to slowly fade a light over 2 hours after it comes on at sunset is also not triggering.
Here's a sample of the simple lamp switch cycle rule and logs showing no trigger happening.
I would suggest stating (in English, not rule terms) what you want this rule to do. From your logs, I don't see anything to suggest that it should have triggered. Your trigger (one of them, anyway) is "NicoleLamp turns off," which I do see happening once--but because of your required expression, this will only count as a trigger if JimLamp was off, which it must not have been at that moment because the required expression was false (or NicoleLamp, but you're unlikely to get an "off" event when a device is already off, so this already looks a bit weird to me, which is one reason a description might help).
The only thing I can see here is the required expression becoming true. A required expression becoming true or false does not do anything per se (e.g., it will not trigger the rule). A required expression must be true at the moment of triggering (or just before, meaning that some trigger events may cause a state change and the state that matters is the one it was before/at the time of the trigger event, not after).
More specifically: because your required expression states that either of the switches must be off and apparently neither were (because the required expression was false), this switch turning on won't trigger the rule, as the required expression was false. Note that it became true shortly after the "off" event (as expected, but again, this doesn't do anything on its own, and it's the value at the moment of triggering that matters for the required expression).
So, if you explain what you're looking to do, perhaps someone can help you come up with something that works.
For your second rule: I don't see a screenshot or description of that one, but you might just want to go in and hit "Done" to re-initialize subscriptions for the rule in case that's the only problem. Otherwise, leaving logging enabled and seeing what happens when you expect it to would be a good first step (hint: look at the App Status page and the "Scheduled Jobs" section to make a good guess as to when this should be...and if you don't see anything at all there, it's definitely a problem).
My screenshot does show that the requirements are for "if any" are off, and it does evaluate to True. That shouldn't block the trigger. Or am I fuzzy on this?
I think the logic makes sense, but what I've just realized is that if I remove the requirement condition, the trigger will fire fine.
Maybe I'm wrong, but I assumed having a "requirement" for each could lessen the load of what rules needed to be checked with each loop.
The original rule was simply a requirement and action, and it used to work. not sure which revision that stopped working.
What I would interpret that pictured rule as doing is IF any are off, to watch for the light to turn off. That seems contradictory to me. I don't see how this ever worked correctly.
The second rule I intentionally didn't include here, to keep the noise level down.
But it's straightforward also. I went ahead and enabled logging, will see how that goes tonight. This rule has been in effect since Oct 2021 and never not worked until yesterday's update to v2.3.1.140.
Gah, I restored the rules from 3/26 just to make sure I wasn't wrong about that original setup for the requirements + action (no trigger); turns out I had a trigger if off+action in the Legacy Rule Machine, and must have consolidated them into that rule above.
I was wrong about the lamp rule not having changed, SORRY gang !!!
For my edification, a rule with a requirement condition, NO trigger, and action, will never fire the action? Is that right?
As for the other mentioned rule, I confirmed the chandelier dim over time rule has not changed (it's' a rule-5.1) ... logging has been enabled per @bertabcd1234's suggestion , will see how it goes tonight.
*UPDATE: revised lamp rule working fine... again I apologize for my confusion
BUT TIL (today I learned) can restore old revisions
You're correct, but that text only updates on page load or refresh, so it doesn't necessarily reflect the current state. Your logs show it was false during the only event I see that would have triggered the rule, hence no real trigger. (Also, it's important to be careful if your required expression and trigger both deal with the same event. I think the most useful case here is when they are meant to capture a specific state transition, and generally the former and latter would be specified for different values then. I can see some cases where your rule as written may not trigger when you expect because of how these interact, but it sounds like you have that figured out now.)
What loop? With a periodic trigger, I suppose you have something like that, but it's generally better just to respond to events as they happen, which it sounds like you've again figured out, so you shouldn't need that. Otherwise, the rule isn't constantly spinning and evaluating things--it just wakes in response to subscribed events (like triggers), scheduled jobs (periodic triggers, delays, repeats, etc.), or so on, in case that is what your were thinking.
Don't get me wrong. I'm an advocate and pusher for HE, I have two at this house: one at a rent house, and maybe another to come to augment the ISY at the other rental that's chock full of Insteon devices. (Yes, am aware of Insteon kerfuffle).
Prior to posting this, I was reading a 2020 post of somebody asking for the ability to apply updates offline, so I was admittedly a little pre-triggered. I wasn't aware of, the Diagnostic path Restore previous version , which IS a workable option, but having the file on my own storage would be preferable. Also, I was unsuccessful at resolving anything @ the /hub/advanced/<download###>. But, all of that's another topic.
