In 5.0.0, colour UDP URLs not issued to milight hub

[untruenorth]

Milight hub running v4.x, group 0 (all bulbs) added and working well for on/off/dim. (Config snapshot at end.)

Hue app on iPhone connected to ha-bridge with no issues. The milight group 0 "bulb" is added to a room. When I use the hue app to change colour, tcpdump confirms that only dim commands get sent:

root@habridge:/home/habridge/data# tcpdump -x -n host 192.168.1.125
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
12:11:57.263202 IP 192.168.1.18.50000 > 192.168.1.125.8899: UDP, length 3
	0x0000:  4500 001f ae8d 4000 4011 0861 c0a8 0112
	0x0010:  c0a8 017d c350 22c3 000b 83fc **4200 55**
12:11:57.364463 IP 192.168.1.18.50000 > 192.168.1.125.8899: UDP, length 3
	0x0000:  4500 001f ae90 4000 4011 085e c0a8 0112
	0x0010:  c0a8 017d c350 22c3 000b 83fc **4e04 55**

At which point, I'm all out of options. Have deleted and re-added the bulb, no difference. Am I missing something?

--Chris

Bulb config:

[FloFoer]

Your config seems correct, exactly the way i'm using it (it works for me using the official hue android app, and other android apps). Maybe the iPhone app does something different.
Could you please turn on the debug log and post it here to see what exactly happens?

[untruenorth]

Here's a log fragment at DEBUG level, with tcpdump output intermingled. I've *'d out the userid as it looks a bit shared-secret-y, but I might just be paranoid. If I haven't given enough context let me know - I tried to snip the logs sensibly either side of the colour change action.

Thanks for a swift reponse!

Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,523 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.HueMulator - HueMulator PUT called on api/* with request <<</api/838****************574/lights/10/state>>>, and body <<<{"bri":103,"xy":[0.307492,0.297067]}>>>
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,524 [qtp349907674-49] DEBUG spark.Request - matchedPart: :userid = 838****************574
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,524 [qtp349907674-49] DEBUG spark.Request - matchedPart: :id = 10
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,524 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.HueMulator - hue state change requested: 838****************574 from 192.168.1.118 body: {"bri":103,"xy":[0.307492,0.297067]}
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,525 [qtp349907674-49] DEBUG com.bwssystems.HABridge.BridgeSecurity - validateWhitelistUser: found a user <838****************574>
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,525 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.HueMulator - Decode Json for url items: [{"item":"udp:https://192.168.1.125:8899/0x420055","type":"udpDevice","delay":"100"},{"item":"udp:https://192.168.1.125:8899/0x4e${intensity.math((X*27)/255)}55","type":"udpDevice","delay":"100"}]
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,525 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.HueMulator - Calling Home device handler for type : udpDevice
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,526 [qtp349907674-49] DEBUG com.bwssystems.HABridge.plugins.udp.UDPHome - executing HUE api request to UDP: udp:https://192.168.1.125:8899/0x420055
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,526 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.DeviceDataDecode - Request <<0x420055>>, not done: false
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,526 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.ColorDecode - Color change with XY: 0.307492 0.297067 Resulting RGB Values: 172 168 191
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,526 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.ColorDecode - Request <<0x420055>>, not done: false
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,526 [qtp349907674-49] DEBUG com.bwssystems.HABridge.util.UDPDatagramSender - Sending response string: <<<B
16:07:45.527193 IP 192.168.1.18.50000 > 192.168.1.125.8899: UDP, length 3
	0x0000:  4500 001f 6a0b 4000 4011 4ce3 c0a8 0112
	0x0010:  c0a8 017d c350 22c3 000b 83fc 4200 55
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,627 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.HueMulator - Calling Home device handler for type : udpDevice
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,627 [qtp349907674-49] DEBUG com.bwssystems.HABridge.plugins.udp.UDPHome - executing HUE api request to UDP: udp:https://192.168.1.125:8899/0x4e${intensity.math((X*27)/255)}55
16:07:45.628454 IP 192.168.1.18.50000 > 192.168.1.125.8899: UDP, length 3
	0x0000:  4500 001f 6a11 4000 4011 4cdd c0a8 0112
	0x0010:  c0a8 017d c350 22c3 000b 83fc 4e0b 55
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,628 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.BrightnessDecode - Math eval is: (X*27)/255, Where X is: 103
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,628 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.DeviceDataDecode - Request <<0x4e0b55>>, not done: false
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,628 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.ColorDecode - Color change with XY: 0.307492 0.297067 Resulting RGB Values: 172 168 191
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,628 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.ColorDecode - Request <<0x4e0b55>>, not done: false
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,628 [qtp349907674-49] DEBUG com.bwssystems.HABridge.util.UDPDatagramSender - Sending response string: <<<N#013U>>>
Nov 26 16:07:45 habridge java[1492]: 2017-11-26 16:07:45,629 [qtp349907674-49] DEBUG com.bwssystems.HABridge.hue.HueMulator - Response is in error: null

[FloFoer]

Ah okay i think i found the culprit: body: {"bri":103,"xy":[0.307492,0.297067]}
Apparently your app transmits the brightness alongside the color, which is unusual. All apps that i tried only transmit the color data if you use the color circle to change the color - no brightness (because you're not changing that property anyways).
If you look at the point where it gets decided which url to use in the java code (File: HueMulator.java at line 1138 - 1151) you see that it uses the dimUrl if the brightness is present in the body and not the colorUrl.

This seems to be something that needs a fix in code. If i try this command with my real hue hub both bri and xy get executed. This didn't come up before because i never saw an app do this. In most apps it is impossible to do this.
In the case both bri/on and xy are present, both Urls should get executed instead of the usual "choose one".

[untruenorth]

Interesting. This is the offical Hue iOS app from Philips that's doing this.

Another thing I noted while experimenting: iConnectHue (one of the other apps I have to hand) appears to send hue and saturation - I think I read that this is unusual...:
Nov 26 16:38:32 habridge java[1492]: 2017-11-26 16:38:32,621 [qtp349907674-56] DEBUG com.bwssystems.HABridge.hue.HueMulator - HueMulator PUT called on api/* with request <<</api/JdC...7GmF/lights/10/state>>>, and body <<<{"hue":58287,"sat":89}>>>

Anyhow - I'll hang fire for a code fix. I'm about 20 years too rusty on the coding front for this!

[FloFoer]

Regarding hue/sat i wrote this in the v5 testing issue:

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.

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.

[untruenorth]

I only mention hue/sat for interest having come across an app that uses it - I'm not personally dependant on that app and probably shouldn't have mentioned it here since it muddies the water. Exams are rather more important.

[untruenorth]

@bwssytems Please ignore the latter query about hue/sat being sent by iConnectHue. Is the original issue ref the official Philips Hue app actually an enhancement/bug? @FloFoer has kindly spotted the root cause already.

[bwssytems]

I will let @FloFoer answer as this was his contribution.

[bwssytems]

@untruenorth Is this issue resolved?

[FloFoer]

Not him but i can say: No, not really since the code was not changed in that way this still applies.
The problem here is our "choose one" policy regarding which url (dim/on/off/color) gets executed. If there is on/off/dim content in the command body it always chooses that over color even if there is color content too.
What we should do, in case there is on/bri and a color value simultaneously in the http put body we should execute both urls and not just one. (First on/dim and then color)
In the official android hue app this is impossible to occur to my experience since you can only open the color wheel if the bulb is already turned on and it doesn't send brightness info if you change the color. But apparently it occurs in the iOS hue app.

[bwssytems]

So this would be an enhancement.

[ml9907]

I have a milight hub v6 which is a bit more comlicated protocol than v4. I have written a small python script which can be used through ha-bridge to dim, switch on/off, change color for any zones. I give details if someone interested in.
However, in the alexa app the light is described as a color light without any color capabilities, so I can not change the color through echo/ha-bridge. Any idea to test the color capabilities through ha-bridge?

[nihebe]

Have a look at #845 ... Echo / Alexa doesn't support color features via the LAN Hue-API. Unfortunately!

But many thanks for the script! That helps here.

[ml9907]

OK, I got it. Anyway, a "Test Color" button on the ha-bridge web UI would be useful.

[bwssytems]

The implementation I will do is a separate call for each type of request that is available in the body. The Philips spec shows that on, bri and color items can be in the same request. IF any are present it will call the url for each. I'll ad a test color button as well.

[dougdalton]

Does anyone have a devices.db they would post that does all the colors and modes?