Openhab-addons: [homematic] Dimmer HmIP-BDT not working in Openhab 3

[maedball]

Expected Behavior

On creation of the HmIP-BDT Dimmer Item via the new UI the Item should have a dimming range of 0-100.

Current Behavior

Instead it is ranging from 0-1. I also noticed that the Homekit integration is showing the Item as a switch instead of a Dimmer.

Steps to Reproduce (for Bugs)

Create a Point (item) in Openhab 3 via the new interface.

Context

I just started playing with the new Openhab 3.

Your Environment

Ubuntu 20.04 LTS
Openhab 3 M2
OpenJava 11

[MHerbst]

I could reproduce the problem in my environment.
@ghys Is it intended to have a value between 0 and 1? In OH 2.5 for dimmers values between 0 and 100 are used and it looks like this in Paper UI:

I can see also some warnings in openhab.log that do not appear in OH 2.5:

20:16:09.438 [WARN ] [se.internal.SseItemStatesEventBuilder] - Exception while formatting value '69' of item HmIPPDT000DD7098B8F23_Level with format '%.2f %unit%': Conversion = 'u'

Because of these warnings, the displayed value is not updated.

If I create a new dimmer item (that is not based on a real channel) in the Model editor it uses values between 0 and 100.

@ghys What do you think? Is this a problem on the UI or a compatibility issue between the binding and the new UI implementation? Maybe some missing information in the channel definition?

[MHerbst]

I have checked the Channel Type definition for this channel and this is what the binding returns:

The defined pattern leads to the warning I have mentioned in my last post.

I have compared it with the stateDescription for a Shelly item that is also defined as dimmer:

As far as I understand, in Paper UI for a Dimmer the ranges are "translated" to percent values (i.e. ranges between 0 and 100).

[ghys]

I think it's weird to have such a state description for a dimmer. The likely problem causing the warning is that it cannot replace %unit% in the pattern with the unit, because it's a dimmer and therefore doesn't have a unit, so I suppose in this case it doesn't make the replacement and the string formatter chokes on %u... I believe it shouldn't be like that, so at least %unit% should be removed from the pattern.
The maximum of 1.01 is also weird since it isn't compatible with the 0.1 step.

As far as I understand, in Paper UI for a Dimmer the ranges are "translated" to percent values (i.e. ranges between 0 and 100).

We'll have to look for that in the Paper UI code then. In general I'm more of the opinion that clients shouldn't do things like that, and simply respect the state description, but we'll see.
Also apparently the slider suffers from the classic floating point problem...

[maedball]

Just 2 stupid questions from my side:

1) the new ui is also called paperui?
2) which module (ui, binding,...) is setting the state description upon creation of an item?
@MHerbst: do you by any chance have the correct values that should be in the state description for the homematic dimmers? I moved straight from config files to the json file so i have no data to compare :-(

[MHerbst]

@ghys @maedball The Homematic binding creates all channel definitions dynamically and it retrieves all configuration values directly from Homematic. There are several devices with this weird maximum value of 1.01. For roller shutter controllers I already corrected the values. I will look into the implementation and I think I can correct the maximum value also for dimmers to 1.00.

The likely problem causing the warning is that it cannot replace %unit% in the pattern with the unit

I agree, this does not really make sense here. Will try to figure out why it is used for a dimmer. Maybe the idea was to automatically show a % character in PaperUI (but this did not work). Interestingly, it does not cause any problems with OH 2.5.9.

We'll have to look for that in the Paper UI code then. In general, I'm more of the opinion that clients shouldn't do things like that, and simply respect the state description, but we'll see.

That's what I also expected and that's why I looked into another binding (Shelly) which uses did not use values between 1 and 100 (as expected for a dimmer).

the new ui is also called paperui?

In the webui git repo "MainUI" is used as the name.

[maedball]

Just in case someone wants to know: The Bug is still present in OpenHAB 3 M2. (I updated the description already)

I don't want to put any pressure on this, it is just to let other people know ;-)

[MHerbst]

It's on my to do list :-) I had some problems with the development environment, but now I have a working environment and can work on it.

[MHerbst]

I think, I have solved the problem. If you like, you can test it with this jar: https://github.com/MHerbst/openhab-addons-test/blob/master/org.openhab.binding.homematic-3.0.0-SNAPSHOT.jar

[maedball]

Looks like it is working even without a removal of the items ;-)

Thank you very much!!

[MHerbst]

@maedball Can you please re-open the issue? I have not created a PR yet and the solution has not been merged. The issue will automatically be closed during the merge process.