I keep seeing a few of these in my logs and just wanted to make sure it wasn't anything to worry about:
One is from a generic zigbee contact sensor, one from a generic zigbee outlet, and the other from a rule machine rule
2023-01-05 08:57:40.254 AMerrororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: GenericZigbeeOutlet.checkEventInterval() is applicable for argument types: () values: [] (method checkEventInterval)
2023-01-05 08:43:06.038 AMerrororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: GenericZigbeeContactSensor.ping() is applicable for argument types: () values: []
Possible solutions: find(), print(java.lang.Object), print(java.lang.Object), find(groovy.lang.Closure), print(java.io.PrintWriter), run() (method ping)
2023-01-05 09:02:58.745 AMerrorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Long#minus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[class java.lang.Character]
[class java.lang.Number] on line 9172 (method allHandler)
Feels like one for HE dev's to look at. It is.... let's call them actions (methods) being called that are not available in the driver for the device in quesiton.
It may be useful to provide both the HE platform version you are running along with some more context of the circumstances when the errors occur, i.e. the definition of the rules involved or other apps or devices.
These just pop up in the logs fairly regularly on their own. The rule machine rule is a pretty simple one that turns a virtual switch on if power usage is over a certain threshold (laundry is running).
The outlet error pops up every 30 minutes, the contact sensor every 15 minutes or so, and the rule machine one every couple minutes but more seemingly random.
The weird part of the contact sensor, I have 4 of those same models. Only one of them throws up that error. All set the same and using the same driver.
You must have paired these with a different driver, like a custom driver (one that had such a method and created a schedule to run it--I don't think any built-in ones do), and then switched to one of these. To fix:
Temporarily switch to the "Device" driver (under "Type" on the device detail page, select "Device")
Run the "Delete Scheduled Jobs" command
Switch back to the driver you intend to use
If you didn't do this in the when switching before, it's also a good idea to run the "Configure" command, if available, after switching drivers
The outlet I actually did, but did the driver and delete states thing. It was some driver that reported presence and other stuff. The extra states were annoying me after I switched it to the generic one.
The contact sensor was always paired with the generic driver but I'll try changing them both to device and back to see if the errors go away.
Any thoughts on the RM rule error?
I'm not even sure if these are a problem, but I'm chasing some random issues and want to eliminate everything I can as possible issue.
Note that you don't want to delete "states" but rather "scheduled jobs." However, both can't hurt. It's odd that the other device would be doing this, but I can't tell from the logs where the errors are actually coming from (so I was just guessing it was these two--maybe not?).
The fact that any error was from RM is also not apparent from the logs. Must be the third log entry you provided? If so, you may need to share more details about what steps you take to reproduce that error. If your current rule is "broken" and won't let you back in, you can try again with a new rule (and delete the old/broken one from its app status [gear icon] page if that's the only way).
Yeah that 3rd one is from RM. Probably because I copy and pasted to notepad to remove those links before posting. If I hover over the entry it tells me what the rule is.
I'm on mobile so apologies for my formatting but this is the RM rule. It pops up with that error every few minutes on it's own.
The rule just turns off a virtual switch. The other rule turns it on when power is greater than whatever for xx minutes. No errors in that one though.
You could try re-creating the rule to see if the problem persists, which might help if the error is related to something from previous edits (other traces of which must be gone now, and if you can figure out what change caused it, it could probably be fixed). If it still happens, maybe there is something in their Rule app that atsffncokls look into.
Interesting. Both of the devices generating the errors did indeed have scheduled jobs. I know the outlet I deleted states but not the scheduled jobs. As for the contact sensor, it had the same 3 scheduled jobs as the outlet despite never changing it's driver. They are cleaned up now and the errors should stop.
I just hit update rule for now, if that doesn't fix it, I'll recreate it. Now that I'm a little more proficient with RM I could probably combine my two laundry on/off into one and get rid of the virtual switch with notifier.
I have several Zigbee plugs that exhibit almost this same behavior -- I have tried a variety of custom drivers for Zigbee outlets and switches, and they all end up generating the same two errors you show for .ping() and .checkEventInterval(), so I assume the issue has to lie somewhere other than just the built-in HE drivers.
The RM angle is new information, I will have to look into that -- but I think it would still have to be something internal and unique to specific Zigbee devices, as there are other devices in my rules that don't exhibit this issue.
Okay, so I have 8 of these same devices; 5 of them do create errors in the log and 3 of them do not. There is also no consistent scenario with RM, as both groups have some devices which use rules and some that do not.
This error is caused by the custom driver scheduling jobs whose "handlers" do not exist in the built-in drivers. The solution is to delete the scheduled jobs and is explained above:
Rule Machine -- or any app -- is not relevant to this problem; it's a driver issue (unless you happen to be taking the unlikely step of calling a non-existent command from a custom app, though I have never seen anyone here try that [EDIT: in the context of this problem, I mean]).
