Milight remember last dimer value

Hi, I am playing with Milight lights rules and have little essue with setting Dimer. When I swith light off with SWITCH item and then try dim it with DIMER item it first start with preview value (for example 100% and then change to set value).

When I try dim lights from 0% to 100% slowly it first start on 100% and than change to 0%, 10%, 20% … so there is 100%flash on the begining. Am I missing something?

Even If I sent dimer to 0% first with Light_brightness_Room_ALL.sendCommand(0) it still start from 100% as it remember form last SWITCH on/off (ON = 100% dimer)

rule "Xiaomi Switch button 1 Room"

    Channel "mihome:sensor_switch:XX:button" triggered
    var actionName = receivedEvent.getEvent()
    switch(actionName) {
        case "DOUBLE_PRESSED": {                               
            var percent = 0                      
            while(percent  <= 90) {
              Light_brightness_Room_ALL.sendCommand(new Integer(percent).toString)
              percent = percent + 10

My binding does not behave the same way and works the way you are wishing. It needs an opensource hub, more info in the thread.

Thank you Matt for reply. That project is wonderful and the espopenhub well done!

I actually build ESPMilishtHub, but using it with “original” OH2 Milight binding over “virtual iBoxes v6” UDP. So you think is better use binding for ESPMilight or switch to MQTT?

I also rebuild this binding to fix flash in nightmode - and it fixed it …
NIghtmode flash link

Also, when you setup each bolb for one channel, are you able control them all at same time? I find out there is little delay when u have group of bolb and I have to control them over 0 channel. I gues bridge can not sent command in same time to all bulbs - lets say turn on 8 bulds each on different channel …

I am biased as I wrote the binding as I wanted to use the open source hub with mqtt for more speed as I have around 23 milight globes all off the one hub currently and all with individual control. Since I have never really used the original binding I have no idea what it is like, but the good news is you can run both bindings at the same time to try them.

The key I found was to build a better nrf24 setup and to reduce the setting called rf repeats then the hub gets even better with multiple globes. I can switch all 23 globes in around 2 seconds without using group 0 shortcuts. I am working on a way to reduce that time in half but it needs a hub firmware change. Do a search in the thread for rf repeats and I have photos of nrf boards I tested.

I Also have full seamless control over google home mini, all colours, dimming, nite mode and back to white all via voice.

Looks very good. Really nice job! I checked whole post and I will try rewrite mine thinks, items into your binding. Since original Milight binding is not moving/fixing this fast as yours and has bugs (it took me lot of time, find out, that its binging bug and not wrong rules setup - especially flas before nightmode and last dimmer state) :slight_smile:
Have to go through MQTT setup.

Thanks a lot!

I too experience this (OH 2.4) with my Zigbee lights. The workaround I use is to first set the light(s) to 1%, then command the light(s) to turn OFF. If you are toggling lights with a rule, this is not an inconvenience to have a two-step OFF procedure, and will cease the flash you are referring to.

What is happening is the light (or binding) is remembering the last percentage used (above 0%), so it decides go to that percentage level first. Of course that is pretty silly when commanding the light to be set to 1% and it turns on at 100% then down to 1%. :-/ So, to work around this when you want to turn off the light via a rule, first command the light to 1 (one percent), then command the light to OFF.