Possible bug in persistence functions?

Setup, Configuration and Use Scripts & Rules
, ,
1

As it might be useful for others I first want to share the (partial) solution for an issue I encountered after migrating my rules to Jython: When calling PersistenceExtensions.minimumSince() and maximumSince() I got a “ClassCastException: java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer” exception.

It turned out, that these exception was thrown when calling the persistence functions for my humidity items. In my setup these items are of type “Dimmer”, to be compatible with the values send on the KNX bus. In the database (PostgreSQL in my case) they where persisted using a value column of type “int8”. Turned out, that was the problem, after changing the column type to int4 it seems to work as expected.

But this resulted in an other strange issue, for “Dimmer” types maximumSince() returns an result that is the actual value * 100

0.48000000 = PersistenceExtensions.minimumSince(itemRegistry.getItem('Feuchte_Rel_Keller_HV'), DateTime.now().minusHours(1)).state 
48 = PersistenceExtensions.maximumSince(itemRegistry.getItem('Feuchte_Rel_Keller_HV'), DateTime.now().minusHours(1)).state

With these values in the database:

2019-01-16 18:00:00.788666+01    48
2019-01-16 18:30:00.758647+01    48
2019-01-16 19:00:00.970973+01    48
2019-01-16 21:35:31.377828+01    48
2019-01-16 22:00:00.794884+01    48
2019-01-16 22:35:31.480138+01    48
2019-01-16 23:00:00.800303+01    48

The item is defined as

Dimmer Feuchte_Rel_Keller_HV "Feuchte Keller HV [%.0f %%]" <humidity> (gMesswerte) [ "CurrentHumidity" ] { channel="knx:device:bridge:knx-tw-1_1_200:Feuchte_Rel_Keller_HV" }

I could observe the same behaviour with other humidity values but not with e.g. temperature values (type Number).

2

The maximumSince value is what I would expect (same value as in your database), but the minimumSince looks like it is divided by 100. What is the line in your script that you are using to log the values? I’ll do a test and see if I get the same results, but I’m using MariaDB with JDBC. Also, are you using JDBC or JPA?

3

I would have to double check my debug code when I am at home tonight, have not checked it in…

But am pretty sure, I just did a conversion of the state to string:

MinKellerHV = PersistenceExtensions.minimumSince(itemRegistry.getItem('Feuchte_Rel_Keller_HV'), DateTime.now().minusHours(1)).state

log.info("Checking humidity values, Keller HV: " + str(MinKellerHV))

I am using the JDBC binding with PostgreSQL 9.6 on macOS, installed via macports. The JDBC database driver is the one supplied by the binding (2.4 Release), which is tested but quite old.

I tested this behavior with several items and could reproduce it with every humidity item which is defined as Dimmer, but not with Number items. In the DSL rules the persistence functions return a value as expected (0<= value <=100).

4

Here is a small code sample with which I can reproduce the problem:

MinKellerHV = PersistenceExtensions.minimumSince(itemRegistry.getItem('Feuchte_Rel_Keller_HV'), DateTime.now().minusHours(1)).state 
MaxKellerHV = PersistenceExtensions.maximumSince(itemRegistry.getItem('Feuchte_Rel_Keller_HV'), DateTime.now().minusHours(1)).state 
    
log.info("Keller HV - min: {0}, min: {1}, max: {2}, max: {3}".format(str(MinKellerHV), MinKellerHV.floatValue(), str(MaxKellerHV), MaxKellerHV.floatValue()))

Results in this log entry:

2019-01-17 22:31:00.714 [INFO ] [.smarthome.automation.debug_rules.py] - Keller HV - min: 0.47000000, min: 0.469999998808, max: 47, max: 47.0

The item definition is as above:

Dimmer  Feuchte_Rel_Keller_HV. "Feuchte Keller HV [%.0f %%]". <humidity> (gMesswerte  [ "CurrentHumidity" ]  { channel="knx:device:bridge:knx-tw-1_1_200:Feuchte_Rel_Keller_HV" }
5

I’m seeing the same…

2019-01-17 18:08:21.029 [INFO ] [org.eclipse.smarthome.automation.jsr223.jython.TEST] - Keller HV - min: 0.55000000, min: 0.550000011921, max: 55, max: 55.0

Number Items are returning proper values…
2019-01-17 18:16:18.233 [INFO ] [org.eclipse.smarthome.automation.jsr223.jython.TEST] - Keller HV - min: 68, min: 68.0, max: 68, max: 68.0

But I’m also seeing this in the DSL (both ways). Looks like there is a bug in PersistenceExtensions for DimmerItem.

import org.eclipse.smarthome.model.persistence.extensions.PersistenceExtensions

rule "Test"
when
    Item Virtual_Switch_1 received command
then
    logDebug("Rules", "Test: Start")

    val MinKellerHV1 = PersistenceExtensions.minimumSince(US_Hallway_Dimmer, DateTime.now().minusMinutes(1)).state 
    val MaxKellerHV1 = PersistenceExtensions.maximumSince(US_Hallway_Dimmer, DateTime.now().minusMinutes(1)).state 
    
    val MinKellerHV2 = US_Hallway_Dimmer.minimumSince(DateTime.now().minusMinutes(1)).state 
    val MaxKellerHV2 = US_Hallway_Dimmer.maximumSince(DateTime.now().minusMinutes(1)).state 
    
    logInfo("Rules", "Keller HV - min1: {}, max1: {}, min2: {}, max2: {}", MinKellerHV1, MaxKellerHV1, MinKellerHV2, MaxKellerHV2)
end

2019-01-17 18:39:42.980 [INFO ] [org.eclipse.smarthome.model.script.Rules] - Keller HV - min1: 0.05000000, max1: 55, min2: 0.05000000, max2: 55

BTW, when using format, it will do all the conversions for you, which is one of the really nice things about using it!

6

You are right I just checked this again and the values in the DSL rules are the same as in Jython. I am sure, that this worked when I first wrote the rule many, many years ago :wink:

I would file a bug, but I am not sure if the openhab2-addons repro would be the right place. In the meantime I changed the tags of this thread, as the issue is obviously not related to Jython alone,

Thanks for the hint! With the DSL rules I was somewhat overcautious with type casting and I guess, that stayed!

7

Today I tested this issue with the rrd4j persistence service, with the same result. So I assume, that it s a problem within openHAB itself and not the jdbc binding.

I am really surprised, that this problem has not been noticed by others before…

8

I don’t suppose many people are interested in historical max/min of Dimmer Items, really.

As you have a reproducible bug, raise an issue for it. I think all persistence services currently come under OH 1.x extensions.

9

I would, if I had any clue in which repository. As the issue is not related to one specific persistence service, I suspect, that it is in some underlying layer and not one of the bundles in the “openhab1-addons” repository