Feature request: adjust log message for log_change item attribute

[onkelandy]

The plugin operationlog allows some mapping of values to be written in a separate log file. As the logging.yaml is very powerful almost all functions of the plugin are obsolete. Anyhow, some options for the log_change attribute would be nice.

As discussed on Gitter I suggest something like this:

log_text: f"{'Person A' if value == 1 else 'Person B' if value == 2 else 'Person C'} ist zuhause"
log_level: "DEBUG" if value <=2 else "ERROR" if value > 2

Of course it's also possible to refer to a helper item for the log text like this (as suggested by msinn) though I think the direct solution is easier and cleaner. Maybe I also misunderstood the idea with the helper item?

log_text_item: .item_logtext.property.value
log_level: "DEBUG" if value <=2 else "ERROR" if value > 2

item_logtext:
    type: str
    eval: f"{'Person A' if value == 1 else 'Person B' if value == 2 else 'Person C'} ist zuhause"

I'm willing to test some code as soon as it's clear how to proceed with the extra attributes.

[bmxp]

The logs in the old fashioned way can be displayed in SmartVISU which is used by several users. As long as we can keep this functionality up, please go ahead and prepare some test code after release 1.8
We should however keep the core simple and not build too much into it because it might have serious side effects...

[onkelandy]

Can do that but I'm still unsure how to provide that feature. Two additional attributes is not a good solution. We could implement that as a list maybe? List entry 1 = item, entry 2 = text, entry 3 = debug eval. Though that's not very intuitive I think. A dict is even worse imho.

[Morg42]

A dict seems more understandable than a list surely. But I agree that complex datatypes are not the method of choice.
I wouldn't put stress on dynamic log levels; if you want, you can always manually set the level - for the log file, or for the item logger - and even change that on the fly.
The log message might be a nice addition, though I don't see any use for it right now. If I need debug logs, usually I want all available information. And if I don't need debug logs, I have not yet encountered the need for flexible log messages.
I might look into that if nothing else pops up in the next days, maybe try an implementation for log_text...

[onkelandy]

Mainly this can be used to show a log file in the (smart)visu. Something like "XY entered the house" etc. Thx!

[msinn]

You can do that logging in a logic and have even more flexibility in logging the text you want.

I don't see that use case as one to change the item logging mechanism.
Having a bit more flexibility for the logtext might be useful. But to be sure that the addition fills a need (and not only a need we suspect), we should wait until a real use case comes along.

[onkelandy]

The need seems to be there as there is a separate plugin for that: https://knx-user-forum.de/forum/supportforen/smarthome-py/904266-neues-plugin-operationlog

My idea was to kill that plugin as its almost obsolete - most of the features are now handled by the logging mechanism and the log_change attribute. Except the formatting of the logtext.

What about this:
log_change: Logger = Text (as string or eval)?

[bmxp]

What I am missing is with log_change is the ability to preset the generic message with an f-string configurable e.g. in etc/smarthome.yaml and the possibility to attach a logics' name if the caller of an items change is a logic.

[msinn]

and the possibility to attach a logics' name if the caller of an items change is a logic.

That can be done by giving the Logic Name in the assignement to the Item. Instead of setting the value like this:

sh.myitem(42)     # set myitem to the answer to all questions 

z.B. so:

sh.myitem(42, 'Logic '+logic.name)     # set myitem to the answer to all questions 

[onkelandy]

all aspects are implemented by now. #681 addresses adaptive log levels. Docu needs to be updated.
general log text via smarthome.yaml is also implemented with #686

[Morg42]

Merged #681, #682.