I get this Exception when a specific rule triggers in Rule Machine:
2021-04-16 19:49:00.511 errorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Integer#minus. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] on line 5930 (allHandler)
The rule looks like this:
If you can figure out a way to reliably reproduce this error, staff would probably be interested in figuring out why so they can fix it (or they may comment here if anything on the App Status page might be helpful to figure it out as-is).
For your particular problem, I'd probably just delete and re-create this rule. Nothing visible here should cause a problem, so something probably just got messed up somewhere, and a new rule should work aruond whatever that was. Luckily, this looks like a short one that would be easy to re-write. 
A method overloading error does not sound like something that would solve itself.
I tried to delete the rule, and recreate it. Same error:
2021-04-18 19:53:00.392 errorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Integer#minus. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] on line 5930 (allHandler)
Hence my suggestion to create a new rule. 
While rare, it does sometimes happen--and you can see several posts here documenting similar issues--that you can get a rule "stuck" in state that throws an error and makes editing impossible. That is all I meant when suggesting that a new rule might help.
I've created a new rule that looks nearly identical to yours:
This works fine for me. So, I suppose, the question is what is different or what may be helpful for staff to figure out what's different. Since Bruce (Rule Machine author) was tagged here, I'm sure he'll have some ideas. (My first guess: make sure all of the bulbs/dimmers you've selected report something for "level" under "Current States" on the device page.)
Please post the App Status page for this rule.
Here is the app status
Name Type Value
| actSubTypeMain.1 | enum | Fade dimmer level over time |
| actTypeMain.1 | enum | Set Dimmers and Bulbs |
| dimFadeIntervalMain.1 | decimal | 60 |
| dimFadeMain.1 | capability.switchLevel | Isterning H, Isterning V, Le Klint H, Le Klint V, Hjørne, Mur, Olde Lai |
| dimFadeTargetMain.1 | text | 100 |
| dimFadeTimeMain.1 | text | 20 |
| dimFadeUpMain.1 | bool | true |
| dValues | bool | true |
| modes1 | enum | ["2"] |
| modesX1 | enum | ["2"] |
| origLabel | text | Tænd lys aften |
| rCapab1 | enum | Mode |
| tCapab1 | enum | Mode |
Source Event Handler Filter
| Smedebakken 7 (Location) | mode | allHandler | false |
Name Value
| actionDone | true |
| actionListMain | [1] |
| actionsMain | {1={wait=null, delay=, modes={}, method=getFadeDimmer, indent=, rule=0, label=Fade Isterning H, Isterning V, Le Klint H, Le Klint V, Hjørne, Mur, Olde Lai up to 100 over 20 minutes with 60.0 seconds interval , cond=0}} |
| actLabelIndent | |
| actNdx | 2 |
| allVars | {} |
| allVarsO | [] |
| capabDone | true |
| capabsfalse | {1.false=Mode becomes Aften} |
| capabstrue | {1.true=Mode becomes Aften, 2.true={}} |
| certainTimes | [] |
| changedValues | true |
| connectors | {} |
| cutAction | [] |
| editCondIf | |
| gvList | [] |
| hasDevice | |
| hasRuleAct | false |
| howMany | 2 |
| howManyT | 2 |
| installed | true |
| installedCapabs | [PushableButton, IlluminanceMeasurement, ReleasableButton, Battery, AudioVolume, MotionSensor, SpeechSynthesis, Initialize, ColorTemperature, PresenceSensor, Light, Refresh, RelativeHumidityMeasurement, MusicPlayer, ColorMode, TemperatureMeasurement, SoundSensor, Notification, HoldableButton, CarbonDioxideMeasurement, SwitchLevel, SoundPressureLevel, Switch, ChangeLevel, Configuration, PressureMeasurement, Actuator, ColorControl, Sensor, DoubleTapableButton, PowerSource] |
| lastEvtDate | 17-Apr-2021 |
| lastEvtTime | 09:22 |
| lastEvtValue | 0 |
| locationBlocked | [] |
| lvList | [] |
| ndx.false | 2 |
| ndx.true | 2 |
| nestedElse | [] |
| nestedInIf | [] |
| nestedLabel | [] |
| nestedRepIf | [] |
| paramNdx | 1 |
| prevState | {PB=true} |
| private | true |
| repeating | [] |
| resubLocation | [mode, mode] |
| ruleNdx | 1 |
| selectActionsParams | {thisStr=Main, label=Tænd lys aften} |
| simpleCond | false |
| stopped | false |
| subscribedVariables | [] |
| thisStr | Main |
| timeFormat | HH:mm |
| timeTriggers | [] |
| timeTriggersW | {} |
| trigCustoms | [] |
| varUseList | {} |
| waitCondNdx | 1 |
| waitConds | [] |
| waitEvents | [] |
No Scheduled Jobs are set.
I forgot to mention, that the bulbs uses in this rule, are all Philips Hue devices (if that makes any difference).
I have tried creating a similar rule, but with only one bulb. Let's see tonight if that works.
I really need the Application State (screenshot) at the point in time of the error. It would also be useful to see the device page (screenshot) of Isterning H at that same time. What driver are you using for these?
Isterning H is of type hueBridgeBulb. All of the devices targeted are of either type hueBridgeBulb of hueBridgeBulbRGBW.
I will try to capture the data you need, when it fails again tomorrow.
I have got some screenshots now.
Before the error:
The error:
2021-04-20 19:57:00.515 errorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Integer#minus. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] on line 5930 (allHandler)
After the error:
Your hue bulb is not setup right. It should be showing Current States, but that is blank. This is the cause of the RM failure. You probably need to remove that device and set it up again.
In order to fade over time, RM has to know what the current level of the device is. But that's just not there.
My ESP is getting better. 
It makes sense. I don't know, how they got in there without levels. I have assured, that they all have a valid level now.
But that brings an additional question to my mind:
If you have polling enabled--and it is, by default, enabled at a 1-minute interval--then Hubitat will eventually catch on to the new level, so this won't be a problem. If you happen to initiate this rule in the meantime, then, yes, Hubitat will use the last known level, and there is no direct way around that. You could increase the Hue polling interval (probably not necessary unless you depend on this in a lot of places), do a refresh() on the Bridge device (same effect as the automatic poll) if you absolutely need the current state from Hue first, or initiate all (or at least as many as you can) bulb/group changes from Hubitat itself instead of Hue, thus avoiding this problem in the first place.
But in any case, the issue is only temporary (unless you disabled polling).
Ok. I think my polling was broken as well. I got it working now.
I will see if my rule runs without problems tonight.
A short follow up, to close this issue.
The rule has been running for some days now, without problem. The missing "level" value on the target devices was clearly the cause. I guess the app could be made a little more resilient, by accepting null values in the level, and interpret nulls as zero.
Thank you for your help.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
