Add curated tags to addons (6/9) [K thru M]

[andrewfg]

Background

In PR #18585 we applied tags to about 350 addons. They were applied by a machine algorithm that tries to guess the appropriate tags based on context in the channel-type xml files. The results of the algorithm are perhaps only about 80% .. 90% accurate.

Furthermore there is another problem in that some of our reviewers are unwilling to review #18585 due to its size.

Solution

In this PR we take over the remaining addons from #18585 whose names start with K thru M and apply my personal curated human improvements to them; although unfortunately we have not received any feedback from actual code owners.

Signed-off-by: Andrew Fiddian-Green software@whitebear.ch

As mentioned these addons have already been reviewed and curated by myself .. so this is for OH Maintainers to keep track of their reviews..

• keba
• knx
• konnected
• lametrictime
• lcn
• lghombot
• lgthinq
• lifx
• liquidcheck
• livisismarthome
• loxone
• lutron
• luxom
• luxtronikheatpump
• magentatv
• max
• mcp23017
• mecmeter
• melcloud
• mffan
• miele
• mihome
• miio
• milight
• millheat
• modbus
• modbus.e3dc
• modbus.helioseasycontrols
• modbus.kermi
• modbus.sbc
• modbus.stiebeleltron
• modbus.studer
• modbus.sunspec
• mqtt.fpp
• mqtt.homeassistant
• mqtt.homie
• mqtt.ruuvigateway
• mystrom
• myuplink

[ccutrer]

LGTM for MQTT generic, homie, and home assistant

[fwolter]

LGTM for lcn

[andrewfg]

Call to action

@openhab/add-ons-maintainers .. just for the avoidance of doubt: I opened #18585 almost two months ago; there was initially some feedback from code owners, but in the meantime the feedback has dried up, and I am not expecting to get any more feedback from those guys; the original tagging was done by my algorithm, and in the meantime I have hand curated the tags. So now I am not asking @openhab/add-ons-maintainers for one by one feedback of their own addons. Instead I am calling upon @openhab/add-ons-maintainers to review en masse the tags in this PR. My goal is to get this into v5.x release as I think it will represent a significant step improvement in usability.

[lsiepel]

first part reviewed until Luxtronikheatpump (skipping knx for now)

[lsiepel]

Looked at all remaining files. Got some comments. Unfortunately i don;t have concrete sugestions in all cases, but i;m confident we will sort them out.

[andrewfg]

@lsiepel .. not related specifically to this PR .. but just for info .. you asked earlier if there was any analysis about 1) which Point.Property tags are used by which bindings and which channel-types thereof, and 2) if we can draw conclusions about possible tagging errors. So I was playing around with an analysis program to (try to) do that. It turned out to be fairly easy to do part 1). See example below for the first Point.Property pair combination of addons already merged in OH main. However I think the part 2) (drawing conclusions) would still need to be done by a human being. The example below shows that the three objects tagged with Alarm.CO are probably correctly tagged .. but note that it can only indicate "sins of commission" and "not sins of omission"..

Point.Property: Alarm.CO
  Binding-id: amazonechocontrol
    Channel-type-id: carbonMonoxideAlarm
    - item-type: Contact
    - label: Carbon Monoxide Alarm
    - readOnly: true
  Binding-id: deconz
    Channel-type-id: carbonmonoxide
    - description: Carbon-monoxide was detected.
    - item-type: Switch
    - label: Carbon-monoxide
    - readOnly: true
  Binding-id: insteon
    Channel-type-id: carbon-monoxide-alarm
    - item-type: Switch
    - label: Carbon Monoxide Alarm
    - readOnly: true

EDIT: including those that will be merged in this PR a total of 193 different point.property tag combinations (including point without property) will have been applied to a total of 3122 binding/channel-types! This does not include the tags that will hopefully also be added by my other three open PRs -- which will add another ~2300 binding/channel-types.

[andrewfg]

Many thanks @lsiepel