Hi,
As said in other discussions, I will have a look at the brightness jssue.
But always keep in mind, that there is no possibility to sync the state if you use the remote, the phone app or openHAB. Milight is a one way communication.
According to the LimitlessLED dev wiki the following commands are used to change brightness.
45 00 55 wait 100ms then send 4E XX 55 - Set Zone 1 to Brightness XX (XX range is 0x02 to 0x1B)
47 00 55 wait 100ms then send 4E XX 55 - Set Zone 2 to Brightness XX (XX range is 0x02 to 0x1B)
49 00 55 wait 100ms then send 4E XX 55 - Set Zone 3 to Brightness XX (XX range is 0x02 to 0x1B)
4B 00 55 wait 100ms then send 4E XX 55 - Set Zone 4 to Brightness XX (XX range is 0x02 to 0x1B)
From my debug windows’s output on the first post (zone 2 being sent) you can see the 47 00 55 sent first followed by 4E 11 55. The latter sets the brightness which in openhab was at 90%. However as the value sent to the bridge is 11 (middle value), in relation to a maximum of 1B, it equates to about 68% brightness.
This is inline with what I am seeing. If I’m right then the scaling in the binding should be changed…?
Thanks for doing some more debugging.
I will have a closer lok at it. Just did a quick review of the code but did not see any wrong scaling at first sight.
The code should transform 90% to a message byte of 18, not 11 like in your logs.
So I eventually figured it out! Really my own stupidity at play here, but I did find a small bug… So it seems that my bulbs have 27 steps as per two posts ago. By me overriding the steps to 10 in my items file I caused 10 to be my maximum. When I changed this to 27 and send a 100 brightness command; now the light goes on full and I can see the correct message sent to the bridge.
The thing is that when I dimm the lights to 1 then nothing happens. This is as a result of the steps (as per API) being defined for the range 0x02 to 0x1B. So when I send a 1 it equates to 1 * 27 / 100 = 0 (int). The lowest value that can currently be sent for a dimm is actually 8, i.e. 8 * 27 / 100 = 2.16 (=2 = 0x02).
So I believe line 271 (and corresponding ones) should change from:
int newCommand = (command.intValue() * rgbwSteps / 100);
Can you give me the org.openhab.binding.milight-x.x.x.jar file earlier?
Have no idea of java compiling and my pregnant wife stumbles without light through the apartment.
Hi, it’s been a while since I’ve looked into this issue again but after installing OpenHAB on a new server today I realise the milight binding is still having the same issue. When I switch off a light it looks like it dims it first and then off. And then when I switch it back on it’s at the very lowest brightness setting.
Did you ever confirm that you resolved this issue?
I’m also getting this kind of flaky behavior on my milight white bulbs. Some don’t come on to 100%, even though I’m sending the ON command to the brightness value. I’m seeing this when I send the ON to a group:switch the bulbs are assigned to.
If I jiggle the slider in Android I can get it back to 100%.
Not sure if there is anything I can do to help troubleshoot. This is on 1.8.3.
I’m also having the same problem. I tried implementing the virtual switch that was suggested in another post, but I’m getting an error
Cannot determine item type of 'officeVirtualLightON’
org.openhab.core.items.ItemNotFoundException: Item ‘officeVirtualLightON’ could not be found in the item registry
So I must not have that set up correctly, although I cannot spot the error.
I’ve tried to implement this as well, but I’m getting an error -
Cannot determine item type of ‘officeVirtualLightON’ org.openhab.core.items.ItemNotFoundException: Item ‘officeVirtualLightON’ could not be found in the item registry7
Items (I’m not sure what is the function of the first labels in the definitions “Brightness” etc, I have tried with and without these) -