From: Marc M. <ma...@me...> - 2010-05-09 19:35:42
|
Shouldn't xpl_sensor items have some kind of timeout? Right now if I read an owfs value from an xpl broadcast and the sensor disappears, mh remembers the old value forever it seems. Unless others disagree, I'll see if I can add a 3mn timeout to sensor items with maybe a way to configure the timeout. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Greg S. <sa...@ir...> - 2010-05-09 21:47:09
|
I think there are two cases: 1) xPL service remains and the heartbeat still continues but the sensor being advertised via the service is removed or eliminated. 2) xPL service goes away (crashes, stopped, etc). In the second case the heartbeat supporting the xPL service would disappear and have to be timed out. It would be important that your MH timeout not be lease then the configured xPL heartbeat timer. Otherwise MH would remove the sensor and then it would be added again in the case of a missed packet. Ideally MH should use the heartbeat timeout by capturing the heartbeat xPL packets and resetting the timer each time it is received. If MH notices the sensor stopped being included in the xPL updates then it could immediately remove the value but this may not happen often enough to be worth doing. Thanks, Greg On May 9, 2010, at 1:35 PM, Marc MERLIN wrote: > Shouldn't xpl_sensor items have some kind of timeout? > Right now if I read an owfs value from an xpl broadcast and the sensor > disappears, mh remembers the old value forever it seems. > > Unless others disagree, I'll see if I can add a 3mn timeout to sensor items > with maybe a way to configure the timeout. |
From: Gregg L. <gr...@li...> - 2010-05-10 12:07:46
|
Greg Satz wrote: > I think there are two cases: > > 1) xPL service remains and the heartbeat still continues but the > sensor being advertised via the service is removed or eliminated. > > 2) xPL service goes away (crashes, stopped, etc). > > In the second case the heartbeat supporting the xPL service would > disappear and have to be timed out. It would be important that your MH > timeout not be lease then the configured xPL heartbeat timer. Otherwise > MH would remove the sensor and then it would be added again in the case > of a missed packet. > > Ideally MH should use the heartbeat timeout by capturing the > heartbeat xPL packets and resetting the timer each time it is > received. If MH notices the sensor stopped being included in the xPL > updates then it could immediately remove the value but this may not > happen often enough to be worth doing. You might possibly leverage some_xpl_item->dead_action(&my_dead_action) for #1 and some_xpl_item->($timeout, &my_missing_heartbeat_action, $is_repeat) for #2. Both of these (as documented in xPL_Items.pm) should be used with # noloop qualifiers if incorporated in user code. Possibly, they could be used in xPL_Sensor for behavior specific outcomes if desired. |
From: Marc M. <ma...@me...> - 2010-09-27 18:32:00
|
On Mon, May 10, 2010 at 08:07:37AM -0400, Gregg Liming wrote: > Greg Satz wrote: > > I think there are two cases: > > > > 1) xPL service remains and the heartbeat still continues but the > > sensor being advertised via the service is removed or eliminated. > > > > 2) xPL service goes away (crashes, stopped, etc). > > > > In the second case the heartbeat supporting the xPL service would > > disappear and have to be timed out. It would be important that your MH > > timeout not be lease then the configured xPL heartbeat timer. Otherwise > > MH would remove the sensor and then it would be added again in the case > > of a missed packet. > > > > Ideally MH should use the heartbeat timeout by capturing the > > heartbeat xPL packets and resetting the timer each time it is > > received. If MH notices the sensor stopped being included in the xPL > > updates then it could immediately remove the value but this may not > > happen often enough to be worth doing. > > You might possibly leverage some_xpl_item->dead_action(&my_dead_action) > for #1 and some_xpl_item->($timeout, &my_missing_heartbeat_action, > $is_repeat) for #2. Both of these (as documented in xPL_Items.pm) > should be used with # noloop qualifiers if incorporated in user code. > Possibly, they could be used in xPL_Sensor for behavior specific > outcomes if desired. It took me a while to get to this, but found some burried xPL_Item documentation in the module about my solutiong being manage_heartbeat_timeout and did this: if ($Startup) { # how often the slowest broadcasting of your XPL devices is sending data my $XPL_Timeout = 180; for my $object_name ( list_objects_by_type( 'xPL_Sensor' )) { next unless $object_name; my $object = &::get_object_by_name($object_name); next if (not $object); print_log ">>>>> $object_name is xPL Sensor, setting timeout to $XPL_Timeout sec"; $object->manage_heartbeat_timeout($XPL_Timeout, "print_log 'XPL: $object_name not reporting after $XPL_Timeout sec'",1); } } I'm actually going to suggest that people do this whenever they use xPL items Now, I have a loop that outputs this print Dumper($oregon_outhumidity2); and you'll see in the object below that I correctly have repeat' => 1, Because it's an object for which I'll never receive data, I do get: 27/09/2010 11:28:03 XPL: $oregon_outhumidity2 not reporting after 180 sec but then I have repeat' => 0, in m_timerHeartBeat Is m_timerHeartBeat repeat working for anyone? Before trigger: > $VAR1 = bless( { > 'm_timeoutHeartBeat' => 180, > 'state' => '', > 'states_nosubstate' => 1, > 'm_allow_empty_state' => 0, > '_device_id_key' => 'device', > 'category' => 'Other', > 'address' => 'iranger-rfx.*', > 'm_actionHeartBeat' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > 'm_state_now_msg_type' => 'unknown', > 'states_nomultistate' => 1, > 'm_appStatus' => 'unknown', > 'sensor_type' => 'humidity', > 'filename' => 'insteon_table', > 'state_monitor' => 'sensor.basic : current', > 'm_timerHeartBeat' => bless( { > 'period' => 180, > 'time' => 1285611848, > 'time_adjust' => 0, > 'state_log' => [ > '27/09/2010 11:24:08 180' > ], > 'pass_triggered' => 0, > 'action' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > 'expire_time' => '1285612028944.6', > 'repeat' => 1, > 'set_next_pass' => undef > }, 'Timer' ), > 'object_name' => '$oregon_outhumidity2', > 'class' => 'sensor.basic', > 'target_address' => '*', > '_device_id' => 'thgr919' >}, 'xPL_Sensor' ); After Trigger: > $VAR1 = bless( { > 'm_timeoutHeartBeat' => 180, > 'state' => '', > 'states_nosubstate' => 1, > 'm_allow_empty_state' => 0, > '_device_id_key' => 'device', > 'category' => 'Other', > 'address' => 'iranger-rfx.*', > 'm_actionHeartBeat' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > 'm_state_now_msg_type' => 'unknown', > 'states_nomultistate' => 1, > 'm_appStatus' => 'alive', > 'sensor_type' => 'humidity', > 'filename' => 'insteon_table', > 'state_monitor' => 'sensor.basic : current', > 'm_timerHeartBeat' => bless( { > 'period' => 180, > 'time' => 1285611903, > 'time_adjust' => 0, > 'time_pause' => 0, > 'state_log' => [ > '27/09/2010 11:25:03 180', > '27/09/2010 11:24:08 180' > ], > 'pass_triggered' => 3420, > 'action' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > 'expire_time' => '1285612083369.03', > 'repeat' => 0, > 'set_next_pass' => undef > }, 'Timer' ), > 'restore_data' => [], > 'object_name' => '$oregon_outhumidity2', > 'class' => 'sensor.basic', > 'target_address' => '*', > '_device_id' => 'thgr919' >}, 'xPL_Sensor' ); -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Marc M. <ma...@me...> - 2010-09-27 19:46:26
|
On Mon, Sep 27, 2010 at 11:31:51AM -0700, Marc MERLIN wrote: > On Mon, May 10, 2010 at 08:07:37AM -0400, Gregg Liming wrote: > > Greg Satz wrote: > > > I think there are two cases: > > > > > > 1) xPL service remains and the heartbeat still continues but the > > > sensor being advertised via the service is removed or eliminated. > > > > > > 2) xPL service goes away (crashes, stopped, etc). > > > > > > In the second case the heartbeat supporting the xPL service would > > > disappear and have to be timed out. It would be important that your MH > > > timeout not be lease then the configured xPL heartbeat timer. Otherwise > > > MH would remove the sensor and then it would be added again in the case > > > of a missed packet. > > > > > > Ideally MH should use the heartbeat timeout by capturing the > > > heartbeat xPL packets and resetting the timer each time it is > > > received. If MH notices the sensor stopped being included in the xPL > > > updates then it could immediately remove the value but this may not > > > happen often enough to be worth doing. > > > > You might possibly leverage some_xpl_item->dead_action(&my_dead_action) > > for #1 and some_xpl_item->($timeout, &my_missing_heartbeat_action, > > $is_repeat) for #2. Both of these (as documented in xPL_Items.pm) > > should be used with # noloop qualifiers if incorporated in user code. > > Possibly, they could be used in xPL_Sensor for behavior specific > > outcomes if desired. > > It took me a while to get to this, but found some burried xPL_Item > documentation in the module about my solutiong being > manage_heartbeat_timeout and did this: > > if ($Startup) > { > # how often the slowest broadcasting of your XPL devices is sending data > my $XPL_Timeout = 180; > > for my $object_name ( list_objects_by_type( 'xPL_Sensor' )) > { > next unless $object_name; > my $object = &::get_object_by_name($object_name); > next if (not $object); > > print_log ">>>>> $object_name is xPL Sensor, setting timeout to $XPL_Timeout sec"; > $object->manage_heartbeat_timeout($XPL_Timeout, "print_log 'XPL: $object_name not reporting after $XPL_Timeout sec'",1); Mmmh, manage_heartbeat_timeout actually doesn't seem to work at all, it gets triggered even for variables that get updated regularly. Or is it that heartbeat isn't reset by value updates for xPL Sensors? I notice that this gets updated: set_time' => 1285616563, While that, in m_timerHeartBeat, never changes: 'expire_time' => '1285616607098.28', That said, it looks like repeat not working is yet a separate problem. Marc > } > } > > I'm actually going to suggest that people do this whenever they use xPL items > > Now, I have a loop that outputs this > print Dumper($oregon_outhumidity2); > and you'll see in the object below that I correctly have > repeat' => 1, > > Because it's an object for which I'll never receive data, I do get: > 27/09/2010 11:28:03 XPL: $oregon_outhumidity2 not reporting after 180 sec > > but then I have > repeat' => 0, > in m_timerHeartBeat > > Is m_timerHeartBeat repeat working for anyone? > > Before trigger: > > $VAR1 = bless( { > > 'm_timeoutHeartBeat' => 180, > > 'state' => '', > > 'states_nosubstate' => 1, > > 'm_allow_empty_state' => 0, > > '_device_id_key' => 'device', > > 'category' => 'Other', > > 'address' => 'iranger-rfx.*', > > 'm_actionHeartBeat' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'm_state_now_msg_type' => 'unknown', > > 'states_nomultistate' => 1, > > 'm_appStatus' => 'unknown', > > 'sensor_type' => 'humidity', > > 'filename' => 'insteon_table', > > 'state_monitor' => 'sensor.basic : current', > > 'm_timerHeartBeat' => bless( { > > 'period' => 180, > > 'time' => 1285611848, > > 'time_adjust' => 0, > > 'state_log' => [ > > '27/09/2010 11:24:08 180' > > ], > > 'pass_triggered' => 0, > > 'action' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'expire_time' => '1285612028944.6', > > 'repeat' => 1, > > 'set_next_pass' => undef > > }, 'Timer' ), > > 'object_name' => '$oregon_outhumidity2', > > 'class' => 'sensor.basic', > > 'target_address' => '*', > > '_device_id' => 'thgr919' > >}, 'xPL_Sensor' ); > > After Trigger: > > $VAR1 = bless( { > > 'm_timeoutHeartBeat' => 180, > > 'state' => '', > > 'states_nosubstate' => 1, > > 'm_allow_empty_state' => 0, > > '_device_id_key' => 'device', > > 'category' => 'Other', > > 'address' => 'iranger-rfx.*', > > 'm_actionHeartBeat' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'm_state_now_msg_type' => 'unknown', > > 'states_nomultistate' => 1, > > 'm_appStatus' => 'alive', > > 'sensor_type' => 'humidity', > > 'filename' => 'insteon_table', > > 'state_monitor' => 'sensor.basic : current', > > 'm_timerHeartBeat' => bless( { > > 'period' => 180, > > 'time' => 1285611903, > > 'time_adjust' => 0, > > 'time_pause' => 0, > > 'state_log' => [ > > '27/09/2010 11:25:03 180', > > '27/09/2010 11:24:08 180' > > ], > > 'pass_triggered' => 3420, > > 'action' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'expire_time' => '1285612083369.03', > > 'repeat' => 0, > > 'set_next_pass' => undef > > }, 'Timer' ), > > 'restore_data' => [], > > 'object_name' => '$oregon_outhumidity2', > > 'class' => 'sensor.basic', > > 'target_address' => '*', > > '_device_id' => 'thgr919' > >}, 'xPL_Sensor' ); > > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems & security .... > .... what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: John <jo...@to...> - 2012-11-25 18:09:26
|
I was thinking I would use Misterhouse to monitor for xPL heartbeat from a device and to send an alert if it does not receive one in a predefined time period. I don't see anything in the xPL section of the mh Wiki. Is there a standard way to implement this with mh? Thanks, John |
From: Lieven H. <li...@li...> - 2012-11-25 18:46:23
|
Hi John, I have been experimenting with this code in the past. Note: currently it is not enabled in my config, so I'm not exactly sure if it still works. #if ($Startup) { # my $xpl_timeout = 300; # # my @objects = (list_objects_by_type('xPL_Squeezebox'), list_objects_by_type('xPL_Sensor')); # # foreach my $object_name (@objects) { # next unless $object_name; # my $object = &::get_object_by_name($object_name); # next if (not $object); # print_log "xPL item '$object_name' will be monitored. MH will report if it is not active in $xpl_timeout seconds"; # #$object->manage_heartbeat_timeout($xpl_timeout, &report_xpl_offline($object_name), 1); # } #} The report function was a sub that sent an email. Kind regards, Lieven. Op 25-nov.-2012, om 19:09 heeft John <jo...@to...> het volgende geschreven: > I was thinking I would use Misterhouse to monitor for xPL heartbeat from > a device and to send an alert if it does not receive one in a predefined > time period. I don't see anything in the xPL section of the mh Wiki. > Is there a standard way to implement this with mh? > > Thanks, > > John > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: John <jo...@to...> - 2012-11-27 02:02:44
|
On 11/25/12 12:46, Lieven Hollevoet wrote: > Hi John, > > I have been experimenting with this code in the past. Note: currently it is not enabled in my config, so I'm not exactly sure if it still works. > > #if ($Startup) { > # my $xpl_timeout = 300; > # > # my @objects = (list_objects_by_type('xPL_Squeezebox'), list_objects_by_type('xPL_Sensor')); > # > # foreach my $object_name (@objects) { > # next unless $object_name; > # my $object = &::get_object_by_name($object_name); > # next if (not $object); > # print_log "xPL item '$object_name' will be monitored. MH will report if it is not active in $xpl_timeout seconds"; > # #$object->manage_heartbeat_timeout($xpl_timeout, &report_xpl_offline($object_name), 1); > # } > #} Apparently you need to pass a sub reference and arguments also cause problems. This will get the sub to be properly recognized: $object->manage_heartbeat_timeout($xpl_timeout, \&report_xpl_offline, 1); If you don't pass reference or if there is a parameter, then a scalar value of "1" is received by the sub. However, as Marc alludes to and I confirm: there is a fundamental issue that manage_heartbeat_timeout is broken. If this is working for anyone I would be interesting in hearing. I think I will try and get my head around what what should happen and go from there. If anyone has input on this let me know. John |
From: Marc M. <ma...@me...> - 2012-11-25 18:18:22
|
On Sun, Nov 25, 2012 at 12:09:16PM -0600, John wrote: > I was thinking I would use Misterhouse to monitor for xPL heartbeat from > a device and to send an alert if it does not receive one in a predefined > time period. I don't see anything in the xPL section of the mh Wiki. > Is there a standard way to implement this with mh? Back when I tried to make this work, it didn't quite work for me. See a thread from 2.5 years ago, attached below. It can probably be made to work, but it wasn't important enough for me at the time, so I moved to other things. Hopefully the info below helps. Marc On Sun, May 09, 2010 at 03:46:48PM -0600, Greg Satz wrote: > I think there are two cases: > > 1) xPL service remains and the heartbeat still continues but the sensor being advertised via the service is removed or eliminated. > > 2) xPL service goes away (crashes, stopped, etc). > > In the second case the heartbeat supporting the xPL service would disappear and have to be timed out. It would be important that your MH timeout not be lease then the configured xPL heartbeat timer. Otherwise MH would remove the sensor and then it would be added again in the case of a missed packet. > > Ideally MH should use the heartbeat timeout by capturing the heartbeat xPL packets and resetting the timer each time it is received. If MH notices the sensor stopped being included in the xPL updates then it could immediately remove the value but this may not happen often enough to be worth doing. > > Thanks, > Greg On Mon, May 10, 2010 at 08:07:37AM -0400, Gregg Liming wrote: > Greg Satz wrote: > > I think there are two cases: > > > > 1) xPL service remains and the heartbeat still continues but the > > sensor being advertised via the service is removed or eliminated. > > > > 2) xPL service goes away (crashes, stopped, etc). > > > > In the second case the heartbeat supporting the xPL service would > > disappear and have to be timed out. It would be important that your MH > > timeout not be lease then the configured xPL heartbeat timer. Otherwise > > MH would remove the sensor and then it would be added again in the case > > of a missed packet. > > > > Ideally MH should use the heartbeat timeout by capturing the > > heartbeat xPL packets and resetting the timer each time it is > > received. If MH notices the sensor stopped being included in the xPL > > updates then it could immediately remove the value but this may not > > happen often enough to be worth doing. > > You might possibly leverage some_xpl_item->dead_action(&my_dead_action) > for #1 and some_xpl_item->($timeout, &my_missing_heartbeat_action, > $is_repeat) for #2. Both of these (as documented in xPL_Items.pm) > should be used with # noloop qualifiers if incorporated in user code. > Possibly, they could be used in xPL_Sensor for behavior specific > outcomes if desired. > > > ------------------------------------------------------------------------------ > > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > On Mon, Sep 27, 2010 at 11:31:51AM -0700, Marc MERLIN wrote: > On Mon, May 10, 2010 at 08:07:37AM -0400, Gregg Liming wrote: > > Greg Satz wrote: > > > I think there are two cases: > > > > > > 1) xPL service remains and the heartbeat still continues but the > > > sensor being advertised via the service is removed or eliminated. > > > > > > 2) xPL service goes away (crashes, stopped, etc). > > > > > > In the second case the heartbeat supporting the xPL service would > > > disappear and have to be timed out. It would be important that your MH > > > timeout not be lease then the configured xPL heartbeat timer. Otherwise > > > MH would remove the sensor and then it would be added again in the case > > > of a missed packet. > > > > > > Ideally MH should use the heartbeat timeout by capturing the > > > heartbeat xPL packets and resetting the timer each time it is > > > received. If MH notices the sensor stopped being included in the xPL > > > updates then it could immediately remove the value but this may not > > > happen often enough to be worth doing. > > > > You might possibly leverage some_xpl_item->dead_action(&my_dead_action) > > for #1 and some_xpl_item->($timeout, &my_missing_heartbeat_action, > > $is_repeat) for #2. Both of these (as documented in xPL_Items.pm) > > should be used with # noloop qualifiers if incorporated in user code. > > Possibly, they could be used in xPL_Sensor for behavior specific > > outcomes if desired. > > It took me a while to get to this, but found some burried xPL_Item > documentation in the module about my solutiong being > manage_heartbeat_timeout and did this: > > if ($Startup) > { > # how often the slowest broadcasting of your XPL devices is sending data > my $XPL_Timeout = 180; > > for my $object_name ( list_objects_by_type( 'xPL_Sensor' )) > { > next unless $object_name; > my $object = &::get_object_by_name($object_name); > next if (not $object); > > print_log ">>>>> $object_name is xPL Sensor, setting timeout to $XPL_Timeout sec"; > $object->manage_heartbeat_timeout($XPL_Timeout, "print_log 'XPL: $object_name not reporting after $XPL_Timeout sec'",1); > } > } > > I'm actually going to suggest that people do this whenever they use xPL items > > Now, I have a loop that outputs this > print Dumper($oregon_outhumidity2); > and you'll see in the object below that I correctly have > repeat' => 1, > > Because it's an object for which I'll never receive data, I do get: > 27/09/2010 11:28:03 XPL: $oregon_outhumidity2 not reporting after 180 sec > > but then I have > repeat' => 0, > in m_timerHeartBeat > > Is m_timerHeartBeat repeat working for anyone? > > Before trigger: > > $VAR1 = bless( { > > 'm_timeoutHeartBeat' => 180, > > 'state' => '', > > 'states_nosubstate' => 1, > > 'm_allow_empty_state' => 0, > > '_device_id_key' => 'device', > > 'category' => 'Other', > > 'address' => 'iranger-rfx.*', > > 'm_actionHeartBeat' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'm_state_now_msg_type' => 'unknown', > > 'states_nomultistate' => 1, > > 'm_appStatus' => 'unknown', > > 'sensor_type' => 'humidity', > > 'filename' => 'insteon_table', > > 'state_monitor' => 'sensor.basic : current', > > 'm_timerHeartBeat' => bless( { > > 'period' => 180, > > 'time' => 1285611848, > > 'time_adjust' => 0, > > 'state_log' => [ > > '27/09/2010 11:24:08 180' > > ], > > 'pass_triggered' => 0, > > 'action' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'expire_time' => '1285612028944.6', > > 'repeat' => 1, > > 'set_next_pass' => undef > > }, 'Timer' ), > > 'object_name' => '$oregon_outhumidity2', > > 'class' => 'sensor.basic', > > 'target_address' => '*', > > '_device_id' => 'thgr919' > >}, 'xPL_Sensor' ); > > After Trigger: > > $VAR1 = bless( { > > 'm_timeoutHeartBeat' => 180, > > 'state' => '', > > 'states_nosubstate' => 1, > > 'm_allow_empty_state' => 0, > > '_device_id_key' => 'device', > > 'category' => 'Other', > > 'address' => 'iranger-rfx.*', > > 'm_actionHeartBeat' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'm_state_now_msg_type' => 'unknown', > > 'states_nomultistate' => 1, > > 'm_appStatus' => 'alive', > > 'sensor_type' => 'humidity', > > 'filename' => 'insteon_table', > > 'state_monitor' => 'sensor.basic : current', > > 'm_timerHeartBeat' => bless( { > > 'period' => 180, > > 'time' => 1285611903, > > 'time_adjust' => 0, > > 'time_pause' => 0, > > 'state_log' => [ > > '27/09/2010 11:25:03 180', > > '27/09/2010 11:24:08 180' > > ], > > 'pass_triggered' => 3420, > > 'action' => 'print_log \'XPL: $oregon_outhumidity2 not reporting after 180 sec\'', > > 'expire_time' => '1285612083369.03', > > 'repeat' => 0, > > 'set_next_pass' => undef > > }, 'Timer' ), > > 'restore_data' => [], > > 'object_name' => '$oregon_outhumidity2', > > 'class' => 'sensor.basic', > > 'target_address' => '*', > > '_device_id' => 'thgr919' > >}, 'xPL_Sensor' ); > On Mon, Sep 27, 2010 at 12:46:07PM -0700, Marc MERLIN wrote: > On Mon, Sep 27, 2010 at 11:31:51AM -0700, Marc MERLIN wrote: > > On Mon, May 10, 2010 at 08:07:37AM -0400, Gregg Liming wrote: > > > Greg Satz wrote: > > > > I think there are two cases: > > > > > > > > 1) xPL service remains and the heartbeat still continues but the > > > > sensor being advertised via the service is removed or eliminated. > > > > > > > > 2) xPL service goes away (crashes, stopped, etc). > > > > > > > > In the second case the heartbeat supporting the xPL service would > > > > disappear and have to be timed out. It would be important that your MH > > > > timeout not be lease then the configured xPL heartbeat timer. Otherwise > > > > MH would remove the sensor and then it would be added again in the case > > > > of a missed packet. > > > > > > > > Ideally MH should use the heartbeat timeout by capturing the > > > > heartbeat xPL packets and resetting the timer each time it is > > > > received. If MH notices the sensor stopped being included in the xPL > > > > updates then it could immediately remove the value but this may not > > > > happen often enough to be worth doing. > > > > > > You might possibly leverage some_xpl_item->dead_action(&my_dead_action) > > > for #1 and some_xpl_item->($timeout, &my_missing_heartbeat_action, > > > $is_repeat) for #2. Both of these (as documented in xPL_Items.pm) > > > should be used with # noloop qualifiers if incorporated in user code. > > > Possibly, they could be used in xPL_Sensor for behavior specific > > > outcomes if desired. > > > > It took me a while to get to this, but found some burried xPL_Item > > documentation in the module about my solutiong being > > manage_heartbeat_timeout and did this: > > > > if ($Startup) > > { > > # how often the slowest broadcasting of your XPL devices is sending data > > my $XPL_Timeout = 180; > > > > for my $object_name ( list_objects_by_type( 'xPL_Sensor' )) > > { > > next unless $object_name; > > my $object = &::get_object_by_name($object_name); > > next if (not $object); > > > > print_log ">>>>> $object_name is xPL Sensor, setting timeout to $XPL_Timeout sec"; > > $object->manage_heartbeat_timeout($XPL_Timeout, "print_log 'XPL: $object_name not reporting after $XPL_Timeout sec'",1); > > Mmmh, manage_heartbeat_timeout actually doesn't seem to work at all, it gets > triggered even for variables that get updated regularly. > > Or is it that heartbeat isn't reset by value updates for xPL Sensors? > > I notice that this gets updated: set_time' => 1285616563, > While that, in m_timerHeartBeat, never changes: 'expire_time' => '1285616607098.28', > > That said, it looks like repeat not working is yet a separate problem. > > Marc On Mon, Oct 04, 2010 at 10:22:11AM -0400, Gregg Liming wrote: > Hi Marc, > > Yes, it probably is me since I implemented those features. I was trying > to remember (and did look briefly) whether it had ever been tested. I'm > guessing not. > > Unfortunately, some of the recent insteon branch issues probably take > priority. So, if anyone is willing to take a look, I certainly don't > object. Otherwise, I'll try to work it in. > > Gregg -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: John <jo...@to...> - 2012-11-28 01:26:25
|
On 11/25/12 12:18, Marc MERLIN wrote: [snip] >>> print_log ">>>>> $object_name is xPL Sensor, setting timeout to $XPL_Timeout sec"; >>> $object->manage_heartbeat_timeout($XPL_Timeout, "print_log 'XPL: $object_name not reporting after $XPL_Timeout sec'",1); [snip] >> That said, it looks like repeat not working is yet a separate problem. [snip] Looks like you need to pass "-1" for repeat and not a "1"! Yes, "1" just does it once. I created a pull request to update the docs (in .pm). I can now move on to other aspects of getting heartbeat working... John |
From: Lieven H. <li...@li...> - 2012-11-28 08:46:12
|
Hi John, Op 28-nov.-2012, om 02:26 heeft John <jo...@to...> het volgende geschreven: > > I created a pull request to update the docs (in .pm). > Merged! > I can now move on to other aspects of getting heartbeat working… > I'm interested in the results. Kind regards, Lieven. |
From: John <jo...@to...> - 2012-11-28 13:34:49
|
On 11/28/12 02:45, Lieven Hollevoet wrote: > Hi John, > > Op 28-nov.-2012, om 02:26 heeft John <jo...@to...> het volgende geschreven: > >> >> I created a pull request to update the docs (in .pm). >> > > Merged! Thanks! My first "code" contribution to an open source project! :) >> I can now move on to other aspects of getting heartbeat working… >> > I'm interested in the results. Actually, for me it looks like it all works as it should (initial results). The xPL generating device is of my own creation and I am doing only subset of heartbeat protocal (just sending hbeat.app message at regular intervals. I might look at adding two way validation. Also, in a seperate message your commented out code look like this: $object->manage_heartbeat_timeout($xpl_timeout, &report_xpl_offline($object_name), 1); You will want to try something like this: $object->manage_heartbeat_timeout($xpl_timeout, sub { &report_xpl_offline($object_name) }, -1); There may be other ways of passing that arg in a code reference or maybe there is mh bug which stops what you had from working. However, the above worked for me. I haven't reviewed all the details of the thread Marc provided to see if there are other issues. John |
From: Lieven H. <li...@li...> - 2012-11-28 21:32:40
|
Hi John, Thanks, I will try it out this weekend. Lieven Op 28 nov. 2012 14:35 schreef "John" <jo...@to...> het volgende: > On 11/28/12 02:45, Lieven Hollevoet wrote: > > Hi John, > > > > Op 28-nov.-2012, om 02:26 heeft John <jo...@to...> het volgende > geschreven: > > > >> > >> I created a pull request to update the docs (in .pm). > >> > > > > Merged! > > Thanks! My first "code" contribution to an open source project! :) > > >> I can now move on to other aspects of getting heartbeat working… > >> > > I'm interested in the results. > > Actually, for me it looks like it all works as it should (initial results). > > The xPL generating device is of my own creation and I am doing only > subset of heartbeat protocal (just sending hbeat.app message at regular > intervals. I might look at adding two way validation. > > Also, in a seperate message your commented out code look like this: > > $object->manage_heartbeat_timeout($xpl_timeout, > &report_xpl_offline($object_name), 1); > > You will want to try something like this: > > $object->manage_heartbeat_timeout($xpl_timeout, sub { > &report_xpl_offline($object_name) }, -1); > > There may be other ways of passing that arg in a code reference or maybe > there is mh bug which stops what you had from working. However, the > above worked for me. > > I haven't reviewed all the details of the thread Marc provided to see if > there are other issues. > > John > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |