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?
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.
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.
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.
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.]
@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.
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.