io_guy Posted January 19, 2019 Share Posted January 19, 2019 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 Link to comment Share on other sites More sharing options...
glacier991 Posted March 9, 2019 Share Posted March 9, 2019 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? Link to comment Share on other sites More sharing options...
io_guy Posted March 9, 2019 Author Share Posted March 9, 2019 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. Link to comment Share on other sites More sharing options...
Michel Kohanim Posted March 10, 2019 Share Posted March 10, 2019 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 Link to comment Share on other sites More sharing options...
io_guy Posted March 10, 2019 Author Share Posted March 10, 2019 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. Link to comment Share on other sites More sharing options...
MWareman Posted March 11, 2019 Share Posted March 11, 2019 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. Link to comment Share on other sites More sharing options...
palayman Posted March 11, 2019 Share Posted March 11, 2019 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. Link to comment Share on other sites More sharing options...
larryllix Posted March 11, 2019 Share Posted March 11, 2019 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. Link to comment Share on other sites More sharing options...
MWareman Posted March 11, 2019 Share Posted March 11, 2019 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.... Link to comment Share on other sites More sharing options...
simplextech Posted March 11, 2019 Share Posted March 11, 2019 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. Link to comment Share on other sites More sharing options...
larryllix Posted March 11, 2019 Share Posted March 11, 2019 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. Link to comment Share on other sites More sharing options...
palayman Posted March 11, 2019 Share Posted March 11, 2019 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. Link to comment Share on other sites More sharing options...
simplextech Posted March 11, 2019 Share Posted March 11, 2019 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. Link to comment Share on other sites More sharing options...
Michel Kohanim Posted March 12, 2019 Share Posted March 12, 2019 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.