Sort by last change instead of update?

I’m trying to create a log with changes of the status from an open/closed node (door, window, fence…).

But it seems that my filter isn’t sorted correctly (or to fast, or …). sortBy[lastUpdate].last.
But sometimes, the wrong device is being shown. See the entry on 07:31:02 in my logfile below.
Maybe because that node sends an global update about his status (thinking out loud here)?
Can I filter on ‘last change’ or so?

items (20 in total)

Contact Deur_Atelier  "Atelier Deur [%s]"   <Door>        (ALL_entries, AllDoors, ent_POL)        { channel = "zwave:device:2f4ef5d0:node93:sensor_door" }
Contact Poort_Atelier "Poort Atelier [%s]"  <garagedoor>  (ALL_entries, ent_POL)                  { channel = "zwave:device:2f4ef5d0:node32:sensor_door" }
...

rule

rule "Logging van open zaken"
when
        Member of ALL_entries changed 
then
        val String currentTime = String::format( "%1$te/%1$tm/%1$tY %1$tT", new java.util.Date )
        val ODstate = ALL_entries.members.filter[s | s.state == OPEN || s.state == CLOSED].sortBy[lastUpdate].last
        executeCommandLine("/bin/sh@@-c@@(echo '" + currentTime + " " + ODstate.label + " " + ODstate.state + ".' >> /var/log/openhab2/OpenClose.log)", 5000)
end

OpenClose.log

4/06/2020 06:48:21 Poort Werkplaats OPEN.
4/06/2020 06:48:55 Poort Werkplaats CLOSED.
4/06/2020 07:31:02 Leefruimte Venster CLOSED.
4/06/2020 07:31:10 Hal Deur CLOSED.
4/06/2020 07:44:32 Hal Deur OPEN.
4/06/2020 07:44:37 Hal Deur CLOSED.
4/06/2020 07:45:36 Hal Deur OPEN.
4/06/2020 07:47:14 Hal Deur CLOSED.

Instead of your ODstate variable, use triggeringItem. Although, doesn’t the event.log provide what you are creating?

Ahh, seems to work nicely with the triggeringitem. I had both (my ODstate and triggeringItem) in my test rule, and 2 different results. The ODstate was wrong, the triggeringitem correct.

rule "Logging van open zaken"
when
        Member of ALL_entries changed
then
        val String currentTime = String::format( "%1$te/%1$tm/%1$tY %1$tT", new java.util.Date )
        if(triggeringItem.state == OPEN || triggeringItem.state == CLOSED) {
                executeCommandLine("/bin/sh@@-c@@(echo '" + currentTime + " " + triggeringItem.label + " " + triggeringItem.state + "' >> /var/log/openhab2/OpenDicht.log)", 5000)
                }
end

And yes, the event.log had all info in. But with tons (150.000+ lines) of other info.
I just wanted to have a file with this info. Other solutions are of course welcome. Always eager to learn… :wink:



You could create an appender for the event you want to log to a separate file…

Or just turn down everything else that is coming up in the event log.

1 Like

You can also sort through and pull just the lines you care about using the tools available to your on the command line. See How to watch and look through logging for Linux and Windows examples. The Linux commands are POSIX so they will also work on Mac.

1 Like

I’m trying to keep it all simple. Use existing technology/setup/stay in the OH enviroment …
And I’m trying to get around with what is possible with OH-rules. :wink:

But I agree that I could do it wit some bash scripts, the log binding… As always, all things have some pro’s and contra’s. In this case, 3 fast solutions?

  • OH rules
  • Log binding (isn’t it more complex then the rule above?)
  • linux scripting/cli/… (isn’t that (system)heavier then the rule above?)

I’m just a bit suprized that you guys think outside the OH-rules. Would just expect that you would promote rules. Or am I missing something? :blush:

One of my pet peeves is when I see someone doing the equivalent of hammering in a nail with a screwdriver. You can do it but it’s going to be a whole lot more work and take a lot more time than using a hammer. The corollary to this is “when the only tool you have is a hammer, all problems look like nails.”

Doing it all in rules really isn’t simpler. It just means you don’t have to learn how to use another tool. IMHO, people are far better off in the long run spending a little but of time learning how to use the right tool for the job rather than forcing a less capable tool to do the job. Not only does the learning itself in-and-of-itself have value, but it gives you access to more tools in your toolbox which will make you faster and more efficient at solving any new problem that comes your way in the future.

openHAB is not and does not pretend to be all things to all people. It has it’s uses for which it excels (home automation) and uses for which it isn’t the best tool for the job (network monitoring) and it has uses for which it is really bad (looking through logs). It doesn’t make anything simpler when trying to use a tool for which there are better tools available.

In this case, watching logs, filtering logs, and searching through logs is something that has been done since before Unix was invented (the 1970’s). tail, grep, and less excel at this job. There are some newer variants (e.g. multitail) that add features but the core features of these nearly 50 year-old-commands is more than adequate in almost all cases.

Want to monitor all the devices on your network? Use Nagios or Zabbix or Fing or something like that.

Want to schedule a nightly backup? Use crontab and a shell script instead of an OH Rule.

And if you want to look through logs, use tail, grep, and less (or their equivalent).

But I guess it all boils down to why you want these log entries isolated. If you just want to look in the file to see when they happened, why go through the pain of writing a new logger config when you can just issue the command:

grep -E "Deur_Atelier|Poort_Atelier" /var/log/openhab2/events.log | grep changed | less

Or, as is usually more useful, you can search through events.log to see those log statements in context.

less /var/log/openhab2/events.log

Then to search for those lines type /(Deur_Atelier|Poort_Atelier).*changed.

It will highlight the lines and navigate using n for next match and N for previous match.

This lets you see the log statements in context (i.e. what events occurred immediately before and what events occurred immediately after) which is almost always more meaningful than seeing the log statements on isolation. Or if you really need to reduce what’s in events.log, change the logging configuration so events.log is more useful to you, don’t write it out to some other log file.

If you really do need them in a separate file, configure the logger to put them into a separate file. This will be more efficient in the long run.