...What was X10 thinking?So X10 put thought into it? ;)
Maybe a few macro examples with notations as to how each of the two switch versions would respond would help some of us clear our heads.
By far the best solution is to return the new WS467 modules to X-10 as defective. Several users have reported receiving replacement WS467 modules which work in exchange, but it's not yet clear whether they've been sent even newer WS467 with the design flaw corrected or just some old modules from the warehouse.
By far the best solution is to return the new WS467 modules to X-10 as defective. Several users have reported receiving replacement WS467 modules which work in exchange, but it's not yet clear whether they've been sent even newer WS467 with the design flaw corrected or just some old modules from the warehouse.
Aren't you then sending a very wrong message to X10, that X10 should never, ever, try to improve any of their products? Not only modules like the WS467, but also AHP? ? ? ? That "die hard" users don't like change, and will not tolerate changes.
...The intended message is that X-10 needs to get its act together. You can hardly call the redesigned WS467 an improvement when it won't work with their flagship ActiveHome Pro product.Any one want to bet on which they do first, fix the module or patch AHP to work with it?
...The major problem is with the new WS467. The apparent design flaw is that it cannot be brightened from the Off state using standard X10 Bright or Dim signals. Downloaded Timers first brighten to 100%, then dim to the specified absolute brightness level. As a result, downloaded Timers won't work with the new WS467 if the module happens to be in the Off state when the Timer executes.So if I understand it correctly, for a macro that sets say 60% brightness I now have to add an ON command before my absolute dim?
Macros by default operate the same way, however one can select Tools > Preferences > Macro options and click the box to "Use On instead of brighten 100%". Then prefix a separate On step to the macro and it should work with both new and original WS467 modules. So one workaround for the Timer problem is to reprogram simple Timers as an On Macro and an Off Macro, and use the Timer to execute the Macros....
...The major problem is with the new WS467. The apparent design flaw is that it cannot be brightened from the Off state using standard X10 Bright or Dim signals. Downloaded Timers first brighten to 100%, then dim to the specified absolute brightness level. As a result, downloaded Timers won't work with the new WS467 if the module happens to be in the Off state when the Timer executes.So if I understand it correctly, for a macro that sets say 60% brightness I now have to add an ON command before my absolute dim?
Macros by default operate the same way, however one can select Tools > Preferences > Macro options and click the box to "Use On instead of brighten 100%". Then prefix a separate On step to the macro and it should work with both new and original WS467 modules. So one workaround for the Timer problem is to reprogram simple Timers as an On Macro and an Off Macro, and use the Timer to execute the Macros....
BTW.. I never really had a clear idea of what the purpose / effect of checking the "Use On instead of brighten 100%" option. What effect does it have with the old switches?
If it is checked, does it mean AHP sends an ON command if I program a 100% bright?
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.)
- 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.
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. ;)
- 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.
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.
And this is of course explained in the AHP instructions or help files, right?
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".
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.