Scene same as Luup?

I have 8 Philips Hue bulbs located around the outside of my property - in a Welcome Group.

I’d like them to come on early in the morning, then go off after sunrise. I’d like them to come on just before sunset and go off at around midnight. All very simple to do - either via Vera or via the Hue app. (if you forget the sunrise and sunset requirement).

What I’ve found is that - because the bulbs are quite spread out and I suppose the connection isn’t rock solid 100% of the time - that the Vera control of these bulbs via Luup seems a bit hit-and-miss. Whereas, if I press the button to turn them all on or all off on my Hue Tap switch, you can guarantee they’ll do as told. I control all of my Hue Bulbs in Vera Scenes via a line of Luup:

luup.call_action ("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{newLoadlevelTarget="0"},deviceNo)

What I’m really wanting to know is this… is there a difference in operation between creating a Vera Scene (trigger, devices, action) vs. me selecting a trigger and then writing some Luup, like above, to turn the bulbs on and off?

Obviously the Luup method, I’m assuming anyway, is fire-and-forget - I send the command and I hope for the best. I do put it in a loop for each bulb, but it’s still not perfect - I can’t depend on it. But is the Scene method one where it sends the command to each Hue bulb and then checks that the command has been received and actioned by checking the bulb’s state?

Or not?

This is actually my - kind of brute force - code to turn all the Welcome Hue Bulbs off:

for i=5,1,-1 do for deviceNo, d in pairs (luup.devices) do if ( ~= "") then if (d.category_num == 2) then if (d.room_num == 14) then luup.log ("SCENE Welcome Lights Off After Sunrise: Setting " .. d.description .. " to no brightness.") luup.call_action ("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{newLoadlevelTarget="0"},deviceNo) luup.sleep (100) end end end end end

It works, mostly… sometimes the odd bulb will be left behind. Any answers to my question, or suggestions for my code, will be very much appreciated.

It is very dangerous to use luup.sleep in a loop.

Calling it after a call_action on a Z-Wave device is meaningless …
Call action on a Z-Wave devices queues the request … and the luup.sleep call prevents the Z-Wave driver from processing the queued request.

I can certainly remove that. My thinking had been that if I was suffering from a very transient network issue, it might be resolved the next time around the loop, with a small delay.

I’ll remove it and monitor.

But the question still stands about fire-and-forget Luup vs. ‘synchronous’ - command-confirmation Scene, I guess?

With Vera Z-Wave commands are queued to the device … It returns before the command has completed.

If you want to do command-response.
You need to convert your code to an event driven model.
You would use luup.variable_watch to attach a function to be called when the Status (or LoadLevelStatus for a dimmer) is changed.

It’s only when the callback is made that you know the command was actually processed successfully.


What I am perceiving is this:

With Vera controlling my 8 Welcome Hue bulbs (just evidenced this morning) it’s rather hit-and-miss - 5 of 8 bulbs were on this morning (that’s with the sleep call removed from the code I showed earlier).

When I walked back into the house and pressed the Hue Tap button just once, and re-checked, all 8 Welcome bulbs were on.

I don’t believe Vera is offering me the same quality of control over the Hue Tap… but my understanding gap is - why that could be?

In my head both methods would be sending the same commands to the Bridge - which then passes them along the network to each bulb. Why is one seemingly more correct than the other?

If there was intermittent network quality issues, I could tolerate the odd time when all 8 Welcome bulbs don’t come on or go off - but with Vera controlling them it is every time that a portion of them aren’t successfully instructed - a press of the Hue Tap gets things back to how they should be. It’s perplexing.