Help with receptacle control

[Dean Roddey]

Though, in any modern system, folks tend to assume the ability to display the status of things graphically, so any subsystem that doesn't provide good, low latency feedback would fall short on that front, even if sensing the state of a thing isn't required in terms of reacting to state changes.

 

[pete_c]

Yup; here never much cared about the lighting status feedback stuff mostly because initially I was just a happy camper with remote capabilities of my light switches from yesteryear.
 
Fast forward to my lawn irrigation status feedback and all of the variables utilized to water the lawn to get that nice green look (our subdivision is surrounded by a golf course).
 
The endeavour did start with just remote controlling the valves utilized to water a subsection of my lawn.  Knowing just that the valves would open and close accordingly while concurrently seeing the lawn being watered was a nice thing.  I wanted more so I added more hardware pieces to provide a bit more granularity.  Initially it was just a weather station, rain tipping buckets, rain sensors et al.  Then it went to measuring the flow and the amount of water that each zone utilized; well then to the amount of evaportransporation and comparing values of calculations versus actual values seen by analog to digital sensors.  Then to the amount of electricity and water utilized to irrigate my lawn.  Lastly its been cams to be able to get visuals.  I did this mostly for the enjoyment of automation.  It's a subsystem running on an Arm CPU that talks to the mothership today.  Do I like the fancy graphics and remote to it today; yes.  Do I need to look at it remotely today? No; cuz I know its just working these days.
 
Having a light switch tell me how much electricity it uses as it keeps tabs in a tiny built in computer with a tiny built database would provide some more granularity.  Do I need it for the multitude of switches; not really; but it would fun to watch and would feed my automation hobby.

 

[Sparkman1]

Larry,
 
With Zwave, the only company who has products that provide that status (without polling) is Leviton. I've heard that they have a patent on that, and no one wants to pay them for the license to use it (if they allowed it). I don't know if the latter is true or not; personally I thought this would be part of the Zwave protocol and assumed that they were the only ones who invested the time to implement it... either way, the Leviton devices do report their status back if there is a state change...  UNLESS (there is always an exception right?) the device was part of an Area/Group command. When the devices receive a command to turn on as a group, they [Leviton devices] do not automatically report their status.

Cooper also has instant status (to the controller) as well.  Both Leviton and Copper have paid Lutron a license fee for this in the patent dispute.  See this article for additional info on this: http://www.cepro.com/article/lutron_sues_leviton_over_rf_lighting_controls/. There's other info available as well.  All z-wave switches that support the Association class will send instant notification to another z-wave device.  The instant status patent is only related in sending the status to a central controller.  Note, Leviton has just come out with cheaper z-wave switches that do not support instant status, so not all Leviton switches support it.
 
Cheers
Al

 

[Dean Roddey]

But of course the VRCOP is another Z-Wave device that essentially just sends out any incoming messages to the controller. How anyone got a patent for such a blindingly obvious idea I don't understand. But, if the restriction is that they just can't send the status to a central controller, well no Z-Wave device is designed to 'send a status to a central controller', it's just designed to send it to some other Z-Wave id that it has been configured for, via the Association interface. If that happens to be a VRCOP, then essentially it's going to a controller indirectly anyway.