Premise X10 eRampDown not working?

[etc6849]

I'm able to use eRampDown to modify volume, but I can't get the same thing to work for a X10 lamp module. The software brightness value changes, but the light doesn't actually dim. Any ideas? I browsed and made sure the dimmer class was inherited by X10_Dimmer. I also made sure everything was bound properly... Is the eRamp property broken for X10_Dimmer modules?

Set objProp = sys.GetObject("sys://Schema/Device/Dimmer/Brightness")

If this.ButtonState = 3 or this.ButtonState = 2 or this.ButtonState = 1 Then
	Home.Theater.TableLamp.RampProperty objProp, eRampDown
	system.addTimer .11, "home.HR12aZoneA.ButtonWithTrigger2.ButtonState = 0",1,"VolumeDown" & this.Parent.Name
Else
	system.removeTimer "VolumeDown" & this.Parent.Name
	Home.Theater.TableLamp.RampProperty objProp, eRampStop
End If

 

[123]

... Is the eRamp property broken for X10_Dimmer modules?

The fault lies with the X10_Dimmer class and the old-style X10 devices it supports.

I tried the RampProperty method for a light that uses the X10_Enhanced_Dimmer class and it works correctly (i.e. ramps by 10% each time the method is invoked).

X10_Enhanced_Dimmer is for X10 devices that support relative changes to brightness (i.e. brighten by 2% from the current level). X10_Dimmer is for old X10 devices that only support absolute changes to brightness (i.e. brighten to 75% will cause it to brighten to 100% and then dim to 75%).

I noticed that you used a Duration of .11 for the VolumeDown timer. If you check the documentation, a Timer's duration is in seconds ... fractional values are not mentioned. I ran a simple test and confirmed the following: a Timer will run for less than one second but will not respect the supplied value. In other words, if you ask for .5 seconds you get something less than one second.

Set Debugview's Options to display the Clock Time and Show Milliseconds. Now run this code and view the results.

debugout "Start"
system.addTimer .5, "debugout 'Trigger'", 10, "TesterTimer"

The attached image shows that the actual duration is more like 0.1 seconds. For future reference, don't expect high accuracy if you use a Duration of less than one second.

 

[etc6849]

Thanks 123. This is very interesting and shows a very deep understanding of Premise far beyond what's in the help files that's for sure! I didn't realize I wasn't getting exactly .x seconds. Any better way to do what I'm trying to do though? I have an HR12A keypad, and I want the up and down buttons to send repetitive commands every x seconds, where x < 1 second.

The dimmers I use now are called IBM Home Director HD465 (I believe it is the same as the LM465). I bought a bunch of them on ebay for dirt cheap...

PS: Will the CM11a send these "enhanced commands" if I find a dimmer compatible with the enhanced X10 dimmer class (feel free to recommend one)?

 

[123]

... Any better way to do what I'm trying to do though? ... I want the up and down buttons to send repetitive commands every x seconds, where x < 1 second
.... Will the CM11a send these "enhanced commands"

As you can see from the results in my previous post, asking for a Duration of 0.5 seconds gets you 0.1 seconds. System.Timer can provide sub-second durations except they don't match the requested values. If you want sub-second precision, System.Timer can't do it but a DelayMacro can. A DelayMacro's DelayTime property accepts values in milliseconds. Search Premise Help for "Creating a Macro Sequence". Macros can be called from VBScript using this convention (from Premise Help's example):

'To play macros under a MacroFolder
sys.PlayMacros Modules.Default.Macros.MacroFolder.GetChildren()

Yes, a CM11A can send the appropriate 'enhanced commands'. Old-style X10 dimmers are limited to understanding X10 BRIGHT and DIM commands and cannot be set to a specific brightness level like 78% (i.e. the DIM command simply dims the light a 'little bit'). For more info, read the last paragraph of this post.

I have several SmartHome X10 Switchlincs that support relative dimming ... other than that, I'm not familiar with which devices do or don't.

PS
There's no need to quote the full body of a post in a new reply. Message threads with duplicated posts are unnecessarily long and tedious to read.

 

[BLH]

The HD465 was an OEM from X10 and I believe is the LM465 with the IBM name on it.

The new X10 wall switches also have a Soft Start feature and act differently than the older ones. Like now there is a preset dim.

http://kbase.x10.com/wiki/Newer_Wall_Switches_and_Preset_Dim

New LM465s Lamp Modules are also now Soft Start.

http://kbase.x10.com/wiki/SoftStart

 

[etc6849]

Thanks BLH. The X10Wiki site is much more useful than their company site! I would agree the "new" IBM stuff I got from ebay is old stock and is more than likely older than 2007, but I did get two complete kits for $15 + shipping

"Most X10 dimming wall switches manufactured in 2007 or later have SoftStart and Preset Dim features added. By default, tapping the switch will bring the switch on at full brightness. You can set the switch to come on at a dim level instead."

 

[etc6849]

123, thanks for the code example! If I understood you correctly in a different thread, all modules within Premise are ran in a common programing thread thus things such as "go to" normally available in vbscript are not available within the Premise Builder's IDE.

Does this mean if I set a delay timer for 1 minute, nothing else in Premise can run for 1 minute? This is why I chose the addtimer method was so that it would not hold up other modules. In the past, I had used poor code like this:

Do While this.ButtonState = 3 or this.ButtonState = 2
	sendCommandToCurrentSource "TunerCommand", 2, 0
	delaySeconds(.7)
Loop

Where delaySeconds looks like this:

'Takes an integer in seconds for delay
'stole this from google, that was easy
Sub delaySeconds(nSecond)
	t0 = Timer
	Do While (Timer - t0) < nSecond
		'If we cross midnight, back up one day
		If Timer < t0 Then
			t0 = t0 - 24 * 60 * 60 ' or t0 = t0 - 86400
		End If
	Loop
End Sub

Obviously, this code I wrote was before I studied some of the modules on here (including yours) that use the addtimer method. Using while loops seemed to keep other modules from firing for X seconds, so I'm working towards only using addTimer combined with proper triggering. The delay macro looks like an easier solution though, but I wanted to make sure it would not tie up the processing thread.

'To play macros under a MacroFolder
sys.PlayMacros Modules.Default.Macros.MacroFolder.GetChildren()

 

[123]

... all modules within Premise are ran in a common programing thread ...Does this mean if I set a delay timer for 1 minute, nothing else in Premise can run for 1 minute?

etc6849, you've raised a valid concern; I ran a test to see what happens.

Premise Browser is rendered by the AutomationBrowser Module. If a DelayMacro could freeze other Modules, you'd expect Premise Browser to become unresponsive. With this in mind, I ran a 25 second DelayMacro and throughout its execution I was able to use Premise Browser. Based on this result, I believe that a DelayMacro (like System.Timer) does not suspend the execution of other Modules.

You can try it for yourself with the atatched MacroTest module. Invoke the "RunTest" script macro and it will execute all macros found in the LongDelayTime folder. The folder contains three macros:

1. Script Macro "FirstMessage" prints a Start message (visible with DebugView)
2. "DelayMacro" waits for 25 seconds (25000 milliseconds)
3. Script Macro "LastMessage" prints a Finish message

You'll have 25 seconds to exercise other Modules and confirm they are not frozen while the DelayMacro is executing.

 

[etc6849]

Thanks 123! This was an interesting excercise. What I did to test your script was simply pushed buttons to trigger commands sent out of an GC-100 port.

Worked great. I see your logical thinking here: sometimes it is easy to make a quick programming test to see if something works or not.

I also ran a test by making a script using this code to call the function I mention above: delaySeconds 60. Guess what? There was a 60 second delay before the commands were sent out of the GC-100 IR port!

The moral I see to this story is never use while loops in premise unless you know for sure they will be short in duration! I think I have found every place I used the old delay function and have corrected it. I'm going to write a function that creates a macro folder with a delay function, then deletes the folder after triggering the delay macro.