Yes, as mentioned,
lastOpened are all expressed in the Unix-standard Epoch date/time format.
I included those for webCoRE users originally when v0.7 of the driver was released:
You will see two events because there is
close event that is used to record the state of the sensor for hub automations, and then there is the second event for the custom attribute
Since the Epoch date/time stamp is simply the number of milliseconds since 00:00:00 UTC on 1 January 1970, those values can. also be used in Rule Machine to compare the previous and current value and take action accordingly. Of course, the
close events themselves have a date/time stamp so that could be used as well.
I plan to release an update to this driver which includes custom attribute events for both Epoch and human-readable date/time stamps that are by default disabled and can be optionally enabled if the user wishes to use them.
The driver also decides whether
info message logging is enabled based on the value of the state variable
prefsSetCount. This state variable is used to allow
info messages to display while the device is being paired, and then when it changes to a value of 1, the message display stops until the user enables it in preferences.
It's possible that something got out of sequence and
prefsSetCount is not set to 1. You can check on the device's details page in the hub UI here:
If you see a value other than 1 then like something happened out-of-sequence during pairing. You could try doing a re-join, which means you go through the pairing process, but without first removing the device from the hub's device list. That should hopefully get
prefsSetCount to click up to a value of 1, but if not, then remove the device and pair it as new to fix it.
The next update of the contact sensor driver will no longer use
prefsSetCount, and instead show log messages for the first 2 hours after pairing, and after that the user would need to enable log message display in the preferences.