Elk M1 and Zwave Sensors

[drvnbysound]

(I have not yet found a configuration that does all device). 

 
I am 99% sure the <Poll^M command does this (via the M1XSLZW). It's listed on page 12 of the M1XSLZW manual; I don't use it, but during testing I found that it would return the status of all devices on my network.
 
My issue with using it is that it also polls my battery powered Zwave lock(s), which obviously reduces battery life. So I got away from polling, and started switching to devices that supported Instant Status (e.g. most Leviton products, and the locks) so I no longer need to poll anything and Elk always maintains the correct device status.

 

[crossbar]

That command does seem to work with some device but not all (specifically the dimmer devices).  That command also takes a very long time to update (33 seconds for just the 3 devices I have that update).  The numerated command only takes about 5 seconds to update.
 
So it turns out that this is all a function of Lutron being a real _____.
It's too bad the patent office enables greedy companies like Lutron to steal money and capabilities from customers by awarding patents for obvious features.  And then Lutron actually takes advantage of this and charges royalties to use these obvious features.
I will do my best to avoid Lutron and any companies licensing this patent.  (I am referring to the Z-Wave instant status-reporting capability).  How can they possibly have a patent on this when X10 supported this feature decades ago?

 

[drvnbysound]

I don't understand how they have the patent on it when it's obviously part of the Zwave protocol... but I know nothing about IP.

 

[RAL]

I used to do a lot of work with patents, and I have obtained a few over the years.  This got the best of my curiosity and I looked up the Lutron patents and Lutron's lawsuits over them. 
 
The patent isn't simply about collecting status.
 
Lutron developed a method for obtaining remote device status in a wireless RF environment as part of their RadioRA products, and that's what the patents cover.  It's wireless and RF that are key here.  Although Lutron designed it for RadioRA, the patent is broad enough to cover other RF protocols, including Z-Wave.  So although the creators of the Z-Wave protocol wrote it to have a method to collect status, it then is up to the Z-Wave product designers to find a way to do that without violating Lutron's existing patents, or pay royalties if they can't figure out another way.
 
Intellectual Property law can be a minefield. Sometimes, there is only one practical way to do things.  If you are the guy who does it first and gets a patent, you can make some money (sometimes a lot of money) on it.  If you don't own the patent, well, then you have to pay royalties.

 

[drvnbysound]

Ah, it makes a lot of sense now!!!

 

[crossbar]

Still how can you patent 1) something that is obvious "to a person having ordinary skill in the art to which the claimed invention pertains." (in this case I would think this is obvious to anyone really).  2) something that has been done with a wired protocol for decades (X10 etc)?
 
I understand the need for IP but this is really going too far.

 

[RAL]

The Lutron patent isn't for the simple act of just obtaining status, but for a specific method of how to do it in a wireless environment.  That is probably enough to make it different from whatever X10 did for control and status over the power line environment.  The Lutron patent does mention X10 as "prior art" and also describes it as a 1-way system. I don't recall when the first X10 two way devices first appeared, but it's possible that Lutron's invention actually pre-dates X10's two way capability.  That patent was filed in 1996, which means that it will expire next year.   But that doesn't mean other manufacturers will be completely off the hook, since Lutron may have other patents as well.
 
Patent law can be strange when it comes to the concept of "obvious."  Often, simply the fact that no one ever thought of a particular way of doing something previously is enough to prove that the invention was not obvious. Otherwise someone would have done it already!

 

[ddennerline]

I agree with RAL. I read the http://www.google.com/patents/US5905442 about a year ago because I too thought, "How could instant feedback be patentable?"  At the time of Lutron’s RadioRA’s  invention, the idea was non-obvious – especially pertaining to slow RF networks. Lutron wasn’t greedy.
 
Luckily it will expire in soon. I don’t know how existing licensee’s will be impacted. Hopefully this will cause prices for Vizia+ to drop by 20% or so.

 

[ddennerline]

I don't use the POLL command either. I do have it programmed to a keypad, so I can initiate a "rebuild network" without having to reboot M1G.
 
As a side bar, Z-Wave polling causes network congestion. On a “modem speed network” (remember modems), the RTT times are exceeding high. If you have enough devices, then you will not be able to poll devices fast enough to get an accurate picture of network.  Basically, slow networks and polling are incompatible. This is why very first operating systems (MSDOS) were designed around interrupt processing I/O instead of polling.
 
Even though GE/Linear Z-Wave switches are cheaper, they don't represent a good value IMHO. There are work arounds like the HAIL command, but this is sort of kludge.

 

[ddennerline]

In regards to the update command, you don't need to send this command. As soon as Elk sends a lighting request, the switch sends back an asynchronous notification back to the "associated controller." Each switch supports up to four associated controllers. While you had the VRC0P+3 on Hyperterminal, you can press switches and see status updates. You can actually send VRC0P+3 commands to M1XSZW serial port, but there's little incentive for doing this because M1XSZW already sends all these commands.

 

[ddennerline]

Also, the current Z-Wave M1XSZW solution is way better than the old version. If you can get everything enrolled and working with RFIT, then the install is pretty run-its-self. I just turned off all the lights in my house/garage in 1 second (there were quite few on). Also, the command locked all my doors too. 
 
If you stay with Elk M1SXZW, you will still need to use VRC0P+3 and Hyper-terminal to setup Areas/Zones/Groups because RFIT over-the-air synchronization relating to this element is broken for VRC0P+3. The VRC0P+3 virtual buttons do not synchronize correctly. I have been trying to get Leviton to fix this for more than one year.

 

[crossbar]

 As soon as Elk sends a lighting request, the switch sends back an asynchronous notification back to the "associated controller."

What is a lighting request?  How do yo get Elk to initiate a lighting request?
 
The associations are only for devices that support the association class and they should asynchronously send their status back so no need for any lighting request.  But devices that don't support association class need to be queried.  Elk does not seem to directly support queries or polling. It sounds like devices that don't support the association class will still send an "I've changed state" message will the VRC0P receive these messages and is there any way for the Elk to respond to this message with a polling command?  Sounds like this is how the other Z-way controllers get around the association issue.
 
Update:  So it does appear that the primary controller does see traffic when a non-associated device changes state but there is no output from the VRC0P.  Does anyone know if this is due to the implementation of the VRC0P or because it is a secondary controller?

 

[ddennerline]

When you use RFIT and the Diagnostics > RS-232 menu, the VRC0P+3 can be associated with any Vizia+ switch/plug/lock. The VRC0P+3 is a secondary controller (technically a Secondary Update Controller). The M1 Z-Wave will not send any response once a notification is received. Some controllers work around the Lutron patent by using the HAIL command. This command is not necessary for Vizia+ devices.
 
The M1XSZW does poll thermostats which do not support association class. It does not poll any other devices unless you send a ">POLL" command to specific serial port number. This will cause a query of all Z-Wave nodes.

 

[crossbar]

The M1XSZW does poll thermostats which do not support association class.

From what I read the M1XSLZW only needs to poll certain thermostats.  This agrees with the M1XSLZW manual that gives the commands to start and stop thermostat polling (indicated as a non-standard implementation).  Do you happen to have or know which z-wave thermostats do NOT need the polling function?

 

[drvnbysound]

I have the RCS TZ45 and it does not need to be polled. Having said that, I don't know of a published list for others...