Hue Emulation re-sequences HueId's on openHAB service restart - Causes out-of-sync with Alexa

Like others, I upgraded to 2.4 release recently, and I’ve also been tweaking the OH Config files to take advantage of the updates, as well as add/remove the Lighting tag on various items.

For me, the HueEmulation has been getting out of sync after certain openHAB configuration changes, resulting in odd behavior across openHAB Service restarts. It looks like the advertised/mapped HueId’s are changed, and no longer match what’s stored in Alexa (from it’s original Discover Devices)

The behaviour is that you’ll ask for a light to be turned on, and some other device will go on instead.

Looking at the Hue Storage JSON (the map between the HueId’s and the Item name):

I observe that, upon openHAB service restart, this file is emptied out at some point in the process and then rebuilt. To restart, I’m using:
service openhab2 restart

Using watch on this file, against a backup, during the service start I can see that it’s getting cleared out and then rebuilt with newly resequenced HueId’s.

To reproduce the issue:

  1. Backup the Hue Storage in /var/lib/openhab2/jsondb/hue.emulation.lights.json
  2. Edit an Item, and disable it’s Hue tagging (eg Lighting -> LightingDISABLED)
  3. Observe it disappear from the existing Hue Storage file, leaving a hole (expected)
  4. <at this point it’s still known by Alexa, no biggie>
  5. Restart the openHAB service (service openhab2 restart)
  6. Observe the Hue Storage file eventually get blanked out ({})
  7. After a while, the Hue Storage will be rebuilt with new Id’s (off-by-one in many cases now)

Once the HueId’s are generated/persisted into the Hue Storage, I expected them to be immutable for a given openHAB Item. I’m not sure why item (6) is happening, but it seems to be the root cause of the off-by-one issues when accessing the Lighting controls via Hue. Presumably similar things happen when Lighting Items are added to the config files.

I can delete the Alexa-discovered stuff, and re-discover Devices, but I have a lot of them (20+) so I’d like to avoid that.


  • openHAB 2.4 release, using config files for items, things, etc
  • Ubuntu 16.04.10 (Linux version 4.4.0-140-generic) VM
  • Amazon Echo Dot gen 1 & gen 2 (and an Alexa-enabled Brilliant Tech device)

The observed behaviour is similar to this discussion:

1 Like

@David_Graeff Let me know if you’d prefer to have this as a bug. I posted here to create any needed discussion.

Overall, seems like the Hue Storage should never be cleared out/reset, only added to. This will have it’s own issues over time, but they’ll not be as bad as corrupting the Alexa config (or making openHAB out of sync with Alexa)

Thank you for this analysis. I didn’t had time for this yet, but I also noticed random re-associations.
That’s clearly a bug, yes. If possible please create a report on Github.

Wow! I asked Alexa to turn off the lights and the door to the vacuum cleaner charging “cave” opened! I can see in the Alexa app that what used to bind the light switch to the Alexa group with that Echo now is bound to this other item.

I asked to tun on the kitchen and my bed light went on. We definitely should tackle that.
But I need the bug report first. I have no idea about json-dbs internal structure and it’s purge rules, but
some other developers do.

Sorry for the delay, filed as:

1 Like

I need some testing help soon.
I have solved the re-sequence problem by using item metadata and also added hue scene, rules, and schedule support:

But I do need testers. I would announce that here if anyone is interested?


I am interested. I would be happy to test your updates to the HueEmulation binding.

I’m also interested in testing. I’m currently using a 2.5-Snaphot-Version from January of the hue emulation with four Echo devices. I would be happy to help.

The provided zip file in the reference issue works on OH 2.5M1 and snapshots.

I wanted to perform a stress test today but my Eclipse IDE decided for me that I should not do OH development today :smiley: So that has to wait.