So I spent a few days reconfiguring my Konnected Alarm interface. Took a while to get it back up and running. In that time, I had forgotten that one of the devices from my alarm system was used as the (only) Trigger for several Rules.
In looking at my HE Apps page, there was no absolutely no indication that these Rules no longer had a Trigger Event, and therefore would never run. Broken Rule!
On the Apps page, Rules now indicate if the Predicate is True or False (which I really don't want to see), but don't bother to tell you if the Rule is broken????? Am I missing something here? How are you supposed to know if a previously functioning Rule is no longer functional?
This won't happen on its own; normally it's because you removed a device that was in use by the actions (so it wouldn't work anyway). In any case, it's been discussed before. Here are some I can find with a search:
I can appreciate the frustration this can cause, and at some level it would be nice to have this warning.
Two things to consider are:
Rule Machine is one app where devices can be used. They can be referenced in other built-in apps, custom apps here from the Community, etc. So one solution for Rule Machine will not solve all the possible issues that can arise from the removal of a device, however useful it would be to have this indication.
The way this is intended to be mitigated is by the user doing a review before removing the device. At the bottom of the Device Edit page there is an "In Use By" section that shows where the device is referenced, including any references in RM rules but also any other app that may use the device. It is expected that these are each addressed before removing the device to allow for a smooth transition.
Yes, I am aware of this feature and think it is good. However, in my personal experience, if you are removing device, the removal of the device is your primary focus of attention, and I have NEVER used that information provided by HE.
It seems like the brilliant folks at Hubitat ought to be able to add a function on the Apps page that forces the evaluation of every Rule. I am not expecting it to find logic faults, etc, just things like... no valid Trigger, no valid Action, Devices that are not longer present.
First of all, be aware that rules with "no valid Trigger" are quite valid, and used (called by other rules), so that one is out. Effectively, given the consequence to a rule of a device used by the rule being removed (behind its back), this idea of yours would simple "break" all of the rules that you are going to discover are broken when you open them. How is that helpful? Not all user suggestions are good ones.
Consider the sequence of events:
Begin device removal.
Ignore explicit warning that device is in use by automations.
Run special scan to discover how you've messed yourself up by step 2.
Come on.... Wise up and don't do step 2. This platform is not that difficult to figure out. A better solution would be to give you training wheels so that you cannot remove a device that is in use, period, until you deal with the automations where it is in use. We decided not to do that based on our possibly erroneous assumption that users would learn not to do step 2, and would prefer the freedom to make an adult choice.
In the meantime I will continue to make efforts to make Broken Rules easier to deal with. As it is, you should be able to just remove the offending action, and replace it. Perhaps that can be improved on. But I am repelled by the idea that we should spend time on step 3 as long as you are going to repeat step 2.
And I think you'd get more complaints if the system was dumbed down to make it foolproof for user error, cos it would have to become less flexible. I mean what if I wanted to deliberately remove a device that was the trigger to the rule? I'd not want the system telling me "no you can't in case it's not what you wanted" like a.n.other system I used previously (in that case it was I couldn't use a device in a condition as well as the action in case an inexperienced person accidentally set up an endless loop)
I did not suggest that HE in any way limit what a User can do. Nor did I suggest that the User Interface be dumbed down. I was merely suggesting/requesting that there be a simple (and optional) way to identify broken rules. My suggested method was apparently not feasible.
I want to re-iterate WHY I have found this a problem. Being an "adult", I have used, and agree that a User should pay attention to "step 2". However, In my experience, if you are removing a Device, it is most commonly because there is a problem with the device; malfunctioning, dead, etc. And in my experience, these are the most difficult devices to get rid of. Even when it is successful, the process of device removal has frequently required multiple Refresh/Repair/Remove/and Reboots. And then, you may still be left with the dreaded "ghost" device. In other words, when you started the process to delete the device, you thought it was going to be a 10 minute process, for which the existing HE notification of where the device is used, was noted, and may be sufficient. However, removing a problem device can become a multi-hour or multi-day process. After multiple hours or days of reading threads, posting questions, contacting Support, etc., and then finally getting the device working, again, the notification provided by HE is a distant memory. Guess I should just take a pencil and paper and write down the HE notification so that days later, I can refer to it. Pencil and paper, how is that for Home Automation?
In summary, the existing HE notification is adequate for the best case scenario of removing a device, but may not be optimal for the average or worst case scenario of removing a device.
In any event, I appreciate the work and support provided by Hubitat.
Yeah but separate the idea of the actual device from its representation in the rules. If you know your device is dying or dead you can remove it from the rules before wrestling with the actual physical creature.
If you need to remember which rules it was in, create a virtual device with the same capabilities and put that in the rules, then that can serve as your guide when you get the device working again or a replacement
I don't remove a bad device until I've added it's replacement and used the old devices rule list to update those rules with the new device. I've done it this way since my smartthings days. Even if it's resetting the same device and adding it back.
One possible way to handle it: When a removed device is still connected to a rule set a flag for the rule that it was removed. The app could display "missing device" like it now shows "paused". I'm not sure of the best way to clear the flag. Could be something as simple as a banner that clears when you click the X.
[x] deviceName has been removed from HE.
In the past I've used a placeholder when removing a device so I've not seen this. The only time I had an issue is when HE told me the device was in use by a certain rule and when I looked at the rule it wasn't referenced anywhere. I've had that happen a couple of times in the past and just ended up removing the device anyway.
As a general comment, reflecting the hub as it is currently implemented, this isn't possible. It implies the existence of an entirely new hub process and adoption in every app of some method that would get called when a device is removed in contravention of the warning. That's a rather large undertaking to solve a user problem that really is on the user to begin with. What is so hard about reading a warning dialog box to avoid this in the first place? Is this really where we should be spending our limited resources, dealing with users who do something stupid, even when warned not to? To make matters worse, it wouldn't work for all circumstances. For example, if a Z-Wave device is removed using general exclusion, which may not even entail the hub at all, there is no way to know that it has occurred, as the Z-Wave SDK has no knowledge of the In Use By elements in the database, nor would it even necessarily have knowledge that the device was removed if another controller did it. Given what's been discussed above, some users go to great lengths trying to kill off Z-Wave devices by whatever means possible, and that was the argument presented above.
I'm somewhat astounded at how stubborn people are about wanting a fix for a mistake they make where they ignore a perfectly clear warning given by the hub. When you screw up some other system after defying a warning, do you go crying to those devs seeking extra relief from your own stupid mistake? Come on, sorry to say, but this is ridiculous.
I think the OP has realised that the better way is to put a place holder in play before they move to deleting the device so that "fixes" their issue of forgetting the warning.
How ever a better argument would be to expand on that and have something like
Warning in use by apps would you like to replace device with a virtual?
virtual is created and put in place of all apps (how great would that be in the situation of failed device and the stress of it)
But that's a bigger request of being able to swap a device from one thing to another in all instances. Would make problem devices or a commercial site a walk in the park with setting it up before adding the real devices.