Elk M1 and Zwave Sensors

drvnbysound said:
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...
How well does the RCS TZ45 inter-operate with the ELK?  If you don't need to poll the thermostat for temperature do you know how often the thermostat sends updates?  Is it periodic or is it just when the reading changes?
Also can the ELK read back the current target temperature settings or the current state of the system (i.e. Heat, cool, auto, fan state)?  Does the RCS TZ45 send this status information to the VRC0P by setting an Association to the VRC0P or by some other method?
 
I'm trying to find a good Z-Wave Thermostat to use with my Elk M1.   My main hesitation with the RCS TZ45 is that RCS will not honor their warranty unless bought and installed by licensed HVAC.
 
Also can you tell me if the RCS TZ45 will mount to a standard electrical box (i.e. has hole pattern that matches).
 
Honestly, I have no idea.
 
I use the eKeypad app and the temp is always properly reflected there when I choose to view it... and I don't do any polling. How often it's updated... no idea.
 
I thought I was going to do more with the tstat, but about the time I got it installed, my wife quit working to stay home with our son. Since they are home most every day I haven't implemented any automation of it to date.
 
Re: the electrical box: also not sure. I replaced my existing Honeywell tstat which was screwed directly into the drywall. I choose to do the same.
 
I bought my TZ45 used here on the forum ;) without hesitation of warranty.
 
Sorry I couldn't be of more help!
 
drvnbysound said:
I use the eKeypad app and the temp is always properly reflected there when I choose to view it... and I don't do any polling. How often it's updated... no idea.
Does the Elk system update other functions of the thermostat (mode, set points, fan).  I.E. if you manually turn on the Fan at the thermostat does Elk know that the Fan is now on?
 
My CT100 is sending this information to the VRC0P (I verified the serial output) but the M1XSLZW or the Elk do not seem to be reading these messages into the Elk.  Others have said the Elk can read the wired thermostats status but I have not found anyone discussing this about the Z-wave Devices.
 
crossbar said:
Does the Elk system update other function of the thermostat (mode, set points, fan).  I.E. if you manually turn on the Fan at the thermostat does Elk know that the Fan is now on?
 
My CT100 is sending this information to the VRC0P (I verified the serial output) but the M1XSLZW or the Elk do not seem to be reading these messages into the Elk.  Others have said the Elk can read the wired thermostats status but I have not found anyone discussing this about the Z-wave Devices.
 
Here's what I see via eKeypad:
 
index.php
 
My CT100 Thermostat is working as expected using ELK-M1XSLZW and VRC0P+3.  My CT100 shows in the network as a General Thermostat V2 so I don't know if it is a newer version or not.  But this CT100 does support association and once the association is set to the node ID of the VRC0P+3 the ELK system will get updates from the CT100 for Temperature, Fan Status, Mode, and Set points (low and high).  If you change any of these setting on the CT100 they will update to the ELK in a few seconds.  You don't need to use the <TPOLL if you set the association (I did not test the <TPOLL method).  Also to get the association to take I had to enter a 1 in the group setting and then the node ID of the VRC0P+3 (using the Zwaver app).  Note the ELK will NOT read the humidity reading form the CT100. :(

Here is a summary of how the Elk implements Z-Wave Thermostats.:

The Thermostat must be added to the network using the primary controller.  This network configuration must then be Replicated to the secondary controller (this usually happens automatically when a secondary controller is added - if the controller is already added a Replication must be initiated after the thermostat is added).

The Elk on power up will query the VRC0P+3 to find the thermostat node ID(s) (>?FI0,8).  Note this command will return a F000 if no thermostats are configured in the VRC0P+3 and the ELK does not check for a Zero response and merrily takes the Zero node ID and assigns it to Thermostat 1.  This can cause an issue where the ELK can still control the Thermostat (because it then issues controls to node ID Zero which is a global command) but will not update any status from the Thermostat since the status will come back form the correct node ID but the ELK will be looking for status from node Zero.

Next you must manually enter a Thermostat name into the ELKRP (Note: the Elk will not show any of the Thermostats it found at startup there is no way to know what the Elk found or didn't find or what the IDs are.  You just have to enter them in manually and see if they work).

I will update on how reliable the CT100 and the ELK are after I have run the system for a while.
 
That's good news you were able to get a CT-100 (v2?) working with M1XSLZW.
 
What is the Z-Waver App?
 
Did you use Leviton RF Installer Toolkit as the master controller?
 
If you didn't have to add a "TPOLL" command to ElkRP, then thermostat supports association class.
 
Elk doesn't read the my OmniPro2's humidity either (Humidity is an often asked for Elk feature).
 
Yes good that CT100 is working with the the M1XSLZW but it seems to be unreliable.  Commands sent to the thermostat sometimes do not update the thermostat.  As is posted in other threads others seem to have the same problem with wired thermostats as well.  So I wonder if the ELK just sometimes doesn't send the commands (this would not surprise me as I have seen this with other things like sending a Z-wave dim command with a value of 1 to 4 the elk just does not send the command at all period - I can send the manual text string to the VRC0P and that works fine but the Elk just won't do it).   At some point I will try to look into this further by looking at the actual serial output from the M1XSLZW.
 
The CT100 definitely supports the association command it reports it as a supported class and you can set it and read back the settings.  The thermostat will not send any status updates unless the association is set.
 
Yes currently I have set up the Z-wave network using a Z-Stick as the master and the Zwaver app for further configurations.  You can set associations and other parameters with either the Zwaver App or by sending raw messages to the VRC0P.  For example you can set association for node 3 to node 10 by sending >N3SE133,1,1,10 to the VRC0P.  You can even do this from the ELK with a text string just add CR (^M) to the end.
 
The most recent unsupported issues I am having currently are with these new devices that have two endpoints like the dual relay module Enerwave ZWN-RSM2.
And the RGBW bulbs that have multiple channels to control.  The VRC0P does not support these devices directly. I called, chatted, and emailed Leviton support but they had no clue.  They are supposed to get back to me.  You should be able to send the "raw" Z-wave commands as strings similar to the association command above but I don't know the parameters required for those command classes.
 
The Elk is just too old, cumbersome, and unreliable for any actual real life automation (as others have noted as well) so I think I will just use it to turn on and off simple things and use an external automation controller for the actual daily automation.  Something that can control new devices and can take input from Z-wave sensors like Humidity, or dusk sensors, etc.  I may get something that supports ZigBee as well since that seems to be a more robust (and open) protocol.
 
crossbar said:
The Elk is just too old, cumbersome, and unreliable for any actual real life automation (as others have noted as well) so I think I will just use it to turn on and off simple things and use an external automation controller for the actual daily automation.  Something that can control new devices and can take input from Z-wave sensors like Humidity, or dusk sensors, etc.  I may get something that supports ZigBee as well since that seems to be a more robust (and open) protocol.
 
I find that very amusing!
 
Many ions ago I tried to get a CT-100 integrated and gave up; it wasn’t Elk fault either.  Not trying to be a kill-pill, but the “Z-Waver” app may not be configuring the thermostat the way that Elk expects the device to be setup. Elk testing and documentation only shows Leviton RF Installer Toolkit.
 
If Elk is sending the correct change temperature command to CT-100, then it’s not M1XSLZW‘s fault the command is not being reliably processed. I do agree that Z-Wave network can be unreliable. Since you have been playing with serial API, you can see that when a large number of commands are simultaneously sent, the responses are different.
 
Unfortunately, The M1XSLZW only supports a very select number of devices that are listed in the documentation. If you want to build a whole system around Z-Wave and use a wide variety of devices, I think a dedicated Z-Wave controller will provide a better experience. 
 
I checked the Serial communications between the M1XSLZW and the VRC0P.  The issues are on the Elk side.  The M1XSLZW will sometimes just not send the commands (my initial testing was using the M1 to Go.  I will do further testing to see if the rules have the same issue of just not sending commands sometimes - but that would explain mine and other's observations).  The second issue is the Elk not processing the responses from the VRC0P.  The VRC0P will send a command confirmation of <X000 if a command was received by the target device and a <X001 if the command failed.  The Elk ignores these messages so there is no way to know if a command was not received by the target device.
 
If you have hard debugging evidence of an issue, then Elk, in my experience, may be open to small fixes (or maybe not?).  If you can collect all your Comms/ASCII traces between M1 and VRC0P+3, then it will be easier for Elk technical support to identify the problem. You may get some pushback if you haven’t use RF Installer Toolkit as the primary controller.
 
I would have thought at least if command failed, the M1SXLZW would at least resend the command.
 
What hardware/software did you use for RS-232 tap?
 
As a side issue, if commands are randomly failing, it may indicate that you need more Z-Wave devices or a better routing table.
 
I just used a serial spy cable I had from a long time ago (back when everything was RS-232).
So that is one the things the M1SXLZW does not look at the replay code from the VRC0P so commands are not resent because it does not check to see if the command was received or not.  As someone pointed out in another thread keeping track of the response codes may just be too much resource wise for the Elk.  I would tend to not to agree with that unless it is an actual code space limitation.  I would assume it was just the simplest implementation.
 
Under normal situations you should have very little communications issues and command should not need to be resent when a command does fail you need to know it failed.  So for I don't see that as an issue with my network commands that are actually send are, as far as I can tell, always received.
 
Back
Top