It's a good thought I just can't remember exactly how that rule ended up last time I edited it.
Just to pick up on this point, my suspicion is that you constructed your rule, then one or more related items changed, like devices being removed, etc. This, if the cause, would not be so much a failing of the platform, but something else. The more I write this I'm thinking you are less likely to have ignored the warnings if you did remove something, but still worth pointing out that some of the potential causes are hard for HE to stop entirely. More recent versions have introduced indicators for broken rules, but from the screenshots that may have already been included in your version.
Yes, as we know in software:
If you allow a user to do something (even if they shouldn't or you don't think they will) they eventually will.
This is where good software can prevent such things from happening in the first place, be proactive, be smart, etc. I'm sure some day HE will get there. I mean, I hope.
1 Like
To be fair to the HE team, they have I think forever given an indication of where a device is used and a warning of the potential for issues if you remove a device with apps that use it. I think there are situations where it is still acceptable / safe to remove devices with links like this, as long as the app can handle it. The kind of things I am thinking of are apps that sync devices from some LAN or cloud platform, like hue lights, etc. The app may not offer a removal option, relying on deletion of the device through the HE UI. Removal of devices with links to automation apps however, that is different....
Yes I'm sure I've seen those kinds of checks in action in HE but I have a feeling something is missing somewhere. Like I said in my first post it's also possible my last update to 2.3.4.138 broke something, who knows.
This issue has hit me about 4 times over the past few months and I believe on more than one hub software version.
Could this be the problem?
I'm searching around as well. I don't think this is exactly it because the date was Nov 2022 and he said it would be fixed in the next release. I've definitely updated my software a couple times since then.
Just to be clear, I haven't edited that rule for quite some time. I just happened to decide to take a look at it today and it would not open.
1 Like
Bruce talked about the line number being important for him identifying where the error occurred and what needed fixing. Your error occurs in a different line in the code, so is probably a different issue.
@bravenel - are you able to take a look at @wj72 's issue? The first post shows an error in the mainPage method when opening the rule.
2 Likes
I've now updated to 2.3.5.105 with no change in behavior but a different mainPage line number in the exception:
1 Like
Ugh, this happened to be twice when creating a brand new rule recently. One of the rules was incredibly long and I had to completely start over. No clue at all what crashed it and no "undo." And I'm not sure exactly how long these will be in my log, but it bothers me:
If this is not some super complex rule, I would suggest that you simply re-create it. That error most likely has to do with some UI break that happened while editing the rule. If it is difficult to recreate the rule, you could export it and send it to me. Without seeing the rule itself, it would be very hard to figure out what went off the rails. If you need to send it to me, send me a pm.
Yes of course I can recreate it, but that is not really the point here.
Like I said earlier this was not a very important or complex rule but in the past I have had to recreate complex rules due to this kind of error (like @Bullfrog above).
I'm more concerned that I can't trust this tool anymore. I'm constantly worried that others will break on me.
@bravenel It looks like in other similar threads you are doing one-off fixes for these kinds of errors. Is there a plan to implement a more robust change that will prevent these kinds of issues overall?
Can I also ask, is this a common/frequent phenomenon seen by the user base as a whole? I'm wondering why I'm seeing this over and over. Is it because I'm using quite a few global and local variables? Is this something I have in common with others having this kind of issue?
It's impossible to say without tracking the error down.
Bugs happen. As we find them, we repair them. There is no magic wand to "prevent" bugs.
I need you to export and send me this rule, so I can find out what is going on. I'm eager to do that. See PM I'm about to send you with instructions.
At this point, bugs in RM are getting to be few and far between -- but they still exist.
BTW, @Bullfrog issue is completely unrelated to yours, but the same problem exists -- that I need to see the rule to track down the problem.
See PM I sent you as well. I need the rules exported and sent to me.
Obviously.
But can something be done to prevent users from not being able to open rules? We're talking about the very core of this platform here. Whether that is not allowing us to save a "bad" rule or something else, you have to see this is a significant issue for complex rules that can suddenly no longer be opened.
1 Like
This is caused by some bug. There is no other answer than that. It has to be found. Obviously we don't want people to be unable to open a rule. And just as obvious, something got in your way. Sometimes database corruption can cause this, and sometimes it's some latent bug. I intend to find out which it is in your case.
It appears that the error was caused by a missing Hub Variable, WindowFansAreSetUp. Could you possibly have deleted that variable? It certainly should not throw an error, but that is what caused it. This will be fixed in the next release.
2 Likes
No, I might have renamed it at some point though.
I hope this will result in a change to prevent users from saving a rule containing a variable that doesn't exist. Why not try to avoid problems in the first place rather than fight with them all later...
Another example of this idea and something else we could all use (I got burned by this twice) are rules that don't run because there's an extra AND for example (i.e. IF X=Y AND B=C AND AND E=F). They can be tricky to spot due to line breaks and there's no rule level indication of broken logic. Anyhow, that's for a different post.
1 Like
RM already has protections about this.
I'm still investigating. There is a bit more to the puzzle...
Look what I found in the rule:
Do you know which variables used to be there?
This is beginning to look like database corruption is the original source of the problem, and in turn some unprotected references in RM caused the error. This wouldn't have turned up in most testing, or in other users' use of RM. The unprotected reference should obviously be protected, and that's how I got into the rule. But this particular action became corrupted somehow, and unless you intentionally messed it up (doubtful), that points at the database.
1 Like
