Hey All-
I have been using Openhab2 for quite sometime with no issue. I recently upgraded to 2.5.0-SNAPSHOT (#1479). I have items/rules/sitemap defined in the config files, and I’m attempting to use the Hue Emulation Binding to interface with an Echo Dot (v2). It starts off fine, but after a few hours a voice command to Alexa for one device will result in unexpected behavior, e.g. Turn On Kitchen will Turn On Bedroom. I’m not seeing any issue in the logs - anyone have some ideas?
Philips hue assigns each bulb a unique number when a bulb is paired the first time. This mapping got lost from 2.3 to 2.4 because the underlying storage changed. So all your items got another number and you must perform a rediscovery after upgrading.
I removed the binding, deleted every hue related file on the openhab device, and removed all lights from the Alexa. I did a fresh discovery and tested every device, they all worked fine at first, within about 3 hours the devices are completely randomized.
Do you have multiple echos? Each echo keeps its own list and I had the problem that “removing all devices” never really removed all devices. Have you read the troubleshooting section of the documentation? Check if the IDs stay constant. If they do, the hue emulation works as intended.
I do have multiple echo’s - I ran the diagnostic on the emulator and that seemed fine so I went ahead and factory reset the echo’s…
So hard resetting helped but i have a few switches defined that are ‘virtual’ meaning there is no device/channel associated with it but it is connected to a rule - e.g. kitchen is a virtual switch which triggers a rule that will turn on several different lights. These rule based switches are where the issues are…
If you create items on the fly, they will get new hue ids assigned each time.
I just created groups in Alexa since that is the only place I used those rules and seems to be fine now ¯_(ツ)_/¯
@David_Graeff, Since updating to an OH2 release that includes the reworked Hue Emulation binding, I have experienced ongoing problems with emulated devices being discovered multiple times, which seems to cause problems when issuing voice commands to Alexa, the most annoying example of which is when Alexa responds that there are multiple devices with that name, please use unique names … (or something very similar.)
I understand that you cleaned up the internals of the binding, which is a good thing, but the functionality for my use has been compromised. Maybe I’m missing some new binding setting that would help ameliorate this issue, but I don’t know what that might be. I don’t recall experiencing this particular problem with the original Hue Emulation binding.
For completeness of this post, I have several echo devices of varying generations:
You need to clear devices first. Make sure they are really gone by refreshing the Alexa app multiple times. Then rediscover. The hue emulation assigned new hue IDs in 2.4 so Alexa knows devices two times if you have not cleared everything. Happened to me twice when I changed from the original hue bridge to Deconz to openhab.
I had my Alexa and Hue Emulation devices working fine after following your advice to have Alexa forget all devices, then refreshing the Alexa app multiple times. My Alexa devices all worked without issue for the several days that I ran 2.5.0-S1484-1 until I upgraded OH to 2.5.0-S1491-1 today. Before restarting OH, I recursively deleted the contents of ${OPENHAB_USERDATA}/cache/ and ${OPENHAB_USERDATA}/tmp/. I waited until the system was completely operational before testing with the Echo Dot here in my office – no joy. It seems Alexa is looking for lights that were forgotten the last time I cleared all devices “she” had discovered.
I presently have 24 emulated devices, yet Alexa was searching for status on devices 39, 40 and 41:
2019-01-06 11:35:20.048 [DEBUG][qtp15581631-876][ulation.internal.HueEmulationService] - 'Hue resource not available' for: /api/rGZYEaoJAcaLnnGb9KdG1u8Rf7FGZQOpg2blnSze/lights/41/state
2019-01-06 11:35:46.239 [DEBUG][qtp15581631-874][ulation.internal.HueEmulationService] - 'Hue resource not available' for: /api/rGZYEaoJAcaLnnGb9KdG1u8Rf7FGZQOpg2blnSze/lights/40/state
2019-01-06 11:36:05.359 [DEBUG][qtp15581631-246][ulation.internal.HueEmulationService] - 'Hue resource not available' for: /api/rGZYEaoJAcaLnnGb9KdG1u8Rf7FGZQOpg2blnSze/lights/39/state
It seems that those emulated devices were not forgotten, despite my having experienced zero voice control failures across all of my Echo devices since the previous OH restart. I’ll repeat the discovery process, but it seems I will have to rediscover emulated devices every time OH is restarted. Is your restart experience different?
Update after Alexa app discovery after requesting that Alexa forget all devices
Through the Alexa page rather than the Android app (Alexa app does not offer a “forget all devices” aciton, but the web page does), I rediscovered all my emulated devices. Each device is discovered twice, first as “Dimmable Light” devices, then as “Royal Philips Electronics smart device” devices. I then tested at each of my Echo devices to verify that there was no “multiple devices with the same name” issue for Alexa.
Screen region capture following discovery:
Auto-updated Hue Emulation config (/var/lib/openhab2/config/org/openhab/hueemulation.config) after discovery:
:org.apache.felix.configadmin.revision:=L"5"
createNewUserOnEveryEndpoint=B"false"
discoveryHttpPort="80"
discoveryIp="192.168.1.205"
pairingEnabled=B"false"
pairingTimeout="60"
restrictToTagsColorLights="ColorLighting"
restrictToTagsSwitches="Switchable"
restrictToTagsWhiteLights="Lighting,Switchable"
service.pid="org.openhab.hueemulation"
Are the multiple devices discovered attributable to the string “Switchable” appearing in the settings for both the restrictToTagsSwitches and restrictToTagsWhiteLights options?
Same for me. But that’s a bug on Amazons side, we are exposing all devices only once. But it still works for me, no “multiple devices with the same name” issue. Unfortunately Amazon will never fix that bug, we have to live with double discovered items for now.
Thanks for the reply, David (@David_Graeff). Glad to know it’s not just my setup or a US vs. DE firmware issue. Everything is working well to this point, so I will continue to monitor and report any anomalies.