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

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
> 

-- 
Rick Steeves
https://www.irelandbybicycle.com

It's all fun and games until someone ends up wearing a cone.


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