From: George C. <ge...@fe...> - 2014-02-06 16:04:18
|
Hi all, I've been trying to get a PLM scene running, and it's really close, except for the scene state tracking. Unfortunately the Wikispaces pages are rather out of date on the new Insteon and scene definitions. I'd be glad to contribute some documentation to the wiki once it's working. Same goes for the I/O Linc and it's sensor definition. I've got a "night_mode" scene which controls my porch lights and one interior night light. The basic linking and controls are working fine. And misterhouse control of the scene works great as well: # Scene for night mode # PLM, Name, Categories INSTEON_ICONTROLLER, A5, night_mode, All_Lights|Outside # name, device, cont, resp, on_lev, ramp_rate SCENE_BUILD, night_mode, l_back_porch, 0, 1, 20%, 0s SCENE_BUILD, night_mode, l_kitchen_window, 0, 1, 20%, 0s SCENE_BUILD, night_mode, l_front_porch, 0, 1, 20%, 0s SCENE_BUILD, night_mode, l_back_hall_bH, 1, 1 On the device side, back hall button H toggles the three lights between off and 20%. And from misterhouse, setting night_mode ON or OFF accomplishes the same thing. So operationally, all is good. However cosmetically, if I press button H, misterhouse does not track the state of the scene. The lights change state within misterhouse, but not the scene. So the scene shows off, even though bH is lit and the lights are at 20%, and mh shows them as "Dim". Any suggestions on how to get the button to update the status of the scene within misterhouse? Thanks, George |
From: H P. <hp...@gm...> - 2014-02-06 16:31:16
|
I think this is similar to a thread a few weeks back (Kevin, please correct me if I'm mistaken) that I raised around does it make sense to track scenes as entities. I'm looking at putting in a few three-way switches, and have had to use a combination of scene lines in my items.mht file, as well as usercode to keep the state of devices and scene in sync. This is important to me as I have a three way light in the garage, and the only way I know it's on from inside the house is the switchlinc led status. The user code activates if a member changes state, and then that subroutine updates the state of all scene members. It's clunky, and there is a 1 second delay for all devices to sync. I trigger the garage light to go on when the door opens, so I open the garage door, the light goes on immediately, and the a second later the little switchlight relay clicks and updates its status. There was some discussion about the best standardized way to approach this, and some good ideas were thrown around, but I don't think we landed on anything. As I'm looking at putting in two more 3 way switches, it would be great to have agreement in this area to save future reconfiguration. That said, what I have works, and I can continue to use it. On Thu, Feb 6, 2014 at 9:04 AM, George Clark <ge...@fe...> wrote: > Hi all, > > I've been trying to get a PLM scene running, and it's really close, > except for the scene state tracking. Unfortunately the Wikispaces pages > are rather out of date on the new Insteon and scene definitions. I'd > be glad to contribute some documentation to the wiki once it's working. > Same goes for the I/O Linc and it's sensor definition. > I've got a "night_mode" scene which controls my porch lights and one > interior night light. The basic linking and controls are working fine. > And misterhouse control of the scene works great as well: > > # Scene for night mode > # PLM, Name, Categories > INSTEON_ICONTROLLER, A5, night_mode, All_Lights|Outside > > # name, device, cont, resp, > on_lev, ramp_rate > SCENE_BUILD, night_mode, l_back_porch, 0, 1, 20%, > 0s > SCENE_BUILD, night_mode, l_kitchen_window, 0, 1, 20%, > 0s > SCENE_BUILD, night_mode, l_front_porch, 0, 1, 20%, > 0s > SCENE_BUILD, night_mode, l_back_hall_bH, 1, 1 > > On the device side, back hall button H toggles the three lights between > off and 20%. And from misterhouse, setting night_mode ON or OFF > accomplishes the same thing. So operationally, all is good. > > However cosmetically, if I press button H, misterhouse does not track > the state of the scene. The lights change state within misterhouse, > but not the scene. So the scene shows off, even though bH is lit and > the lights are at 20%, and mh shows them as "Dim". Any suggestions on > how to get the button to update the status of the scene within misterhouse? > > Thanks, > George > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: > https://lists.sourceforge.net/lists/listinfo/misterhouse-users > > |
From: George C. <ge...@fe...> - 2014-02-06 16:43:22
|
Hi, I use a similar setup for my 3-way switches, and I didn't notice it before, but indeed it has the same issue. INSTEON_ICONTROLLER, A4, back_hall, All_Lights|BackHall SCENE_BUILD, back_hall, l_back_top_stairs, 1, 1, 100%, 0s SCENE_BUILD, back_hall, l_back_entrance, 1, 1, 100%, 0s SCENE_BUILD, back_hall, l_back_hall_bA, 1, 1, 100%, 0s This should be simpler than the night-mode scene, in that all three devices are controllers and responders and are all fully cross-linked. The individual device statuses all track. It's only the scene that is left behind. George On 02/06/2014 11:30 AM, H Plato wrote: > I think this is similar to a thread a few weeks back (Kevin, please > correct me if I'm mistaken) that I raised around does it make sense to > track scenes as entities. I'm looking at putting in a few three-way > switches, and have had to use a combination of scene lines in my > items.mht file, as well as usercode to keep the state of devices and > scene in sync. This is important to me as I have a three way light in > the garage, and the only way I know it's on from inside the house is > the switchlinc led status. > > The user code activates if a member changes state, and then that > subroutine updates the state of all scene members. It's clunky, and > there is a 1 second delay for all devices to sync. I trigger the > garage light to go on when the door opens, so I open the garage door, > the light goes on immediately, and the a second later the little > switchlight relay clicks and updates its status. > > There was some discussion about the best standardized way to approach > this, and some good ideas were thrown around, but I don't think we > landed on anything. As I'm looking at putting in two more 3 way > switches, it would be great to have agreement in this area to save > future reconfiguration. That said, what I have works, and I can > continue to use it. > > > On Thu, Feb 6, 2014 at 9:04 AM, George Clark <ge...@fe... > <mailto:ge...@fe...>> wrote: > > Hi all, > > I've been trying to get a PLM scene running, and it's really close, > except for the scene state tracking. Unfortunately the Wikispaces > pages > are rather out of date on the new Insteon and scene definitions. > I'd > be glad to contribute some documentation to the wiki once it's > working. > Same goes for the I/O Linc and it's sensor definition. > I've got a "night_mode" scene which controls my porch lights and one > interior night light. The basic linking and controls are working > fine. > And misterhouse control of the scene works great as well: > > # Scene for night mode > # PLM, Name, Categories > INSTEON_ICONTROLLER, A5, night_mode, All_Lights|Outside > > # name, device, cont, resp, > on_lev, ramp_rate > SCENE_BUILD, night_mode, l_back_porch, 0, 1, > 20%, > 0s > SCENE_BUILD, night_mode, l_kitchen_window, 0, 1, > 20%, > 0s > SCENE_BUILD, night_mode, l_front_porch, 0, 1, > 20%, > 0s > SCENE_BUILD, night_mode, l_back_hall_bH, 1, 1 > > On the device side, back hall button H toggles the three lights > between > off and 20%. And from misterhouse, setting night_mode ON or OFF > accomplishes the same thing. So operationally, all is good. > > However cosmetically, if I press button H, misterhouse does not > track > the state of the scene. The lights change state within misterhouse, > but not the scene. So the scene shows off, even though bH is lit and > the lights are at 20%, and mh shows them as "Dim". Any > suggestions on > how to get the button to update the status of the scene within > misterhouse? > > Thanks, > George > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: > https://lists.sourceforge.net/lists/listinfo/misterhouse-users > > |
From: Eloy P. <pe...@ch...> - 2014-02-06 17:46:33
|
Hi George, On 02/06/2014 11:43 AM, George Clark wrote: > Hi, > > I use a similar setup for my 3-way switches, and I didn't notice it > before, but indeed it has the same issue. > > INSTEON_ICONTROLLER, A4, back_hall, All_Lights|BackHall > SCENE_BUILD, back_hall, l_back_top_stairs, 1, 1, 100%, 0s > SCENE_BUILD, back_hall, l_back_entrance, 1, 1, 100%, 0s > SCENE_BUILD, back_hall, l_back_hall_bA, 1, 1, 100%, 0s > > This should be simpler than the night-mode scene, in that all three > devices are controllers and responders and are all fully cross-linked. > The individual device statuses all track. It's only the scene that is > left behind. I also have a 3-way switch setup and I believe it is working as it should, i.e. control the light from anywhere (locally from any of the switches, through the MH web interface, or through MH user code) and the state of the scene is always accurate. The wiki talks about how to handle this but I think the documentation can be improved because it took me a little bit of experimentation to get where I am right now. I've been busy and haven't had a chance to work on improving the wiki section on this but I'll try to find some time to do it. In the meantime, here's what you can do to fix your 3-way switch setup (see if this can also help with the night_mode PLM scene, although I have never used this for that. I think it's more complicated because of the different dim levels): You need to use the tie_event() method for the MH INSTEON object that controls the load. That tie_event() references a function that you will need to write. That function will be called when the state of the object that controls the load changes (someone changed the state by pressing a paddle locally, or MH changed the state, etc.). Here's an example from my setup: $upstairs_hallway_mast_light->tie_event('&update_PLM_scene_state($upstairs_hallway_mast_light, $upstairs_hallway_light)'); #noloop So, when $upstairs_hallway_mast_light changes state, update_PLM_scene_state() will be called with two parameters: 1. name of the actual object that changed state, and 2. name of the scene that needs to be updated. These parameters are hardcoded when you call the tie_event() method. My update_PLM_scene_state() function is below, but basically it works like this: 1. If the state of the object hasn't changed then it does nothing. This function can be called when the device is queried to get its status, and we don't want to do extra, unnecessary work in that case, so we just return if the state hasn't changed. 2. We check who changed the state of the object -- if it was the PLM scene itself then the state of the scene does not need to be updated; if it was something else then the state of the scene does need to be updated. 3. If needed based on the check in (2), we update the state of the scene by calling the scene's set_receive() method, which updates the internal MH state without actually generating any traffic. Hope this helps. Cheers, Eloy Paris.- # See http://misterhouse.wikispaces.com/Insteon+Devices+-+Quirks+and+Hints#KeypadLinc--Tying Local Control of a Light to MH Scenes sub update_PLM_scene_state() { my ($ref_device, $scene) = @_; if (!$ref_device->state_changed() ) { print_log("update_PLM_scene_state(): called for " . $ref_device->get_object_name() . " and scene " . $scene->get_object_name() . " but state has not " . "changed; not doing anything."); return; } # This is a lot of information to log, but it's useful for debugging. print_log("update_PLM_scene_state(): called because " . $ref_device->get_object_name() . " changed state " . "to '" . $ref_device->state() . "'; attempting to update " . "PLM scene " . $scene->get_object_name() . "..." . " (" . $ref_device->get_object_name() . " was set by " . $ref_device->get_set_by()->get_object_name() . ". \$ref_device->get_set_by() = " . $ref_device->get_set_by() . ", scene = " . $scene . " )."); # If the device was not updated by the scene itself, i.e. some local # control (like locally toggling the lighswitch) caused the scene to # change then we need to update the state of the scene. We cannot use # "&& $ref_device->get_set_by eq $ref_device" as the second condition # because there might be other devices that can change the scene # (typical example is a n-way switch). if (ref $ref_device->get_set_by() && $ref_device->get_set_by() ne $scene) { print_log("update_PLM_scene_state(): updating state of PLM scene because scene was not changed by us."); $scene->set_receive($ref_device->state(), "update_PLM_scene_state()"); } else { # Mask automation because the device was locally controlled print_log("update_PLM_scene_state(): not updating state of PLM scene because scene was changed by us."); } } > > On 02/06/2014 11:30 AM, H Plato wrote: >> I think this is similar to a thread a few weeks back (Kevin, please >> correct me if I'm mistaken) that I raised around does it make sense to >> track scenes as entities. I'm looking at putting in a few three-way >> switches, and have had to use a combination of scene lines in my >> items.mht file, as well as usercode to keep the state of devices and >> scene in sync. This is important to me as I have a three way light in >> the garage, and the only way I know it's on from inside the house is >> the switchlinc led status. >> The user code activates if a member changes state, and then that >> subroutine updates the state of all scene members. It's clunky, and >> there is a 1 second delay for all devices to sync. I trigger the >> garage light to go on when the door opens, so I open the garage door, >> the light goes on immediately, and the a second later the little >> switchlight relay clicks and updates its status. >> There was some discussion about the best standardized way to approach >> this, and some good ideas were thrown around, but I don't think we >> landed on anything. As I'm looking at putting in two more 3 way >> switches, it would be great to have agreement in this area to save >> future reconfiguration. That said, what I have works, and I can >> continue to use it. >> >> >> On Thu, Feb 6, 2014 at 9:04 AM, George Clark <ge...@fe... >> <mailto:ge...@fe...>> wrote: >> >> Hi all, >> >> I've been trying to get a PLM scene running, and it's really close, >> except for the scene state tracking. Unfortunately the Wikispaces >> pages >> are rather out of date on the new Insteon and scene definitions. >> I'd >> be glad to contribute some documentation to the wiki once it's >> working. >> Same goes for the I/O Linc and it's sensor definition. >> I've got a "night_mode" scene which controls my porch lights and one >> interior night light. The basic linking and controls are working >> fine. >> And misterhouse control of the scene works great as well: >> >> # Scene for night mode >> # PLM, Name, Categories >> INSTEON_ICONTROLLER, A5, night_mode, All_Lights|Outside >> >> # name, device, cont, resp, >> on_lev, ramp_rate >> SCENE_BUILD, night_mode, l_back_porch, 0, 1, 20%, >> 0s >> SCENE_BUILD, night_mode, l_kitchen_window, 0, 1, 20%, >> 0s >> SCENE_BUILD, night_mode, l_front_porch, 0, 1, 20%, >> 0s >> SCENE_BUILD, night_mode, l_back_hall_bH, 1, 1 >> >> On the device side, back hall button H toggles the three lights >> between >> off and 20%. And from misterhouse, setting night_mode ON or OFF >> accomplishes the same thing. So operationally, all is good. >> >> However cosmetically, if I press button H, misterhouse does not >> track >> the state of the scene. The lights change state within misterhouse, >> but not the scene. So the scene shows off, even though bH is lit and >> the lights are at 20%, and mh shows them as "Dim". Any >> suggestions on >> how to get the button to update the status of the scene within >> misterhouse? >> >> Thanks, >> George >> |
From: George C. <ge...@fe...> - 2014-02-06 18:06:18
|
Hi Eloy, Thanks for the detailed example. I'll work through this and try to get it working for both my night scene and the N-way switches. I'll be glad to contribute back to the wiki. I'd find it helpful to have focused "task" based pages as opposed to general discussion pages, for ex: - Insteon3WaySwitches - InsteonIOLinkSensor - InsteonKplScenes The examples shipped with mh are good, but it's really difficult to find specific examples of simple configurations, and a lot of them are out of date. Finding the related tidbits within the pod documentation is also a bit daunting. I've joined the wiki as GeorgeClark and requested access. Thanks again, George On 02/06/2014 12:46 PM, Eloy Paris wrote: > The wiki talks about how to handle this but I think the documentation > can be improved because it took me a little bit of experimentation to > get where I am right now. I've been busy and haven't had a chance to > work on improving the wiki section on this but I'll try to find some > time to do it. > > In the meantime, here's what you can do to fix your 3-way switch setup |
From: Kevin R. K. <ke...@kr...> - 2014-02-06 18:07:55
|
George, Eloy has given you good advice, we just discussed this exact issue a few days ago. While maybe a little confusing, the solution will achieve what you want. The issue exists because at the protocol level PLM Scenes are not really objects that have a state. Instead, PLM Scenes are really just announcements. The PLM tells all the devices what to do, but doesn't check back later to see if the devices have varied from this instruction. Within MH we have tried to give the Scene a state like parameter, but as you have found, it is not perfect. I have been considering changes to MH that would make this process easier. Kevin |
From: George C. <ge...@fe...> - 2014-02-06 21:07:58
|
Hi Kevin, Eloy, This indeed worked, Thanks. I apologize for hitting the list with so much debugging. Each step forward, and I seem to take another step backwards. The learning process is painful. I now have one 4-way switch group that is having a bit of issues. Scan links / Sync links on the switches and PLM is completely clean. Controlling the scene from MH results in NAKs and unknown groups. # Front hall 1st/2nd floor, 3 switches INSTEON_SWITCHLINC, 25.52.76, l_2fl_hall_m, All_Lights|FrontHall #2nd Fl Hall back 25.52.76 2477D R7.2 2913 (Load) INSTEON_SWITCHLINC, 29.0C.BE, l_2fl_hall_s1, hidden #Top front stairs 29.0C.BE 2477D R7.2 3913 INSTEON_SWITCHLINC, 25.41.AE, l_2fl_hall_s2, All_Lights|FrontHall #Front hall 25.41.AE 2477D R7.2 2913 (Load) INSTEON_ICONTROLLER, A1, front_hall, All_Lights|FrontHall SCENE_BUILD, front_hall, l_2fl_hall_m, 1, 1, 100%, 0s SCENE_BUILD, front_hall, l_2fl_hall_s1, 1, 1, 100%, 0s SCENE_BUILD, front_hall, l_2fl_hall_s2, 1, 1, 100%, 0s CODE, $l_2fl_hall_m->tie_event( '&update_PLM_scene_state($l_2fl_hall_m, $front_hall)'); #noloop CODE, $l_2fl_hall_s1->tie_event( '&update_PLM_scene_state($l_2fl_hall_s1, $front_hall)'); #noloop CODE, $l_2fl_hall_s2->tie_event( '&update_PLM_scene_state($l_2fl_hall_s2, $front_hall)'); #noloop The communications tests reasonably clean, though the stress test reported one error: 06/02/2014 15:31:43 Running: l 2fl hall m print message stats 06/02/2014 15:31:43 [Insteon::BaseDevice] Message statistics for $l_2fl_hall_m: In Corrupt %Corrpt Dupe %Dupe HopsLeft Max_Hops Act_Hops 11 0 0.0% 1 9.1% 0.0 1.1 1.1 Out Fail %Fail Retry AvgSend Avg_Hops CurrHops 5 0 0.0% 0 1.0 1.0 1 06/02/2014 15:31:47 Running: l 2fl hall s2 print message stats 06/02/2014 15:31:48 [Insteon::BaseDevice] Message statistics for $l_2fl_hall_s2: In Corrupt %Corrpt Dupe %Dupe HopsLeft Max_Hops Act_Hops 12 0 0.0% 0 0.0% 0.3 2.1 1.8 Out Fail %Fail Retry AvgSend Avg_Hops CurrHops 5 1 20.0% 7 2.4 2.0 3 06/02/2014 15:31:52 Running: l 2fl hall s1 print message stats 06/02/2014 15:31:52 [Insteon::BaseDevice] Message statistics for $l_2fl_hall_s1: In Corrupt %Corrpt Dupe %Dupe HopsLeft Max_Hops Act_Hops 10 0 0.0% 0 0.0% 0.0 1.5 1.5 Out Fail %Fail Retry AvgSend Avg_Hops CurrHops 5 0 0.0% 0 1.0 2.0 2 These 3 switches are all on the same circuit. They are on a different phase from the PLM. They all blink green when I do a bridging test. Individual devices can be controlled just fine, And the scene tracks the state of the switches, so everything is tied correctly. But if I tell the scene to go on or off from the MH web, mh shows everything turning off as expected, but the lights remain on, so it's out-of-sync between MH and the individual devices: Something seems strange here, with NAK's and invalid groups. I get the following log messages: 06/02/2014 15:42:45 [Insteon_PLM] DEBUG2: Sending obj=$front_hall; command=off; extra=00 incurred delay of 0.00 seconds; starting hop-count: 0 06/02/2014 15:42:45 [Insteon_PLM] DEBUG3: Sending PLM raw data: 0261a11300 06/02/2014 15:42:45 [Insteon_PLM] DEBUG4: PLM Command: (0261) all_link_send All-Link Group: a1 All-Link Command1: 13 All-Link Command2: 00 06/02/2014 15:42:45 [Insteon::BaseObject] $front_hall::set(off, web) 06/02/2014 15:42:45 [Insteon_PLM] DEBUG3: Received PLM raw data: 0261a1130006 06/02/2014 15:42:45 [Insteon_PLM] DEBUG4: PLM Command: (0261) all_link_send All-Link Group: a1 All-Link Command1: 13 All-Link Command2: 00 PLM Response: (06) ACK 06/02/2014 15:42:45 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$front_hall; command=off; extra=00 06/02/2014 15:42:45 [Insteon_PLM] DEBUG3: Received PLM raw data: 0250290cbe20d956e113ff 06/02/2014 15:42:45 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 29:0c:be To Address: 20:d9:56 Message Flags: e1 Message Type: (111) NAK of All-Link Cleanup Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 13ff Cmd 1: (13) ALL-Link Alias 1 Low Cmd 2: (ff) Group 06/02/2014 15:42:45 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:off; type:cleanup; group: 06/02/2014 15:42:45 [Insteon::BaseInterface] ERROR: received cleanup message from $l_2fl_hall_s1 that does not correspond to a valid PLM group. Corrupted message is assumed and will be skipped! Was group ff 06/02/2014 15:42:45 [Insteon_PLM] DEBUG3: Received PLM raw data: 02502541ae20d956e113ff 06/02/2014 15:42:45 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 25:41:ae To Address: 20:d9:56 Message Flags: e1 Message Type: (111) NAK of All-Link Cleanup Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 13ff Cmd 1: (13) ALL-Link Alias 1 Low Cmd 2: (ff) Group 06/02/2014 15:42:45 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:off; type:cleanup; group: 06/02/2014 15:42:45 [Insteon::BaseInterface] ERROR: received cleanup message from $l_2fl_hall_s2 that does not correspond to a valid PLM group. Corrupted message is assumed and will be skipped! Was group ff 06/02/2014 15:42:46 [Insteon_PLM] DEBUG3: Received PLM raw data: 025806025025527620d956e113ff 06/02/2014 15:42:46 [Insteon_PLM] DEBUG4: PLM Command: (0258) all_link_clean_status Status Byte: (06) ACK 06/02/2014 15:42:46 [Insteon_PLM] Received all-link cleanup success: obj=$front_hall; command=off; extra=00 06/02/2014 15:42:46 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 25:52:76 To Address: 20:d9:56 Message Flags: e1 Message Type: (111) NAK of All-Link Cleanup Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 13ff Cmd 1: (13) ALL-Link Alias 1 Low Cmd 2: (ff) Group 06/02/2014 15:42:46 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:off; type:cleanup; group: 06/02/2014 15:42:46 [Insteon::BaseInterface] DEBUG3: received cleanup message responding to PLM controller group: ff. Ignoring as this has already been processed 06/02/2014 15:42:46 update_PLM_scene_state(): called because $l_2fl_hall_s1 changed state to 'off'; attempting to update PLM scene $front_hall... ($l_2fl_hall_s1 was set by $front_hall. $ref_device->get_set_by() = Insteon::InterfaceController=HASH(0xb0cc904), scene = Insteon::InterfaceController=HASH(0xb0cc904) ). 06/02/2014 15:42:46 update_PLM_scene_state(): not updating state of PLM scene because scene was changed by us. 06/02/2014 15:42:46 update_PLM_scene_state(): called because $l_2fl_hall_s2 changed state to 'off'; attempting to update PLM scene $front_hall... ($l_2fl_hall_s2 was set by $front_hall. $ref_device->get_set_by() = Insteon::InterfaceController=HASH(0xb0cc904), scene = Insteon::InterfaceController=HASH(0xb0cc904) ). 06/02/2014 15:42:46 update_PLM_scene_state(): not updating state of PLM scene because scene was changed by us. 06/02/2014 15:42:46 update_PLM_scene_state(): called because $l_2fl_hall_m changed state to 'off'; attempting to update PLM scene $front_hall... ($l_2fl_hall_m was set by $front_hall. $ref_device->get_set_by() = Insteon::InterfaceController=HASH(0xb0cc904), scene = Insteon::InterfaceController=HASH(0xb0cc904) ). 06/02/2014 15:42:46 update_PLM_scene_state(): not updating state of PLM scene because scene was changed by us. The first NAK from 29.0C.BE - 2fl_hall_s1, I can't find anywhere a group FF shows up in the link tables. I re-ran a scan and sync of the link table on S1, it reports as clean, and nothing to do. And it had 0 failures in the stress test. Here's the logged link tables involved 06/02/2014 15:48:00 : Saving object states ... done 06/02/2014 15:48:00 Running: l 2fl hall m log links 06/02/2014 15:48:00 [Insteon::AllLinkDatabase] Link table for $l_2fl_hall_m health: good 06/02/2014 15:48:00 [Insteon::AllLinkDatabase] [0x0FF8] contlr(01) record to $PLM, (d1:03, d2:00, d3:01) 06/02/2014 15:48:00 [Insteon::AllLinkDatabase] [0x0fd0] rspndr(01) record to $PLM (a1): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:00 [Insteon::AllLinkDatabase] [0x0fd8] rspndr(01) record to $l_2fl_hall_s1 (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:00 [Insteon::AllLinkDatabase] [0x0fe0] rspndr(01) record to $l_2fl_hall_s2 (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:00 [Insteon::AllLinkDatabase] [0x0fe8] contlr(01) record to $l_2fl_hall_s1, (d1:03, d2:00, d3:01) 06/02/2014 15:48:00 [Insteon::AllLinkDatabase] [0x0ff0] contlr(01) record to $l_2fl_hall_s2, (d1:03, d2:00, d3:01) 06/02/2014 15:48:05 Running: l 2fl hall s2 log links 06/02/2014 15:48:05 [Insteon::AllLinkDatabase] Link table for $l_2fl_hall_s2 health: good 06/02/2014 15:48:05 [Insteon::AllLinkDatabase] [0x0FF8] rspndr(01) record to $l_2fl_hall_m (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:05 [Insteon::AllLinkDatabase] [0x0fd0] rspndr(01) record to $PLM (a1): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:05 [Insteon::AllLinkDatabase] [0x0fd8] rspndr(01) record to $l_2fl_hall_s1 (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:05 [Insteon::AllLinkDatabase] [0x0fe0] contlr(01) record to $l_2fl_hall_s1, (d1:03, d2:00, d3:01) 06/02/2014 15:48:05 [Insteon::AllLinkDatabase] [0x0fe8] contlr(01) record to $l_2fl_hall_m, (d1:03, d2:00, d3:01) 06/02/2014 15:48:05 [Insteon::AllLinkDatabase] [0x0ff0] contlr(01) record to $PLM, (d1:03, d2:00, d3:01) 06/02/2014 15:48:13 Running: l 2fl hall s1 log links 06/02/2014 15:48:13 [Insteon::AllLinkDatabase] Link table for $l_2fl_hall_s1 health: good 06/02/2014 15:48:13 [Insteon::AllLinkDatabase] [0x0FF8] rspndr(01) record to $l_2fl_hall_m (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:13 [Insteon::AllLinkDatabase] [0x0fd0] rspndr(01) record to $PLM (a1): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:13 [Insteon::AllLinkDatabase] [0x0fd8] contlr(01) record to $l_2fl_hall_m, (d1:03, d2:00, d3:01) 06/02/2014 15:48:13 [Insteon::AllLinkDatabase] [0x0fe0] contlr(01) record to $l_2fl_hall_s2, (d1:03, d2:00, d3:01) 06/02/2014 15:48:13 [Insteon::AllLinkDatabase] [0x0fe8] contlr(01) record to $PLM, (d1:03, d2:00, d3:01) 06/02/2014 15:48:13 [Insteon::AllLinkDatabase] [0x0ff0] rspndr(01) record to $l_2fl_hall_s2 (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 15:48:26 Running: PLM log links 06/02/2014 15:48:26 [Insteon::ALDB_PLM] Link table health: good 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_back_top_stairs (d1=01, d2=1f, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_top_stairs(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($back_hall (a4)) record to $l_back_top_stairs (d1=01, d2=00, d3=a4) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_under_counter (d1=01, d2=32, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_under_counter(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($kitchen_counter (a3)) record to $l_under_counter (d1=01, d2=00, d3=a3) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_back_porch (d1=01, d2=1f, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_porch(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($night_mode (a5)) record to $l_back_porch (d1=01, d2=00, d3=a5) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $io_driveway_camera (d1=07, d2=00, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $io_driveway_camera(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $io_back_door (d1=07, d2=00, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $io_back_door(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $io_back_door (d1=07, d2=00, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $io_garage_door (d1=07, d2=00, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $io_garage_door(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_kitchen_recess (d1=01, d2=1c, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_kitchen_recess(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_kitchen_u_hi(03) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_kitchen_u_low(04) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_kitchen_oh_s2(06) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($kitchen_overhead (a2)) record to $l_kitchen_recess (d1=01, d2=00, d3=a2) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_back_hall_bA (d1=02, d2=2c, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_hall_bA(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_back_hall_bA (d1=02, d2=2c, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_hall_bB(02) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_hall_bC(03) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_hall_bD(04) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_hall_bH(08) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($back_hall (a4)) record to $l_back_hall_bA (d1=01, d2=00, d3=a4) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($night_mode (a5)) record to $l_back_hall_bA (d1=01, d2=00, d3=a5) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_basement (d1=02, d2=2a, d3=42) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_basement(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_bath_fan_lt (d1=02, d2=2a, d3=42) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_bath_fan_lt(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_kitchen_window (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_kitchen_window(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_kitchen_window (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($night_mode (a5)) record to $l_kitchen_window (d1=01, d2=00, d3=a5) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_kitchen_oh_m (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_kitchen_oh_m(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_kitchen_oh_m (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($kitchen_overhead (a2)) record to $l_kitchen_oh_m (d1=01, d2=00, d3=a2) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_back_room (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_room(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_bath_vanity (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_bath_vanity(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_kitchen_oh_s1 (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_kitchen_oh_s1(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($kitchen_overhead (a2)) record to $l_kitchen_oh_s1 (d1=01, d2=00, d3=a2) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_back_entrance (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_back_entrance(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($back_hall (a4)) record to $l_back_entrance (d1=01, d2=00, d3=a4) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_2fl_hall_s2 (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_2fl_hall_s2(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($front_hall (a1)) record to $l_2fl_hall_s2 (d1=01, d2=00, d3=a1) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_2fl_hall_m (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_2fl_hall_m(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($front_hall (a1)) record to $l_2fl_hall_m (d1=01, d2=00, d3=a1) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_garage (d1=02, d2=2a, d3=43) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_garage(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_dining_room (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_dining_room(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_front_porch (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_front_porch(01) (d1=07, d2=00, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_front_porch (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($night_mode (a5)) record to $l_front_porch (d1=01, d2=00, d3=a5) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr(01) record to $l_2fl_hall_s1 (d1=01, d2=20, d3=41) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] responder record to $l_2fl_hall_s1(01) (d1=00, d2=00, d3=00) 06/02/2014 15:48:26 [Insteon::ALDB_PLM] cntlr($front_hall (a1)) record to $l_2fl_hall_s1 (d1=01, d2=00, d3=a1) George On 02/06/2014 01:07 PM, Kevin Robert Keegan wrote: > George, > > Eloy has given you good advice, we just discussed this exact issue a > few days ago. While maybe a little confusing, the solution will > achieve what you want. > > The issue exists because at the protocol level PLM Scenes are not > really objects that have a state. Instead, PLM Scenes are really just > announcements. The PLM tells all the devices what to do, but doesn't > check back later to see if the devices have varied from this instruction. > > Within MH we have tried to give the Scene a state like parameter, but > as you have found, it is not perfect. I have been considering changes > to MH that would make this process easier. > > Kevin > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > > > ________________________________________________________ > To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users > |
From: Kevin R. K. <ke...@kr...> - 2014-02-06 21:46:48
|
Strange, A NAK with FF in the Command 2 location generally means an I2CS linking error. More specifically, it means that the Sender's ID is not in the Link database of the receiving device. This error is odd though, because you say that you can directly control the on and off each individual device from MH. Can you run log_links on one of the misbehaving devices and send that? Presumably that is only a few lines. Kevin |
From: George C. <ge...@fe...> - 2014-02-06 21:52:09
|
Here are the two NAKs and the link tables for those two devices: 06/02/2014 15:42:45 [Insteon_PLM] DEBUG3: Received PLM raw data: 0250290cbe20d956e113ff 06/02/2014 15:42:45 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 29:0c:be To Address: 20:d9:56 Message Flags: e1 Message Type: (111) NAK of All-Link Cleanup Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 13ff Cmd 1: (13) ALL-Link Alias 1 Low Cmd 2: (ff) Group 06/02/2014 15:42:45 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:off; type:cleanup; group: 06/02/2014 15:42:45 [Insteon::BaseInterface] ERROR: received cleanup message from $l_2fl_hall_s1 that does not correspond to a valid PLM group. Corrupted message is assumed and will be skipped! Was group ff 06/02/2014 15:42:45 [Insteon_PLM] DEBUG3: Received PLM raw data: 02502541ae20d956e113ff 06/02/2014 15:42:45 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 25:41:ae To Address: 20:d9:56 Message Flags: e1 Message Type: (111) NAK of All-Link Cleanup Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 13ff Cmd 1: (13) ALL-Link Alias 1 Low Cmd 2: (ff) Group 06/02/2014 15:42:45 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:off; type:cleanup; group: 06/02/2014 15:42:45 [Insteon::BaseInterface] ERROR: received cleanup message from $l_2fl_hall_s2 that does not correspond to a valid PLM group. Corrupted message is assumed and will be skipped! Was group ff 06/02/2014 16:48:45 Running: l 2fl hall s1 log links 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] Link table for $l_2fl_hall_s1 health: good 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fbf] is empty 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fc7] contlr(01) record to $PLM, (d1:03, d2:1c, d3:01) 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fcf] is empty 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fd7] rspndr(01) record to $l_2fl_hall_s2 (01): onlevel=100% and ramp=0.1s (d3:01) 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fdf] contlr(01) record to $l_2fl_hall_s2, (d1:03, d2:1f, d3:01) 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fe7] rspndr(01) record to $l_2fl_hall_m (01): onlevel=100% and ramp=0.1s (d3:01) 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fef] contlr(01) record to $l_2fl_hall_m, (d1:03, d2:1f, d3:01) 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0ff7] is empty 06/02/2014 16:48:45 [Insteon::AllLinkDatabase] [0x0fff] rspndr(01) record to $PLM (00): onlevel=100% and ramp=0.1s (d3:01) 06/02/2014 16:48:49 Running: l 2fl hall s2 log links 06/02/2014 16:48:49 [Insteon::AllLinkDatabase] Link table for $l_2fl_hall_s2 health: good 06/02/2014 16:48:49 [Insteon::AllLinkDatabase] [0x0FF8] rspndr(01) record to $l_2fl_hall_m (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 16:48:49 [Insteon::AllLinkDatabase] [0x0fd0] rspndr(01) record to $PLM (a1): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 16:48:49 [Insteon::AllLinkDatabase] [0x0fd8] rspndr(01) record to $l_2fl_hall_s1 (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 16:48:49 [Insteon::AllLinkDatabase] [0x0fe0] contlr(01) record to $l_2fl_hall_s1, (d1:03, d2:00, d3:01) 06/02/2014 16:48:49 [Insteon::AllLinkDatabase] [0x0fe8] contlr(01) record to $l_2fl_hall_m, (d1:03, d2:00, d3:01) 06/02/2014 16:48:49 [Insteon::AllLinkDatabase] [0x0ff0] contlr(01) record to $PLM, (d1:03, d2:00, d3:01) 06/02/2014 16:49:00 : Saving object states ... done On 02/06/2014 04:46 PM, Kevin Robert Keegan wrote: > Strange, > > A NAK with FF in the Command 2 location generally means an I2CS > linking error. More specifically, it means that the Sender's ID is > not in the Link database of the receiving device. > > This error is odd though, because you say that you can directly > control the on and off each individual device from MH. > > Can you run log_links on one of the misbehaving devices and send that? > Presumably that is only a few lines. > > Kevin |
From: Kevin R. K. <ke...@kr...> - 2014-02-06 22:00:52
|
George, I don't see responder records for the front_hall scene (group A1) in there. What happens when you run the voice command Sync Links on the front_hall scene? Kevin |
From: George C. <ge...@fe...> - 2014-02-06 22:33:57
|
That was it ... partially. grep -i Adding /var/log/mh.log | tail -20 | grep -v hop\ count 06/02/2014 17:05:08 [Insteon::BaseController] Adding responder record to $l_2fl_hall_s1 from $front_hall 06/02/2014 17:05:08 [Insteon::AllLinkDatabase] DEBUG2: adding link record to $l_2fl_hall_s1 light level controlled by $PLM and group: A1 with on level: 100, ramp rate: 0.1, local load(data3): 00 That fixed s1, 2fl_hall_m is now messed up 06/02/2014 17:19:37 Running: l 2fl hall m log links 06/02/2014 17:19:37 [Insteon::AllLinkDatabase] Link table for $l_2fl_hall_m health: good 06/02/2014 17:19:37 [Insteon::AllLinkDatabase] [0x0FF8] contlr(01) record to $PLM, (d1:03, d2:00, d3:01) 06/02/2014 17:19:37 [Insteon::AllLinkDatabase] [0x0fd0] rspndr(01) record to $PLM (a1): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 17:19:37 [Insteon::AllLinkDatabase] [0x0fd8] rspndr(01) record to $l_2fl_hall_s1 (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 17:19:37 [Insteon::AllLinkDatabase] [0x0fe0] rspndr(01) record to $l_2fl_hall_s2 (01): onlevel=100% and ramp=0.1s (d3:00) 06/02/2014 17:19:37 [Insteon::AllLinkDatabase] [0x0fe8] contlr(01) record to $l_2fl_hall_s1, (d1:03, d2:00, d3:01) 06/02/2014 17:19:37 [Insteon::AllLinkDatabase] [0x0ff0] contlr(01) record to $l_2fl_hall_s2, (d1:03, d2:00, d3:01) The a1 group link is present, but the $PLM (00) link is missing, and now that switch seems to not respond to MH any more. Scan link table says it is healthy Sync links reports nothing to do. The other switches report 3 PLM links., (00), (a1), and (d1:03, d2:00, d3:01) Here is the nak now: 06/02/2014 17:28:25 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 25:52:76 To Address: 20:d9:56 Message Flags: e1 Message Type: (111) NAK of All-Link Cleanup Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 11ff Cmd 1: (11) ALL-Link Recall Cmd 2: (ff) Group I attempted a Link to Interface ... to see if that would fix the link table. It doesn't add the missing link. 06/02/2014 17:31:01 [Insteon::BaseObject] The link table for $l_2fl_hall_m is in sync. 06/02/2014 17:31:01 [Insteon::AllLinkDatabase] WARN: attempt to add link to $l_2fl_hall_m that already exists! object=$PLM, group=01, is_controller=1, data3=01 06/02/2014 17:31:01 [Insteon::ALDB_PLM] WARN: attempt to add link to PLM that already exists! deviceid=255276, group=01, is_controller=0, subaddress=00 06/02/2014 17:31:01 [Insteon::BaseInsteon] Link_To_Interface successfully completed for device $l_2fl_hall_m On 02/06/2014 05:00 PM, Kevin Robert Keegan wrote: > George, > > I don't see responder records for the front_hall scene (group A1) in > there. What happens when you run the voice command Sync Links on the > front_hall scene? > > Kevin > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > > > ________________________________________________________ > To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users > |
From: Kevin R. K. <ke...@kr...> - 2014-02-06 22:45:40
|
Well, I am officially stumped on that last one. I agree the PLM(00) responder link is missing, but it shouldn't be necessary. The link is added during the "link to interface" routine for i2cs objects. A device needs one responder link in its database before it will respond to commands from a device. The 00 is literally a throw away link as no such group exists or can exist. So MH creates it first during a psuedo-manual linking session, and then ignores it forever. I don't know how you got where you are, not your fault I have seen this happen to me too, but having the A1 responder link should be all you need. I have a number of devices lacking the 00 group that don't have any issues. All I can suggest is to wait a bit and see if it clears itself up. If not you can try turning the offending device on and off. Just pull the air gap. This will cause you to have to run scan links on that device again, but it might resolve it. Beyond that, my next step would be a factory reset of that device, sorry. |
From: George C. <ge...@fe...> - 2014-02-06 22:54:39
|
Hi Kevin, Thanks for the help, and no need to apologize. These 3 devices (well, plus one more) were on a branch circuit that had a large number of communication issues, so maybe something got corrupted. I'll break for supper, try the air gap first, and then if that doesn't resolve it try a factory reset. Definitely growing pains here :) One more quick question if you can put up with it. How do I intercept the off_fast command. Does it show up as a state_now value? I have not been able to catch it in my user code yet, but I've only tried it quickly. George On 02/06/2014 05:45 PM, Kevin Robert Keegan wrote: > Well, I am officially stumped on that last one. > > I agree the PLM(00) responder link is missing, but it shouldn't be > necessary. The link is added during the "link to interface" routine > for i2cs objects. A device needs one responder link in its database > before it will respond to commands from a device. The 00 is literally > a throw away link as no such group exists or can exist. So MH creates > it first during a psuedo-manual linking session, and then ignores it > forever. > > I don't know how you got where you are, not your fault I have seen > this happen to me too, but having the A1 responder link should be all > you need. I have a number of devices lacking the 00 group that don't > have any issues. > > All I can suggest is to wait a bit and see if it clears itself up. If > not you can try turning the offending device on and off. Just pull > the air gap. This will cause you to have to run scan links on that > device again, but it might resolve it. > > Beyond that, my next step would be a factory reset of that device, > sorry. |
From: Kevin R. K. <ke...@kr...> - 2014-02-06 23:07:52
|
On Thu, Feb 6, 2014 at 2:54 PM, George Clark <ge...@fe...> wrote: > One more quick question if you can put up with it. How do I intercept > the off_fast command. Does it show up as a state_now value? I have > not been able to catch it in my user code yet, but I've only tried it > quickly. > Yes, it shows up as the state of the device. So state_now or state will work. You should be able to see it in the device state log too. Kevin |
From: George C. <ge...@fe...> - 2014-02-09 14:50:03
|
Hi Kevin, I just let everything sit for a couple of days, no pulling of air gaps, no power failures, etc. This morning I ran a scan links on that switch and somehow the A1 link was gone and the 00 link was back. I reran sync links, nothing to do, reran sync links on scene A1, and it added it. And now everything is working. So, it's all working, I have no idea why, must be phase of the moon. Thanks for all the debugging help. George On 02/06/2014 05:45 PM, Kevin Robert Keegan wrote: > Well, I am officially stumped on that last one. > > I agree the PLM(00) responder link is missing, but it shouldn't be > necessary. The link is added during the "link to interface" routine > for i2cs objects. A device needs one responder link in its database > before it will respond to commands from a device. The 00 is literally > a throw away link as no such group exists or can exist. So MH creates > it first during a psuedo-manual linking session, and then ignores it > forever. > > I don't know how you got where you are, not your fault I have seen > this happen to me too, but having the A1 responder link should be all > you need. I have a number of devices lacking the 00 group that don't > have any issues. > > All I can suggest is to wait a bit and see if it clears itself up. If > not you can try turning the offending device on and off. Just pull > the air gap. This will cause you to have to run scan links on that > device again, but it might resolve it. > > Beyond that, my next step would be a factory reset of that device, > sorry. > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > > > ________________________________________________________ > To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users > |
From: Kevin R. K. <ke...@kr...> - 2014-02-10 19:35:17
|
On Sun, Feb 9, 2014 at 6:49 AM, George Clark <ge...@fe...> wrote: > So, it's all working, I have no idea why, must be phase of the moon. > Glad it is all working. I periodically get some of those moon oddities as well. |