Dome Water Valve Not Triggering Control in Programs

[io_guy]

I have a Dome water value (ZW+) and it doesn't seem to trigger the control "switched on" in programs.

If I change the program to status on, no issue.  Change to control on, no triggering.  When I hit the button on the valve this is what the log shows:

[ZWAVE-RX ZW006_1] [25/03] Binary Switch Report val=0xFF ACK,AUTO,EXPLORE From=0x06
[ZWAVE-RX ZW006_1] [25/03] Binary Switch Report val=0xFF ACK,AUTO,EXPLORE From=0x06
[D2D EVENT   ] Event [ZW006_1] [ST] [100] uom=78 prec=0
[     ZW006_1]       ST 100 (uom=78 prec=0)

Device info shows:

[ZW-SHOW         ] Main Water Valve
[ZW-SHOW         ] ZW006_1 uid=6 type=4.16.6 mid=543 tid=3 pid=2
[ZW-SHOW         ] Association Group ID 1
[ZW-SHOW         ]    -  x5E  V2   ZWAVEPLUS_INFO
[ZW-SHOW         ]    -  x86  V2   VERSION
[ZW-SHOW         ]    -  x72  V2   MANUFACTURER_SPECIFIC
[ZW-SHOW         ]    -  x5A  V1   DEVICE_RESET_LOCALLY
[ZW-SHOW         ]    -  x73  V1   POWERLEVEL
[ZW-SHOW         ]    -  x85  V2   ASSOCIATION
[ZW-SHOW         ]    -  x59  V1   ASSOCIATION_GROUP_INFO
[ZW-SHOW         ]    -  x25  V1   SWITCH_BINARY
[ZW-SHOW         ]    -  x20  V1   BASIC
[ZW-SHOW         ]    -  x27  V1   SWITCH_ALL
[ZW-SHOW         ] - Secure

[glacier991]

I am investigating a way way to automatically shut off my water main in the event any of my CAO moisture sensors detects a leak. Curious about your experience with the Dome unit and remote triggering via Z wave. Did you ever get your above issue resolved?

 

[io_guy]

Triggering works fine.  My issue is the ISY doesn't trigger off control, meaning  when I push it's button.  Status updates but no control trigger.

[Michel Kohanim]

Hi @io_guy,

What do you mean by "ISY doesn't trigger off control"? Are you providing ISY with a  Control? If so, then it should trigger in programs under Control.

With kind regards,
Michel

[io_guy]

It's not a Node Server, it's a z-wave device that gets linked.  When I use the control event for it in programs it never triggers.  The log info is in my first post.

[MWareman]

AFAIK - many zwave devices don’t distinguish between status and control (like Insteon does).

I don’t think I have a single zwave device where I’ve ever seen anything like a control message. Only status. I’ve had to use status throughout with zwave devices.

[palayman]

13 minutes ago, MWareman said:

I don’t think I have a single zwave device where I’ve ever seen anything like a control message.

Really?  If it's listed as a control message by the ISY it needs to be control, as io_guy's post shows, otherwise it should be listed as status. This is a bug not a feature.

[larryllix]

50 minutes ago, MWareman said:

AFAIK - many zwave devices don’t distinguish between status and control (like Insteon does).

I don’t think I have a single zwave device where I’ve ever seen anything like a control message. Only status. I’ve had to use status throughout with zwave devices.

Then ISY should not allow the construct for something that doesn't exist.

[MWareman]

2 hours ago, larryllix said:

Then ISY should not allow the construct for something that doesn't exist.

Agreed. If only zwave devices could be queried for functionality they support - and only the options supported presented. It would make this much easier. Unfortunately, as far as I can tell the basic set capabilities in zwave never anticipated needing a difference between 'control' and 'status', yet i'm sure some devices exist that send control type messages as custom elements. Just another reason to get a zwave sniffer I guess....

[simplextech]

9 minutes ago, MWareman said:

Agreed. If only zwave devices could be queried for functionality they support - and only the options supported presented. It would make this much easier. Unfortunately, as far as I can tell the basic set capabilities in zwave never anticipated needing a difference between 'control' and 'status', yet i'm sure some devices exist that send control type messages as custom elements. Just another reason to get a zwave sniffer I guess....

Z-Wave devices can be queried for the functionality they support.  In fact this i what is done on the initial include process.  A device is queried about what "device classes" it supports and that information is used to determine the functionality/capabilities of the device.  This information must be interpreted on the software side correctly to match the functionality of the device appropriately.

The Control vs Status thing is not a big concept within Z-Wave like it is in Insteon.  Coming from a Z-Wave background this at first confused me with the difference in programs with ISY.  Z-Wave devices unless they support Scene Controller class don't necessarily provide a "Control" like function where a change is detected as being manually initiated from the device like Insteon does.  With that all updates/changes are all "Status".  In marketing you will see the term "Instant Status".  That refers to the physical changes being pushed to the controller from the device itself.  This would be the equivalent of "Control" from Insteon but it is still called status from z-wave.  Since it is still status there is limited capability from the controller to distinguish it as being from a physical change vs a programmatic change... it is just a change of status.

[larryllix]

27 minutes ago, simplextech said:

Z-Wave devices can be queried for the functionality they support.  In fact this i what is done on the initial include process.  A device is queried about what "device classes" it supports and that information is used to determine the functionality/capabilities of the device.  This information must be interpreted on the software side correctly to match the functionality of the device appropriately.

The Control vs Status thing is not a big concept within Z-Wave like it is in Insteon.  Coming from a Z-Wave background this at first confused me with the difference in programs with ISY.  Z-Wave devices unless they support Scene Controller class don't necessarily provide a "Control" like function where a change is detected as being manually initiated from the device like Insteon does.  With that all updates/changes are all "Status".  In marketing you will see the term "Instant Status".  That refers to the physical changes being pushed to the controller from the device itself.  This would be the equivalent of "Control" from Insteon but it is still called status from z-wave.  Since it is still status there is limited capability from the controller to distinguish it as being from a physical change vs a programmatic change... it is just a change of status.

On a switchLinc the control comes from the paddle status, while the status comes form the dimmer electronics status. I am not sure if that applies to other styles of Insteon devices as they have no paddles but I believe UDI has only provided triggers from actual  signals. Zwave may be different. I have none and hopefully will never need any.

[palayman]

25 minutes ago, simplextech said:

The Control vs Status thing is not a big concept within Z-Wave like it is in Insteon.  Coming from a Z-Wave background this at first confused me with the difference in programs with ISY.  Z-Wave devices unless they support Scene Controller class don't necessarily provide a "Control" like function where a change is detected as being manually initiated from the device like Insteon does.  With that all updates/changes are all "Status".  In marketing you will see the term "Instant Status".  That refers to the physical changes being pushed to the controller from the device itself.  This would be the equivalent of "Control" from Insteon but it is still called status from z-wave.  Since it is still status there is limited capability from the controller to distinguish it as being from a physical change vs a programmatic change... it is just a change of status.

Yes. Here is excerpt from the manual for my Zen15:

On/Off Status Change Notifications
Parameter 24: Your Power Switch will automatically send
a notification to the controller and other associated
devices if its status changes from on to off or the other way
round. Choose when you want it to send the report.
Values: 0 – disabled (it will not send status change
notifications); 1 – sends notification if status is changed
manually or remotely via Z-Wave (default); 2 – sends
notification ONLY if status is changed manually by
pressing and releasing the Z-Wave button on the Power
Switch; Size: 1 byte dec.

I interpreted this to mean that by default On/Off Status should be a Control function in the ISY and it did show up as Control. Other functions like Power, Current and Voltage just show up as Status in the ISY.

[simplextech]

4 minutes ago, palayman said:

Choose when you want it to send the report.
Values: 0 – disabled (it will not send status change
notifications); 1 – sends notification if status is changed
manually or remotely via Z-Wave (default); 2 – sends
notification ONLY if status is changed manually by
pressing and releasing the Z-Wave button on the Power
Switch; Size: 1 byte dec.

Pay close attention to that part of the details.  It's an either or situation of receiving status.

1 - send notification if status is changed manually or remotely via Z-Wave (default)

2- sends notification ONLY if status is changed manually by pressing and releasing the Z-Wave button on the Power Switch

There is no distinction between a manual or z-wave change only when to send the status update.  Always no matter the change (physical/z-wave) or only from physical change.  This is different in the "control" aspect of Insteon where if it's physically changed that sends the "control" but any other change still updates the status.  This is usually not a problem with z-wave as the use of device -> device associations are not as commonly used.  But if they are then a link like this would be problematic:

• Switch set to option 2 (only when manually changed)
  • Motion sensor associated with switch on/off

In that scenario the controller would never receive the "status" of the switch because it is configured to not send status on z-wave changes.  IF no direct associations are ever used and the switch is controlled ONLY by the controller OR manually then the status should always be accurate from the controller view.

I think this is a large difference in how Insteon handles the differences as the "status" is always known/sent whether it's from manual or Insteon command but the "control" is specific to a manual or device action (motion sensor activated / open close sensor activated).

This status thing has a long discussion on other forums around z-wave and trying to determine if the "change" was manual or programmatic and although z-wave devices are not including "Instant Status" in more and more devices there is still no "good" or standard method of determining manual or z-wave change it's all just status.

[Michel Kohanim]

Just to clarify, many Z-Wave devices indeed support control such as motion sensors, switches etc. In short, those devices that can report their change of state. The only reason some don't is because they might be old and inflicted with the Lutron patent.

With kind regards,
Michel