[hueemulation] Group items can no longer be exposed as hue devices

Development Add-ons
1

I have always exposed many OH groups as devices, and controlled those with Alexa.
This is a typical setup for a room (worked for years):
Group:Switch:OR(ON,OFF) gKitchenGroup “Kitchen Lights” (gLightsLivingRoom) [ “Lighting” ] { expire=“3s” }
Switch KitchenLight “Kitchen Sink Lights” (gKitchenGroup) [ “Switchable” ]
Switch KitchenRoofLights “Kitchen Roof Lights” (gKitchenGroup) [ “Switchable” ]
Dimmer KitchenFanLights “Kitchen Fan Lights” (gKitchenGroup) [ “Lighting” ]
Dimmer KitchenFloorLights “Kitchen Floor Lights” (gKitchenGroup) [ “Lighting” ]

I used to see the “Kitchen Lights” as a Hue device, which I would bind to the Amazon Echo in that zone so I could say “Alexa, lights please” etc.

With 2.5, this seems to have been changed with the new support for Hue Groups. I can see now that a an OH group will only result in a Hue group, even with device tagging. (Can I use the Hue Group for anything?)

At my home, I’d like to still be able to use a Group as a device, so I’m currently running a self-patched version of the Hue emulation binding, where tags take precedence over item type.

Question is: Should I make this into a PR? Maybe add some doc? Or is there a better way (without scripting) to keep backward compatibility? (I know this has broken at least a couple of times before… )

@David_Graeff
@Kai

2

Which 2.5 version are you using? Milestone 5 just got released/

3

Hi, I was using M4, then switched over to master and compiled myself.

4

Hue Groups are a natural fit for OH Groups. But it is true that Hue groups are not well supported on anything other than the original Hue App.

What might work is to expose those groups as “rooms”. I think Alexa supports Hue rooms.

A “lighting” tag should IMO not decide if an item is exposed as Hue Light or Group though. But another tag could be added to control this behaviour.

2 Likes
5

Hello David,

thanks for your many helpful comments here. Im using OH 2.5 last snapshot. Before I used OH 2.3 and 2.4. Never had any problems. Tried the HUE emulation, and my problem is that those groups (and many others)

Group:Switch morgen “Morgen” [“Switchable”]
Group:Switch abend “Abend” [“Switchable”]
Group:Switch nacht “Nacht” [“Lighting”]

are not exposed to Alexa, while

Switch Stehlampe_Studio “Stehlampe Studio” (F3_Studio, gLight, light_studio) [“Switchable”]

works fine. All items with group:switch are not exposed.

Any possibility to solve this?

Nicolai, could you give me your patched version of Hue emulation?

Many thanks

Marcus

6

Hi @cuse

I posted a .jar file here:

Great that you are giving your feedback here!
I would love more involvement from others on the breaking change in 2.5.

@David_Graeff shouldn’t the behavior be left intact as it was for explicitly tagged groups, until a definite solution with new usable features is in place? Is there an advantage by adding Hue Groups? Does anyone use the Hue app to control OH? I don’t use Hue app or bridge myself, and I’m not familiar with Hue rooms either.

1 Like
7

Many thanks Nicolai! You are absolutely right, would really appreciate if the tagged groups would be working again. Its a lot of work in my case to keep the system running with rules etc.

8

Nicolai thank you very much for posting this patched file, now it works again! You did a great job! Had many trouble with OH due to hue emulation over the last weeks (devices not found etc.). Now everything is perfect again. openHAB 2.5.0 Build #1762

1 Like
9

I’m using hue emulation exclusively for the hue app. It’s not easy because the SSL certificate must be created in a specific way, so it’s probably not the common case.

2.4 to 2.5 is a breaking change for the hue emulation anyways because it’s an entire rewrite and emulates a V2 bridge, I don’t see a point in trying to be backwards compatible. Hue groups is part of the api and maps to OH groups and can be used by the app in the intended way. Just because Amazon’s implementation doesn’t handle groups shouldn’t be the reason not to use them. Just my opinion.

1 Like
10

Isn’t it possible to introduce Hue groups as a non-breaking change? E.g. By using a new tag, leaving the old as-is?

11

Technically, of course it is possible. But I guess this is not what you are actually asking for :smiley: The answer to the question “Can we not use the expected standard behaviour for a hue api server implementation?” is unfortunately No as long as I’m the maintainer :slight_smile:

It is a breaking change that is correct, but it is also a fact that the former implementation was a hacky incomplete implementation that just didn’t care about anything else than /api/lights.

But it is a one liner linux shell command to add a “use_base_type” tag to your item files for all items that are groups. That is if we decide on using such a tag to tell io-services to treat a group like the groups base type.

1 Like
12

do you mean I just have to add [“use_base_type”] to the item and it should work?

like this:
Group:Switch down_haus “Haus schließen” <rollershutter> [“Switchable, use_base_type”]

13

Could you explain how and what you changed in the .jar file? Thanks

14

This is not implemented. This matter is currently discussed.

15

Inside LightsAndGroups.java, in the added(Item newElement) function:

if (element instanceof GroupItem && StateUtils.getTaggedDeviceType(cs, element) == null) {

In StateUtils, I refactored that function out of DeviceType determineTargetType(ConfigStore cs, Item element):

 public static @Nullable DeviceType getTaggedDeviceType(ConfigStore cs, Item element) {
        Set<String> tags = element.getTags();
        if (cs.colorFilter.stream().anyMatch(tags::contains)) {
            return DeviceType.ColorType;
        }
        if (cs.whiteFilter.stream().anyMatch(tags::contains)) {
            return DeviceType.WhiteTemperatureType;
        }
        if (cs.switchFilter.stream().anyMatch(tags::contains)) {
            return DeviceType.SwitchType;
        }
        return null;
    }
16

@ngrodum can you give me a hint how to turn the debug log on in karaf and/or what debug info I should collect?

I am still getting a response from Alexa saying sorry something went wrong. This happens on a fresh install of 2.5m5 with the new jar file. The command works, but I don’t get a successful response. I wanted to try to chase down where the error is. My items have worked with Alexa since 2.3 and have not changed.

17

perfect, thank you very much!

18

I have made a PR that allows us to continue using Group type items as exposed lights:

19

Thanks!

20

@ngrodum I see this is in the release candidate.

Any chance you could link me to the jar file? I don’t want to upgrade just yet. Due to available time, Was going to wait for the release, I would like to test the new group feature though.

Also where do we put the tag? Is it with the lighting tag or elsewhere?

1 Like