Is my Choice of ASync Correct in This Instance?

[Monte73]

Hello everyone,

So jumping ahead into home automation, mostly with regards to motion sensing and light control right now and creating my various pistons. When I decided to create the one for fading my lights in 30 minutes prior to sunset, I thought to myself I need to do this using async versus sync, otherwise the emulation time for the fade will prevent the rest of the lights coming on at the same time that fade slightly different.

Can someone please take a look and tell me if I am correct in that assumption and have done this correctly?

One other question, if ask for the light to be set to a temp, does that also automatically turn the light on at the previous level it was shut off at? I am thinking it does which is why I set it to 1% at first in case it was on much brighter prior. The only thought around this is for that brief moment if the color was something else it will momentarily flash as that color. My hope is that I can set it to a specific temp or color without turning it on and then fade it in from 0 to the end level, just not sure if that is possible. These are Hue bulbs to just be clear in case that makes a difference.

Thanks for the help!
Ron

[WCmore]

My two cents?

Fades are some of the most demanding commands, forcing webCoRE to send a different command every couple of seconds… Plus, you want to do it with 7 devices… Plus, you want them ASYNC…

Bleh…

Essentially, you are trying to push out 450 commands in about a minute.

---

My apologies, but in my house, I would avoid this logic like the plague…

[WCmore]

One other question, if ask for the light to be set to a temp, does that also automatically turn the light on at the previous level it was shut off at?

It depends on the Device Handler. The best bet is to simply Test a single line piston to see how your device responds.

---

My hope is that I can set it to a specific temp or color without turning it on and then fade it in from 0 to the end level, just not sure if that is possible

As far as I know, it’s not possible with Hue. You can have the color set before it turns off… Or a lazy man’s way is to have it come on at 1% (barely visible), then change the color… Then do whatever.

[Monte73]

Thanks for the reply… I appreciate the advice. I didn’t know if webCoRE was constantly sending the commands or if the hue bulbs were able to perform the logic in there own once the initial command was sent. After testing though I can see how fading does not really work well as it seems to update the level every 5 seconds or so even with just one bulb not making for a smooth fade in.

I’ll see if there are any of the hue formulas that do the same thing at all and just make the webCoRE piston more basic where needed.

[Mebejedi]

I would avoid this logic like the plague in my house.

There’s a plague in your house?

(Sorry, couldn’t resist )

[Robin]

We all have a plague nearby right now <<<<2m>>>>>>

I wouldn’t touch smart bulbs with a barge pole, I prefer proper wall switches, but with my Fibaro Dimmers I can control the fade duration by tweaking the device parameters.

I’ve altered my Fibaro handlers so that I can change the fade duration via a custom command in webCoRE, so i only have to send a single ‘on’ command, the module does the rest (perfectly smooth and reliable across multiple circuits).

Looks like it may be even easier with Hue… the following handler is old but it lets you adjust the required fade duration alongside a setLevel command.

i.e

setLevel(99, 18000)

Would transition to level 99 from current level over 30 minutes (18000 tenths of a second = 60 * 30 * 10)

The fade duration is actually hard coded into the handler as ‘21’, but easy enough to tweak the handler to allow setting from webCoRE.

Enhanced Zigbee Hue Bulb - Direct Connect to ST

Add:

command "setLevelWithDuration"

and

def setLevelWithDuration(value, duration) {
	log.trace "setLevel($value)"
    def transitionTime = swapEndianHex(hexF(duration,4))
    
    
    def unreachable = device.currentValue("unreachable")
    log.debug unreachable
    if(unreachable == null) { 
    	sendEvent(name: 'unreachable', value: 1)
    }
    else { 
    	sendEvent(name: 'unreachable', value: unreachable + 1)
    }
    if(unreachable > 2) { 
    	sendEvent(name: "switch", value: "off")
        sendEvent(name: "switchColor", value: "off", displayed: false)
    }
    
	def cmds = []

	if (value == 0) {
		sendEvent(name: "switch", value: "off")
        sendEvent(name: "switchColor", value: "off", displayed: false)
		cmds << "st cmd 0x${device.deviceNetworkId} ${endpointId} 6 0 {}"
	}
	else if (device.currentValue("switch") == "off" && unreachable < 2) {
		sendEvent(name: "switch", value: "on")
        log.debug device.currentValue("colorMode")
        sendEvent(name: "switchColor", value: (device.currentValue("colorMode") == "White" ? "White" : device.currentValue("colorName")), displayed: false)
	}

	sendEvent(name: "level", value: value)
	def level = hex(value * 2.55)
    if(value == 1) { level = hex(1) }
	cmds << "st cmd 0x${device.deviceNetworkId} ${endpointId} 8 4 {${level} ${transitionTime}}"

	//log.debug cmds
	cmds
}

[WCmore]

I didn’t know if webCoRE was constantly sending the commands or if the hue bulbs were able to perform the logic in there own once the initial command was sent

It’s usually webCoRE trying to carry the burden, but there are a few Device Handlers that can accept a single command, and it takes over from there issuing the mini-commands during the duration. (For an example, see Robin’s post above)

---

Sorry, couldn’t resist

LOL… I did not notice how that came out… Fixing it now.