Since upgrading to 2.1.0.x, I have been having Groovy (Java) errors in two of my user community contributed apps that were previously working. Recurring errors I now see in logs are:
java.lang.NumberFormatException: null on line 245
groovy.lang.MissingMethodException: No signature of method: com.hubitat.hub.domain.Location.currentState() is applicable for argument types: (java.lang.String) values: [sunsetTime] on line 151 (changeHandler)
java.lang.NullPointerException: Cannot invoke method getAt() on null object on line 454 (updated)
I've looked at the code to try and interpret what this means but unfortunately I am not fluent in Java or Groovy.
I'm thinking of downgrading back to 2.0.9.x but the notes say I need a copy of a 2.0.9.x backup which I am not sure I have. What are the risks of downgrading with the existing database?
Does anyone have any other suggestions on how to best deal with these problems? Thanks in advance.
As @bobbles stated, most of the the user app developers are VERY responsive to community input. Just reach out to them in the thread for their app or via PM, I'm sure they can help get your sorted out quickly.
I wouldn't recommend just "living with it" as any error showing in the logs POTENTIALLY COULD cause HE stability issues and is almost certainly causing the application to not work as designed. The errors are probably due to the "platform changes" related to security that were part of the 2.10 firmware update.
As user apps are not "supported" by HE support you will need to rely on the developer of the code, but if you specified the name of the apps I'm sure that would help too. It's likely other users are using the apps and that possibly one of them have already reached out to the developer.
Rolling back really should be your last-resort 2.10 has a TON of fixes and changes.
Edit: edited wording for "FUD" factor per @JasonJoel
The hub overall is running fine but the apps do not work.
I have contacted the owner of one of the apps (Wemo Connect) but so far little response and no resolution for almost a week. As a result, I cannot use the Wemo outlets with Hubitat.
The other app (Holiday Color Lights) just started failing after the lates Hub update. The author is no longer maintaining it.
Is the Hub working? Yes.
Is the Hub providing all my home automations as prior to the update? No.
And I just finished moving everything from Smartthings to HE . . . . Patience; need more patience. And more coding knowledge wouldn't hurt either.
Based on the description of the app in the code it appears that this could be duplicated pretty easily in RM 3.0, if It were me I would just create a rule or two that would achieve the same effect. I'm from the school of thought that if I can do it RM no need for "user code". The main advantage being if something breaks HE staff will almost certainly have a fix or workaround.
Not sure how to help you on the wemo-connect app, if the developer isn't helping you may have to hope that another user that is a coder can assist.
The Wemo Connect app does discover the Wemo devices but fails when creating them in the Devices list. There may be other errors as well but that's where my instance of the app fails. This app does appear to be maintained and others have also reported errors. I am hopeful this one will be resolved in the coming days/weeks.
Using RM 3.0 as a way to get rotating color lights sounds interesting. I was actually thinking of something similar using a series of holiday Scenes and scheduling rules to activate. There is a similar WebCoRE script but personally I find WebCoRE slow and confusing.
What I had done was discovered my WeMo switch and insight and then disabled the app as I didn't want HE to control them as one has my HE plugged into it and the other my RPi.
Hence no errors. It was only when I enabled WeMo connect that I got the errors.
Interesting idea just sprung to my mind. As a keen amateur tinkerer, I also wish I could get into Groovy programming and understand how to write drivers and apps on HE. But didn't yet find a good intro that could walk me through it. Seems there is maybe a market here for some professionally written training material/videos. I for one would pay a modest amount for a good quality set of courses on this to extend my understanding and open new doors.
I don't see how that could possibly have been working. I'm pretty sure this is one of those cases where you made multiple changes but you did not realize it and just assumed it was the last change (upgrading your hub) that broke it. I actually use the wemo connect as well, I had my own version but I switched to the one I believe the rest of the community is using : hubitat/apps/jason0x43-wemo_connect.groovy at master · jason0x43/hubitat · GitHub
I too got the same error. I looked at the line it was occuring on and nothing jumped out at me, I then looked at the change history for that app and noticed a change to line 451: Clean up WeMo Connect code, add more logging · jason0x43/hubitat@1adacab · GitHub
There is nothing I can see that populates "address" in the map that is being referenced there, so it is trying to reference a value that does not exist. when I reverted that change from deviceData.address to deviceData.mac it works fine for me.
I took a quick look at the Location class, we have not changed it since Oct 2018 and it does not currently and as far as I can tell has never had a method named "currentState" so I'm also unsure how this was ever working for you.
@chuck.schwer . . . THANK YOU! That did the trick. I changed line 451 from deviceData.address to deviceData.mac and my Wemo devices are being discovered and successfully added to Devices.
Thanks! It does, indeed, need an update. (Well, to be changed back to what it was.) I'm not sure what I was thinking when I changed that particular line of code. I was doing some general cleanup, but as @chuck.schwer points out, there never was an address property on device data.
