search

bwssytems / ha-bridge

Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that has an http/https/tcp/udp interface. This is a compact impl to run on small format computers. This is impl started from this project https://github.com/armzilla/amazon-echo-ha-bridge.
Apache License 2.0
1.45k stars 198 forks source link

MiLight/Limitless LED Hex Colors Being Sent Incorrectly after 3.1.0 #261

Closed jacc1234 closed 7 years ago

jacc1234 commented 7 years ago

After version 3.1.0, ha-bridge seems to have issues setting the correct color for limitlessled/milight bulbs.

For example, this UDP string should turn on the bulb and set the color to a warm yellow (0x95): [{"item":"udp://192.168.1.3:8899/0x450055"}, {"item":"udp://192.168.1.3:8899/0x409555"},

On version 3.1.0, it works as intended but on newer versions the color is set to a bright violet (0x00). I don't want to speculate on why this is happening but my testing found that any color after green (0x60) becomes violet/purple.

I tried to get some viable info from the logs but was unable to. If more info is needed please let me know how best to enable the right logs.

bwssytems commented 7 years ago

I'll give it a test as well

bwssytems commented 7 years ago

So, You do not have the closing bracket on that text above. Is there a closing "]" in the rest of that statement? I tested it with the closing bracket on v3.5.1 and it works.

jacc1234 commented 7 years ago

The closing bracket was on my statement that was in the HA-Bridge software but I retyped the whole thing again and am still having issues. I did a bit more testing and found that for me, any hex value after 0x79 (green/yellow) actually becomes violet.

A new example is: [{"item":"udp://192.168.1.3:8899/0x450055"}, {"item":"udp://192.168.1.3:8899/0x408055"}]

I decided to run TCPdump and have found that when the value is set to anything past 407900 in habridge, the payload becomes 40EFBF when the UDP packet is sent. I can upload the pcap file if you like.

I would like to add I ran the same command on 3.1.0 and 3.5.1 while using TCPDump. [{"item":"udp://192.168.1.3:8899/0x450055"}, {"item":"udp://192.168.1.3:8899/0x409055"}]

On 3.1.0 the payload for the color UDP packet was 409055. On 3.5.1 it was 40EFBF.

If you can give me advice on what loggers to enable I would be glad to post some more details.

bwssytems commented 7 years ago

That is totally weird. I have a udp server test tool that runs on on another machine and it dumps out the hex values and I can send your items just fine, 409055 sent is received as 409055. There is something very weird on your system that would cause the issue you are experiencing. So, I know some people have had cut and paste issues from some websites and get unusual characters inserted. Create a whole new device and type it in is my next suggestion, that way any residual chars from a cut and paste will be gone.

jacc1234 commented 7 years ago

Sorry for the delay. I just ran some more tests and am still having the issue. I am on a RasPi 3 running the latest Raspbian version.

I updated to version 3.5.1, created a new blank config and a new blank DB. I then manually created a new device with type UDP and a target of encapsulated. I typed out the udp string to ensure there were no control characters etc included.

I one again ran TCPDump and am still getting the odd hex values. I am not sure what might be happening on my end and do believe that somehow this issue was introduced after version 3.1. I have not made any changes to the default network settings of the Pi.

tball78 commented 7 years ago

I am having exact same issue on RPi 3 with version 3.5.1. Anything above 406055 does not set lights to accurate color. I also get the purpleish color with 409055. Another symptom was that the "turn off" color URL command in the same device did not work (appears as no action taken):

[{"item":"udp://192.168.1.130:8899/0x450055"}, {"item":"udp://192.168.1.130:8899/0xC50055"}]

I attempted down-rev to ha-bridge-3.1.0.jar as a test and now the color 409055 properly displays as yellowish-orange and 40AF55 now displays as red whereas both were purpleish on 3.5.1. I am now also able to execute the off command for the same device and lights switch back to white as they should.

Hope this helps.

Regards.

jacc1234 commented 7 years ago

I would like to confirm that I also experienced the same issue with being unable to turn off colored groups or change them back to white on versions after 3.5.1

bwssytems commented 7 years ago

Will take a look at this. thanks

bwssytems commented 7 years ago

Confirmed on pi, works properly on windows. now a bug.

bwssytems commented 7 years ago

And found it... converting back to string on linux is not correct. Need to send the bytes converted,

glyxkecks commented 7 years ago

Seems to be working in 4beta1. But what's weird is for values <=127 the intensity is send as 1 byte, for values >= 128 it is send as 2 bytes.

I can change my Arduino to accept 1 or 2 bytes but it should be fixed on HA Bridge.

bwssytems commented 7 years ago

Will put this in the next beta release.