[SOLVED] Is This A Bug With Dimming?

[alzee]

X10 Commander when using Amazon Echo or the PC gui to dim appears to dim the last light turned on instead of the light selected. can this be fixed so it dims the item selected?

thanks

[alzee]

Melloware what do you think?

[Melloware]

Melloware what do you think?

Check the logs. It should not it should always be sending the HOUSE CODE of the item you are trying to DIM to the X10 SDK. The logs should verify that.

[alzee]

Log says its dimming the device selected but it dims the last device turned on. The log is wrong?

[Melloware]

Log says its dimming the device selected but it dims the last device turned on. The log is wrong?

No whatever the log says is exactly what I am sending to the X10 API. If you send me house code B10 I am handing B10 to the ActiveHome SDK. If it is dimming the wrong module are you sure you dont have the wrong house code mapped or two devices accidentally mapped to the same house code?

[alzee]

I guess the question is does the log display the request or the actual command sent. If it is the request then it could be in error. BTW doesn't matter whether I use the CM19a, cm17a or cm11a.

[alzee]

No all have unigue house/unit codes. And it happens the same way regardless of lights used.

[alzee]

I have AHP on another PC with CM15a. When I check its activity monitor it shows the X10 Commander activity. it logs the dim commands but only lists the house code not the unit code for the dim. Could x10 Commander not be sending the unit number so the system defaults to the last device turned on??

[alzee]

Looks like a bug in X10 commander. Its log says it is sending out a dim command to one device ( the one selected) but the command actually sent is for the last light turned on.

[Melloware]

Looks like a bug in X10 commander. Its log says it is sending out a dim command to one device ( the one selected) but the command actually sent is for the last light turned on.

Its not. This software has been running for almost 10 years and you will find hundreds of people posting here that it works. Here is a CM19 user that has dimming working correctly.

Here is a post from 9 years ago from a CM19 user that has it working.

http://forum.melloware.com/viewtopic.php?f=13&t=6476

It is also concerning that you are saying you are only seeing the house code in the logs like "B". That would explain why X10 API is dimming the last known module on that house code? Also please post the X10 COmmander log when you dim so I can see for myself that I am sending the proper data to the X10 SDK.

[alzee]

I agree! I tried ahcmd.exe and still get the same funky dimming issue! But i have no idea what in my network is causing this.

[Melloware]

I agree! I tried ahcmd.exe and still get the same funky dimming issue! But i have no idea what in my network is causing this.

I told ya! X10 is tricky, try the X10 forums http://forums.x10.com/ X10 experts there may be able to help.

Marking this thread SOLVED as its not a Commander issue.

[alzee]

Well I spent a couple weeks over at the x10 forum and this is what I found:

1. The cm19a dims properly with AHP software and Firecracker software but not with x10 commander
2. I bought a new cm19a and still have the same issue when using x10 commander
3. X10 commander dims as expected with cm17a, cm11 and cm15a.
4. The AHP activity monitor shows that when changing the device to dim on x10 commander when using the cm19a, x10 commander sends out a dim command but not a new device code which agrees with the end response, i.e. the previously turned on light dims not the one selected on right click.

Melloware, any thoughts?

Thanks!

[Melloware]

The CM15 and CM19 use the identical code and X10 SDK API. You can see here is the block of code...

We know the CM15 works and as far as I know the CM19 used to work since it is the EXACT same call for either device to the X10 SDK.

Code: Select all

      if (cboX10Device.ItemIndex = CM15A_CM19A) then
      begin
         logger.Info('   USB ' + strType + ' ' + strX10Command);
         if (FDimmingAccuracy) and (Pos('DIM', strX10Command) > 0) then
         begin
            iValue := StrToInt(FX10Commands.Strings[2]);
            if iValue > 0 then
            begin
              ActiveHome.SendAction(strType, strHouseCode + ' DIM 100');
              ActiveHome.SendAction(strType, strHouseCode + ' BRIGHT ' + FX10Commands.Strings[2]);
            end;
         end
         else if (FDimmingAccuracy) and (Pos('BRIGHT', strX10Command) > 0) then
         begin
            ActiveHome.SendAction(strType, strHouseCode + ' BRIGHT 100');
            iValue := 100 - StrToInt(FX10Commands.Strings[2]);
            if iValue > 0 then
            begin
              ActiveHome.SendAction(strType, strHouseCode + ' DIM ' + IntToStr(iValue));
            end;
         end
         else begin
            ActiveHome.SendAction(strType, strX10Command);
         end;
      end;


[alzee]

I here what your saying, but maybe they don't both require the same code? Maybe they did at one time but X10 changed cm19a ?

And I still don't understand my previously reported anomaly , X10 Commander requires that "Device Type" be set to "Power Line" even though CM19a communicates via RF or it won't dim at all.

Your thoughts?