User Mistake with Device Removal

We are unable to properly remove the OR operator within a RM trigger after removing a device. It's a big inconvenience as it forces the user to recreate rules in order to keep things clean. Can please get this fixed in the next release? I have included screens shots.

1 Like

This has been reported before. See, among others, here: Orphaned Trigger Events. Staff have not commented on whether they plan to address this issue, but it is cosmetic only and has no effect on the rule. (I'm guessing it's one of those things that is more difficult to "fix" than it is worth.)

It is not. :slight_smile: Again, it is simply a display issue. If this bothers you, there are two solutions: recreate the rule, or look at the "In use by" section for a device before deleting it (and remove it from any rules--or at least triggers--beforehand).

1 Like

It's UI bug. There is no way to reset the view back to default. Can we please get this fixed? I would appreciate it.

We don't know staff's plans, but I really doubt this cosmetic issue in an advanced tool rises to the top. What I've posted above plus whatever else you can find with a search is all we know. I recommend taking one of the two suggestions to avoid this problem if it bothers you.

1 Like

I'm aware of the other options just don't want to use them as they are work arounds. Let's just fix the root issue. Removing devices will continue to happen in the future, we need to be able to easily update corresponding rules.

There is no direct way for an app to know that a device has been removed, and to "fix" itself. When you remove a device, it gives you a warning about the apps that are using that device. This is your indication that you need to edit those apps to remove the device from the apps before you remove the device itself.

Consider this trigger:

Temperature of Average Indoor Temp(77.442) becomes < Outside Temp(56.32)

Now, suppose you remove the Outside Temp device. How could the resulting trigger possibly be corrected or used?

It is up to the user to fix apps that use a device before removing a device. Failure to do this can have unpredictable results for those apps.

6 Likes

I get what you’re saying, but that OR can hang around, even when you completely remove the triggers. I know it doesn’t harm anything, but it bothers me as well. I will rebuild even really complicated rules when that happens to avoid seeing that OR oddly hanging out above a single trigger. It’s obsessive, I don’t deny that. I can rationalize it till the cows come home, but it doesn’t bother me any less after all my careful consideration. :wink:

2 Likes

This isn't true. If you remove the trigger for the device that is going to be removed, the OR disappears. The only way you get the stand-alone OR is to remove the device before removing the trigger.

When you put devices into apps, you are programming a system. If you build a program based on a, b, and c, then remove b, you can't possibly expect the program that depends on a, b and c to be right anymore. You're the creator of that program. It's up to you to change it prior to ripping the guts of it out through some other mechanism -- namely, before you remove b.

The documentation for Remove Device should make this very clear. If there are any apps shown under In Use By on the device page, those apps must be fixed prior to removing the device. We don't enforce this, although we could. In some cases, just ripping out the device is ok, but its up to you to know when it's ok and when it's not. Ripping out a device used in a trigger is not ok.

2 Likes

Fair enough, but sometimes a device could fail. That leaves the user with no option but to rebuild the rule or live with the OR. Difficult to remember all the steps in order when one is already stressed about things like Z-Wave devices that refuse to join properly. Plus our angst is heightened with all the ghost devices we are probably creating in that process. But what else do you do? We need these things to work, and sometimes it’s just not easy at all. Not anyone’s fault at Hubitat, just the sometimes ugly nature of the beast. This is all supposed to be fun, but I can definitely empathize with the stress one can get from it, especially when encountering multiple issues at once.

Also, I do recall this happening when you clone a rule and try to replace the trigger, if that even works when attempting it. On several occasions, that’s just given me a 500 error with older rules versions and the rule could no longer be opened at all, but that a whole different issue.

Is it not a reasonable that the software might someday be able to automatically remove devices and their orphaned operators for rules? Perhaps, when removing a device, flagging the user that the following apps must be repaired and saving a report to make that task simpler?

This is not true. Add the new device to the system, then edit the trigger event to use the new device. Then, and only then, remove the failed device.

No, this is not reasonable. This would take a huge amount of intelligence, to understand what the person who set the rules up intended. That level of intelligence is far beyond the scope of this system.

IF((a OR b) AND NOT c) THEN

If you remove the device b, and and a new device b2, how can you possibly expect an app to figure out what it meant when there was a big hole in a complex expression?

The fix for this is in the documentation.

1 Like

When I replace a device, here are the steps I take:

  1. Add new device.

  2. On old device page, click on each link under In Use By. In that app, find the use of the old device, and edit it to use the new device instead.

  3. When the In Use By list for the old device is gone, remove the old device.

2 Likes

You misunderstand me perhaps. I’m not expecting AI, but if I can look a devices details and see which rules it’s used in, why couldn’t the system pop up a notification that the following rules will be affected when removing this device (when I try to remove it) and tell me to see a report? It’s already known in the devices details that it’s been used in specific rules, but once the device is removed, that record is gone. So it the user forgot to check that before removal, they have no option but to try and remember, and then manually verify.

It does do this now, as in the screenshot I posted above.

1 Like

Could that be extended to a saved report? I know we can expect that everyone will slow down and read, but we know that doesn’t happen. I certainly make mistakes.

So we're giving you a warning, we're giving you the links to each app that needs to be fixed. What more can we do? We could, as I said, stop you from removing the device UNTIL it's not used by any app at all. But, that would be super annoying for those who know what they're doing and don't need to fix each app (for whatever reason, known to them).

That makes no sense. By then, its too late. The apps have been corrupted. The time to do it is BEFORE device removal. And you have the report right in front of you, in the IN USE BY section of the device page. Not only is it a list, its a list of links to the very places that need fixing. Use it before removing the device.

Perhaps the warning should be in stronger language: "Hey, if you rip out this device these apps are likely to be destroyed by doing so, so go fix them first."

2 Likes

If we remove a device referenced in an action, RM will state "Broken", which a user can easily remove and correct the issue, keeping things clean. Why can't we have the same behavior in Triggers vs leaving a random OR operator in place when there is only a single trigger listed?

I feel current method of moving between app and links in the driver Could be improved, but I seem to be alone in that.

Perhaps better docs are needed around the subject and that’s all. Thanks for engaging in the ideas. Much appreciated.

Yes, there are some glitches in that. For many apps, but not all, when you hit Done in the app it returns to that list if that's how you got to the app. Sometimes, it returns to the Apps page instead, which is annoying. Another way to do it on a computer is to use two tabs, and right click on the link on the device page, so that page remains available.

The simple answer is that the app doesn't work that way for triggers or conditions. I'll look at that possibility, but not making any promises about it.

It remains that the instructions for removing a device are to first correct any rules that use the device. Following this instruction will avoid these problems.

See the post above about how to swap a new device for an old one:

1 Like

How about this:

16%20PM

Next release...

10 Likes

That's a pretty neat warning actually.
I see this blank problem on ST as well and they couldn't solve it with their super cloud power.