New ELK M1 Inst Problems

[Dogman]

I have brand new Elk M1 I just installed about 2 weeks ago. Still learning all the different aspects. Am also new to home automation for the most part. Have a Z-wave issue with the serial setup using the M!XSP

I have a small Zwave network (13 nodes) using the M1XSP with a Leviton RZCOP serial interface. I have one non leviton device in the system it is an intermatic CA3500 outlet. The M1 doesn't seem to detect the correct status of some of the devices yet I can change the state of the devices fine with the keypads . It seems that it really is only a problem when I use rules to activate a group. The status does not seem to get broadcast to the RZCOP if using groups. Note: I have updated the firmware for the M1 and the M1XSP to the latest versions on the ELK website including the special version for the M1SXP for the Leviton Vizia RZCOP. However if I manually change any of the devices locally or with the Leviton primary controller almost always the M1 detects the correct status but of course this is not using groups. Is anyone else having this issue?

 

[ryannelson]

Did you get this resolved? I'm looking at installing a pretty large Z-wave system with Elk in a house I'm about to build and want to know if the status of z-wave devices is still an issue with ELK.

 

[Spanky]

The M1 gets the status feed back of controlling a single light. Many lighting systems do not send back their status if a group or scene is controlled.

 

[Dogman]

Did you get this resolved? I'm looking at installing a pretty large Z-wave system with Elk in a house I'm about to build and want to know if the status of z-wave devices is still an issue with ELK.

Well yes sort of. I ended up posting on the Elk Website the same issue. Essentially it is because I used a Group on command in the ELK rules. Group On commands do not automatically make the individual Z-wave devices report their status. The Elk M1XSP firmware for the Leviton RZCOP didn't put in a polling command so after the rule fires and changes the state of the devices in the group there is no reporting of the status. Don Lamb at Elk looked into this for me and suggested a workaround to just add a rule to just poll the devices after the group on command fired. I did that and it worked fine. Don also put it on their list for the next firmware release. Note: if you manually operate any of the Vizia RF+ devices the status works perfectly on the ELK without any polling rules it is just required if you use the ELK to send Group commands. So My issue is essentially resolved from what I can tell and whenever they release the next version of firmware for M1XSP for the Leviton RZCOP that has the Group Polling enabled I will just delete the polling rule. Below is an example of a rule that turns on Group 2:

Group 2 example:


a. WHENEVER Group2[130(I2)] IS TURNED ON BY THE M1

THEN TURN Output 20 ON FOR 20 SECS

b. WHENEVER Group1[130(I2)] IS TURNED OFF BY THE M1

THEN TURN Output 20 ON FOR 20 SECS

c. WHENEVER Output 20 STATE IS TURNED OFF

THEN SEND THE FOLLOWING TEXT:”>GR2^M^J” THROUGH PORT 1

 

[ryannelson]

Excellent - thanks for the info!!

 

[cliffs]

The Elk M1G is a event driven system and it was not designed to do polling(Spanky can clue you in
on the technical reasons). It can receive if the light is turned on or off and remember the condition
(with proper programming) either from the M1G or externally if you have the proper protocol.

Polling is not needed if you do your controlling through the M1G as it can be made to remember the
status of the switch. The switch must be able to transmit a turn on or off to the M1G for it
to remember what the status is at a particular time. Most switches are receivers only and don't
transmit anything. Some if you press the switch it will turn on the light and also transmit its
X10(or whatever) code that the switch has been turned on, then the M1G can set a flag that the
switch was turn on from the switch. This gives the switch status but does not require polling.

Cliffs

 

[Dogman]

The Elk M1G is a event driven system and it was not designed to do polling(Spanky can clue you in
on the technical reasons). It can receive if the light is turned on or off and remember the condition
(with proper programming) either from the M1G or externally if you have the proper protocol.

Polling is not needed if you do your controlling through the M1G as it can be made to remember the
status of the switch. The switch must be able to transmit a turn on or off to the M1G for it
to remember what the status is at a particular time. Most switches are receivers only and don't
transmit anything. Some if you press the switch it will turn on the light and also transmit its
X10(or whatever) code that the switch has been turned on, then the M1G can set a flag that the
switch was turn on from the switch. This gives the switch status but does not require polling.

Cliffs

Cliffs you are correct this is another way to accomplish the same thing and maybe even cleaner, but it assumes everthing worked so that is why I like the rule above which requests the status of all the individual nodes after sending the group "on" command or group "off" command. I was specifically reponding to the Levition vizia RF+ which can and does transmit status but will not do that if the initiating command was done as a group command. Maybe I shouldn't have used the term polling since it truely is not a polling i.e. every x seconds the rule above is as you correctly stated is an event driven rule that just requests the node status after the M1 has either turned the group on or off.