Lots of rules broken after 2.3.4.119

This happened to me as well when upgrading from .117 to .119 last night. No broken rules on .117 but after going to .119 at least four were broken with an added line in the rule that said broken condition where there was nothing before (i.e. 1 simple condition became 2 where one said broken 'OR' original condition).

Rolled back to .117 and restored previous database and all is fine. Guess this is the first update I will be stopping any further updates since everything is working as needed.

restored to .117 .. there is no first trigger in that rule.. will restore backup.. update rule and try update again.

could it be that that device is autorefreshed on hub reboot. and the broken rule checking is running at the same time the refresh of the device or trigger occurs?

1 Like

This thread made me look (thanks!), and I found one broken rule on .119 - it was most definitely not broken before update...

119 added 2 ghost triggers to a rule that only had one trigger. I removed the 2 broken ghost triggers and all seems well again.

Very strange.

2 Likes

I also had broken rules going from 117 to 119. I found it only happened to rules that had Bond devices as triggers. If the rule had 2 Bond devices, I ended up with 2 additional broken triggers. If the rule had 3 Bond devices as triggers, I ended up with 3 additional broken triggers etc.

I just deleted the broken triggers for about 8 rules. All is well after that.

It found what it thought was a broken trigger. It could be that you had a prior trigger that you removed, and it left a remnant. Please show me from Application State 'capabstrue'.

It's easy to fix a broken trigger, just delete it.

1 Like

For any spurious broken triggers, just delete them. I will track down where this is coming from, with a little help from you guys.

If you find a broken trigger, please post for me from Application State on the App Status page, the line for 'capabstrue' @hydro311

1 Like

same issue.. just updated and it has the broken additional trigger again.. in .119

Is this the same one you posted above? Please post a screenshot of the Triggers.

yes. the trigger was just the one trigger in .117 and it now shows two triggers. with broken again.. i dont think i have a power fail switch device. not sure what that is..

maybe a remnant of a different device handler?

1 Like

Yeah, it can't find a device called 'FR Extender (Power Fail Switch)'. Did you used to have that name for that device?

no i did not.. .. not sure what it is.. but will remove the trigger. guess it was always broken like this even in .117 and just now showing..

thanks for your help

1 Like

Right on -- I already deleted the 2 blank/ghost triggers .119 added, but here's that line for the affected rule...

Like Kahn's, my 2 added ghost triggers were included with "OR"s -- not sure if that matters or not

1 Like

Yeah, before it just didn't show non-existent devices. That didn't work out so well for those who choose to remove devices without cleaning up apps. Hence, the move to show them. That non-device was lurking in the rule.

1 Like

Too late, you already fixed it.

1 Like

i am thinking it was not really a non existent device but a switch on this device if you look closely.. thinking in an older version of the device handler it had that switch that would flip on power outage, but at some point i changed to this version (I think to be able to do range test) and the switch capablity disappeared and i forgot to change the rule...

Hence the lingering issue..

thanks again.

Interesting, and since before it suppressed the missing device/trigger, you never knew it was still there.

1 Like

You can safely use 119. Just remove the broken conditions and all will be fine.

2 Likes

Bruce, perhaps this helps.

Broken Rule Triggers

and, as you requested, some state info:

App State info

Your suggestion to open the rule and Done out didn’t fix.

Discussion:
C7 with 2.3.4.119, never ran 2.3.4.118, never hit “Find Broken Rules”.
The two broken triggers appeared with 2.3.4.119.

Looking at the capabstrue, capabsfalse, I believe I see what happened, if it helps. The rule is monitoring presence sensors for our cats, using the SurePet cat door integration ported by Dominick Meglio. It turns on the patio chandelier on our enclosed patio if any cats are outside at night.

There was a period a few months ago when SurePet’s cloud server went bonkers, inoperable for days. For reasons unknown to me, the integration (or Hubitat) decided to delete the two presence devices (one for each cat) during this craziness. I simply fixed (or so I thought) the broken triggers and actions when the cloud server stabilized (it happened twice). I believe the missing triggers are identical to the last trigger.

I realize it’s a simple matter for me to delete the broken triggers (or even recreate the simple rule). I’ll hold off fixing things if you need any more info.

It’s no big deal. Thanks for the diagnostic that something was amiss. The rule still works fine.

You can just remove the broken triggers.

1 Like

That fixed it and removed the BROKEN indicator.