What I found is the order of the elements in the config file is important. That is, the tags in the square brackets need to be at a certain place in the line. Here is an example of a working line from an items file. Hope it helps.
Switch BasementStairLight “basement stair” (ALL,lights,ff,bs,ffA) [ “homekit:Switch” ] {insteonplm=“1F.4D.6E:F00.00.12#switch”}
and here is a group entry that also works:
Group ffA “First floor lights” [“homekit:Switch”]
Doesn’t seem to matter where I place mine. I still get that error at the beginning of the line.
I have successfully installed the Emulator and added the necessary tags, light ON/OFF functionality is working very well. Thank you for taking on this effort.
I am using an Insteon PLM for signaling and I have discovered the Insteon binding is reporting “command XX is not implemented yet” for percentage changes. The same commands work fine from other UIs.
I have isolated the difference to the received command value.
From the Hue Emulator - the command is a DecimalType
From other UI’s - the command is a PercentType
Not sure if Insteon Binding should play better with a DecimalType or Hue Emulator should send a PercentType
Any ideas would be appreciated.
Hi Scott, thanks for the feedback! Yes I am blindly sending this as a Decimal type which is probably not great, give me a sec and I can put an updated version up for you.
can you try this and report back?
https://github.com/digitaldan/openhab2-addons/releases/download/HueEmulator-1/org.openhab.io.hueemulation-2.0.0-SNAPSHOT.jar
Amazing turnaround time. Works very nicely. Thank you!
No problem, you did the hard work of isolating why it was failing, so thank you 
i have problem with Milight binding,
item received command, but the light isn’t turning OFF
=================================
EDIT: my bad. i forgot the binding config. sorry
Hi Farhan, is the Milight binding working for you under OH2? The reason I ask is it looks like OH2 correctly gets the command, but it’s like the binding is not loaded, can you control your lights from the Classic UI or mobile clients (in OH2)? I’ll try and find some time to look more on mind end for you.
oops… you’re right @digitaldan, forgot the binding cfg.
my bad, sorry about that.
anyway, this ia one of my milight bulb
Switch Bedlight "Bedlight" (bLight) ["homekit:Lightbulb"] {milight="bridge1;7"} Dimmer BedlightB "Brightness" (bLight) {milight="bridge1;7;brightness;27"}
Turning ON and OFF is good, but not brightness.
how should i tag my item?
use ["homekit:DimmableLightbulb"] , also download a new version of the jar here https://github.com/digitaldan/openhab2-addons/releases/download/HueEmulator-1/org.openhab.io.hueemulation-2.0.0-SNAPSHOT.jar
This should handle both percentage and decimal types, I just updated it and did not have a chance to test, so let me know how it goes.
so…question. …
what if i also have homekit installed as well? will the tags work for both at the same time?
Yep, that’s by design, we wanted to have a single tag format that would work across different bindings and apps.
thats kinda cool…thanks
I just installed OH2 beta 3 and bought an echo today. Tried to get this working. I have tagged a few switches for lighting (looks like right before the beta release the tag syntax changed from homekit: to bare words. IF that’s wrong please let me know. The bigger issue is that device discovery from echo isn’t working. I added “hueemulator” to the “misc=” line in my addons.conf. I now see in the device log a line that says:
2016-06-02 14:41:58.503 [INFO ] [ulation.internal.HueEmulationServlet] - Started Hue Emulation service at /api
I did enable pairing in the paper ui and restart openhab (just in case).
The echo isn’t seeing the bridge. I did a wireshark capture and I’m not seeing any UPNP multicast from the openhab IP. I tried to figure out how to debug the log like you guys were doing above here but the closest I can get is to logging into the karaf shell and tailing the log. The only examples I can find are “log:set DEBUG org.openhab.binding.zwave”. I tried “log:set TRACE org.openhab.misc.hueemulation” but that didn’t change any log levels…
I would really appreciate some help at least getting logging going.
The binding was changed to support “Switchable”, “Lighting”, and “TargetTemperature” tags, although i have not tried it yet.
Yep, the binding is activated
The echo should be initiating the discovery by sending a multicast UDP packet on port 1900, the emulator binding then should respond back. You can enable more verbose logging at the osgi console with log:set INFO org.openhab.io.hueemulation . I’m assuming both are on the same subnet?
sorry thats log:set DEBUG org.openhab.io.hueemulation
Thank you so much! The logging worked perfectly. Much to my surprise after I enabled logging it connected perfectly.
I am wondering if I needed to give it more time to come all the way up. I am using a Raspberry PI 3 so it can be a bit pokey.
To be clear I am using the [“Lighting”] tag and it works perfectly.
It’s absolutely the coolest thing since bubbles.
Hi there
maybe someone can help me, too.
I’ve also been trying to connect Alexa aka Amazon Echo to OH2.
My setup:
The hue emulation service is running and pairing is set to enabled. Here are the respective lines from the OH Log:
15:07:32.759 [DEBUG] [ulation.internal.HueEmulationServlet] - Device pairing enabled : true
15:07:34.103 [DEBUG] [org.openhab.io.hueemulation ] - BundleEvent STARTED - org.openhab.io.hueemulation
Now, whatever I try, I can’t get Alexa (or the Paper UI for that matter) to discover my items which I set up in the hue emulation.
Here’s the item line I’m using (I’m trying to control a knx switch - which works from the classic ui, by the way):
Switch TestSwitch1 “AZSwitch” e[ “Switchable” ] { knx=“1/0/0” }
And here’s the log entry which happens right after I try discovering items with Alexa:
15:08:27.811 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.112: GET /api/discovery.xml
15:08:27.813 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/discovery.xml
15:08:27.815 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/discovery.xml
15:08:27.813 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.112: GET /api/discovery.xml
15:08:27.815 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/discovery.xml
15:08:27.815 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/discovery.xml
15:08:28.395 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/OyjvZvxuZN1ICL5maCrIahzw5TBEZLsbDBcSkkmk/lights
15:08:28.508 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/OyjvZvxuZN1ICL5maCrIahzw5TBEZLsbDBcSkkmk/lights
15:08:29.037 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/OyjvZvxuZN1ICL5maCrIahzw5TBEZLsbDBcSkkmk/lights
15:08:29.259 [DEBUG] [ulation.internal.HueEmulationServlet] - 192.168.178.124: GET /api/OyjvZvxuZN1ICL5maCrIahzw5TBEZLsbDBcSkkmk/lights
The IP 192.168.178.112 is a Bose SoundTouch, which for some reason seems to be involved here.
Last but not least - I’m using OH2 beta 3
If you need any more information, let me know.
Best