OK, wow, this is long winded…sorry! I snagged some of the Cooper Aspire RF receptacles when Homeseer had the sale a couple weeks ago. They are scene-capable, and work well with Leviton controllers.
When using the Cooper Aspire RF receptacles, since they are scene-capable, and the Leviton controllers can flip them on instantly. Installed them, included them, changed scenes, Vera reprogrammed the zone controllers, and things worked instantly…EXCEPT LED control and status in Vera. This isn’t an issue with other Leviton receptacles, so there is something different going on.
I enabled verbose logging, and I see the Scene getting activated (I added a GE switch for testing). Vera turns on the GE switch, and then I see this in the log:08 08/10/12 19:29:39.993 JobHandler_LuaUPnP::HandleActionRequest device: 138 service: urn:upnp-org:serviceId:SwitchPower1 action: ^[[36;1mSetTarget^[[0m <0x803>
08 08/10/12 19:29:39.994 JobHandler_LuaUPnP::HandleActionRequest argument newTargetValue=1 <0x803>
24 08/10/12 19:29:40.117 ZWaveNode::ReceivedMessage node 109 device 138 skipping SetTarget because it's a scene controller <0x803>
Device 138 (node 109) is the Aspire RF receptacle…but it isn’t a scene controller, and shouldn’t be skipped! Since Vera doesn’t try to turn it on, and the device doesn’t seem to report to Vera when it’s turned on from a controller, the LED for the scene never gets turned on.
Any thoughts/ideas? The receptacle supports 24 associations (I think)…does Vera need to be associated with a certain one to get all status updates? And running the scene from the dashboard works correctly.
Background on Leviton external LED control:
It’s a “one-way street” for external Leviton LED control (see http://bugs.mios.com/view.php?id=1476 and http://forum.micasaverde.com/index.php?topic=6335.msg39275#msg39275 ).
I kept toying with things, and found a workaround.
To each scene, I added a 1 second delay, and repeated the actions for each device. That triggers Vera to set the device appropriately (even though the controller already did it). This way, Vera gets updated nearly immediately, and the controllers LEDs are correct.
Since Vera runs the scene (but skips part of it), you can also set the light directly via LUUP, but then the status in Vera isn’t correct (until Vera gets around to polling the devices).
Interesting. Your observation is consistent with my not-fully investigated suspicion that Vera doesn’t verify the state of the (devices in the) scene, for scene-capable devices.
I think what the trace really means is that she’s skipping setting the device (or otherwise verifying its state), as it is controlled by a scene controller.
That works ok in a Leviton environment, as the device’s state update will come to Vera through the reverse association. But as you observed, it won’t work with non-Leviton scene capable devices even though they may support instant status updates, such as the Coopers, because they presumably don’t send an update when controlled remotely. And it certainly won’t work with a scene-capable device that does not support instant status updates, such as the Evolve gear. (That’s how I noticed it originally.)
So, for instance, running a scene that controls a GE plug-in module would work fine, but running the same scene with the Evolve variant would not; in terms of the LED updating.
I guess MCV should add some form of scene state verification, either by repeating the actions (as you did; and I think Vera may be used to do?) or polling.
I filed a bug report, #2512.
Good; thanks! So your observation (with the Coopers) triggered me to finally take a closer look at this, so I did try the other scenario I mentioned. Everything we said here appears to be consistent / add up to a hypothesis. So let’s see what MCV does with the bug report.
(The GE scenario worked fine, Vera controlled the device, LED state was correct; Evolve scenario didn’t work, as Vera skipped the device, LED state incorrect.)