I recently changed a Simple Automation Rule to use a different sensor. The original sensor is still in use with other Simple Automaton Rules. When I look at the Device Details page it still shows this sensor being used in the Rule that I removed it from. I have seen a lot of posts on this with RM but this is a different app. How can I clean us this so I don't have other problems as sensors can be sensitive. I am using the ZooZ ZSE-40 sensors which have done me well.
1 Like
Could you post a screenshot of the device and the rule in question?
I've seen this many times. I just ignore it as it doesn't seem to have an ill effect
4 Likes
I could not get a screen capture of the entire device screen so attached is the Device Information section as well as the Simple Automation Rule requested.
Don't you think if there is a bug we should report it so the team can look into it? I run a software QA department, "just ignore it" isn't in my blood 
2 Likes
Disregard, I just noticed that I overlooked changing the sensor in the restriction section. Now that I set it to the correct sensor the automation went away in the devices as it should.
1 Like
I think I have seen Bruce mention this error before and he said to ignore it as well
1 Like
Correct, I also recall this and so I also ignore it although it does pick at my OCD somewhat when I see it. And especially when we are cautioned to always remove a device from an app before deleting the device, and then we get these spurious notifications that the device is still in use.
It really should be fixed.
1 Like
The workaround for this in pretty much any app is to de-select devices in sort of reverse order. For example, if you have a Simple Automation Rule set up something like this:
...but then want to change it to "Motion" instead of "Switched Turned On/Off" to trigger the action (action not pictured), then you should un-select the switch ("TEST Switch 2" here) before choosing "Motion," since when you select away from "Switch Turned On/Off", the "Which switch?" input will disappear, preventing you from easily removing it yourself. (Note that it's still possible--if you chose something else, just re-choose "Switch Turned On/Off," and you'll again be able to remove the unneeded device. It's not 100% wrong that the switch is still selected in the app, even if you can't see it, but obviously this is counterintuitive when you consider that the device doesn't really participate in the automation.)
This has historically been quite notable in Rule Machine, though the latest firmware update is supposed to address many (all?) of these issues. It could really happen in any app with dynamic pages, SAR being no exception. It's not impossible for a developer to code around this problem but usually takes a lot of thought, which I'm guessing is why it's apparently low priority here and took so long for RM. (I try to avoid this in my apps, but doing so definitely makes me understand what goes into this--Hubitat's app UI model, which in fairness they did not exactly invent, does nothing to help a developer here, even if as a user it seems apparent that it should be based on what you can actually see on the screen.)
As a user, again, working "backwards" and un-selecting settings (device inputs, in particular) that exist only due to previously selected options is generally a good idea to follow in any app, stock or custom, when you want to make significant modifications. For major changes, creating an entirely new instance of the app may be easier. Not saying this is ideal, just providing the general workaround for this type of situation. 
3 Likes
