Print

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

[Walt2]

I just noticed something strange, that seems to be the cause of some of my problems.

I have multiple 2-way modules set to the same house/unit codes.  Because of this, I found that I need to disable the status return on them to prevent the onslaught of status response commands every time I send them a command.  All these status responses create a lot of power line traffic causing unnecessary command collisions.

OK, the fix is simple.  I send out an Extended Configuration command to them, of 3B'x + 00'x.    This disables all the status response commands from the 2-ways.

However, I just noticed that when I open a file in AHP, it automatically sends out an Extended Configuration command to all defined 2-way modules of 3B'x + 03'x.  Just have the Activity Monitor open when you load a file, and you will see them.

This re-enables all my 2-ways' status returns!!   

I've trying to figure out why the disable status returns for my 2-ways doesn't "stick".  That the disable seems to work for a while, and "suddenly" the 2-ways start returning status again.

Is there some way to stop this?   

[Walt2]

Just to explain a bit more of the "why"....

For an example, an "F-3" and "F-On" command is sent, by coincidence, shortly after a 2-way was sent a command.  The status returns by the 2-ways clobber the "F-3".  So, the "F-On" doesn't get executed by "F-3", but instead gets executed by what ever module that was last addressed on the F house code. That could have been, and typically is, a module that was addressed hours ago.

My problem is that this happens quite regularly (once or twice a week), and I find a light (or something) 'on' that is not suppose to be 'on'.

[Boiler]

I just noticed something strange, that seems to be the cause of some of my problems.

I have multiple 2-way modules set to the same house/unit codes.  Because of this, I found that I need to disable the status return on them to prevent the onslaught of status response commands every time I send them a command.  All these status responses create a lot of power line traffic causing unnecessary command collisions.

What type of modules are you using?  I have PR511's (two on a channel) and I don't receive a status request unless I specifically poll the device.

I tried loading a file with activity monitor open - nothing transmitted.

I've trying to figure out why the disable status returns for my 2-ways doesn't "stick".  That the disable seems to work for a while, and "suddenly" the 2-ways start returning status again.

Is there some way to stop this?   

A periodic timer to send out the disable command?  A bit ugly, but it should work.

[Walt2]

What type of modules are you using?  I have PR511's (two on a channel) and I don't receive a status request unless I specifically poll the device.

I tried loading a file with activity monitor open - nothing transmitted.

They are the lamp LM14A's.  AHP/CM15A is sending them configuration command settings that enable "maximum" status responses, including a confirmation status response upon the receipt of any command.

I just installed AHP on my notebook.  However, the .AHX files on still on my main PC.  So, when I start/open AHP on my notebook, I then have to manually open the AHX file, thru my network, from my main PC.   This is why AHP isn't starting with the last AHX file automatically loaded, which is the usual way it works.

Anyway, that is why I just started to see this.  It is very repeatable.

A periodic timer to send out the disable command?  A bit ugly, but it should work.

I was having the LM14A's configured once per week.  That was enough, until I started using my notebook.  Now that I discovered this "oddity", and with the lack of anyway to stop it, it seems that I have to manually run the timer/macro each time I open up AHP on my notebook.

BTW, while this doesn't affect my LM14A's, these configuration commands from AHP/CM15A also have the ramp rate bits reset back to factory defaults.  If anyone has Leviton or other brand of modules that support different ramp rates, and are wondering why the ramp rates keep resetting back, this could be why.

[Boiler]

They are the lamp LM14A's.  AHP/CM15A is sending them configuration command settings that enable "maximum" status responses, including a confirmation status response upon the receipt of any command.

That's just plain nasty.  Is this the X10 "status on command" (binary 11011) or something different?  I just tried the "status on" command using the SDK and I don't see any change from my PR511's. 

I just installed AHP on my notebook.  However, the .AHX files on still on my main PC.  So, when I start/open AHP on my notebook, I then have to manually open the AHX file, thru my network, from my main PC.   This is why AHP isn't starting with the last AHX file automatically loaded, which is the usual way it works.

Anyway, that is why I just started to see this.  It is very repeatable.

I've done the same exact thing using my wife's notebook upstairs (she wasn't happy that I was invading her PC space).  I have not seen this. 

Something peculiar to the LM14a?  A problem with the AHP notebook installation?

[Walt2]

That's just plain nasty.  Is this the X10 "status on command" (binary 11011) or something different? 

The command sent out is 3B'x 03'x.   

Something peculiar to the LM14a?  A problem with the AHP notebook installation?

My guess is that X10 had problems with users complaining about AHP's reporting of status of LM14A's wasn't working correctly.  X10 determined that the cause was that the 2-way modules like the LM14A had their status return function disabled.  So, to "help" users of AHP, X10 has it automatically, always, send out a command to these 2-ways to ensure their status return function is enabled.

The only difference, I can tell, is that my notebook doesn't have any .AHX files locally.  So, there are no files to automatically load at startup.  I always have to load one (open file ...) manually.  And with that, I have an opportunity to actually have the Activity Monitor running first.

The reason I installed AHP onto my notebook, was to help debug a problem.  As it turned out, it was causing a new problem, and offered few hints for my original problem.

Regardless, I do appreciate your interest...   

[Boiler]

The command sent out is 3B'x 03'x.   

Sorry but my PR511's don't appear to respond to the "configure modules" command (finally found the auto acknowledge command in the X10 reference).  The SDK sends to command out OK.  The PR511's do not transmit anything back when I send an on or off.

I'm guessing this is something specific between AHP and the LM14a.

Could you change module types to keep AHP from sending the auto acknowledge commands?