zwave operations question

[jkmonroe]

so im still learning about how zwave actually works. i came across this in a forum and it got me to thinking -

I feel silly writing that last sentence because of course it should work that way!
However, that's not how the Leviton VRCS4-MRZ works when I go through the Hub.
Pressing a button the first time sends an "on" command, the second time sends an
"off" command, on, then off, on, then off, and so on. It doesn't matter if the switch is
off, it will still send an "off" command. If the Hub would just toggle the switch when I press
the button, then there would be no need for two-way communication. But as it stands,
the VRCS4-MRZ needs feedback in order to send the correct command.

so let's see if i get this right, please correct me where im wrong:

right now a scene controller sends out a scene actuator message, which we can receive no problem in CQC. but when we go to turn the scene off, it always sends the same message.

assuming my understanding of the above is correct, if the VRC0P sees the incoming button press and then sends back some data that we'd have to extrapolate as acknowledgement, we would then see an identifiable 'OFF' message?

so for a scene controller - button 1 sends command identifiable as button 1, VRC0P receives command, driver then sends back acknowledgement that 'scene' was actuated and button light stays on. press button again to turn off, but this time the message would be different, so the scene knows to turn itself off. VRC0P receives message, driver sends back acknowledgement and button light turns off.

does that make sense?

[Dean Roddey]

AFAIK, we just get a scene was activated. Anything beyond that is state that the receiver would have to keep. But there's nothing that indicates a scene in Z-Wave is off or on really, since it's just a set of levels to apply to lights, and at any time those individual lights can be modified after that. So there's no real concept of a scene being off or on.

As always it's complicated by the fact that there are three different scene mechanisms in Z-Wave. But, generally, all they provide is the id of the scene and a duration for invoking it. Sometimes they provide a dimming level for the scene.

Some of them work by just sending out commands directly to the lights to set them to a stored scene setting. The other schemes store scene info in the lights themselves and the controller just sends a 'set scene x' command to the lights and they see if they are set up for scene x and set themselves if so.

The VRC0P see one of those types of messages, but there's no scene off/on information in them. And that's pretty much the case for all scene controllers. There's no such thing as a scene being turned off, there's just setting a scene.

[jkmonroe]

AFAIK, we just get a scene was activated. Anything beyond that is state that the receiver would have to keep. But there's nothing that indicates a scene in Z-Wave is off or on really, since it's just a set of levels to apply to lights, and at any time those individual lights can be modified after that. So there's no real concept of a scene being off or on.

As always it's complicated by the fact that there are three different scene mechanisms in Z-Wave. But, generally, all they provide is the id of the scene and a duration for invoking it. Sometimes they provide a dimming level for the scene.

Some of them work by just sending out commands directly to the lights to set them to a stored scene setting. The other schemes store scene info in the lights themselves and the controller just sends a 'set scene x' command to the lights and they see if they are set up for scene x and set themselves if so.

The VRC0P see one of those types of messages, but there's no scene off/on information in them. And that's pretty much the case for all scene controllers. There's no such thing as a scene being turned off, there's just setting a scene.

so what youre saying is because those scenes are directly linked to specific devices, having a single 'off' doesnt matter because only those linked devices get the off.

with that implementation, devices can only be linked to one active scene at a time. so let's say a single device is part of 2 scenes, i turn on scene 1, then turn on scene 2, how does the controller know what to do with the remainder of scene 1 based on the actions of a single device?

this is all very confusing and makes no sense whatsoever.

[Dean Roddey]

I think you are thinking that scenes are more than they are. All a scene is is a set of levels for a set of configured lights. It's no different than if you created a CQC action that set a set of lights to particular levels, that's it. It's just configured at the Z-Wave level instead of the CQC level.

When you invoke a scene, those commands go out to set those configured light levels for scene 1. The 'scene' has no life beyond that. If you do scene 1, then those commands are sent. If you then do scene 2, then those lights configured for scene 2 are affected. Any that were affected by scene 1 but not scene 2 just stay where they are.

There's nothing out there that says 'scene 1 is now set', any more than (in the CQC action scenario) there'd be something out there that said CQC Action XYZ is now set. It was just a set of commands to lights to change levels.

[jkmonroe]

i do get that part on some level.

but considering all of these devices have two-way LED status indicators suggest otherwise. they *must* know, by receipt of a message, that something has happened.

vivek actually has this working independent of CQC (i think). he can turn a light on with his Leviton scene controller, the LED turns on, he hits it again, the light turns off and the LED turns off. if he manually turns on the light, the LED comes back on, and hitting the scene controller will turn the light off.

so somewhere, there is two-way activity. i just dont know how or where that is.

[Dean Roddey]

If the LED is a separately controllable thing and its status can be read, you could of course have the pressing of button 1 turn on the LED for button 1, and use that as some sort of indicator of status. For a single light, you don't need to do that since the light status itself is that thing, you know its off or on by just looking at the light status.

For scenes, you could do it to say this is the last scene button I sent, but that's sort of semi-meaningless because if there's more than one light in a scene, and they can all be changed individually after the scene is invoked, what is the state of that 'scene'? It's neither off or on, because it's really just a set of levels for a set of lights, and any of them could have been changed since that scene was last invoked.

[jkmonroe]

see, thats what i don't understand! my pea-brain can't grasp it.

let's say i turn on a scene, then through the rigamarole of daily life, switches get manually turn on/off/dimmed, but the scene is never disabled.

does that LED indicator just stay on all day thinking the scene is enabled when in real life it isn't?

i mean, Hue does the same thing you're describing; you simply enable a scene and off happens elsewhere. it's easier to fully comprehend because there are no indicators other than lights being on.

[Dean Roddey]

Assuming the light comes on just because you pressed the button, then yeh, it would just stay one because the controller has no idea whether the scene is actually still in effect as it was invoked. It would have to watch every configured light in order to do that. And, in the scheme where the scene info is stored in the actual modules, it wouldn't even now what lights it's affecting necessarily. It just sends out a 'scene 5 was activated' msg to anything it's associated with. Some of them may respond to scene 5 and some may not, so it wouldn't know what scene 5 even means.

[jkmonroe]

i could get behind this if there wasn't that damned LED.

i guess my original idea of using Insteon keypads to display status is the 'right' one, but in reality it seems like it's the only one.

[zaccari]

When I started using the Insteon KPLs, I loved them. I got a visualization of the buttons I pushed when they were not local. Now that they are aging, I have to say, the Insteon switches are excellent but they do not last. The KPLs I have lose their links and for some reason they flash meaning they did not get an ack to their request. I guess it could be the bridges getting old but this smells just like the X10 technology that worked great right until it fried itself.