“Was” versus “is” in the event log

[dshafer]

short version: Can someone explain to me why some contact sensors log the event with [device name] was opened and some log with [device name] is open? This is driving me crazy and I don't know how many rules I wrote to parse the event log have broken because of a sensor who logs a different verbiage from what I expected.

Longer version: In a sick perverted way I would like to thank IFTTT for disabling the free service. It has gotten me off my duff and I've taught myself more about writing code to replicate what I've lost. I've got 90% of the functionality I had with IFTTT replicated with local rules and special thanks to bptworld for his Event Watchdog and endorphin_junkie for his Abode integration driver. One of the biggest things I was using IFTTT for was to create a unified event log for both systems (in a Google Docs spreadsheet). It's almost working, but every time I think I've got all the corner cases covered one of my sensors logs "device is open" when the string parser was looking for "was opened" and the darn rule breaks, and usually takes down Event Watchdog with it. grrrrr... Does anybody know why or how I can control this? It does seem to have some loose correlation with how long ago "debug logging" was enabled for the device, but that's not the main reason as there are exceptions.

[bertabcd1234]

This is up to the driver author (whatever they put as descriptionText, technically, or whatever the platform might provide as a default, if anything, if they don't--I'm not sure if that latter thing is really a thing or not, as in my own drivers I do it myself). If the driver is open-source, you could edit this yourself; if it's built-in, you're at the mercy of staff.

You might know that parsing the description text is an odd way to write a rule/app. If you aren't familiar with the more traditional ways of accomplishing your goal--generally, responding to the actual event (attribute and value change, usually) from the device--I suspect someone could suggest a workaround. Perhaps you have reasons for doing in this specific way, but it's not clear from the information provided.

[dshafer]

I'm parsing the event log with the goal of having one rule log events to a Google docs spreadsheet for most of my devices. By parsing the event list, I can parse both the device name and the action from the event text. I tried to trigger from a contact status events change, but the problem was I had to code a rule for each device. I couldn't figure out how to have a rule trigger from a contact change from any of 30 sensors and have the name of the sensor that triggered the event be stored in a variable. If you know of a way to do that PLEEEASE tell me, as that would make my life soooo much easier.

[JohnRob]

To be honest, I'm not sure I understand your current path. So I offer this simply as a way I do something similar.

I use Node-Red running on a laptop with a simple flow to capture the Hubitat events and write them to a CSV file. I'm not a Node-Red expert but from what I can see it should be easy to "parse" the events if you wish.
For historical purposes (aka troubleshooting) I import the csv file into Excel and have a Macro do any parsing.

[JasonJoel]

That would have been my suggestion. Quit parsing off the description and use the event value and device name.

But I also do it in node red, where it is easy to do such.

[dshafer]

In truth bertabcd1234 answered the question. It's set by the text strings inside the device driver. So I have no choice but to either live with it, or switch to a more powerful scripting environment that allows me to create my events list without having to parse strings. So thanks to all who have chimed in with suggestions of a more powerful scripting environment. Can I just say that if Hubitat had a system variable for last device to log an event, this would all go away? Oh well. Thanks anyways.

[bertabcd1234]

@dshafer

ave the name of the sensor that triggered the event be stored in a variable.

Are you using Rule Machine? If so, you have four built-in variables that refer to the last triggering event/device: %device%, %value%, %time%, and %date% (plus %now% for the current time). It seems like one of those should do what you want. If you're writing your own app, you should have access to the actual event object and be able to extract the data from there (not the optional description text, though that may be included). If you're not writing your own app, that might be the "more powerful scripting environment" you're looking for.

[dshafer]

You are awesome. Thank you. That was exactly what I needed. Yes, I was using the rule engine, and that tip just allowed me to replace a replace a 50 line rule with a 3 layer nested if, and still had bug in it, with a 5 line rule that seems to be working fine. I'm now down to one sensor that is not logging properly, but that' a lot better than better shape than I was in yesterday. BTW: Is there a document that lists the reserved and system variables? I swear I googled the wiki and couldn't find anything.

[bertabcd1234]

They're mentioned in the original global variables doc, but I'm not sure if that ever made it into formal documentation. They are also listed in the RM UI itself when you do a log/notify action, which I think was originally the only place they could be used (this either predates or was introduced around the same time as global variables, both before local variables that we also now have).

Glad it helped!