Time of last update = 1970

[Spaceman_Spiff (Sebastian)]

My timestamp got updated to 1970.
Any hints how I can fix this?

Number	    Smoke_Batterie              "SmokeAlarm [%d %%]"				            { channel = "zwave:device:controller:node67:battery-level", autoupdate="false" }
DateTime	Smoke_Update                "SmokeAlarm [%1$td.%1$tm.%1$tY %1$tH:%1$tM]"	{ channel = "zwave:device:controller:node67:battery-level", autoupdate="false"  [profile="system:timestamp-update"]}

2021-09-01 08:14:58.193 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Smoke_Update' changed from NULL to 1970-01-01T00:01:27.000+0000

Edit:
I woke the device three more times and its always the same timestamp.

[mstormi (Markus Storm)]

Time machine ?
I’d guess the device does not send anything or what is sent is broken, so the updater assumes “never”, in terms of the long variable that’s used to represent time that’s a ‘0’ and equals into the epoch which is what you see.
(also, “autoupdate=false” on a DateTime item ? Seems weird at least)
Debug your device zwave communications. Ultimately you likely cannot do anything about it except to exchange hardware.

[Spaceman_Spiff (Sebastian)]

@mstormi

Time machine ?

I wish!

@mstormi

I’d guess the device does not send anything or what is sent is broken, so the updater assumes “never”, in terms of the long variable that’s used to represent time that’s a ‘0’ and equals into the epoch which is what you see.

The device reports a battery level of 87% which then gets translated to 1970-01-01T00:01:27

@mstormi

(also, “autoupdate=false” on a DateTime item ? Seems weird at least)

I made it a habit to include this in all Z-Wave fields that report the value themselves.
While this has saved me lots of trouble in my rules (learned through pain) this effectively brakes the system profile.

Once I removed the auto-update from the item definition the system profile worked as expected.

[mstormi (Markus Storm)]

@Spaceman_Spiff

The device reports a battery level of 87% which then gets translated to 1970-01-01T00:01:27

Nah, don’t confuse the value with the timestamp for the value. The timestamp isn’t exactly 00:00 so it was updated, just calculated without/with a bad offset.
Have you waited for another update to see what happens ?

@Spaceman_Spiff

Once I removed the auto-update from the item definition the system profile worked as expected.

Did you mean to say that solved it ?

PS: moved to separate topic. Examples section isn’t for this.

[Spaceman_Spiff (Sebastian)]

@mstormi

Nah, don’t confuse the value with the timestamp for the value. The timestamp isn’t exactly 00:00 so it was updated, just calculated without/with a bad offset.

The device reports battery level of 87. Instead of using the timestamp because of the system profile the battery level gets interpreted as a datetime. Openhab interprets it as secs since 1970:
1970.01.01 00:00:00 + 87 Seconds → 1970.01.01. 00:01:27

@mstormi

Did you mean to say that solved it ?

Yes - it’s working as expected now after I removed the auto update.
It seems auto-update disables the profile.

[rossko57]

@Spaceman_Spiff

It seems auto-update disables the profile.

I’m pretty sure it was your syntax. Remembering that a profile must attach to a channel, it’s not a free-standing gadget-

channel = "zwave:device:controller:node67:battery-level", autoupdate="false"  [profile="system:timestamp-update"]}

is broken. The channel has no profile, the comma says here’s the next parameter, autoupdate has some weird tag that will get ignored.

channel = "zwave:device:controller:node67:battery-level"   [profile="system:timestamp-update"], autoupdate="false"}

{ channel [profile] , autoupdate , other comma-separated parameters. }

[Spaceman_Spiff (Sebastian)]

@rossko57

I’m pretty sure it was your syntax.

I’m pretty sure it was my syntax, too!

You’re absolutely correct - thanks for the hint!
I’ll try to pay more attention next time.

[rlkoshak (Rich Koshak)]

I’m a little surprised it let you link a Number Channel to a DateTime Item without error. Sometimes I wonder if it would be worth the wailing and gnashing of teeth that would result from tightening up the error checking on this sort of thing. There has to be a way to prevent it in cases where a profile is not being used but allow it where the profile is provided which can change the Item type.

In this case it would maybe have given you the hint that the profile syntax was wrong by complaining that you can’t link a Number Channel to a DateTime.

Though even with the error checking I can see where a Number Channel would be allowed to be linked to a DateTime if that Number represents epoch. So maybe not.

[rossko57]

But you can link a Number channel to a Datetime Item … or a Rollershutter to Play if you like. Not just with the timestamp profiles, but with any completely arbitrary arrangement the user cares to make with generic transforms.

Ennyway this one fits a hobby horse about people using files instead of GUI to configure and fighting syntax errors