diyhue / diyHue

Main diyHue software repo
https://diyhue.org/
Other
1.55k stars 275 forks source link

MiLight sync error because of missing field "saturation" #50

Closed maberle closed 5 years ago

maberle commented 5 years ago

Config

ESP_MiLight-Hub 1.8.5 (nodemcuv2), several bulbs and stripes rgb_cct and rgbw

Output

Docker Setup Initiated Restoring Certificate Certificate Restored Restoring config Config restored Docker Setup Complete ERROR:root:light 7 is unreachable Traceback (most recent call last): File "/opt/hue-emulator/HueEmulator3.py", line 835, in syncWithLights bridge_config["lights"][light]["state"]["sat"] = int(light_data["saturation"] * 2.54) KeyError: 'saturation'

returned config 7 from esp-milight-hub

{ "state": "ON", "status": "ON", "brightness": 255, "level": 100, "hue": 31, "color": { "r": 255 }, "bulb_mode": "color" }

Workaround for me

line 835: try: bridge_config["lights"][light]["state"]["sat"] = int(light_data["saturation"] * 2.54) except KeyError: pass

mariusmotea commented 5 years ago

Milight output changed with new updates. Can you provide same output with the bulb set in both color and color temp modes to see what i need to remove or to add?

Update: for sure this is a issue with milight hub because saturation is mandatory if you provide the hue value to know exactly the nuance.

maberle commented 5 years ago

I tried some color modes with a rgbw and a rbb_cct bulbs. On the GUI the remote type "rgbw" does not provide a "saturation" slider like "rgb_cct". Maybe rgbw must be handled different from rgb_cct.

Here are the configuration results from my tests:

http://esp-milight/gateways/0xc544/rgbw/1

{ "state": "ON", "status": "ON", "brightness": 255, "level": 100, "hue": 31, "color": { "r": 255 }, "bulb_mode": "color" }

{ "state": "ON", "status": "ON", "brightness": 255, "level": 100, "hue": 248, "color": { "r": 33 }, "bulb_mode": "color" }

{ "state": "ON", "status": "ON", "brightness": 255, "level": 100, "bulb_mode": "white", "color": { "r": 255, "g": 255, "b": 255 }, "effect": "white_mode" }

http://esp-milight/gateways/0x5dc6/rgb_cct/3

{ "state": "ON", "status": "ON", "mode": 0, "bulb_mode": "scene", "color": { "r": 255, "g": 255, "b": 255 }, "effect": "0" }

{ "state": "ON", "status": "ON", "brightness": 255, "level": 100, "hue": 227, "saturation": 5, "color": {}, "bulb_mode": "color" }

{ "state": "ON", "status": "ON", "brightness": 69, "level": 27, "kelvin": 13, "color_temp": 181, "bulb_mode": "white", "color": { "r": 255, "g": 255, "b": 255 } }

mariusmotea commented 5 years ago

I recommend to open issue on milight hub because on hue color mode the saturation is a mandatory key so it need to be present. I can implement an hotfix that consider saturation to be 100% if is not declared, but better to have this fixed at origin.

maberle commented 5 years ago

I am not sure, but I think, the old MiLight bulbs (rgbw) dont provide saturation control. The old remote control also does not provide a controller key, only brightness. So I think, the missing saturation value is by intention missing in the milight hub.

A workaround fix would be nice, so I dont have to patch the program after each watchtower update of the diyhue docker image.

maberle commented 5 years ago

The old milight bulbs rgbw (not rgbww) do not provide saturation control (https://github.com/sidoh/esp8266_milight_hub/wiki/RGBW). I will provide a pull request for that case.

GitHub
sidoh/esp8266_milight_hub
Replacement for a Milight/LimitlessLED hub hosted on an ESP8266 - sidoh/esp8266_milight_hub
MunkeyBalls commented 5 years ago

I've updated to the latest version of diyHue and the latest version of esp8266 milight hub and for me it's missing the "hue" key.

I'm using mostly RGBCCT bulbs and they are all failing to sync (unreachable) now

Feb 18 20:11:02 DietPi HueEmulator3.py[931]: ERROR:root:light 2 is unreachable
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: Traceback (most recent call last):
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:   File "/opt/hue-emulator/HueEmulator3.py", line 893, in syncWithLights
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:     bridge_config["lights"][light]["state"]["hue"] = light_data["hue"] * 180
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: KeyError: 'hue'
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: ERROR:root:light 1 is unreachable
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: Traceback (most recent call last):
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:   File "/opt/hue-emulator/HueEmulator3.py", line 893, in syncWithLights
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:     bridge_config["lights"][light]["state"]["hue"] = light_data["hue"] * 180
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: KeyError: 'hue'
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: ERROR:root:light 3 is unreachable
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: Traceback (most recent call last):
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:   File "/opt/hue-emulator/HueEmulator3.py", line 893, in syncWithLights
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:     bridge_config["lights"][light]["state"]["hue"] = light_data["hue"] * 180
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: KeyError: 'hue'
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: ERROR:root:light 4 is unreachable
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: Traceback (most recent call last):
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:   File "/opt/hue-emulator/HueEmulator3.py", line 893, in syncWithLights
Feb 18 20:11:02 DietPi HueEmulator3.py[931]:     bridge_config["lights"][light]["state"]["hue"] = light_data["hue"] * 180
Feb 18 20:11:02 DietPi HueEmulator3.py[931]: KeyError: 'hue'
ghost commented 5 years ago

I'll reopen this issue for you @MunkeyBalls

mariusmotea commented 5 years ago

I need somebody to explain me when the function should expect rgb key (type of bulb, "bulb_mode" value, etc) to modify the function. I cannot get this data as i don't use anymore the milight hub.

MunkeyBalls commented 5 years ago

@mariusmotea this is the JSON I get from the milight bulbs when calling

http://miglightHub/gateways/0x1/rgb_cct/1

{"state":"ON","brightness":250,"bulb_mode":"color","color":{"r":255,"g":251,"b":232}}

I've already changed the code a bit locally so it works again, but the change doesn't have perfect color accuracy (probably because I convert from RGB to XY, and seems a bit twitchy sometimes. I didn't have time to look at it further, I think best would be if we could just use the RGB values directly but couldn't quickly find out how.

Here's a sample of the code I changed where it's crashing normally

elif "bulb_mode" in light_data and light_data["bulb_mode"] == "color":
                        bridge_config["lights"][light]["state"]["colormode"] = "xy" 
                        #bridge_config["lights"][light]["state"]["colormode"] = "hs" 
                        #print(json.dumps(light_data, indent=4, sort_keys=True)) 
                        if ("hue" in light_data) :
                            bridge_config["lights"][light]["state"]["colormode"] = "hs" 
                            bridge_config["lights"][light]["state"]["hue"] = light_data["hue"] * 180
                        if ("saturation" in light_data):
                            bridge_config["lights"][light]["state"]["colormode"] = "hs"
                            bridge_config["lights"][light]["state"]["sat"] = int(light_data["saturation"] * 2.54)
                        **if("color" in light_data):
                            bridge_config["lights"][light]["state"]["colormode"] = "xy"
                            r = int(light_data["color"]["r"])
                            g = int(light_data["color"]["g"])
                            b = int(light_data["color"]["b"])                             
                            xyValue = convert_rgb_xy(r, g, b)
                            logging.info("xyUpdate: x" + str(xyValue[0]) + "y" + str(xyValue[1]))
                            bridge_config["lights"][light]["state"]["xy"] = xyValue**
                            logging.info("New state: " + json.dumps(bridge_config["lights"][light]["state"])) # print new light state 
stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 2 days if no further activity occurs. Thank you for your contributions.

stale[bot] commented 5 years ago

This issue has been automatically closed as it has not had any recent activity. Thank you for your contributions.