M1 Virtual Keypad - Leviton Dimming

[briankelly63]

I am using the M1XEP's built in web application - virtual keyboard. I cannot DIM Leviton HCM06-1DW's (PLC) using the slider in the web application. The switches are configured as extended / dimmer in the M1G. Interestingly, Dim commands to these switches using rules work just fine but when using the virtual keyboard application they do not. Is this a bug or a limitation of the free, built in virtual keyboard application? Seems like a bug... I have some older Switchlincs on the same installation and the slider for dimming works fine on them... PLC commands are being sent as a result of moving the slider but apparently not the correct extended control commands.

Thoughts?

brian

 

[briankelly63]

I am using the M1XEP's built in web application - virtual keyboard. I cannot DIM Leviton HCM06-1DW's (PLC) using the slider in the web application. The switches are configured as extended / dimmer in the M1G. Interestingly, Dim commands to these switches using rules work just fine but when using the virtual keyboard application they do not. Is this a bug or a limitation of the free, built in virtual keyboard application? Seems like a bug... I have some older Switchlincs on the same installation and the slider for dimming works fine on them... PLC commands are being sent as a result of moving the slider but apparently not the correct extended control commands.

Thoughts?

Brian

...

 

[Spanky]

ELKRM, ELKRMS, and the java webpage uses preset dim settings on X-10 devices. If the switches require the DIM or BRIGHT commands, they are not sent from the touchscreens or webpage. You can send them from Rules. Use a button on the screen and generate the dims or brights from rules.

 

[briankelly63]

I hate to sound like I'm complaining but I don't see the logic of this arrangement. Why would the M1G allow the configuration of different devices ie: standard, Preset Dim, Extended Compose etc. if the remote virtual keyboard client and RM only asks the M1 to send to Preset Dim commands despite the configuration. Is there a reason you can't correct this or is there a reason you chose to have it function this way?

Thank You

brian

 

[briankelly63]

No comment yet...?

 

[briankelly63]

Still no follow-up...

 

[icellama21]

Have you looked into other software packages to control your lighting? There are a number of options ranging from free(like Premise) to custom-config cadillacs(CQC, pro-systems). Maybe you can run one of these programs side by side with ELKRMS?

Another potential option is to write a script and have it run on your PC or CE machine. Whenever it senses a preset-dim command sent by ELKRMS, send an ASCII command to the M1 to send the appropriate dimming commands for your device. It will take a bit of tinkering to break into the RMS data stream, but after that it is pretty easy if you are using the non-secure port.

 

[briankelly63]

All valid suggestions but I'd like ELK to address why this incongruity exists within their own product space.... You can set a Device Format (like Extended)within the lighting configuration of the M1 via ElkRP but within ElkRM it ignores that Device Format and only uses preset dims. Rather than going silent on this I'd rather hear why / when Elk can or cannot address this. I find it annoying when someone gives an explanation within a professional community that implies that its normal for something not to work as it should. If its a design choice / bug / problem / oversight then address it. If it works within rules it should be working within the M1's other components, in this case ELKRM.

If we could only read Centigrade temperatures within ElkRM vs. Fahrenheit in Rules I doubt we'd see the logic of that either.

ELKRM, ELKRMS, and the java webpage uses preset dim settings on X-10 devices If the switches require the DIM or BRIGHT commands, they are not sent from the touchscreens or webpage. (Spanky Quote)

 

[Spanky]

Dim commands in the old standard X10 switches are a fairly complex operation. Turn the light off, turn the light on full brightness, issue the number of dims desired to get to the proper dim level. You can do this operation with Rules in the M1 from a touchscreen command.

Why was the old Dim/Bright commands not implemented in the ELKRM software? It is a complex operation with no feed back as to how dim the light actually is. The Dim/Bright commands are a trial and error function according to the incandescent light bulb wattage rating. If you placed the dim indicator at 50%, the light may be somewhere between 20 to 80%. Implementing that function would create more problems than the benefits of the feature.

If you want to implement Dims:
Write a Task Rule with:
Turn off the light
Turn on the light
Issue the number of Dims

From ELKRM activate the Task.

There is no dim level feedback on X-10 devices.

Have a charming day!

 

[briankelly63]

I think we are talking apples and oranges... I agree with your comments on the old, pure X10 commands regarding dim, brighten etc they were all relative to where you happened to be in the range. I understand how that wouldn't work wit the slider in ElkRM.

I'm talking about extended commands used in the Leviton HCM06-1DW that do not require the sequence you mentioned. The M1G is using the extended commands when called upon within the rules and will directly set a percentage brightness. For example when using rules you can go directly from say 25% brightness to 75% without a series of dim's as long as the device is set up as an extended (format) Dimmer (Type) within Lighting under ElkRP. So its curious the ElkRm doesn't work the same way. The extended command set which you have implemented yields the same result as the Preset Dim you've discussed, its absolute.