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.
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.
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.
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?
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.
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."
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?
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:
The solution above is specific to Rule Machine. Other apps will still have problems with removed devices.
Removing devices without first fixing the apps is just a bad practice, and should be totally discouraged. This isn't a platform or app problem, this is a user education problem. The platform can't protect a user from doing wrong things. Well, it could just refuse to remove the device as long as it was still in use.
That is actually what happens when you try to delete custom drivers that are currently "in use by" a running app... A notification pops up stating the driver cannot be deleted because it's in use by X app.
Just reading the thread and wanted to weigh in on this. Right now, I think that would be a bad option. I like Bruce's solution to show missing device in the rule.
I do my absolute best to make sure a device has been removed from a rule before deleting the device, as described. But sometimes it says it is still involved in a rule, but it isn't. Likely it's because I've cloned a rule, switched out a device in the clone, but the rule hasn't really released the original device. When this happens, I do a page search for the device in the rule, and if I can't find it, I OK the deletion.
That was a sarcastic comment, not a serious suggestion. We aren't changing the way device deletion works, but we might make the warning a bit stronger worded.
When you remove a device, any app that references that device should be assumed to be trashed by the removal. Hence, if you don't want to trash the app or rule, remove the device from the app first!
