[homekit] support multiple Enum Values for current state of accessory

[grzegorz914]

Hi,

right now we can define for accessory characteristic current state only one Enum Value, for example thermostat current heating cooling mode HEAT(1), COOL(2), etc... I have many devices which report HEAT(1), SUPER HEAT(3), COOL(2) SUPER COOL(4), in this case I want to show thermostat current state HEAT[1,3 ]and COOL[2,4]. I think it can be use as one of.

Thanks Grzegorz

[lsiepel]

Is https://github.com/openhab/openhab-addons/pull/17134 solving this issue? Maybe a test jar can be provided to check if this meets your ideas.

[grzegorz914]

I don’t think this PR solve this, the enum values need to support array of multiple values for characteristic. Right now we can define enum but only single value is accepted just like currentHeatingCoolingState.COOL == 1, in my case we need to check any value of array like currentHeatingCoolingState.COOL == one of array[1,3].

[lsiepel]

@ccutrer has some great velocity regarding the homekit binding, maybe this is something he can also look at.

[ccutrer]

Heh :). I looked at this one for a moment yesterday already! It's semi-related to two other things. First, the linking CurrentHeatingCoolingMode to a Switch bug I fixed yesterday was unable to return COOL, because of how switches build up their enum mapping - multiple openHAB values mapped to a single HAP enum value. Which is essentially what this issue is for!

The other related issue that I have a WIP commit--but I've shelved for now-- is that I have a String item from a Home Assistant based lock that I'm trying to expose to HomeKit. It has values "LOCKED" and "UNLOCKED". But to unlock it, you send "UNLOCK" - i.e. the state is an adjective, but the command is a verb. So I need to both configure the openHAB addon to support multiple values for the enum, but also in a way that I know which of those values is used when a command comes in from HAP.

Story time aside, let's talk implementation. Ideally this is done by having multiple values for a a single key in the configuration of the item. But I don't know if that's possible when configuring from the UI or files (I know it is technically possible from the underlying data model, because we already deal with booleans and different types of numbers vs sometimes always being strings). Assuming I can't just rely on that, I'm wary of simply taking a string value, and splitting on commas or pipes or something to get multiple values, because it's theoretically possible that someone needs that character as the actual value. Thoughts?

[ccutrer]

Okay, I've done my testing. When using JRuby, I can easily assign an array to a metadata configuration. When using MainUI, after creating a custom metadata item, you're simply given a YAML editor which easily accepts an array instead of a scalar value. When using MainUI specifically with the HomeKit metadata key, there's a helpful editor for single characteristics to allow providing your own mappings, but you can switch over to the Code view YAML editor same as any other metadata. Interestingly, when you put an array here, then switch back to the more basic Config view, it will display the array as a comma separated string! But if you modify it here, it will get persisted as that string, so one must be careful.

The speed bump is file-based items. Doing String TestString2 "Test String" { key="value"[key1="value1", key1="value2"}, "value2" simply overwrites "value1". Doing String TestString2 "Test String" { key="value"[key1=["value1", "value2"]} results in a syntax error. I think I'll try to get a PR into core to support arrays here. Then this ticket becomes far more straight forward.