Hi there,
I’ve started a migration from openHAB 2.4 (running on macOS) to openHAB 2.5 (running on a rPI 3B+).
The migration went pretty well except for my groovy rules: I cannot access very common types like OpenClosedType
or DecimalType
(listed https://www.openhab.org/docs/configuration/jsr223.html). Other types like SimpleRule
or OnOffType
are usable.
The scripts worked when used with openHAB 2.4, I just changed 2 imports from
import org.eclipse.smarthome.automation.*
import org.eclipse.smarthome.automation.module.script.rulesupport.shared.simple.*
to
import org.openhab.core.automation.*
import org.openhab.core.automation.module.script.rulesupport.shared.simple.*
.
Here is a boiled down script version trying to get an Item state as a DecimalType
import org.openhab.core.automation.*
import org.openhab.core.automation.module.script.rulesupport.shared.simple.*
import org.eclipse.smarthome.config.core.Configuration
scriptExtension.importPreset("RuleSupport")
scriptExtension.importPreset("RuleSimple")
import org.slf4j.Logger
import org.slf4j.LoggerFactory
import org.eclipse.smarthome.core.items.ItemRegistry
//import org.eclipse.smarthome.core.library.types.DecimalType
import org.openhab.core.library.types.DecimalType
//openhab access (otherwise not accessible when used in named classes)
class OH {
Object events
ItemRegistry ir
OH(Object events, ItemRegistry ir) {
this.events = events
this.ir = ir
}
}
class DecTypeTestRule extends SimpleRule {
String name = "DecTypeTestRule in Groovy"
private static Logger logger = LoggerFactory.getLogger('DecTypeTestRule')
private final OH oh
DecTypeTestRule(OH oh) {
this.oh = oh
}
Object execute(Action module, Map<String, ?> inputs) {
logger.warn("DecTypeTestRule: executing")
logger.warn("DecTypeTestRule: getItem: " + oh.ir.getItem('N_AZIMUTH')) //<<< works
logger.warn("DecTypeTestRule: getItem.state: " + oh.ir.getItem('N_AZIMUTH').state) ////<<< works
logger.warn("DecTypeTestRule: getStateAs: " + oh.ir.getItem('N_AZIMUTH').getStateAs(DecimalType.class)) //does not work
// int azimuth = oh.ir.getItem('N_AZIMUTH').getStateAs(DecimalType.class).intValue() //the intended code
logger.warn("DecTypeTestRule: done executing")
}
}
void addTriggers(SimpleRule aRule) {
List<Trigger> eventTriggers = new ArrayList()
eventTriggers.add(TriggerBuilder.create()
.withId("${aRule.class.simpleName}_triggerTest")
.withTypeUID("core.ItemStateChangeTrigger")
.withConfiguration(new Configuration([itemName: 'triggerTestRule']))
.build())
aRule.setTriggers(eventTriggers)
}
def sRule = new DecTypeTestRule(new OH(events, ir))
addTriggers(sRule)
automationManager.addRule(sRule)
Running this script leads to the following log output:
==> /var/log/openhab2/openhab.log <==
2019-12-29 16:20:05.121 [WARN ] [DecTypeTestRule ] - DecTypeTestRule: executing
2019-12-29 16:20:05.125 [WARN ] [DecTypeTestRule ] - DecTypeTestRule: getItem: N_AZIMUTH (Type=NumberItem, State=230.87987753820812, Label=Azimuth, Category=null, Groups=[G_ASTRO])
2019-12-29 16:20:05.129 [WARN ] [DecTypeTestRule ] - DecTypeTestRule: getItem.state: 230.87987753820812
2019-12-29 16:20:05.133 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule '724b45dc-b4cf-456f-bf71-13dead4ea6db': Fail to execute action: 1
Getting the item seems to be okay (oh.ir.getItem('N_AZIMUTH')
), reading its state via state
also, but reading its state and converting it to a DecimalType
using oh.ir.getItem('N_AZIMUTH').getStateAs(DecimalType.class)
is not working.
This ist the item definition
Number N_AZIMUTH "Azimuth [%.1f]" (G_ASTRO) {channel="astro:sun:home:position#azimuth"}
In another script, I was trying to use OpenClosedType
def ctItem = oh.ir.getItem(ctItemName)
if (ctItem.state == OpenClosedType.CLOSED) {
Running this leads to
2019-12-29 16:03:02.684 [ERROR] [DisplayHallRule ] - Error: groovy.lang.MissingPropertyException: No such property: OpenClosedType for class: DisplayHallRule: No such property: OpenClosedType for class: DisplayHallRule
I’ve tried using various import
statements but did not find a way to access these types. In special cases, I was able to use strings instead of the problematic types, but that is very dirty.
As you can see by the OH
class, I’ve already implemented workarounds for scoping problems related to the named rule class
style. Maybe this is also a scoping problem?
Do you have an idea?
Thanks