Hue Emulation on 2.4

The upgrade to 2.4 has this message

Warning: Hue emulation: The item to hue ID mapping is no longer stored in files, but in the openHAB storage service. You need to rediscover “devices” in all services that use the hue emulation (Amazon Echo, Google Home, etc).

yet when I look up the latest documentation

it still mentions demo.things & demo.items for hue.

I’m working completly file based. Using files for a main system and a system to test.
That way when things work on my test system, I can turn it into my main system and I cant easily have the same setup on the other system.
(Important to try out new version of openhab )

So my question is, can anyone explain to me what “he item to hue ID mapping is no longer stored in files,” means?
Is that for the internal system and can I still use my files for setup?

Hue emulation is not provided by the Hue binding, rather by the Hue Emulation binding.

There is no manual, file-based configuration for the item to hue ID mapping for the Hue Emulation binding. Your usual file-based configuration can still be used for add-ons, things, items and rules.

1 Like

ah I had no idea that was something different.

file-based configuration for the item to hue ID mapping for the Hue Emulation binding

Brings me to another issue. I was controlling other openhab things from alexa before.
Are there changes to other alexa controls?

I had a virtual item
Switch Alexa_Kitchen_Light “Kitchen” <light> (gGF_Kitchen ) [ “Lighting” ]
Where a rule did the updates when this one changed

Was this based on hue emulation?

What do I need to check to know?


It looks like you were using the Hue Emulation binding for that item, the tell is your item name and the ["Lighting"] tag. There would be nothing else you might check, the tag provides the linkage to the Hue Emulation binding.

1 Like

ok. That is clear.
so this no longer works?

It does work, but the Alexa pairing process is slightly different from the original. You should read the documentation at the link I provided. I am currently using it successfully.

That page talks about Paper UI, which I don’t use .
I’m doing everything file based.
I don’t want manual installations, that gives troubles when I swap between openhab installs.

For Hue Emulation, you have no choice but to use the PaperUI, it provides the means to enable pairing when Alexa is discovering new devices.

Sad that the older way of working is no longer supported.

Like I said Paper ui is not an option for me.

I’ll wait till we have again file based configuration for hue emulation.

To be honest, I don’t think there was ever any other way to allow Hue Emulation items to be discovered by Alexa. You must have been able to do it when you originally configured your system or Alexa could not have discovered your emulated devices.

Not sure I understand

You must have been able to do it when you originally configured your system or Alexa could not have discovered your emulated devices.

I’m not interested in automatic discovery.
I’m ok with manually configuring
and that did work before.

And from what I understand, that manually configuration in files, is now no longer working, in favor of automatic discovery.
I understand that some people like the automatic discovery. I understand it’s added.
I don’t understand that something that was working fine was removed.

I get the impression you are confusing discovery of OpenHAB things vs. Alexa discovering smart devices provided via the Hue Emulation binding, they are not the same. You can still manually configure your OpenHAB things, just as you did before this upgrade. Some of the syntax for configuration may have changed, but manual configuration is still possible, in fact, that is my preferred method for configuring OpenHAB things. To the best of my knowledge it has never been possible to manually provide for Alexa’s smart device discovery process.

I guess I did mix these two up

then I still don’t understand the upgrade message that I posted at the start of this thread

The item to hue ID mapping is no longer stored in files

My question remains: is this the configuration files or is this an internal file.
if it is an internal file (as I know become to think) then why is this a breaking message to tell during an upgrade?

What I do get from the page you mentioned earlier, is that paperUI is needed to turn on the pairing with alexa.(so that alexa can discover the devices)
(using the names I give in an items file)

So what I think now has changed is that before the discovery/pairing was always on and now it needs to be turned on.
I think that is indeed a good thing. Yet at this moment (at least that is how I understand it) it needs to be turned on from paperUI. where I hope that one day it will be possible to do it from a .cfg file.

I’m not sure where or what file(s) the hue ID mapping for Hue Emulation used before this update. Regardless, I don’t think that mapping file was user editable or configurable, it was always generated by the Hue Emulation binding.

So others may learn from our discussion here, perhaps you could change the title of this thread to something like Hue Emulation Binding vs. Hue Binding on 2.4.]

1 Like

Sound logical to me.
so the message sounds more like: you need to rediscover your openhab items in alexa after re-installation.
(and you need paperUI for it)

@yves, I’ve continued researching your issue. It may be possible to control some settings of the Hue Emulation binding from a text file. On my system I found the file /var/lib/openhab2/config/org/openhab/hueemulation.config. It contains the following:


I haven’t tried changing the value of pairingEnabled to B"true" to see if that would enable emulated Hue device discovery for echo devices, but you may want to give it a try. It may even be possible to create the file /etc/openhab2/services/hueemulation.cfg with this content, which would be a similar process to that used for other bindings.

1 Like

That is not necessary. Hue emulation is a normal openHAB service. If can consume service configuration via Paper UI, the openHAB console or service text files. But I do not see my responsibility as an author of the hue emulation binding to tell a user. I would repeat the general documentation, that already exists.

The file was never intended to be editable by the user and is isn’t intended to be editable now, correct.
Before it was stored in a lined based ItemID=hueID file and now it is stored as json file via internal framework means. That’s all that the breaking changes messages is saying. Doesn’t have to to with textual vs Paper UI configuration.

Fair enough, but do you not view it as your responsibility to document the available Hue Emulation binding setting keys?

[Update: I see those keys are documented in the binding documentation, but it isn’t clear from that documentation where those keys may be used.]