[mh] Bug in MH handling of v1.0 ApplianceLinc 2-way X-10

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

I'm looking for advice from other developers that know the code better.  I
got an old 2002STW ApplianceLinc with a v1.0 0203 sticker (so it was made
early 2002) on ebay and it seems to be sending a response to X10 status
request that MH doesn't expect.  Here's a piece of the log:

04/19/2013 07:09:46 PM [Insteon_PLM] x10 sending code: A1 as insteon msg:
6600
04/19/2013 07:09:46 PM [Insteon_PLM] x10 sending code: ASTATUS as insteon
msg: 6f80
04/19/2013 07:09:46 PM [Insteon_PLM] DEBUG2: Sending 6600 incurred delay of
0.00 seconds; starting hop-count: ?
status 04/19/2013 07:09:46 PM Undefined subroutine: main::1
04/19/2013 07:09:46 PM [Insteon_PLM] DEBUG2: Sending 6f80 incurred delay of
0.55 seconds; starting hop-count: ?
Serial data: event_type=X, event_data=XASTATUS_ON
04/19/2013 07:09:47 PM ed1:ASTATUS_ON prev_units : A1
X10: Previous units= reset_flag=1
04/19/2013 07:09:47 PM X10: Unmatched incoming data=XASTATUS_ON
Serial data: event_type=X, event_data=XA1
04/19/2013 07:09:48 PM XA1: x10_WorkroomBackLamp manual
X10: Previous units=A1 reset_flag=0
04/19/2013 07:09:48 PM X10: Merged string data=XA1STATUS_ONA1
Serial data: event_type=X, event_data=XAJ
X10: Previous units=A1 reset_flag=1
04/19/2013 07:09:48 PM X10: Merged string data=XA1STATUS_ONA1AJ
04/19/2013 07:09:48 PM X10: Unmatched incoming data=XAJ

Since MH ends up with Merged string data=XSTATUS_ONA1AJ I added this to
X10_Items.pm:
            $self->add ('XSTATUS_ON' . substr($id, 1, 2) . $hc . 'J',
'status on');
            $self->add ('XSTATUS_OFF' . substr($id, 1, 2) . $hc . 'K',
'status off');

below the existing lines:
            $self->add ($id . $hc . 'STATUS_ON', 'status on');
            $self->add ($id . $hc . 'STATUS_OFF', 'status off');

That mostly fixes the problem:
04/20/2013 12:17:33 AM [Insteon_PLM] x10 sending code: B1 as insteon msg:
e600
04/20/2013 12:17:33 AM [Insteon_PLM] x10 sending code: BSTATUS as insteon
msg: ef80
04/20/2013 12:17:33 AM [Insteon_PLM] Command stack size: 1, active message
'obj=$plm; ; interface_data='
04/20/2013 12:17:33 AM [Insteon_PLM] DEBUG2: Sending e600 incurred delay of
0.04 seconds; starting hop-count: ?
04/20/2013 12:17:34 AM [Insteon_PLM] DEBUG2: Sending ef80 incurred delay of
1.62 seconds; starting hop-count: ?
  ********  charger state changed to 'status'
04/20/2013 12:17:35 AM Undefined subroutine: main::1
Serial data: event_type=X, event_data=XBSTATUS_ON
04/20/2013 12:17:36 AM ed1:BSTATUS_ON prev_units : 
X10: Previous units= reset_flag=1
04/20/2013 12:17:36 AM X10: Unmatched incoming data=XBSTATUS_ON
Serial data: event_type=X, event_data=XB1
04/20/2013 12:17:36 AM XB1: x10_Chargers manual
X10: Previous units=B1 reset_flag=0
04/20/2013 12:17:36 AM X10: Merged string data=XSTATUS_ONB1
  ********  charger state changed to 'manual'
Serial data: event_type=X, event_data=XBJ
X10: Previous units=B1 reset_flag=1
04/20/2013 12:17:36 AM X10: Merged string data=XSTATUS_ONB1BJ
Running serial_data_buffer string: XSTATUS_ONB1BJ
Serial data: event_type=X, event_data=XSTATUS_ONB1BJ
04/20/2013 12:17:37 AM ed1:STATUS_ONB1BJ prev_units : B1
04/20/2013 12:17:37 AM XSTATUS_ONB1BJ: x10_Chargers status on
X10: Previous units=NB reset_flag=1
04/20/2013 12:17:37 AM X10: Merged string data=XSTATUS_ONB1STATUS_ONB1BJ
  ********  charger state changed to 'status on'

"charger state changed to 'status on'" is extra debug output I added
whenever $x10_Chargers->state_changed() was defined.

One problem with this fix is there seems to be a bug somewhere that changes
the original XBSTATUS_ON received to XSTATUS_ON in the final string that my
fix compares to using $self->add ('XSTATUS_ON' . substr($id, 1, 2) . $hc .
'J', 'status on');

Is that bug worth fixing or is it likely to break something else?

The other problem is this line that appears before and after the fix:
Undefined subroutine: main::1
That's main::ONE not main::L, btw.  This line doesn't seem to break anything
or cause a crash but I'd like to fix it if possible.  Unfortunately I have
no idea how to figure out where it's coming from.

--
View this message in context: http://misterhouse.10964.n7.nabble.com/Bug-in-MH-handling-of-v1-0-ApplianceLinc-2-way-X-10-tp17823.html
Sent from the Misterhouse - User mailing list archive at Nabble.com.