I am often seeing this behavior and it's killing me because obviously the rule is now dead, I can't see it to recreate it. I end up having to start over from scratch every time this happens. Is there a known workaround to bring it back? Is there some way to see it in a lzf backup file to help re-create it? This is very painful.
I am on a C7 with 2.3.4.138.
I realize I am behind in firmware but to be honest I'm afraid things will break every time I consider upgrading. If there is a known fix for this after 2.3.4.138 then I will. Please let me know.
Error: Cannot invoke method startsWith() on null object
I'm not sure if this will work.... But could you restore an olfr hub backup, recover the rule by exporting it, then applying the most recent backup...? I keep this as a last resort...
Also very painful. I don't know when I last changed the rule and I shouldn't have to go through all the hoops to find an old backup where it used to work.
I guess the last time I made a change to this rule it was "invalid". I feel like I have to back up rules now before making changes to avoid this. Also very painful.
Can we please improve this tool? Is it possible to update rule machine to prevent us from saving such a "broken" rule which leads to this scenario?
I suppose it's also possible my last update to 2.3.4.138. broke this rule. How do we know?
I'm quite sure this rule was using local variables (integers) as well as a boolean hub variable.
I wasn't suggesting that approach as some kind of accepted or acceptable fix for this situation, only as an attempt to get you up and running again more quickly, but only if it was a quick exercise for you.
I am not suggesting that you should have to backup everytime you make a change either. Let's not jump to conclusions before we work out what the cause actually is.
Unfortunately I can't offer you any more assistance at this stage, but hopefully others will chime in soon.
Thanks @sburke781 and sorry, I'm just really frustrated with several aspects of this platform. I appreciate your time and thoughts.
I'm really wondering if this is happening to others, and if so, how often. I'm really tired of getting burned by this one in particular and my confidence in things here is slowly eroding.
I can't help but feel more focus needs to be put into "making sure things work" rather than "finding ways to make things work". Don't get me wrong, I see exactly the same thing in other systems/apps/etc, including the software the company I work for builds.
Btw this rule is not a critical one. It's really not this particular rule being dead that bothers me, it's that I'm becoming hesitant to edit rules now... and that is the center of everything isn't it.
I get what you mean, I also work in IT more generally and so can appreciate both sides of the process of getting something built. I guess just like when someone has issues with something we build, we wouldn't want to see them labelling the system with negative traits without the opportunity to identify what the cause is first. I can see though that your comments are coming from your frustrations, which is understandable.
In terms of those screenshots, the third one has some null references in the actions section. I'm not sure whether they would be expected or whether once referenced elements may no longer be available. Do you know what they may have been in the past?
That's fair enough, it would only be if you had some memory of what the actions for the rule looked like and even then some guess work on where the issue might lie
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.
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.
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.
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.
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.
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?
