How to use lock screen events as a trigger for a script

My Magic Mouse 2 died today and I thought it would be cool if I could use the locking of the screen as a trigger to send a push notification to my iPhone to remind me to plug my mouse in to charge.

I looked into it a little bit. There is an app called EventScripts that has a screen saver trigger. I tried out the demo, but it's too slow.

I also learned that I can send push notifications via script from my Mac to my iPhone using Prowl/Growl.

And I found that one of the system logs (/var/log/DiagnosticMessages/*) contains activeScreenSaver events that show up immediately when I watch the console. It would be great if I could just send a prowl push notification whenever activeScreenSaver appears in that log., I know how to send the push, however all the files in /var/log/DiagnosticMessages are binary. I can grep them for activeScreenSaver and see that there are matches, but I don't have one file in ASCII that I can apply tail -f to and pipe it to a script that watches for activeScreenSaver occurrences and sends the push… Does anyone know how I could watch those files for activeScreenSaver occurrences? I've written similar log parsers for other plain text logs before, but I don't know where to start when I'm dealing with binary files that change every so often.

BTW, I have tried using an iBeacon for reminders, but by the time I get the notification, I'm too lazy to go back to my desk to plug the mouse in. So I'd love to get the push notification right after I lock the screen… at least until it becomes habit.

UPDATE:

Through more googling, I discovered I could do this:

cat 2019.05.17.asl | strings - -o | grep activeScreenSaver
 290676 (com.apple.ScreenSaver.activeScreenSaver
 452746 (com.apple.ScreenSaver.activeScreenSaver
 481785 (com.apple.ScreenSaver.activeScreenSaver

Note, I used -o to show the matching line number so I could tell which events were which.

However, that did not include all of my lock screen test events today. I searched through the raw strings output and discovered that if I did this instead, I got all the events from today (when I compared it to what I see in the Console app when searching for activeScreenSaver):

cat 2019.05.17.asl | strings - -o | grep "QuartzCore,ScreenSaver"
 290278 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 443512 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 481387 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 482889 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 486926 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 488824 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 501148 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 504036 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib

I thought I was good to go, but when I tried tail -f instead of cat, the output was truncated:

tail -c +1 -f 2019.05.17.asl | strings - -o | grep "QuartzCore,ScreenSaver"
 290278 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib
 443512 nAppKit,GLEngine,Flurry,QuartzCore,ScreenSaver,libdispatch.dylib,CoreFoundation,HIToolbox,Direct,libdyld.dylib

I'm not sure why tail -f stops in the middle of the file… Plus, I would still have to figure out how to update the tail when the file changes…

tail -F gets me farther – to the current end of the file, but new entries added to the file do not spit out.

Also, I tried a few homebrew versions of tail which I had hoped would allow the monitoring of multiple files, but none of them were able to handle the binary files…

Interestingly, if I don't pipe the output of strings to anything, I see live messages continually come out. But if I pipe to grep of a perl on-liner, the stream just dies half way through.