openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.88k stars 3.59k forks source link

[yeelight] UI not updating when device controlled by services other than openHAB #4767

Closed sverzijl closed 5 years ago

sverzijl commented 5 years ago

Expected Behavior

When light is controlled by a non-openHAB service (for example Google Home), the state of the item should update in openHAB UIs (like Basic UI).

Current Behavior

When light is controlled by a non-OpenHAB service (for example Google Home), the state of the item updates but not the UI on OpenHAB. An example is - turning off the light in Google Home does not change the displayed status on Basic UI from On to Off. Openhab logs show that it detects when the state has been changed (isPowerOff): 2019-01-30 20:47:00.208 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=255, g=127, b=0, color=16744192, brightness=50, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_COLOR, isMusicOn=false, name=]

Possible Solution

In YeelightHandlerBase.java it seems the intention is that if 'isPowerOff' state is set then the UI should change. void updateBrightnessAndColorUI(DeviceStatus status) { if (status.isPowerOff()) { updateState(YeelightBindingConstants.CHANNEL_BRIGHTNESS, new PercentType(0));

When a change of status occurs the binding appears to detect it and update the state of the device: And when I look in DeviceBase.java and at onNotify there is code where the status is updated: if (prop.getKey().equals("power")) { updateProp += " power"; if (prop.getValue().toString().equals("\"off\"")) { mDeviceStatus.setPowerOff(true); } else if (prop.getValue().toString().equals("\"on\"")) { mDeviceStatus.setPowerOff(false); }

I've noticed a 'listener' class (DeviceStatusChangeListener.java) which I assume is meant to tell classes that contain devices, like YeelightHandlerBase, that a device instance state has changed. public void onStatusChanged(String prop, DeviceStatus status) { logger.debug("UpdateState->{}", status); updateUI(status); }

However it obviously isn't being called despite it being mentioned in DeviceBase: if (needNotify) { logger.info("status = {}", mDeviceStatus.toString()); for (DeviceStatusChangeListener statusChangeListener : mStatusChangeListeners) { statusChangeListener.onStatusChanged(updateProp.trim(), mDeviceStatus); } }

Steps to Reproduce (for Bugs)

  1. Request Google Home to turn off or on the light.

Context

The outcome is that you no longer have an accurate display of the state of the light on the OpenHAB UIs

Your Environment

goodfore commented 5 years ago

I was unable to reproduce the issue. I have White V1 bulb, and openhab 2.4 with custom Yeelight binding (doing some work on the binding, the changes are going into a PR).

I controlled the same Yeelight with home assistant, and the status updated correctly in openhab.

I can't test with google home directly as my Xiaomi account was lost during their migration.

I do see one warning in the log, 2019-02-02 23:04:00.276 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler YeelightWhiteHandler of thing yeelight:dolphin:xxxxxxxxxxxx tried updating channel brightness although the handler was already disposed.

I wonder if that's related. Despite the warning, the status was updated correctly. Wondering if someone else has google home setup can confirm the bug?

sverzijl commented 5 years ago

Hi goodfore - it also happens when I control it in the Yeelight app.

Change anything on the Yeelight app - colour or brightness - and no change on OpenHab UI. Do the reverse, change brightness or colour via OpenHab UI and the Yeelight app shows the change.

goodfore commented 5 years ago

Just tried using the yeelight app (Android), connected to the Singapore server. Works fine, status showing correctly on both sides (Yeelight and Openhab). I wonder if it's something to do with the model of the bulb.

Can you try enable debug log for Yeelight and see anything useful out of the logs?

Thanks, Joe

goodfore commented 5 years ago

Hm, I wonder Firmware on the bulb has anything to do with it. Mine bulb's firmware is pretty old.

sverzijl commented 5 years ago

I'll try the logs tonight.

When your Yeelight app turns off the bulb is the Yeelight app controlling brightness and setting to 0 or is it doing what my one is where it sends a power off signal?

I'm using the latest firmware.

Also I just acquired a Wonder V2 and I have the same issue.

goodfore commented 5 years ago

I think the app sent power off to my bulb/openhab as well.

sverzijl commented 5 years ago

I set the logging to debug mode and this what it came up with when controlled via Google Home (and Yeelight app).

`2019-02-05 21:43:53.129 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"on"}}

2019-02-05 21:43:53.133 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"on"}}

2019-02-05 21:43:53.139 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=255, g=127, b=0, color=16744192, brightness=10, ct=5000, hue=30, sat=100, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-05 21:43:53.139 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=255, g=127, b=0, color=16744192, brightness=10, ct=5000, hue=30, sat=100, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-05 21:43:53.143 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=false, r=255, g=127, b=0, color=16744192, brightness=10, ct=5000, hue=30, sat=100, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-05 21:43:53.148 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=false, r=255, g=127, b=0, color=16744192, brightness=10, ct=5000, hue=30, sat=100, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_SUNHINE, isMusicOn=false, name=]`

goodfore commented 5 years ago

Thanks for the log. This is the log for when turning the Yeelight ON when the app, correct?

Joe

sverzijl commented 5 years ago

I was turning it on.

Turning it off results in {"method":"props","params":{"power":"off"}}

goodfore commented 5 years ago

Can you please also list/show me your channel/item mapping? I read thru the handler, On/Off status only works for Brightness channel.

Thanks, Joe

sverzijl commented 5 years ago

Well that explains something. The Wonder doesn't have a Brightness channel - only Color and ColorTemperature.

It's not in PaperUI or in the binding xmls: openhab2-addons/addons/binding/org.openhab.binding.yeelight/ESH-INF/thing/wonder.xml

goodfore commented 5 years ago

Hmm, that doesn't seem right. How do you currently control on/off using Openhab? on the CT channel?

sverzijl commented 5 years ago

Just on the Color channel.

On Thu, 7 Feb. 2019, 4:53 am goodfore <notifications@github.com wrote:

Hmm, that doesn't seem right. How do you currently control on/off using Openhab? on the CT channel?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openhab/openhab2-addons/issues/4767#issuecomment-461120526, or mute the thread https://github.com/notifications/unsubscribe-auth/AULNSM9RVfxtLE5FfZ2QS_5OUGmZsMdvks5vKxaagaJpZM4acErU .

goodfore commented 5 years ago

I think we should begin by adding the Brightness channel to wonder bulbs. If you get you a jar, can you please help us test? Assuming you know how to side load bindings.

sverzijl commented 5 years ago

No problems, happy to assist!

On Fri, 8 Feb. 2019, 6:13 am goodfore <notifications@github.com wrote:

I think we should begin by adding the Brightness channel to wonder bulbs. If you get you a jar, can you please help us test? Assuming you know how to side load bindings.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openhab/openhab2-addons/issues/4767#issuecomment-461558189, or mute the thread https://github.com/notifications/unsubscribe-auth/AULNSDszC9OPN8bWrF1gmqjJfsSTtzBrks5vLHq9gaJpZM4acErU .

claell commented 5 years ago

I just added a link to the issue where this originated from.

@goodfore I also think that the reason, why you cannot reproduce this is because you don't have a color bulb, afaik and this seems to happen only with color bulbs.

I think we should begin by adding the Brightness channel to wonder bulbs.

There actually used to be one, but during the review process of the binding @kaikreuzer told me that was actually not needed, because the same can be achieved by simply using the color channel. This is also the way how LIFX does it, afaik.

What I am wondering is, what causes this. Possibly the bulb updates just don't get forwarded correctly to the channel, like they are for the white bulb. Then this is (hopefully) an easy fix.

goodfore commented 5 years ago

@sverzijl , when you turn off the bulb in the app, does it have similar log entry as below?

2019-02-05 21:43:53.139 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=255, g=127, b=0, color=16744192, brightness=10, ct=5000, hue=30, sat=100, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_SUNHINE, isMusicOn=false, name=]

The above is the log item you sent for turning on the bulb with google home. I wonder if there is similar entry for turning the bulb off.

@claell could it be lifx and yeelight works differently?

@kaikreuzer , when a switch item is bind to a color channel, how does it determine the on/off state? Does it read the brightness level on the HSBType ?

goodfore commented 5 years ago

@sverzijl @claell I might a clue on what's going on, but to confirm, I would want to review the following.

Turn on debug log, get the log item for the following 4 scenarios.

Turn on the color bulb using the App - Already prvoded by @sverzijl Turn off the color bulb using the App Turn on the color bulb using Openhab Turn off the color bulb using Openhab

It's really hard for me to debug when I don't have a color bulb, so I need to depends on log files from other.

claell commented 5 years ago

could it be lifx and yeelight works differently?

Internally probably yes, but what I was talking about is the openHAB side, which shows that it should be possible to handle a device like that somehow.

sverzijl commented 5 years ago

@goodfore Yes it is an equivalent entry:

2019-02-08 21:16:34.190 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"off"}}

2019-02-08 21:16:34.196 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=true, r=128, g=128, b=128, color=8421504, brightness=10, ct=5000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_COLOR, isMusicOn=false, name=]

2019-02-08 21:16:34.200 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=true, r=128, g=128, b=128, color=8421504, brightness=10, ct=5000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_COLOR, isMusicOn=false, name=]

When turned off using Openhab:

==> /var/log/openhab2/events.log <==

2019-02-08 21:20:28.319 [ome.event.ItemCommandEvent] - Item 'SimeonLightColor' received command OFF

2019-02-08 21:20:28.327 [nt.ItemStatePredictedEvent] - SimeonLightColor predicted to become OFF

==> /var/log/openhab2/openhab.log <==

2019-02-08 21:20:28.330 [DEBUG] [internal.handler.YeelightHandlerBase] - Handle Color Command OFF

2019-02-08 21:20:28.335 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: Write Success!

2019-02-08 21:20:28.344 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"id":146, "result":["ok"]}

2019-02-08 21:20:28.348 [INFO ] [light.internal.lib.device.DeviceBase] - ######### this is control command response, don't need to notify status change!

==> /var/log/openhab2/events.log <==

2019-02-08 21:20:28.353 [vent.ItemStateChangedEvent] - SimeonLightColor changed from 0,0,50 to 0,0,0

==> /var/log/openhab2/openhab.log <==

2019-02-08 21:20:29.205 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"off"}}

2019-02-08 21:20:29.209 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=true, r=128, g=128, b=128, color=8421504, brightness=10, ct=5000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_COLOR, isMusicOn=false, name=]

2019-02-08 21:20:29.212 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=true, r=128, g=128, b=128, color=8421504, brightness=10, ct=5000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_COLOR, isMusicOn=false, name=]

When turned on using Openhab:

2019-02-08 21:19:10.348 [ome.event.ItemCommandEvent] - Item 'SimeonLightColor' received command ON

==> /var/log/openhab2/openhab.log <==

2019-02-08 21:19:10.364 [DEBUG] [internal.handler.YeelightHandlerBase] - Handle Color Command ON

==> /var/log/openhab2/events.log <==

2019-02-08 21:19:10.363 [nt.ItemStatePredictedEvent] - SimeonLightColor predicted to become ON

==> /var/log/openhab2/openhab.log <==

2019-02-08 21:19:10.369 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: Write Success!

2019-02-08 21:19:10.377 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"id":145, "result":["ok"]}

2019-02-08 21:19:10.383 [INFO ] [light.internal.lib.device.DeviceBase] - ######### this is control command response, don't need to notify status change!

==> /var/log/openhab2/events.log <==

2019-02-08 21:19:10.392 [vent.ItemStateChangedEvent] - SimeonLightColor changed from 0,0,0 to 0,0,100

==> /var/log/openhab2/openhab.log <==

2019-02-08 21:19:11.375 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"on"}}

2019-02-08 21:19:11.380 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=128, g=128, b=128, color=8421504, brightness=10, ct=5000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_COLOR, isMusicOn=false, name=]

2019-02-08 21:19:11.383 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=false, r=128, g=128, b=128, color=8421504, brightness=10, ct=5000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_COLOR, isMusicOn=false, name=]

==> /var/log/openhab2/events.log <==

2019-02-08 21:19:11.401 [vent.ItemStateChangedEvent] - SimeonLightColor changed from 0,0,100 to 0,0,50

goodfore commented 5 years ago

@sverzijl Please try this jar file. https://d.pr/free/f/wJonVd Please rename from .zip to .jar.

@claell This jar also contains the duration changes, if you wish to test it.

I mainly re coded the following method, in the base handler. I can't test it myself, so I can't guarantee anything.

Please note that the color channel should only be updated when the bulb is in color mode or HSV mode. The Sunshine mode should only update CT, according to Yeelight spec.

    void updateBrightnessAndColorUI(DeviceStatus status) {

        HSBType hsbType = null;
        if (status.getMode() == DeviceMode.MODE_COLOR) {
            HSBType tempHsbType = HSBType.fromRGB(status.getR(), status.getG(), status.getB());
            if (status.isPowerOff()) {
                hsbType = new HSBType(tempHsbType.getHue(), tempHsbType.getSaturation(), new PercentType(0));
            } else {
                hsbType = new HSBType(tempHsbType.getHue(), tempHsbType.getSaturation(),
                        new PercentType(status.getBrightness()));
            }
            logger.debug("Update Color->{}", hsbType.toString());
            updateState(YeelightBindingConstants.CHANNEL_COLOR, hsbType);
        } else if (status.getMode() == DeviceMode.MODE_HSV) {
            if (status.isPowerOff()) {
                hsbType = new HSBType(new DecimalType(status.getHue()), new PercentType(status.getSat()),
                        new PercentType(0));
            } else {
                hsbType = new HSBType(new DecimalType(status.getHue()), new PercentType(status.getSat()),
                        new PercentType(status.getBrightness()));
            }
            logger.debug("Update Color->{}", hsbType.toString());
            updateState(YeelightBindingConstants.CHANNEL_COLOR, hsbType);
        } else if (status.getMode() == DeviceMode.MODE_SUNHINE) {
            logger.debug("Update CT->{}", status.getCt());
            updateState(YeelightBindingConstants.CHANNEL_COLOR_TEMPERATURE,
                    new PercentType((status.getCt() - COLOR_TEMPERATURE_MINIMUM) / COLOR_TEMPERATURE_STEP));
        }

    }
claell commented 5 years ago

After a short look, this seems to be the right method where to change things.

However, I think that it might be possible to update the color channel with an OnOffType, so not changing the brightness to zero when turned off (so the brightness state doesn't get deleted).

Example (don't know whether this will work or is correct syntax): updateState(YeelightBindingConstants.CHANNEL_COLOR, OnOffType.OFF);

goodfore commented 5 years ago

I am not sure that will work either, but if you look at the white bulb, status off will is also setting brightness to 0 also.

if (status.isPowerOff()) {
            logger.debug("Device is powered off!");
            updateState(YeelightBindingConstants.CHANNEL_BRIGHTNESS, new PercentType(0));
        } else {
            logger.debug("Device is powered on!");
            updateState(YeelightBindingConstants.CHANNEL_BRIGHTNESS, new PercentType(status.getBrightness()));
        }

logically, if the bulb is off, shouldn't brightness be 0, always?

claell commented 5 years ago

That is a point, the white bulb and color bulb should behave similarly. The question is, whether it is done correctly for the white bulb.

I just looked at the log output again: 2019-02-08 21:16:34.200 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=true, r=128, g=128, b=128, color=8421504, brightness=10, ct=5000, hue=0, sat=0, isFlowing=false, delayOff=-1, mFlowItems=[ColorFlowItem [duration=1996, mode=1, value=14438425, brightness=80], ColorFlowItem [duration=1996, mode=1, value=14448670, brightness=80], ColorFlowItem [duration=1996, mode=1, value=11153940, brightness=80]], mode=MODE_COLOR, isMusicOn=false, name=]

There the brightness is still at 10, while power is set to off. But maybe that is only needed for internal purposes, so no need to display it at the UI (which might also not be possible by sending an off command to the channel, since that might also set the brightness to zero automatically). However when turning the bulb on again from openHAB with a switch the brightness should get restored to 10 again. But I assume that is already what happens currently. So then your implementation is probably completely fine :+1:

goodfore commented 5 years ago

@sverzijl the link to the file will expire in couple days, please let me know if you a re-upload.

sverzijl commented 5 years ago

Apologies! I missed the link! I will try tonight.

sverzijl commented 5 years ago

Sorry, can I have a little more of pointer on how to use the ZIP file? Do I just copy the folder to the addons folder and restart openhab?

goodfore commented 5 years ago

@sverzijl Are you familiar with the openhab console? You would need to stop and uninstall your current yeelight binding first. Here are some steps I take to update the binding

  1. Rename the .zip file to .jar file
  2. login in to openhab console. Instructions can be found here https://www.openhab.org/docs/administration/console.html
  3. Find the bundle, by run this command bundle:list | grep Yeelight . The first number on the returned row is the binding ID. Remember that number.
  4. Stop the binding by running bundle:stop 999, replace 999 with the binding ID from step 3.
  5. Uninstall the binding by running bundle:uninstall 999 , again replace 999.
  6. logout of openhab console
  7. Put the .jar file into the addons folder.

Openhab should be able to pick up the new binding and install it. Sometimes, after updating the binding, I found that some/all Yeelight things don't work. Here is my step to fix it.

  1. Remove the Thing (don't need to remove the item)
  2. Power cycle the Yeelight
  3. Add the Yeelight thing again, with the new binding.

Hope that helps.

goodfore commented 5 years ago

@sverzijl Any improvements with the new zip/jar?

Thanks, Joe

sverzijl commented 5 years ago

Apologies for the delay - will trial today.

sverzijl commented 5 years ago

Hi, tested it out just now:

Turn On via Google Home:

2019-02-16 16:55:29.132 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"on"}}

2019-02-16 16:55:29.135 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:55:29.137 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=false, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:55:29.139 [DEBUG] [internal.handler.YeelightHandlerBase] - Update CT->4000

Turn off via Google Home:

2019-02-16 16:56:31.232 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"off"}}

2019-02-16 16:56:31.235 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=true, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:56:31.237 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=true, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:56:31.238 [DEBUG] [internal.handler.YeelightHandlerBase] - Update CT->4000

Turn On Via Openhab:

2019-02-16 16:57:24.832 [ome.event.ItemCommandEvent] - Item 'SandraLightColor' received command ON

2019-02-16 16:57:24.843 [nt.ItemStatePredictedEvent] - SandraLightColor predicted to become ON

==> /var/log/openhab2/openhab.log <==

2019-02-16 16:57:24.841 [DEBUG] [internal.handler.YeelightHandlerBase] - Handle Color Command ON

2019-02-16 16:57:24.854 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: Write Success!

==> /var/log/openhab2/events.log <==

2019-02-16 16:57:24.869 [vent.ItemStateChangedEvent] - SandraLightColor changed from 0,0,0 to 0,0,100

==> /var/log/openhab2/openhab.log <==

2019-02-16 16:57:24.881 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"id":22, "result":["ok"]}

2019-02-16 16:57:24.885 [INFO ] [light.internal.lib.device.DeviceBase] - ######### this is control command response, don't need to notify status change!

2019-02-16 16:57:24.891 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"on"}}

2019-02-16 16:57:24.895 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:57:24.898 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=false, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:57:24.902 [DEBUG] [internal.handler.YeelightHandlerBase] - Update CT->4000

Turn off:

2019-02-16 16:57:48.096 [ome.event.ItemCommandEvent] - Item 'SandraLightColor' received command OFF

2019-02-16 16:57:48.103 [nt.ItemStatePredictedEvent] - SandraLightColor predicted to become OFF

==> /var/log/openhab2/openhab.log <==

2019-02-16 16:57:48.132 [DEBUG] [internal.handler.YeelightHandlerBase] - Handle Color Command OFF

2019-02-16 16:57:48.136 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: Write Success!

2019-02-16 16:57:48.142 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"id":23, "result":["ok"]}

2019-02-16 16:57:48.144 [INFO ] [light.internal.lib.device.DeviceBase] - ######### this is control command response, don't need to notify status change!

2019-02-16 16:57:48.146 [DEBUG] [lib.device.connection.WifiConnection] - WifiConnection: get response: {"method":"props","params":{"power":"off"}}

2019-02-16 16:57:48.149 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=true, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:57:48.151 [DEBUG] [internal.handler.YeelightHandlerBase] - UpdateState->DeviceStatus [isPowerOff=true, r=255, g=0, b=0, color=16711680, brightness=100, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_SUNHINE, isMusicOn=false, name=]

2019-02-16 16:57:48.153 [DEBUG] [internal.handler.YeelightHandlerBase] - Update CT->4000

==> /var/log/openhab2/events.log <==

2019-02-16 16:57:48.170 [vent.ItemStateChangedEvent] - SandraLightColor changed from 0,0,100 to 0,0,0
goodfore commented 5 years ago

Thanks. I guess it didn't work as expected. I noticed that the mode is sunshine, which means it won't update the color channel, is that the case? Is it possible to try with hsb mode or color mode?

sverzijl commented 5 years ago

Okay - I do apologize- I only half read what you wrote in the post above with the file. Quite embarrassing.

When I go into the Yeelight App and choose a colour the Yeelight changes to Color Mode. Whilst in that mode everything works correctly with your update. Yay.

I guess the only issue is that we need to make sure we are in colour mode for it to work which may be confusing for future users. Is there any way that it can be made to work in all modes? Or default to colour mode somehow?

I'm not sure if the mode only changes whilst in the app. I'll play around.

sverzijl commented 5 years ago

So - if the light is turned off at the power point and then turned back on it is no longer in Colour mode and must be changed in the app before it will update properly in Openhab.

goodfore commented 5 years ago

Thank you for testing. I think we need to figure out how to logically map the modes to openhab channels.

How many modes are there in the app? Color, HSV, sunshine(CT)? Let's leave out flow mode for now.

Also, it seems like whenever google home controls the light, it's in sunshine mode? Or it was just the state when it was last on?

Thanks, Joe

sverzijl commented 5 years ago

So the only modes I can access via the app are Color and Sunshine.

With Google Home - On/Off just returns to the previous state. Telling Google to change Color goes to Color mode. Not sure what to say to Google home to adjust color temperature.

claell commented 5 years ago

Nice to hear, it works now at least when in color mode.

@goodfore After realizing, sunshine mode means CT mode, I think this brightness should also be mapped to the color channel for color bulbs, since those bulbs use the color brightness channel also for changing brightness when in CT mode. I hope it works to set brightness for their color channel without having the bulb go into color mode, but I think it should work.

goodfore commented 5 years ago

based on the results and the log files, I think it's safe to say that the status update from the bulb always contains info for both colour channel and CT, thus I think we should update both channels on every update, regardless of which colour mode the bulb is in.

goodfore commented 5 years ago

I have made the following changes to the method.

    void updateBrightnessAndColorUI(DeviceStatus status) {

        PercentType brightness = status.isPowerOff() ? new PercentType(0) : new PercentType(status.getBrightness());

        HSBType tempHsbType = HSBType.fromRGB(status.getR(), status.getG(), status.getB());
        HSBType hsbType = status.getMode() == DeviceMode.MODE_HSV
                ? new HSBType(new DecimalType(status.getHue()), new PercentType(status.getSat()), brightness)
                : new HSBType(tempHsbType.getHue(), tempHsbType.getSaturation(), brightness);

        logger.debug("Update Color->{}", hsbType.toString());
        updateState(CHANNEL_COLOR, hsbType);

        logger.debug("Update CT->{}", status.getCt());
        updateState(CHANNEL_COLOR_TEMPERATURE,
                new PercentType((status.getCt() - COLOR_TEMPERATURE_MINIMUM) / COLOR_TEMPERATURE_STEP));
    }

@sverzijl I have uploaded a new zip/jar, pleaes give it a try. Download Here

goodfore commented 5 years ago

Hi @sverzijl , have you had a chance to confirm the new code works for both modes? If everything works, I will submit a PR and close the issue.

Thanks, Joe

sverzijl commented 5 years ago

Hi, apologies, first time this week I've had time to look at. Testing now.

sverzijl commented 5 years ago

So odd behavior. I updated the plugin (merely replaced the previous jar file you sent me). I restarted Openhab and only one of my lights successfully updates - though it updates in any mode. The other light doesn't update in any mode. When I restarted Openhab again only one worked - but this time it was my other Yeelight.

Not working light:

2019-02-23 12:00:58.021 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=78, g=217, b=255, color=5167615, brightness=0, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_COLOR, isMusicOn=false, name=null]

Working light:

2019-02-23 12:00:58.021 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=78, g=217, b=255, color=5167615, brightness=0, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_COLOR, isMusicOn=false, name=null]

2019-02-23 12:01:28.636 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=true, r=78, g=217, b=255, color=5167615, brightness=0, ct=4000, hue=359, sat=100, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_COLOR, isMusicOn=false, name=null]

2019-02-23 12:01:30.769 [INFO ] [light.internal.lib.device.DeviceBase] - status = DeviceStatus [isPowerOff=false, r=53, g=255, b=127, color=3538815, brightness=52, ct=3441, hue=142, sat=79, isFlowing=false, delayOff=-1, mFlowItems=null, mode=MODE_COLOR, isMusicOn=false, name=]

==> /var/log/openhab2/events.log <==

2019-02-23 12:01:30.793 [vent.ItemStateChangedEvent] - SimeonLightColor changed from 141,79,0 to 141,79,52
sverzijl commented 5 years ago

Also - just to add to the previous comments about what modes there are, there is one mode I didn't notice before called 'null'. It occurs when Google Home turns on the light when someone has reset the Yeelight at the power point.

goodfore commented 5 years ago

Hi, try remove the things, then hard reset the bulbs. Then add the things back in.

sverzijl commented 5 years ago

Works perfectly! Brilliant. Thanks for fixing it!

goodfore commented 5 years ago

Glad it works. I will submit the PR soon. Thanks for testing.

claell commented 5 years ago

Glad to hear that! For reference: #4973