Before I open up the request, I wanted to check if the community believes that it would be useful feature, so go ahead and post some comments
Scope: Create a new Configuration section in PaperUI called “Logging” that will allow a web based modification of the logging facility (levels, appenders, etc) of openHAB2. At least for org.openhab.* and smarthome.*
Why ??? : To make it easier for users to: (1) identify loggers & (2) change on the fly log settings to help them with debugging/root-cause analysis.
Display current loggers and their levels (grouped)
I am afraid that such a feature won’t have much chance on ESH for two reasons:
The logging features are completely left to the solutions, there won’t be a general concept in ESH for that.
Logging is not meant to be part of the “UX”. It should only be relevant for developers or for reporting issues to developers. Hence, this is nothing that should be exposed in the “normal” UIs.
But there is probably a fairly easy solution to your problem: The Apache Felix Web Console. This should be easy to install on Karaf in openHAB2 and it provides all the features you ask for (and many many more!).
I was thinking the same, just wanted to verify my understanding here (in the community) before I posted a feature request
Clarification: By “solutions”, you mean technical/infrastructure solutions (like Apache Karaf) ?
It does make sense not to tie too close the ESH with a technology.
Agreed. I was thinking about something simple for the user who doesn’t want to dig in the more advanced stuff. Just a simple way for him/her to see what gets logged where and to modify these settings. This is not so useful for me personally, since I handle this stuff in other ways.
I won’t open the issue. It doesn’t really belong to ESH
Hey, while I like the idea in general, this is not linked to openHABian, is it?
If you were to develop something like this, why not develop it as an independent UI next to Paper UI, HABmin etc.? As a user selectable add-on it’s probably also in line with the idea by @Kai “nothing that should be exposed in the “normal” UIs”.
As I said I would rather recommend the Felix Web Console as this is a wide-spread tool that many people know and which can do much more “developer-related” stuff. It could be added as a “Misc” Add-on to the distro indeed.
Hm, good point, I actually thought that feature is there, but that might have been a wrong assumption. The web console only let’s people filter the existing log…
Probably best to ask at the Karaf forum if people have a UI for log level management. It indeed might be tricky as it will depend on the used logging framework and Karaf leaves some choices to the user. Btw, once we upgrade to Karaf 4.1, we will also switch from log4j to log4j2, so any implementation that only works on log4j would break again as well…
@Kai I agree with you. But I can comprehend @Dim’s idea because I already had a quite similar ide.
Currently the log output is (as far as I can see) the only possibility to get more information if something does not work as expected.
As an example, I made a test and switched off my Homematic bridge (CCU). In Paper UI I can see that all things are offline and on my Android phone with HABdroid after some time the actual temperature values are no longer shown. I think there are bindings where it is not possible to see that something is wrong when you only can
But in order to find out the reason for the problem I have to look into the log file (for a “normal user” the information in the log are probably not really helpful).
I think it would be very helpful to have some sort general mechanism that allows the bindings to make information about problems available for the UIs and/or myopenHAB (e.g. via REST API). Or ESH itself could indicate that something is wrong if an exception occurs.
In my test case it would help if I could see somewhere that the connection to the CCU got lost.
I have installed it on my Raspi and it is really nice. Unfortunately it does not help when I am not in my home network because I can’t access it.
The same applies to all solutions that are not integrated into openHAB and therefore accessible via the openHAB cloud.