New version is now uploaded and as usual you can find it in post#1
I added new thing type LogTailer witch uses org.apache.commons.io.input.Tailer. It is only there for my own testing purposes. While testing I encountered a bug that stops the tailing and start reading log file from beginning. Work in progress to get tailer patched. You can ignore this and use LogReader as usual.
P.S Trying to write a proper readme to github. Have anything that should be covered?
Nope, did not save them.
Since upgrading to #1112, the binding does not produce trace logs anymore.
Will stop using the binding for now until the openHAB snapshot gets a little bit more stable again.
The last output I can provide for now:
openHAB started at 08:38, binding stopped working at 09:07 (last read), events.log at that time:
2017-12-06 09:07:30.218 [ome.event.ItemCommandEvent] - Item 'Shading_Shutter_LivingWest_Autoshade' received command OFF
2017-12-06 09:07:33.959 [vent.ItemStateChangedEvent] - logreaderLastWarningLine changed from 2017-12-06 08:57:34.102 [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.io.monitor.internal.EventLogger@1b389ce' takes more than 5000ms. to
2017-12-06 09:07:33.972 [hingStatusInfoChangedEvent] - 'logreader:reader:reader1' changed from ONLINE to OFFLINE (CONFIGURATION_ERROR): 1
2017-12-06 09:07:33.993 [vent.ItemStateChangedEvent] - logreaderLastRead changed from 2017-12-06T09:02:32.932+0100 to 2017-12-06T09:07:33.962+0100
logreader.things:
logreader:reader:reader1 [ refreshRate=300 ]
openhab.log:
2017-12-06 08:42:20.891 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'logreader.things'
@gitMiguel, have you published your source codes to GitHub? More eyes will always find bugs fasten.
You have done great work and I’m also very interest in this binding, but there are many of us, which doesn’t install any 3rd party bindings without seeing the source codes (and even build version from the source codes). I’m in no way to blame you for anything, but when you whole house is controlled via openHAB, you just need to be extreamily careful.
@sihui, That’s all right. Hope to get you back testing asap. You provide very valuable information and it’s easy for me to enhance the binding based on that.
Errors are captured and binding immediately set to offline rather than outputting warning lines to log. “Unparseable” lines is one thing to cause this. This could be handled differently but imho the binding is there to capture warnings and not to produce more of them. I think there’s two ways to resolve this. One is to not immediately put binding state to offline and stop reading but to direct these to warnin log and let the binding continue reading in the next loop. The second is to try to cover all different log outputs and handle them correctly. The latter is what I’m after.
@pauli_anttila, thise are some wise words and I agree. I have to admit that I havn’t thought it this way while developing and distributing this. I saw your posting in IoT Matketplace topic and I second all of your comments. I asked similar questions in here: Developing and distributing own bindings. Hoped to get some guidance how to handle these things in future.
And yes, source code can be found at github. github.com/gitMiguel Please have a look there. Help is always appreciated!
I quickly checked the Tailer based implementation and it seems to be pretty clean
Couple of ideas/remarks:
Filepath could/should be configurable. Many of us, have configured separated log files (e.g. for different bindings). Binding could support both absolute and relative paths. Then also system logs could be monitored (at least if search patterns are also configurable).
There could be custom channel where also search pattern is configurable.
Trigger channel could be cleaner solution or both could be supported.
rule "Error event"
when
Channel 'logreader:reader:reader1:error' triggered
then
var message = receivedEvent.getEvent()
logInfo("error occurred", "Error: {}", message)
end
LogTailerHandler logger has a paste typo (LoggerFactory.getLogger(LogReaderHandler.class))
Precompiled matchers could gain performance (might be that JVM do that anyway). No compile is done every time when line is received.
When TailerListenerAdapter receive Exception (handle exception method), should thing but to offline state?
If you are planned to make PR in someday, you could make PR with WIP tag immidiately, then it’s easier to give review comments directly from GitHub.
Yes. Current idea is to have it configurable. Leaving it blank would default it to openhab.logdir. This would guarantee easy setup for beginners.
I’d say more than one.
What’s the advantage if trigger channels are used?
Good catch. I’ll fix this.
Think you are right about performace. I’ll look into this.
Imho this depends on exeception (See my earlier post about when to stop or log as warning).
I’ve been thinking about making a PR. I’m just a bit unsure this being ready enough to do so. Especially TailerListener having that bug as I mentioned earlier.
New version available. Mostly for @sihui . Binding now goes offline only when there’s errors during initialization. In other cases errosr are directed to warn log and reading continues.
I just tried your binding and it stumbled over the date format in my logs. Here’s the error along with the log line that caused the error:
(Line breaks inserted by me after pasting)
07-Dec-2017 16:11:52.971 [WARN ] [openhab.binding.logreader.handler.LogReaderHandler] - First line could not be read.
Timestamp mismatch: 02-Dec-2017 08:28:37.185 [INFO ] [.module.script.internal.GenericScriptEngineFactory] -
Activated scripting support for ECMAScript
Yeah, I’ve been reading that same topic and won’t upgrade untill all that is sorted out. Still running #1080.
Ok. Have you @ralle altered your logging settings to output a different time format? This would explain the bahvior. And can you give your platform specs also?
Yes I have tweaked my logging config according to @Dim’s post here. I have changed the time and date formatting now from dd-MMM-yyyy to yyyy-MM-dd and now it doesn’t complain anymore.
The binding runs now and updates its items, but every update interval it logs the following warning:
2017-12-08 13:14:42.627 [WARN ] [openhab.binding.logreader.handler.LogReaderHandler] - Exception occurred while parsing log: 1
java.lang.ArrayIndexOutOfBoundsException: 1
at org.openhab.binding.logreader.handler.LogReaderHandler.readLog(LogReaderHandler.java:211) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Do you need a trace to find the root of the problem?
Trace logs are not needed but if you could provide whole log contents from past 10min (if you have default refreshRate of 60 seconds then past 5minutes is enough) so I can see the line what the binding tries to parse.
And what does bundle:list command in karaf console say? What is the version number of this binding?