after migrating to OH2, I noticed a problem with the persistence layer. All my items are stored in a mysql database using the mysql persistence service.
To narrow down the problem I’ve created two test items:
Switch ITM_Test1 “Test1” (GRP_Test)
Number ITM_Test2 “Test2 [%d %%]” (GRP_Test)
On startup the items seem not to be restored properly. In the events.log i see the following line:
2016-10-17 00:18:16.011 [ItemStateChangedEvent ] - ITM_Test1 changed from NULL to ON
2016-10-17 00:18:16.012 [ItemStateChangedEvent ] - ITM_Test2 changed from NULL to 26
However looking at the classic ui I do observe the following behaviour:
Test1: Switch is in Off position, status on the left side is green
Test2: Value is displayed as “- %”
Using the REST API both items show the expected values (On / 26).
Accessing ITM_Test2 within a rule will cause the following error message:
2016-10-17 00:37:00.004 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule TestRule: org.eclipse.smarthome.core.library.types.DecimalType
If I set the items to new values using the REST API, the behaviour is correct everywhere, new values are shown and also stored the the mysql db. However restarting OH2 will again lead to the broken situation.
I wouldn’t read too much into the Classic UI’s behavior unless refreshing the page doesn’t change the Undefineds to their actual values. The Classic UI and Basic UI (and really I think ALL the UIs) get their data to display from the REST API.
The rule error is odd. What happens if you test for NULL before casting to DecimalType.
if(ITM_Test2.state == NULL) logInfo("test", "Number Item is Undefined in rule!")
else {
...
}
The REST API returns the exact same values in the broken / working situation. Refreshing the the classic / basic UI doesn’t update the values. They will show the broken behaviour until I manually update the items using the REST API or new values are received over KNX.
I’m using the CometVISU, which shows correct values in all situations. I only stumbled over the issue, because my rules sometimes stopped working.
item.state in not NULL is both cases. Apparently the object behind state is somewhat different. Is there any way to get class / type info?
One more question: Is there a way to get some more debug infos from the rule processor? log:set DEBUG doesn’t increase the debug information from the rule processing.
I’m reaching deep into the dusty vaults of my memory, but I think you can get the classname using:
ITM_Test2.state.class.name
But I’m not sure if that will give you the most specific class or just the class that the language thinks it is in the current context. It has been quite awhile since I’ve messed with reflection in Java (this is a Java thing, not a Rules DSL thing).
When you dumped the Item above it is clear that it is a NumberItem so I’m not sure if this will be all that informative.
If you log the state out using toString without trying to cast it, does it read correctly or generate an error?
logInfo("network", ITM_Test2.state.toString)
You could go to TRACE level logging. I’m not sure how to increase the logging in the Rules interpreter in a targeted way.
Perhaps it is a timing issue. The time required for the MySQL Persistence classes to create a connection to the MySQL server and authenticate may be just long enough that the rules start executing before restoreOnStartup finishes initializing the Items.
That doesn’t explain why the state isn’t NULL which is what I would expect.
You might consider using a tiered persistence approach like I describe here:
The tl;dr is use MapDB for restoreOnStartup, rrd4j for recent historical data, and something like MySQL or InfluxDB for charting and long term analysis data.
