[mqtt.homie] Homie convention compliant property names display incorrectly

leifclaesson commented 2 years ago

According to the homie convention: An MQTT topic consists of one or more topic levels, separated by the slash character (/). A topic level ID MAY ONLY contain lowercase letters from a to z, numbers from 0 to 9 as well as the hyphen character (-).

My homie devices follow the convention, with topic names such as:

homie/2fl-lr-mcu/board0/front-balc-dwnlts
homie/2fl-lr-mcu/board0/gallery-dwnlts
homie/2fl-lr-mcu/board1/gallery-emrg-lights
homie/2fl-lr-mcu/board3/stairway-chandelier

I have followed the convention to the letter, and in openHAB 2.x everything displayed correctly.

I am now starting a new openHAB installation with 3.x and the channel name display (UID) is now a mess:

mqtt:homie300:main:2fl-lr-mcu:board0#front_2Dbalc_2Ddwnlts
mqtt:homie300:main:2fl-lr-mcu:board0#gallery_2Ddwnlts
mqtt:homie300:main:2fl-lr-mcu:board1#gallery_2Demrg_2Dlights
mqtt:homie300:main:2fl-lr-mcu:board3#stairway_2Dchandelier

As you can see, the device name (2fl-lr-mcu) is displayed correctly, but the property names are not.

This is a huge issue for me, I have hundreds of homie switches, and hyphen is the ONLY allowed separator in homie.

Expected Behavior

I would expect names to be properly displayed, as they were in openhab 2.x.

Possible Solution

Since '-' is obviously an allowed character, as it's part of the device name, it would be great if this very basic character would be supported. There is really no overlap between the homie convention and the current state of openHAB homie item display, as the homie convention does not permit upper case characters, and it was here first.

Steps to Reproduce (for Bugs)

Create a homie device which includes a hyphen in a property name, and look up its representation in openHAB 3.x.

Context

I'm trying to integrate my hundreds of Homie switches (self-made relay boards and software) in my new smart home into openHAB. I have designed everything to be compliant with the Homie convention, and tested extensively with openHAB 2.x throughout deployment since that is the version I was running. I have finally started a new openHAB 3.x installation on a new system and now need to integrate all the existing devices. The improperly displayed property names makes everything MUCH more difficult to read, for no apparent gain. This is a difficult enough project as it is, having to parse garbled names is an unexpected and unwelcome surprise. :(

Please note that the homie device name is still displayed correctly so obviously hyphen is still an allowed character in the UID in openHAB 3.0.. it's just the property names that are garbled.

2021-12-08_14-20-09

Your Environment

openHAB 3.2.0 M5 docker arm64 on a RPi4 (previously openHAB 2.5.0 on raspbian buster on a RPi3b)

jochen314 commented 2 years ago

Your definitly are right, that everything is according to to the homie specification. But the specification does not say anything about the way, in which we internally identify things. The UID is an Internal identifier. Because of the internal structure of the identifier it was neccesary to escape some characters.

ccutrer commented 1 year ago

@openhab/add-ons-maintainers: this is simply an issue of the binding unnecessarily encoding the UID. But not doing that would be a breaking change, since all channel IDs would change. Do we think this is worth fixing for 4.0?

lsiepel commented 10 months ago

The question has been answered as 4.x has been released earlier :-) Maybe it is good to just create a PR and see when it gets merged from there. In the end ithas to be fixed at some point in time, and i don't think it is possible to have some script run to update all the id's, so yes this will be a breaking change i guess.

openhab / openhab-addons