Rule throwing index out of range since release 2.2

It is been a while since @halloween posted a nice solution to get the values from the incoming call in on a Fritzbox here:

As this is a connected topic I like to mention it here, but think I start a new one because of a different issue. I seem to have some issues with a working Fritzbox rule. I started to switch to another val definition which works great, but sometimes I get this error at an incoming call. The funny thing is, at the next call the rule works again as expected without the error… since upgrading to 2.2 I get occassionally this error message and no caller identification…:

2018-01-05 21:22:55.732 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Eingehender Anruf': Index is out of range

Here is the rule based on various great input from this community:

rule "Eingehender Anruf"


  Item fboxRinging changed to ON


  // Read Data of Calltype
  val callerNumber = fboxIncomingCall.state.toString.split(',').get(1)
  val incCall2 = fboxIncomingCallResolved.state as StringListType
  val LastCallName = incCall2.getValue(1)
  val CallTo = fboxIncomingCall.state.toString.split(',').get(0)

  // Remove own number from the variables
  LastCallName = LastCallName.removeStart("123456")

 // Check if caller is unknown
  if(LastCallName.startsWith("Name not found for"))
    // Update Name with Unbekannt
  LastCallName = "Unbekannt"
  // Update Caller data into Sitemap items


  logInfo("RuleLastCaller", "Der Anruf von " + callerNumber + " (" + LastCallName + ")" + " an die Nummer " + CallTo + " wurde als Letzter Anrufer gespeichert.")

  if (callerNumber == "017212345") {
        sendTelegram("mygroup", "mymessage!")


I get two validation issues when refreshing the rule:

Assignment to final variable

But I have no glue why this in 2.2 works sometimes and sometimes not.:face_with_raised_eyebrow:

Are you guys probably aware of any changes in 2.2 that could have impacted this rule?


This post says val items are final and cannot be assigned to.

So if you want to change the value of, for example, LastCallName, you should declare it with:

var LastCallName = ...

Thank you @namraccr ! Will change this one to var and observe again :wink:
Seems the var / val difference did not have impact in 2.1 ?

Seems like I’ve seen other threads indicating that 2.2 is stricter on things than 2.1 was, though I can’t point to one off the top of my head.

@namraccr, I changed LastCallName to var as I change this one, the rest is values I do not modify. However I keep getting the error message from time to time (Index out of range). No validation issues though while loading the rule.

Any hints what else to check ?

I only see three candidates for where the out of range error could be originating. They’re each of the lines above that end with get(X) (or getValue(X)).

To narrow it down, you could log out the values that each of the get operations is using as input.

Thing is, i also have this Setup and I narrowed it already down to the “StringListType”, when “unknown” caller is in the list.

  val incCall2 = fboxIncomingCallResolved.state as StringListType
  val LastCallName = incCall2.getValue(1)
  val CallTo = fboxIncomingCall.state.toString.split(',').get(0)

if there’s a unknown caller, the incCall2.getValue(1) runs into an NPE, because, there is not (1), only (0).
I didn’t find out, how to call/count/whatever a StringlistType. Neither .Count, nor .List, … worked for me… So the rule always breaks at that.

if there’s no way to get the Count of a StringListType, we have to rewrite the rule into Splitting a .toString - but I’d like to avoid that.

I have a bit different observations so far, as I get the error also with known numbers. But I followed the recommendation from @namraccr to replace the val definitions with var definition. Did so also for the other two variables (not just last caller name). I’ll keep watching the error log :wink:

@namraccr I changed every value to var removed all val definitions but still get this irregular out of range errors… haven’t yet logged out the values…