[homematic] Slightly incorrect values for dimmers and other datapoints

[sidamos]

Migrated from eclipse-archived/smarthome#6841. See also comments from other people there.

I am using openHAB 2.5.0 stable and a CCU3 with the newest firmware. Devices are all HM IP. Everything has been configured with PaperUI.

Values often differ by 1 between CCU3 and openHAB.

The reported dimmer value from the CCU3 is often one less in openHAB. For example, the dimmer is at 20% but it’s 19% in openHAB. 60% is 59%.
Setting to 60% in openHAB sets it to 60.5% in the CCU3, but then displays 59% in openHAB.
Setting to 100% in openHAB sets it to 101% in the CCU3, but then displays 100% in openHAB.

Same thing for level (valve) of a thermostat. When it’s 53% in the CCU3, it is 52% in openHAB.

The Android App TinyMatic is working correctly in all these cases.

2 other minor things:
The formatted SetPointTemperature of a thermostat has 2 decimal points. 1 would be enough.

The formatted ActualTemperature of a thermostat has 0 decimal points. It should have 1.

Thermostat: HmIP-eTRV
Dimmer: HmIP-PDT

[MHerbst]

The value differences look like rounding errors and maybe a different understanding of the dimmer values between openHAB and the CCU.

2 other minor things:
The formatted SetPointTemperature of a thermostat has 2 decimal points. 1 would be enough.

As far as I know, temperatures in openHAB generally have 2 decimals. But you can limit it to one in the label definition, e.g. "Temperatur [%.1f °C]". I made it in the items file but I think it should also work in the sitemap.

The formatted ActualTemperature of a thermostat has 0 decimal points. It should have 1.
Can you please check how the channel is defined in PaperUI? Ist it Number:Temperature, Number:Dimensionlessor simply Number.
There seems to be a problem with the correct unit detection and certain HmIP devices.

[sidamos]

The ActualTemperature of a thermostat is Number Dimensionless in PaperUI.

[MHerbst]

The ActualTemperature of a thermostat is Number Dimensionless in PaperUI.

That's what I expected. This means it is the same problem as #6102

[sidamos]

Thanks, so I can solve the ActualTemperature problem by recreating the thing, as it seems. I will probably do that, although I only have that problem in PaperUI, not in Habpanel.

Any chance on solving the rounding problem for dimmers?

[MHerbst]

Recreating the thing won't help yet, as the problem is not solved in the current version. I will try to upload a test version with a solution this afternoon.

Will also have a look at the dimmer. Fortunately I have the device here, but only used it as switch. But I can test the behaviour with it.

[sidamos]

Cool, thanks. One more thing that I had mentioned in the older bug report and first thought, it is fixed in 2.5.0, but it is not:
When you set the dimmer to 100% (by openHAB command or via Google Assistant saying "ON"), then openHAB sends 101% to the CCU3. This results in switching the dimmer ON, but with the last dimmer value and not with 100%.
Therefore, I have this rule as workaround:
rule "Fix TV-Licht" when Item HM_TVLicht_3_Level received command 100 or Item HM_TVLicht_3_Level received command ON then HM_TVLicht_3_Level.sendCommand(99) end

[36grad]

This appears to be a bug in the RPC interface of the Homematic CCU.
For whatever reasons, it will return "1.01" as max value for the dimmer values instead of "1.0". This leads to the observed behavior.

Affected are not only the Dimmer Transmitter and Virtual Receiver channels, but also the channels for the "Week Programs".

I tested a workaround (code see below) where I correct the max value to 1.0 for ".*LEVEL" data points on "DIMMER_.*" channels and with my HmIP-BDT dimmer this works fine.

As it took me half a week to get at least the VSCode development setup running (I tried Eclipse to no avail) it will for sure take another few days until I figure out how to submit the updated code. If someone more experienced wants to submit a pull request sooner, please feel free to do so.

I have inserted the following line in GetParamsetDescriptionParser.java in line 59ff (after HmDatapoint dp = assembleDatapoint...):

if (channel.getType().startsWith("DIMMER_") && datapointName.endsWith("LEVEL") && ((int) (dp.getMaxValue().doubleValue() * 100.0)) == 101) { dp.setMaxValue(Double.valueOf(1.0)); }

Note: I've opted for checking against an int value to avoid any surprises here even though it appears to work when comparing against 1.01.

[MHerbst]

@36grad I have a running Eclipse Development Environment and can create a PR. But I am not sure whether this solves all problems. According to the first post in this issue, the values are generally different. Maybe some sort of rounding issue.

[36grad]

My first step was to look into the suspected rounding issue in PercentTypeConverter.java as mentioned in eclipse-archived/smarthome#6841 (comment) and from there it became quite quickly clear that the issue is caused by the dp.getMaxValue().doubleValue() being 1.01.

I can speak only for the HmIP-BDT (Unterputz Dimmer) since I don't own any Roller Shutters.

Edit:

When you set the dimmer to 100% (by openHAB command or via Google Assistant saying "ON"), then openHAB sends 101% to the CCU3. This results in switching the dimmer ON, but with the last dimmer value and not with 100%.

I did not read this properly the first time but had first assumed that the 1.01 value should have some special meaning and was also suspecting that it would turn the dimmer from off to its previous value. However, I am not able to produce such a behavior. No matter what dimmer level I set (either programmatically or using the physical dimmer switch), when sending 1.01 it always goes to some medium bright level but definitely not the last used value.

Also, in the Homematic CCU it shows both for the actual brightness as well as the virtual channel level the value 101%. Maybe the CCU behavior has been changed in the recent past?

[dr2okevin]

I'm not sure if it is the exact same error, but it sounds very similar.
I have a HM-LC-Bl1PBU-FM which works only with command between 1 and 100. If I set a 0 it is interpreted as a 100.
I have also a HmIP-BSL which accepts for its led lights only values between 0 and 99. A 100 is interpreted as 0.

[sidamos]

When I send 100 to my HmIP dimmer then it goes to the previous value. So, when I send 50 then 0 then 100, it is at 50 again. I have to send 99 to get 100% in the CCU3 UI.
I think, when I send 100, then it sends 101 to HM. This is either an illegal value or a special value for HM (meaning last known value).

[36grad]

@sidamos can you confirm this behavior by using a different last value, say 10% or 90%?
For me, no matter which value I set before turning the dimmer off, sending 101% turns the dimmer on do something like 40% or 50%, but in the CCU it shows 101%.

I'm running piVCCU version: 3.49.17-35 on a Rasberry Pi 4, which version do you have?

[sidamos]

@36grad I have a CCU3 with 3.47.15 and you are right. I tested this with my HmIP-PDT:
OH 60 -> HM 60.5 -> OH 59
OH 0 -> HM 0 -> OH 0
OH 100 -> HM 101 -> OH 100 -> Real 55
OH 20 -> HM 20 -> OH 19
OH 0 -> HM 0 -> OH 0
OH 100 -> HM 101 -> OH 100 -> Real 55
I always sent the first number to OH and then looked what it became in HM and in OH. So, sending 60 to OH resulted in 60.5 in HM and 59 in OH.

[c--r]

Hi,
I'd like to point to the original issue, in which I have posted a detailed analysis of what I think the root cause is (including a suggestion for a fix). This should be easy to resolve hopefully.

[36grad]

@c--r I checked that and for me the percentage rounding was definitely not the issue. For the Homematic IP Dimmer (HmIP-BDT) the problem is caused by the maximum dimmer value 101 reported by the RPC interface which, however, is not properly processed if actually set.

[MHerbst]

There are two problems at the same time: the first problem is that the HM reports a max value of 1.01 which is not correct (BTW: the older non HMIP dimmers have a max value of 1.0). But there is an additional rounding issue. Even if you use a max value of 1.0 some values will have one decimal.

[MHerbst]

I think, I have fixed this problem. I have uploaded a test jar with description how to install it here: https://github.com/MHerbst/openhab-addons-test