Lastcheckin showing numbers and not date (Xiaomi driver)

[AlanB]

Hi all
Following on from another post i made about some issues I'm having, I've got some Xiaomi contact and motion sensors that don't show a date for Lastcheckin (see image below). They just show a large number which I assume links in to some date but am not sure. I'm using the custom driver that most use (Xiaomi / Aqara ZigBee device drivers (possibly may no longer be maintained)). I've tried deleting the driver and reinstalling but no change. The devices still show a number.
Can anyone shed some light on how to fix this or what I'm doing wrong?
Thanks
Alan

[Royski]

Thats the Epoch time.

[markus]

Just as @Ryoski says. Here is the reply from the driver author:

[Deprecated] Xiaomi / Aqara ZigBee device drivers (possibly may no longer be maintained)

Yes, as mentioned, lastCheckin, lastClosed, and 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 contact - open or 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 lastClosed or lastOpen. Since the Epoch date/time stamp is simply the number of millisec…

[AlanB]

Thanks. I'll read up on that. I hope there is an easy way of converting to normal.

[markus]

@AlanB

I hope there is an easy way of converting to normal.

The Xiaomi/Aqara Temperature and Humidity driver has that under lastCheckinTime if you want an example on how to do it.

[bobbles]

I still don't understand why this should be happening for you. (As discussed in your other post).
These time displays are ok for me.
Very strange.

[JohnRob]

I have an:

• Aqara Temperature Humidity Sensor - model WSDCGQ11LM
• I'm using the V1.0.1 driver from veeceeoh
• I'm in the US in time one EDT

definition (name: "Xiaomi Temperature Humidity Sensor", namespace: "veeceeoh", author: "veeceeoh", importUrl: "https://raw.githubusercontent.com/veeceeoh/xiaomi-hubitat/master/devicedrivers/xiaomi-temperature-humidity-sensor-hubitat.src/xiaomi-temperature-humidity-sensor-hubitat.groovy")

My current state is just like the driver shows:

The driver attribute defn from the V1.0.1 code.

attribute "lastCheckinEpoch", "String"
attribute "lastCheckinTime", "Date"
attribute "batteryLastReplaced", "String"

Could it be you are using a different driver with different attribute defn's ?

[bobbles]

Thinking about this I seem to remember going through all my Xiaomi/Aqara drivers and modifying them as above.
Some needed the mod and some did not.

[AlanB]

Thanks.
It's been a while since I've done coding.... a long while. . I'll need to dust off the brain and try figure out what needs changing

[AlanB]

Ok, I'm not coming right. I played around with the code last night but couldn't get it right. Not as simple as adding an attribute apparently . Is the answer in the long code post? I did a search but it wasn't obvious, so will do a deeper dig but was hoping someone could tell me if it is in there first before going though thousands of posts. Or if you know anywhere else it is?
Thanks for any help.
Alan

[markus]

This is one of the reasons you shouldn't post threads with similar issues, you yourself get confused and lost:

Losing connection to devices and reading false states

The way it displays for @AlanB is how it would display without modifying the driver. The change needed to show as @bobbles have the date is a very minor one. Replace all occurrences of "now()" with "new Date().toLocaleString()".

I did give easier to follow instructions than earlier, just in another of your threads.

[AlanB]

Sorry Markus. I try keep to post topic and the other one was more talking about connections, not a date change. Other forums moan when you go off topic. Also I didn't get an email notification or would have looked there.
thank you for the help

[markus]

I understand, it is hard to rel on e-mail notifications though. Go through your Notification Preferences and see if you can set something that makes it easier for you to keep track.

If you have multiple issues that are related and they fit under the support section but not really under a subcategory there is no need to separate them. In this case they do fit under Support Devices, so could just have been one since they are related.

[AlanB]

Will do for next time