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

Thanks for everyone's contributions, I've tried to accommodate them all 
where possible (apologies if I missed anything),  have minimum changes 
and maintain backwards compatibility.

I've now created pull request  #820 which includes the change to mh and 
a sample customised print_log_private. I've also updated the docs on the 
wiki.

Happy logging

Giles

On 12/01/2021 16:56, 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