“Others” mostly have no programming skills and therefore are very thankful for your both work.
So why not just combining forces and creating an even better binding as it already is 
2 Likes
@gitMiguel, I’m fine with that, but I definitely don’t want to “steal” your idea, so I will give credits to you as well when I do the PR to OH repo.
I did even more refactoring, and now I’m pretty happy to binding structure. Channels are still fixed (warning, error and one custom), but I think they should be dynamic, so that user could define one or more search based channels dynamically. As I have never implemented dynamic channels which are defined in runtime rather than statically, I will postpone that to the future.
Compiled binding can downloaded from here for testing purposes and documentation can be found here.
4 Likes
Sounds good to me. I’ll update the first post accordingly and add a link to your recent post so all users can catch up. I’ll keep the “original” LogReader to my self and change its name to avoid confusion.
And thanks for the credits.
and thanks for combining forces. 
2 Likes
Just popped to my mind that @ssalonen requested tailer implementation for journalctl. This should be kept in mind for future developement.
Which one of the two versions is the “right” one?
Should i use the original version from first post or the new version from @pauli_anttila?
That post has been updated and links to the “new” one which is now the only one 
@sihui here is right. Use Paulis version. He made a total rewrite of the binding. Sorry if the first post is somehow misleading.
Hey @pauli_anttila,
I got inspired by your code and I’m rewriting my original logreader. Trying to keep the functionalities as is but implement it in same way as apaches tailer. I would like to reuse parts of your code. Espcelially searchEngine. Is it ok?
of course.
I tried to implement binding modular, so if you want to replace Tailer, you could just write new file reader which extends AbstractLogFileReader implements LogFileReader (like FileTailer does). Then in LogReaderHandlerFactory, you create LogHandler, but with new file reader rather than FileTailer. In the end, there could be new thing type or user could configure used file reader from binding configuration. This is how journalctl based solution should be implemented as well. Not sure if there are any java based implementation available or should command line util be used.
Thanks.
I’ll be forking your repo then. Just have to be careful with namings so it won’t get to confusing. I like more creating a new thing type because I want few of the channels different.
Regarding journalctl this is what I have read a few times https://stackoverflow.com/questions/27178431/calling-journalctl-from-java but you propably have seen this already. Imho replacing Tailer with jctlTailer and creating another thing type. Passing lines from json response to handle method should do it.
I’m wrote another Tailer named Parser which contains my old reading method which is now runnable. Also theres a new thing type parser with few new channels and less config options. Can this be handled with the same configuration class if somebody decides to run both things paraller?
And because there’s different methods in Parser should new interface and abstract class be written to replace FileReaderListener and abstractLogFileReader? Seems that handlers cannot be made abstract so all methods have to be implemented, even unused ones. Or what is the best way?
Just so you get my idea I want this to be something that doesn’t read lines continuously but between longer intervals and gathers all information into single update. For example I was testing out my alarm rules for modbus binding. As soon as I physically disconnected the modbus server from network there were lots of errors in logs and I don’t want them flooding my telegram account.
Edit
I uploaded my logreader branch to my github account. I ran out of time this evening and it’s a mess. Work in progress as they say 
Would be happy to receive some guidelines how to proceed and implement things your way.
@gitMiguel, are you implementing this log reader (Parser) for fun or is there use case behind which Apache Tailer doesn’t match? Apache Tailer go throw whole log file only ones, then monitor when new lines are available and read only those new lines, so it’s from resource (CPU, IO, etc) use point of view very efficient way.
No, I’m not doing this for fun and this is more or less for my own use. I tried to explain what I’m after in my earlier post and your implementation imho is a really good base for further features. You are absolutely right about Tailer being more efficient and I remember saying that this is how LogReader should be functioning in the end. You got there first and made it so that a PR can be made in official repo. And I am pleased it is so.
But as my OH system is still in developement, I’m using snapshots and alpha state bindings, errors and warnings are not so rare. This is why I want my version of logreader to not flood my mobile phone with notifications if lots of errors happen. Gathering updates in a rule and sending them once an hour doesn’t seem reasonable to me so thats why i want this to happen at binding level. Prove me wrong because I might be totally on thr wrong tracks here.
Why not? You can pretty easily implement and change log aggregation and time based rules for notifications. E.g. prevent notification sending in the night, collect errors in certain time period or even make collection dynamic, so that first alarm is send immediately and then next ones are aggregated e.g. in 10 minutes and if lot of errors are still received, increase the notification time even further. Or send one email every morning which include all previous day/night errors.
It surely is possible, but at this time I just don’t know enough about rules to create them the way you are describing. But I can make the binding to do so for me. Thats why I resoned it this way.
Did not mean to be rude, I just wanted to understand the use case which can’t be handled by the current binding. So you can surely do it how it’s easier for you.
Rules are very essential and also powerful part of the OH, so you should use some time to learn that as well. In general, bindings should just provide data or make possible to control some actuators, and business logic should be normally handled by the rules as there are normally so many uses cases (every user have own needs) that it’s pretty impossible to handle them all in the binding level.
1 Like
Are there more examples of working configurations, in debug im gettting
2018-04-05 22:56:55.159 [INFO ] [binding.logreader.handler.LogHandler] - Using configuration: [filePath=/var/log/openhab2/openhab.log, refreshRate=1000, warningPatterns=gcal, warningBlacklistingPatterns=none, errorPatterns=gcal|10_0_0_32, errorBlacklistingPatterns=SNMP: snmp not initialised - aborting request|Another annoying error which should ignored, customPatterns=null, customBlacklistingPatterns=null]
2018-04-05 22:56:55.164 [DEBUG] [binding.logreader.handler.LogHandler] - Start file reader
2018-04-05 22:56:57.108 [DEBUG] [binding.logreader.handler.LogHandler] - Unsupported command 'REFRESH' received for channel 'logreader:reader:openhablog:lastWarningEvent'
2018-04-05 22:56:57.212 [DEBUG] [binding.logreader.handler.LogHandler] - Unsupported command 'REFRESH' received for channel 'logreader:reader:openhablog:lastErrorEvent'
2018-04-05 22:56:57.303 [DEBUG] [binding.logreader.handler.LogHandler] - Unsupported command 'REFRESH' received for channel 'logreader:reader:openhablog:lastCustomEvent'
I did have a 409 error which i believe ive solved,
manually installed thing in 2.2 as
logreader:reader:openhablog[ refreshRate=1000, warningPatterns="gcal", warningBlacklistingPatterns="none", errorPatterns="gcal|10_0_0_32", errorBlacklistingPatterns="SNMP: snmp not initialised - aborting request|Another annoying err$
other items and site map as examples using
DateTime logreaderLogRotated "Last Log Rotation [%1$tY.%1$tm.%1$te %1$tR]" <time> { channel="logreader:reader:openhablog:logRotated" }