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

Thanks Rick,

I am always reluctant to modify existing code, but maybe if the 
modification was to rename the current "print_log" sub to something like 
"print_log_simple" and then make a new "print_log" that just ran:

sub print_log {
     &handle_log(@_);
     &print_log_simple(@_);
}

Then there would be little likelihood of breaking anything that works 
currently.

I am now less inclined to put parameters into an ini since a user 
function is more flexible and easier to code, but I suspect that is 
mainly due to laziness!  I will leave the implementation up to Giles.

Jeff


On 2021-01-12 2:00 p.m., Rick Steeves wrote:
> Might it not make more sense to modify print_log, so that, as is, it 
> keeps working as expected, but in any case that print_log was called 
> with more than one parameter then new things happened?
>
> That makes all the existing code keep working, but new code (or people 
> modifying existing code) could just add parameters.
>
> If you were going to do a search/replace for print_log, you're still 
> going to have to find all the cases of it and manually adjust them for 
> what you want to have happen.
>
> That would avoid creating a new function, have it keep working as-is 
> in all the existing code, and let it be adjusted on a case-by-case basis.
>
>
> I do like the event responses being defined in mh.private.ini. so in 
> mh.private.ini something like
> event.critical=SMS|email|print|sound
> event.error=email|print
> event.info=print
> event.debug=null
>
> event.email = "[email protected]";
> event.sms = "555.555.1212";
> event.sound ="dangerwillrobinson.wav";
>
> IF nothing is defined, then print_log would also just work as normal. 
> Or if event.SMS was null, then it would be ignored.
>
>
>
> rick
>
>
> On 1/12/2021 1:10 PM, Jeff Siddall via misterhouse-users wrote:
>> 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
>>
>


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