[Core] Added item metadata infrastructure

[kaikreuzer]

Fixes #3692.

This PR introduces a MetaDataRegistry which can be queried for item-related meta data. The meta data can be add-on specific and thus it is always referred to with a namespace.

There is a ManagedMetaDataProvider, which allows adding meta data through the REST API, but add-ons are also free to implement their own MetaDataProvider, if they have other sources for that information.

Wrt textual configuration, it uses the existing infrastructure for "binding configurations", i.e. the { ..} part of item files. Any such definition for which there is NO reader available will end up in the meta data registry through the GenericMetaDataProvider.

As an example, this allows to do definitions like:

Switch "My Fan" { homekit="Fan.v2", alexa="Fan"[type="oscillating", speedSteps=3] }

Note that also the new configurations can be used to provide key-value maps if necessary.

The item endpoint of the REST API has been extended to directly include meta data for given namespaces in an item response, so that it should be easy for external clients to get hold of the data.

Still to do:

• Handling of exceptional cases (e.g. delete requests for read-only meta data)
• Code polishing
• Unit tests
• Documentation

Signed-off-by: Kai Kreuzer [email protected]

[kaikreuzer]

@beowulfe, I would like to validate that approach with you.
My hope is that this new feature would allow to refactor the homekit add-on in a way that it does not rely on item tags (only), but on meta-data instead. A thermostat could e.g. look like:

Group Thermostat { homekit="Thermostat" [units="Celsius", name="Kitchen"]}
Number Temperature (Thermostat) { homekit="temperature.current" }
Number Temperature_Setpoint (Thermostat) { homekit="temperature.target" }

Alternatively, it could even try to derive some information when no meta-data on the group is specified:

Group Kitchen
Number Temperature (Kitchen) { homekit="thermostat:temperature.current" }
Number Temperature_Setpoint (Kitchen) { homekit="thermostat:temperature.target" }

-> auto derive a Thermostat service with the following capabilities:

thermostat:name=Kitchen (taken from the group's name)
thermostat:temperature.units=Celsius (once we have unit support on Number items)
thermostat:heating-cooling.current = Heat
 (e.g. when target is higher than current)
thermostat:heating-cooling.target = auto

This would give you the full flexibility to do mappings to the HomeKit definitions. We should imho try to keep support for a common semantic tag library in the add-on, so whenever there is a good mapping from ESH tags to Homekit, that could be automatically derived without requiring from the user to specifically add homekit information.

What do you think about this approach? Would that work for you?

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/new-binding-hue-emulator-amazon-echo-integration/7944/193

[SpeedmaxX]

Hi, did you do any steps forward in this issue in the background?

[marziman]

@kaikreuzer,

really cool stuff. Took a look and it would be great to have this officially available. I think the docu part is important next to the unit tests. Great job!

Any idea, when this can go into core? Do you need support with testing this?

BR Mehmet

[maggu2810]

Hm, this would be a good candidate for the cleaned up (Generic)UID base class usage. 😉

[sjsf]

Nice - didn't have it on my radar either...

[sjsf]

As agreed with @kaikreuzer I continued this PR in order to push forward this topic.

Thereby I

• rebased it onto the latest master (therefore - as aligned - the force-push instead of a PR against this PR)
• renamed MetaData to Metadata as it's a single word (apart from that I left the initial commit untouched)
• introduced an AbstractUID class (as already attempted in [WIP / RFC] move generic UID stuff to a seperate class #4891 - now we have the use-case for it as @maggu2810 pointed out in [Core] Added item metadata infrastructure #4390 (comment))
• let the MetadataRegistry listen only on the ManagedItemProvider instead of the ItemRegistry in order to perform the clean up in its managed provider. Otherwise it would happen also when a provider disappears.
• added tests for the whole enchilada
• added some conceptual documentation
• some minor fixes here and there

Yet missing is the adaption of the Paper UI.

[kaikreuzer]

@digitaldan & @beowulfe: I have just rolled this change out to openHAB - so the metadata infrastructure should be available for Alexa & Homekit integration in the openHAB IDE (after refreshing your target platform). Please note that you are the Guinea pigs for that - if you run into any issues, please report them!

Here you can find an example service that uses metadata - you'd have to do something similar to get access to it.

[marziman]

@kaikreuzer you forgot me. Since the Google Assistant integration should also use the metadata approach. Can you point me on some example on how this will look like in a concrete example.
So I can go and directly bring this into Google Assistant integration?

@digitaldan & @beowulfe Yes please! Lets arrange for some "common" convention to have a not-complicated way to use this in the real world integrations.
As I didnt follow the complete PR code, I would be happy with proposals. Otherwise I can give it a try and propose sth. I already have similiarities with Alexa, but some tags differ.

Thanks & BR
Mehmet

[kaikreuzer]

you forgot me

I didn't, I just thought you do not want to be a Guinea pig 🐷 !
But sure, the same is also relevant for Google Assistant integration.

Can you point me on some example on how this will look like in a concrete example.

I gave an example DSL in the comment above and a link to the code that consumes this data just before. Some short documentation had been [added here] - that's all there is right now.

[andylintner]

Awesome! One thing that adds a decent amount of complexity to the HomeKit addon is the code that tracks items in a Group that need to be composed to form a HomeKit accessory. If I was to abstract that out from HomeKit, so we only have one implementation instead of many, where's the right place for that?

[digitaldan]

@kaikreuzer fantastic

I have just rolled this change out to openHAB

So is this available in the nightly builds then?

[digitaldan]

So is this available in the nightly builds then?

nevermind, I see that it is :-)

[kaikreuzer]

If I was to abstract that out from HomeKit, so we only have one implementation instead of many, where's the right place for that?

@beowulfe I am not quite sure what kind of methods/features you have in mind for this. Could you elaborate on it / give an example? Is it something that could be potentially added to the MetadataRegistry?

[andylintner]

@kaikreuzer - that might work. Let me get something working and I'll start a PR for discussion.

[marziman]

Hi @beowulfe @digitaldan
did you already included this? Since it is a good point (and people ask me, in tagging confusion) I would be happy to follow (or help to create) the new semantics.

BR Mehmet

[digitaldan]

@marziman yes we have this already implemented in the v3 version of the Alexa skill, see https://github.com/openhab/openhab-alexa/tree/v3 .

@marziman and @beowulfe while we have a specific metadata syntax for Alexa v3, we have been discussing keeping a more basic form that would keep things simpler for most users, and is similar to the syntax we have in tags. We would like to have consistency with homekit and google on this. We are proposing to support the following "labels"

Lighting
Switchable
Lock
Thermostat
CurrentTemperature
TargetTemperature
(homekit:)HeatingCoolingMode
LowerTemperature (new)
UpperTemperature (new)
ColorTemperature (new)
Activity (new)
Scene (new)
EntertainmentChannel
EntertainmentInput
MediaPlayer
SpeakerMute
SpeakerVolume

I realize this is probably the wrong thread to discuss such things, but wdyt as a starting place? See https://github.com/openhab/openhab-alexa/tree/v3#labels-concept for more info on "labels".

@jsetton has been working on this as you can see at openhab/openhab-alexa#68

[marziman]

@digitaldan:

Your proposal is pretty cool on Google Assistant side. We currently use these tags:

• Lighting
• Switchable
• Thermostat
• CurrentTemperature

So this fits to the proposal. Fine from GA side, and I would like to switch to the metadata style these days.

@beowulfe: Is that fine for you, too?

Just need to setup my installation and need to try it out.

BR Mehmet

[andylintner]

Those look great to me as well. Thanks for pulling those together @digitaldan

[digitaldan]

Those look great to me as well. Thanks for pulling those together @digitaldan

As much as I would like to take the credit, @jsetton came up with those :-)

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/additional-key-value-attributes-field-for-genericitem/48037/5

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/what-kinds-of-devices-does-the-google-integration-support/61661/1

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/what-kinds-of-devices-does-the-google-integration-support/61661/1

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/what-kinds-of-devices-does-the-google-integration-support/61661/1

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/what-kinds-of-devices-does-the-google-integration-support/61661/1