That’s at the opposite end of the spectrum, we’re looking at something more verbose than debug. besides originally “critical” was a level, from the original version
# loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
# see here : http://docs.python.org/2/library/logging.html
loglevel = WARNING
and there are try/exceptions that only provide for certain exceptions and any thing else is unhandled so that would be good to tidy up too. Whilst I understand the reason to avoid using except Exception as e approach, as a stop gap it catches any unhandled exceptions and also serves as a “TODO” flag so it doesn’t get missed or forgotten.
That is a preferred approach but I do not think that alone is the fix here as I would like to see a mechanism for excessive logs when debugging/development gets tough. Plus that could take time and possibly get confusing for users if we are heavily dependent on it. I does fit with the original way I had emonhub settings cascading down, so all interfacers would use the emonhub wide level unless there was a interfacer level defined, so (for example) all interfacers could default to warning, but whilst there is an issue to be resolved in a particular interfacer, add a new level to that interfacer’s config only and during times it’s not needed, just comment it out, the hash becomes a switch when frequently switching. I would hate to see a new loglevel setting in every interfacer’s config, that was never how emonhub was intended to work. Many of the settings in the OEM default conf are pointless as they simply duplicate the hardcoded defaults and pad the conf file out with stuff the user doesn’t need to worry about.
I agree, I was looking at the lesser evil, having what we have isn’t great but I didn’t want to rock the boat and alter the logging in case it results in a drastic change that is less workable, i have been biting my tongue on this subject for a very long time as the OEM project is heavily dependent on the emonhub logs for debugging so many different things. I was not thinking this would ever need to be used by “users” unless being guided by one of us, just for developers and confident code tweakers.
No I think that idea has a lot of merit. I quite like the idea of a devmode or debugmode boolean setting in the interfacers runtimesettings independent of log levels (global or interfacer level) that is sort of “hidden” as in not advertised, not on show in the conf for general use. That would be very easy to implement in the emonhub interfacer core and get inherited to each interfacer, so all devs need to do when writing interfacers is essentially leave their working “prints” in place, tidied up as log messages that only get included IF the “debugmode = True” is set in the relevant runtimesettings. I like that idea a lot as it’s quick to implement and doesn’t interfere with any plans to change the loglevels or expand to interfacer level loglevels.
This afternoon I have received a PM about this very subject in emonhub regarding some other dev work that’s going on behind the scenes and there is an apparent desire to “print everything” to the emonhub.log, whilst a lot of info can be useful, when debugging having a dozen interfacers spewing endless intermingled information is not going to help. The debugmode would allow devs to go crazy with prints without ruining the existing debug loglevel.
Even if just a stop gap, this is IMO the best and quickest fix. But I actually hope it is a permanent feature.
The other consideration with massive amounts of log info is the log files will get rotated out very rapidly and info will become hard to find, there’s also the disk writes when they get persisted by log2ram.
Certainly a candidate for a debugmode only debug level message! I think we’re on the same page @bwduncan, this development, should it proceed would help a massive amount in 2 other current debugging threads (1x mbus and 1x modbus interfacers) that IMO need way more debugging info, but much of it is stuff we don’t want to see when the interfacer dev is complete or it’s behaving at least. IMO there are 2 kinds of debugging at play here, the first is debugging why connected devices are not working as expected, in this respect emonhub is a tool to help users get their stuff working. Then there’s debugging emonhub itself, that’s dev debugging and “users” do not need easy/frequent access to that if we’re developing good code for emonhub, but since we cannot always reproduce faults, it would be great for a user to simply switch on “devmode” and post the logs.
I’m conflicted about the name, debugmode seems more right, but it doesn’t differentiate from the debug loglevel enough to avoid confusion. devmode (sounds odd but) is clearly different and obviously not a normal “user” setting.