zwave.sceneActuatorConfV1.sceneActuatorConfGet(sceneId: 0)

According to the spec for “Scene Actuator Configuration Command Class, version 1”

A call to get where the scene id is 0 states:

“The value 0 MUST indicate that the current active scene (if any)”

For the report it states:

"The value 0 MUST indicate that no scene is currently active at the sending node and no scene setting is advertised in this command. "

Does ST drop the request for scene id 0? It does not appear that ST will ever receive a report if the sent scene id 0 is requested.

Are you talking about the Z-wave command class for a Z-wave scene activation? SmarThings doesn’t support Z-wave scenes. They have created their own scene architecture but it doesn’t work the way that Z wave scenes do.

I am referring to the Z-wave API call, not Smartthings application layer scene support.

The API call should be supported correctly for Z-wave certification. The ST hub appears to have a bug with regards to this API call.

Smartthings doesn’t support z wave scenes.

I would suggest that you look at the device code for the “ZWN-SC7 Enerwave 7 Button Scene Controller” (published back in 2014,) or similar devices, if you want to understand the question before you answer.

The term “scenes” is overused, which leads to a lot of confusion.

LMAO…what a jerk. For your information, I have read it. Your hub is a primary controller. Scene control would come from a secondary controller. And unless your DTH is programmed to interpret those messages into something else, SmartThings won’t see them. Hence, ST doesn’t support Z wave scenes. Maybe if you searched on the forum for the 4 or 5 other articles out there on this topic, you wouldn’t have posted this on your own.

Since you don’t seem to have anything to share, but are well read, let me provide you with a few more details.

In Z-wave networks you have controllers. The function of the PRIMARY controller relates to other controllers only for health of the network (I.e. it alone is should handle the creation of new nodes on the network).

A “scene” is a bit Swiss Army knife, different vendors/applications will use it in different ways. A universal concept in it though is that devices which support, and by this I mean non-controllers, will hold some state information about requests. As an example you can take a GE Z-wave plus light switch and toggle the power to it using a scene (you can either preprogram the value or issue a new value each time). Information about the last level and duration change are also provided. If the last change was made by a controller or by someone physically toggling the switch is also available ( this requires you make requests via the scene controller API).

As one example, by requesting the state of the switch you can find out if the switch was last updated by someone tapping it or if it was done by the controller ( a bonus feature is that you can determine which controller made a change (If how that works is not obvious, I can explain this if this is a mystery to you; there are many misconceptions around how multiple controllers work on a single network)).

To find out the state of the device you need to be able to request the current state. This is done by requesting scene 0 (scenes 1…255 are valid states). Currently, it appears that the ST is dropping sending requests for scene 0 somewhere in the application layer.

If you find yourself wanting to learn more about the topic, you can search for “ZWN-SC7 Enerwave 7 Button Scene Controller” which was written by Matt Frank. He created both an application and device driver using some of the z-wave capabilities. In the device driver you should look for the keywords SceneActivationSet, SceneActuatorConfGet, and SceneActuatorConfReport.

Other examples can be found in the ST tree if you look at the device drivers for the Aeon Key Fob, the Aeon Minimote, or the Cooper rf9500.

You will find that a number of devices can only be operated by using this portion of the z-wave API.

I am sorry if my reply to your second response made you feel uncomfortable.

My original post probably should have been a bug report.