Release Candidate for testing V5

[bwssytems]

Here is a release candidate for testing V5 that includes color raw control.

Use "${color.r}", "${color.g}", "${color.b}" for the replacement values,

For miLight use "${color.milight:([01234])}"

Get the release here http://bwssystems.com/files/ha-bridge-5.0.0rc5.jar

Update: New RC5 to try!

[tuicemen]

Is the color control all you need help with?
I have a couple color milights at the cottage if I can get them to work.

[FloFoer]

Note that the "${color.milight:([01234])}" for miLight does not only return the milight color value.
The exact usage for miLight is as follows: udp://ip:port/0x${color.milight:x} where x is a number between 0 and 4 (0 all groups, 1-4 specific group). The group is necessary in case the color turns out to be white. This is because white is handled different than normal colors. The correct group on must of course still be sent before that udp packet.

[tuicemen]

Thanks I'll give it a try on the weekend.
@bwssytems
I downloaded RC1 to try here which I use with a PC frontend for X10.
the return line now for a get devices call( GET http://host:port/api/devices) has changed from 4.5.6
the color info (hue, sat, effect, ct) seems to be missing or has changed location in the return string

This info no longer appears for me so the response order must have changed or that info as been eliminated.

[FloFoer]

@tuicemen This could be due to the new automatic color capability detection.
Every device has a property "type". Normal values for this type are "Extended color light" and "Dimmable light". Up until now all devices were Dimmable lights and the color info did exist regardless.

With real hue bulbs the properties hue, sat, effect, ct, xy, colormode get only returned if the light is color capable and the hue app relies on this, that means Dimmable lights would be displayed as color lights if they have one of these properties. Since this is not what we want the color info doesn't get stored (and thereby returned) anymore for non-color lights. That way the apps know if a device is really color capable.

HA-Bridge decides automatically if a device is color capable by the following rules:

1. If it's a Philips Hue passthru device look at the state returned by the real light: if it contains the attribute "colormode" it's a Extended color light, otherwise it's a Dimmable light.
2. If it's not a passthru it's a dimmable light if the new colorUrl is empty. Otherwise it's a Extended color light. (We have now a separate url additional to on/off/dim which gets executed if a color change request arrives)

The new groups/rooms (another new feature) are always displayed as color lights. It doesn't check what type the group members are.

[tuicemen]

That makes sense.
So then the bridge web interface should not display hue, sat... for non color devices but it does.
I'll know more if/when I get my milights working with the bridge.

[tuicemen]

Well I see why I took my milights and hub to the cottage.
This was a first generation hub and a royal pain to setup. It was working at one point but I can't get the hub re-configured since getting a new router. So unfortunately I can't test the color feature with milights :(
Although I was promised the milight hub was firmware upgradeable (and it does have this option) It isn't upgradable. I was told I need to by a new hub. Just checking the site I see they now have an even newer Hub which to me looks like a table lamp.
I suspect the new color option (for milights) added to the HA-Bridge only will work with the newest milight hub.
Should keep trying to get the first gen milight hub reconfigured or will it not work with this?

[davidhennemann]

its nice to see the progress of habridge in the last month :-) But i am still facing an issue with the color support and alexa. After setting up the Color-URL Alexa recognizes the device as a "color light", but after telling her to change the color to "red" for example, she keeps telling me, that the corresponding device does not support this. Changing the color with the "all 4 hue" app works. Am i missing something here?

[FloFoer]

@davidhennemann Yes unfortunately color does only work with apps and not with alexa. This is due to the fact that alexa does on/off/dim natively & local, but color works through the official hue skill. Since HA-Bridge is not linked to a hue account you can't link ha-bridge with the hue skill and thereby color commands aren't possible without programming a custom skill for alexa and exposing ha-bridge or another server as middle man to the internet. I described this behavior and the rooms feature here
I still implemented this because it's nice to have color at least via apps.
The only way at the moment to get anything like a color command with alexa is to create a device for each color. I did that for my milight ambient light. For example i created a device "Ambient blue" which is a stateless device which when i say "ambient blue on" changes the color and also sets the correct status for my main "Ambient" device, so that it's displayed correctly in my hue app. I also applied an ip filter to these color devices so that they are only visible to alexa and not in my hue app.

[Rockman18]

I use HA-Bridge since 2 days, since I've received my new Google Home.
I directly try the v5.RC and it works really well. Google Home app detects the local HA-Bridge when I want to sync a new home equipment Philips Hue without using online meethue API.
I use HA-Bridge to manage MiLights v6 with iBox bridge (the small lamp). I use a nodejs script to send udp commands as new MiLight API is more complicated than the first API.
Everything works perfectly (On, Off, Dim and Color).

Ex : color payload => node c:\Users\Me\habridge\milight.js 192.168.1.20 2 color ${color.r} ${color.g} ${color.b}

node : nodejs should be installed
c:\Users\Me\habridge\milight.js : absolute path to nodejs script
192.168.1.20 : bridge v6 ip address
2 : MiLight zone
color : mode (on, off, dim, color)
${color.r} ${color.g} ${color.b} : parameters (here rgb color)

milight.js.txt

Thank you very much for this HA-Bridge

[Andyjd86]

I would like to help test this out, I am using milight and smartthings, but when I upgraded to the beta I couldn't get any lights to turn on. could someone post an example? the following works in the stable release, but if I try it on the Beta nothing happens.
udp://ip:port/0x450055
I haven't tackled the colour options yet as I was hoping to get the standard white light on and off first. do I need to change the calls for standard white on and off now?

[Andyjd86]

I'm wondering, does this work with the older RGBW bulbs and on the v5 milight hub?

[FloFoer]

@Andyjd86 udp://ip:port/0x450055 should still work, i turn on my ambient light the same way.
Yes it works with v5 milight API. In fact v6 isnt't implemented in ha-bridge. It's still the simple udp variant.

[cspot78]

iPad editing working great on v5rc!

[Andyjd86]

@FloFoer thanks for confirming that it should still work. for me, it doesn't. when I click "test on" with the stable build, lights come on and the green confirmation popup shows in the top right. using the beta nothing happens at all.

I have managed to get a test entry to show up as colour in the smartthings app though which is good, just nothing actually happens still.

I can grab logs if needed, though an idea which bit to grab would be good.

[emigrating]

@bwssytems @FloFoer
So.. I'm having some issues with this.

Basically, I have some bulbs taking a UDP input in the form of setcolor,R,G,B and it's not working. That is so say, as soon as I send a color command thru HDBridge the bulbs turn off.

Sending setcolor,255,0,0 thru packetsender (ie. directly to the bulb - they are wifi enabled via ESP8266) turns the bulb red as expected.

Saying "Alexa turn the Living Room Red" (the bulbs are discovered as a SmartThings Device, dimmable, color, tunable white) turns the bulb off.

Using the SmartThings app turns the bulb off.

Using the Hue 4 All turns the bulb off.

What am I missing here? If I set the color command to a static value (ie. udp://ip:port/setcolor,127,32,87) works fine from all apps (as well as Alexa). Is there a conversion I'm missing between color.r and so on to actual RGB values?

[scallviz]

Updating from 4.5.6 to 5.0rc1 None of the external commands seem to run anymore.

Neither the test buttons in the webgui nor alexa control seem to trigger them.

Going back to 4.5.6 restores functionality

When I have time tomorrow I'll start with a fresh confog and see if that helps.

[emigrating]

@bwssytems @FloFoer
As as update to my previous post - I setup a packet listener to see what values were actually being transmitted and I must be doing something wrong somewhere, because what I get is;

Time: 2:34:11.061 pm
TO: You:55056
From: 192.168.0.150:50000
Method: UDP
Error: 

ASCII:
setColor,${color.r},127,32,

HEX:
73 65 74 43 6f 6c 6f 72 2c 24 7b 63 6f 6c 6f 72 2e 72 7d 2c 31 32 37 2c 33 32 2c

My actual call looks like

[{"item":"udp://192.168.0.183:55056/setColor,${color.r},127,32,"}]

Any ideas?!

[emigrating]

Ok, so more testing.

This time with the color.milight variable. If I send

0x${color.miligt:0}

nothing is transmitted at all and I get an error logged for spark.webserver.MatcherFilter. No actual error message is included however.

If I send a

${color.miligt:0}

I simply get that transmitted. If I send a

yourefuckingkiddingme${color.miligt:0}

I get exactly that.

Something is wrong :D

[FloFoer]

Seems like your placeholder doesn't get replaced.
Is this [{"item":"udp://192.168.0.183:55056/setColor,${color.r},127,32,"}] the whole thing? Because it should be [{"item":"udp://192.168.0.183:55056/setColor,${color.r},127,32,","type":"udpDevice"}]. The type is relevant for execution.

[Andyjd86]

Arne is driving, but would like to confirm that ${color.miligt:0} was a typo just in here not in his request ;)

[emigrating]

@FloFoer

Right, I'm back at my desk. I changed the type to UDP in the middle of testing, and it yields the same results.

So now I have
[{"item":"udp://192.168.0.183:55056/setColor,${color.r}","type":"udpDevice"}]
and it gives me
setColor,${color.r}
in my packet listener.

Also, in the dim command I have
[{"item":"udp://192.168.0.183:55056/setBrightness,${intensity.byte},"}]
and that goes over the wire as expected, i.e.
setBrightness,99,
or similar no matter whether the type is set or not.

What else should I be looking at in order to get this sorted?

Setting DEBUG for the log level I never see anything resembling these lines

log.debug("Color change with XY: " + x + " " + y + " Resulting RGB Values: " + rgb.get(0) + " " + rgb.get(1) + " " + rgb.get(2));
log.debug("Color change with CT: " + ct + ". Resulting RGB Values: " + rgb.get(0) + " " + rgb.get(1) + " " + rgb.get(2));
log.debug("Convert RGB to Milight. Result: " + milight + " RGB Values: " + rgb.get(0) + " " + rgb.get(1) + " " + rgb.get(2));

is it possible the RC1 version linked in the OP was compiled using the wrong ColorDecode? Or does this infact work for some people?

[FloFoer]

@emigrating
If i try this exact udp command at my setup it gets replaced. Of course you must put the item in the new colorUrl and not in the onUrl, otherwise the color placeholders will not work. You have it there, right?
If that's not it, maybe post the complete device config here and an extract of the debug log containing a failed color command.

RC1 works for me.

[emigrating]

@FloFoer
I have it in colorUrl. I was simply showing the dimUrl as it would get replaced no matter what type was set. As I said, if I put static values rather than the placeholders it works fine (obviously to the one color).

But sure, here's a complete device

{"id":"18","uniqueid":"00:17:88:5E:D3:12-12","name":"Test light","deviceType":"UDP","offUrl":"[{\"item\":\"udp://192.168.0.183:55056/setPower,on\"}]","dimUrl":"[{\"item\":\"udp://192.168.0.183:55056/setBrightness,${intensity.byte}\"}]","onUrl":"[{\"item\":\"udp://192.168.0.183:55056/setPower,on\"}]","colorUrl":"[{\"item\":\"udp://192.168.0.183:55056/setColor,${color.r},${color.g},${color.b}\"}]","inactive":false,"noState":false,"offState":false,"description":"This is a dimable, white tunable, color capable bulb.","comments":"Wi-Fi bulb."}

and here's a DEBUG log from the issuance of ON, thru DIM, followed by OFF and COLOR

09-29-2017 20:38:36.686 | DEBUG | httpMethod:put, uri: /api/3ad6b96dbe1c4aab98cd0e6293e20220/lights/18/state | spark.webserver.MatcherFilter
-- | -- | -- | --
09-29-2017 20:38:36.686 | DEBUG | get params | spark.Request
09-29-2017 20:38:36.686 | DEBUG | get splat | spark.Request
09-29-2017 20:38:36.686 | DEBUG | HueMulator PUT called on api/* with request <<</api/3ad6b96dbe1c4aab98cd0e6293e20220/lights/18/state>>>, and body <<<{"on":true}>>> | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:36.686 | DEBUG | get params | spark.Request
09-29-2017 20:38:36.686 | DEBUG | matchedPart: :userid = 3ad6b96dbe1c4aab98cd0e6293e20220 | spark.Request
09-29-2017 20:38:36.686 | DEBUG | matchedPart: :id = 18 | spark.Request
09-29-2017 20:38:36.686 | DEBUG | get splat | spark.Request
09-29-2017 20:38:36.686 | DEBUG | hue state change requested: 3ad6b96dbe1c4aab98cd0e6293e20220 from 192.168.0.183 body: {"on":true} | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:36.686 | DEBUG | validateWhitelistUser: a user was not found and it is not strict rules <3ad6b96dbe1c4aab98cd0e6293e20220> being created | com.bwssystems.HABridge.BridgeSecurity
09-29-2017 20:38:36.688 | DEBUG | Decode Json for url items: [{"item":"udp://192.168.0.183:55056/setPower,on"}] | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:36.688 | DEBUG | executing HUE api request to UDP: udp://192.168.0.183:55056/setPower,on | com.bwssystems.HABridge.plugins.udp.UDPHome
09-29-2017 20:38:36.688 | DEBUG | Request <<setPower,on>>, not done: false | com.bwssystems.HABridge.hue.DeviceDataDecode
09-29-2017 20:38:36.688 | DEBUG | Sending response string: <<<setPower,on>>> | com.bwssystems.HABridge.util.UDPDatagramSender
09-29-2017 20:38:36.758 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:36.758 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.60:4099, body: M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Content-Length: 0 MAN: "ssdp:discover" MX: 2 ST: urn:schemas-upnp-org:device:MediaServer:1 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:37.027 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:37.028 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.183:49197, body: M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 Man: "ssdp:discover" MX: 3 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:40.028 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:40.028 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.183:49197, body: M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 Man: "ssdp:discover" MX: 3 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:40.440 | DEBUG | httpMethod:put, uri: /api/3ad6b96dbe1c4aab98cd0e6293e20220/lights/18/state | spark.webserver.MatcherFilter
09-29-2017 20:38:40.440 | DEBUG | get params | spark.Request
09-29-2017 20:38:40.440 | DEBUG | get splat | spark.Request
09-29-2017 20:38:40.440 | DEBUG | HueMulator PUT called on api/* with request <<</api/3ad6b96dbe1c4aab98cd0e6293e20220/lights/18/state>>>, and body <<<{"on":true,"bri":99}>>> | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:40.440 | DEBUG | get params | spark.Request
09-29-2017 20:38:40.440 | DEBUG | matchedPart: :userid = 3ad6b96dbe1c4aab98cd0e6293e20220 | spark.Request
09-29-2017 20:38:40.440 | DEBUG | matchedPart: :id = 18 | spark.Request
09-29-2017 20:38:40.440 | DEBUG | get splat | spark.Request
09-29-2017 20:38:40.440 | DEBUG | hue state change requested: 3ad6b96dbe1c4aab98cd0e6293e20220 from 192.168.0.183 body: {"on":true,"bri":99} | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:40.440 | DEBUG | validateWhitelistUser: found a user <3ad6b96dbe1c4aab98cd0e6293e20220> | com.bwssystems.HABridge.BridgeSecurity
09-29-2017 20:38:40.441 | DEBUG | Decode Json for url items: [{"item":"udp://192.168.0.183:55056/setBrightness,${intensity.byte}"}] | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:40.441 | DEBUG | executing HUE api request to UDP: udp://192.168.0.183:55056/setBrightness,${intensity.byte} | com.bwssystems.HABridge.plugins.udp.UDPHome
09-29-2017 20:38:40.441 | DEBUG | Request <<setBrightness,99>>, not done: false | com.bwssystems.HABridge.hue.DeviceDataDecode
09-29-2017 20:38:40.441 | DEBUG | Sending response string: <<<setBrightness,99>>> | com.bwssystems.HABridge.util.UDPDatagramSender
09-29-2017 20:38:41.522 | DEBUG | httpMethod:put, uri: /api/3ad6b96dbe1c4aab98cd0e6293e20220/lights/18/state | spark.webserver.MatcherFilter
09-29-2017 20:38:41.522 | DEBUG | get params | spark.Request
09-29-2017 20:38:41.522 | DEBUG | get splat | spark.Request
09-29-2017 20:38:41.522 | DEBUG | HueMulator PUT called on api/* with request <<</api/3ad6b96dbe1c4aab98cd0e6293e20220/lights/18/state>>>, and body <<<{"on":false}>>> | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:41.523 | DEBUG | get params | spark.Request
09-29-2017 20:38:41.523 | DEBUG | matchedPart: :userid = 3ad6b96dbe1c4aab98cd0e6293e20220 | spark.Request
09-29-2017 20:38:41.523 | DEBUG | matchedPart: :id = 18 | spark.Request
09-29-2017 20:38:41.523 | DEBUG | get splat | spark.Request
09-29-2017 20:38:41.523 | DEBUG | hue state change requested: 3ad6b96dbe1c4aab98cd0e6293e20220 from 192.168.0.183 body: {"on":false} | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:41.523 | DEBUG | validateWhitelistUser: found a user <3ad6b96dbe1c4aab98cd0e6293e20220> | com.bwssystems.HABridge.BridgeSecurity
09-29-2017 20:38:41.523 | DEBUG | Decode Json for url items: [{"item":"udp://192.168.0.183:55056/setPower,on"}] | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:41.523 | DEBUG | executing HUE api request to UDP: udp://192.168.0.183:55056/setPower,on | com.bwssystems.HABridge.plugins.udp.UDPHome
09-29-2017 20:38:41.523 | DEBUG | Request <<setPower,on>>, not done: false | com.bwssystems.HABridge.hue.DeviceDataDecode
09-29-2017 20:38:41.523 | DEBUG | Sending response string: <<<setPower,on>>> | com.bwssystems.HABridge.util.UDPDatagramSender
09-29-2017 20:38:41.763 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:41.763 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.60:4099, body: M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Content-Length: 0 MAN: "ssdp:discover" MX: 2 ST: urn:schemas-upnp-org:device:MediaServer:1 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:43.724 | DEBUG | httpMethod:get, uri: /api/8f8eccc5f7e5468ba23ecaacd2c98fa8/lights | spark.webserver.MatcherFilter
09-29-2017 20:38:43.724 | DEBUG | get params | spark.Request
09-29-2017 20:38:43.724 | DEBUG | get splat | spark.Request
09-29-2017 20:38:43.724 | DEBUG | HueMulator GET called on api/* with request <<</api/8f8eccc5f7e5468ba23ecaacd2c98fa8/lights>>>, and body <<<>>> | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:43.724 | DEBUG | get params | spark.Request
09-29-2017 20:38:43.724 | DEBUG | matchedPart: :userid = 8f8eccc5f7e5468ba23ecaacd2c98fa8 | spark.Request
09-29-2017 20:38:43.724 | DEBUG | get splat | spark.Request
09-29-2017 20:38:43.724 | DEBUG | hue lights list requested: 8f8eccc5f7e5468ba23ecaacd2c98fa8 from 192.168.0.120 | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:43.724 | DEBUG | validateWhitelistUser: found a user <8f8eccc5f7e5468ba23ecaacd2c98fa8> | com.bwssystems.HABridge.BridgeSecurity
09-29-2017 20:38:43.724 | DEBUG | Save HA Bridge settings. | com.bwssystems.HABridge.BridgeSettings
09-29-2017 20:38:45.550 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:45.550 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.135:37271, body: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 1 ST: urn:dial-multiscreen-org:service:dial:1 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:45.844 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:45.844 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.135:37271, body: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 1 ST: urn:dial-multiscreen-org:service:dial:1 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:46.152 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:46.153 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.135:37271, body: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 1 ST: urn:dial-multiscreen-org:service:dial:1 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:46.768 | DEBUG | isSSDPDiscovery Found message to be an M-SEARCH message. | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:46.768 | DEBUG | isSSDPDiscovery Got SSDP packet from 192.168.0.60:4099, body: M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Content-Length: 0 MAN: "ssdp:discover" MX: 2 ST: urn:schemas-upnp-org:device:MediaServer:1 | com.bwssystems.HABridge.upnp.UpnpListener
09-29-2017 20:38:48.667 | DEBUG | httpMethod:put, uri: /api/8f8eccc5f7e5468ba23ecaacd2c98fa8/lights/18/state | spark.webserver.MatcherFilter
09-29-2017 20:38:48.667 | DEBUG | get params | spark.Request
09-29-2017 20:38:48.667 | DEBUG | get splat | spark.Request
09-29-2017 20:38:48.667 | DEBUG | HueMulator PUT called on api/* with request <<</api/8f8eccc5f7e5468ba23ecaacd2c98fa8/lights/18/state>>>, and body <<<{"hue":33105,"sat":97,"on":true,"alert":"none","transitiontime":4}>>> | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:48.667 | DEBUG | get params | spark.Request
09-29-2017 20:38:48.667 | DEBUG | matchedPart: :userid = 8f8eccc5f7e5468ba23ecaacd2c98fa8 | spark.Request
09-29-2017 20:38:48.667 | DEBUG | matchedPart: :id = 18 | spark.Request
09-29-2017 20:38:48.667 | DEBUG | get splat | spark.Request
09-29-2017 20:38:48.667 | DEBUG | hue state change requested: 8f8eccc5f7e5468ba23ecaacd2c98fa8 from 192.168.0.120 body: {"hue":33105,"sat":97,"on":true,"alert":"none","transitiontime":4} | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:48.667 | DEBUG | validateWhitelistUser: found a user <8f8eccc5f7e5468ba23ecaacd2c98fa8> | com.bwssystems.HABridge.BridgeSecurity
09-29-2017 20:38:48.669 | DEBUG | Decode Json for url items: [{"item":"udp://192.168.0.183:55056/setColor,${color.r},${color.g},${color.b}"}] | com.bwssystems.HABridge.hue.HueMulator
09-29-2017 20:38:48.669 | DEBUG | executing HUE api request to UDP: udp://192.168.0.183:55056/setColor,${color.r},${color.g},${color.b} | com.bwssystems.HABridge.plugins.udp.UDPHome
09-29-2017 20:38:48.669 | DEBUG | Request <<setColor,${color.r},${color.g},${color.b}>>, not done: false | com.bwssystems.HABridge.hue.DeviceDataDecode
09-29-2017 20:38:48.669 | DEBUG | Sending response string: <<<setColor,${color.r},${color.g},${color.b}>>>

This all gave me the following in my listener

Time: 8:51:04.201 pm
TO: You:55056
From: 192.168.0.150:50000
Method: UDP
Error: 

ASCII:
setPower,on


HEX:
73 65 74 50 6F 77 65 72 2C 6F 6E



Time: 8:51:16.945 pm
TO: You:55056
From: 192.168.0.150:50000
Method: UDP
Error: 

ASCII:
setBrightness,99


HEX:
73 65 74 42 72 69 67 68 74 6E 65 73 73 2C 39 39



Time: 8:51:25.919 pm
TO: You:55056
From: 192.168.0.150:50000
Method: UDP
Error: 

ASCII:
setPower,on


HEX:
73 65 74 50 6F 77 65 72 2C 6F 6E



Time: 8:51:32.436 pm
TO: You:55056
From: 192.168.0.150:50000
Method: UDP
Error: 

ASCII:
setColor,${color.r},${color.g},${color.b}


HEX:
73 65 74 43 6F 6C 6F 72 2C 24 7B 63 6F 6C 6F 72 2E 72 7D 2C 24 7B 63 6F 6C 6F 72 2E 67 7D 2C 24 7B 63 6F 6C 6F 72 2E 62 7D

Now, if you say the above linked file works for you there's obviously something wrong with my setup. But I can't see what it is. I've tried creating a new device, I've tried editing an old one, both give the same output. Running on Debian 1609.

--EDIT--
Yes, I realize I forgot to set the UDP type on this test bulb. I set it now, and it gives the exact same output.

[FloFoer]

Ah now i see what's the problem. This:
hue state change requested: 8f8eccc5f7e5468ba23ecaacd2c98fa8 from 192.168.0.120 body: {"hue":33105,"sat":97,"on":true,"alert":"none","transitiontime":4} | com.bwssystems.HABridge.hue.HueMulator
With Philips Hue there are 3 variants to describe a color: XY values, CT, and hue/sat. No RGB. So in order to have RGB values one must implement a conversion. This conversion is currently implemented for XY and CT values. Your code snippet uses Hue/Sat. This is the only conversion that is currently not implemented.
May i ask what device/app is sending these commands? Because with alexa and all the apps i used hue/sat never got used. Normally they all use XY for colors and CT for white temperatures.

[emigrating]

Hmm.. Now this is weird.

On the initial device I get this using any app as well as voice via Alexa. That includes the Hue 4 All app.
On the second device, i.e. Test Light, I actually get proper values using the Hue 4 All app.

Anyway, I'm using SmartThings, so the bulbs are picked up by Alexa as a SmartThings "thing" rather than a Hue bulb, but they obviously go thru the HABridge either way.

[FloFoer]

Since i never encountered Hue/Sat (using alexa, hue app, all 4 hue and some other apps) i wanted to implemented it last of the 3 variants and then i ran out of spare time for private programming and eventually i forgot this because i never ran into problems without the Hue/Sat conversion since my echo and none of my apps tried to use it that way ever.
Maybe i find the time to implement Hue/Sat in the future, but not right now, i have exams currently. Otherwise @bwssytems or someone else has to implement this if needed.

[emigrating]

I'll have a look. Although I haven't found much info on Hue Sat conversion, it all seems to be HLS or HBS.

But in any case. Getting this done will allow for color via Alexa as long as you also have a smartthings hub.

[bwssytems]

New version to try! See top post

[TheCellMC]

I am getting this error when I navigate to the « Hue Devices » tab or the « Home Assistant Devices tab.

Get Hue Items Error: undefined with status: Server Error - 500

Here are the logs:

0-23-2017 21:57:22.928 | WARN | HTTP response code was not an expected successful response of between 200 - 299, the code was: HTTP/1.1 404 Not Found | com.bwssystems.HABridge.plugins.http.HTTPHandler
0-23-2017 21:57:22.932 | ERROR |   | spark.webserver.MatcherFilter

I fixed this by downgrading to the Release Candidate 1 of 5.0.0. #768

I also can't control the temperature of my lights when I change the whole group color. However, I can change it individually.

[bwssytems]

@TheCellMC I am seeing the same issue with the HUE Passthru. Working on that.

[bwssytems]

@TheCellMC Found it, it is fixed in the next RC to try

[bwssytems]

New version rc4 to try! See top post

[bwssytems]

Closing this thread for testing, hopefully, the final release candidate. Will open another thread.