I'm trying to switch from my old SVN checkout to the new git branch.

I notice that not all xPL messages are processed, more specifically the messages originating from my motion sensors.

I'm trying to find out what change to xPL_Items causes this problem.

Similar to Issue #61 which was solved in pull request #63.

The sub add_link in the aldb_plm object sets the $message->callback to _process_sync_queue. This results in _process_sync_queue getting called twice, once when the message is sent, and then again when the ACK is processed. This causes sync_links to process out of order.

Delete all orphan links on a specific device
Request Copied from Wiki

Not a whole lot of details. But Delete Orphan Links (Audit) just froze up on me. I have seen this before and don't know what causes it.

In this most recent event, I scanned all links, scanned a few devices directly, and then performed Delete Orphan Links (Audit). The log shows the following entries:

04/02/2013 11:41:49 Running: PLM AUDIT - delete orphan links
04/02/2013 11:41:49 [Insteon::ALDB_PLM] #### NOW BEGINNING DELETE ORPHAN LINKS ####
04/02/2013 11:41:49 [Insteon::ALDB_i1] Nothing else to do for $f_fm_lt_ma after deleting 0 links

but nothing else. All other commands continue to work, but I cannot perform the delete orphans (audit) without restarting MH.

As reported by Marc and Micheal:

I do seem to pick up a duplicate entry each time though.

Here's the log if that helps.
http://marc.merlins.org/tmp/mh_sync_link2/sync_link3

I have seen where there are discrepancies between what MH thinks it is syncing and what
the device actually contains. This could easily cause subsequent syncs to duplicate
entries. If you are curious you can reproduce the condition with the following sequence:
Sync links on a device (device needs to have new entries to sync)
Log links on that device
Scan links on that device
Log links on that device
Then do a diff of the link output between the two "log links" commands. When I do this I
see discrepancies in the group numbers. I'll dig into that issue and see what I find. It
will take me a while because I don't fully understand the metadata used to link devices;
the Insteon documents are vague in this area.

Sincerely,
Michael

An xPL_Plugwise item should only change state upon the reception of an .trig message and not when a change is requested.

Right now when a device is toggled, the state of the device is automatically changed. However, when a change of state of a device is request, it should only change when the device actually responded over xPL.

Validate the structure (command and length) of any message sent to the plm (to prevent lock-ups)
Request Copied from Wiki

Dustin Robinson reported the following error:

tie_events eval error: Can't locate object method "device_id" via package "Insteon::ALDB_PLM" at /opt/misterhouse/mh/bin/../lib/Insteon/AllLinkDatabase.pm line 718.

Marc Merlin reported another error:

Similar (but not idential problem) here on delete orphans:
19/12/2012 18:30:24 [Insteon_PLM] DEBUG3: Received raw PLM data: 026207de8b0f2be806
19/12/2012 18:30:24 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$gar_outlights_kpl; command=peek; extra=E8
19/12/2012 18:30:24 [Insteon_PLM] DEBUG3: Received raw PLM data: 025007de8b18d4ce232ba2
Can't use an undefined value as an ARRAY reference at ../lib/Insteon/AllLinkDatabase.pm line 1240.
mh stopped, enter to restart

Here's the patch I had to write for mine. You may need to write a similar
patch for your problem.

--- mh/lib/Insteon/AllLinkDatabase.pm.orig      2012-12-19 18:35:22.259809914 -0800
+++ mh/lib/Insteon/AllLinkDatabase.pm   2012-12-19 18:40:50.003238952 -0800
@@ -1217,7 +1217,9 @@
 sub delete_duplicate_link_address
 {
        my ($self, $address) = @_;
-        my $num_duplicate_link_addresses = @{$$self{aldb}{duplicates}};
+        my $num_duplicate_link_addresses = 0;
+
+       $num_duplicate_link_addresses = @{$$self{aldb}{duplicates}} if (defined $$self{aldb}{duplicates});
         if ($num_duplicate_link_addresses)
         {
                my @temp_duplicates = ();
@@ -1237,7 +1239,8 @@
 {
        my ($self, $address) = @_;
         # before adding it, make sure that it isn't already in the list!!
-        my $num_addresses = @{$$self{aldb}{empty}};
+       my $num_addresses = 0;
+       $num_addresses = @{$$self{aldb}{empty}} if (defined $$self{aldb}{empty});
         my $exists = 0;
         if ($num_addresses and $address)
         {

Note that this code is not bullet proof, Gregg wrote a lot of it quicky when
I was reporting bugs to him just before he had to stop contributing.

Marc

Found a typo on line 1262:

@{$$self{adlb}{empty}} = sort(@{$$self{aldb}{empty}});
^aldb

Similar error appears on 1215

Allow devices to be set as disabled. This would prevent retries during status request and/or other attempted operations (e.g., sync all) if the device is considered unavailable/disabled. Common uses for this may be (a) seasonal, (b) device failure, (c) etc. At present, I'm toying with this as I need it; am interested in other user views.
Request Copied from Wiki

This is a weird one, and I am still diagnosing it, but this is what I believe is happening so far.

Issue:

If two PLM scene commands are issued sequentially, the second command may never be sent. In this scenario, each Scene controls only one device. Specifically, they are surrogate scenes for KPL buttons. The basic print log shows something as follows:
PLM_Scene_1->set('on')
Received acknowledgement from PLM_SCENE_1
PLM_Scene_2->set('on')
Received acknowledgement from PLM_SCENE_1 (This is not a typo, the print log shows the first scene as acknowledged twice.)

Current Theory:

Setting the insteon debug level to 3 provides some additional detail. If left at the default settings, it looks like the PLM_Scene_1 command is issued and an acknowledgement is received. MH then tries to send the PLM_Scene_2 command but receives a "PLM is extremely busy" error 15 and claims that the command will be retried in 1 second.

While waiting to retry the command, MH receives a command from the PLM. The PLM reports this as being a second acknowledgement from PLM_SCENE_1. (I suspect at this point that MH erroneously deletes the pending command for PLM_Scene_2 that is waiting, believing that this command has been acknowledged).

If I up the Insteon_xmit setting to .7 seconds. Everything seems to work fine. The Insteon:3 debug log shows the following general sequence:
PLM_Scene_1->set('on')
Received acknowledgement from PLM_SCENE_1
Received All_Link Cleanup success from PLM_SCENE_1

PLM_Scene_2->set('on')
Received acknowledgement from PLM_SCENE_2
Received All_Link Cleanup success from PLM_SCENE_2

So I am not an Insteon guru, but it looks like we should be expecting two acknowledgments to PLM Scenes (at least this specific type of scene). While the first acknowledgment is specific to the one linked device. I believe the second acknowledgement is basically saying "All of the linked devices in this scene have reported in successfully."

I suspect that with the Insteon_xmit setting at the default level, that the All-Link Cleanup success message is why the PLM is busy when we attempt to send the PLM_Scene_2 command.

As noted above, I further suspect that at the default setting, the All-Link Cleanup success message causes MH to delete the pending PLM_SCENE_2 command.

Solutions:

1. Fix the code so that MH only removes a pending message if it receives a correct acknowledgement. Right now it looks like the comparison is not working perfectly.
2. If PLM Scenes will always receive an ALL-Link Cleanup Success message, maybe we should wait for it to come in.
3. Some combination of 1 and 2.

Status:

I am still working on diagnosing where in the code this all happens, if anyone smarter than me knows where to look or has some suggestion, please let me know.

It appears that the calls to delete_links and the traversing of the devices are being handled concurrently rather than sequentially. As a result, a psuedo log sequence looks like this:

Checking Device A for orphan links
Checking Device B for orphan links
Orphan link found on Device B
Checking Device C for orphan links
Checking Device D for orphan links
Orphan Links complete 1 link deleted
Deleting orphan link on Device B
Orphan Links complete 2 links deleted

Syncing links to remotelincs times out with I1, should use I2. If not, retry count should be very high so that user can watch logs and put the remotelinc back in pairing mode when it drops out of it in the middle of a sync.
Issue Copied from Wiki

In at least ubuntu 12.04, the xPL interface of the current master branch is broken.

The reception of xPL messages is not working. It is unclear if this is due to changing the port determination algorithm (too find an unused port) or due to the defaul address being set to 0.0.0.0.

To reproduce:

1. Factory Reset a Device
2. Scan Device
3. Sync Device
4. Log Links

MH will now print that the link table is empty. This is because add_link has failed to update the health of the link table.

In a scan posted here http://marc.merlins.org/tmp/mh_scan_all1/scan_all by Marc, there are quite a few instances of a ghost timer expiry. They seem to be benign until one occurs while a command is queued after a PLM busy NACK (15) response. That halts the scan state machine. Need to figure out why a timer is either 1) inadvertently left running, or 2) not correctly matched to the device / message after it expires. I suspect 1). I created a nice timeline with the following egrep command after saving off the file:
egrep "timer expired but no transmission|Scan all link tables|[Insteon::ALDB_i1] DEBUG3:" scan_all

I have not confirmed this yet, but in a recent scan all links returned the following error:

WARN!! encountered a nack message () for $f_dn_lt_ma. It may be unplugged, have a burned out bulb, or this may be a new I2CS type device that must first be manually linked to the PLM using the set button.

At this point Scan_Links stopped. Presumably there is no call to the failure callback.

Marc Merlin, myself, and someone else on the mailing list all commented that we at times see corrupted aldb entries. I believe, all of us initially assumed that the entries on the device were bad. Michael hinted that corrupt entries are unlikely to be on the devices as there are at least basic CRC checks that ensure that individual messages are not corrupt.

Last night I installed a new keypadlinc and noticed some incorrect entries at various points. At least in my case, the corrupt entries could all be fixed by conducting a second scan. As such, in my case the corruption is occurring on messages from the device back to MH. My list of possible culprits in order of decreasing likelihood are:

1. Bad error or message handling in MH (most likely the cause)
2. Interference in the USB connection (unlikely but possible)
3. Interference in the powerline or rf signal and the PLM doesn't do the CRC check (highly unlikely)

This problem explains why I have issues with and such an aversion to the sync_all_links and delete_orphan_links functions. If there is an error in the aldb hash stored by MH it could inappropriately delete a link as orphan or inappropriately add a duplicate link.

I had only a surface level of debugging enabled last night when this happened. This is one of those annoying intermittent problems that will take a while to reproduce. Hopefully I can make heads or tails of it this weekend.

The current design for handling All-Link messages in MH is a total mess.

The PLM handles much of the work for transmitting the messages. It sends a broadcast message and then sends individual messages to each device that fails to respond. It does not however nicely handle the responses, it just dumps all of them on us. In short the All-Link process is as follows:

1. Send ALL-Link Command
2. a. INSTEON Standard Message Received - for each device (for successful messages) OR
3. b. ALL-Link Cleanup Failure Report - for each device (that fails)
4. ALL-Link Cleanup Status Report - Only one. With an ACK/NACK depending on whether all devices properly responded

MAJOR Caveat - The PLM will just give up, if it receives another command from the computer. So you have to let it complete its tasks if you want it to work.

The current code is a total mess, it clears the active message after receiving the first INSTEON Standard Message Received. It completely ignores any Failure Reports that are received after this it also ignores if the Status Report contains a NACK. Finally, if another message is queued it will send that command to the PLM cancelling the ALL-Link process before it completes.

In short it is a total mess.

Roger noticed that after reverting the xPL regexp to the old value in #11 messages for device that have spaces in their names don't longer work.

I'll look into fixing this during the weekend.

I noticed that several of the ALDB_i1 functions switch to the AllLinkDataBase namespace once the call backs are completed. Honestly I don't fully understand the implications. Is this the correct behavior or should all the ALDB_i1 functions switch back to the ALDB_i1 namespace?
Example (1 of 3)
sub delete_link
....
package main;
eval($link_parms{callback});
package Insteon::AllLinkDataBase;

The recommended setup for MH is to have a user defined data_dir. However, tagline.pl looks for file data/remarks/1100tags.txt in the user defined directory, but never looks in the Pgm_Root/Data directory.

A stupid bug, likely in a little used feature, but it should be fixed since users may see a visible error in the output.

Somewhere around AllLinkDatabase.pm line 402.

The ALDB flag includes an "in use" flag. Why do we keep scanning the remaining bits if we the flag tells us the record is not in use?

Cmd1 in peek response messages is periodically corrupted. However, MH will still decode and treat the message as valid. It shouldn't do that.

A logged example can be found here:

http://pastebin.com/w5ZpXe6W

In this case an error occurs in scanning byte 0FF0. Specifically on line 83, the PLM receives the following message: 02500bbb541a794c27a40e. Decoding this message results in:
0250 - Standard Insteon Message
0bbb54 - From Address
1a794c - To Address
27 - Message Flags
a4 - This is a non-existant message type This should read 2B
0e - This should have been A2

23/03/2013 07:28:52 Running: PLM AUDIT - delete orphan links
23/03/2013 07:28:53 [Insteon::ALDB_PLM] #### NOW BEGINNING DELETE ORPHAN LINKS ####
23/03/2013 07:28:53 Insteon::ALDB_PLM Delete Orphan Link to non-existant
deviceid: 07de8b; group:41; controller; data:03
tie_events eval error: Can't call method "device_id" on an undefined value at
../lib/Insteon/AllLinkDatabase.pm line 2439.
at ./mh line 31

This is an odd and very specific error. To recreate you need to do the following:

1. A PLM controlled scene synced to two or more devices.
2. Delete one device as a responder to the scene, but leave the scene defined and the other device still linked.

If you run AUDIT Delete Orphans, the PLM section will contain a message similar to the following:
(AUDIT) Delete orphan controller link from PLM to $s_ma_room_lt_s1 because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $surrogate_s_st_lt_ma_b

But when you run Delete Orphans you will get the following error:
error during scan callback Can't locate object method "device_id" via package "Insteon::ALDB_PLM" at

Yet if you completely delete the PLM scene, Delete Orphans will work correctly.

A close inspection reveals the problem is in the ALDB_PLM Delete_Orphans subroutine around line 1971. The delete_req hash is all messed up, it should be identical to the delete_req has on or about line 1899, which is the request for a deleted plm scene.

I have a fix and will post later tonight.

Currently, if a user uses the "reload user code" command and there is an error in one of the user code files the user is only notified of the error in the console output. There is no option to enable logging of the error.

All of this is buried deep within the main mh perl file. Notably, the eval_user_code_load handles a lot of the error reporting to the console with a series of simple print commands.

Optionally sending these errors to a log seems like a good idea. This should probably be in addition to sending the errors to console.

As a side note, is anything other than a "Restart" ever sent to the error_log?

I had this when starting mh when my keypadlinc was misconfigured as keypadlinc instead of keypadlinc_relay:

Can't call method "_process_command_stack" on unblessed reference at ../lib/Insteon_PLM.pm line 625.
at ./mh line 31
main::ANON('Can't call method "_process_command_stack" on unblessed refe...') called at ../lib/Insteon_PLM.pm line 625
Insteon_PLM::parse_data('Insteon_PLM=HASH(0xa4cbd90)', '02564207de8b025806') called at ../lib/Insteon_PLM.pm line 164
Insteon_PLM::check_for_data('Insteon_PLM=HASH(0xa4cbd90)') called at ../lib/Insteon/BaseInterface.pm line 11
Insteon::BaseInterface::check_for_data() called at ./mh line 1402
main::run_hooks('MainLoop_pre') called at (eval 335) line 5
main::MainLoop_pre_hooks() called at ./mh line 1515
main::check_for_action called at ./mh line 3296
main::monitor_commands called at ./mh line 6713

Revise log output to better assist debug as well as anomaly detection. This also includes the ability to adjust the verbosity level on a per-device (to include the plm) basis.
Request from Wikispaces

The substr() function fails miserably if given a starting location beyond the end of the string. When the PLM code receives a partial message the decoder tries to parse it and fails.

I had just assumed Michael had access. He clearly has the knowledge to handle his own merges and certainly contributes enough to warrant it.

Gregg implemented code to omit RF devices from the sync links process. This is his check-in that I think has a typo: daa83de#lib/Insteon.pm

I’ve never seen a semicolon at the end of an if/elsif/else stanza like that and the push line doesn’t have the requisite semicolon….. Perl doesn’t generate any kind of warning that I can see. How does Perl interpret that? Is this something that I should change? I’m worried about the unintended consequences since I don’t understand how Perl currently interprets the code.

124     +             push @_sync_devices, \%sync_req
125     +                };

Currently if an add, delete or update link fails, the failure is called out in the print log, but only at the time of the error. As a result, if a failure occurs during a sync_links or delete_orphans call to the PLM the failures will often be buried within the long print log output. These failure can easily be missed.

As a solution, the errors should be gathered and displayed at the end of the batch process similar to how they are displayed for scan_all_links. Some of the foundational logic for this already exists for sync links, the failure call back just needs to be passed down through the subroutine calls.

Delete_Orphans does not contain any logic for this and would need to be supplemented.

The file lib/Insteon/MessageDecoder_test.pl is a Perl script but does not have a shabang line and therefore cannot be executed directly like the other Perl scripts in the same directory. Also; the Perl Module files in the directory all have their executable mode bits set but such files are not intended to be executated directly.

These issues can be resolved by:

1. Add a shabang line to MessageDecoder_test.pl like this: "#!/usr/bin/perl -w".
2. Remove the executable mode setting from the *.pm files.

Is it Windows XP/Vista/7? I can't confirm that it works on 8 and don't think we need to support anything older than XP but let's discuss it.

The relevant User docs I know of are:
docs/faq.pod
docs/install.pod
docs/mh.pod

I cloned the latest GIT to begin playing with zwave. Although the wiki is outdated in regards to zwave, there should be a file ZWave_RZC0P.pm (or I think the old version ZWave_Interface_RZC0P.pm) but it's missing from GIT.

So:

1. Do we need to add ZWave_RZC0P.pm to the GIT code?
2. Anything else we need to do to restore ZWave functionality?

I'm new to perl, and newish to MH but I will happily own this as a branch. However, I'll need a helping hand to get going...

Device pull down menu should have "resync device" that would scan all links, remove orphans, and sync missing links. Think of a "make device links be what mh thinks they should be"
Request Copied from Wiki

The voice commands do nothing.

Running the subroutines directly such as $object->link_to_interface works

Hi fellow repo maintainers,

I propose we give Kevin (@krkeegan) write access to the main repo. He is actively contributing code, so I think it is rightful he can decide to merge pull requests himself.

What is your view on this?

Kind regards,
Lieven.

If the user unplugs the PLM, holds the button, plugs the PLM back in, and continues to hold the button until the PLM quits the long beep while connected to a running MH instance; the messaging parsing logic will get wedged with a PLM message stuck in the receive queue. The PLM send a "user reset detected" message x02x55. Since this is not decoded by the receive loop, the message sticks as "extra" data.

22/03/2013 21:35:41 [Sync all links] Adding $garage2_neon_kpl_gar_outlights to sync queue
22/03/2013 21:35:41 [Sync all links] Adding $garage2_neon_kpl_yard_lights to sync queue
tie_events eval error: Can't call method "health" on an undefined value at ../lib/Insteon.pm line 173, line 11.
at ./mh line 31
main::ANON('Can't call method "health" on an undefined value at ../lib/I...') called at ../lib/Insteon.pm line 169
Insteon::sync_all_links(1) called at (eval 94479) line 1
eval '&Insteon::sync_all_links(1)
;' called at ./mh line 2476
main::check_for_tied_events('Voice_Cmd=HASH(0xb7cf640)') called at ../lib/Generic_Item.pm line 1144
Generic_Item::reset_states2('Voice_Cmd=HASH(0xb7cf640)', 'AUDIT - sync all links', 'web [192.168.205.7]', '') called at ../lib/Generic_Item.pm line 1461
Generic_Item::reset_states called at ./mh line 1499
main::check_for_action called at ./mh line 3296
main::monitor_commands called at ./mh line 6713
Sending 22 bytes of data to localhost port 8084, socket made, data sent
22/03/2013 21:35:50 Received server_data data: name=: action=run arg=

Syncing links to remotelincs should have a 'sync all buttons' option

Syncing links to KPLs should have a 'sync all buttons' option

Issue Copied from Wiki

I am not sure exactly what this parameter was supposed to do when it worked.

But I am nearly certain that it does nothing now. I can't see anything that it does in the code. Plus, I set it to 1 and then ran a scan at startup in which the last device scanned incurred a delay of 31 seconds before the message was sent and it didn't do anything.

Can anyone describe what this was supposed to do?
Should we get rid of this config param?

Delete orphan links should detect hangs on devices and recover/continue
Request Copied from Wiki

This has not been confirmed.

On a brand new device I did not link manually (except with the PLM):

I then ran a scan link table. Mmmh, I have an empty slot now:
> > 22/03/2013 22:35:37 [Insteon::BaseObject] The Link Table Version for $gar_outlights_kpl has been updated to version number 06

22/03/2013 22:35:37 [Insteon::AllLinkDatabase] Link table for $gar_outlights_kpl health: good
22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0fc7] is empty > > 22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0fcf] contlr(01) record to $garage1_neon_kpl (05), (d1:ff, d2:00, d3:05) > > 22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0fd7] contlr(01) record to $fmr_kpl (07), (d1:ff, d2:00, d3:07) > > 22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0fdf] contlr(01) record to $garage2_neon_kpl (05), (d1:ff, d2:00, d3:05) > > 22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0fe7] contlr(01) record to $kitchen_kpl (07), (d1:ff, d2:00, d3:07) > > 22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0fef] rspndr(01) record to $PLM (01): onlevel=on and ramp=none (d3:01) > > 22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0ff7] contlr(01) record to $PLM (01), (d1:03, d2:1f, d3:01) > > 22/03/2013 22:35:37 [Insteon::AllLinkDatabase] [0x0fff] contlr(01) record to 13d0df (01), (d1:03, d2:1c, d3:01)

Mmmh, I had just done a scan all links, I wonder how those got lost, so I redid a new scan all links
and the first failed:

22/03/2013 22:44:06 [Scan all link tables] Now scanning: $entryway (12 of 27)
22/03/2013 22:44:06 [Insteon::ALDB_i2] $entryway reading ALDB at location: 0x0000
(...)
22/03/2013 22:44:08 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops.
22/03/2013 22:44:08 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group:
22/03/2013 22:44:08 [Insteon::BaseObject] DEBUG3: Adding hop count of 1 to hop_array of $entryway
22/03/2013 22:44:08 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0ff7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read
22/03/2013 22:44:08 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0ff7] received ack
22/03/2013 22:44:08 [Insteon_PLM] DEBUG3: Received PLM raw data: 02510f230218d4ce112f0001010ff701a2040e0912ff000000
22/03/2013 22:44:08 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group:
22/03/2013 22:44:08 [Insteon::BaseInterface] Processing message for $entryway
22/03/2013 22:44:08 [Insteon::BaseObject] DEBUG3: Adding hop count of 1 to hop_array of $entryway
22/03/2013 22:44:08 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0ff7] received: 0001010ff701a2040e0912ff000000 for _mem_activity=scan mem_action=aldb_i2readack
22/03/2013 22:44:08 [Insteon::ALDB_i2] $entryway reading ALDB at location: 0x0fef
22/03/2013 22:44:08 [Insteon_PLM] DEBUG2: Sending ce00 incurred delay of 0.61 seconds; starting hop-count: ? > > 22/03/2013 22:44:08 [Insteon_PLM] DEBUG3: Sending PLM raw data: 0263ce00 > > 22/03/2013 22:44:08 [Insteon_PLM] DEBUG3: Received PLM raw data: 0263ce0006
22/03/2013 22:44:08 [Insteon_PLM] DEBUG3: Received PLM acknowledge: ce00 > > 22/03/2013 22:44:09 [Insteon_PLM] DEBUG2: Sending c380 incurred delay of 1.15 seconds; starting hop-count: ? > > 22/03/2013 22:44:09 [Insteon_PLM] DEBUG3: Sending PLM raw data: 0263c380
22/03/2013 22:44:09 [Insteon_PLM] DEBUG3: Received PLM raw data: 15 > > 22/03/2013 22:44:09 [Insteon_PLM] DEBUG3: Interface extremely busy. Resending command after delaying for 1 second > > 22/03/2013 22:44:10 [Insteon::BaseMessage] WARN: now resending c380 after 1 attempts.
Can't call method "get_object_name" on an undefined value at ../lib/Insteon/Message.pm line 139. > > at ./mh line 31
main::ANON('Can't call method "get_object_name" on an undefined value at...') called at ../lib/Insteon/Message.pm line 139
Insteon::BaseMessage::send('Insteon::X10Message=HASH(0xbc87618)', 'Insteon_PLM=HASH(0xad80074)') called at ../lib/Insteon/BaseInterface.pm line 235
Insteon::BaseInterface::process_queue('Insteon_PLM=HASH(0xad80074)') called at ../lib/Insteon_PLM.pm line 189 > > Insteon_PLM::check_for_data('Insteon_PLM=HASH(0xad80074)') called at ../lib/Insteon/BaseInterface.pm line 11
Insteon::BaseInterface::check_for_data() called at ./mh line 1402
main::run_hooks('MainLoop_pre') called at (eval 335) line 5 > > main::MainLoop_pre_hooks() called at ./mh line 1515 > > main::check_for_action called at ./mh line 3296 > > main::monitor_commands called at ./mh line 6713