pimatic log-reader updates variables just at device creation

---

Hi,
I tried the log-reader on a logifle. I thought the variables are update the time the logfile changes but for me no updates take place (I already tried to change the file manually, I tried to chmoid 777 and I tried to recreate it, I also tried to append new lines…nothing changed the situation so far)

The only way to update the variables is to edit and re-create the device. This works flawless.

Any clue? How can I check if the watchdog? is up and running? Maybe the service checking changes of the log is not able to run on my raspi setup?

As everything works once after creation of the device it should not have to do somethin witrh my config or the logfile itself?!

   {
      "file": "/home/pi/pimatic-beta/logs2parse/nu.lg",
      "attributes": [
        {
          "name": "State",
          "type": "string"
        }
      ],
      "lines": [
        {
          "match": "STATE:1",
          "State": "YES"
        },
        {
          "match": "STATE:0",
          "State": "NO"
        }
      ],
      "xAttributeOptions": [],
      "id": "nu",
      "name": "Nu",
      "class": "LogWatcher"
    }

Logile has currently just one line:

STATE:1
or
STATE:0

br
Mike

Hey. I dont have any experience with that Plugin but I think for your use-case you should Better go with a VariablesDevice. There you can define a Shell “command” that reads your logfile in a specified “Intervall”.

Command could be something like that:
grep -r "STATE" yourlogfile.log | awk '{print $3}'

Hi ,
thanks for your fast response!

Yes this would be my workaround but just to be sure: As far as I know there is currently (v.9.x) no option to run a shell comand directly from the variables device?!
I will need a separate shell sensor for each of my variables plus the variables device to show them in gui together. Correct?

Thanks, br
Mike

@merphun Sorry! ShellSensor is what I actually ment. And yes: You need multiple Devices if you want to read multiple values from that log file.

that’s very strange!
i tried to recreate your issue and i get to the same result. When the one line of the log get overwritten there is no change of the device. Don’t really know yet if this is an issue or a faulty match.
but i can only change the value of the variable after changing and saving (recreating) the device itself.

what if you append your logfile so that the last line is always the actual state.
this worked for me.
having a continous log then. You could also write the date of the change into the log when the STATE got updated. So your log becomes more informative.

here’s my device :

    {
      "file": "/home/pi/state.log",
      "attributes": [
        {
          "name": "state",
          "type": "number"
        }
      ],
      "lines": [
        {
          "match": "STATE:([0-9])",
          "state": "$1"
        }
      ],
      "xAttributeOptions": [],
      "id": "nu",
      "name": "Nu",
      "class": "LogWatcher"
    },

now you should get a variable called $nu.state and you can use it in rules like WHEN state of Nu = 0 THEN do something
just an idea : you could use a dummy presence sensor to visualize 1 or 0 (full dot or empty dot) now.

Hi,
thanks for supporting me here! If it is working as intended - in case we have to use continous logs - this should be stated clearly in the plugin to prevent others having the same troubles.

For me I already implemented the workaround as described above. Its a few more devices but I guess its not really more load on the system and I have not to use a cont. log (wich always tends to eat up all reamining free hd space

Br
Mike

well usually the logreader works also with non continuous logs. have several devices where everything is good going.
therefore i have really no idea actually of whats going wrong here

For non-continous log files the question is how do you truncate the log file?

If you simply overwrite the file, e.g. using the > output operator multiple times, e.g. echo -n "" >yourLogFile or cat /dev/null >filename, a new file will be created each time and log reader will point to the original file which is left intact for the open file descriptor. See also http://stackoverflow.com/questions/2028874/what-happens-to-an-open-file-handler-on-linux-if-the-pointed-file-gets-moved-de

If you use logrotate to shrink the log file this should not happen. Alternatively, you can use the truncate command to shrink the file, e.g. truncate -s0 yourLogFile or use the “:>” I/O operator with bash to truncate the file, e.g. :> yourLogFile.

@merphun For you one line log file you can try as follows.

# the following line will create or truncate the file 'yourLogFile'
:> yourLogFile
# append the output to the log file
echo $stateVariable >> yourLogFile

Hi,
thanks for this information. You are completly right. After I changed my script as suggested by you the log reader does its job.

:> yourLogFile
echo $stateVariable >> yourLogFile

instead of

echo $stateVariable > yourLogFile

br
Mike

@merphun That’s great! I think we should add a note in the README on this.