Damn, you are breaking all openHAB standards, I have never seen it written like that
Thx, now it works. But please note that the refreshRate has to be written without quotes. With quotes I get a java error (openHAB snapshot build #1084)
Enable TRACE logs to see more precisely what reader does and finds. DEBUG shows errors and should be enough to find the cause. Error should also be displayed with bindings state like in your image. Although that error message looks a bit weird. Might be a bug and Iāll investigate it asap.
Edit
Corrected my answer. I made some adjustments in logging but you have to wait for new version. Iām working on adding a new thing type that only tails the log and I want this to be in the same release.
In spite of your āEditā: binding stopped again after a couple of hours, here is the error message and the trace log:
30-Nov-2017 13:15:14.518 [DEBUG] [openhab.binding.logreader.handler.LogReaderHandler] - Last line: at java.lang.Thread.run(Thread.java:748)
30-Nov-2017 13:15:14.521 [DEBUG] [openhab.binding.logreader.handler.LogReaderHandler] - Exception occurred while counting lines: For input string: " at "
java.lang.NumberFormatException: For input string: " at "
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:?]
at java.lang.Integer.parseInt(Integer.java:569) ~[?:?]
at java.lang.Integer.parseInt(Integer.java:615) ~[?:?]
at org.openhab.binding.logreader.internal.LogReaderCore.timestamp(LogReaderCore.java:28) ~[?:?]
at org.openhab.binding.logreader.handler.LogReaderHandler.readLog(LogReaderHandler.java:194) ~[?:?]
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) [?:?]
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?