Re: [mh] Your help re Genericising Error and log handling

Brian,

Of course, existing print_log will remain untouched and will work 
exactly as it has.  The new handle_log sub would be a more capable 
replacement that anyone could use if desired.

Having thought about it a bit more while writing this, I think it might 
be even better to make handle_log a drop in replacement for print_log -- 
meaning it should be possible to global search/replace print_log with 
handle_log and then have the log $data written to the print log like usual.

Anyway, the main benefit of handle_log is to provide a standard way for 
modules to log information while allowing user control over what happens 
when log of a certain severity are received. That way, for example, a 
user can get a email to let them know something of adequate severity 
happens.

Thinking about your other idea, I don't think we need a directory 
approach necessarily, but having something flexible like user 
configurable REs for parsing specific events would be pretty slick.

For example, if handle_logs was called with a single parameter (like 
print_log), and thus no severity, then an RE to search for some keywords 
might make it possible to handle legacy/user defined events.  The user 
could always code these into the "handy_utilities.pl" -- or wherever the 
code went.  Ex:

if (!defined ($severity) && $message =~ /Insteon.*WARN/) {
     $severity = "ALERT";
}

But it might be nicer to have something like an ini file setting.  Ex:

log_alert=Insteon.*WARN|Foyer_Security_MS.*set|WARNING.*temperature

which would send an alert whenever one of those three conditions were found

Thoughts?

Jeff


On 2021-01-12 11:56 a.m., Brian M wrote:
> Giles,
>
> First, thank you for all the attention you and others are recently 
> giving to MH.
>
> I'm not sure I completely understand your proposal, but I'm certainly 
> in favor of the concept. If I have any thoughts to offer, it's in 
> regards to the implementation...
>
> First, I would want existing code that uses print_log to continue to 
> work but use your new structure. So I would change the internal 
> function of print_log to allow (but not require) calling out to user 
> code. Otherwise you wind up having two logging calls with different 
> results and split logging. "This way madness lies." Perhaps that is 
> what you were suggesting in your final question regarding print_log.
>
> Next, I'm a fan of the "designated-directory" approach, such as was 
> used in the old /etc/init/rc5.d boot initialization system (along with 
> many others). What would you think of creating a reserved directory 
> name in local/code (may be "local/code/print_log")? If that directory 
> exists and if there are files in in, print_log calls them in 
> alphabetical order, providing the calling parameters you've already 
> described. That way, specific severities, categories, or whatever 
> could have their own log handlers code instead of needing to having 
> everything in one file. I might one one per device ("oh, xyz just went 
> offline - better restart something"), whereas you might have a file 
> for each severity level ("warning = send an e-mail; critical = send a 
> text too"). And, of course, if the user does nothing with this 
> directory, print_log just does it's ordinary job like it does now. So, 
> no transition at all, just a new capability for those that want to 
> take advantage of it.
>
> I hope you find something useful in these musings. Please keep up the 
> good work.
>
> -Brian M
>
> On 1/12/21 8:23 AM, Giles Godart-Brown wrote:
>>
>> Jeff and I have been wondering about creating a more generic error 
>> handling system that would allow implementers to easily modify what 
>> happens when an error or log entry occurs, for example send emails or 
>> SMS. Here is a summary of what we are thinking;
>>
>> 1) We start with the MisterHouse syslog severity levels viz;
>>
>>   * EMERGENCY
>>   * ALERT
>>   * CRITICAL
>>   * ERROR
>>   * WARNING
>>   * NOTICE
>>   * INFORMATIONAL
>>   * DEBUG
>>
>> 2) We create a new handle_log routine that is passed a severity as 
>> above, a category e.g. "in my routine" and a message, something like
>>
>> <snip>
>>
>> sub handle_log {
>>     my ($message, $severity, $category ) = @_;
>>     if ($severity eq "EMERGENCY") {
>>         # put your code to handle Emergencies here e.g. send email
>>     } elsif {
>>     if ($severity eq "ALERT") {
>>         # put your code to handle Alerts here e.g. send a send Growl 
>> and SMS
>>     } elsif {
>>     if ($severity eq "CRITICAL") {
>>
>>         # put your code to handle Critical errors here e.g. send email
>>     } elsif {
>>
>>     if ($severity eq "ERROR") {
>>         # put your code to handle Error here e.g. email
>>     } elsif {
>>     if ($severity eq "WARNING") {
>>         # put your code to handle Warnings here e.g. let it drop to 
>> print_log
>>     } elsif {
>>     if ($severity eq "NOTICE") {
>>         # put your code to handle Notices here
>>     } elsif {
>>     if ($severity eq "INFORMATIONAL") {
>>         # put your code to handle Informational messages here
>>     } elsif {
>>     if ($severity eq "DEBUG") {
>>         # put your code to handle Debug messages here
>>     }
>>
>>     # catch-all to at least put it to the print log
>>
>>     print_log("$Severity: , $category - $message");
>>
>> }
>>
>> </snip>
>>
>> I suggest we put this in handy_utilities.pl so people aren't messing 
>> with mh.pl, but maybe there is a better place, like perhaps its own .pm
>>
>> 3) Modules should then just call handle_log directly, or, we could 
>> parameterise this further by having an mh.ini parameter like;
>> <snip>
>>
>> Tasmota_HTTP_Send_Fail_Severity = ALERT
>>
>> </snip>
>>
>> And in the module something like;
>>
>> <snip>
>>
>> my $send_fail_sev = $::config_parms{Tasmota_HTTP_Send_Fail_Severity};
>> if (!defined $send_fail_sev) {
>>     $send_fail_sev = "ERROR";
>> }
>> # when the http fails
>> handle_log("Failed to send to $item_name", $send_fail_sev, "HTTP send ");
>>
>> </snip>
>>
>> Could we drop this in instead of print_log?
>>
>> Have we missed anything?
>>
>> Giles
>>
>>
>>
>>
>> ________________________________________________________
>> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>
>
>
> ________________________________________________________
> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>


________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users