[quote=“SeeAge, post:20, topic:92836”]
Maybe you could add some words on how that time offset actually works for my better understanding? [/quote]
This is the difference between the time reported by the device, and your local PC time (ie the time on the machine running OH).
The thing to consider is that the offset should not be constant, but the derivative should be (generally) constant. ie the drift on the PC, and the drift on the device should be constant, and therefore rate between them should be constant. Probably your PC is being updated regularly through NTP, so that will have a 0 drift (assuming it’s updated regularly), and therefore the rate you are looking at is the rate of drift of the device.
What the binding does is periodically request this rate, and when it gets above a certain value, it resets it. So if you were to look at every value, say every minute, you would see this regularly increasing until it is reset.
The first plot in your graph has nothing before it, so this looks fine to me without actually seeing the actual data. The others in general are regular although there does look like there might be a low value in there, but that might be a graph artefact.
Anyway, I hope that helps you understand how this works?
My first understanding was that it would be a fixed value constantly displayed in the time offset item, which displays the offset between my raspi and the device (I am not sure if the raspi is synced but my FritzBox acts as a time server so it could be), but if I understand you correct the peaks that can be seen in my chart are the sync events and after the sync event, the offset is and should be zero.
FYI, the value which is not 0 for a longer period is 60 in the chart. The item actually had this value.
My main question was, if the chart looks okay like this and second if the values of the high peaks are okay like this. So you answered this question.
Do you know the unit of the time offset? Since the automatic update is only started when the time differs more than 60 seconds, I cannot explain the 10k-30k values?
In milliseconds it would be 10-30 seconds which is too less and in seconds it would be way to much.
No - it will not be a fixed value. Clocks drift at different rates. If the clock drifts at 1 minute per day, then if you look after 6 hours, the value will be 15 seconds - look in another 6 hours, it will be 30 seconds.
If there was no update for 2 days, then the value would be 120 seconds, so it is certainly possible to have values higher than expected if there was no communication for some time.
It should be in seconds from looking at the code.
The large one is right at the beginning - maybe the time was this far out (8 or 9 hours) at some point as it hadn’t been controlled for a long time, and it was reset? After that it looks “ok”. That said, this seems to indicate that it’s drifting by 1000 seconds / day, which in itself doesn’t seem ok!
If you can grab a debug log showing the requests I’ll take a quick look.
I guess you need one at the moment when the syncing happens?
As I never did that before, I guess I need to enable debugging for the zwave binding, correct?
Okay, I finally managed to do the debug logging. The timeoffset is reported in the event.log:
2020-07-06 01:35:19.091 [vent.ItemStateChangedEvent] - UG_AZ_Thermostat_TimeOffset changed from 0 to 2039
2020-07-06 01:35:24.415 [vent.ItemStateChangedEvent] - UG_AZ_Thermostat_TimeOffset changed from 2039 to 0
Here is the ZWave Debug log. It contains some minutes before and after the above mentioned time. ZWave.TimeOffset.Debug.log (895.1 KB)
The node id of the UG_AZ_Thermostat thing is node111.
If you need more around it, I saved the full log of some hours on my computer.
Thanks for taking a look, let’s see if this thing is working as it should.
.