Leviton VRCOP/M1XSP Elk Lighting Rule “FOR†Not Working

ddennerline

Active Member
I just installed the six Leviton LEV-VRI06 Vizia+ Dimmers. Everything except this feature seems to be working correctly.

I have spent the better part of 5 hours trying to work through why the “FOR†clause is not causing my lights to turn OFF after specified amount of time elapses. I have basically boiled the test case down to this rule only. There are no other zones or lighting rules configured. Tonight I un-enrolled all my expansion modules except the main keyboard and VRCOP<->M1XSP. I am getting pretty frustrated because I want certain lights to turn off automatically after set amount of time has elapsed.
WHENEVER F6 KEY ON ANY KEYPAD ACTIVATES
THEN TURN Light [28(B12)] ON, FADE RATE=0 FOR 1 MIN
THEN ANNOUNCE Light [28(B12)]​
The M1XSP details are Hardware Ver=.3, Bootware Ver=1.0.1, Firmware Ver=20.0.4, Additional Information=Firmware supports Leviton Z-Wave.
I have checked the internal clock, and it’s correct. I have the lighting selection set to "Serial Expander*".

I have created all sorts of different variations of the rule above using different triggers. I can create separate rules that turn on and off light at specified times. Bi-directional communication between ElkRM and keypads work correctly.

Has anyone ever experienced a similar problem with Z-Wave or any other lighting technology?

I know I can possibly work around this problem by emulating a timeout using a virtual output and counter. I want to know if there’s something wrong with my ElkM1G.

Does anybody know of way to determine if the ElkM1G is sending LIGHT OFF command to VRCOP? What would be the best way to figure out what’s going on –short of purchasing a RS-232 line analyzer?
 
I just installed the six Leviton LEV-VRI06 Vizia+ Dimmers. Everything except this feature seems to be working correctly.

I have spent the better part of 5 hours trying to work through why the “FOR†clause is not causing my lights to turn OFF after specified amount of time elapses. I have basically boiled the test case down to this rule only. There are no other zones or lighting rules configured. Tonight I un-enrolled all my expansion modules except the main keyboard and VRCOP<->M1XSP. I am getting pretty frustrated because I want certain lights to turn off automatically after set amount of time has elapsed.
WHENEVER F6 KEY ON ANY KEYPAD ACTIVATES
THEN TURN Light [28(B12)] ON, FADE RATE=0 FOR 1 MIN
THEN ANNOUNCE Light [28(B12)]​
The M1XSP details are Hardware Ver=.3, Bootware Ver=1.0.1, Firmware Ver=20.0.4, Additional Information=Firmware supports Leviton Z-Wave.
I have checked the internal clock, and it’s correct. I have the lighting selection set to "Serial Expander*".

I have created all sorts of different variations of the rule above using different triggers. I can create separate rules that turn on and off light at specified times. Bi-directional communication between ElkRM and keypads work correctly.

Has anyone ever experienced a similar problem with Z-Wave or any other lighting technology?

I know I can possibly work around this problem by emulating a timeout using a virtual output and counter. I want to know if there’s something wrong with my ElkM1G.

Does anybody know of way to determine if the ElkM1G is sending LIGHT OFF command to VRCOP? What would be the best way to figure out what’s going on –short of purchasing a RS-232 line analyzer?


I had a similar issue with Insteon. The "on for" rules never worked when polling was enabled on the XSP. When I disabled polling (via jumper) on the XSP "on for" started working. No idea how those two issues could be related but it worked for me. Polling with the XSP and Insteon was barely usable anyway.
 
The Elk M1G is a interrupt driven system. If any polling is enabled then commands will
be missed when the system polls. You can write around most any case without having
to use polling. Basically there is a list of events to be serviced when a interrupt occurs, either by
time of date or triggered by a timer or event. These events are programed with the
software. Some are internal such as zone activities, other by external events.

The interrupt system is far more responsive when many events a triggered than a
polling system, this is why the M1G was programmed to use a interrupt system.

I hope this explains why you had a problem with the dimmers.


Cliffs
 
There are some setup programming in the VRCOP that you have to do to get two way operational. I do not have the details right now but they are available from Elk. Check on the elkproducts.com website perhaps in the M1XSP manual.
 
Can you please be more specific?

I followed all the directions in the Elk VRCOP installation instructions dated 10/27/2008, firmware version 20.0.4. Jumper S8 is the only jumper (request node status) that can be configured. Setting Jumper S8=0 will result in a request node status being sent whenever a "Hail" command on the ZWave network is detected. I left this jumper in the off position – even though there's no recommendation.

Elk M1XSP/Vizia+ bi-directional communication seems to be working correctly. If I use either ElkRemote or Keypad, the status is correctly shown when manually switching light/load.

I did notice there was a similar problem reported in Insteon driver that was corrected in firmware 50.1.4, 1/20/2009.
Found and resolved an issue when using a rule to turn on a light for a timed period using the Insteon PowerLinc
MODEM (PLM) #2412S. The timer associated with the light would be erased, resulting in the light never turning off
.​
I was just wondering if anyone else has a PIR driven rule and is using Elk M1XSP/Leviton Vizia+ module.

As a side note, the rule below is not working either. I believe this should work because Vizia+ is two-way. The keypad will not beep if I toggle this switch. This problem is may be a different issue that I should create seperate thread posting :horse:
WHENEVER OutsideLights [22 (B6)] IS TURNED ON
THEN START KEYPAD BEEPS in Home (Area 1)​
 
I have found that the "For x minutes" does not work most of the time for me also. I have had to resort to using CQC with timers for that. Mine are driven via PIR commands. The PIR senses movement, light comes on, supposed to turn off after 10 minutes - doesn't happen.

George M
 
Back
Top