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

Update: I installed that commit on my system and it works great. Solves 
some of my other hacky log handling solutions with a much more 
simple/elegant version.

Thanks!

Jeff

On 2021-01-14 4:46 a.m., Giles Godart-Brown wrote:
>
> 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
>


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