[Homematic] Paper UI Control randomizes ui elements for controls

[mdicke2s]

From @Seikilos on December 16, 2016 20:39

Using 2.0b4 I added a button to openHAB and it displays the buttons as follows:

Key radio_button_uncheckedPress Short radio_button_uncheckedPress Long

Key radio_button_uncheckedPress Long radio_button_uncheckedPress Short

Two other objects have their maintenance entries switched:

Maintenance trending_upSignal Strength -52 radio_button_uncheckedLow Battery OFF

and

Maintenance radio_button_uncheckedLow Battery OFF trending_upSignal Strength 0

This is quite confusing and seems to be quite random for me.

Copied from original issue: openhab/openhab2-addons#1580

[mdicke2s]

From @MHerbst on December 24, 2016 10:6

I can reproduce at least the second one. For some devices the order is different. @gerrieg should know whether this is a problem of the binding or a general Paper UI issue.

[mdicke2s]

From @gerrieg on December 25, 2016 8:32

I have no influence on the sorting of the metadata, so this is a PaperUI issue.

[mdicke2s]

From @MHerbst on May 21, 2017 8:37

@gerrieg I am not sure whether I have looked into the correct class (HomematicChannelTypeProviderImpl). But as far as I could see, you are using HashMaps to store the channels. What about using a TreeMap instead to get the same order for all channels.

[mdicke2s]

From @gerrieg on June 8, 2017 16:29

I'm not sure if this will help, i don't know the internal OH implementation, but let's try it see https://github.com/openhab/openhab2-addons/pull/2346

[mdicke2s]

From @gerrieg on June 8, 2017 16:32

does not work, i get a exception at startup with a TreeMap. I reverted the commit

[mdicke2s]

From @martinvw on June 8, 2017 16:38

What kind of exception do you get, your change looks reasonable to me.

[mdicke2s]

From @gerrieg on June 8, 2017 16:43

2017-06-08 18:41:07.778 [ERROR] [omematicDeviceDiscoveryService:114  ] - org.eclipse.smarthome.core.thing.type.ChannelTypeUID cannot be cast to java.lang.Comparablejava.lang.ClassCastException: org.eclipse.smarthome.core.thing.type.ChannelTypeUID cannot be cast to java.lang.Comparable
    at java.util.TreeMap.getEntry(TreeMap.java:349)
    at java.util.TreeMap.get(TreeMap.java:278)
    at org.openhab.binding.homematic.type.HomematicChannelTypeProviderImpl.getChannelType(HomematicChannelTypeProviderImpl.java:43)
    at org.openhab.binding.homematic.type.HomematicTypeGeneratorImpl.generate(HomematicTypeGeneratorImpl.java:133)
    at org.openhab.binding.homematic.handler.HomematicBridgeHandler.onDeviceLoaded(HomematicBridgeHandler.java:296)
    at org.openhab.binding.homematic.internal.communicator.AbstractHomematicGateway.loadAllDeviceMetadata(AbstractHomematicGateway.java:415)
    at org.openhab.binding.homematic.discovery.HomematicDeviceDiscoveryService$1.run(HomematicDeviceDiscoveryService.java:110)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)

[mdicke2s]

From @martinvw on June 8, 2017 17:3

Fair enough, forgot about that logical limitation.

we could of course do a PR to make ChannelTypeUID comparable, does make sense @sjka wdyt?

[mdicke2s]

From @kaikreuzer on June 9, 2017 6:58

Imho it does not make any sense to add an order to channel types - only sorting channels has some value. And this should already be covered by the framework: The order that getChannels() returns them is also kept in the REST API and thus used in the Paper UI.

[mdicke2s]

From @martinvw on June 9, 2017 7:30

Sounds fair indeed.

But to me its not completely clear whether the actual problem is with channel types or channels. Can somebody clarify that?

[mdicke2s]

From @MHerbst on June 9, 2017 22:3

Sorry, but I was on the wrong track and tried to solve it in the wrong class. As @kaikreuzer said, it does not make sense to order the channel types. Instead the list of channels of each thing type must be in a consistent order. I am trying to understand how the channels are defined in the Homematic binding to find a better solution.