[SOLVED] What is the syntax error in my RGB -> HSB conversion?


I just upgraded from 2.3 -> to 2.5.1, and try to fix all errors out from log. At the moment rules are not shown, and some validator fails due my rule file. Can you please spot what’s the error here?

//import org.openhab.core.library.types.*

rule "Set HSB value of item RGBLed to RGB color value"
        Item AllinRGBLed changed
        val hsbValue = AllinRGBLed.state as HSBType

        val redValue = String.format("%02X", (hsbValue.red.floatValue*2.55*hsbValue.brightness.intValue/100).intValue)
        val greenValue = String.format("%02X", (hsbValue.green.floatValue*2.55*hsbValue.brightness.intValue/100).intValue)
        val blueValue = String.format("%02X", (hsbValue.blue.floatValue*2.55*hsbValue.brightness.intValue/100).intValue)

        val color = redValue + greenValue + blueValue
        logInfo("AllinRGBLed changed: ", "Colour: " + color)

        sendCommand(allin_rgb_color, color)

I commented out the include, as there was warning about wildcard imports, and manual says it imports that dir contents in any case.

This is the error I get:

2020-02-05 10:52:00.795 [ERROR] [xtext.validation.CompositeEValidator] - Error executing EValidator
java.util.ConcurrentModificationException: null
        at org.eclipse.emf.common.util.AbstractEList$EIterator.checkModCount(AbstractEList.java:758) ~[?:?]
        at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:712) ~[?:?]
        at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:692) ~[?:?]
        at org.eclipse.emf.common.util.AbstractTreeIterator.next(AbstractTreeIterator.java:133) ~[?:?]
        at org.eclipse.xtext.resource.impl.DefaultResourceDescription.computeExportedObjects(DefaultResourceDescription.java:88) ~[?:?]
        at org.eclipse.xtext.resource.DerivedStateAwareResourceDescriptionManager$1.getLookUp(DerivedStateAwareResourceDescriptionManager.java:84) ~[?:?]
....  continues several pages

and next:

2020-02-05 10:52:01.612 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'allin_rgb.rules', using it anyway:
Error executing EValidator

But I’m newbie to rules, I have used them so little. What is the syntax problem leading to such error for validator?

Add in some logInfo statements to see what is going on in the rule

logInfos aren’t going to help with a compile time error.

You could comment the lines out of the rule body, and see when the failure recurs as you re-enable them.
Actual validator error rather than problem report suggests something odd - a hidden strange character maybe.

Any other imports in this file? (I see the commented out one)

I misread the error, sorry

somehow it’s related to imports. If I have the import in place, I get deprecation warning, but no validator error:

2020-02-05 14:27:05.353 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'allin_rgb.rules', using it any
The use of wildcard imports is deprecated.
2020-02-05 14:27:05.388 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'allin_rgb.rules'

I read the rules guide in a way that import isn’t necessary, as it is automatically already imported:

A few default imports are already done, so classes from these packages do not need to be explicitly imported:


So why does the validator fail if I remove it to get rid of the warning? This rule worked BTW in 2.3 version, I don’t know if it nagged about the import.

Ok, fixed. Changing the import line to:

import java.awt.Color

fixed it. Got it from here: How to convert RGB to HSB and vice versa?


1 Like

I have never seen this error before. But based on the information presented, I would guess that there is just something timing wise (Concurrent) with the way the parser and validator processes the file it gets tripped up. Or it could be that for some reason it thinks the file changed while it was processing it.

I don’t think there is anything specifically wrong with your original code as written beyond the fact that it’s best to avoid the use of primitives except when you have to use them. Instead of calling .intValue cast it to Number instead. Primitives cause the parser and validator to do a whole lot of extra work and can potentially add minutes to your parsing time, even on a fast machine in some cases. It’s very noticeable on an RPi.

Indeed, the imports are not needed and should not be used, which has been the case since OH 2.0 was released.