@Ryan780 is correct. You can't have an orphaned line for a missing trigger through any means except removing a device from the system. When you remove the device from the trigger itself, it does not leave this artifact. Ryan is also correct in stating that in this case of a 'missing' trigger, it does no harm beyond the eyesore.
With respect, this is not accurate. I have had this happen to me when editing a rule without excluding any devices. I don't have time right now but I will see if I can replicate the issue again. Give me some time and I will post the steps to cause this.
1 Like
@bravenel Here is a screenshot of a missing trigger without me excluding a device. If you want to split this into another thread I'll post the steps. Granted it is user error but RM doesn't catch it.
Here's another
Are you hitting the back button without picking a device for the trigger?
What back button? The browser back button?
Yes.
No. As I stated earlier this is a user error but not something that RM couldn't trap. Create a rule with two triggers, save the rule. Go back into the rule and click on the triggers. Select 'Edit Event Trigger', select the first trigger. From there unselect the device then click <<App List in the upper left corner. This is user error but I don't see why RM couldn't trap for this error. This is a different issue from hitting the back button in the browser. In that case RM would have no way to catch that.
Which is the same as using the back button....aka navigating away from where you are supposed to be. You always have to return to rule list by clicking "done" at the bottom of the page. That is what I said hours ago.
That's why this is on the rule's main page:
1 Like
You are the correct one.
I have had this happen as well with no excluding of devices, and no back browser button
I have read that.
I didn't hit the back button in the browser. This is different because RM could check for this when you hit <<App List because it is within RM control. They are not the same. If that is how RM works that's fine but to say they are the same. is incorrect That is why I specifically asked you what back button you were referring to. I never brought this up to Bruce because it is an edge case. RM should be able to check for this whereas it can't check if you hit back in the browser. Same way it catches "double operators"
Not true. There is no way to catch this in an app. We can update the Warning to say,
Thanks Bruce. I didn't come here to argue. I was just pointing out an issue that can come up. Hitting back in the browser and hitting <<App List are not the same thing. I just find it odd that you can't check for this before it exits the page. I stand corrected.
Both back button and « App List remove control from the app. It never knows what hit it. The warning will be updated.
There are many ways one can corrupt a rule, many of which cannot be prevented. And the point is?
I have no point other than what I stated.
I kept stating "Why couldn't RM (the app) check", I misspoke. What I meant is why couldn't the platform check. I don't know how HE is architected so I don't know where the check would be done.
I guess what I was thinking is why couldn't the platform check with the app prior to the <<App List function being executed. I click <<App List, platform asks app to check itself for errors, if it reports errors it cancels leaving the page. Maybe it's not possible within HE but it's something I have my code testers check for.
The only way the GUI could prevent you from clicking on a link that you're not supposed to is to remove the link from the page while you're editing a rule. And I like that they're there because you can always right click and open it in another tab without a problem.
Also, in this case, if you were to navigate back to the triggers definition page, you would see that it picks up right where you left off, allowing you to complete the definition of the trigger.
I created this one by miss-clicking the same as you did:
But if you click on the triggers, this is what you are presented with:
It picks up right where you left off to pick the device to add back to the trigger. If you finish it off correctly and come back out by clicking done, the trigger is fixed.
That's the big difference between miss-clicking and removing a device. If you miss click, you can end up fixing it and it won't let you do anything else in that section till you finish off what you started. That's not true if you remove a device. That ghost is there for good.
Everything you stated is correct. I have been playing with RM for the past two weeks doing stupid things to see what would "break" or cause issues in the app. The reason I am doing this is because my neighbor, who is not technical whatsoever, saw my setup and wanted to put one in his house. I had him create a few rules and configure some apps. During this process he ended up in a situation like this. He got frustrated and stated he wouldn't get something that "wasn't user friendly" his words not mine. HE lost a customer. Since I had a background in software testing, that was nearly 20 years ago, I figured I would play around and see what other stuff I could find. I am purposely doing things that an 'educated' user wouldn't do. I'm just not going to point these things out anymore. It's not worth the bickering.
3 Likes
I think this is exactly the type of thing that SHOULD be done. No offense to Hubitat staff, as I appreciate the work they do and have done, but there are many things that could be better. Hubitat is extremely powerful, and it works well overall, but there are a few things that need some cleanup that would make the user experience better for both new and experienced users alike. The documentation is one thing that is often out of date, or does not match latest changes. Some of the wording/layout in the GUI is another.
It is not always apparent when, how, or where to do things in multiple places in Hubitat, especially for new or less technical users. Rule Machine is one example, but even Simple Lighting and Motion Lighting have some really confusing or ambiguous wordings. More popups, warnings, and careful wording are helpful especially if you aren't constantly mucking about in the software.
If I had one suggestion for Hubitat staff, it would be to skip one feature update (no new drivers, no new apps etc) every 3-4 months (quarterly), and instead just do GUI cleanup and documentation updates/improvements. If they were open source or had unlimited staff like other hubs, they could keep the pace they have been doing for the last couple years with adding new things. They don't have those resources, so maybe fewer updates are warranted at this point in time.
1 Like
I am just reading this topic and I have something similar that happened. I have excluded some devices from hubitat but not the devices in a particular rule that stopped working last week. When I pulled up the rule to see what was going on I discovered that the devices were missing from the rule. They are still in hubitat but they have disappeared from the rule.
Actually, it looks like the device is gone! I didn't exclude this device. I wasn't even around the device when I did the exclude. I wonder how it excluded it without me pushing the button on it?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
