Feature Request: Access to last change date of an item (for iobroker driver)

[tukey42]

It would be great, if the last change date of an item can be accessed (especially for the iobroker driver).

[uwe5]

I would like that too!

The timestamp arrives in the ioBroker adapter (io_iobroker.js) here:
stateChanged: function(item, state) {
...
// state.lc: TIMESTAMP of last change
...
}

Here you would have to somehow send state.lc instead of state.val to the widget, perhaps via an attribute as switch to use state.lc instead of state.val.
I wanted to include this concept here, but I don't know enough about it.

State is the actual value of the data point and presented by javascript object:
{
val: VALUE,
ack: ACKNOWLEDGED,
ts: TIMESTAMP, // could be converted into time with "new Date(state.ts)" (In older version of js-controller - "new Date(state.ts * 1000)")
lc: TIMESTAMP of last change,
from: ADAPTER_NAME,
q: QUALITY
}

greetings Uwe

[wvhn]

I am already working on it.

Since we have the keyword „property“ for item properties already in smarthomeNG and the templatechecker can check this I would use this here, as well.
So to visualize the items last changed property you would enter myItem.property.lc as parameter in the widget which then is filled with myItem.state.lc in the driver.
To simplify the procedure, I would map all item properties if any one is requested on the actual page for that item. Otherwise, only myItem.state.val is mapped like in the actual driver.

Does that fulfill the requirements?

regards
Wolfram

[tukey42]

Yes, that would be great!

Best Regards, Stefan

[wvhn]

OK. Can you test the attached driver for me, after renaming it from .txt to .js and selecting this driver in config page? I ran some dry tests but have no ioBroker system for validation.
io_iobroker_new.txt
Request the item last changed property as myItem.property.lc. You can display the time with basic.print('','myItem.property.lc','time','VAR*1000') if the timestamp is in seconds.

Regards
Wolfram

[tukey42]

I did a quick test. Unfortunately I got a lot of the following error message in the browser console:

TypeError: io.openItems.removeEntry is not a function. (In 'io.openItems.removeEntry(item)', 'io.openItems.removeEntry' is undefined)

Regards
Stefan

[wvhn]

Ah. Sorry! I forgot that I had implemented already a new function in the driver which is not compatible with v3.4. Can you run the test in the develop version of smartVISU?
Alternatively you could try to fix the missing function error by putting the following code in visu.js in the folder of your pages or writing it as a new file e.g. myfunction.js into the ./dropins folder:

/**
 * workaround for v3.4.  Delete after upgrading to a later version
 * 
 * Removes the first occurrence of a given array element
 */
 if(!Array.prototype.removeEntry) {
	 Array.prototype.removeEntry = function(value) {
		if (!value)
			return false;
		var index = this.indexOf(value);
		if (index > -1)
			this.splice(index,1);
		return true;
	 }
	// Hide method from for-in loops
	Object.defineProperty(Array.prototype, "removeEntry", {enumerable: false});
}

Regards
Wolfram

[tukey42]

Many thanks, my first test works!
If I just print the timestamp as integer basic.print('','myItem.property.lc') the correct Unix timestamp is shown.
If I use basic.print('','myItem.property.lc','time','VAR*1000') a totally wrong time is shown, but this seems to be an issue with basic.print itself.

Best Regards
Stefan

[wvhn]

Since @uwe5 wrote that the controller versions may differ in the timestamps unit (ms or s) I added the formula VAR * 1000 in basic.print in case the timestamp is in seconds. I guess your version is already in ms. Just change the formula to VAR*1 and then the time should be correct.

Regards
Wolfram

Edit: This worked for me in a test with v3.4. There has been a fix for basic.print timestamp handling after v3.4 which is in the develop version. See here: 79fd4d1. With that fix you can omit the formula.

[tukey42]

It does not show the right time with or without *1000.
The timestamp is in ms:
1716196335350 (Mon May 20 2024 11:12:15 GMT+0200 (Mitteleuropäische Sommerzeit))
With *1000 it prints: 13:15 (time) or 05.02.56354 13:15 (long)
Without *1000 it prints: aN:aN

I will test the new version of basic.print later. I am on 3.3.1.

Best Regards
Stefan

[wvhn]

I had been editing my comment above after testing with v3.4. Please review and use VAR*1. This should work for v3.3.1, as well.

Regards
Wolfram

[wvhn]

I tested it in v3.3.1. VAR*1 works there as a workaround. The multiplication by 1 converts the timestamp string into a number which is required for conversion into a time/date.

[wvhn]

implemented with #984