Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Boiler]

If you define the new modules to be an LM14A in AHP, isn't this what you get?  As I mentioned, AHP uses the extended dim command for all dim operations, and simple 'on' and 'off' commands for 'on' and 'off'.

I just don't see why users don't want to define the new modules as LM14A in AHP ?  Well, other than looking for something to complain about.

If you define the modules as a LM14A, AHP will wait for a status response (which the new modules can't provide).  I'm not sure what, if any, complications arise from the "waiting" period.  The device status will never be updated withing AHP.

You'll have the same problem with my proposed configuration (extended code commands won't be reflected in the AHP status), but AHP will not be waiting on a status response that it will never receive.

To be honest, this is personal preference.  I'm accustomed to using simple on/off modules in the AHP interface and then programming the advanced functions within macros.  I feel I have a better handle on what is happening this way.

As far as "new users" are concerned, I think they have a right to expect their WS467 to operate properly when they select this interface from AHP.  They have every right to complain when it does not (due to undocumented changes in the unit).

Boiler

[Charles Sullivan]

Another solution is to program for the WS467 as if it were a LM14A.  This will work, but there will be no activity shown in the Activity Monitor or in the brightness level indicator in the icon.  (AHP waits for the extended status response from a LM14A, but the new WS467 is only a 1-way device.)

Are you really sure about this?   

I just tried a little experiment.  I disabled the status responses return on my LM14A modules, essentially turning them from 2-ways into 1-ways.  That should, make them just like the new lamp 1-way modules, no?

AHP seems to have no problems with doing this.

I see all the appropriate and expected activity in the Activity Monitor.  I see 'on' commands.  I see 'off' commands.  I see extended dim commands.  Of course, I see no status feedback.

The AHP icon displays just fine.  It correctly shows 'on' and correctly shows 'off'.  It correctly shows the current dim level.  Of course, it is the requested dim level, and it is not being corrected by any status update/feedback, but since it uses the direct, exact value, extended dim level command, the display is reasonably close.

Therefore, I am going to guess that new WS467 or LM465 modules will work just fine in AHP.  Just do the reasonable thing, and define them as LM14A modules.   

Walt2:
When a new WS467 is defined in AHP as a LM14A, my comment about seeing nothing in the Activity Monitor referred to a  downloaded simple On/Off Timer.   Have you tried that?

[Charles Sullivan]

• Use the AHP advanced function "extended code" to output a direct dim command (command byte x31 data byte 0 - x1F).  This will directly control the on level without the problems associated with concatenated bright/dim commands.  Again, you can define the module as a simple on/off unit (appliance module/relay switch) and still use the extended code command.  AHP doesn't care how the module is defined, it will output the extended code sequence from within the macro.  I use this setup with my Leviton switches. 
  Downside to this is that some Active couplers will not repeat extended code commands.  My leviton HCA02 appears to handle them OK.  Others??

If you define the new modules to be an LM14A in AHP, isn't this what you get?  As I mentioned, AHP uses the extended dim command for all dim operations, and simple 'on' and 'off' commands for 'on' and 'off'.

I just don't see why users don't want to define the new modules as LM14A in AHP ?  Well, other than looking for something to complain about.

And this is of course explained in the AHP instructions or help files, right?

[Walt2]

If you define the modules as a LM14A, AHP will wait for a status response (which the new modules can't provide).  I'm not sure what, if any, complications arise from the "waiting" period.  The device status will never be updated withing AHP.

AHP doesn't "wait" for a status response.  At least mine doesn't.

If a status response comes in, AHP will update its status, but it doesn't wait for it.  Remember, a status response could come in (to AHP) due to a manual operation.

[Walt2]

And this is of course explained in the AHP instructions or help files, right?

Of course not.     AHP's help files do not provide help for new modules that didn't exist back when it was written.   That doesn't make these new modules "defective".

[Charles Sullivan]

And this is of course explained in the AHP instructions or help files, right?

Of course not.     AHP's help files do not provide help for new modules that didn't exist back when it was written.   That doesn't make these new modules "defective".

Walt2:
I might agree with you if X-10 had introduced the redesigned modules with a part number which distinguished them from the old modules.  But that a module labeled "WS467" won't work when selected in AHP as a WS467 makes it a defective module.

It's still defective if X-10 revises AHP to add a new type, say "WS467_new" because the naive user won't have a clue as to whether their particular module is new or old without trying one or the other types and having AHP work or not work correctly.

In my view, the only way X-10 can make these new modules non-defective is to revise the design so that they are backwards compatible with the old modules,   or at the very least label them with a different part number - even "WS467 Rev 1" would suffice if there were a similarly labeled icon in AHP.

[Boiler]

AHP doesn't "wait" for a status response.  At least mine doesn't.

If a status response comes in, AHP will update its status, but it doesn't wait for it.  Remember, a status response could come in (to AHP) due to a manual operation.

Walt2,

I stand corrected.  I just tried using the LM14a interface with my Leviton units (receive only).  The interface works well and does not request or wait for status from the switch (as I had previously thought).

At the same time, Charles is absolutely correct about the timer activity (I tried this as well).  A simple timed command will function, but there is no entry in Activity Monitor and therefor no way of tracking the status of the module.  The only way that I can see to perform tracking is to construct a "timed macro" and track the module status with flags.

Boiler